Записаться

Инструменты и технологии хранилищ данных

Извлечение, очистка и преобразование данных

Задачи извлечения данных из источников, их очистки и преобразования для загрузки в хранилище могут выполняться несколькими отдельными подпрограммами или единым интегрированным подходом. Крупные поставщики хранилищ включают ETL-процедуры (Extract, Transform, Load — извлечение, преобразование, загрузка) в комплексное решение. Тогда не нужен отдельный модуль или продукт другого вендора, который пришлось бы интегрировать с хранилищем. Всё реализовано в одном программном продукте.

ETL-процедуры работают с первичным источником, а данные попадают в единое хранилище. Поэтому инструмент должен читать информацию независимо от её природы: база данных, сайт в интернете, файл на удалённом жёстком диске. Источник не важен. Задача любого инструмента ETL — уметь видеть всё что угодно. Поэтому такое сложное комплексное решение лучше делать интегрированной компонентой внутри хранилища, а не отдельным модулем, который будет разрабатывать неизвестно кто.

СУБД в составе хранилища

Внутри хранилища данные где-то хранятся, значит нужна СУБД (система управления базами данных; DBMS, Database Management System), управляющая этим хранением. Она находится в ядре хранилища. Обычно СУБД стандартны: набор ограничен, достоинства и недостатки известны. В курсе моделирования баз данных использовался SQL Server; работа с ним продолжится и при обсуждении хранилищ. SQL Server регламентирует внутреннюю работу и физическую реализацию базы данных. Аналогично внутри хранилища СУБД отвечает за полное функционирование, корректное выполнение запросов, корректную трансформацию данных и работу ядра системы.

Факторы выбора СУБД

При выборе СУБД нужно учитывать:

• параллельность работы. С хранилищем работают многие разнопрофильные сотрудники, одновременно идут внутренние процессы, резервное копирование, обслуживаются запросы огромного числа пользователей. Возможность параллельной работы — самый актуальный фактор.
• контроль высокой производительности. Если отклик на небольшой запрос занимает минуты, система неэффективна и не нужна.
• контроль масштабируемости. Компания, число пользователей и объём данных растут. Хранилище не должно упереться в предел. При выборе решения нужно закладывать рост с запасом.
• контроль готовности и управляемости. Нужны внутренние инструменты контроля корректного функционирования хранилища.

Требования к СУБД хранилища данных

Список требований более-менее абстрактный, но за ним стоит конкретный смысл. Если требование не выполняется, стоит задуматься, подходит ли такая СУБД.

• Высокая производительность данных: данные должны попадать в хранилище быстро и оперативно.
• Возможность обработки данных во время загрузки: не просто закинуть сырые данные, а по дороге что-то отбросить, модифицировать, дополнить, просуммировать.
• Средства управления качеством данных: проверка, согласованы ли данные одного источника с данными другого.
• Высокая производительность запросов: запрос пользователя к хранилищу должен обрабатываться быстро.
• Масштабируемость по объёму и количеству пользователей.
• Возможность организации сети хранилищ данных: создание цепочки хранилищ.
• Средства администрирования: качественный, нативно понятный инструмент для эффективного администрирования.
• Поддержка интегрированного многомерного анализа размерностей.
• Расширенный набор функциональных средств запросов: инструмент должен быстро формировать сложные запросы; источником идеи может быть и человек, и машина.
• Метаданные: они участвуют в формировании запросов и хранят информацию о том, какие типы и конкретные запросы выполняются к хранилищу.
• Синхронизация метаданных: первичные источники различны, а метаданные должны хранить всё: например, поле 1 пришло из источника A, поле 2 — из источника B. Метахранилище должно взаимодействовать и синхронизироваться с разными источниками, собирать разные метаданные вместе.

Многомерный анализ и иерархии

Многомерный анализ удобно пояснить на корпоративной структуре: президент, вице-президент, департаменты, отделы, подотделы, сотрудники. Можно захотеть запрос: вернуть данные по договорам, которые курирует сотрудник Иванов, отчёт третьего уровня, составленный в департаменте номер шесть. В одном запросе фигурируют человек (низший уровень иерархии) и департамент (средний уровень). Затем запрос ограничивается временем: июнь—июль. Это ещё одна размерность (dimension). Добавляется регион, например Ленинградская область, — ещё одна размерность. В запросе смешаны три-четыре размерности. Хранилище должно оперативно двигаться по этим размерностям, видеть сложную иерархию и структуру при большом количестве размерностей и иерархии внутри отдельной размерности. Для этого нужен соответствующий инструмент, позволяющий быстро сформировать и выполнить такой запрос.

Управление и администрирование хранилища

Инструменты управления и администрирования должны позволять:

• контролировать загрузку из нескольких источников;
• проверять качество и целостность данных;
• управлять и обновлять метаданные;
• контролировать текущую производительность базы данных: видеть нагрузку и эффективность работы;
• проводить аудит использования хранилища: какой пользователь, когда подключился, что запросил, какой объём данных получил, какой отчёт сформирован;
• выполнять репликацию, разбиение и распределение данных — для резервного копирования и распределённого хранения с целью повышения производительности;
• поддерживать эффективное управление хранилищем: удаление ненужных данных, архивирование, резервное копирование, восстановление после сбоя, управление средствами защиты.

Все эти процессы нужно предоставить в управление.

Переход к витринам данных

Следующий пункт — магазины, они же витрины, они же витрины данных (data mart). Это следующий объект рассмотрения.

Краткие итоги

Практическая ценность темы определяется связкой трёх уровней: поступления данных, их хранения и эксплуатации. ETL-инструменты не сводятся к разовой загрузке; они должны обеспечивать единое чтение разнородных источников и преобразование данных до попадания в ядро. Поэтому архитектурно выигрышнее интегрированное решение, где извлечение, очистка, преобразование и хранение развиваются согласованно, а не склеиваются из случайных модулей.

Выбор СУБД становится не технической формальностью, а управленческим решением. Параллельность, отклик, запас масштабирования и управляемость определяют, сможет ли хранилище обслуживать множество пользователей и процессов без деградации. Если эти свойства не заложены заранее, рост компании и объёма данных быстро превращает удобную систему в узкое место, а экономия на этапе выбора оборачивается потерями в эксплуатации.

Требования к СУБД показывают, что хранилище — это не только место хранения. Оно должно обрабатывать данные во время загрузки, контролировать качество, быстро отвечать на запросы, поддерживать сеть хранилищ, администрирование и многомерный анализ. Особую роль играет способность работать с иерархиями и несколькими размерностями: практические вопросы часто соединяют разные уровни управления, периоды и регионы. Чем сложнее такая аналитика, тем важнее инструменты формирования запросов.

Метаданные и администрирование образуют контур управления. Синхронизация метаданных связывает разнородные источники, а средства управления позволяют контролировать загрузку, качество, производительность, аудит, репликацию, архивирование, восстановление и защиту. Без этого хранилище теряет прозрачность и предсказуемость. Переход к витринам данных логичен: после организации ядра и управления возникает потребность в специализированных представлениях для конкретных задач.