В блоге 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

Я довольно давно не писал про коммерческие продукты которые мы делаем. Какие-то из них на слуху, какие-то не очень, но рассказать есть о чём. В этот раз немного про архитектуру работы с данными и технические особенности продуктов на данных.
—
Вот сейчас мы закончили переезд нашего каталога данных 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