UPD: Продолжение статьи по ссылке - habrahabr.ru/company/avito/blog/322510
О чем эта статья?
Прошел год незаметно с начала работ по разработке и внедрению хранилища данных на платформе Вертика.На хабе уже есть статьи о самой СУБД Вертика, особенно рекомендую вот эту: HP Vertica, первый запущенный проект в РФ , потому что его автор нам очень помог на начальном этапе.
Алексей, еще раз спасибо.
Хотелось бы рассказать о том, какая методология использовалась при проектировании физической структуры хранилища, чтобы в полной мере использовать возможности HP Vertica. Эту статью я хотел бы посвятить обоснованию оптимальности выбранной методологии, а в следующей хотелось бы рассказать о том, какие методики позволяют анализировать данные, содержащие десятки миллиардов.
Постановка задачи
Рассмотрим высоконагруженный сайт крупной российской интернет-компании (теперь можно - это Авито ;)).Деятельность компании описывается следующими цифрами: ~10 миллионов активных пользователей, ~100 миллионов просмотров страниц в день, около 1 тысячи новых объектов, размещенных пользователями на сайте в течение 1 минуты, ~10 тысяч поисковых запросов пользователей в минуту.
Грубая оценка количества действий, которые будут храниться в репозитории, — 100 миллионов новых записей в день (~100 ГБ новых данных в день).
Те.
при построении классического хранилища данных с отказом от стирания ранее полученных данных объем хранилища после 3 месяцев эксплуатации составит 10ТБ сырых данных.
Большие данные, как они есть.
Необходимо построить хранилище, которое бы хранило данные минимум за 6 месяцев, позволяло их анализировать, визуализировать и как можно меньше отставало бы от реальной жизни (в худшем случае отставало бы на день, в лучшем случае , по минутам).
Сразу исключая вопрос о выборе платформы, СХД должна работать на HP Vertica — столбчатой СХД на базе MPP, см.
вступительную статью в заголовке.
Выбор методологии
В настоящее время популярны несколько методик строительства складских помещений:- Во-первых это Кимбел и строительство хранилища в виде комбинации «звезд».
Одна из самых популярных методик, потому что.
ей учат во всех наших институтах, где читают про хранилища.
- Во-вторых, это Инмон.
.Точнее, не просто Инмон, а скорее инерция.
Его подход к проектированию хранилищ содержит ряд красивых тезисов, таких как нормализация, но не содержит четкого алгоритма того, как именно преобразовать бизнес-модель в модель данных (в таблицы СУБД).
Но всегда есть короткий путь — можно взять таблицы исходной системы, из которой заполнено хранилище, перенести их КАК ЕСТЬ, немного модифицировать и хранилище будет. Почти по Инмону.
- В-третьих, это Хранилище данных .
Сравнительно новая методика, но уже более-менее известная в России, есть даже статья в Википедии на русском языке.
Неплохо, есть и идеология, и алгоритм построения моделей.
- В-четвертых, это Якорное моделирование .
Совершенно новая методология, местами шокирующая, потому что… предполагает хранение данных в соответствии с 6-й нормальной формой.
- Гетерогенность - хранилище должно принимать данные из разных учетных систем разной природы (реляционная OLTP-база данных, и NoSQL JSON-хранилище свободной структуры с данными о веб-трафике)
- Гибкость и расширяемость.
Не позволяйте модели данных хранилища стать фиксированной.
Бизнес компании расширяется, добавляются новые услуги, открываются новые филиалы.
В любой момент модель данных хранилища может потребоваться перепроектировать для отражения новых типов данных.
- Историчность – недопустимо хранить в хранилище только текущие состояния объектов.
Также необходимо вести полную историю изменений всех атрибутов всех сущностей.
Например, если пользователь разместил объявление на сайте компании, а затем трижды изменил его название и цену, хранилище должно позволять оценивать популярность объявления для каждого временного интервала между изменениями.
- Скорость — в предыдущих разделах статьи были приведены оценки объёма данных, поступающих на склад каждый час.
В этом случае следует не только добавлять новые данные, но и обновлять старые записи.
При получении списка рекламных объявлений необходимо не только загрузить новые данные, но и проверить, не изменились ли ранее загруженные поля.
- Объем – хранилище должно обеспечивать высокую глубину хранения данных, что вместе с оценками скорости поступления данных означает, что модель хранилища данных должна успешно справляться с задачей сохранения историчности и гибкости при объемах данных в миллиарды записей и десятки терабайт.
Эта методология не предоставляет стандартных механизмов неразрушающего расширения модели.
Другими словами, чтобы добавить в модель новые сущности (новые измерения, новые факты), необходимо расширить старые таблицы, а это означает модификацию ETL-процессов.
Таким образом, при каждом расширении есть риск допустить ошибку и нарушить работу старого функционала.
Кроме того, модель данных «Звезды» испытывает трудности с сохранением историчности данных.
Историчность данных измерений реализуется за счет реализации медленно меняющихся измерений 2-го типа ( медленно меняющееся измерение, тип 2 ).
Однако такой подход приводит к многократному увеличению количества строк в таблице фактов, и реализовать историчность фактов в этой модели крайне сложно.
Подход Инмона слишком общий, его можно использовать для создания своей методологии.
ведь все существующие, готовые и проверенные методологии отбрасываются.
Методология Хранилище данных выглядело чрезвычайно многообещающе в контексте этой задачи.
Data Vault не обеспечивает разделения таблиц на факты и измерения; позволяет независимо вести историю любых полей данных, за исключением бизнес-ключей.
Историчность поддерживается за счет реализации медленно меняющихся измерений типа 2 (медленно меняющихся измерений типа 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-процессов (одна вставка + одно обновление), но значительно быстрее при поиске текущей версии данных (наличие двух дат позволяет найти текущую запись, независимо перебирая версии и проверяя даты на текущую дату между ними).
Однако в пределах МПП баз данных ситуация меняется — операция обновления в них происходит значительно медленнее операции вставки (внутри СУБД Vertica — в десятки и сотни раз).
Реализация функциональности оконных функций из стандарта ANSI SQL 2003 (окно, конструкция OVER (partition by. order by.)) позволяет осуществлять поиск текущей версии данных только по дате начала, практически никакой потери производительности по сравнению с двумя датами.
Таким образом, неэффективность операции обновления в СУБД Vertica вынуждает нас отдать предпочтение варианту сохранения историчности данных на основе методологии Anchor Modeling.
- Поддержание высокой скорости ETL-процессов по мере роста объемов.
Data Vault предполагает хранение атрибутов объектов, сгруппированных во вспомогательных таблицах.
Например, если у сущности имеется 50 атрибутов с сопоставимой вероятностью изменения, методология Data Vault рекомендует хранить их в одной таблице.
Методика моделирования привязки в этом случае требует создания 50 таблиц, по одной для каждого атрибута.
На первый взгляд подход якорного моделирования кажется излишним, хотя он и удовлетворяет 6-й нормальной форме.
Собрать фактические значения всех 50 атрибутов возможно только путем создания специальных материализованных представлений.
Без них собирать атрибуты для аналитика склада слишком сложно.
Но насколько различаются подходы в области больших данных? В эксперименте записи веб-трафика, содержащие 20 столбцов, загружались параллельно в две разные структуры — одну широкую таблицу из 20 столбцов, соответствующую методологии Data Vault, и 20 максимально нормализованных узких таблиц, соответствующих методологии Anchor Modeling. В первую неделю после запуска эксперимента скорость подходов различалась незначительно, при этом наилучшую производительность при анализе данных показал подход Data Vault (не нужно объединять 20 таблиц в одну витрину).
Однако через месяц загрузки, когда количество записей в каждой из таблиц превысило 5 миллиардов записей, были получены следующие результаты: • Регулярный запуск ETL-процесса для дополнительной загрузки новых данных за последние 20 минут позволил ввести ~5 миллионов новых строк.
• Сбор данных из исходных систем, очистка и обогащение – идентичные для обеих методик, заняли около 10 минут. • Добавление данных в узкие таблицы моделирования привязки выполнялось в виде 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 минут для структуры таблицы привязочного моделирования).
).
Дальнейшее снижение производительности процессов ETL, заполняющих широкую таблицу Data Vault, поставило под угрозу синхронизацию хранилища с оперативными данными в реальном времени.
Хранилище стало отставать от боевых систем, и требовало переноса старых исторических данных из широкой таблицы Data Vault в архив.
Модель Anchor Modeling не продемонстрировала подобных недостатков.
- Поддерживайте управляемость и расширяемость хранилища.
Хотя казалось бы, что Вертика — это столбчатая база хранения и должна быть инвариантна к количеству столбцов в таблице, приведенный пример — далеко не единственная демонстрация того, что много узких таблиц лучше, чем одна широкая.
Например, со временем вам может понадобиться перераспределить таблицу.
Вертика делает эту операцию просто — создает копию таблицы и начинает на ней переразметку.
Казалось бы, все просто.
Но переразметка обычно выполняется для удаления старых исторических разделов, когда на диске заканчивается место.
Дело в том, что стирание данных в Вертике — крайне неэффективная операция; если речь идет о миллионах строк, то это возможно, но когда речь идет о миллиардах, стирание может длиться сутками, блокируя все остальные процессы в системе.
В условиях нехватки дискового пространства может просто не хватить места для создания копии таблицы с большим количеством столбцов.
И даже если места достаточно, переразметка такой таблицы займет сутки.
Если вместо одной таблицы использовать множество узких из 3-4 столбцов, то даже для 50-60 миллиардов строк они будут перераспределены за часы, причем процесс можно будет выполнять поочередно, что облегчит работу пользователя.
система поиска нужного места.
выводы
Краткое резюме — методология Anchor Modeling оказалась на удивление подходящей для создания хранилища больших данных на HP Vertica. Приведенные примеры — это лишь часть того, с чем мы столкнулись, и почти всегда оказывалось, что если бы мы не пошли по пути Anchr Modeling, нам было бы гораздо сложнее.Однако я не рекомендую думать, что Анкорное моделирование само по себе решит все проблемы архитектора.
Сильная и слабая сторона этой методологии – очень четкое структурирование всех операций.
Для разработки репозитория необходимо полностью автоматизировать генерацию моделей данных, кода создания объектов базы данных и ELT-процедур.
Эту проблему мы решили, используя собственный код на Python, а описание метаданных сохранили в Excel. В результате вся инфраструктура была создана за месяц, а через два месяца после знакомства с Вертикой хранилище начало решать первые бизнес-задачи и достигло объема в 1 ТБ.
На самом деле вот оно.
Если тема кого-то заинтересует, планирую рассказать о других нюансах работы с высоконормализованными хранилищами в HP Vertica, в частности о том, как эмулировать работу алгоритма Map-Reduce поверх SQL, когда обычный SQL не справляется.
Теги: #Vertica #dwh #sql #Большие данные
-
Алдер, Курт
19 Oct, 24 -
Подкаст Об Интернет-Мониторинге №001
19 Oct, 24
