Как командам по работе с данным документировать свою работу? Большая часть заметок и описаний являются внутренними, но у команды 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
Учитывая насколько дата инженеры, аналитики и сайентисты не любят документировать свою работу, то вдвойне полезно почитать.
А я бы обратил в этом гайде на два аспекта:
- 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
В рубрике полезных инструментов по работе с данными, инструменты по документированию баз данных.
- schemaspy [1] довольно древний популярный инструмент по генерации документации к базам данных. На входе настройки подключения, на выходе папка с HTML файлами. Сам движок написан на Java, поддерживает только SQL базы данных, но не все.
- dbdocs.io [2] онлайн сервис/продукт по генерации документации к базам данных․ Кусочек в открытом
коде, но сам сервис онлайн. Self hosted версии пока нет․ Эта же команда разработчики стандарта DBML [3] по описанию баз данных
- tbls [4] движок по генерации документации написанный на Go. В том числе поддерживает NoSQL и генерацию документации в разных форматах и с очень гибкими настройками.
- SchemaCrawler [5] открытый код на Java и поддержка любой СУБД через JDBC, очень много возможностей и опций.
А также есть много узкоспециализированных инструментов и коммерческих продуктов.
В средних и крупных компаниях сейчас такими инструментами пользуются редко поскольку мигрируют на каталоги данных и системы управления метаданными, поскольку важнее становится не только то где данные хранятся, а все объекты дата-инженерии, взаимосвязи, data lineage (нет нормального перевода этого термина) и так далее.
Тем не менее инструменты документирования данных имеют своё применение. Лично я предполагаю их будущее в направлении загрузки данных в каталоги данных.
Ссылки:
[1] https://github.com/schemaspy/schemaspy
[2] https://dbdocs.io
[3] https://www.dbml.org
[4] https://github.com/k1LoW/tbls
[5] https://github.com/schemacrawler/SchemaCrawler
#data #datatools #opensource #datadocumentation #datacatalogs
- schemaspy [1] довольно древний популярный инструмент по генерации документации к базам данных. На входе настройки подключения, на выходе папка с HTML файлами. Сам движок написан на Java, поддерживает только SQL базы данных, но не все.
- dbdocs.io [2] онлайн сервис/продукт по генерации документации к базам данных․ Кусочек в открытом
коде, но сам сервис онлайн. Self hosted версии пока нет․ Эта же команда разработчики стандарта DBML [3] по описанию баз данных
- tbls [4] движок по генерации документации написанный на Go. В том числе поддерживает NoSQL и генерацию документации в разных форматах и с очень гибкими настройками.
- SchemaCrawler [5] открытый код на Java и поддержка любой СУБД через JDBC, очень много возможностей и опций.
А также есть много узкоспециализированных инструментов и коммерческих продуктов.
В средних и крупных компаниях сейчас такими инструментами пользуются редко поскольку мигрируют на каталоги данных и системы управления метаданными, поскольку важнее становится не только то где данные хранятся, а все объекты дата-инженерии, взаимосвязи, data lineage (нет нормального перевода этого термина) и так далее.
Тем не менее инструменты документирования данных имеют своё применение. Лично я предполагаю их будущее в направлении загрузки данных в каталоги данных.
Ссылки:
[1] https://github.com/schemaspy/schemaspy
[2] https://dbdocs.io
[3] https://www.dbml.org
[4] https://github.com/k1LoW/tbls
[5] https://github.com/schemacrawler/SchemaCrawler
#data #datatools #opensource #datadocumentation #datacatalogs
GitHub
GitHub - schemaspy/schemaspy: Database documentation built easy
Database documentation built easy. Contribute to schemaspy/schemaspy development by creating an account on GitHub.
Есть задачи для которых LLM совсем не годятся, а есть те которые годятся очень даже. Например, есть довольно узкая, но очень частая задача автоматического документирования данных.
У меня есть набор запросов к LLM на которых я это тестирую автодокументирование наборов данных. На полях/колонках которые содержат слова позволяющие по смыслу понять что там LLM выдает очень вменяемые ответы.
Это сколько же инструментов надо теперь переделать чтобы повысить их эффективность😂
В рамках экспериментов с Dateno у меня где-то несколько сотен тысяч схем CSV файлов которые можно превратить во что-то что было бы чем-то большим чем просто схема. В документацию.
#opendata #thoughts #datadiscovery #dataengineering #dataquality #datadocumentation
У меня есть набор запросов к LLM на которых я это тестирую автодокументирование наборов данных. На полях/колонках которые содержат слова позволяющие по смыслу понять что там LLM выдает очень вменяемые ответы.
Это сколько же инструментов надо теперь переделать чтобы повысить их эффективность😂
В рамках экспериментов с Dateno у меня где-то несколько сотен тысяч схем CSV файлов которые можно превратить во что-то что было бы чем-то большим чем просто схема. В документацию.
#opendata #thoughts #datadiscovery #dataengineering #dataquality #datadocumentation