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

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

Приготовить идеальное "дата-зелье", без их помощи крайне сложно.

На все руки👍

Вот мы и добрались до инженеров. Я встречал множество различных определений, но больше всего мне нравится то, которое дали авторы книги "Fundamentals of Data Engineering":
Инженеры данных – это специалисты по разработке, запуску в эксплуатацию и сопровождению систем и процессов по извлечению данных из различных источников и предоставлению их в удобном для дальнейшего использования виде, например, системами аналитики или машинного обучения. (мой вольный перевод)

Из этого определения следуют 3 основные задачи инженера данных:
- Извлечь данные из источника
- Сохранить данные
- Преобразовать данные для предоставления их в удобном виде конечному пользователю

На мой взгляд, ETL/Data и DataOps-инженеры - это одна профессия, просто уровень по матрице компетенций разный.

Каюсь, я забыл про еще одну важную дата-профессию. Да простят меня мои бывшие и нынешние коллеги!

Архитектор данных – это тот человек, который "видит всю картинку целиком", проектирует ваш дата-мир и в специальных программах рисует основные “сюжетные” блоки и линии.

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

Далее мы переходим к задачам инженеров данных и инструментам, при помощи которых эти задачи решаются.

Первая задача инженера данных – извлечение (или точнее поглощение, но я по старинке😁) данных.

Кажется, что тут все просто: извлечение/поглощение – процесс перемещения “сырых” данных из системы-источника в систему хранения. Однако есть ряд интересных моментов, подходов и концепций для рассмотрения.

Для начала вопросы, которые следует задать перед решением данной задачи:

• Каков тип источника данных (файл, API, SQL/NoSQL база данных и т. д.), соответствует ли он выбранной системе хранения(файловая система, объектное хранилище, база данных и т. д.)?
• Как часто нужно забирать данные из источника?
• Каковы ожидаемые объем и прирост данных?
• Какова схема данных и как часто она меняется?
• Какова нагрузка на систему-источник?
• Возможна ли инкрементная загрузка (то есть только изменений, произошедших с момента предыдущей загрузки) и как ее организовать?
• Как будет осуществляться первоначальная загрузка?
• А что там с качеством данных?

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

Частота выгрузки данных из источника настолько важна, что стоит ее рассмотреть отдельно. Здесь можно выделить 3 подхода:

• Batch – пакетная обработка. Данные загружаются большими порциями (пакетами) либо за определенный интервал времени, либо по достижении определенного порогового размера
• Micro-Batch – то же самое, только временной интервал меньше (до 1 минуты)
• Real-time (streaming) – потоковая обработка. Данные передаются непрерывно сразу же после их возникновения в системе-источнике.

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

Потоковая обработка обычно используется в таких областях, как кибербезопасность, Интернет вещей (IoT), персонализированные маркетинговые сервисы и т. д.

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

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 и т. д.)

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

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

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