Согласитесь, первое, что приходит в голову, когда вы слышите Data lineage это визуализация диаграмм потоков данных. Это могут быть и pipeline как в informatica ipc или, я например, видела кастомную визуализацию в виде графа. Очень интересно, но ничего не понятно.
Обладаю намерением рассказать, что визуализация важна, но вторична.
План заметки:
- Применение lineage
- Подводные камни внедрения
- Причем тут коты
Итак, lineage - это “родословная”, а точнее метаинформация о связях между объектами (source/target) внутри вашего DWH и шире (это важно).
Применение
1 Анализ влияния (Impact)
1.1 Мониторинг загрузок
Допустим, упал поток загрузки. На какие расчеты это влияет? Требуется остановить какие-то процессы, которые идут после?
Спорный момент тут заключается в том, что наличие lineage это лишь малая часть метаданных, которая нужна для того, чтобы в действительности оценить влияние и отреагировать на ситуацию. Рекомендую статью на эту тему: https://medium.com/airbnb-engineering/visualizing-data-timeliness-at-airbnb-ee638fdf4710
Если без картинок, то можно сделать следующее:
- Autorecovery на различных этапах pipeline
- Заведение проблем в тикет систему
- Отправка уведомлений о влияние
- Подготовка сводного ежедневного статуса(в формате светофор - без диаграмм) по влиянию на критичные процессы бизнес аналитиков
1.2 Анализ проблем с качеством данных
Раскапываем проблему в target таблице, через предыдущие этапы трансформаций.
Если без картинок: В этом случае картинки могут быть очень хороши. Потому что открывая 5 подзапрос, в 3 view ты реально забываешь с чего начал. А если это все есть на картинке и как-то условно “кликабельно”. Это актуально если мы говорим о каких то новых/нетипичных ошибках, или если проблемами с данными занимаются совсем не те люди, которые этот код писали. Потому что в иных случаях - вот эта базовая логика связи объектов лежит в голове у аналитика или инженера.
- Просто имея список связанных объектов - можно пробежаться и поискать как выглядела интересующая строка записи в предыдущих своих реинкарнациях на более ранних стадиях загрузки - а лучше начать с самой ранней и источника.
- Если речь идет о промежуточных расчетах, так же можно count-ами рассчитать с какого момента идет значительное отклонение от ожиданий.
1.3 Реинжиниринг витрин, а точнее этап блиц анализа и оценки сложности.
Представим есть stg схема с больше чем 1000 атрибутами, а в итоговой витрине около 300 атрибутов. Нужно воспроизвести финальную витрину на другой бд.
Например, вы можете вообще не знать из каких источников загружены 1000 атрибутов. Определение источников и типов подключения - в данном случае базовая потребность.
Получив lineage можно разделить данные на бизнес домены, оценить по кол-ву связей сложность логики.
Понять наличие дублирования алгоритмов или излишне запутанных расчетов и сделать код более простым.
Но для непосредственного создания новых алгоритмов в моем понимании все равно нужно смотреть код и/или какую-то техническую документацию.
Если без картинок:
Лично мне как аналитику табличный вид удобнее всего на свете, но это субъективно. В таблице при помощи фильтров и CTRL F найти все таблицы, где ключ клиента - FK, или, например, все таблицы, где есть историчность, в них есть минимум одно поле с датой без технического названия.
2.Тепловые карты и удаление данных
Если есть данные, которые никак не используются в бизнес сценариях - будь то какие, то определенные специфические таблицы, или очень широкие таблицы с неиспользуемыми атрибутами - целесообразно продумать механизмы охлаждения этих данных и переноса в архивы.
Но возвращаемся к теме того, что нужно больше метаданных, lineage требуется объединить с информацией о частоте загрузок, наличию и активности использования в пользовательских и технических приложениях.
Наоборот информацию о наиболее используемых объектах можно использовать для ранжирования выборки в дате каталоге.
3. Безопасность (GDPR и прочее)
Во всех системах есть персональные данные или чувствительные данные - csv коды от карточек, например, нужно(а часто и по законодательству положено) понимать куда они утекают и как контролируется доступ к этим данным.
Ограничение, которое имеет тут место быть, что после трансформации чувствительность данных меняется: например, при группировке и если lineage реализован не до уровня полей - может возникнуть избыточность ограничений.
4. Инструмент документирования
Data lineage - сам по себе ценность, потому что это какой-то иной (кроме кода) способ фиксации информации о логике загрузок. DWH - клуб любителей сохранять данные. А Data governance - клуб любителей сохранять метаданные. Информация о связанности объектов данных имеет огромный, думаю нам еще не вполне понятный, потенциал: как, например, обучение искусственного интеллекта писать запросы отвечающие типовым запросом бизнес аналитиков на базе профилирования данных источника.
Подводные камни внедрения
1. Отсутствие инструментов автоматизированного сбора Data lineage
Если для РСУБД довольно много всяких приятных движков по парсингу кода, то например когда код пишется на Scala. Вся логика сходится к тому, что чтобы было что раскладывать в lineage нужны стандарты разработки и методы мета описания объектов.
Если Data lineage документируется вручную - много рисков, что он не соответствует реальности и устаревает.
2. Логика загрузки на разных инструментах
Допустим что-то написано на sap data services и там все красиво и понятно, а вот этот кусок загрузки ба бац и на микро сервисах от разных команд и как следствие необходимость собирать и систематизировать метаинформацию или вручную или с помощью дополнительных сервисов.
3. Нет процессов и инструментов обеспечивающих актуализацию метаинформации
При проектировании решения нужно сразу думать про то как мы будем с каждым релизом или с каждым обновлением кода получать обновленную метаинформацию. И не будет ли это слишком дорого и долго для наших команд - а это вызов.
4. Нет возможности контролировать фронтальные объекты
Это как раз то самое “шире” из определения Data lineage, которое я сформулировала выше. Если есть дашборды в отдельной системе, куда данные поставляются большими витринами или, например, песочницы с бесконтрольными возможностями подгрузки через jdbc, но в именно там решают значимые для бизнеса вопросы, приходим к тому, что видим цепочку, но без самого нужного флага - “вот это на самом деле важно”.
5. Недостаточно других метаданных
Про это уже упоминала выше, кроме lineage нужно решить базовые вопросы управления:
- определение перечня дата объектов и ответственных за них
- релизные политики и практики включающие актуализацию метаданных
- sla с потребителями
- бизнес актуальность данных
Каких котов спасаем?
lineage очень популярная фича, ее продали и не раз на тех самых слайдах с короткими формулировками. Вот, например, 31 голос она получила (где 32 самая популярная фича) в результатах опроса после 5 дневного тренинга по governance культуре https://t.me/datanature/192 обыграв, например, статус качества данных объектов.
И действительно, дело хорошее, но все точно так же, нужно понять какую конкретно нишу (“котов”) будет закрывать она в данном конкретном случае, насколько это реально. (моя заметка на тему важности формулировок в бэклоге: https://t.me/helenlovedata/76)
Предложу следующих “котов”, в которых мне кажется максимально целесообразным использовать Lineage.
1. Небольшие группы команд, которые разрабатывают на едином технологическом стеке, выстроены процессы devopsa и управления дата объектами, формализованы требования критичности от бизнес аналитиков.
2. Как помощь в переработке большого количества кода - например, переехать в другое хранилище при смене технологического стека и сделать новое dwh “лучше”, а pipeline прямее.
3. Если у вас очень большая текучка кадров (шутка, или нет ;)) - т е действительно если людям регулярно приходится разбираться в чужом коде - будь то вопросы качества данных, или восстановления загрузок.
Во всех этих случаях прежде чем что-то рисовать и тратить на это время, лучше уточнить качество метаинформации, которой вы обладаете! Но вообще, аналитики решительные, и им что угодно, лучше, чем ничего.
Приоритет бэклога в 140 символах.
Есть довольно много методик, которые помогают приоритезировать продуктовый бэклог. В необходимости учитывать техническую сложность реализации они релевантны к инструментам и задачам управления данными.
Но не релевантны, например, в следующем:
1. Заказчики и потребители фичей часто разные люди ( заказывает - политика по управлению данными, потребляет - d-people) те ценность не в руках потребителя.
2. Отсутствует возможность очевидно превратить результат в деньги или другие простые показатели типа CSI
3. Дорого мониторить более сложные метрики (например, тепловые карты использования данных)
4. Количество потребителей может не иметь никакой прямой связи с важностью задачи
Сижу смотрю на бесконечные бэклоги(70+фичей) к "Дата Платформе"(как заказчик), к развитию "Дата Продукта"(как исполнитель).
И понимаю, что даже если предположить, что у владельцев продуктов появится время на методики оценки, то для customer journey map, требуется вовлечение потребителей, скольких? и долго этот CJM будет актуален?
Если говорим про governance - то это все про внутренние сервисы компании, можем ли обосновать руководству затраты на подобные исследования? Круто, если да.
В свою очередь, очевидно, что например, топ менеджеры принимают и более сложные решения. На что они смотрят? На цифры, ок, а рядом с цифрами что? обычно текст. Простой, понятный, вынесенный на определенный существенный уровень абстракции. И текста немного, по каждому варианту вероятно не больше 140 символов.
Моя мысль в том, что формулировку описания фичи нужно составлять как тот самый "тезис" для руководства - добавить существенность и простоту. Что делаем? зачем именно эту фичу(главная причина)? и ну и потом оценку сложности реализации от продуктовой команды.
"Зачем" может быть естественно и без цифр, а просто качественный и если не выходит сформулировать, возможно и не стоит тратить на это ресурсы? Опять же сама формулировка и её понятность не погруженным людям и будет служить лакмусовой бумажкой пользы.
Таким образом, могут появиться такие прекрасные фичи как:
1.Расширим атрибутный состав в витрине “отчет для шефа” не за 10 дней, а за 5 благодаря тому что будем иметь возможность за 1 день перекинуть текущий срез данных в доступную для прототипирования среду. А мы расширяем отчет раз в месяц. (228 символов)
2.Сможем отследить наличие у критичных витрин влияния на Потребителя если у нас будет Data Lineage и связаться с ним в тот же день, а не он к нам придет через 5 дней когда найдет ошибку (163 символа)
3 Сможем видеть не только статус загрузки данных, но бизнес дату актуальности после интеграции системы мониторинга и системы ККД, что позволит нашему бизнесу раз месяц случайно заглянув в дашборд увидеть актуальную дату (217)
Да, звучит немного как детская сказка, но мне кажется проще это приоритезировать чем обезличенные пусть и ещё более короткие фичи ниже пусть и снабжённые неким ICE:
1. Поставка данных в песочницу за 1 день
2. Lineage по всем потокам данных
3. Интеграция системы ККД и Мониторинга
Согласитесь, по сказкам выше становится заметно, что-то, что кажется правильным, зачастую никому и не нужно.
В комментарий добавлю: ссылку на методики оценки бэклога (я их даже прочитала, и несколькими пользуюсь) и примеры количественных метрик успешности фичи.