#faketillyoumakeit #jobchange
У меня есть несколько интересных историй, про знакомых и друзей, кому я помог поменять работу или изменить даже жизнь, не знаю к лучшему или худшему. Помогать хорошо для кармы, или просто хорошо, поэтому есть несколько success stories, которые еще актуальны, говорят о том, что все в ваших руках.

История 1,2.
История 3 и 4
У меня был товарищ с завода, он меня научил работать на фрезерном станке🤩. Его звали Стас С. и у него был еще один друг Стас П, который любил говорить "доконца гандончики", после службы ВДВ. Особенно, когда мы ходили на турник или делали что-то с SAP BO.🤣

У меня была прям мания, помочь всем обязательно найти работу получше и мне очень хотелось "обмануть систему". После завода, где много начальников и бюррократии, я понял только одно, в отделе кадров большинству все равно. Например, мы думаем, что наше красиво резюме будет распечатано HR, прочитано за чашекой чая (кофе), потом его покажут коллегам и тп. В реальности все не так.

Все работают с большой нагрузкой и в режиме мультизадачности. Это значит, когда мы отправляем резюме, то в лучшем случае HR бегло глянет на него, найдет ключевые слова (BI, DW, SQL) и потом уже назначит следующий шаг. Но если он ведет 20 вакансий, и на каждую приходят по 20 резюме, и при этом нужно успеть попить кофе и с коллегами пообщаться (все мы люди, а не роботы), то получается, все что нужно сделать, это правильно завернуть резюме, чтобы пройти первый farewall и попасть на собеседование. Сам процесс наема это тоже очень интересный процесс, он занимает время, вам нужно отрываться от работа, и там очень много bias, особенно в компаниях, где обычно вас собеседует начальник, то есть в 80% вам надо понравиться начальнику. Я все это к тому, что сам по себе опыт, это не всегда главный критерий.

Стас П. заинтересовался в BI. Дальше все по классике, SQL, SAP BO, database и все это дело на виртуальной машине, новое резюме, несколько историй про BI проекты, и на собеседование в Lamoda. В итоге Стас П стал работать младшим BI разработчиком. Теперь самое главное пройти испытательный срок. Секрет успеха прост, мы компенсируем не знание предмета своим временем, то есть то что я могу сделать за 2 дня, он может сделать за 5 дней, но у него есть в запасе 18 часов в сутках + 2 выходных, таким образом можно все успеть и подтянуть знания. Сейчас, Стас П работает в Польше, внедряет SAP BO, и наслаждается сельской местностью своей деревней под Варшавой, ездит на мерседесе Е класса в Беларусь и Калининград на выходных😎

Стас С. тоже пошел по такому пути, SQL, SAP BO, резюме и истории, он устроился в Перекресток - BI разработчик. Но не прошел испытательный срок. Просто ему это оказалось не интересно, и он не захотел в это развиваться. Он так до сих пор не нашел себя. Поэтому работу найти просто без опыта с выдуманным резюме, а вот удержаться сложнее, нужно обладать самомотивацией и усидчивостью.

Как Амазон тестирует продукты https://youtu.be/e1YwohZPFWg

Пример решения для Amazon Redshift. Решения используют микросервисы, то есть вместо монолитного ETL, у нас много сервисовм, которые работают независимо, и все они выполняются сервисами AWS (AWS Step Function, Lambda, Batch). Микросервисы очень хороши для приложений и ПО. Но я не люблю использовать такие решения для DW/BI, я за gentle data engineering с фокусом на скорость (fast time to merket/insights) и на бизнес пользователей. Но это моя история, я привык работать в быстро движущейся среде. Возможно в традиционных организациях, где главное стабильность, а не скорость, и где есть армия разработчиков, такие решения хорошо зайдут.

Еще один важный тренд, на примере AWS, решение можно развернуть используя шаблон CloudFormation (аналоги есть Azure, GCP). Это очень важный элемент, и если вы делаете решения в облаке, обязательно изучите вопрос шаблонов, чтобы ваше решения могло быть развернута с одного клика.

И если вы используете Power BI, то обязательно подпишитесь на чатик Power BI🤗

Вот пример Микросервисов VS монолита. Архитектура микросервисов разбивает приложение на набор маленьких loosely-coupled сервисов. Loosely coupled значит, что сервисы могут общаться через надежные API. Если один из сервисов сломается, то все решение будет продолжать работать.

Самый большой Redshift Cluster может быть 128 нод. Я работаю с таким кластером. 128 Node типа dc2.8xlarge. Это максимально возможное кол-во нод и одновременно недостаток Redshift. 326 ТБ данных (с компрессией это в 2 раза больше данных). И этого нам не хватает. То есть вроде как облако, где можно кликнуть и удвоить мощность, а вроде и уже нельзя. Но это не главная проблема хранилище данных. Главная проблема это кол-во одновременных запросов. (concurrency). То есть кластер может одновременно обрабатывать 15-20 запросов, остальные в очередь. Есть также Work Load Manager (это можно для каждого пользователя настраивать правила, сколько может быть одновременных запросов и при каких условиях убивать плохие запросы). Самая дорогая операция - это копирование данных между нодами (data distribution), именно поэтому единственное что важно знать в аналитических хранилищах - это правила распределения данных и варианты (Distribution style, sorty key), чтобы снизить нагрузку на копирование ТБ данных по сети.

У меня была задача, пересчитать метрика за 2018 и 2019 года. Я не могу это выполнить одним запросом, так как если я запущу запрос, где данных больше 1 недели, WLM его убьет. В итоге у меня 1 запрос - это 1 день. Значит надо где-то 600 раз запустить один и тот же джоб. То есть можно это сделать programmatically. Вот когда нам нужно знать Python. Сделать цикл, который будет запускать джоб (ее API). Недолго думая, я запустил все это дело с параметром 1000 параллельных запросов. И я сделал это несколько раз.

Я не знал несколько деталей, сколько одновременных запросов может обрабатывать Redshift от этого пользователя (оказалось 3), сколько обычно Redshift обрабатывает запросов (оказалос 1500-1800). В результате выстроилась очередь в 3500 запросов и несколько дней.

Ситуация мне напомнила книгу "Продавец Обуви" - "Вас запоминают не за правила, которым вы следуете, а за правила, которые вы нарушаете". В целом, это проблема дизайна, то есть когда строили хранилище, не знали, что с ним будет дальше. И это уже второй Redshift, который переживает сложные времена. Другая команда, имела похожие проблемы, в итоге они заменили все на Озеро Данных (S3+Athena). Но главный challenge для озера данных и big data платформ, это GDPR, то есть как удалить клиента, если он лежит в каком-то Parquet файле.

Еще напомнило. Самолет это Redshift, красные точки это запросы. И возможно мои запросы не были так критичны (3-4 минуты) один запрос, как запросы кого-нибудь, которые могут висеть вечно и никто не узнает про них (например, если вы запустили запрос и удалил job, и он будет вечно висеть и занимать слот)

Как я понял, эта книга просто бомба, The Great Mental Models. Меня поразила цена в 80 баксов за твердый переплет, их совсем мало. Но очень заинтересовала. Никто не читал?

Написал блог про сертификацию. Там половина в общем про сетификацию, а 2ая половина про табло. На самом деле это текст предназанчался для книги по Табло сертификации, но я указал 3 основных случая, когда нужна сертификация и почему:
1)Требование работадателя
2)Требование клиента(консалтинг)
3)Просто показать, что у нас есть скилы. Но это не очень крутой аргумент, чтобы зубрить экзамен.

Я например сдал Tableau Desktop и Server, чтобы стать Tableau Alliance Partner. Так еще сверху заплатил 3k US$, partnership fee. Теперь у меня есть Tableau Server, Desktop и Prep и 25 лицензий. Но в марте все это кончается, и будет вопрос, а стоит ли продлевать эти отношения или нет.

Сказали, что очень классный курс - https://www.startupschool.org/. К сожалению, все инкубаторы нацелены на продуктовые компании, и я еще не встречал информации по сервисным компаниям. Оно и понятно, сложно масштабируется и зависит от команды. Если, что знаете, кидайте в комментарии.

Кстати одна из моих любимых книг по аналитике это Lean Analytics. В этой книге есть KPI по основным индустриям и примеры методологий, включая мой любимый OKR.

Полезный коммент увидел про удаленную работу

Weekly Business Review или WBR или Wall of Numbers - еженедельные встречи в Амазон, где обсуждаются метрики. Амазон же data-drive компания. Что это из себя представляет? Прежде всего отчет (обычно без графиков и визуализации, вообще) в формате PDF (экспорт из Tableau в лучшем случае) или просто Excel (в 80%). Вот вам ирония, самая data driven компания смотрит в статические отчеты и делает это раз в неделю. Отсюда напрашиваются выводы:

1) Для бизнес метрик и целей, нужно ли нам делать near real time data pipelines? Конечно нужны, но все зависит от задачи и требований.
2) Нужно ли нам смотреть на наши показатели 5 раз в день, каждый день? Важно держать руку на пульсе для операционных метрик, но там нужно настраивать систему оповещения (alert) если что-то отклонилось от нормы.
3) Нужно ли нам много красиво графиков? Доказано, что визуализацию лучше цифр. Но бизнес лидеры предпочитаю смотреть на цифры.
4) Нужны ли нам дорогие инструменты визуализации и аналитики? Для статистических отчетов типа WBR нет. Но для анлитиков, которые ковыряются в данных (deep dive), нужны.

Вывод простой, неважно каким образом мы строим отчеты, и что используем. Они должны помогать бизнесу делать их работу - смотреть на данные и принимать решения, которые нацелены всего на 3 цели:

1) Увеличить прибыль
2) Снизить издержки
3) Снизить риски

Пример WBR слайда. Обычно это 50 страниц, где могут смотреть на одни и теже метрики в разных разрезах. Всегда готовят 50 слайдов, но обсуждают только 10, которые важно обсудить. Перед встречей нужно, написать callouts (что значимого случилось), после встречи часто нужно делать deep dive, и объяснить отклонения, во многих случаях это ошибка в ETL (нет инструментов data quality, notifications).

Абсолютно все делают такие отчеты, и многие изобретают велосипед.

WBR

Ebook - Science + Data

Попробовал использовать хабр и перевел статью про озеро данных. Уже вижу комментарии под постом как в анектоде: "На форуме пишут, не подскажите, где купить хороших яблок?", А в ответ: "Зачем вам яблоки? Лучше груши" или "Опять вы со своими яблоками, уже всем надоели ваши яблоки" и другие упрёки, это очень у нас такой менталитет🤠 если есть чего по делу можно написать поподробней, рассказать, чтобы другим было понятно и полезно. В общем это был эксперимент. Кстати комментарий с рекламой облаков меня поставил в ступр, я нахожусь в другом рынке и конечно у меня bias в сторону того, что я использую в Амазон, rock your data и в целом в моей индустрии. А возможно это как писать про то, что уже надоели со своими машинами во времена, когда форд изобрел автомобиль, может облака это тоже прогресс? В общем если нравиться и полезно, ставьте лайк, если есть чего добавить расскажите так чтобы было всем понятно, а если нет, можно мимо пройти🥂

Слышали вы про H20? Это платформа для data science и ml. И это open source. https://youtu.be/BtnugVpu7V8

А вам знакомо?🙈я и команды не помню😳

А вот и пример MLOps с использование Git и DVC (раньше я только знал про MLFlow).

Если вы следите за трендами в индустрии, то знаете Snowflake. Хотя это слово у меня в канале в топ key words)) В общем, теперь же это платформа данных. Вот один из аргументов, у Snowflake есть утилитка - SnowSQL это CLI тул через командную строку, хотят такой же был и у Терадата, вроде BTEQ. Но есть и еще один - SnowPipe, это такая штука для потока данных в Snowflake. Вот тут подробности.

Я бы заменил Infrastructure Engineer на SysAdmin. Часто нужно помощь с настройкой доступов, аутентификации, сетей и тп. В облачных решениях отпадает надобность в инженерах, которые обслуживают Hardware и занимается установкой Software. Очень классно поделили на Doeкs и Thinkers! А вы кто?

Небольшой update по Startup School от Y Combinator. Прошла неделя 1. Посмотрел 3 видео, очень классные, все применимо даже для обычного BI разработчика, если подумать, что ваш проект (отчет?) это стартап, и вы решаете проблему (боль) клиента.

Они предлагали пообщаться с другим стартапами в группах, по 4 компании. Почему бы и нет. Я думал, послушаю, как люди делают стартапы, а получось очень даже интересно. Один стартап вообще без беты был, один чувак пилет приложение какое-то, зато в Ванкувере живет. А вот другой был из LA, у них приложение для каких-то видео мемов. Даже инвестиции получили. (Как минимум для вас бесплатная практика английского и можно любые вопросы задавать, а вдруг на работу еще возьмут!). А вот это компания https://www.productlift.io/ (из Ванкувера) ищет co-founder (разработчика), если кому интересно, могу познакомить (отличный вариант поучиться создавать приложения на AWS, говорить по английски и изучать продуктовую аналитику на реальных клиентах).

Я им рассказал про Rock Your Data, они сначала ничего не поняли (то есть я толком не могу рассказать, что я предлагаю), потом они поняли. Оказалось, что это прям боль стартапов - аналитики, платформа данных и метрики в дашбордах. Договрились, что я им почти за бесплатно попробую сделать аналитическое решение, и у меня будет reference и у меня будет, что предложить другим. Возможно пытаясь продавать услуги в Medium и Enterprise это сложно и требует связей, посмотрим как у стартапов. И самое главное, если классная компания - Fishtown Analytics, которая только это и делает и не нужно изобретать велосипед.

Кстати через них зашел на BI инструмент Mode. Я его знаю, это такой SQL friendly Cloud Native BI. Оказывается бесплатный до 4гб и одного пользователя. Делаете Аналитику для себя? Стоит попробовать, в качестве DW можно взять BigQuery (до 5Гб фрии в год) или Azure SQL Server (12 months free). Или платить копеечку AWS.

Кстати, если вы в ранней стадии и вам нужно аналитическое решение, не стесняйтесь спрашивать, всегда интересно, кто и чего делает, и как.