Способы извлечения/поглощения данных

▪️Прямое подключение к базе данных (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, ага…

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

Очень люблю такие статьи. Все четко, по полочкам, по уму. Но не работает (в подавляющем большинстве случаев). Чтобы внедрить культуру данных, корпоративную культуру и прочие "над-культуры", должен появиться определенный уровень "просто-культуры". А пока этот уровень находится где-то в районе "Айзек Азимов за свою жизнь написал 500 книг, это ровно на 500 книг больше, чем прочитали мои родители", все попытки внедрения сродни попыткам измельчить жидкость без вкуса, цвета и запаха до размера молекулы продолговатым предметом в сосуде округлой формы.

Поэтому, условно говоря, сначала Чехов, а уж потом Клеппман...

P.S. Цитата про Айзека Азимова принадлежит доктору Шелдону Куперу в переводе "Кураж-Бамбей".

https://big-i.ru/innovatsii/tekhnologii/kak-sozdat-v-kompanii-kulturu-dannykh/

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

Как в биатлоне, промахнулись и зашли на штрафные 150 метров...

https://habr.com/ru/post/721636/

Кажется, что пора оторваться от высоких материй и вернуться к видам систем хранения.

Аналитические базы данных – это системы (обычно распределенные), предназначенные специально для поддержки OLAP-нагрузки. Для этого в них имеются всякие модные штуки, типа: колоночное хранение, приближенные вычисления и др.

Основные представители – мой любимый GreenPlum, нетормозящий ClickHouse, Vertica и т. п.