Greenplum: от архитектуры к правильному проектированию таблиц (ч. 1)

Greenplum — MPP-база (в посте выше рассматривали, что это такое и зачем, а также рассмотрели архитектуру GP) , где данные распределяются по сегментам и обрабатываются параллельно.

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

Чтобы этого не происходило, нужно добиваться равномерного распределения данных и оптимальной структуры таблиц. Этого можно достичь с помощью:

*️⃣Дистрибуции — распределения данных по сегментам
*️⃣Партиционирование — деления данных внутри сегмента,
*️⃣Оптимальных типов таблицы и параметров хранения/сжатия.

⚙️ Дистрибуция

Дистрибуция — это метод, по которому данные распределяются между сегментами в GP.
Цель — чтобы объём данных на каждом сегменте был примерно одинаковым.

Если распределение неравномерное (data skew), один сегмент будет обрабатывать больше строк и замедлит выполнение всего запроса.

Основные типы:

HASH (DISTRIBUTED BY ()) — равномерно распределяет данные по ключу (например, client_id) или связке ключей. Это наиболее предпочтительный и при этом автоматический способ дистрибуции: если явно не задать ключ распределения при создании таблицы, Greenplum по умолчанию использует первый столбец таблицы в качестве ключа дистрибуции.

Хэш-дистрибуция позволяет:

*️⃣получить максимальную выгоду при JOIN таблиц без избыточного хранения данных;
*️⃣обеспечить равномерное распределение строк между сегментами;
*️⃣минимизировать перераспределение при запросах.

Используется чаще всего для таблиц фактов и больших объёмов данных.

RANDOMLY (DISTRIBUTED RANDOMLY) — тип распределения, при котором Greenplum сам распределяет строки по сегментам.
Подходит для небольших таблиц или временных данных, когда ключ дистрибуции неочевиден.

Особенности:
*️⃣равномерное распределение по сегментам;
*️⃣теряется выгода при соединениях (JOIN) — система выполняет Redistribute/Broadcast Motion;
*️⃣исключает перекосы данных.

REPLICATED (DISTRIBUTED REPLICATED) — копия таблицы на каждом сегменте.
Отлично подходит для маленьких справочников, но дублирует объём данных.

Особенности:

*️⃣JOIN выполняются максимально быстро, без движения строк между сегментами;
*️⃣удобно для маленьких справочников (dimensions).
*️⃣ главный недостаток - дублирование данных на всех сегментах

💡 Рекомендации по дистрибуции:

1. Явно задавай DISTRIBUTED BY — даже для временных таблиц.
Иначе по умолчанию система возьмёт первый столбец, который вероятно приведет к skew

2. Если нет хорошего ключа — выбирай RANDOMLY.
Также выбирай рандом для финальной таблицы, которая не будет участвовать в join в дальнейшем

3. Не используй для дистрибуции поле часто встречающееся в WHERE.
Иначе при запросах данные будут перераспределяться по сегментам → падение производительности.

4. Избегай типов date и datetime + выбирай integer вместо string для дистрибуции.
Для первых хэш вычисляется долго + для str аналогично

5. Лучший ключ дистрибуции — тот, что участвует в JOIN ON.
Это минимизирует motion и делает запросы стабильнее.

@data_driven_bogdan

Greenplum: от архитектуры к правильному проектированию таблиц (ч. 2)

🧱 Партиционирование

Партиционирование — это разделение таблицы на логические части (партиции) внутри каждого сегмента по определённому признаку (чаще всего — по дате). Такое деление позволяет ускорить запросы, снизить нагрузку на диск и упростить администрирование данных.

Зачем нужно партиционирование

*️⃣Ускоряет аналитику — при фильтрации по WHERE Greenplum читает только нужные партиции, а не всю таблицу.
*️⃣Снижает нагрузку на сегменты — не происходит полного сканирования таблицы, читаются только нужные диапазоны.
*️⃣Упрощает сопровождение — можно быстро удалить или архивировать старые данные, не трогая актуальные.
*️⃣Изолирует данные по периодам — удобно для построения витрин с логикой «по месяцам» или «по кварталам».

Принцип и пример:

При указании фильтра WHERE Greenplum читает только нужные партиции, а не всю таблицу.

SELECT *
FROM dm.xyz
WHERE datetime BETWEEN '2025-04-01' AND '2025-06-30';

Если таблица партиционирована по datetime, будет прочитан только 2 квартал, а не весь объём.
Это значительно снижает время выполнения запроса, особенно при миллионах строк данных.

🧩 Как пользоваться партициями:

Узнать ключи партиционирования:

SELECT *
FROM pg_catalog.pg_partition_columns
WHERE schemaname = 'dm'
AND tablename = 'xyz';

Проверить, что запрос использует нужную партицию - через EXPLAIN перед запросом:

EXPLAIN
SELECT *
FROM dm.xyz
WHERE datetime BETWEEN '2025-04-01' AND '2025-06-30';

Если всё корректно, в плане запроса будет видно, что используется только выбранный диапазон партиций.

Добавить или удалить партицию:

ALTER TABLE dm.xyz ADD PARTITION p202507 START ('2025-07-01') END ('2025-08-01');
ALTER TABLE dm.xyz DROP PARTITION p202301;

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

💡 Советы по проектированию партиций:

1. Партиционируй таблицы фактов — это основной кандидат для деления по дате.

2. Не делай слишком мелкие партиции (например, по дням) — это создаёт избыточные метаданные и замедляет DDL-операции.

3. Оптимальный уровень — по месяцам или кварталам.

4. Используй фильтры в WHERE по ключу партиционирования — иначе Greenplum не сможет исключить ненужные партиции.

5. Для небольших справочников (dictionary tables) партиционирование избыточно — оно не ускорит запросы, но усложнит структуру.

@data_driven_bogdan

Greenplum: от архитектуры к правильному проектированию таблиц (ч. 3)

🧩 Типы таблиц в Greenplum

1. Heap (row storage)
Это классический тип таблиц, унаследованный от PostgreSQL.
Данные хранятся построчно — каждая запись (row) хранится целиком, что делает работу с отдельными строками быстрой, но аналитические запросы медленнее.

Используется для:

*️⃣небольших таблиц (до ~300 тыс. строк или до ~100 MB);
*️⃣таблиц, где часто происходят операции UPDATE, DELETE, INSERT;
*️⃣задач с OLTP-нагрузкой (операционные системы, логирование, промежуточные буферы).

2. Append-Optimized (AO)
AO — это оптимизированный под аналитику формат хранения, доступный только в Greenplum.
Такие таблицы предназначены для OLAP-нагрузки, где данные в основном читаются, а не обновляются.

AO-таблицы позволяют:
*️⃣экономить место за счёт сжатия (compresstype и compresslevel);
*️⃣ускорять аналитические запросы, т.к. считываются только нужные колонки (orientation = column);
*️⃣эффективно работать с батчевыми вставками (INSERT пакетами).

Пример создания оптимальной таблицы:

CREATE TABLE schema.table_name
WITH (
appendonly = true, -- таблица только для добавления (без UPDATE/DELETE)
orientation = column, -- колоночное хранение (эффективно для аналитики)
compresstype = zstd, -- алгоритм сжатия Zstandard
compresslevel = 4, -- уровень сжатия (оптимальный баланс скорость/размер)
blocksize = 32768 -- размер блока в байтах (кратно 8192)
)
DISTRIBUTED BY (client_id); -- ключ дистрибуции по клиенту

💡 Best Practices для таблиц в Greenplum

1. Сжимай данные.
Компрессия (zstd, compresslevel=4) сокращает занимаемое место в хранилище при минимальном влиянии на производительность.

2. Используй колоночное хранение для аналитики.
Greenplum — OLAP-система, и колоночные таблицы значительно ускоряют агрегации и фильтрацию.

3. Heap — только для частых обновлений.
Для оперативных таблиц с частыми UPDATE/DELETE используйте Heap. Для аналитических витрин — AO.

4. Не смешивай типы хранения в одной цепочке.
Факт-таблицы делай AO, справочники — Heap или AO column (если редко обновляются).

5. Обновляй статистику (ANALYZE) после загрузки данных.
Это поможет оптимизатору правильно оценивать стоимость запросов.

Итого

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

Пишите в комментариях вопросы/замечания/что понятно, а что нет👇

@data_driven_bogdan

Топ-10 SQL вопросов, которые точно спросят на собесе (уровень junior)

Без практики не обойтись, но теорию не забываем

1️⃣Порядок выполнения SQL-запроса

FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT

💡 Поэтому WHERE не видит алиасы из SELECT.

2️⃣ WHERE vs HAVING

*️⃣WHERE — фильтрует строки до группировки
*️⃣HAVING — фильтрует после GROUP BY

Пример:


SELECT city, COUNT(*)
FROM users
WHERE age > 18
GROUP BY city
HAVING COUNT(*) > 10;

3️⃣ Виды JOIN-ов (логические)

JOIN — это оператор, который объединяет строки из двух таблиц по общему полю (ключу), чтобы получить связанные данные в одном наборе.

*️⃣INNER — только совпавшие
*️⃣LEFT — все из левой
*️⃣RIGHT — все из правой
*️⃣FULL — всё подряд

Таблицы склеиваются в "ширину"

4️⃣ UNION vs UNION ALL

UNION (/ALL) — это оператор, который склеивает таблицы вертикально, то есть добавляет строки из одной таблицы под строки другой. Главное — структура (кол-во и типы столбцов) должна совпадать.

UNION — объединяет вертикально и убирает дубли
UNION ALL — объединяет вертикально и оставляет все записи

💡 UNION ALL быстрее, UNION безопаснее, когда хочешь избавиться от повторов.

5️⃣ Как убрать дубликаты?

DISTINCT vs GROUP BY vs ROW_NUMBER() = 1

✅ DISTINCT — просто убрать дубли на уровне строк

SELECT DISTINCT user_id FROM orders;

✅ GROUP BY — группировать по колонке, где требуется оставить уникальные значения


SELECT user_id, COUNT(*) FROM orders GROUP BY user_id;

✅ ROW_NUMBER() — когда дубли одинаковы не по всем полям и нужно выбрать одну по выбранному признаку

SELECT *
FROM (
SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC) AS rn
FROM orders
) t
WHERE rn = 1;

.
6️⃣ DELETE vs TRUNCATE vs DROP

DELETE - Удаляет строки (можно с условием where), можно откатить
TRUNCATE - Удаляет все строки (быстро, без условий)
DROP - Удаляет таблицу целиком

7️⃣ Подзапрос vs CTE

Подзапрос — быстро и локально, когда нужно одно промежуточное значение:

SELECT user_id
FROM orders
WHERE order_date = (
SELECT MAX(order_date)
FROM orders o2
WHERE o2.user_id = orders.user_id
);

💡Минус — код тяжело читать и отлаживать, особенно если вложено несколько уровней.

CTE (WITH) — удобно для пошаговых расчётов и чистого кода:

WITH last_orders AS (
SELECT user_id, MAX(order_date) AS last_dt
FROM orders
GROUP BY user_id
)
SELECT u.user_name, l.last_dt
FROM users u
JOIN last_orders l USING(user_id);

💡 CTE проще дебажить, можно переиспользовать, выглядит как «story» запроса.

8️⃣ Оконные функции
Позволяют считать агрегаты без потери строк 👇


SELECT
user_id,
SUM(amount) OVER (PARTITION BY user_id) AS total_spent,
COUNT(*) OVER () AS total_rows
FROM payments;

💡 GROUP BY схлопывает строки, а OVER() просто добавляет новые расчётные поля.
Например, можно посчитать долю:


SUM(amount) OVER (PARTITION BY category) / SUM(amount) OVER () AS share

9️⃣RANK vs DENSE_RANK vs ROW_NUMBER

Оконные функции, которые:

ROW_NUMBER() - Просто нумерует строки
RANK() - Пропускает номера при одинаковых значениях
DENSE_RANK() - Без пропусков, ранги идут подряд

🧩 Пример:
Зарплаты — [100, 90, 90, 80]

ROW_NUMBER - 1,2,3,4
RANK - 1,2,2,4
DENSE_RANK - 1,2,2,3

1️⃣0️⃣ Работа с NULL в SQL

NULL — это не значение, а отсутствие данных.
Он не равен ничему, в том числе другому NULL.

Фильтровать можно только так:

WHERE col IS NULL
WHERE col IS NOT NULL

а не = NULL или != NULL.

💡 Важно помнить:

*️⃣COUNT(col) игнорирует NULL,
*️⃣COUNT(*) — считает всё,

Также в арифметике 5 + NULL = NULL, в таком случае для подстановки значения используйте функцию COALESCE() для подставки 0 или 'tbd'.

Добавил бы что-то в этот список базированных вопросов? Пиши в комменты

@data_driven_bogdan

Как оформить резюме (уже не только опыт) (Ч.2)

Продолжаем рубрику оформления резюме.
В прошлой части разобрали основной блок — опыт работы, теперь возьмемся за остальные части.

1. Релевантность опыта

*️⃣Не отходя от кассы с опытом отмечу важный поинт - релевантность опыта. Оформляем резюме конкретно под вакансию: собесимся на продуктового аналитика — делаем отдельное резюме под ПА, с уклоном в опыт с A/B-тестами; на ДЕ — акцент на архитектуру и ETL, и так далее.

*️⃣Опыт работы также должен соответствовать вакансии (никаких практикантов, менеджеров по планированию и т.д.).

*️⃣Нерелевантный опыт либо удаляем, либо переигрываем под нужную нам вакансию.

2. Контакты

*️⃣Для РФ указываем Москву — повышаем шанс найти вакансию, т.к. больше предложений.
Возраст не указываем — чтобы не натолкнуться на эйджизм.
С зарплатой и должностью уже разобрались в прошлых постах.

3. Блок «О себе»

*️⃣Коротко о себе в рамках вакансии — крутой ДЕшник, работал в X сферах, потрогал Y стек ищу команду/компанию, где можно развиваться в Z.

Пример:

Data Engineer с опытом построения ETL-пайплайнов и моделирования DWH в ритейле и финтехе.
Работал с Airflow, Kafka, Greenplum, ClickHouse, dbt, Docker.
Ищу команду, где можно развивать архитектурные решения и оптимизацию потоков данных

*️⃣Не забываем в данный блок добавлять контакт для связи — Telegram / номер телефона, дабы повысить конверсию.

telegram: @...
phone: +79....

*️⃣Также на hh есть отдельный блок «Контакты – комментарии», куда можно тоже написать tg, но часто HR долбятся в глаза, поэтому дублируем в блоке «О себе» тоже.

4. Навыки

*️⃣Указываем по максимуму хард-скиллы и стек — релевантные под вакансию и рынок (что писать, если не знаешь, обсуждали в посте выше). На hh максимум можно указать 30 навыков — используй это место по максимуму.

4. Курсы

*️⃣Тут много споров - я не пишу полотно курсов, только качественные и, если все таки есть желание их написать, то основную массу советую ставить в даты старта карьеры.

Резюме — это не просто документ, а инструмент продаж твоего опыта/тебя как специалиста.

Если есть вопросы по составлению резюме или его адаптацией под DA/DE — пиши в личку, посмотрим, где можно усилить формулировки и добавить импакта.

А сколько версий резюме у тебя сейчас — одно универсальное или под каждую вакансию отдельное?

@data_driven_bogdan

Теория о данных.

Безопасность и управление данными — Ч.1

🔐 Безопасность данных

Безопасность — это не “чужая зона ответственности”, а часть профессии каждого, кто работает с данными.

Если ты проектируешь пайплайны, делаешь отчеты, настраиваешь интеграции— ты тоже отвечаешь за то, кто, как и когда имеет к ним доступ.

P.S. На практике, конечно, матрица ответственности в каждой компании своя:
где-то контроль доступов лежит на ИБ и DevOps, где-то — на владельцах доменов данных, где-то распределён между инженерами, администраторами и data stewards. Но независимо от формальных ролей, все, кто работает с данными, находятся на стыке технологий и ответственности: он первый, кто может предотвратить риск, и часто последний, кто видит его последствия.

Главные принципы:

1️⃣ Минимальные привилегии.
Дай ровно столько доступа, сколько нужно — и только на время задачи.
“На всякий случай” = источник инцидента.
Работа с суперпользовательскими ролями ради SELECT-запросов, создаёт не гибкость, а дыру.

2️⃣ Безопасность во времени.
Доступ должен быть временным.
В зрелых системах права отзываются автоматически, ключи истекают, а доступы согласуются.

3️⃣ Люди — главный риск.
Большинство утечек — не от взломов, а от человеческих ошибок: фишинг, общий доступ, халатность.
Первая линия обороны — культура безопасности, а не технологии.

4️⃣ Защита на всех этапах.
Данные нужно шифровать и при передаче, и при хранении.
Маскирование, токенизация, аудит действий и контроль видимости — стандарт, а не “доп. опция”.

5️⃣ Понимание IAM.
Любой специалист, работающий с данными, должен понимать роли, политики, пароли, сетевые права и ключи доступа. Без этого невозможно построить безопасную и масштабируемую экосистему данных.

📌 Суть проста: безопасность = доверие.
Если данные не защищены, вся аналитика теряет смысл.

🧭 Управление данными

Data Management — звучит корпоративно, но по сути это просто способ сделать данные понятными, надёжными и согласованными между командами.

Ключевые направления:

1️⃣ Data Governance (руководство данными)

Это не про документы, а про согласованность людей, процессов и технологий вокруг данных.
DG определяет, кто владеет данными, как они определяются, как контролируются доступы и как обеспечивается их качество. Когда DG нет — появляются “серые зоны”: дубли, противоречия, отчёты, которым никто не верит, и вечные “откуда эти цифры?”.

DG включает в себя роли (Data Owner, Data Steward), политики, контрольные процедуры и технические инструменты (каталоги, lineage, data contracts).

На практике же в крупных компаниях часто есть отдельно выделенная ставка под stewardship, к которому можно заходить по вопросам данных/их качеству/происхождению и тд.

2️⃣ Изучаемость (Data Discoverability) и подотчётность (Accountability)

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

Data Governance. Изучаемость достигается через data catalogs, документацию, lineage, и систему data stewardship, где за каждый домен отвечает конкретный человек.
Примеры дата каталогов - OpenMetaData/ dbt docs

3️⃣ Metadata Management — управление метаданными

Метаданные — это нервная система платформы.
Они обеспечивают прозрачность и повторное использование данных.

Они бывают четырёх типов:
*️⃣Бизнес-метаданные: определения, владельцы, правила, контекст.
*️⃣Технические: схемы, data lineage, ETL-логика, связи между объектами.
*️⃣Операционные: логи, job ID, SLA, статусы процессов.
*️⃣Справочные: коды, классификаторы, единицы измерения.

Хорошая Metadata Management System связывает инженеров и бизнес: автоматически собирает lineage, но сохраняет человеческий контекст.

Продолжение...

@data_driven_bogdan

Теория о данных.

Безопасность и управление данными — Ч.2

4️⃣ Data Quality Management — управление качеством данных
Качество — это не абстракция, а чёткий набор характеристик:

*️⃣Accuracy (точность),
*️⃣Completeness (полнота),
*️⃣Timeliness (своевременность).

Проверка качества должна быть частью пайплайна: тесты данных, SLA и мониторинг аномалий.
“Проверим потом” = потеря доверия к платформе

5️⃣ Master Data Management (MDM)

MDM отвечает за согласованность “основных сущностей”: клиентов, продуктов, контрагентов, филиалов.
Это система и процесс, создающие “золотые записи” (Golden Records) — единые определения для всей организации.

MDM устраняет расхождения между системами и делает возможным единый аналитический контур: CRM, DWH и отчёты работают с одними и теми же объектами.

MDM всегда завязан на бизнес — именно он определяет, что считается «основными данными». Например, для ритейла это может быть каталог товаров и магазинов, для банка — клиенты и счета, для логистики — маршруты и склады.

📌 Управление данными делает платформу предсказуемой.
Без него каждый отчёт — гадание на данных, где никто не уверен, откуда взялись цифры и можно ли им верить.

📚 Главные выводы

*️⃣Безопасность — часть инженерного мышления.
*️⃣Управление данными — способ сохранить смысл данных.
*️⃣Метаданные — память платформы.
*️⃣MDM — источник единой истины.

С этими практиками работа с данными становится системной, а не хаотичной.

📘 Пост основан на книге «Основы инженерии данных»
Разбираем первый два блока из схемы “Основные фоновые процессы жизненного цикла инженерии данных”.

А как в вашей компании устроены процессы безопасности, управление качеством и MDM❓👇

@data_driven_bogdan