[2/2] Обеспечение качественных ETL на Vertica - Александр Крашенинников - SmartData 2023 (Рубрика Architecture)

В первый пост по этому докладу не поместились все практические советы Саши, поэтому продолжим

Для построения аналитики стоит построить OLAP куб с компонентами

• Измерения: время, учетная запись, ресурсная группа, узел кластера
• Показатели: sum/skew/avg/q50/q75/q90/q99 по метрикам запросов
• Время: CPU, общее время
• RAM
• Объемы данных: чтение/запись по диску, чтение/запись по сети
• Число запросов
• COST

Ну а дальше работа с дефектами - когда проблемы имеют схожие паттерны, которые можно разделить на

• Статические - данные лежат спокойно, но больно станет, когда придется с ними работать (таблицы, колонки)
• Динамические - это уже сейчас работает не оптимально (запросы и последовательности запросов)

Статические дефекты данных

• Хранение и обработка текстовой информации в VARCHAR - если мы просим VARCHAR(2048), а пишем туда 2 символа, то мы имеем доп накладные расходы, а при использовании UDF (user defined functions) мы действительно будем занимать все 2kb даже если напишем 2 символа
• numeric с управлением точности числа - больше точность, больше места на диске, а при несовпадении типов у нас тратится CPU и RAM на их приведение. Обычно хватает numeric(18, 4) в 90% случаев (что занимает места как int64)
• Сортировка - важно сортировать по меньшему полю + слишком много полей для сортировки может быть ошибкой
• Распределение данных (шардинг) - шардинг по меньшему полю + правильное использование несегментированных таблиц. Использование сегментации по float может быть ошибкой (из-за плавающей точности и распределения близких значений по разным нодам)
• Партиционирование - по правильному полю + большое партицируем на не слишком много партиций, если маленькое, то не партицинируем
• Перекос данных - перекошенные данные тормозят все запросы, надо с перекосами бороться. Саша показывает как это делать с NULL полями
• И еще куча проблем

Динамические дефекты данных

• Динамические дефекты данных могут быть связаны с уязвимостями и "дурным запахом" в уже работающих запросах.
• Например, если запрос генерирует много временных данных, это может быть признаком ошибки, и запрос может быть отстрелен рано или поздно.
• Если запрос передает много данных по сети, это также может быть признаком ошибки, и запрос может быть отстрелен за это.
• Если запрос обновляет данные в ходе выполнения, и это превышает определенный размер, это может быть признаком ошибки, а запрос может быть оптимизирован для использования инкрементального обновления.

Оптимизация запросов

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

Проблемы с производительностью

• Объем временных данных на одном узле может вызвать проблемы с производительностью.
• Неявные коммиты и множественные sql инструкции могут вызвать ошибки и false positive.
• Важно обучать пользователей правилам игры и границам дозволенного.

Выводы

• Квотируйте ресурсы на самом старте
• Обозначайте правила игры с базами данных и границы дозволенного
• Обучайте пользователей - документаци, воркшопы, ...
• Собирайте аналитику по деятельности процессов
• Не бойтесь отстреливать проблемные процессы
• Создавайте прозрачность для пользователей про показатели их процессов

#Data #DWH #Processes #Management #Architecture #Software #SoftwareArchitecture