Как командам по работе с данным документировать свою работу? Большая часть заметок и описаний являются внутренними, но у команды 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
The GitLab Handbook
Data Team
The GitLab Enterprise Data Team is responsible for empowering every GitLab team member to contribute to the data program and generate business value from our data assets.
В рубрике полезных инструментов по работе с данными, инструменты по документированию баз данных.
- 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.