Всем привет! Меня зовут Андрей, и я инженер данных. Мой первый опыт с данными случился в 2006 году (тогда это были СУБД Paradox и генератор отчетных форм Crystal Reports), и с тех пор я попробовал себя в разных ролях: от оператора БД до руководителя практики инженеров данных.
За это время у меня было множество интересных (и не очень) задач и проектов, одна(увы!) статья на хабре и запущенный совместно с коллегами корпоративный курс для DE.
А теперь я решил попробовать себя в качестве автора канала в Telegram.
Этот канал будет ориентирован скорее на новичков, на тех, кто хочет найти/сменить профессию, или же просто хочет разобраться в хитросплетениях различных дата-профессий, понять, чем они отличаются друг от друга и как взаимодействуют друг с другом.
Хардкора не будет, но это не точно.

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

OLTP (англ. Online Transaction Processing) — системы, предназначенные для быстрой обработки транзакций, то есть вставки, изменения, удаления записей.

OLAP (англ. online analytical processing) – системы, предназначенные для аналитических запросов.

Таким образом, появилась необходимость в специалистах, которые будут перемещать данные между OLTP и OLAP-системами. Желательно точно в срок, с необходимой полнотой и качеством, в удобном для использования виде…
Данные специалисты, пройдя несколько стадий эволюции, расширив свой функционал и разнообразив технологический стек, получили свое нынешнее, наверняка не последнее, название.

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

* Аналитик данных(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-систему в виде различных прогнозов, скоринговых моделей, персональных рекомендаций и т. д.