В блоге Pinterest история про то как они выбирали и в итоге настроили оркестратор задач на базе Airflow [1]. Пост интересный, про сложную архитектуру, реально большие данные, сложные процессы и тд.
А также там же много интересных цифр про Pinterest:
- 500 петабайт данных всего
- 600 терабайт данных ежесуточно
- 4000 workflows
- 10 000 data flows
- 38 000 ежесуточных задач в среднем
Достоинство больших проектов и крупных команд как раз в таких масштабах и решениях возникающих от сложностей подобного объема данных.
А в случае Pinterest'а ещё и интересна их архитектура связки потоков данных, развертывания кода и кластеров Kubernetes.
Ссылки:
[1] https://medium.com/pinterest-engineering/spinner-pinterests-workflow-platform-c5bbe190ba5
#opensource #bigdata #datarchitecture #datapipelines
А также там же много интересных цифр про Pinterest:
- 500 петабайт данных всего
- 600 терабайт данных ежесуточно
- 4000 workflows
- 10 000 data flows
- 38 000 ежесуточных задач в среднем
Достоинство больших проектов и крупных команд как раз в таких масштабах и решениях возникающих от сложностей подобного объема данных.
А в случае Pinterest'а ещё и интересна их архитектура связки потоков данных, развертывания кода и кластеров Kubernetes.
Ссылки:
[1] https://medium.com/pinterest-engineering/spinner-pinterests-workflow-platform-c5bbe190ba5
#opensource #bigdata #datarchitecture #datapipelines
Medium
Spinner: Pinterest’s Workflow Platform
Ace Haidrey | Software Engineer, Workflow; Ashim Shrestha | Site Reliability Engineer, Workflow; Dinghang Yu | Software Engineer, Workflow…
Я довольно давно не писал про коммерческие продукты которые мы делаем. Какие-то из них на слуху, какие-то не очень, но рассказать есть о чём. В этот раз немного про архитектуру работы с данными и технические особенности продуктов на данных.
—
Вот сейчас мы закончили переезд нашего каталога данных Datacrafter (data.apicrafter.ru) на новый сервер. Он снова доступен и должен работать значительно быстрее. А также продолжаем миграцию основных наших продуктов API к базам данных APICrafter (apicrafter.ru), по итогам они тоже будут быстрее чем ранее.
Это продукты про предоставление доступа к API с данными, а в последние несколько месяцев прошлого года я лично был погружен в перестройку его из продукта по продаже доступа к данным, в технологический продукт помогающий публиковать свои данные. Так сложилось что изначально DataCrafter создавался как моно-продукт с унаследованным кодом включавшем сбор, регистрацию и визуализацию данных с сильной заточкой под обработку больших бэтчей, опубликованных датасетов открытых данных. Внутри него много функций и упрощённых операций которые позволяют, например, огромный XML файлы быстро превратить в базу MongoDB, создать схему данных, автодокументировать всё что только возможно и опубликовать базу данных как API.
В итоге получилась хорошая, но не гибкая штука, с унаследованным кодом от которого ряд ограничений:
- описание источников данных идёт в коде на Python вместо конфигурационных файлов YAML как это делается в Meltano, dbt, soda, ploomber и других инструментах
- работа с метаданными "размазана" по компонентам, вместо концентрации только в реестре.
- обработка больших файлов сейчас не осуществляется параллельно, хотя это точно нужно для обработки слепков данных от нескольких гигабайт.
- компоненты не до конца разделены в отдельные продукты, пока полноценно отделен только apicrafter/metacrafter с помощью которого идёт классификация полей данных. А должно быть четкое деление на сборщик, регистратор данных, регистратор схем, фронт каталога, фронт управления (админка) и тд. но это же усложняет работу с данными, довольно сильно.
- архитектура не предусматривает модели плагинов для расширения отдельных блоков, например, сейчас в качестве адресата данных используется MongoDB, хотя некоторые данные могли бы загружаться и в другие NoSQL базы и в SQL базы поддерживающие JSON объекты
- для некоторых задач анализа структуры данных можно и нужно использовать нейросети, но пока это задача в не первая в списке
В итоге технически - это система работы с NoSQL данными, в современном стеке данных таких сейчас нет, все "танцуют" вокруг SQL во всех вариациях.
И почти всё это может быть переведено в открытый код + облачный сервис. А DataCrafter сейчас это эксперимент работающий на прототипе этой платформы.
Под такую платформу я и искал и ищу инвестиции на то чтобы её завершить и довести до продуктового состояния, а пока продолжаем наполнять наш каталог большими объёмами интересных данных;)
#opendata #datatools #datacatalogs #datarchitecture
—
Вот сейчас мы закончили переезд нашего каталога данных Datacrafter (data.apicrafter.ru) на новый сервер. Он снова доступен и должен работать значительно быстрее. А также продолжаем миграцию основных наших продуктов API к базам данных APICrafter (apicrafter.ru), по итогам они тоже будут быстрее чем ранее.
Это продукты про предоставление доступа к API с данными, а в последние несколько месяцев прошлого года я лично был погружен в перестройку его из продукта по продаже доступа к данным, в технологический продукт помогающий публиковать свои данные. Так сложилось что изначально DataCrafter создавался как моно-продукт с унаследованным кодом включавшем сбор, регистрацию и визуализацию данных с сильной заточкой под обработку больших бэтчей, опубликованных датасетов открытых данных. Внутри него много функций и упрощённых операций которые позволяют, например, огромный XML файлы быстро превратить в базу MongoDB, создать схему данных, автодокументировать всё что только возможно и опубликовать базу данных как API.
В итоге получилась хорошая, но не гибкая штука, с унаследованным кодом от которого ряд ограничений:
- описание источников данных идёт в коде на Python вместо конфигурационных файлов YAML как это делается в Meltano, dbt, soda, ploomber и других инструментах
- работа с метаданными "размазана" по компонентам, вместо концентрации только в реестре.
- обработка больших файлов сейчас не осуществляется параллельно, хотя это точно нужно для обработки слепков данных от нескольких гигабайт.
- компоненты не до конца разделены в отдельные продукты, пока полноценно отделен только apicrafter/metacrafter с помощью которого идёт классификация полей данных. А должно быть четкое деление на сборщик, регистратор данных, регистратор схем, фронт каталога, фронт управления (админка) и тд. но это же усложняет работу с данными, довольно сильно.
- архитектура не предусматривает модели плагинов для расширения отдельных блоков, например, сейчас в качестве адресата данных используется MongoDB, хотя некоторые данные могли бы загружаться и в другие NoSQL базы и в SQL базы поддерживающие JSON объекты
- для некоторых задач анализа структуры данных можно и нужно использовать нейросети, но пока это задача в не первая в списке
В итоге технически - это система работы с NoSQL данными, в современном стеке данных таких сейчас нет, все "танцуют" вокруг SQL во всех вариациях.
И почти всё это может быть переведено в открытый код + облачный сервис. А DataCrafter сейчас это эксперимент работающий на прототипе этой платформы.
Под такую платформу я и искал и ищу инвестиции на то чтобы её завершить и довести до продуктового состояния, а пока продолжаем наполнять наш каталог большими объёмами интересных данных;)
#opendata #datatools #datacatalogs #datarchitecture
apicrafter.ru
API Crafter
Я давно не писал про то дата-инженерные задачи которые приходится решать. Вот, к примеру, нетипичная-типичная задача - это построение поискового индекса по открытым данным - это то для чего начинался Common Data Index. Чтобы построить поисковый индекс надо
а) Собрать оригинальные опубликованные каталоги метаданных, чаще всего это REST API возвращающее JSON или JSON каталоги по стандарту DCAT
б) Проанализировать и подготовить схемы/структуру собранных данных
в) Преобразовать собранные первичные данные в общий поисковый индекс, соответственно преобразовав первичные данные в унифицированную структуру.
Типовых API и вариантов экспорта данных которые есть уже сейчас 9 штук, то что может быть сведено к типовому API ещё примерно 10 разных типов API и вариантов экспорта данных, а также есть огромное число произвольных API или даже сайтов без API, из которых самые значимые это большие онлайн каталоги открытых данных где публикуется их, условно, от 100 тысяч наборов данных.
Все собираемые данные через API из этих каталогов - это JSON или XML и природа данных такова что преобразовывать их в плоские таблицы - это потратить много сил на проектирование структур данных, с каждого API данные преобразуются от 1 до 10 таблиц и, также, одна из задач в сохранении всех первичных данных чтобы с ними можно было бы удобно работать в будущем.
Всё это пока что нельзя отнести к большим данным или данным реального времени, тут нет пока что большого технического челленжа, но есть челленж аналитический и решение задачи по интеграции и преобразовании данных. Большие данные тоже будут, но позже, когда уже начнётся сбор не только описаний наборов данных, но и самих файлов, а там уже данных очень много, петабайты если не больше, если обрабатывать всё.
А пока с построением поискового индекса возникает резонный вопрос как всё собирать и обрабатывать и это то почему я постоянно сетую что не хватает ETL/ELT инструментов с поддержкой NoSQL. Потому что поисковый индекс это тоже не плоские таблицы, это хранилище, тоже NoSQL, например, Elasticsearch.
Итого, на входе тысячи источников данных, с данными в JSON, не менее чем 9 разных схем, хранением первичных данных, преобразованием этих данных в унифицированный формат и итоговый поисковый индекс. И для всего этого хочется ещё и observability, управляемые конвейеры для обработки (pipelines), контроль качества и ELT/ETL для трансформации первичных данных в унифицированный формат, а инструментов для этого из коробки просто нет.
Но решать надо и я позже расскажу как эта задача сейчас решается, а пока мысли вслух о какими данными приходится работать.
#opendata #dataengineering #datarchitecture
а) Собрать оригинальные опубликованные каталоги метаданных, чаще всего это REST API возвращающее JSON или JSON каталоги по стандарту DCAT
б) Проанализировать и подготовить схемы/структуру собранных данных
в) Преобразовать собранные первичные данные в общий поисковый индекс, соответственно преобразовав первичные данные в унифицированную структуру.
Типовых API и вариантов экспорта данных которые есть уже сейчас 9 штук, то что может быть сведено к типовому API ещё примерно 10 разных типов API и вариантов экспорта данных, а также есть огромное число произвольных API или даже сайтов без API, из которых самые значимые это большие онлайн каталоги открытых данных где публикуется их, условно, от 100 тысяч наборов данных.
Все собираемые данные через API из этих каталогов - это JSON или XML и природа данных такова что преобразовывать их в плоские таблицы - это потратить много сил на проектирование структур данных, с каждого API данные преобразуются от 1 до 10 таблиц и, также, одна из задач в сохранении всех первичных данных чтобы с ними можно было бы удобно работать в будущем.
Всё это пока что нельзя отнести к большим данным или данным реального времени, тут нет пока что большого технического челленжа, но есть челленж аналитический и решение задачи по интеграции и преобразовании данных. Большие данные тоже будут, но позже, когда уже начнётся сбор не только описаний наборов данных, но и самих файлов, а там уже данных очень много, петабайты если не больше, если обрабатывать всё.
А пока с построением поискового индекса возникает резонный вопрос как всё собирать и обрабатывать и это то почему я постоянно сетую что не хватает ETL/ELT инструментов с поддержкой NoSQL. Потому что поисковый индекс это тоже не плоские таблицы, это хранилище, тоже NoSQL, например, Elasticsearch.
Итого, на входе тысячи источников данных, с данными в JSON, не менее чем 9 разных схем, хранением первичных данных, преобразованием этих данных в унифицированный формат и итоговый поисковый индекс. И для всего этого хочется ещё и observability, управляемые конвейеры для обработки (pipelines), контроль качества и ELT/ETL для трансформации первичных данных в унифицированный формат, а инструментов для этого из коробки просто нет.
Но решать надо и я позже расскажу как эта задача сейчас решается, а пока мысли вслух о какими данными приходится работать.
#opendata #dataengineering #datarchitecture