Свежая картинка по продуктам с открытым кодом в области дата инженерии.
Подробнее о ней в блоге её автора на Substack [1].
А я скажу что такие картинки хороши когда надо синхронизировать картинку в голове с изменениями за год, правда, мне лично, вот такой иконостас иконок всегда казался не наглядным и куда практичнее были обзоры по наиболее интересным развивающимся и новым продуктам.
Вот в этой картинке, например, нет SODA для data quality, в платформе метаданных зачем-то CKAN, хотя он про другое.
Я, кстати, несколько по другому систематизирую инструменты с открытым кодом. Когда-то просто стал делать закладки в Github по категориям [2] и там много их, больше 30 списков.
А заодно для тех кто интересуется разного рода экзотическим открытым кодом. Markdowndb [3] наглядная реализация принципов "всё таблица" и "всё SQL". Это фреймворк превращающий документы с разметкой Markdown в SQL базу данных к которой можно делать запросы к содержимому этих файлов с фильтрацией по тэгам, файлам и тд. Внутри используют Sqlite, в гайдах рассказывают как заменить статические файлы на эту базу в статических сайтах.
Ссылки:
[1] https://practicaldataengineering.substack.com/p/open-source-data-engineering-landscape
[2] https://github.com/ivbeg?tab=stars
[3] https://markdowndb.com
#opensource #data #dataengineering #datatools
Подробнее о ней в блоге её автора на Substack [1].
А я скажу что такие картинки хороши когда надо синхронизировать картинку в голове с изменениями за год, правда, мне лично, вот такой иконостас иконок всегда казался не наглядным и куда практичнее были обзоры по наиболее интересным развивающимся и новым продуктам.
Вот в этой картинке, например, нет SODA для data quality, в платформе метаданных зачем-то CKAN, хотя он про другое.
Я, кстати, несколько по другому систематизирую инструменты с открытым кодом. Когда-то просто стал делать закладки в Github по категориям [2] и там много их, больше 30 списков.
А заодно для тех кто интересуется разного рода экзотическим открытым кодом. Markdowndb [3] наглядная реализация принципов "всё таблица" и "всё SQL". Это фреймворк превращающий документы с разметкой Markdown в SQL базу данных к которой можно делать запросы к содержимому этих файлов с фильтрацией по тэгам, файлам и тд. Внутри используют Sqlite, в гайдах рассказывают как заменить статические файлы на эту базу в статических сайтах.
Ссылки:
[1] https://practicaldataengineering.substack.com/p/open-source-data-engineering-landscape
[2] https://github.com/ivbeg?tab=stars
[3] https://markdowndb.com
#opensource #data #dataengineering #datatools
Я давно не писал про некоторые базовые принципы работы с данными, хотя регулярно о них задумываюсь в практическом контексте применения концепций и принципов инженерии данных к открытым и общедоступным данным. Например, про data lineage, которое на русский язык коллеги переводят как генеалогию данных. Я буду использовать термин data lineage, как более употребимое.
Так вот интересное тут то что в корпоративном мире с густой аналитикой (когда аналитические команды есть и они сильные, и запрос на аналитику есть), так вот в корпоративном мире data lineage - это понятное явление, если не привычное, то активно обсуждаемое и применяемое. Потому что decision maker'ы часто задают вопросы о том как та или иная цифра вышла и надо иметь ответ о том, а как же это оно есть. А вот в мире общедоступных данных, статистики и, отчасти, науки, с data lineage всё, скажем там, плоховато или очень специфично.
В случае научных данных общего типа, происхождение данных, обычно, описано текстом, неструктурировано и, частично, выявляется из ссылок на данные которые использовались. Иногда по этим ссылкам можно определить быстро первоисточник и способы обработки, иногда сложнее. Для хорошо структурированных научных областей вроде биоинформатики это должно быть проще, для других наук сложнее и тд.
В других случаях это сложнее, иногда реально сложно. Ещё сложнее со статистикой, при том что там источники данных указываются практически всегда, но это указание может быть не на первоисточник, а на глобальный источник. Простой пример, какой-нибудь агрегатор данных статистики вроде портала данных ООН (data.un.org) может собирать данные из портала данных Международного валютного фонда (IMF) data.imf.org, а тот из первоисточника, страницы раскрытия данных на сайте резервного банка или статслужбы страны. А кто-то коммерческий может, опять же, собирать данные с портала ООН и выдавать в своём сервисе.
Будем ли он при этом рисовать полноценный data lineage от портала данных ООН до сайта статслужбы ? Вообще-то нет, источником будет указан портал ООН.
С открытыми данными данными ещё хуже, там даже приближения к генеалогии данных нет, даже если в первоисточнике базы из которой создан датасет он есть.
Потому что есть огромное немаловажное явление - это технологический разрыв между порталами раскрытия и системами управления данными.
Он особенно остро ощущается теми кто работает в обоих мирах, с корпоративными данными, и с общедоступными данными.
Лично я его ощущаю довольно сильно и проекты и инициативы которые создаются дата инженерами и, условно, идеологами и активистами отличаются очень сильно.
Первые продвинуты технологически и сразу ориентированы на разработчиков (API, структурированное хранилище, преобразование данных в удобные форматы JSON, Parquet и др.), но, часто, забывая про базовые принципы открытости.
Вторые, наоборот, ориентированы на государственную или корпоративную прозрачность, но технологическая реализация всегда оставляет ощущение архаики.
Как выглядят идеальные порталы/сайты индикаторов или порталы публикации геоданных? Лично я считаю что главное в них это максимальная ориентация на использование дата-инженерами и дата-аналитиками владеющими современными инструментами. Даже, если не суперсовременными, но хотя бы актуальными.
Это реализация data lineage, это проектирование по принципу API First, это современные форматы предоставления данных для data science, это _всегда_ наличие bulk download, это концепция в основе что data as a product, а не данные как производный продукт от чего то ещё.
#opendata #data #dataengineering #thoughts
Так вот интересное тут то что в корпоративном мире с густой аналитикой (когда аналитические команды есть и они сильные, и запрос на аналитику есть), так вот в корпоративном мире data lineage - это понятное явление, если не привычное, то активно обсуждаемое и применяемое. Потому что decision maker'ы часто задают вопросы о том как та или иная цифра вышла и надо иметь ответ о том, а как же это оно есть. А вот в мире общедоступных данных, статистики и, отчасти, науки, с data lineage всё, скажем там, плоховато или очень специфично.
В случае научных данных общего типа, происхождение данных, обычно, описано текстом, неструктурировано и, частично, выявляется из ссылок на данные которые использовались. Иногда по этим ссылкам можно определить быстро первоисточник и способы обработки, иногда сложнее. Для хорошо структурированных научных областей вроде биоинформатики это должно быть проще, для других наук сложнее и тд.
В других случаях это сложнее, иногда реально сложно. Ещё сложнее со статистикой, при том что там источники данных указываются практически всегда, но это указание может быть не на первоисточник, а на глобальный источник. Простой пример, какой-нибудь агрегатор данных статистики вроде портала данных ООН (data.un.org) может собирать данные из портала данных Международного валютного фонда (IMF) data.imf.org, а тот из первоисточника, страницы раскрытия данных на сайте резервного банка или статслужбы страны. А кто-то коммерческий может, опять же, собирать данные с портала ООН и выдавать в своём сервисе.
Будем ли он при этом рисовать полноценный data lineage от портала данных ООН до сайта статслужбы ? Вообще-то нет, источником будет указан портал ООН.
С открытыми данными данными ещё хуже, там даже приближения к генеалогии данных нет, даже если в первоисточнике базы из которой создан датасет он есть.
Потому что есть огромное немаловажное явление - это технологический разрыв между порталами раскрытия и системами управления данными.
Он особенно остро ощущается теми кто работает в обоих мирах, с корпоративными данными, и с общедоступными данными.
Лично я его ощущаю довольно сильно и проекты и инициативы которые создаются дата инженерами и, условно, идеологами и активистами отличаются очень сильно.
Первые продвинуты технологически и сразу ориентированы на разработчиков (API, структурированное хранилище, преобразование данных в удобные форматы JSON, Parquet и др.), но, часто, забывая про базовые принципы открытости.
Вторые, наоборот, ориентированы на государственную или корпоративную прозрачность, но технологическая реализация всегда оставляет ощущение архаики.
Как выглядят идеальные порталы/сайты индикаторов или порталы публикации геоданных? Лично я считаю что главное в них это максимальная ориентация на использование дата-инженерами и дата-аналитиками владеющими современными инструментами. Даже, если не суперсовременными, но хотя бы актуальными.
Это реализация data lineage, это проектирование по принципу API First, это современные форматы предоставления данных для data science, это _всегда_ наличие bulk download, это концепция в основе что data as a product, а не данные как производный продукт от чего то ещё.
#opendata #data #dataengineering #thoughts
Свежие и полезные инструменты с открытым кодом для загрузки и обработки данных:
- PyAirbyte [1] библиотека для Python от команды Airbyte для того чтобы перенести логику этого движка по сбору данных в Python. Поддерживает все коннекторы Airbyte ранее написанные на Python
- dlt [2] Data Load Tool, явно созвучное dbt, библиотека для Python для реализации принципа Extract-Load-Transform. Выглядит довольно целостно, стоит изучить внимательнее
- ingestr [3] утилита командной строки по переносу баз данных из одного источника в другой. Поддерживает основные SQL СУБД
- sling [4] инструмент для выгрузки/загрузки данных с большинства основных СУБД включая облачные, файловых систем и различных дата файлов. Реализован на Go, важное ограничение GPL 2 лицензия (для сравнения у dlt лицензия Apache 2, а у ingestr MIT).
И конечно остаются такие инструменты как Meltano, Dagster, CloudQuery и многие другие
Ссылки:
[1] https://airbyte.com/blog/announcing-pyairbyte
[2] https://dlthub.com
[3] https://github.com/bruin-data/ingestr
[4] https://github.com/slingdata-io/sling-cli
#opensource #dataengineering
- PyAirbyte [1] библиотека для Python от команды Airbyte для того чтобы перенести логику этого движка по сбору данных в Python. Поддерживает все коннекторы Airbyte ранее написанные на Python
- dlt [2] Data Load Tool, явно созвучное dbt, библиотека для Python для реализации принципа Extract-Load-Transform. Выглядит довольно целостно, стоит изучить внимательнее
- ingestr [3] утилита командной строки по переносу баз данных из одного источника в другой. Поддерживает основные SQL СУБД
- sling [4] инструмент для выгрузки/загрузки данных с большинства основных СУБД включая облачные, файловых систем и различных дата файлов. Реализован на Go, важное ограничение GPL 2 лицензия (для сравнения у dlt лицензия Apache 2, а у ingestr MIT).
И конечно остаются такие инструменты как Meltano, Dagster, CloudQuery и многие другие
Ссылки:
[1] https://airbyte.com/blog/announcing-pyairbyte
[2] https://dlthub.com
[3] https://github.com/bruin-data/ingestr
[4] https://github.com/slingdata-io/sling-cli
#opensource #dataengineering
Airbyte
Announcing PyAirbyte: Bringing the power of Airbyte to every Python developer | Airbyte
Фразы которыми можно пугать дата инженеров на собеседованиях и не только:
- данные у нас в CSV и Excel на FTP сервере
- наши Excel файлы обновляются в реальном времени на сетевом диске
- требуется работать с большим числом серверов и таблиц из SAP/1С/Oracle Application (нужное тяжелое легаси подставить)
- данные в личных папках пользователей в Sharepoint, надо их синхронизировать
- мы хотим сделать наше озеро данных на Hadoop'е
- большая часть данных у нас в PDF, мы не знаем тексты там или сканы
- требуется 10-летний опыт с dbt cloud
А чем Вы пугаете, чем пугают Вас ?
#humor #dataengineering
- данные у нас в CSV и Excel на FTP сервере
- наши Excel файлы обновляются в реальном времени на сетевом диске
- требуется работать с большим числом серверов и таблиц из SAP/1С/Oracle Application (нужное тяжелое легаси подставить)
- данные в личных папках пользователей в Sharepoint, надо их синхронизировать
- мы хотим сделать наше озеро данных на Hadoop'е
- большая часть данных у нас в PDF, мы не знаем тексты там или сканы
- требуется 10-летний опыт с dbt cloud
А чем Вы пугаете, чем пугают Вас ?
#humor #dataengineering
Свежий доклад State of Data Engineering 2024 от команды LakeFS.
Подмечают три ключевых тренда:
1. Генеративный ИИ влияет на инструментарий в Modern Data Stack
2. Конкуренция дата продуктов растёт и, соответственно, моё дополнение, цена выхода на рынок с новым продуктом.
3. Открытые форматы создают закрытые заборы. В центре конфликт между Databricks и Snowflake.
Последнее утверждение спорное, скорее речь о том что есть такой конфликт на рынке, а уж каким образом и что используется при нем - не это в его основе.
Что характерно в таких обзорах State of ... так то что от 75 до 95 процентов инструментов, по разным категориям, это облачные продукты. К российским реалиям, к примеру, они не применимы. Как и ко многим особо закрытым не-российским стекам данных.
И, кстати, чтобы не забыть, составители таких State of продолжают путать открытые данные и каталоги открытых данных и корпоративные каталоги. А это очень разные продукты под очень разные задачи.
А если бы я выпускал свой State of data ... то делал бы два отдельных. Один для облака, а другой для корп оффлайна. А может быть даже и три. Ещё один для корп оффлайна открытого кода.
#datatools #opensource #stateof #dataengineering #moderndatastack #readings
Подмечают три ключевых тренда:
1. Генеративный ИИ влияет на инструментарий в Modern Data Stack
2. Конкуренция дата продуктов растёт и, соответственно, моё дополнение, цена выхода на рынок с новым продуктом.
3. Открытые форматы создают закрытые заборы. В центре конфликт между Databricks и Snowflake.
Последнее утверждение спорное, скорее речь о том что есть такой конфликт на рынке, а уж каким образом и что используется при нем - не это в его основе.
Что характерно в таких обзорах State of ... так то что от 75 до 95 процентов инструментов, по разным категориям, это облачные продукты. К российским реалиям, к примеру, они не применимы. Как и ко многим особо закрытым не-российским стекам данных.
И, кстати, чтобы не забыть, составители таких State of продолжают путать открытые данные и каталоги открытых данных и корпоративные каталоги. А это очень разные продукты под очень разные задачи.
А если бы я выпускал свой State of data ... то делал бы два отдельных. Один для облака, а другой для корп оффлайна. А может быть даже и три. Ещё один для корп оффлайна открытого кода.
#datatools #opensource #stateof #dataengineering #moderndatastack #readings