Классическая модель работы с данными предполагает использование ETL инструментов где ETL - это Extract, Transform, Load [1], комплексный процесс описанный ещё в 70-е годы 20-го столетия исходящий из данные последовательно извлекаются, преобразуются и далее уже только загружаются в очищенном/преобразованном виде в базу данных, как правило, являющуюся часть хранилища данных (Data Warehouse) и используемую для аналитических расчётов, систем BI и так далее.

ETL инструментов существует бессчетное количество, как в поставке вместе с движками баз данных крупнейшими вендорами, так и как самостоятельные продукты. Главным достоинством ETL всегда было то же что является его же главным недостатком - необходимость тщательного проектирования, понимания итогового результата что требовало, зачастую, довольно кропотливой подготовительной работы. Другой недостаток в том что в случае ETL из-за стадии преобразования время загрузки данных всегда было значительным. Это затрудняло работу с потоками данных.

Важное изменение в последние годы - это появление нового подхода, ELT. ELT - это Extract, Load and Transform [2], модель построенная на потоковой обработке данных и замену стадий L и T. При ELT данные вначале извлекаются, но ещё до их обработки они загружаются в финальное хранилище и уже инструментами предоставляемыми этим хранилищем они обрабатываются и превращаются очищенные/обработанные данные. Преобразование может производится самыми разными способами, от процедур в SQL, до внешних инструментов по преобразованию данных (data wrangling) и специализированных платформ.

Такой подход резко сокращает время загрузки данных и даёт возможность создавать на базе собранных первичных данных разные итоговые продукты, это могут быть:
- базы для аналитической работы и BI
- базы эталонных (золотых) записей
- срезы данных для использования в data science
и иные продукты.

При этом, для ELT хранилище данных - это не обязательно data warehouse с тщательно прописанными метаданными и тд. Зачастую это озёра данных с куда как менее тщательными требованиями по интеграции данных между собой.

Это не значит что у ELT нет недостатков.
Как минимум можно говорить о том ELT:
1. Требует хранения большего объёма первичных данных.
2. Требует значительных процессорных мощностей в хранилище необходимых для обработки данных.
3. Требует значительного более внимательного отношения к персональным и чувствительным данным, потому что в ETL процессе они, как правило, вычищаются на стадии трансформации и не попадают в целевую систему. А в ELT данные уже в системе и на неё накладываются ограничения связанные с обработкой данных и их хранением в определённой юрисдикции.


Подход ELT активно пропагандируется и продвигается облачными сервисами, что и понятно, они обеспечивают практически неограниченные аппаратные возможности, для хранения и обработки данных, зависящие только от бюджета тех кто обрабатывает на них свои данные.

ELT неразрывно связано с концепцией data pipelines и его отличия подробно разобраны во многих источниках компаний создающие свои продукты по этой концепции:
- блог XPlenty [3]
- блог Panoply [4]
- блог Talend [5]
- блог OpenBridge [6]
- блог DataForm [7]

Спросить чем отличаются ELT от ETL или попросить привести в пример несколько продуктов обоего типа - это хорошие вопросы на собеседовании инженера по работе с данными (дата инженера). ELT применимо не для всех задач, но уже настолько распространено, что нельзя не знать о том что это такое и как устроено.

Ссылки:
[1] https://ru.wikipedia.org/wiki/ETL
[2] https://en.wikipedia.org/wiki/Extract,_load,_transform
[3] https://www.xplenty.com/blog/etl-vs-elt/
[4] https://blog.panoply.io/etl-vs-elt-the-difference-is-in-the-how
[5] https://www.talend.com/resources/elt-vs-etl/
[6] https://blog.openbridge.com/etl-tools-elt-vs-etl-process-89bb1f71c7b3
[7] https://dataform.co/blog/etl-vs-elt

#etl #elt #data #datalakes #datawarehouse

Я не так давно писал про ETL выделенную из Datacrafter'а для данных в NoSQL форматах JSONlines и BSON [1]. Это кусок кода отделенный в рамках "техдолга", то что надо было сделать давно и только недавно до этого дошли руки.

Но есть задача для которой точно нет подходящего простого ETL/ELT/data pipeline engine - это как раз цифровая архивация для создания тематических коллекций архивируемых сайтов, аккаунтов в соцсетях и тд.

Задачи по цифровой / веб архивации можно разделить на несколько видов, но в части сбора данных, основных всего два.

Массовый сбор и сфокусированные коллекции.

Массовый сбор - это когда роботы вроде краулеров Archive.org обходят условно неограниченное число цифровых ресурсов и делают слепки и актуализируют ранее собранные материалы.

Сфокусированные коллекции - это когда собирается не всё а по перечню: сайтов, разделов на сайтах, отдельных файлов, каналов в телеграм, аккаунтов в соцсетях и тд.

Для массового сбора есть своя экосистема инструментов, а вот для сфокуированных коллекций категорически нехватает ETL инструментария. Причём скорее ETL чем ELT потому что много двоичных данных которые можно поместить в озеро данных и сложно хранить в хранилище данных.

Логика та что что у классических ELT продуктов.
Извлечение данных с помощью разных инструментов и стратегий, преобразование для долгосрочного сохранения и загрузка в Internet Archive, какое-то постоянное хранилище и ещё куда-то, по необходимости.

Эта логика дополняется ещё одной стадией D - Discovery. Это когда движок получает на вход набор ссылок и на их основе автоматически определяет стратегию в зависимости от типа ресурса. В итоге получается DELT (Discover Extract Transform Load).

Недостаток такого движка в узкой применимости и в больше значимости этапа Extract, поскольку извлечение и сбор данных наиболее длительны и ресурсоёмки.

В принципе развитие дата инженерии давно уже достигло той стадии когда нужны специализированные решения. В основном они сейчас строятся на готовых продуктах, но иногда функций готовых продуктов недостаточно.

#digitalpreservation #etl #dataengineering

Написал заметку про DELT (Discover, Extract, Load, Transform) на английском языке [1] на Medium.

Ссылки:
[1] https://medium.com/@ibegtin/delt-discover-extract-load-transform-are-we-ready-for-etl-for-digital-preservation-ced3a08727a

#datadiscovery #digitalpreservation #etl #data

Вышла версия 2.0 Meltano [1] ELT движка интегрированного в Modern Data Stack, все изменения как раз про эту интеграцию. В частности там поддерживается:
- dbt для трансформации данных
- Great Expectations для качества данных
- Airflow для управления потоками данных
- Superset для аналитики

И ещё много чего. На поляне ELT у Meltano сейчас возможно наилучший потенциал, растущее сообщество и хорошее развитие продукта. Если думать с каким ELT движком интегрировать свои продукты то Meltano - это хороший вариант.

Ссылки:
[1] https://meltano.com/blog/meet-meltano-2-0/

#opensource #datatools #etl #elt #moderndatastack

Для тех кто регулярно пользуется ETL/ELT инструментами, обновился Apache Hop, визуальный ETL движок с большим числом встроенных трансформаций над данными [1]. В новой версии 2.0 осуществили переход на Java 11 и кучу новых плагинов [2].

Лично я не отношу себя к фанатам Hop да и других ETL продуктов из экосистемы Apache, всё таки продукты вроде Meltano, Dagster, Prefect и др. написанные на Python, Go и тд. представляются мне куда более практичными, но для ряда задач инструменты вроде Hop могут быть полезны. Например, когда изначально инфраструктура построена на других продуктах из экосистемы Apache и основной язык разработки Java.

Ссылки:
[1] https://hop.apache.org/
[2] https://hop.apache.org/blog/2022/06/hop-2.0.0/

#datatools #etl #opensource

В рубрике интересных продуктов для работы с данными SteamPipe. Это фреймворк для доступа к более чем 200+ источникам данных через SQL запросы [1].

Идея проста - любые данные должны иметь SQL интерфейс для этого у StreamPipe 78 плагинов [2] для доступа к большинству известных СУБД и к разного рода онлайн сервисам и протоколам.

Например, доступ к почтовому ящику IMAP через SQL [3] или доступ к сетевой информации сертификатов, доменов, IP адресов через SQL [4].

Сама идея подкупает своей универсальностью и реализация вполне рабочая. Скорее всего там есть существенные ограничения в работе с рядом иерархических данных, но, с другой стороны преимущества универсального доступа велики.

Проект написан на Go командой стартапа Turbot [5], доступен с открытым кодом и активно развивается [7].

Проект должен хорошо вписываться в любой ELT/ETL инструмент и стоит ожидать новых ETL продуктов на Go с его поддержкой.

Ссылки:
[1] https://steampipe.io/
[2] https://hub.steampipe.io/plugins
[3] https://hub.steampipe.io/plugins/turbot/imap
[4] https://hub.steampipe.io/plugins/turbot/net
[5] https://turbot.com/
[6] https://github.com/turbot/steampipe

#opensource #datatools #etl

Полезное чтение про данные, технологии и не только։
- NormConf: Selected talks and lessons learned [1] в блоге Prefect про конференцию Normconf и избранные выступления про машинное обучение. Там же ссылки на все выступления и, в принципе, интересная конференция с разными докладами про данные и ML
- List of AI and ML Conferences in 2023 [2] большая подборка конференций по ИИ и машинному обучению в 2023 году. Большая часть в США и Европе, несколько в Восточной Азии.
- Uber’s Facial Recognition Is Locking Indian Drivers Out of Their Accounts [3] о том как алгоритмы блокировали доступ водителей в Индии к их аккаунтам в Uber из-за невозможности их идентифицировать после изменения стрижки, к примеру. Обзор влияния применения распознавания по лицам для "gig workers" (курьеров, водителей и иных схожих уберизированных профессий).
- Updating dbt Cloud pricing to support long-term community growth [4] команда продукта dbt обновила его ценовую модель, как бы красиво они не подавали изменения в ценах, в реальности для небольших команд цена вырастает в 100%, если пользоваться их онлайн облаком и IDE. Это важно поскольку dbt превратился в один из ключевых инфраструктурных проектов в современных стеках работы с данными.
- A Zero ETL Future [5] о будущем ETL продуктов и о том что вероятна весьма скорая их замена владельцами крупнейших онлайн хранилищ. Об этом давно идут разговоры, что если Snowflake и AWS добавят ETL функции в их продукты, то весь рынок облачных ETL быстро развалится.
- Daath AI Parser [6] необычный парсер HTML который на вход получает HTML код и с помощью OpenAI разбирает видимые элементы и возвращает данные. Я уже думал о подобной штуке, а тут автор напрямую начал её реализовывать. Для многих задач у неё хороший потенциал.

Ссылки։
[1] https://medium.com/the-prefect-blog/what-i-learned-from-normconf-2022-f8b3c88f0de7
[2] https://tryolabs.com/blog/machine-learning-deep-learning-conferences
[3] https://pulitzercenter.org/stories/ubers-facial-recognition-locking-indian-drivers-out-their-accounts
[4] https://www.getdbt.com/blog/dbt-cloud-package-update/
[5] https://seattledataguy.substack.com/p/a-zero-etl-future
[6] https://github.com/kagermanov27/daath-ai-parser

#opensource #ai #machinelearning #dbt #dataengineering #etl

Open Data Fabric - открытый протокол/спецификации по обработке данных с использованием Web 3.0 и умных контрактов. Малоизвестно широкой публике и большинству дата-инженеров, разработано компанией Kamu в 2020 г. [1] как часть их платформы по работе с корпоративными данными в среде распределённых реестров. Любопытно детальностью проработки спецификации, наличием инструмента для работы и то что продукт и спецификация развиваются. За пределами экосистем вокруг блокчейна всё это выглядит экзотикой, особенно обработка данных на IPFS, всё это далеко от Modern Data Stack, но внимания всё же стоит, тут могут быть интересные идеи как минимум.

Поэтому из плюсов - хорошо проработанная спецификация. Из минусов - абсолютная ориентация на плоские простые таблицы и схемы и SQL для реконструкции наборов данных. Никакие иные данные кроме табличных не рассматриваются.

И туда же ещё ряд похожих проектов։
- Holium [2] - движок по обработке данных поверх IPFS
- Bacalhau [3] платформа для выполнения задач по обработке данных поверх IPFS по модели Compute Over Data [4]

Про Compute Over Data отдельный разговор, это явление из Protocol Labs почти полностью закольцованное на экосистему Web 3.0, блокчейна и тд. Лично я не видел до сих пор ни одного применения продуктов из этой среды коммерческими компаниями за пределами мира "крипты" что доверия им не добавляет.

Но, возвращаясь к спецификации и Open Data Fabric, сама по себе она может быть интересной.

Ссылки։
[1] https://docs.kamu.dev/odf/
[2] https://docs.holium.org/
[3] https://docs.bacalhau.org/
[4] https://www.cod.cloud/

#openprotocols #openspecifications #data #etl

Команда Meltano, ETL/ELT продукта вышедшего из инженерной команды Gitlab, преданонсировали запуск Meltano Cloud [1], облачной версии их продукта, пока без цен, что чуть ли не самое важное, так что ждём.

А также они полностью обновили интерфейс хаба коннекторов Meltano Hub [2] где можно подобрать коннектор для специфичных сервисов и подключить его в свой экземпляр Meltano.

Облачные продукты на базе open source довольно распространены, это чуть ли не основная бизнес модель сейчас для новых СУБД и инфраструктурных продуктов. В этом смысле Meltano один из продуктов за которыми я давно слежу, от активного использования их ETL лично меня сдерживают те же ограничения что у большинства ETL/ELT продуктов - это ориентация на модель SQL-only и преимущественно на работу с плоскими таблицами. Не для всех задач с которыми лично я сталкиваюсь это годится.

В остальном, Meltano один из продуктов и стартапов по работе с данными за которыми я лично наблюдаю. Как-нибудь сделаю список из всех о которых я писал и за которыми слежу. Они преимущественно с открытым кодом, таких дата продуктов немало.

Ссылки:
[1] https://meltano.com/cloud/
[2] https://hub.meltano.com/

#opensource #etl #startups #data #elt

В рубрике полезного чтения про данные, технологии и не только:
- Zero ELT could be the death of the Modern Data Stack [1] о том как вендоры крупнейших SaaS платформ могут в короткий срок убить всю экосистему Modern Data Stack реализовав достаточно простые инструмент для загрузки данных. Zero ETL - это, по сути, "убиение" ETL, например, в этот подход склоняются Amazon и Snowflake. Вообще процесс можно описать таким образом. Вначале появляется потребность в работе с данными в облачных сервисах, в первую очередь эта потребность у тех кто и так держит данные в облаках и многочисленными провайдерами разных сервисов, вроде платежных, и вынужден объединять данные. Потом появляются нишевые стартапы хорошо решающие конкретные задачи автоматизации работы с данными (всё как по учебнику), такие как Fivetran, Dbt, Hightouch и другие. Они оказываются основой Modern data stack, объединяющего понятия хорошо интегрированных сервисов работы с данными и, наконец, оказывается что клиентам управление сложностью возникшей конфигурации может быть более затратно, чем более простые инструменты, но интегрированные в платформу базового провайдера. Поэтому Zero ETL действительно имеет хорошие перспективы.

- We need to talk about Excel [2] автор и критикует и хвалит Excel и приводит в пример несколько стартапов которые не то чтобы его заменяют, но дают некоторые близкие возможности, при этом самому Excel как продукту до сих пор замены нет. Размышления вполне структурированы и аргументированы. Я лично когда думал про Excel понял что для меня всегда главной нелюбовью к нему был язык VBA. При том что когда-то, много лет назад, я на нём даже мог писать сложные макросы и отлаживать непростой код, тем не менее он до сих пор ощущается как крайне неудобный. Будь в MS Excel нативная поддержка, например, Python. Может быть когда-нибудь Microsoft поглотит PyXLL [3] и такая поддержка появится.

- Polars – Laziness and SQL Context. [4] автор пишет о том что Polars это не только более производительный инструмент для аналитики чем Pandas, но и обладает несколькими полезными функциями такими как ленивая загрузка файлов позволяющая обрабатывать файлы размером больше чем объём памяти и SQL контекст с помощью которого можно делать SQL запросы, например, к таким лениво загруженным файлам. Возможности полезные когда работаешь с данными относительно большого объёма.


Ссылки:
[1] https://medium.com/@hugolu87/zero-elt-could-be-the-death-of-the-modern-data-stack-cfdd56c9246d
[2] https://davidsj.substack.com/p/we-need-to-talk-about-excel
[3] https://www.pyxll.com
[4] https://www.confessionsofadataguy.com/polars-laziness-and-sql-context/

#data #datatools #readings #etl

Всякое интересное чтение про данные, технологии и не только:
- Meltano Cloud ETL/ELT продукт от одноимённого стартапа вышел в бета режиме. На мой взгляд Meltano один из наиболее интересных ELT продуктов последних лет и точно стоит к нему присмотреться, как минимум к открытой опенсорсной версии, но и от облака может быть практическая польза

- Castor теперь CastorDoc - Castor это такой стартап для каталогизации данных, они поменяли приоритет и стали CastorDoc, стартапом по документированию данных. Ценник у них резко взлетел, минимальная стоимость продукта в $1200 в год, всё остальное по договорённости. Ниша интересная и перспективная

- Paragraphica голландский артист/инженер/дизайнер Bjørn Karmann сделал фотоаппарат которые "делает снимки" так похожие на реальность. Данных там нет, но есть про ИИ и сама концепция. Современное искусство в чистой, незамутнённой форме

- Instacard pipelines про модуляризованные ковейеры данных внутри Instacart, с использованием Spark и Lakehouse архитектуру. Полезно как практический пример живой системы.

- 144TB Nvidia GPU - Nvidia пока однозначно лидирует в гонке ИИ, новый их продукт специально для Generative AI.

- В Японии копирайт не распространяется на обучение ИИ - отличная новость для ИИ, печальная для художников, писателей и тд. ИИ лоббисты (биг тех) всё сильнее, а традиционные копирайтовладельцы не могут им противостоять.

#ai #data #datatools #datacatalogs #etl

Свежий инструмент Amphi для визуальных ETL процессов, с low-code проектированием труб данных (data pipelines) через интерфейс в Jupyter lab

Из плюсов:
- low code
- не cloud-first
- базовый набор для обработки структурированных и неструктурированных данных
- всё можно делать в UI прямо в Jupyter Lab
- открытый код

Из минусов:
- low-code (для кого-то минус)
- не cloud-first (для кого-то минус)
- мало разнообразия в источниках получения данных
- лицензия Elastic, недоопенсорс

Мне чем-то напомнило Apache Nifi, но только отчасти.

Интеграция в Jupyter Lab - хорошо,но пока что и в целом надо приглядется. Продукт явно сделан пока скорее для инвесторов чем для пользователей, но без пользователей и инвестиций не будет.

В целом из разработки дата инструментов мне нравятся не только продукты, но и команды Clickhouse и Duckdb.

Хочется дождаться ETL сделанное по аналогии с Duckdb. Удобным ядром и большим числом хорошо написанных расширений. Какое-то время назад мне казалось что Meltano на эту роль подходит, но с тех пор как они отдали свои публичные ресурсы довольно хреновым маркетологам читать их стало тяжело. Развитие продукта сложно оценивать.

#etl #opensource #datatools

Ещё немного про всякое сугубо техническое, сейчас в Dateno постепенно идёт переход от индексирования тысяч маленьких порталов с общедоступными данными и метаданными, к охвату крупных каталогов. Ключевое отличие таких крупных каталогов данных в том что необходимо писать скрейперы под каждый индивидуально, а это хоть и несложно, но означает увеличение кода скрейпинга многократно что постепенно будет усложнять сопровождение кода и так далее. Но это не проблема, это вполне измеримая техническая задача.

Что сложнее так то что многие из таких крупных каталогов данных - это базы индикаторов. Часть из них написаны на типовом ПО, большая часть на нетиповом, но что характерно для большей части таких каталогов так то что сбор метаданных и данных (значений) индикаторов по трудоёмкости почти не различаются

Это сильно отличает такие порталы от порталов открытых или научных данных, где выкачать метаданные можно быстро и они имеют относительно разумные размеры, а вот данных могут быть там сотни гигабайт и терабайт, их сбор и обработка уже сложнее.

А в случае индикаторов, хорошие владельцы таких баз данных всё чаще дают возможность выкачать их целиком в режиме bulk download. Как минимум это ECB, Eurostat, FAO, Ilostat и ещё многие. Данные там почти всегда CSV или сжатые CSV и вот тут то срабатывает магия инструментов вроде duckdb. Во всех ситуациях когда CSVшки в кодировке utf8 и имеют предсказуемые схемы данных, с помощью duckdb можно многократно ускорять их обработку заменяя обработку через датафреймы на прямые SQL запросы к CSV, даже без копирования данных в БД и не строя ни одного индекса.

В общем могу сказать что в роли "дешёвого ETL инструмента для бедных" duckdb работает прекрасно. К примеру DISTINCT по разреженному полю по CSV файлу в 15GB и 22 миллиона записей без индекса отрабатывается на 19.8 секунд. Это в режиме когда совсем без оптимизаций, без преобразований в parquet. А если в parquet преобразовать то, ожидаемо, DISTINCT отрабатывает за 0.5 секунд. Выбор очевиден 🛠 надо использовать!

Например, про данные из другого проекта, если кто-то надумает использовать данные по госконтрактам [1], то они вполне себе читаются с помощью duckdb особенно после преобразований в parquet. Например, jsonl файл с госзаказчиками вполне себе легко преобразуется в parquet после всего операции по преобразованиям занимают сотые доли секунд. В этом смысле единственный недостаток открытых данных из Госзатрат только в том что они сжаты в zip, а если сжать их в gz или публиковать в parquet, то можно ещё и ускорить подготовку данных.

Таких примеров много, главный вывод в том что можно удешевить ресурсные требования во многих задачах и многие R&D задачи решать без дополнительных серверных ресурсов, экспериментируя локально.

Ссылки:
[1] https://clearspending.ru/opendata/

#duckdb #tech #dataengineering #etl

К вопросу о дата-инженерии и Dateno, одна из особенностей проекта в том что практически вся работа с данными построена на собственных инструментах с открытым кодом, что имеет кучу преимуществ при старте, и накапливающиеся ограничения в будущем которые уже хочется избежать.

И здесь не последнюю роль играет выбор итогового технического стека который, в свою очередь, ограничен спецификой проекта, данных, их источников и тд.

Вот некоторые важные особенности:
1. Почти все первичные данные в Dateno - это JSON, JSON lines, и сильно реже CSV, которые тоже преобразуются в JSON. Отсюда и хранение первичных данных в MongoDB как наиболее естественно подходящем хранилище. Хотя уже можно рассматривать альтернативы. В любом случае сейчас в проекте нет SQL, за исключением DuckDB для аналитики и экспериментов.

2. В отличии от корпоративной дата инженерии тут огромное число неуправляемых внешних источников метаданных. Их более 10 тысяч всего из которых 5 тысяч уже подключено и индексируются. Вместе с отсутствием SQL это делает малопригодными классические оркестраторы задач и ETL/ELT инструменты.

3. Другая особенность в итеративности задач и в работе с первичными данными. Логика сбора построена на постобработке первичных данных. Вначале они собираются AS IS из первоисточников и далее, отдельными процессами, преобразуются в эталонную схему и финальную базу данных (поисковый индекс). При этом все первичные данные хранятся и используются для аналитической работы когда надо построить новый фильтр, то вначале проверяется есть ли опора для него в первичных метаданных.

4. Конвееры данных могут оперировать как очень большими, так и очень малыми данными. Число датасетов из каталога данных Всемирного банка может быть более 6 миллионов за раз, а из ряда малых каталогов данных это может быть всего 2-3 датасета.

5. Если рассмотреть инструменты для оркестрации и ETL/ELT в контексте этих особенностей то вылезает следующее:
- Meltano - ключевая фишка в большом числе коннекторов которые надо писать под каждый источник данных. Потенциальный ETL/ELT инструмент в связке с инструментом оркестрации.
- Dagster - выглядит симпатично на небольшом числе конвееров, нет результатов экспериментов на большом их числе, условно на тысячах.
- Kestra - внешне выглядит неплохо, но написан полностью на Java что заранее накладывает сомнения применимости в Python-only инфраструктуре.
- Airflow - чистый оркестратор, может быть применён в связке с собственной или донастроенным внешним ETL/ELT
- Prefect - хорошо выглядящий оркестратор на Python, но с заложенными ограничениями в бесплатной версии.

6. Какой стек работы с данными в итоге выбрать? Из того что я видел на практике, ни один нельзя использовать как единственно возможный и даже выбрав надо всё равно делать свой дашборд мониторинга работы с источниками данных потому что пока ни в одном из инструментов я ещё не встречал работы с цепочками конвееров данных.

7. И это ещё не доходя до вопроса контроля качества данных. Контроль качества данных вроде как должен быть частью конвееров сбора данных, но практика в том что неполнота и недостаточное качество не должно быть ограничением для включения в поисковый индекс, но должно быть механимом пост-контроля выявления проблем и перезагрузки датасетов или доработкой процедур обогащения и очистки данных.

8. Поэтому один из путей решения - это условное разделение источников поступления эталонных данных. Неважно как именно отработал пайплайн, оркестратором, ad-hoc скриптами или пушем из другого сервиса, главное что он соответствует заданной схеме и проходит валидацию. Поступающие данные идут в staging (промежуточную) базу данных, а уже в ней работает конвеер по преобразованию данных в эталонные.

9. Это позволяет переводить инфраструктуру сбора и обработки метаданных датасетов на конвееры итеративно, но требует документирования схем, хорошего их проектирования под дальнейшую эволюцию и тд. Впрочем проектирование схем это нечто неизбежное поскольку без них контроль качества данных недостаточен.

#dateno #thoughts #dataengineering #elt #etl #datapipelines