Change Data Capture (CDC) – захват изменения данных – еще одно важное понятие, достойное отдельного рассмотрения. Это набор шаблонов для определения измененных в системе-источнике данных, применяемый с целью упрощения/ускорения процесса загрузки.
Можно выделить 2 основных способа:
• Полное извлечение • Инкрементное (дифференциальное)
В свою очередь инкрементное извлечение можно поделить на пакетное и потоковое (непрерывное).
Полное извлечение подразумевает под собой копирование всех данных из источника в приемник. Обычно используется при первой загрузке. Но может запускаться и по расписанию. В таком случае приемник либо полностью очищается, либо идет построчное сравнение для определения разницы. Плюсы и минусы такого подхода очевидны:
➕ Очень просто реализовать, даже думать практически не надо ➖ Сложности с сохранением истории изменений (особенно при полной очистке😄) ➖ На больших объемах может выполняться очень долго (особенно, если вычисляется разница)
Долгое время считался антипаттерном, "изгоем" в мире данных, "Тем-Кого-Нельзя-Называть". "Набрал силу" с ростом популярности data science и machine learning. Это обратный процесс, когда обработанные в OLAP-системе данные возвращаются в OLTP-систему в виде различных прогнозов, скоринговых моделей, персональных рекомендаций и т. д.
Кажется, что это 2 самых популярных и дискуссионных акронима в мире данных. Образованы они от одних и тех же слов, только порядок букв немного различается. При быстром взгляде немудрено и перепутать.
E(xtract) – извлечение данных из источника T(ransform) – преобразование данных L(oad) – загрузка данных в место назначения
ETL от ELT отличается тем, что в процессе движения данных от источника к назначению к ним применяются различные преобразования: очистка, обогащение, изменение структуры и т. д. В ELT же данные сначала загружаются в “сыром” виде (в том, в котором они хранились в источнике), а уже потом к ним применяются различные преобразования.
Когда-то эти подходы были предметом жарких споров, но сейчас границы между ними размыты, и очень часто можно встретить платформы данных, в которых применяются оба.
По сути, data ingestion – это и есть ETL/ELT за некоторыми исключениями.
Как-то раз фраза "да мы тут всего одно поле дропнули", произнесенная командой разработчиков системы-источника для хранилища, которое я тогда разрабатывал, оставила меня без новогодних праздников.
Мораль: всегда предупреждайте своих коллег заранее даже о небольших изменениях в схеме данных. Или внедряйте Data Mesh😁
Еще один важный аспект для рассмотрения: Push vs Pull vs Poll.
• Push – система – источник сама отправляет данные в систему назначения • Pull – система назначения забирает данные из системы-источника • Poll – система назначения периодически проверяет систему-источник на наличие изменений, если изменения есть она их забирает
https://habr.com/p/712946/ Статья явно не для начинающих. Но, думаю, что интересно будет почитать про платформу данных, в которую уже интегрировано 150 источников
Частота выгрузки данных из источника настолько важна, что стоит ее рассмотреть отдельно. Здесь можно выделить 3 подхода:
• Batch – пакетная обработка. Данные загружаются большими порциями (пакетами) либо за определенный интервал времени, либо по достижении определенного порогового размера • Micro-Batch – то же самое, только временной интервал меньше (до 1 минуты) • Real-time (streaming) – потоковая обработка. Данные передаются непрерывно сразу же после их возникновения в системе-источнике.
Пакетная обработка подходит для большинства сценариев использования данных: регулярная отчетность, анализ продаж, сегментация клиентов и т. д.
Потоковая обработка обычно используется в таких областях, как кибербезопасность, Интернет вещей (IoT), персонализированные маркетинговые сервисы и т. д.
Первая задача инженера данных – извлечение (или точнее поглощение, но я по старинке😁) данных.
Кажется, что тут все просто: извлечение/поглощение – процесс перемещения “сырых” данных из системы-источника в систему хранения. Однако есть ряд интересных моментов, подходов и концепций для рассмотрения.
Для начала вопросы, которые следует задать перед решением данной задачи:
• Каков тип источника данных (файл, API, SQL/NoSQL база данных и т. д.), соответствует ли он выбранной системе хранения(файловая система, объектное хранилище, база данных и т. д.)? • Как часто нужно забирать данные из источника? • Каковы ожидаемые объем и прирост данных? • Какова схема данных и как часто она меняется? • Какова нагрузка на систему-источник? • Возможна ли инкрементная загрузка (то есть только изменений, произошедших с момента предыдущей загрузки) и как ее организовать? • Как будет осуществляться первоначальная загрузка? • А что там с качеством данных?
Каюсь, я забыл про еще одну важную дата-профессию. Да простят меня мои бывшие и нынешние коллеги!
Архитектор данных – это тот человек, который "видит всю картинку целиком", проектирует ваш дата-мир и в специальных программах рисует основные “сюжетные” блоки и линии.
Теперь, кажется, точно все. Конечно, мир не стоит на месте, профессии будут меняться и добавляться, взаимопроникать друг в друга, но данные 5 – это достаточный минимум для формирования полноценной дата-команды, способной решать амбициозные задачи.
Далее мы переходим к задачам инженеров данных и инструментам, при помощи которых эти задачи решаются.
Вот мы и добрались до инженеров. Я встречал множество различных определений, но больше всего мне нравится то, которое дали авторы книги "Fundamentals of Data Engineering": Инженеры данных – это специалисты по разработке, запуску в эксплуатацию и сопровождению систем и процессов по извлечению данных из различных источников и предоставлению их в удобном для дальнейшего использования виде, например, системами аналитики или машинного обучения. (мой вольный перевод)
Из этого определения следуют 3 основные задачи инженера данных: - Извлечь данные из источника - Сохранить данные - Преобразовать данные для предоставления их в удобном виде конечному пользователю
На мой взгляд, ETL/Data и DataOps-инженеры - это одна профессия, просто уровень по матрице компетенций разный.
Дата-стюарды – незаметные и недооцененные герои дата-мира, на мой взгляд. Их основная задача – помочь всем желающим в поиске необходимых качественных данных. Для этого они определяют правила по сбору, хранению, использованию, документированию и качеству данных и следят за выполнением этих правил.
Порой кажется, что они чересчур назойливы и требовательны, но, когда нужно за короткий срок найти данные для отчета среди тысяч таблиц в сотнях различных источников, понимаешь важность этих специалистов.
Приготовить идеальное "дата-зелье", без их помощи крайне сложно.
Тема нашего сегодняшнего разговора – дата-сайентисты. В русскоязычных публикациях их иногда именуют "исследователями данных", иногда – "специалистами по науке о данных". Оба термина мне не нравятся. Первый ограничивает суть, исследование данных – только часть их функционала, кроме того, аналитики данных тоже занимаются исследованиями. Второй для меня слишком "тяжеловесен". Поэтому в дальнейшем я буду упоминать только разговорное название.
Основная задача, как и у аналитиков, - помощь бизнесу в принятии решений на основе данных. Только, если фокус аналитиков – прошлое и настоящее, то помыслы дата-сайентистов устремлены в будущее. Используя "мутные", только им понятные алгоритмы, они строят модели для прогнозов и рекомендаций.
Здесь больше математики и программирования и меньше визуализации.
Аналитики данных собирают и интерпретируют данные для поиска ответов на какие-либо вопросы или решения какой-либо задачи. А потом презентуют результаты своей работы бизнесу. С точки зрения инженеров и администраторов баз данных, постоянно “наводят суету”, пренебрегают правилами и являются источником головной боли и бессонных ночей. Зато всегда на виду.
Хороший аналитик знает: - SQL для получения данных из базы - Python или R для обработки данных - Математику и статистику, а также бизнес-процессы для правильной интерпретации полученных результатов - Средства визуализации (Tableau, Power BI), чтобы продемонстрировать свои результаты бизнесу.
Есть еще DataOps/MLOps-инженеры, но кто это такие, я понятия не имею. По крайней мере, я не знаю ни одного человека, который бы себя позиционировал подобным образом. И на HH вакансии можно по пальцам пересчитать.
