О каталоге Greenplum (2)

Начало

Какая мораль у этой статьи про распухшие каталоги Гринплама.

Следите, следите и еще раз следите за вашим каталогом!

Бытовые рекомендации.

1️⃣Объем pg_catalog и его динамику - на мониторинг если еще не.

2️⃣Не жестите с параллелизмом сегментов. 2-3 праймари на большую ВМ или даже железный сегмент-сервер вполне ОК. Эта же рекомендация поможет легко проглатывать пики параллелизма нагрузки и упростит настройку ресурсных групп.

3️⃣Не жестите с партициями. Схлопнуть где-то партиции с дня до месяца - это нормально и оправдано. Проще где-то поднять лишние данные с дисков сегментов в некоторых запросах, чем нагружать каталог на мастере, который нужен при вообще каждом запросе

4️⃣Вакуум таблиц каталога - первейшая задача. А также реиндексы и т.д. Это тяжелая операция, которая блокирует кластер, поэтому многие ее не делают - неудобно и пользователи негодуют. Но надо!

5️⃣ETL, где по любому чиху работают с партициями на удаление/замену, сильно нагружает каталог. pg_attribute все еще постгресовая таблица, подверженная блоату и расдуванию индеков. А вы из нее удаляете-добавляете строки сотнями на каждый чих. Просто сделайте Trucate insert и не мучайте беднягу. То же с созданием и удалением различных временных объектов.

6️⃣Мелкие таблицы проще сделать строчными, а не колоночными. То же и со временными. Будет одна запись на таблицу, а не на колонку таблицы.

Инсайты из рассказа Дмитрия Реймана (Авито) о Трино

Доклад: Trino 2 года спустя

Инсталляция

1️⃣2 года назад начата миграция из Вертики в Трино

2️⃣Разделение Compute - Storage на сервисах Trino + Ceph. Суммарно 15 кластеров Трино

3️⃣Данные поднимаются по протоколу S3 из Ceph. Формат данных ORC.

4️⃣Канал: теоретический пик 80 Гбайт/сек, реально достижимое значение 40 Гбайт/сек. В один запрос может разогнаться до 10 ГБайт/сек.

5️⃣Все новое создается в Trino уже сейчас.

6️⃣Нагрузка 50/50 Vertica / Trino

7️⃣Нагрузка от Trino в сторону Ceph - топ-1 из всех потребителей Ceph. Не все цефовцы это любят.

8️⃣Потребовалась конфигурация Ceph с выносом метаданных на NVMe диски


Нагрузка

1️⃣300 потребителей Ad-Hoc

2️⃣1 ПБ / день обрабатывается в Трино

3️⃣Свой оркестратор на 100к+ задач в день


Советы

1️⃣Всем кто строит Лейкхаус обязательно провести нагрузочный тест на Troughput от вычисления до хранения.

2️⃣(ТОП СОВЕТ) В архитектуре ETL действует правило - максимальная длина джоба = 1 час

3️⃣(ТОП СОВЕТ) Также в архитектуре любого потребителя данных DWH - обязательный retry.

4️⃣Pandas to_sql - боль 🙂


Trino

1️⃣Голое Trino - не воин. Придется развернуть или дописать многое вокруг.

2️⃣fs.cache.enabled = true - включение локальных кешей в Трино (с 439 версии).

3️⃣Hive Metastore хоть и легаси, но используется для больших данных. Iceberg для относительно маленьких потребителей, где важна консистентность. Hive движок для Trino как будто чуть более оптимизирован по сравнению с Iceberg. Hive любит делать лишние листинги в объектный Storage, когда оно не нужно, что убивает S3.

4️⃣SDK Trino очень развитый. Авито используют для написания собственных движков чтения SQL. Также можно написать свои обертки для API, специфических БД в таблицы.

5️⃣ETL / ELT в Trino для 6NF (!) - ок! По крайней мере не хуже Вертики.

6️⃣Написали свой Trino Catalog для метаданных

7️⃣Иногда падает Трино Координатор. Но быстро восстанавливается, так как Stateless

Доклад тут