Лекция №1 в МГТУ им. Баумана: особенности OLTP и OLAP, основные понятия курса

• Паша Ковалев рассказывает о своем опыте в разработке и преподавании.  

• Он работал в банке и построил три хранилища данных.  

• Сейчас занимается дата-архитектурой в Сравни.  

• Курс состоит из пяти занятий, включая три лекции и две практики.  

• Первая лекция посвящена основам SQL для DW и архитектуре в Сравни.  

• Вторая лекция рассматривает инструменты для построения DW.  

• Третья лекция посвящена техникам оптимизации для Grempl и ClickHouse.  

• Четвертая и пятая лекции включают практики по Grempl и ClickHouse.  

• Рассматриваются основные понятия хранилищ данных и систем обработки данных.  

• Обсуждаются уникальные особенности архитектуры в Сравни.  

• Объясняется, почему аналитические запросы сложны и требуют особого подхода.  

• Аналитические запросы отличаются от транзакционных нагрузок.  

• Курс предназначен для всех, но сертификаты доступны только для студентов Бауманки.  

• Необходимы базовые знания SQL для понимания курса.  

• OLAP и OLTP имеют разные цели и подходы.  

• OLTP системы работают в реальном времени и обрабатывают транзакции.  

• OLAP системы используются для аналитики и прогнозирования.  

• OLAP системы работают с большими объемами данных и редко меняют данные.  

• Используются де-нормализованные подходы для повышения эффективности.  

• Цель OLAP систем – поддержка принятия решений и бизнес-процессов.  

• Приводится пример оптимизированного OLAP кода.  

• Код выглядит громоздко, но работает быстро.  

• Пример включает около 120 миллионов строк данных.  

• Хранилища данных DWH и Lakehouse.  

• Источники данных: БД, ERP, API.  

• Консолидация данных из разных источников в единую систему.  

• Очистка данных от грязных значений и адресов.  

• Преобразование данных для аналитики.  

• Использование систем, таких как PostgreSQL и Hadoop.  

• Даталейк как свалка файлов.  

• Дешевое хранение данных.  

• Использование для хранения структурированных и полуструктурированных данных.  

• Хранение данных в дешевом хранилище.  

• Работа с сырыми данными для проверки гипотез.  

• Проблемы с историчностью данных.  

• Объединение даталейка и Lakehouse в одной системе.  

• Использование систем, таких как Redshift и Snowflake.  

• Хранение как сырых, так и преобразованных данных.  

• Сырые данные, интеграционный слой, витрины данных.  

• Витрины данных как готовые к использованию таблицы.  

• Трансформация данных на этапе загрузки.  

• Использование Spark, Scala, Java и других инструментов.  

• Автоматизация трансформации данных.  

• Хранение сырых данных в промежуточном слое.  

• Использование DWH для оперативной аналитики.  

• Преимущества и недостатки DWH.  

• Примеры процессов и инструментов для DWH.  

• Современные системы хранения данных горизонтально масштабируются.  

• Классические системы, такие как PostgreSQL, могут быть шардированы, но не подходят для больших объемов данных.  

• Современные системы, такие как HBase и Cassandra, поддерживают горизонтальное масштабирование.  

• Вертикальное масштабирование ограничено объемом данных и ресурсами.  

• Системы с мастером или координатором имеют узкое горлышко в виде мастера.  

• Пример: архитектура GRIMPLAN, популярная на российском рынке.  

• Разделение компьютер-сторож: разделение задач между машинами.  

• Пример: использование HBase и Cassandra в Яндекс.  

• Планы по переносу данных на объектное хранилище.  

• Проблемы с инфраструктурой и документацией на начальном этапе.  

• Внедрение документации и создание инфраструктуры.  

• Проблемы с сырыми данными и метриками.  

• Найм разработчиков и дата-инженеров.  

• Настройка работы с Kubernetes и стриминг данных.  

• Создание фреймворка для работы с данными.  

• Создание гайдов для аналитиков по эффективным запросам.  

• Использование дата-таблиц для метаданных.  

• Найм высококвалифицированных аналитиков.  

• Создание системы для аналитиков через пури-квесты.  

• Автоматизация процессов и улучшение фидбека.  

• Текущее состояние: использование Snowflake для хранения данных.  

• Используются более 50 источников данных, включая Hadoop и базы данных.  

• Фреймворк написан на Python, оркестратор - Argo.  

• Argo выбран из-за его простоты и надежности.  

• Используются Grafana, Victoria Metrics и Terraform для мониторинга и развертывания.  

• Стриминг данных через Kafka с помощью коннекторов.  

• Проблемы с переходом на новые системы из-за изменений в модели данных.  

• Схема DWH включает доставку данных стримингом, бачем и Kafka.  

• Используются классические коннекторы на Python и Kafka Connect.  

• Argo автоматизирует доставку данных из различных источников.  

• Snowflake используется как лейкхаус платформа, но не работает с Россией с 2014 года.  

• Платформа двухслойная, что усложняет повторное использование кода.  

• Snowflake поддерживает различные облачные провайдеры и имеет виртуальные кластеры.  

• Проблемы с зоопарком инструментов и отсутствием единой системы.  

• Сложности с погружением в платформу и анализом данных.  

• Дорогая архитектура и необходимость оптимизации запросов.  

• Решение проблем в текущем решении не будет, планируется новое DWH в облаке.  

• Использование Kafka и коннекторов для доставки данных.  

• Архитектура с использованием Spark и ClickHouse для аналитической нагрузки.  

• Оптимизация аналитических запросов требует времени и усилий.  

• Важно понимать, зачем оптимизировать и как это влияет на производительность.  

• Оптимизация должна быть ограничена определенными критериями и целями.  

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

• Оптимизация может основываться на правилах и догадках, но в сложных системах это не всегда работает.  

• Важно знать, как работает оптимизатор и система в целом.  

• Оптимизатор анализирует статистику и данные для лучшего выполнения запроса.  

• Если все работает нормально, оптимизация может не требоваться.  

• В сложных случаях аналитики могут помочь улучшить запросы.  

• Запрос проходит через парсер, оптимизатор и движок выполнения.  

• Оптимизатор формирует план выполнения и отправляет его в движок.  

• Пример работы оптимизатора на сервере.  

• Запрос отправляется в парсер, оптимизатор и движок выполнения.  

• Оптимизатор взаимодействует с данными, хранящимися в памяти или на диске.  

• Понимание работы оптимизатора под капотом важно для оптимизации.  

• Грамотная архитектура базы данных помогает оптимизировать запросы.  

• Понимание типа нагрузки помогает выбрать подходящие техники оптимизации.  

• Оптимизация запросов может быть необходима при проблемах с производительностью.  

• Алгоритм доступа к данным определяет, как данные читаются с диска или из памяти.  

• Индексирование помогает ускорить поиск данных.  

• Индексы могут быть бинарными деревьями с разной гранулярностью ключей.  

• Поиск данных по индексу может быть полным сканированием или частичным.  

• Поиск по равенству называется синглтон лука.  

• Поиск по предикатам, таким как больше или меньше, требует полного сканирования страницы.  

• Индексные сканирования могут быть эффективными, но не всегда.  

• В системах с большим количеством полей данные могут храниться по колонкам.  

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

• Колонночные системы хранят данные по колонкам, что ускоряет доступ к нужным данным.  

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

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

• Хэш-индексы используются для низкоселективных столбцов, таких как пол или флажки.  

• Кластерные индексы материализуют таблицу в виде B-дерева, что ускоряет поиск.  

• Функциональные индексы материализуют формулы, такие как LEFT или SUBSTRING, для эффективного поиска.  

• Географические индексы позволяют эффективно искать по широте и долготе.  

• Оптимизатор использует оценщик кардинальности для выбора эффективного алгоритма соединения.  

• Хэш-алгоритм является самым распространенным и простым, но требует больших выделений памяти.  

• Мердж-алгоритм использует хэш-таблицу для быстрого поиска, но может потреблять много памяти.  

• Хэш-алгоритм работает с двумя таблицами, одна из которых используется для построения хэш-таблицы.  

• Мердж-алгоритм требует сортировки данных перед соединением, что может быть неэффективно.  

• Визуализация алгоритмов помогает понять их работу и возможные проблемы.  

• Псевдокод описывает процесс поиска в хэш-таблице.  

• Алгоритм универсален и подходит для не отсортированных данных.  

• Ограничение: работает только с равенствами, не с бинарными операциями.  

• Наивный нейн использует вложенные циклы для поиска.  

• Оптимизирован для повышения эффективности.  

• Визуализация алгоритма проста и понятна.  

• Индекс на внутренней стороне таблицы может значительно ускорить поиск.  

• Пример: если на внешней стороне мало клиентов, индекс может быть эффективнее.  

• Псевдокод для наивного нейна сложен и требует времени для написания.  

• Хэш-таблица подходит для не индексированных таблиц и больших таблиц.  

• Может не хватать памяти и вызывать замедление.  

• Сортировка в мерче может быть блокирующей операцией.  

• План запроса состоит из дерева операторов.  

• Операторы включают сканы таблиц, индексы, джойны, сортировки и группировки.  

• Визуализация плана запроса важна для анализа и оптимизации.  

• Операторы плана запроса являются функциональными единицами обработки.  

• План читается справа налево и снизу вверх.  

• Логические операторы, такие как левый и правый джойны, преобразуются в физические алгоритмы.  

• Решение не оптимизировать на сырых данных, чтобы избежать бесконечных оптимизаций.  

• Создание рекомендаций на основе анализа загрузки и ошибок.  

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

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

• Решение: оптимизировать предикаты, чтобы читать только нужные строки.  

• Пример: сканирование всей таблицы вместо фильтрации по предикату.  

• Пример с двумя таблицами и фильтрацией по дате.  

• Оптимизация через секционирование и индексирование.  

• Пример с разными предикатами по одному полю, которые можно объединить.  

• Проблема взрыва строк при соединении многие-ко-многим.  

• Пример с дубликатами и отсутствием условий соединения.  

• Рекомендации: проверять все ли предикаты учтены и исключать дубликаты на раннем этапе.  

• В колонночных системах можно хранить метаданные вместе с данными.  

• Это позволяет оптимизировать запросы, например, на максимальную дату.  

• Алгоритм "сортовый лимит" использует сортировку для выдачи строк на ранних этапах.  

• В колонночных системах можно использовать метаданные для фильтрации.  

• Это устраняет необходимость в дополнительных сканах и сортировках.  

• Важно учитывать, что поле может содержать несколько значений на максимальную дату.  

• Фильтрация по полю в JSON может быть медленной из-за отсутствия функциональных индексов.  

• Рекомендуется выносить нужные поля в отдельные столбцы для улучшения фильтрации.  

• Пример: фильтр по остатку в левом джойне.  

• Соединения через "или" в колонночных системах часто не оптимизируются.  

• Переписывание на "union" может значительно улучшить производительность.  

• Важно исключать дубликаты при использовании "union".  

• Избыточное вычисление может привести к падению производительности.  

• Пример: использование сложной оконной функции для формирования массива.  

• Важно анализировать запросы для выявления и устранения избыточных вычислений.  

• Освоение темы требует времени и усилий, но она полезна для бэкендеров и DWH.  

• Вопросы касаемо новой архитектуры и использования данных в ClickHouse.  

• ClickHouse плохо работает с витринами и сложными вычислениями.  

• В Greenplum формируются витрины, которые затем передаются в ClickHouse.  

• ClickHouse справляется с задачами дешевле и быстрее, чем Greenplum.  

• В Greenplum формируется фундамент витрины, который затем передается в ClickHouse.  

• Рекомендованы книги по архитектуре данных, такие как "До того 2.0" и "Аден Линстед".  

• Книги по архитектуре данных описывают методологию, которая не устаревает.  

• Якорная модель проста, но требует правильного построения.  

• Дима Короткевич написал книгу по оптимизации в одной базе данных.  

• Оптимизация данных требует сложных алгоритмов и правильного проектирования.  

• В компании используются отдельные инструменты для разных отделов.  

• Важно правильно выстраивать архитектуру данных для аналитиков и инженеров.  

• Оптимизация данных помогает избежать проблем в будущем.  

• Greenplum и ClickHouse считаются революционными базами данных.  

• Cassandra также является популярной базой данных с колоночными данными.  

• В будущем возможно появление графовых баз данных, но пока они не доминируют.