Как командам по работе с данным документировать свою работу? Большая часть заметок и описаний являются внутренними, но у команды Gitlab есть огромный детальный и интересный раздел Data team [1] описывающий буквально все аспекты работы с данными внутри Gitlab: взаимодействие команд, инфраструктуру данных, используемые инструменты, решаемые задачи, перечень дашбордов и источников данных, правила программирования на Python, правила настройки dbt и ещё много чего другого.

Учитывая насколько дата инженеры, аналитики и сайентисты не любят документировать свою работу, то вдвойне полезно почитать.

А я бы обратил в этом гайде на два аспекта:
- Trusted Data Framework [2] создание в корпоративной системе данных "доверенной зоны" которая настроена на многочисленные проверки. Она должна покрывать те области в которых принимаются наиболее критически важные решения.
- Data Pumps [3] другое название для Reverse ETL, инструменты возврата в маркетинговые и транзакционные системы результатов анализа для улучшения работы этих систем.
- Data Spigot [4] краны данных. Это когда каждое приложение получает данные по индивидуальным реквизитам доступа (своему ключу) и только в минимальном объёме необходимом ему для работы. В Gitlab'е всё построено вокруг хранилища в Snowflake, но сама идея универсальна.

Заодно можно понять почему так взлетает использование dbt, почему Gitlab начали создавать Meltano и то насколько в сложных продуктах всё собирается и интегрируется из отдельных кирпичиков, а задача дата инженеров в переплетении их между собой.

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

Ссылки:
[1] https://about.gitlab.com/handbook/business-technology/data-team/
[2] https://about.gitlab.com/handbook/business-technology/data-team/platform/#tdf
[3] https://about.gitlab.com/handbook/business-technology/data-team/platform/#data-pump
[4] https://about.gitlab.com/handbook/business-technology/data-team/platform/#data-spigot

#data #datainfrastructure #datadocumentation #dataengineering

Возвращаю на голову шляпу дата инженера и продолжаю про разные инструменты.

Одна из рабочих идей у меня сейчас - это инструмент автоматического документирования датасетов/баз данных с приоритетом на "дикие данные" когда файл с данными есть, а документации на него нет. Очень частая ситуация с порталами открытых данных.

Причём потребность в таком инструменте уже очень давно есть, а вот наглядно я видел только облачный сервис CastorDoc который в этом продвинулся и только некоторые дата каталоги. А я сам экспериментировал и создал утилиту metacrafter для идентификации семантических типов данных. Но потребность в автодокументировании шире. Это, как минимум:
1. Автоматизация описания полей набора данных, желательно на нескольких языках: английский, испанский, русский, армянский и тд.
2. Написание описания набора данных так чтобы по датасету или его части можно было бы рассказать о чём он.
3. Описание структуры датасета не просто перечислением полей, а указание типа, описания полей, числа уникальных записей и тд.
4. Автоидентификация и документирование справочников. Почти всегда эти справочники есть и почти всегда их необходимо идентифицировать и описывать.
5. Автоматическая генерация типовых запросов к данным по аналогии с автогенерацией кода для доступа к API, нужны автосгенерированные запросы для доступа к данным.

Это всё самое очевидное, чуть более неочевидное это генерация документации по шаблонам, на разных языках и многое другое.

Самое простое и быстрое решение которое я вижу - это связка DuckDB + LLM модель, простые эксперименты подтверждают что это возможно и несложно. Но если Вы знаете хорошие/эффективные/удобные инструменты документирования датасетов - поделитесь, интересно их посмотреть в работе. Особенно те что с открытым кодом.

#opendata #datadocumentation #opensource #datatools #ideas