https://habr.com/p/712946/
Статья явно не для начинающих. Но, думаю, что интересно будет почитать про платформу данных, в которую уже интегрировано 150 источников

Еще один важный аспект для рассмотрения: Push vs Pull vs Poll.

• Push – система – источник сама отправляет данные в систему назначения
• Pull – система назначения забирает данные из системы-источника
• Poll – система назначения периодически проверяет систему-источник на наличие изменений, если изменения есть она их забирает

Продолжение следует ...

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

Мораль: всегда предупреждайте своих коллег заранее даже о небольших изменениях в схеме данных. Или внедряйте Data Mesh😁

Всех с пятницей, что ли!

Кажется, что это 2 самых популярных и дискуссионных акронима в мире данных. Образованы они от одних и тех же слов, только порядок букв немного различается. При быстром взгляде немудрено и перепутать.

E(xtract) – извлечение данных из источника
T(ransform) – преобразование данных
L(oad) – загрузка данных в место назначения

ETL от ELT отличается тем, что в процессе движения данных от источника к назначению к ним применяются различные преобразования: очистка, обогащение, изменение структуры и т. д. В ELT же данные сначала загружаются в “сыром” виде (в том, в котором они хранились в источнике), а уже потом к ним применяются различные преобразования.

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

По сути, data ingestion – это и есть ETL/ELT за некоторыми исключениями.

Долгое время считался антипаттерном, "изгоем" в мире данных, "Тем-Кого-Нельзя-Называть". "Набрал силу" с ростом популярности data science и machine learning.
Это обратный процесс, когда обработанные в OLAP-системе данные возвращаются в OLTP-систему в виде различных прогнозов, скоринговых моделей, персональных рекомендаций и т. д.

Change Data Capture (CDC) – захват изменения данных – еще одно важное понятие, достойное отдельного рассмотрения. Это набор шаблонов для определения измененных в системе-источнике данных, применяемый с целью упрощения/ускорения процесса загрузки.

Можно выделить 2 основных способа:

• Полное извлечение
• Инкрементное (дифференциальное)

В свою очередь инкрементное извлечение можно поделить на пакетное и потоковое (непрерывное).

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

➕ Очень просто реализовать, даже думать практически не надо
➖ Сложности с сохранением истории изменений (особенно при полной очистке😄)
➖ На больших объемах может выполняться очень долго (особенно, если вычисляется разница)

Продолжение следует ...

Инкрементное извлечение применяется для переноса только измененных данных.

Пакетное инкрементное извлечение используется, в случае, если в источнике есть поля, по которым можно определить измененные строки, например, дата/время изменения. Таким образом можно отфильтровать данные, измененные с момента предыдущей загрузки.

➕ Тоже достаточно просто реализовать
➕ Практически нет проблем с сохранением истории изменений. Но сохраняться будут только конечные состояние строк. Если в течение регламентного периода строка менялась несколько раз, то промежуточные изменения мы не увидим
➖Нельзя отследить удаленные на источнике записи
➖ Последние загруженные значения нужно где-то хранить, каждый раз вычислять их на большом объеме будет тяжелой задачей. Но тут может помочь использование оркестратора, например, Apache Airflow
➖Мало кто строит индексы по подобным полям, а значит процесс извлечения может быть медленным

Потоковое инкрементное извлечение подразумевает передачу изменений практически в реальном времени. Есть несколько подходов для реализации такой передачи.

Например, при возникновении изменений источник сразу записывает их в приемник. Такой подход называется trigger-based.

Или же log-based подход, который применяется, если система-источник ведет лог изменения данных. В таком случае специальные CDC-инструменты могут читать этот лог и отправлять изменения в систему-приемник. Пример – Debezium и Apache Kafka.

➕ Есть возможность получать все изменения практически в реальном времени
➖ Триггеры могут замедлить работу системы-источника, а для чтения логов придется "пошаманить" со специальными инструментами.

Из интересного "на почитать".

Все четко и по делу. Естественно, ни о какой “очередной смерти бигдаты” речи не идет, скорее об изменении мышления. Последние пару лет многие компании озаботились ценностью, которую им приносят данные, поиском шаблонов их использования, поиском редко запрашиваемых данных для оптимизации хранения и ускорения запросов к данным. А некоторые даже подобрались к великому вопросу имени Гарика "Бульдога" Харламова: "А нужна ли вот аналитика вообще, в принципе? Нужна потому, что?” - “Потому что гладиолус,” - их уже не устраивает.

Я вижу некий парадокс в том, что data-driven подход, который подразумевает переход от принятия решений на основе экспертной оценки к решениям на основе данных, сам по себе является сейчас даже не expert-, а business-driven. А что если можно применить data-driven подход к самому data-driven подходу?🤔
https://motherduck.com/blog/big-data-is-dead/

У кого так было?

Лирическое отступление или как стать инженером данных.

Начните с изучения того, что станет фундаментом вашей карьеры

✅ Алгоритмы и структуры данных
✅ Теория баз данных и SQL
✅ Теория хранилищ данных
✅ Data Mesh
✅ Git
✅ Docker

Пустая трата времени:

❌ Изучение конкретного иструмента, если не планируете применять его здесь и сейчас.
❌ Изучение “хайпового” инструмента. “Чем больше хайп, тем громче падает,” - кажется, так говорили в моем севернодеревенском детстве.

Способы извлечения/поглощения данных

▪️Прямое подключение к базе данных (SQL, ETL-инструменты, Python и т. п.)

▪️Чтение лога базы данных (CDC-инструменты, например Debezium)

▪️API. Поставщик данных предоставляет интерфейс для доступа к ним (Python и т. д.)

▪️Брокеры сообщений

▪️Обмен файлами. Система-источник выгружает файл с данными в согласованном формате, например, в объектное хранилище по расписанию. Экстремальный случай – файл выгружает специально обученный человек и отправляет его по почте.

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

Когда наконец-то завершил курс "Инженер облачных сервисов" от Яндекса.

Следующая задача инженера данных – организовать постоянное или промежуточное хранение для извлеченных данных. А значит, нужно понимать, какие подходы и системы для этого используются.

Основные подходы

Data Warehouse (хранилище данных)
Data Lake (озеро данных)
Data Lakehouse (русскоязычный термин мне не встречался)
Data Platform (платформа данных)

Продолжение следует...

Data Warehouse или же хранилище данных (в русском переводе “книги с кабанчиком” – склад данных)

Отцом данного подхода, увидевшего свет в 1990 году, является товарищ Билл Инмон, определение которого я и приведу.

Хранилище данных – предметно-ориентированная, интегированная, неизменяемая, зависимая от времени база данных, предназначенная для поддержки принятия решений.

Характеристики хранилища данных

▪️ Предметно-ориентированность (subject-oriented) – данные хранятся в соответствии с областями, которые они описывают

▪️Интегрированность (integrated) – данные объединены из различных источников и структурированы

▪️Неизменяемость (nonvolatile) – данные в хранилище не должны изменяться или удаляться (если это, конечно, не противоречит действующему законодательству)

▪️Засисимость от времени (time variant) – сохраняется история изменения данных в источнике.

Существуют разные подходы к проектированию хранилищ, но все их объединяет одно: данные преобразованы и структурированы таким образом, чтобы поддерживать "тяжелые" аналитические запросы.

DE Skill Set от Marc Lamberti
(возможно, самый известный популяризатор Apache Airflow, рекомендую начать следить за его публикациями, если еще нет)

Копипаст, если вдруг кому-то лень лезть в Линкедин

The Data Engineer Skill Set 🧳
These skills will set you up to become a Data Engineer 🚀
Don't chase the hype!
Trends and tools change; Core concepts stay 😉
P.S: Soft skills are important too. Communication is key!

И ссылка на оригинал для тех, кому не лень

Data Lake (Озеро данных) – предназначено для хранения большого объема данных в “сыром” (Raw), необработанном виде.

Данные обычно поступают из нескольких разнородных источников и могут быть структурированными, частично структурированными (CSV, лог файлы, XML, JSON) и неструктурированными (почтовые сообщения, документы, pdf).

Data LakeHouse – для многих архитектура мечты😀

Если совсем просто, то это гибрид DL и DWH, в котором данные хранятся в DL (объектное хранилище, например), только к этому прикручена возможность поддержки схемы данных, транзакций и update/delete операций.

Основные проекты, которые помогут построить LakeHouse: Delta Lake, Apache Iceberg и Hudi.