Лучшие способы убить производительность аналитической СУБД
В основе современных аналитических СУБД и распределённых систем обработки данных лежит ряд ключевых принципов. Если Инженер Данных сможет постичь их суть и успешно использовать, то он постигнет дзен, обретёт спокойствие и уверенность в завтрашнем дне.
Эти принципы формулируются предельно просто: • параллельная обработка; • оптимальное хранение данных (согласно сценариям использования); • управление ресурсами и группами пользователей; • резервирование и репликация данных; • мониторинг производительности и своевременное устранение проблем.
Ниже приведены распространённые способы нарушить эти принципы и тем самым свести преимущества таких систем к нулю.
1. Лишить возможности производить вычисления параллельно
Всё равно, что отказаться от основного принципа работы с большими данными. Чтобы обеспечить параллельную обработку, данные должны быть распределены равномерно между узлами (нодами, воркерами и т. д.). Скорость обработки данных в такой системе будет равна скорости самого медленного из её элементов. И вы чётко увидите это при возникновении узких мест (bottlenecks).
2. Заставить узлы (ноды) обмениваться большими объёмами данных по сети
Недостаточно только распределить данные равномерно, необходимо обеспечить максимальную локальность выполнения операций на узлах кластера. Это соединения (JOIN), группировки (GROUP BY), аналитические функции. Кто сказал Map Side Join? Для этого нужно знать (или хотя бы предполагать), как ваши данные будут использоваться (предикаты для WHERE, JOIN ON, колонки для GROUP BY и т. д.).
3. Постоянно обрабатывать лишние объёмы данных
Тождественно расходованию драгоценных ресурсов впустую. Чтобы читать только набор данных, максимально приближенный к запрашиваемому, данные можно упорядочить (отсортировать) и поделить на секции (партиции).
4. Предоставить карт-бланш на доступ к ресурсам
В рамках кластера действует несколько групп пользователей и процессов, обладающих разными приоритетами. Если один пользователь или процесс съест все ресурсы системы, остальные не получат ничего.
5. Забыть про сжатие данных
Цитата одного из визионеров систем аналитики: «If you aren't compressing your tables, you are simply leaving money on the table». Существует множество алгоритмов и подходов: Algorithmic (LZO), Multi-value (Bitmap), Encoding (Delta range). Порой можно достичь коэффициентов сжатия в 10-100 раз по сравнению с сырыми данными.
6. Подвергнуть OLTP-нагрузке
Нужно помнить, что аналитические системы не предназначены для частых и точечных операций UPDATE, DELETE. Такая нагрузка будет тратить ресурсы впустую. Подходы к организации таких операций различны, вплоть до разделения на 2 зоны: для записи (Write Optimized) и для чтения (Read Optimized). И порой дешевле удалить и записать заново весь кусок данных целиком, чем обновлять одну строку.
7. Забыть про резервирование
Организация репликации данных (хранении копий) и регулярных бэкапов окажет незаменимую помощь при возникновении непредвиденных ситуаций и выходе из строя узлов и дисков.
8. Пренебрегать мониторингом и анализом
Без инструментов и методов мониторинга система превратится в Чёрный Ящик, в котором не представляется возможным понять, что происходит внутри. При возникновении проблем определённые метрики и показатели укажут на корневые причины, а также способы их устранения.
Все эти рецепты будем подробно изучать и разбирать, и, что самое главное, самостоятельно применять в рамках курса Data Engineer. Знание ключевых принципов и подходов обеспечит принятие стратегически правильных и грамотных решений.
