Parquet и ORC — что это вообще такое❓❓❓

Сегодня оба формата воспринимаются как стандарт для Data Lake.
Но появились они как ответ на реальные боли Hadoop-эры.
Начало 2010-х.
В экосистеме Apache Hadoop данные лежат в HDFS, аналитика делается через Apache Hive.
Проблема простая:
🔴CSV / TSV занимают много места
🔴Full table scan работает медленно
🔴Компрессия слабая
🔴Нет нормальной статистики по данным
🔴Hive буквально читает всё подряд.
Команда Hive понимает: нужен формат, который будет ускорять аналитические запросы.
Так в 2013 году появляется Apache ORC(Optimized Row Columnar).

Что такое ORC?🤔

📝ORC — это колоночный формат хранения данных. Файл в ORC логически делится на Stripes — крупные блоки данных, внутри которых хранятся сами колоночные данные и индексная информация. В конце файла находится Footer с общей метаинформацией и PostScript, содержащий служебные данные о структуре файла и параметрах компрессии. Внутри ORC хранится статистика по данным — min/max индексы по колонкам, встроенные Bloom filters для ускорения фильтрации, а также используется продвинутая схема компрессии, позволяющая эффективно сжимать данные разных типов. Изначально ORC создавался как «ускоритель Hive» и отлично подходит для тяжёлых DWH-нагрузок и сценариев с full table scan, где важно максимально оптимизировать чтение больших объёмов данных.

Параллельно Cloudera и Twitter понимают: Нужен формат, который будет работать не только с Hive. В том же 2013 году появляется Apache Parquet.
Его идея — универсальность:
🟣поддержка разных движков
🟣сложные nested структуры
🟣хорошая совместимость
🟣кросс-платформенность

Что такое Parquet🤔

📝Parquet — это колоночный формат хранения данных, в котором файл логически разделён на Row Groups — крупные блоки строк, внутри которых данные организованы по колонкам в виде Column Chunks, а минимальной единицей хранения являются Pages. В конце файла находится Footer, содержащий схему и метаданные. В footer хранится статистика по каждой колонке: минимальные и максимальные значения, количество строк, число null-значений и другая служебная информация.

Когда движок, например Apache Spark, выполняет запрос, он сначала читает footer, анализирует статистику и определяет, какие Row Groups можно пропустить. Затем он считывает только те блоки, где потенциально есть подходящие данные, и загружает только нужные колонки. Такой механизм называется predicate pushdown, column pruning и data skipping. Благодаря этому существенно уменьшается объём чтения с диска и снижается нагрузка на CPU и сеть, поэтому Parquet в разы быстрее обычных строковых форматов вроде CSV.


🐱Parquet и ORC появились не ради «ещё одного формата». Они стали ответом на практическую проблему: читать терабайты CSV — дорого, медленно и неэффективно. Строковые форматы заставляют движок загружать весь файл целиком, даже если в запросе нужны всего несколько колонок.

Колоночное хранение изменило экономику аналитики: стало меньше I/O, меньше нагрузки на CPU, сократился shuffle и в целом подешевела инфраструктура. Движки начали читать только нужные колонки и пропускать ненужные блоки данных, что кратно ускорило запросы.

Именно поэтому сегодня почти любой современный Data Lake строится поверх Parquet (реже ORC) — это уже не просто формат, а стандарт индустрии.

Рынок Data Engineering в 2026 — это уже совсем другой уровень!
За этот год требования значительно взлетели.
Теперь на собеседованиях мало просто «понимать технологии» — от тебя ждут реального опыта, глубоких деталей и умения рассказать, как ты решал настоящие проблемы в продакшене.

Типичные вопросы сейчас:
⏺Какой самый сложный ETL-процесс тебе приходилось разрабатывать?
⏺Как организована поставка в прод?
⏺Сколько строк в секунду реально лилось через пайплайн?
⏺На чём был реализован процесс (Spark, Flink, Airflow, dbt, Kafka Streams…)?
⏺Как проходила миграция данных / схем / хранилища?
⏺Какие требования бизнеса / SLA стояли?
⏺Какая была твоя роль на проекте ?

Вкатиться самостоятельно стало в разы сложнее.
Поверхностные знания уже не прокатывают — работодатели копают глубоко и хотят слышать конкретные истории успеха и фейлов.
Но хорошая новость: за последний месяц я с командой проработал много реального материала:
🔘 Собрали настоящие кейсы из жизни дата-инженеров
🔘 Разобрали вопросы по компаниям (от Big Tech до российских продуктовых)
🔘 Составили мощные легенды и структурированные рассказы о проектах
🔘 Подготовили ответы, которые реально цепляют интервьюеров
Результат? Люди проходят сложные этапы и получают долгожданные офферы ❕❕❕
Хочешь такую же детальную легенду под себя + уверенный рассказ о проектах, который не развалится под давлением?
Приходи на менторство.
Последние отзывы от ребят:
https://t.me/it_mentors/6596
https://t.me/it_mentors/6514
Пиши в личку, обсудим твою ситуацию:
В 2026 году офферы берут не те, кто «знает теорию», а те, кто может уверенно рассказать «как я это делал в проде и что было сложно».
Давай сделаем так, чтобы это был ты❕❕❕

Как работает CDC pipeline?

🌐В современных дата-платформах данные редко грузят батчами раз в сутки.
Чаще используют CDC (Change Data Capture) — потоковое получение всех изменений из базы.

Разберём классический пайплайн:

MySQL → Debezium → Kafka → ClickHouse

1️⃣В MySQL все изменения пишутся в binlog (binary log) - по сути журнал транзакций базы.
Каждая операция фиксируется как событие: INSERT,UPDATE,DELETE

2️⃣Debezium — это CDC-коннектор (обычно работает через Kafka Connect)
Он:
➡️подключается к MySQL
➡️читает binlog
➡️превращает события в Kafka messages
➡️пишет события в Kafka топики

3️⃣Kafka: транспортный слой между OLTP и аналитикой которая позволяет довольно продолжительное время накапливать историю

4️⃣Далее все направляется в ClickHouse: аналитическое хранилище
Он читает Kafka через Kafka Engine или ingestion сервис.
Выглядит это примерно так:
Kafka topic
↓
Kafka Engine Table
↓
Materialized View
↓
MergeTree таблица

🧐Почему такая архитектура стала стандартом

Она даёт:
➡️Near real-time данные
➡️минимальную нагрузку на OLTP
➡️возможность replay истории
➡️масштабируемость

Было полезно? Ставьте 🔥
#dataengineering #cdc #debezium #kafka

👋Рад тебя видеть в Дата Инженер Лаб!

Я — Артём Подвальный. Помогаю разобраться в работе инструментов обработки больших данных и как происходят эти процессы в компаниях. Здесь я стараюсь простым языком объяснить самое важное что надо знать начинающему DE и получить заветный оффер.

Самое полезное, что уже можно найти в канале:

🔥 Обязательно для прочтения:
Легендарный Roadmap для DE. Проверь, всё ли из этого ты знаешь

🏗 Все самое полезное для DE

💼 Для тех, кто ищет работу или планирует вкатываться в DE

Давай общаться!
Задавай вопросы в комментариях к любому посту или пиши мне лично: @ampodvalniy.

Давайте разберем такую ситаацию: твой пайплайн упал и данные за последние 3 часа «испарились», а восстановить их не из чего 💀

Если у тебя стоит RabbitMQ — это реальный сценарий. Если Kafka то проблема может решится парой команд в консоли. Так почему же один брокер будет прощать ошибки, а другой — нет? Разбирем фундаментальную разницу между Smart Broker и Dumb Broker, чтобы вы больше никогда их не путали.

Главное различие — в «интеллекте» системы:

🔘RabbitMQ (Smart Broker): Брокер сам следит за состоянием очередей, маршрутизирует сообщения и удаляет их сразу после подтверждения (ack). Это модель Push: брокер сам «толкает» данные потребителю. Это упрощает код клиента, но нагружает систему при росте данных.

🔘Kafka (Dumb Broker): Это распределенная платформа потоковой передачи, работающая как распределенный коммит-лог. Она просто записывает данные и хранит их. Здесь работает модель Pull: потребители сами запрашивают данные, когда готовы их обработать.

👀 Почему для Data Engineering почти всегда нужна Kafka?

🔛 Гипер-масштабируемость: Кафка переваривает миллионы сообщений в секунду. Секрет в партиционировании (partitions): топики делятся на части и распределяются между брокерами. Это позволяет распараллеливать чтение и запись на петабайтах данных. Мы упоминали это, когда разбирали современный Lakehouse.

🔛 Постоянство данных (Retention Policy): Сообщения не удаляются после прочтения. Они хранятся по времени или объему. Это позволяет нескольким потребителям читать одни и те же данные в разное время.

🔛 Replayability (Повтор): Если в пайплайне баг, ты просто перечитываешь данные заново. В RabbitMQ «съеденное» сообщение пропадает навсегда.

🔛 Гарантии Exactly-once: Кафка умеет доставлять сообщение «ровно один раз», что критично для финансов. Рэббит обычно гарантирует только «хотя бы один раз».

🐰Когда RabbitMQ — это НЕ ошибка?
🔘Сложная маршрутизация: Если нужно раскидывать задачи по куче условий (exchanges: direct, fanout, topic, headers). Кафка в базе так не умеет.

🔘Приоритеты: В RabbitMQ можно пометить сообщение как высокоприоритетное, и оно проскочит очередь. В Кафке порядок строго хронологический внутри партиции.

🔘Низкая задержка на малых данных: При небольших объемах Рэббит может быть быстрее, но при росте нагрузки его задержки растут лавинообразно.

Итого:
Если ты строишь Data Lake, систему аналитики или ETL-пайплайны — твой выбор Kafka. Она идеально ложится в архитектуру Data Vault, сохраняя историю без потерь.

RabbitMQ оставляем для микросервисов и простых очередей (например, фоновая отправка писем).

🔖Что почитать по теме: https://habr.com/ru/companies/slurm/articles/666326/

❓Вопрос к тем, кто учится:

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

Пиши в комментариях, обсудим! 👇


#Kafka #RabbitMQ #DataEngineering #ITCareer #CareerDE #DataScience

Вопрос по которому часто возникают трудности у кандидатов😐

«Как вы боретесь с дублями в Kafka на проде?». Напиши свой ответ в комментариях и сравнивай:

Ответ: "Три уровня защиты. Producer: enable.idempotence=true — закрывает сетевые ретраи. Consumer: проверяю event_id в Postgres перед обработкой. Транзакции — только для read-process-write между топиками Kafka. Главное правило: check → process → commit offset."

Совпало? Теперь разберем по полочкам, почему это важно: 👇

Почему дубли вообще есть?

1️⃣Producer retry
Producer отправил сообщение → брокер не ответил → producer отправил СНОВА
Kafka получила 2 одинаковых сообщения

2️⃣Consumer crash
Consumer прочитал сообщение → начал обработку → УПАЛ
При рестарте читает то же сообщение СНОВА

3️⃣Rebalance группы (80% проблем на проде!)
Consumer A обработал партицию → Consumer B взял её → обработал СНОВА

Как это можно решить:

🔵Настройка продюсера

Кафка выдает тебе Producer ID (PID) и заставляет нумеровать сообщения. Если брокер видит сообщение с номером, который уже был - он его просто выкидывает.

Настройка: enable.idempotence=true.

Почти не влияет на скорость. Включай всегда по умолчанию.

🔵Транзакции

Объединяет чтение и запись в одну неделимую операцию (Read-Process-Write). Если что-то упало - вся цепочка откатится, и дублей в конечном топике не будет.

Настройка: transactional.id + isolation.level=read_committed.

Добавляет задержку (latency). Используй только там, где критичен идеальный порядок.

🔵 Идемпотентность консьюмера

Кафка не знает, что в твоей базе. Если сервис записал данные, но «упал» до фиксации оффсета - кафка пришлет дубль. Поэтому проверяй уникальность ключа на входе в базу.

Пример: INSERT ... ON CONFLICT DO NOTHING в Postgres или SET NX в Redis.

Самый надежный способ, который спасет, даже если настройки кафки не помогли.

🤔Какой следующий вопрос разобрать?

#Kafka #DataEngineering #ITCareer #CareerDE #DataScience

Страшно начинать с нуля 😱

Это первая мысль, когда решаешь уйти из другой сферы или только заканчиваешь универ…

📌Но вот в чём штука — ты и не начинаешь с нуля

Ноль — это когда нет ничего. А у тебя есть: годы учёбы или работы, насмотренность, понимание того, как устроены процессы, люди, системы. Это не обнуляется от того, что ты открыл первый туториал по Python⚠️

Именно прошлый опыт часто становится скрытым преимуществом:

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

Коммуникация
DE — это не только код. Объяснить аналитику, почему данные «поехали», согласовать с бизнесом приоритеты — это добрая половина работы 🍻

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

Внимание к «скучным» деталям
Бухгалтерия, документирование процессов, контроль качества — там, где без проверок нельзя. Этот «занудный» навык в DE превращается в суперсилу 👀

Гибкость в освоении нового
Если ты уже менял роли или сферы, твой мозг умеет перестраиваться. Новый стек, новая терминология уже не шок 🧑‍💻

Опыт работы с документацией
Умеешь читать инструкции, регламенты, стандарты? Значит, разобраться в API, логах и метриках — вопрос времени, а не способностей.

🏫А если ты только из универа?
Учился на экономиста, биолога, физика, юриста — неважно. Ты уже умеешь разбираться в сложных системах, работать с большим объёмом информации и доводить задачи до результата под дедлайн. Это и есть база, на которую ляжет DE.

Твой опыт, абсолютно любой — это актив. Его стоит ценить и использовать!

📱 SQL, Python, облака и оркестрацию выучить можно. А умение не паниковать, когда всё горит, чувствовать бизнес и структурировать хаос — это приходит с опытом, который у тебя уже есть

Если сейчас стоишь перед этим шагом и не знаешь, с чего начать — пиши в личку @ampodvalniy 👋

Расскажешь про свой
бэкграунд, разберём вместе: что уже есть, что нужно подтянуть и как выстроить путь без хаоса👍

📊Ты считаешь ежедневных юзеров, и вдруг DAU (Daily Active Users) подскочил на 25%! Команда празднует вирусный рост, а ты хватаешься за дебаггер ⚠️

Ребята, давно хотел обновить свой роадмап по Data Engineering - и вот наконец сделал. Кстати, на канале появилось много новеньких - привет всем, кто только подписался, вы тут вовремя появились👋

Переписал роадмап под реалии 2026: убрал лишнее, добавил актуальные инструменты, прикрепил ссылки на материалы и вилки по каждому грейду. Получилось объёмно, но по делу.

Если заходите в профессию или думаете куда расти 📈

-> ЧИТАЕМ ТУТ

P.S. Буду благодарен за комментарии и лайки, хотелось бы продвинуть статью😋

Правильный ответ:

Разный grain (считают по заказам, а агрегируют по позициям — строки размножаются) 🔄

Почему это происходит?

Представь, что у тебя есть таблица «Заказы» (где 1 заказ = 1 строка) и таблица «Товары в заказе» (где 1 товар = 1 строка) 📦Если в одном заказе купили 3 разных товара, то при объединении (JOIN) этих таблиц одна строка заказа «размножится» на три

В чем косяк? Если ты начнешь считать сумму продаж по такой «раздутой» таблице, SQL сложит сумму одного и того же заказа трижды 🥲 В итоге в отчете цифры будут гораздо выше реальных (тот самый «взрыв дублей»), хотя на самом деле продаж больше не стало 📉

Как исправить? Нужно сначала «схлопнуть» (агрегировать) данные о товарах до уровня заказа и только потом делать JOIN☑️

Снова увидел S3 в требованиях? Давай раз и навсегда разберёмся

🤔 Часто в вакансиях вижу S3. Решил напомнить (или рассказать тем, кто не знает) - что это вообще такое 👇

S3 (Amazon Simple Storage Service) - если совсем просто, это «бездонная бочка». Гигантский виртуальный склад. Кидаешь туда файл любого типа и размера - и не думаешь, что место кончится.

Как оно устроено?

В отличие от компбютера(файловой системы) где файлы лежат в папках, тут всё плоское. Без иерархий. Вот три основных понятия, которые надо знать:

🪨Объект - сам файл. Картинка, видео, документ, лог. У него есть:
🔘сами данные
🔘метаданные (размер, тип и прочее)
🔘ключ - уникальный адрес, по которому его найдёшь

📦Бакет - контейнер верхнего уровня, куда складываешь объекты. Название бакета должно быть уникальным во всей системе. Вообще всей.

🔑Ключ - полный путь к файлу. Например,

documents/2023/invoice.pdf. 

Вся строка целиком - это и есть ключ. Похоже на папки, да. Но внутри - нет, просто строка.

Почему S3 все так любят?

♾Место не кончается - терабайты, петабайты. Система сама расширяется, когда ты добавляешь файлы.

💰 Дёшево - в 10–20 раз дешевле, чем хранить то же самое в нормальной базе данных или Data Warehouse.

❤️Никуда не денется - данные копируются между серверами и даже между разными городами (дата-центрами). Риск потерять почти ноль.

Но есть и минусы, куда без них

❌ Неизменяемость - объекты нельзя просто «поправить». Хочешь изменить одно слово в текстовом файле? Качай новую версию целиком, перезаписывай старую. Всё заново.

❌ Не для баз данных - S3 медленнее, чем обычный диск. Не подходит для вещей, где данные надо менять мгновенно (например, для работающей базы интернет-магазина).

⏱ Задержки - доступ к файлу может быть медленнее, чем в обычной файловой системе.

А ещё S3 — это фундамент современной аналитики

Его называют «фундаментом» для Lakehouse. На S3 лежат огромные массивы сырых данных в открытых форматах (типа Parquet). А системы вроде Delta Lake или Apache Iceberg превращают эти файлы в удобные таблицы для аналитиков. Красота 🍾

Сделать вам обзор на Delta Lake и Apache Iceberg (или уже 10 раз про них успели прочитать)?