Поздравляю всех с Днём Знаний! Внимание вопрос! Почему в Москве 22°, в Казани 27°( а по ощущениям 33). Города на одной параллели

Что не так с лавочкой в Иннополисе?

Друзья, сегодня у меня был незабываемый День Знаний в Иннополисе. На память, предлагаю повеселиться, включаем фантазию - продолжите фразу в контексте того, чем занимаетесь на работе, а я дам версию со стены предсказаний (где их 365 под QR кодами) в технопарке А.С.Попова,что в Иннополисе : Кто рано встаёт..

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

И вот тут мне не даёт покоя тот факт, что динозавры появились 200 млн назад, а машина Тьюринга в 1936, но какой прогресс уже в развитии ИТ зоопарка, и в части концепций, и в части ДНК, на которых они реализованы

Greenplum: динозавр или рабочая лошадь в 2025

Greenplum - это движок, который долгое время был символом корпоративной аналитики.
В эпоху, когда Hadoop только взлетал и все мечтали о дешёвом "data lake", именно Greenplum давал то, чего так не хватало: SQL, транзакции и ACID.

🏦 В банках и телекоме это был настоящий game changer. Hadoop клал файлы и костылял через Hive без транзакций. Greenplum же позволял писать надёжные аналитические запросы, жить в SQL и быть уверенным в консистентности данных. Именно поэтому десятки проектов в 2010-х поднимались на Greenplum.

Что с ним сейчас
⚙️ Архитектура MPP по-прежнему рабочая;
🖥 Кластеры в проде до сих пор крутятся и обслуживают критичные процессы;
⛔️ Хайпа давно нет, а новые проекты почти не появляются;

Уже даже на data конференции 2 и 3 сорта, не приходит тот самый чел в сером в пиджаке, который рассказывает, как они «подняли хранилище на 200 ТБ и все офигели».😁

В конце 2023 Broadcom (после покупки VMware) фактически заморозила основную open-source ветку. Комьюнити жаловалось на редкие релизы и мёртвые пулл-реквесты, и теперь Greenplum в OSS-смысле выглядит как пациент в коме: вроде жив, но движения нет.

🚀 Modern Data Stack уже уехал
-Lakehouse решили вопрос ACID через Delta, Iceberg, Hudi
-Cloud-first модели с pay-as-you-go съели рынок
-Экосистема вокруг Icebrg, Airflow, Trino даёт гибкость и скорость, которой у Greenplum нет
-Интеграция с ML/LLM? Почти нулевая

За последний месяц у меня было несколько встреч с основными облачными провайдерами на нашем рынке. И никто из них не планирует в дальнейшем развивать этот продукт как часть их экосистемы.

❓Вопрос на 2025

Greenplum будет жить - потому что миграция с него стоит дорого, а бизнес не любит рисковать. А еще есть arenadata в РФ, которая успела подсадить больших корпов и госы на свой проприетарных GP и отказаться от него теперь очень сложно и дорого.
Но новые проекты? 🤔 Серьёзно, кто сейчас сознательно выберет Greenplum для старта?

Greenplum однажды сделал шаг в будущее раньше Hadoop — дал ACID там, где были только костыли. Но теперь сам остался в прошлом: закрытый OSS, стагнация и потерянный тренд.

У меня только 1 вопрос к автору - а реально есть MPP аналог, такой же удобный, с полным Тьюрингом в режиме компилятора ( а не интерпретатора), интеграцией а-ля PXF с половиной МИРА, партициями, сжатием и все это в одном флаконе?

Решение теста выше: Solution of the test above
Как ни странно, запрос 1 кратно лучше, почти на порядок.
Что интересно, если t1 распилить на 2 отдельные таблицы, то в таком варианте дихотомии имеем в среднем выигрыш ~75% ( см. distinct_bench_single_vs_split.txt, 2 прогона).
Но в случае распила с партициями(что есть более жизненный сценарий, кмк), даже если они используются в запросе 2 явно в виде физических таблиц в плане появляется сортировка,
которая сьедает львиную долю run-time ( см. distinct_bench_single_vs_split_partitioned.txt).
Увы, этот самый external merge появляется даже при отборе уникального сета из одной таблицы-партиции.
⁉️А если взять CTE, на которую накинуть DISTINCT ? - болт, результат(план) тот же.
Ума не приложу, зачем так сделано, но реальность 6-ки пока такова.

Oddly enough, query 1 is significantly better, almost an order of magnitude.
Interestingly, if t1 is split into two separate tables, this dichotomy solution yields an average performance gain of ~75% (see distinct_bench_single_vs_split.txt, two runs).
But if partitions are used (which is a more realistic scenario, in my opinion), even if they are explicitly used in query 2 as physical tables, the plan adds a sort,
which eats up the lion's share of runtime (see distinct_bench_single_vs_split_partitioned.txt).
Unfortunately, this same external merge occurs even when selecting a unique set from a single partition table.
⁉️But what if we use a CTE with DISTINCT? Doesn't matter, the result (plan) is the same.
I can't imagine why this was done, but this is the reality of the v6.

📌Собственно, за пререквизиты брал
Actually, I took it as a prerequisite
t1:
tst_100bln_dk - сет из 100 млрд чисел int4 в диапазоне 1..1 000 000 // a set of 100 billion int4 numbers in the range 1..1,000,000

t2:

create table tst_100bln_dk_part_by_n
    (n int, prt_mod int)
WITH (appendonly=true,orientation=column,compresstype=zstd,compresslevel=1)
distributed by (n)
    partition by list(prt_mod)
(partition p0 values (0),
partition p1 values (1),
default partition other);

-- Заполняем чет/нечет партиции по условию prt_mod = mod(n,2) :
-- Fill the even/odd partition according to the condition prt_mod = mod(n,2):

insert into tst_100bln_dk_part_by_n
    select n, (n & 1)
from tst_100bln_dk

Файлы // Files

Секрет 41 ( Доверяй, но проверяй: нюанс сбора статистики в партициях )
Оказия случилась с опросом выше, благодаря которой родился новый секрет, для тех, кто не зациклен на чтении документации.

Собственно, выявлена неожиданная особенность в 6ке,
gp_autostats_mode = on_no_stats не тригерит сбор статы в партицированой таблице, в которую вносим данные:

For partitioned tables, automatic statistics collection is not triggered if data is inserted from the top-level parent table of a partitioned table.
 
But automatic statistics collection is triggered if data is inserted directly in a leaf table (where the data is stored) of the partitioned table.

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

Таким образом, корректный ответ в опросе:2, мудрость толпы восторжествовала!
🔥Респект @alias cd='rm -rf ', заметившему брешь в моей логике и @Василий Антонов, подсветившему, что
такое поведение gp_autostats_mode в рамках документации.

В итоге, выигрыш от бисекции DISTINCT-а составил 36% по результатам 2х прогонов. ( расчет в файле ниже )
Подумаю, не запатентовать ли сию оптимизацию.

Secret 41 (Trust, but verify: the nuance of collecting statistics in partitions)
An unfortunate incident with the survey above gave birth to a new secret, for those who aren't fans of reading documentation.

A specific issue was discovered in version 6:
gp_autostats_mode = on_no_stats doesn't trigger stats collection in the partitioned table into which we insert data.

For partitioned tables, automatic statistics collection is not triggered if data is inserted from the top-level parent table of a partitioned table.
 
But automatic statistics collection is triggered if data is inserted directly in a leaf table (where the data is stored) of the partitioned table.

This is precisely what led to my false conclusion, because, being certain that
stats were collected in partitions due to the parameter above, I compared an object with stats to an object without stats.

Therefore, the correct answer is 2; the wisdom of the crowd has triumphed!
🔥Kudos to @alias cd='rm -rf' for spotting a flaw in my logic, and to @Vasily Antonov for pointing out that
this behavior of gp_autostats_mode isn't a bug.

In the end, the gain from DISTINCT bisection was 36% based on two runs (calculations in the file below).
I'll consider patenting this optimization.

К секрету 41 // for Secret 41

Вопрос 5
#никогда не было и вот опять!
Создаю в 6ке вью v на табл-у t - делаю select * from v => permission denied for relation t
select * from t проблем не вызыввает.
drop + снова Создаю вью v на табл-у t ( идентичной командой под тем же пользаком ) - select * from v отработал.
Что это было ?

И снова здравствуйте!
Дам мой комментарий к опросу выше, если это поможет тем, кто еще не определился.
Если кратко, у каждого будет свой ответ исходя из сценария использования ХД

Итак, основываясь на тестах, которые свел в отчет, видим.
В каждом тесте использовалась одна и та же таблица "document" из 10 млр строк (S), равномерно распределенных по полю doc_date в интервале 2000 - 2025 гг с ключом doc_rk,
в которой менялась только схема партицирования, определяемая 2 параметрами - числом партиций на каждом уровне и числом уровней партицирования ( max 2 )
Отдельная строчка на каждой из 8 вкладок отчета ниже представляет отдельный тест.

В рамках теста на select (вкладки вида %select) использовался эталонный запрос
на отбор документов по диапазону дат + фильтр на источник, из которого загружен документ), извлекающий 7 млн строк:

select * from S 
 where doc_date between '2021-01-01'::date and '2022-08-23'::date 
   and src_cd = 'foo'

В рамках теста на insert (вкладки вида %insert) подготовленная эталонная AOCO (без партиций) таблица "document_snap" переливалась в "document" через Insert as select с сохранением ключа
AORO - Append Only Row Oriented секционирована либо по дате док-та (1 level в названии вкладки), либо по дате док-та + SRC_CD (2 levels )
AOCO - Append Only Column Oriented секционирована либо по дате док-та, либо по дате док-та + SRC_CD

Параметр max_appendonly_tables = 10 000
Число сегментов кластера - 348.

Какие выводы можно сделать, изучив отчет ?
📌
Для операции select влияние числа партиций несущественно
Для одноранговых партиций ( все вкладки вида %1 level%) число партиций не влияет на скорость select, либо это влияние имеет место в пограничных случаях ( когда
число партиций близко к max_appendonly_tables (вкладка AORO, 1 level, select), либо когда число партиций близко к пределу, который определяется как
max_appendonly_tables, так и числом колонок таблы (см. AOCO,1 lvl, select).
Что касается 2х уровнего партицирования, влияние числа партиций практически отсутствует за исключением граничных случаев для строчной таблы (AORO, 2 levels, select)
📌
Для операции insert влияние числа партиций на перформанс запроса статистически значимо, т.е. прослеживается корреляция как между числом партиций в целевой таблице N
и временем выполнения запроса,
так и между средним потреблением RAM ( напр. AOCO, 1 lvl, insert, поле avg_mem_used_in_gb_per_segment ) и N.
К слову, случаи avg_mem_used_in_gb_per_segment < 0 - это баг 6ки, когда план запроса генерим в JSON формате ( на которых построен отчет ), но Аренадата уже фиксит.

p.s.
Для тех, кому нужно больше подробностей, напомню про