О чем статья
Незаметно пролетел год, как начались работы по разработке и внедрению хранилища данных на платформе Вертика.
На хабре уже есть статьи про саму СУБД Вертика, особенно рекомендую эту: HP Vertica, первый запущенный проект в РФ, ведь ее автор очень помог нам на начальном этапе. Алексей, спасибо еще раз.
Хотелось бы рассказать о том, какая методология применялась для проектирования физической структуры хранилища, чтобы наиболее полно использовать возможности HP Vertica.
Эту статью хотел бы посветить обоснованию оптимальности выбранной методологии, а в следующей — рассказать о том, какие техники позволяют анализировать данные, содержащие десятки млрд. строк, не быстро, а очень быстро.
Постановка задачи
Рассмотрим высоконагруженный сайт крупной российской интернет-компании (входит в топ 10 сайтов рунета по количеству уникальных пользователей по данным LiveInternet и Google Analytics).
Деятельность компании описывается следующими цифрами: ~ 10 млн. активных пользователей, ~100 млн. просмотров страниц в день, около 1 тыс. новых объектов, размещенных пользователями на сайте в течение 1 минуты, ~10 тыс. поисковых запросов пользователей в минуту.
Грубая оценка количества действий, подлежащих сохранению в хранилище, составляет 100 млн. новых записей в сутки (~100 GB новых данных в сутки).
Т.е. при построении классического хранилища данных с отказом от стирания поступивших ранее данных, объем хранилища через 3 месяца эксплуатации составит 10TB сырых данных. Big Data как она есть.
Нужно построить хранилище, которое хранило бы не меньше 6 месяцев данных, позволяло их анализировать, визуализировать, и отставало бы от реальной жизни настолько мало, насколько это возможно (в худшем случае — отставало бы на день, в лучшем — на минуты).
Вынося сразу за скобки вопрос выбора платформы — хранилище должно работать на HP Vertica, MPP базе колоночного хранения, см. вводную статью в заголовке.
Выбор методологии
Сейчас для построения хранилищ популярны несколько методологий:
- Во-первых это Кимбэл, и построение хранилища в виде комбинации «звезд». Одна из самых популярных методологий, т.к. ей учат во всех наших институтах, где читают про хранилища.
- Во-вторых, это Инмон.… Точнее не просто Инмон, а скорее инерция. Его подход к проектированию хранилищ содержит ряд красивых тезисов, вроде нормализации, но не содержит однозначного алгоритма, как именно преобразовать бизнес-модель в модель данных (в таблицы СУБД). Но всегда есть короткая дорога — можно взять таблицы исходной системы, из которой заполняется хранилище, перенести их AS IS, немного доработать и будет хранилище. Почти по Инмону.
- В третьих, это Data Vault. Относительно новая методология, но в России уже более-менее известная, даже статья в википедии на русском есть. Неплохая штука, есть и идеология, и алгоритм построения моделей.
- В четвертых, это Anchor Modeling. Совсем новая методология, местами шокирующая, т.к. предполагает хранение данных с соблюдением 6-й нормальной формы.
Проектируемое хранилище данных должно удовлетворять следующим требованиям, вытекающим друг из друга:
- Гетерогенность — хранилище должно принять данные из разных учетных систем, имеющих разную природу (реляционная OLTP база, и NoSQL JSON хранилище свободной структуры с данными о веб- трафике)
- Гибкость и расширяемость — нельзя допустить фиксацию модели данных хранилища. Бизнес компании расширяются, добавляются новые услуги, сервисы, открываются новые филиалы. В любом момент модель данных хранилища может потребоваться переработать для отражения новых типов данных.
- Историчность — в хранилище недопустимо хранить только актуальные состояния объектов. Необходимо также сохранять полную историю изменений всех атрибутов всех сущностный. Например, если пользователь разместил на сайте компании объявление, а затем трижды менял у него название и цену, хранилище должно позволить оценить популярность объявления для каждого временного интервала между правками.
- Velocity — в предыдущих разделах статьи приводились оценки количества ежечасно поступающих в хранилище данных. При этом должны не только добавляться новые данные, но и актуализироваться старые записи. При получении списка объявлений необходимо не только загружать новые данные, но и проверять, не изменились ли поля, загруженные ранее.
- Volume — хранилище должно обеспечить высокую глубину хранения данных, что, в совокупности с оценками скорости поступления данных, означает что модель хранилища данных должна успешно справляться с задачей поддержания историчности и гибкости на объемах данных в миллиарды записей и десятки терабайт.
На основании анализа приведенных выше требований методология “Звезда” была отброшена первой. В рамках данной методологии не предусмотрено штатных механизмов для неразрушающего расширения модели. Другими словами, для добавления в модель новых сущностей (новых измерений, новых фактов) необходимо расширение старых таблиц, а значит — модификация ETL процессов.
Таким образом, при каждом расширении существует риск допустить ошибку и нарушить работоспособность старой функциональности.
Кроме того, модель данных “Звезда” испытывает сложности при поддержании историчности данных. Историчность данных измерений реализуема посредством реализации медленно меняющихся измерений типа 2 (slow changing dimension type 2). Однако такой подход приводит к кратному росту количества строк в таблице фактов, а реализовать историчность фактов в данной модели крайне сложно.
Подход Инмона слишком общий, его можно использовать для создания собственной методологии… после того как будут отброшены все существующие, уже готовые и проверенные методологии.
Методология Data Vault выглядела крайне многообещающе в контексте данной задачи. Data Vault не предусматривает разделения таблиц на факты и измерения, в ней допустимо независимое поддержание историчности любых полей данных, за исключением бизнес-ключей. Историчность поддерживается посредством реализации медленно меняющихся измерений типа 2 (slow changing dimension type 2, с двумя датами — from_date, датой начала действия данных и to_date, датой конца действия данных).
Data Vault поддерживает неразрушающий рост модели. Другими словами, при выявлении новых бизнес-сущностей или новых связей между старыми бизнес-сущностями модель хранилища Data Vault может быть расширена без внесения правок в старые таблицы и ETL процессы. Старая логика просто продолжит работать независимо от изменений.
Также Data Vault значительно упрощает распараллеливание ETL процессов за счет полной независимости процессов загрузки Хабов (сущностей) и Сателитов (атрибутов сущностей). Только при загрузке Линков (связей сущностей) возможны зависимости, требующие выполнить одни ETL процессы раньше других.
Все приведенные выше преимущества модели Data Vault актуальны и для Anchor Modeling, поэтому дальнейшие решения принимались на основании нагрузочных экспериментов с промышленными данными в среде СУБД Vertica.
Эксперименты показали следующие различия между моделями, построенными на методологии Data Vault и Anchor Modeling:
- Поддержание историчности. Data Vault предусматривает реализацию медленно меняющихся измерений типа 2 с двумя датами — датой начала действия данных и датой конца действия данных. Другими словами, когда приходит новая версия данных, старая версия должна быть обновлена для выставления даты конца действия данных. Anchor Modeling предусматривает хранение только одной даты — даты начала действия данных. Такой подход позволяет реализовывать концепцию only-insert-ETL — загрузка данных без обновлений, только со вставками. На обычных СУБД подход с двумя датам незначительно медленнее в рамках ETL-процессов (одна вставка + одно обновление), но значительно быстрее в рамках поиска актуальной версии данных (наличие двух дат позволяет найти актуальную запись, независимо перебирая версии и проверяя даты на попадание текущей даты между ними). Однако в рамках MPP баз ситуация меняется — операция обновления в них значительно медленнее операции вставки (в рамках СУБД Vertica — в десятки и сотни раз). Реализация функционала оконных функций из стандарта ANSI SQL 2003 (windowing, конструкция OVER (partition by… order by …)) позволяет искать актуальную версию данных на основании только даты начала, практически без потери производительности по сравнению с двумя датами. Таким образом, неэффективность операции update в СУБД Vertica заставляет предпочесть вариант поддержания историчности данных на основе методологии Anchor Modeling.
- Поддержание высокой скорости ETL процессов при росте объемов. Data Vault предполагает хранение атрибутов сущностей сгруппированными в таблицах-сателлитах. Например, если сущность обладает 50 атрибутами со сравнимой вероятностью изменений, методология Data Vault рекомендует хранить их в одной таблице. Методология Anchor Modeling в подобном случае требует создать 50 таблиц, по одной для каждого атрибута. Подход Anchor Modeling на первый взгляд кажется избыточным, хотя и удовлетворяет 6 нормальной форме. Сбор актуальных значений всех 50 атрибутов возможен только посредством создания специальных материализованных представлений. Без них собрать атрибуты слишком сложно для аналитика, работающего с хранилищем. Но на сколько различаются подходы в условиях Big Data? В рамках эксперимента записи о веб-трафике, содержащие 20 столбцов, загружались параллельно в две различные структуры — единственную широкую таблицу из 20 столбцов, соответствующую методологии Data Vault, и в 20 максимально нормализованных узких таблиц, соответствующих методологии Anchor Modeling. В первую неделю после запуска эксперимента скорость подходов различалась незначительно, в то время как подход Data Vault давал лучшую производительность для анализа данных (не нужно объединять 20 таблиц в одну витрину). Однако через месяц загрузки, когда количество записей в каждой из таблиц превысило 5 млрд. записей, были получены следующие результаты:
• Штатный запуск ETL процесса для догрузки новых данных за последние 20 минут позволял ввести новых строк ~ 5 млн.
• Забор данных из исходных систем, очистка и обогащение — идентичный для обеих методологий, занимал около 10 минут.
• Добавление данных в узкие таблицы Anchor Modeling запускалось как 20 независимых потоков. Каждый из них запускался одновременно и завершался за время от 40 секунд до 2 минут.
• Добавление данных в единственную широкую таблицу Data Vault занимало от 7 до 9 минут.
• Контрольный запуск добавления данных в широкую таблицу Data Vault, без параллельно работающей вставки в таблицы Anchor Modeling, показал такие-же цифры, от 7 до 9 минут.
Эксперимент показал, что при росте количества уже хранящихся в таблице строк данных до 5 млрд. вставка в модель Data Vault начинает работать в ~4 раза медленнее, чем в модель Anchor Modeling.
После месяца эксплуатации хранилища ETL-процессы, заполняющие широкую таблицу Data Vault, требовали в общей сложности от 17 до 19 минут для загрузки данных, поступавших из внешних систем за 20-минутный интервал (против 11-12 минут для структуры таблиц Anchor Modeling).
Дальнейшая деградация производительности ETL-процессов, заполняющих широкую таблицу Data Vault, поставила под угрозу синхронизацию хранилища с операционными данными в реальном времени. Хранилище начинало отставать от боевых систем, и потребовало переноса старых историчных данных из широкой таблицы Data Vault в архив. Модель Anchor Modeling подобных недостатков не продемонстрировала. - Поддержание управляемости и расширяемости хранилища. Хотя, казалось бы, Вертика — база колоночного хранения, и должна быть инвариантной к количеству столбцов в таблице, приведенный выше пример — далеко не единственная демонстрация того, что много узких таблиц — лучше чем одна широкая. Например, со временем может потребоваться репартиционировать таблицу. Вертика делает эту операцию просто — создает копию таблицу, и запускает на ней репартиционирование. Казалось бы, все просто. Но репартиционирование обычно делают, чтобы выполнить стирание старых исторических партиций, когда заканчивается дисковое пространство. Дело в том, что стирание данных в Вертике — крайне неэффективная операция, когда речь идет о миллионах строк — оно возможно, когда же речь идет о миллиардах — стирание может длиться сутками, заблокировав все прочие процессы в системе. В контексте нехватки дискового пространства — места для создания копии таблицыс большим количеством столбцов может элементарно не хватить. И даже если места достаточно — репартиционирование подобной таблицы займет сутки. Если же вместо одной таблицы используется множество узких, в 3-4 столбца, то даже для 50-60 млрд. строк они будут репартиционироваться за часы, и процесс можно будет выполнять по очереди, что упростит системе поиск необходимого места.
Выводы
Краткое резюме — методология Anchor Modeling оказалась на удивление подходящей для создания Big Data хранилища на HP Vertica.
Приведенные примеры — только часть того, с чем нам довелось столкнуться, и практически всегда оказывалось, что не пойди мы по пути Anchr Modeling — нам было бы намного сложнее.
Однако не рекомендую думать, что Anchor Modeling сама по себе решит за архитектора все проблемы. Сила и слабость этой методологии — в очень четкой структурированности всех операций. Чтобы хранилище можно было развивать — генерация моделей данных, кода создания объектов БД и ELT процедур должна быть полностью автоматизирована.
Мы решили эту задачу за счет собственного кода на Python, а описание метаданных хранили в Excel, в итоге вся инфраструктура была создана за месяц, а через два месяца после знакомства с Вертикой хранилище стало решать первые бизнес-задачи и достигло объема в 1Тб.
Собственно вот. Если тема будет кому-то интересна, планирую рассказать о прочих нюансах работы с высоконормализованным хранилищем в HP Vertica, в частности о том, как эмулировать работу алгоритма Map-Reduce поверх SQL, когда обычный SQL не справляется.
Автор: azathot
