data будни

Как в Википедии, ты тыкаешь на одну ссылку почитать, и все, через 3 часа ты читаешь про то, как разводить кабачки в условиях болтной местности.
Так и я продолжил читать статьи Maxime Beauchemin и наткнулся на свежую How the Modern Data Stack is Reshaping Data Engineering

Вообще, выражение Modern Data Stack это уже баззворд, пихают его везде. Чаще этой фразы я слышу только “Hadoop умер” (нормально он себе живет относительно нишево, ничего он не умер, как и Ruby, не слушайте шарлатанов).
Так вот, основные моменты из статьи

Data infrastructure as a service
Нам пора думать о платформах, потому что без развития платформы, невозможно расти дальше определенного этапа, слишком больно.

Data integration services
Готовые решения по интеграции данных будут заменять постепенно скриптики, которые мы написали для REST API

Mountains of Templated SQL and YAML
Были полотна YAML шаблонов, теперь и полотна SQL. Программисты не любят SQL, говорят про инъекции, грязный код и вот это все, но количество аналитиков всех мастей растет, а для них SQL основной инструмент

ELT > ETL и Reverse ETL
Данные в хранилище мы научились поставлять. А теперь бы нормально научиться отдавать в наши системы.

The rise of the analytics engineer
Ага, DataOps это вот сюда тоже.

Ну и еще несколько пунктов. Сходите почитать, полезное чтиво.


P.S. на картинках можно заметить, что почти во всех пайплайнах есть DBT. 😄

P.S.S. Если лень читать, можно послушать на английском языке его доклад на эту тему https://www.youtube.com/watch?v=EKhYGYrq0eI

Мне близок Сашин взгляд на то, что болит у аналитиков - обобщил бы это как "борьба за качество данных".

Я тоже походил по Матемаркетингу, пообщался с людьми, доклады послушал.

К перечисленному в посте могу добавить 2 больших блока болей:

🔸Демократизация данных и self-service BI. Аналитики все чаще становятся бутылочным горлышком в процессе принятия решений и больше времени тратят в роли интерфейса к базе данных для своих коллег. Решают ее все по-разному, в основном с помощью новых процессов, open-source инструментов или самостоятельной разработки.

🔸Работа аналитиков в маркетинге сильно меняется из-за новых privacy-политик от Apple и Google и возможности запрета трекинга. Способы дальше работать есть, но со стороны выглядят как костыли. Я в этом, честно говоря, не разбираюсь и был сильно удивлен масштабом бедствия.

P.S. был безумно рад всех увидеть в оффлайне и познакомитсья с кучей клевых ребят!

#конференции

Стас добавил ещё два пункта по текущие проблемы. Про селф-сервис полностью согласен — в идеале данные должны быть легко доступны (а значит, правильно подготовлены и полно описаны!).

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

ламповые объявления о работе с Матемаркетинга

кажется, это не попало в официальные трансляции) выложу сюда часть, чтобы добро не продпало

Документация на данные

Принцип «всё как код» — и таблицы тоже.

Частая проблема в документации — её просто нет ¯\_(ツ)_/¯ а если есть, то она устаревшая.

Так бывает, когда документация не зависит от текущей реальности: красивые описания живут в модном Ноушене, но DDL в Postgres ничего про это не знает))

Что делать? Переселить документацию ближе к реальности. В Яндекс.Такси решили, что все сущности в ДВХ будут описываться в коде — названия, колонки, их тип и комментарии (!). Нельзя просто так поменять атрибут без изменения документации — всё связано.

А раз описания уже в коде, это всё версионируется через гит с указанием ответственных. К тому же всё можно обвешать автотестами (всё как у настоящих разработчиков!): назвал колонку не по канону — не сможешь замержить свой пулл-реквест, пока не исправишь.

А ещё пулл-реквесты удобно ревьюить. Скинул ссылку старшему коллеге и он в одном месте видит все изменения, аккуратно подсвеченные. Если что не так — комментит нужную строку.

Что болит

Общее впечатление что все хотят в data driven. Уже никого не надо убеждать в ценности данных — этот этап пройден.

Теперь следующая проблема — данные собрали, пайплайны настроили, первые дашборды нарисовали. Постепенно данных становится всё больше: добавляются новые, старые — меняются. И в какой-то момент наступает ДАТА-ХАОС!

И вот сейчас основные боли — это документация и описанные модели данных.
⁃ Таблицы на десятки и сотни колонок без описания и странными названиями
⁃ Таблиц по заказам — пять разных вариантов (плюс ещё сколько-то вьюх по ним)
⁃ Эвенты, названные абы как
⁃ Метрики, которые каждый рассчитывает по-своему и в конце ни у кого ничего не сходится ¯\_(ツ)_/¯

Короче, тренд сезона — дата-инфраструктура.

прямо сейчас идёт конференция Матемаркетинг — на сайте есть трансляция одного трека (из трёх доступных).

Уже был мега-полезный доклад от Влада Флакса про общие концепции как сделать данные на бещбордах актуальными

И новый бомбический доклад Ромы Бунина (лучше, чем новый фильм Марвел!) — ещё один взгляд под капот архитектуры дашбордов на примере Яндекс GO.

https://youtu.be/BowbeThqKmU
(идёт трансляция, поэтому не даёт дать ссылку на конкретный таймкоды — Флакс был в начале, Бунин примерно на 1:15 от начала)

П.С.: я сейчас здесь, на выставке — если что, давайте встречаться :-)

[ЧЕРЕЗ ПОЛГОДА] Команда инфраструктуры приносит работающий продукт:
⁃ Понятно, какие СУБД нужны
⁃ Какие бывают «стрелочки» между ними
⁃ Как раскладывать данные на слои

<<< здесь пригождается план перехода с текущей архитектуры на целевую (только что ↑ придуманную)


Как отрефакторить большой DWH? Разделить на небольшие кусочки!

Как монолит делят на микросервисы, так и хранилище данных можно разделить на свои етл-сервисы. Каждый по отдельности проще отрефакторить, чем всё и сразу (и потом ещё удобно стыдить другие сервисы за их отсталость!).

Ещё в каждом етл-сервисе свои релизы — можно тестить новые фичи независимо от других сервисов.


[ЕЩЁ ЧЕРЕЗ ГОД] Изменения в команде

Команда инфраструктуры:
⁃ Целевая картина появилась и работает
⁃ Разработчики узко специализированы

Команда продукта:
⁃ Выросла в 2 раза
⁃ Переписали самое болезненное легаси
⁃ Собрали «низкие фрукты»
⁃ Наладился контакт с бизнес-заказчиками

Следующие цели:
⁃ Ускорять работу продукта
⁃ Переходим на работу по эпикам
⁃ В каждый эпик подмешиваем рафакторинг

Видео с доклада на Youtube | Презентация на сайте конференции

Разделить команду на инфраструктуру и продукт

Команда инфраструктуры:
⁃ Разработчики с широким кругозором
⁃ Найм небольшой

Люди, которые не приносят пользу (и выручку!) бизнесу напрямую — по сути, это такой «налог на инфраструктуру».

Команда развития продукта:
⁃ Разработчики, близкие к бизнес процессу
⁃ «Реальная» работа (в терминах бизнеса)
⁃ Весь найм сюда

Работа начала налаживаться, но система имеет большую инерцию и по-прежнему пайплайны падают. Просто взять и переписать всё с нуля заняло бы год (= полностью остановить работу над продуктом на это время).

Решение:
⁃ Выделить квоты времени на починку самого важного: 20-40% своего времени разработчики разбираются с технологом.
⁃ Ввести «дежурство». Разработчик на 100% времени занимается стабильностью системы: выкатывает релизы, оперативно чинит мелкие баги, сложные — диагностирует и делегирует. Дежурят все по очереди.

Как в 2019 году в Яндекс Такси «взорвался» DWH

Фёдор Лаврентьев — руководитель тамошнего хранилища — рассказал на конференции HighLoad, как хранилище перестало выполнять свои задачи и как они потом это всё чинили (на первый этап ушёл год).

Само хранилище разрабатывали с 2016 года. Как обычно, всё начинается с одной прикладной задачи, потом добавляется ещё одна и так наслаивается одна за другой. А про общую архитектуру подумать как-то всё некогда.

В какой-то момент начинается «ой всё сложно»: пайплайны падают. Витрины опаздывают. Данные неверные. Бизнес негодует.

Подумать про общую архитектуру каждый раз некогда — сроки горят; поэтому всюду постепенно появляются «локальные костыли, заплатки и смелые решения».

В итоге окончательно ломается контроль над рантаймом: не знаешь что происходит прямо сейчас.

Хочется всё взять и переписать!

Но тут надо разобраться.

В итоге родился план «Вулкан» в три этапа:

I Архитектура
1. Придумать целевую архитектуру
2. Наметить план перехода к ней (неотделимо от п. 1)

II Рутина
3. Почистить бэклог
4. Наладить работу с закзчиками

III Техдолг
1. Найти и замониторить всё важное
2. Переписать легаси-процессы
3. Перестать плодить легаси-код