Айти-Пингвин | Дата инженер

Что такое Lakehouse?

Название Lakehouse сложилось из Data Lake и Data Warehouse. Идея в том, чтобы хранить данные как в Data Lake, но работать с ними почти как в DWH.

В классическом DWH данные загружаются внутрь СУБД, например Greenplum. Она отвечает за хранение, SQL, транзакции и управление таблицами.

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

Data Lake устроен иначе. Данные лежат в S3 в открытых форматах вроде Parquet. Хранилище масштабируется отдельно, а одни файлы могут использовать разные инструменты.

Но просто сложить Parquet-файлы в S3 недостаточно.

Если одна джоба перезаписывает таблицу, другая может прочитать её в середине загрузки. Также нужно хранить схему, отслеживать версии и понимать, какие файлы относятся к текущему состоянию таблицы.

Lakehouse добавляет этот недостающий слой управления.

Из чего он состоит?

1. Объектное хранилище

S3, MinIO или другой storage хранит файлы с данными.

2. Табличный формат

Iceberg, Delta Lake или Hudi управляет схемой, версиями и изменениями файлов. Этот слой даёт транзакции, конкурентную запись, time travel и rollback.

3. Каталог

Хранит информацию о таблицах и указывает движкам, где находятся их актуальные метаданные. В этой роли могут использоваться Hive Metastore, AWS Glue, Nessie или Iceberg REST Catalog.

4. Вычислительные движки

Spark выполняет обработку, Trino запускает SQL-запросы, Flink работает с потоками. Все они могут обращаться к одним таблицам.

Зачем отделять хранение от вычислений?

Объём данных растёт постоянно, а нагрузка меняется. Ночью может работать тяжёлый ETL, днём выполняются короткие запросы, а часть истории месяцами просто хранится.

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

Также не обязательно создавать отдельную копию данных для Spark, вторую для SQL и третью для ML. Разные инструменты могут работать с общей таблицей.

Когда Lakehouse действительно нужен?

Не каждой компании нужен Lakehouse.

Если данных немного, ими занимается одна команда, а аналитика помещается в одной СУБД, Lakehouse может только добавить сложности.

Польза становится заметна, когда данных действительно много, с ними работают разные команды, а внутри компании есть несколько типов нагрузки и форматов данных.

Одной команде нужен SQL и BI, другой - Spark, третьей - машинное обучение, четвёртой - потоковая обработка. Хранить для каждой команды отдельную копию данных становится дорого и неудобно.

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

Но компания должна быть достаточно зрелой. Нужны единые правила работы с данными, владельцы таблиц, каталог, разграничение доступа, контроль качества и команда, которая поддерживает платформу.
Без этого вместо Lakehouse легко получить большое S3-хранилище, в котором никто не понимает, кому принадлежат данные и можно ли им доверять.

Почему это стало возможным именно сейчас?

Хранить файлы отдельно умели и раньше. Но старым Data Lake не хватало управления таблицами, а работа с файлами уступала DWH по удобству и надёжности.

Затем объектные хранилища стали обычной частью data-платформ. Появились Iceberg, Delta и Hudi, развились каталоги, а движки научились работать с этими форматами.

А что с DWH?

Lakehouse не обязательно заменяет DWH. Современные облачные DWH тоже разделяют хранение и вычисления, поэтому граница между подходами размывается.

Для стабильной BI-нагрузки готовая СУБД часто проще. Lakehouse полезен, когда данных много и они нужны разным командам и инструментам.

Если коротко, Lakehouse - это Data Lake, которому добавили управление таблицами и часть возможностей DWH. Но оправдан он обычно тогда, когда масштабы и зрелость компании требуют собственной data-платформы.
————
Как же нейронки стали хорошо генерить картиночки))

it пингвин | data engineer 🐧

⚡️⚡️Архитектура доступа к данным меняется. Что дальше?

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

Сегодня рядом с привычными JDBC и ODBC появляются Apache Arrow, ADBC, Flight SQL, Spark Connect и нативные HTTP-протоколы движков. На SmartData 2026 Петр Гуринов (Yandex Cloud) разберет, что происходит между запросом и результатом, почему старые интерфейсы пока не уходят, где новые подходы действительно помогают и какие компромиссы приходится учитывать при выборе технологии.

Если вы проектируете платформы данных, работаете с аналитическими системами или BI-инструментами, этот доклад поможет лучше понять архитектуру доступа к данным и осознаннее выбирать инструменты под свои задачи.

🗓SmartData 2026 пройдет 23–24 сентября (Москва + онлайн).

🐧Купить персональный билет со скидкой 15% по промокоду DATAPENGUIN и ознакомиться с полной программой можно на сайте конференции.

Мошенники под видом рекрутеров

Ребят, аккуратнее с тестовыми заданиями от незнакомых рекрутеров.

Сейчас мошенники могут представиться рекрутером и прислать вредоносный код под видом тестового задания.

Это может быть ссылка на репозиторий или архив с проектом. Задача будет выглядеть вполне обычно: установить зависимости, запустить приложение и что-нибудь в нём поправить.

Но вместе с проектом можно запустить вредоносный код.

Схема такая:

Вам пишет якобы рекрутер, немного общается про опыт и предлагает хорошую вакансию. Потом присылает тестовое и просит запустить его на своём компьютере.

В одном из таких заданий нашли скрытый импорт вредоносного npm-пакета. Код был обфусцирован (специально запутан, чтобы его было сложно прочитать). После запуска он скачивал ещё один файл и запускал его отдельным процессом в фоне.

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

Что он искал?

- данные браузеров Chrome, Edge;
- токены и сохранённые сессии;
- данные браузерных расширений;
- файлы криптокошельков;
- сохранённые пароли и другие учётные данные.

На компьютере разработчика обычно лежит ещё много важного: SSH-ключи, файлы .env, токены доступа к репозиториям, облакам и рабочей инфраструктуре.

И для этого не обязательно запускать какой-то подозрительный exe-файл. Вредоносный код может выполниться во время обычного npm install через install-скрипты пакета.

Что стоит проверить перед запуском?

1. Кто прислал тестовое

Посмотрите аккаунт рекрутера, сайт компании и саму вакансию. Лучше отдельно найти контакты компании и проверить, действительно ли у них есть такой сотрудник и вакансия.

2. Зависимости

Иногда вредоносный пакет маскируют под популярный. Например, пакет crossenv маскировался под настоящий cross-env. Отличие только в одном дефисе, который легко не заметить.

Поэтому стоит посмотреть package.json и проверить незнакомые зависимости.

3. Скрипты запуска

В обычном тестовом не должно быть кода, который скачивает неизвестные файлы, запускает PowerShell или отдельные процессы через child_process, spawn и exec.

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

4. Где запускается проект

Не стоит запускать неизвестное тестовое на рабочем компьютере или основном ноутбуке. Лучше использовать отдельную виртуальную машину без общих папок, паролей, ключей и рабочих доступов.

Docker тоже не всегда спасает. Если внутрь контейнера передали папки с компьютера, переменные окружения или Docker socket, доступ к данным всё ещё можно получить.

В последнее время всё чаще слышу про подобные истории. Будьте внимательны и смотрите, что вам присылают. Даже если это обычное тестовое задание от рекрутера.
————
Вам такие тестовые попадались? Я бы сейчас тестовые или вообще не делал. Или делал после реального собеседования и только тестовое в виде текстового файлика/ворда/просто сообщение (конечно, если очень хочется в этом месте работать).

upd. И да, следите кому отправляете свои документы (часто просят весь пакет документов для оформления на работу)! 100 раз подумайте, может ли этот человек быть скамщиком.

it пингвин | data engineer 🐧

Apache Iceberg - зачем он нужен?

Iceberg всё чаще встречается в вакансиях и архитектуре. Что это: база данных, альтернатива Parquet или часть Spark?

Iceberg - открытый табличный формат. Он не заменяет Parquet и не выполняет запросы вместо Spark или Trino.

Допустим, в S3 лежит таблица из множества Parquet-файлов. Parquet определяет устройство каждого файла, но ничего не знает о таблице целиком.

Какие файлы сейчас актуальны? Что делать, если две джобы одновременно записывают данные? Как вернуть таблицу в состояние до неудачной загрузки?

Iceberg хранит над файлами метаданные: схему, партиционирование, статистику и историю изменений.

Таблица состоит из snapshots - её версий. Каждый snapshot содержит точный список файлов на определённый момент.

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

Что это даёт?

1. Конкурентная запись

Несколько джоб могут одновременно работать с таблицей. При коммите Iceberg проверяет, не изменились ли затронутые данные, и обнаруживает конфликт.

2. Time travel и rollback

Можно прочитать таблицу в состоянии на определённый момент или вернуть её к предыдущему snapshot после ошибочной загрузки.

3. Безопасное изменение схемы

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

4. Скрытое партиционирование

В запросе можно фильтровать обычную колонку с timestamp, а Iceberg сам определит подходящие партиции. Способ партиционирования можно менять без немедленной перезаписи старых файлов.

5. Планирование чтения

По статистике в метаданных движок заранее исключает файлы, в которых нет нужных данных. Для таблиц с миллионами файлов это сильно сокращает объём чтения.

Почему недостаточно DWH, например Greenplum?

В MPP-СУБД хранение и вычисления находятся в одном кластере. Расширяя его ради растущего объёма данных, приходится добавлять и вычислительные ресурсы.

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

Почему Iceberg появился только сейчас?

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

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

Что Iceberg даёт этим движкам?

Iceberg - не отдельный сервер. Это спецификация таблицы, библиотеки и интеграции.

Они объясняют движку, как найти нужные файлы, применить фильтры, прочитать таблицу, записать новую версию и выполнить коммит. Движок занимается вычислениями, а Iceberg отвечает за состояние таблицы.

Снаружи всё действительно выглядит просто. Но внутри snapshot ссылается на manifest list, тот - на manifests, а в них уже хранятся списки data files и статистика.

Iceberg также разрешает конфликты между параллельными записями, повторяет неудачные коммиты, отслеживает удаления и сохраняет файлы, которые ещё нужны старым snapshots.

Таблицы приходится обслуживать: объединять небольшие файлы, удалять старые snapshots, очищать потерянные файлы и оптимизировать manifests.

То есть идея простая, а реализация нет. Пользователь видит обычную таблицу именно потому, что основная сложность спрятана внутри формата и его интеграций.

————
Как вам формат? Хочу чаще делать посты, писать на понятном языке про всякие de-шные (и не только) технологии.


it пингвин | data engineer 🐧

Обзор большого собеседования с IT_One

У моего менти было интересное собеседование😢 Длительность 3 часа💀
"По опыту косвенные вопросы, по типу на вопросах иногда просили уточнить как это было устроено у вас на работе"

Кандидат ответил на все вопросы и очень хорошо. Пришел отказ без нормальной обратной связи.
В общем, та еще клоунада. IT_One в своем репертуаре ))
Но мы получили хороший список вопросов для самопроверки. Всем будет полезно.

Основные вопросы:
1) Чем отличаются DWH и Data Lake?
2) Какие существуют форматы хранения данных?
3) Какие преимущества у колоночных форматов, например Parquet?
4) Что такое OLTP и OLAP?
5) Какие задачи решают OLTP и OLAP системы?
6) Что такое snapshot в контексте DWH?
7) Что такое staging слой в DWH?
8)Какова роль core слоя в DWH?
9)Что такое marts в DWH?
10)Объясните понятие surrogate key.
11)Чем отличается surrogate key от natural key?
12)Что такое Kimball методология?
13)Что такое Inmon методология?
14)В чем разница между star и snowflake схемами?
15)Как выбрать последние 1000 записей по времени с помощью SQL?
16)Что такое running balance и как его реализовать?
17)Чем оконные функции отличаются от агрегатных?
18)Как реализовать фильтрацию по конкретной дате в SQL?
19)Какие типы JOIN существуют?
20)Как оптимизировать JOIN в больших таблицах?
21)Что такое партиционирование в базах данных?
22)Чем полезна архитектура MPP?
23)Как справляться с проблемой data skew?
24)Какие методы обработки невалидных данных вы знаете?
25)Что такое quarantine для данных?
26)Как организовать мониторинг качества данных?
27)Чем отличается commit от push в git?
28)Что такое ветвление (branching) в git?
29)Как устроен CI/CD pipeline?
30)Как хранить secrets в CI/CD системах?
31)Что такое Spark?
32)Как устроена архитектура Spark?
33)Что такое RDD и DataFrame в Spark?
34)Как писать Spark-приложения на PySpark?
35)Как реализовать сложную агрегацию в Spark?
36)Что такое HDFS и как с ним работать?
37)Как автоматизировать запуск Spark job через Airflow?
38)Как работает Kafka?
39)Что такое Kafka Connect?
40)Как реализовать потоковую обработку на базе Kafka и ClickHouse?
41)Как устроен Data Pipeline с Kafka → Kafka Connect → Materialized Views → ClickHouse?
42)Что такое dbt и для чего он нужен?
43)Как dbt помогает с lineage данных?
44)Какие преимущества у инкрементальной загрузки данных?
45)Как проектировать ключи дистрибуции в Greenplum?
46)Какие средства мониторинга и алертинга вы использовали?
47)Что такое Iceberg и Trino?
48)Как настроить multi-cluster обработку в Spark?
49)Какие есть best practices для ETL пайплайнов?
50)Как проводить code review для ETL и аналитического кода?

Задачу тоже прикрепляю 🫡

Как вам собесик😁? Ответили б на все вопросы?

it пингвин | data engineer 🐧

#собеседование #менти

Те самые вечера с Глебом Михайловым 🚬

Прохожу курс по алгоритмам от Глеба 🐆

Пока, что закончил пару блоков - быстрый старт по питону и задачи по массивам.

Что могу сказать на данный момент.
Конечно, курс мне нравится))
Смотрю видосики на 2.25, решаю задачки. Все лампово. Подача материала очень хорошая, ничего лишнего. Видосики больше 10 минут не идут. Задачки прям интересные.

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

Нравится, что Глеб вкидывает информацию как правильно именовать переменные, показывает и простые решения в лоб, и оптимальные алгоритмы и однострочные решения. Объяснил как считается сложность алгоритма. Все это интересно.

Прохождение курса логирую. Сейчас я потратил на курс 6 часов 20 минут и решил 28 задач🍴

Результат уже виден. После блока по массивам я решил сходу задачки, которые раньше не решил бы 🦦
Главное дальше двигаться по графику и решать все задачки. Курс длится до августа 😱


Вот прикольная задачка:
Замените элементы на наибольший элемент в правой части.
Дана последовательность элементов arr. Замените каждый элемент этой последовательности на наибольший элемент среди элементов справа от неё, а последний элемент замените на -1.

После этого верните массив.

Example 1:

Input: arr = [17,18,5,4,6,1]
Output: [18,6,6,6,1,-1]

Example 2:

Input: arr = [400]
Output: [-1]

Я чуть позже в комменты закину решение.
Кто осилит задачку, тоже делитесь решениями ⬇️

it пингвин | data engineer 🐧