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

* Аналитик данных(data analyst)
* Исследователь данных(data scientist)
* Дата-стюард(data steward)

Есть еще DataOps/MLOps-инженеры, но кто это такие, я понятия не имею. По крайней мере, я не знаю ни одного человека, который бы себя позиционировал подобным образом. И на HH вакансии можно по пальцам пересчитать.

Аналитики данных собирают и интерпретируют данные для поиска ответов на какие-либо вопросы или решения какой-либо задачи. А потом презентуют результаты своей работы бизнесу.
С точки зрения инженеров и администраторов баз данных, постоянно “наводят суету”, пренебрегают правилами и являются источником головной боли и бессонных ночей. Зато всегда на виду.

Хороший аналитик знает:
- SQL для получения данных из базы
- Python или R для обработки данных
- Математику и статистику, а также бизнес-процессы для правильной интерпретации полученных результатов
- Средства визуализации (Tableau, Power BI), чтобы продемонстрировать свои результаты бизнесу.

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

Основная задача, как и у аналитиков, - помощь бизнесу в принятии решений на основе данных. Только, если фокус аналитиков – прошлое и настоящее, то помыслы дата-сайентистов устремлены в будущее. Используя "мутные", только им понятные алгоритмы, они строят модели для прогнозов и рекомендаций.

Здесь больше математики и программирования и меньше визуализации.

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

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

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

На все руки👍

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

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