Пример решения для 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.

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

Вдруг вам будет интересно поучаствовать и поучиться: Х5 проводит масштабный контест по машинному обучению, успейте зарегистрироваться!

RetailHero - это не одно, а сразу три соревнования и конференция 15 февраля 2020! Разыгрываются 1 600 000 ₽ призовых 💰

Организаторами были подготовлены три задачи, чтобы учесть вкусы самых искушённых участников:

✨ Каким клиентам нужно отправить SMS?
Вы не раз могли слышать про Uplift моделирование. А теперь - наконец-то можно его попробовать реализовать самим! В этой задаче необходимо подготовить список клиентов, ранжированный по эффективности коммуникации.
https://retailhero.ai/c/uplift_modeling/

✨ Какие товары клиент купит в следующий раз?
Более серьезная задача, где будет еще и немного ML Engineering с условиями еще и по нагрузке на решение. Тут участникам предстоит построить рекомендательную систему и при этом сделать сервис, который выдержит нагрузку.
https://retailhero.ai/c/recommender_syst…

✨ Как расставить товары по полкам?
Для любителей Computer Science, алгоритмов и оптимизации, ACM-style задача. Нужно реализовать алгоритм, который сможет найти самую эффективную расстановку товаров.
https://retailhero.ai/c/shelf_allocation…

Участвовать можно хоть в одном соревновании, хоть в двух, хоть в трёх, на ваш выбор! 🙂
Можно в команде. А можно в составах разных команд - в каждой задаче в новой команде 👍🏻
Канал для всех задач в slack ods.ai: https://app.slack.com/client/T040HKJE3/C…

Регистрация на соревнование и конференцию, подробное описание задач на странице Retail Hero:
https://retailhero.ai/

Короткая статья о главных вопросах и ошибках в управлении данными. Ее написала Светлана, которая является CDO ВТБ. Я с ней познакомился на конференции в Бостоне EDW19 в прошлом году.🤗