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.

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

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

Пример
https://habr.com/ru/company/leroy_merlin/blog/561072/

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

Реляционные БД (PostgreSQL, MSSQL, Oracle и т. д.) по-прежнему остаются популярными в качестве основы для построения хранилищ данных, особенно небольших (примерно до 1ТБ).

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

Главный минус тоже очевиден. С тяжелыми запросами, выбирающими большие объемы данных, могут возникнуть проблемы, даже если все и вся перекрыть индексами. Поэтому ведущие производители таких СУБД дополняют их средствами для поддержки подобных запросов, например, колоночные индексы в MSSQL.

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

Лирическое отступление - 2 или внутри инженера данных.

Мне всегда нравилось возиться с цифрами. В четвертом классе на вопрос: "Кем ты хочешь стать?" - я уверенно отвечал: “статистиком”. Примерно в то же время я "построил" свою первую платформу данных, когда мама попросила перенести на "холодное хранение" кучи номеров еженедельника "Футбол", захламлявших антресоли.

В качестве Object Storage я выбрал красную папку советского производства, в качестве ETL-инструмента – ножницы, для визуализации – зеленую школьную тетрадь в клетку (18 листов, Архангельский Целлюлозно-Бумажный Комбинат).

Я вырезал понравившиеся мне материалы из еженедельника и складывал их в папочку. А уже потом, когда первоначальная загрузка была завершена, приступил к анализу. Я рисовал в тетрадке таблицы лучших бомбардиров всех времен различных европейских футбольных турниров: Кубка Обладателей Кубков, Кубка Чемпионов, Кубка УЕФА. Используя придуманные мной алгоритмы, составлял символические сборные чемпионатов СССР по футболу. Такой вот data science, ага…

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