Проблемы разработки и сопровождения хранилищ данных
Недооценка ресурсов загрузки
При объединении множества первичных источников трудно заранее оценить длительность и ресурсоемкость загрузки. Пока информация собирается и заливается в хранилище, аналитический вопрос может потерять актуальность: приходит новое состояние бизнеса, и требуется новый анализ. За процессом объединения данных стоят программное и аппаратное сопровождение, а значит, большие финансовые инвестиции. Если затраты выше выгоды от ответа, проект становится неэффективным.
Скрытые проблемы источников данных
Хранилище не проверяет корректность данных и принимает то, что вобрало внутрь. Если в источнике есть ошибка, ответ на аналитический вопрос тоже будет ошибочным. Поэтому важны проверка согласованности первичных источников и инструменты аудита данных.
Отсутствие требуемых данных в архивах
Для ответа на сложный запрос может не хватать информации, которой нет ни в одном источнике. Причина — бизнес-процессы и техническое задание не предусмотрели логирование нужных данных. В результате при формировании сложного запроса использовать нечего.
Повышение требований конечных пользователей
С хранилищем взаимодействуют бизнес-аналитики и дата-сайентисты. Их требования меняются: нужны новые данные и новые возможности инструмента. Если при выборе хранилища учитывали только текущую задачу, через 3–5 лет дорогая архитектура может перестать отвечать требованиям. Поэтому выбор вендора — важнейший процесс. Лучше потратить время на анализ рынка, конкурентов, формирование требований с запасом на рост, учесть историю вендора и его кейсы. Молодые компании и стартапы предлагают новаторские идеи, но часто не отвечают корпоративным требованиям. Их идеи нередко поглощаются крупными вендорами и интегрируются в известные решения.
Унификация данных
Хранилище собирает информацию из разных источников, но единообразия обычно нет. Различаются формы хранения и форматы, например даты. Один и тот же сотрудник в разных бизнес-процессах может иметь разные внутренние номера, потому что действует от разных ролей. На уровне объединения данных нужно выполнить мейпинг (mapping) — сопоставить номера 35 и 79 одному Ивану Иванову. Это сложная задача, частично решаемая на уровне хранилища.
Высокие требования к ресурсам
Чем крупнее компания, тем больше и сложнее данные. Соответственно, растут требования к ресурсам, обслуживающим всю цепочку работы с данными.
Владение данными
Актуальна проблема права владеть информацией, особенно персональными данными. Законы регламентируют, кто имеет право владеть такими сведениями. Возникает вопрос: можно ли сливать нужные для анализа данные в хранилище и есть ли право ими владеть. В корпоративных системах данные часто деперсонализируются: аналитик видит не фамилию, а набор цифр и букв. Деперсонализация может касаться и числовых значений: факт наличия счета известен, а объем средств — нет.
Сложное сопровождение и долговременные проекты
Система многофакторная, состоит из множества элементов и решает широкий спектр задач. Сопровождение такой структуры затратно и не всегда эффективно. Хранилище чаще видит информацию на вчерашний день. Чтобы извлечь данные, нужно задание от бизнес-аналитика, участие администратора хранилища, администраторов, программистов и технических сотрудников. Даже простая задача вроде выгрузки года рождения человека может занять так много времени, что информация потеряет актуальность. Первичная установка хранилища в крупной корпорации может длиться 3–5 лет.
Сложности интеграции
Источников много, и интегрировать их вместе — отдельная кропотливая задача.
Архитектура хранилища данных
Источники и ODS
Слева находятся источники оперативных данных: базы данных и OLTP-источники (Online Transaction Processing, оперативная обработка транзакций). Они хранят информацию по отдельным бизнес-процессам. Формально они через диспетчер загрузки выгружают содержимое в хранилище, но правильнее считать инициатором выгрузки само хранилище: у него есть разрешение забирать данные. Информация из оперативных источников поступает также в ODS (Operational Data Store, операционное хранилище данных). Далее ODS через тот же диспетчер загрузки поставляет информацию в хранилище.
Диспетчер загрузки и ETL
Внутри хранилища работает диспетчер загрузки. Его процедуры приводят данные к единообразию, модифицируют и чистят их. Например, в базе HR-отдела могут храниться email, ИНН, СНИЛС сотрудника. Для хранилища эти данные бессмысленны для анализа и стратегических решений. Поэтому сумма данных хранилища меньше суммы данных первичных источников. В диспетчере загрузки также происходит агрегирование, если оно требуется. Множество процессов внутри диспетчера загрузки называется ETL-процедурами (Extract, Transform, Load — извлечение, преобразование, загрузка). ETL извлекает данные, преобразует их (чистка, суммирование, проверка согласованности), затем загружает в хранилище.
Чистка и агрегация
Агрегация нужна, например, чтобы хранить продажи по категориям продуктов. В первичном источнике лежат все продажи по каждому продукту, но для анализа их можно сразу сегрегировать и суммировать по категории. Тогда бизнес-аналитику не нужно просить хранилище суммировать одинаковые категории. Чаще всего необходимый уровень агрегации делается заранее, хотя иногда суммирование происходит только по факту требования.
Метаданные
Метаданные — это данные о данных. Они хранят карту хранилища: что лежит, откуда взялось, как преобразовано, в каком анализе или отчете используется. Это структурированное описание, часто отдельная база данных, XML- или JSON-файл. С помощью инструмента бизнес-аналитик может визуализировать метаданные, искать и фильтровать их, понять, какие данные есть, в какой форме и формате их можно выгрузить. Метаданные позволяют аналитику и администратору быстро понимать друг друга: например, сослаться на поля номер 15, 17 и 39. По сути, это техническое задание на хранилище в структурированной форме.
Внутренний диспетчер и уровни данных
Внутри хранилища есть собственный диспетчер хранилища данных, который обеспечивает внутренние процессы. В хранилище находятся подробные данные — очищенные и приведенные к единообразию данные из первичных источников и ODS. Далее идут данные с низкой степенью агрегирования, например суммирование по категориям продуктов, и данные с высокой степенью агрегирования, например продажи по регионам. Уровень агрегации определяется требованиями бизнес-аналитика.
Архив и резервные копии
Ниже расположены архивные данные или резервные копии. У хранилища, как и у базы данных, должна быть репликация — возможность откатиться к версии с заданным шагом резервного копирования. При отказе можно быстро переключиться на резервную копию, не потерять новые процессы и сохранить возможность анализа. Резервная копия может отставать от актуальной версии, но она позволяет не потерять уже сохраненные данные.
Диспетчер запросов и инструменты пользователей
Диспетчер запросов обеспечивает выполнение запросов от конечных пользователей к хранилищу. Среди инструментов: формирование отчетов, запросов, разработка приложений и ЕИС (EIS); инструменты OLAP (Online Analytical Processing, оперативная аналитическая обработка) и OLAP-отчетности, включая многомерный куб; инструменты глубокого анализа данных — data mining (интеллектуальный анализ данных), которые позволяют интегрировать данные с алгоритмами машинного обучения и искусственного интеллекта для прогноза; инструменты доступа конечных пользователей через клиентские приложения.
Макроархитектура
На макроуровне архитектура хранилища включает источники, ODS, диспетчер загрузки, ETL, чистку, агрегацию, метаданные, внутренний диспетчер, архив, диспетчер запросов и пользовательские инструменты. Внутреннее устройство цилиндров — подробных данных, данных с низкой и высокой степенью агрегации — будет рассматриваться как архитектура далее.
Краткие итоги
Практическая ценность хранилища проявляется не в самом факте сбора данных, а в способности своевременно превращать разрозненные сведения в ответы, пригодные для решения текущих задач. Если сбор и преобразование занимают больше времени, чем период актуальности вопроса, даже технически корректная система теряет смысл. Поэтому проектирование начинается не с выбора инструмента, а с оценки ресурсов, источников, требований и ограничений владения данными. Ошибки источников не исчезают при загрузке: хранилище принимает их как истину, значит, качество анализа напрямую зависит от согласованности и аудита первичных систем. Отсутствие нужных данных оказывается следствием более ранних решений в бизнес-процессах, когда необходимость логирования не была учтена. Рост требований пользователей превращает выбор вендора в стратегическое решение: архитектура должна допускать развитие, иначе через несколько лет она перестанет отвечать новым задачам. Унификация и mapping показывают, что данные разных процессов описывают одни объекты по-разному; без сопоставления невозможна достоверная агрегация. Ограничения владения и деперсонализация влияют на доступность персональных и чувствительных сведений, поэтому аналитик получает не все данные, а только разрешенные. Сложное сопровождение и длительность проектов требуют организационной зрелости: многие роли участвуют в цепочке, а задержки снижают актуальность. Архитектура хранилища отвечает на эти проблемы разделением потоков загрузки и запросов. ETL, чистка и агрегация готовят данные заранее; метаданные делают хранилище понятным и управляемым; репликация снижает риски отказа; OLAP, data mining и клиентские инструменты обеспечивают анализ и прогноз. Практическое применение требует баланса между детализацией и агрегацией, между полнотой данных и правом на владение, между стоимостью загрузки и ценностью ответа. Только такой баланс превращает хранилище в рабочий инструмент поддержки решений.
Проблемы хранилищ данных
Недооценка ресурсов загрузки. При объединении множества источников трудно заранее оценить длительность и ресурсоемкость. Пока данные собираются, аналитический вопрос может потерять актуальность. За процессом стоят программное и аппаратное сопровождение, большие инвестиции. Если затраты выше выгоды, проект неэффективен.
Скрытые проблемы источников. Хранилище не проверяет корректность данных и принимает их как истину. Ошибка источника дает ошибочный ответ. Нужны проверка согласованности и аудит.
Отсутствие требуемых данных. Для сложного запроса может не хватать информации, которой нет в источниках, потому что бизнес-процессы не предусмотрели логирование.
Рост требований пользователей. Бизнес-аналитики и дата-сайентисты меняют требования, нужны новые данные и возможности инструмента. Если архитектура выбрана только под текущую задачу, через 3–5 лет она может не отвечать требованиям. Выбор вендора важен: нужны анализ рынка, конкурентов, требований с запасом на рост, история и кейсы вендора. Молодые стартапы предлагают идеи, но часто не отвечают корпоративным требованиям; их идеи поглощаются крупными вендорами.
Унификация данных. Источники различаются форматами, формами хранения и идентификаторами. Один сотрудник в разных процессах может иметь разные номера. Нужен mapping — сопоставление разных идентификаторов одному объекту.
Ресурсы и владение данными. Чем крупнее компания, тем больше и сложнее данные, тем выше требования к ресурсам. Законы ограничивают владение персональными данными. Применяется деперсонализация: аналитик видит коды, а не фамилии; может знать факт счета, но не объем средств.
Сопровождение и проекты. Система многофакторная, сопровождение затратно. Хранилище видит данные часто на вчера. Для выгрузки нужны бизнес-аналитик, администратор хранилища, администраторы, программисты. Даже простая задача может потерять актуальность. Установка в крупной корпорации может длиться 3–5 лет. Интеграция множества источников — отдельная сложная задача.
Архитектура хранилища
Источники и ODS. Слева — источники оперативных данных: базы данных и OLTP-источники (Online Transaction Processing). Они хранят информацию по бизнес-процессам. Через диспетчер загрузки они выгружают данные в хранилище, но инициатор — хранилище, у которого есть разрешение забирать данные. Информация также поступает в ODS (Operational Data Store, операционное хранилище данных), затем через диспетчер загрузки — в хранилище.
Диспетчер загрузки и ETL. Внутри хранилища диспетчер загрузки приводит данные к единообразию, модифицирует и чистит. Например, ИНН, СНИЛС, email из HR не нужны для анализа, поэтому сумма данных хранилища меньше суммы источников. Здесь же выполняется агрегирование. Процессы внутри диспетчера — ETL (Extract, Transform, Load): извлечение, преобразование, загрузка. Преобразование включает чистку, суммирование, проверку согласованности.
Агрегация. Например, продажи по каждому продукту можно сразу суммировать по категориям. Тогда аналитику не нужно просить хранилище суммировать. Чаще всего нужный уровень агрегации делается заранее.
Метаданные. Метаданные — данные о данных. Это карта хранилища: что лежит, откуда, как преобразовано, где используется. Это структурированное описание, часто отдельная база, XML или JSON. Бизнес-аналитик через инструмент визуализирует и ищет метаданные, понимает, какие данные есть, в какой форме и формате. Аналитик и администратор могут ссылаться на поля, например 15, 17, 39. Метаданные — техническое задание в структурированной форме.
Внутренний диспетчер и уровни данных. Диспетчер хранилища данных обслуживает внутренние процессы. Хранятся подробные данные — очищенные данные из источников и ODS; данные с низкой агрегацией, например по категориям; данные с высокой агрегацией, например по регионам. Уровень агрегации определяется требованиями аналитика.
Архив и репликация. Ниже — архивные данные или резервные копии. Нужна репликация — возможность откатиться к версии с заданным шагом резервного копирования. При отказе можно переключиться на копию, не потерять данные и сохранить анализ.
Диспетчер запросов и инструменты. Диспетчер запросов обеспечивает запросы конечных пользователей. Инструменты: отчеты, запросы, разработка приложений и ЕИС (EIS); OLAP (Online Analytical Processing) и OLAP-отчетность, многомерный куб; data mining — глубокий анализ, интеграция с машинным обучением и ИИ для прогноза; клиентские приложения для доступа.
Макроархитектура. На макроуровне: источники, ODS, диспетчер загрузки, ETL, чистка, агрегация, метаданные, внутренний диспетчер, архив, диспетчер запросов, пользовательские инструменты. Внутреннее устройство уровней данных рассматривается как архитектура далее.
1. Недооценка ресурсов загрузки может сделать анализ неактуальным до получения ответа.
2. Хранилище не проверяет корректность источников, поэтому ошибки источников переходят в ошибки анализа.
3. Отсутствие нужных данных в архивах связано с недоучетом логирования в бизнес-процессах.
4. Рост требований пользователей требует запаса развития при выборе вендора и архитектуры.
5. Молодые стартапы часто предлагают идеи, но не отвечают корпоративным требованиям.
6. Унификация данных нужна из-за разных форматов, идентификаторов и ролей одного объекта.
7. Mapping сопоставляет разные идентификаторы одному физическому объекту.
8. Высокие требования к ресурсам растут вместе с объемом и сложностью данных.
9. Владение данными ограничено законами, поэтому применяется деперсонализация.
10. Сопровождение хранилища сложное и долговременное из-за множества участников и процессов.
11. ETL выполняет извлечение, преобразование и загрузку, включая чистку и агрегацию.
12. Метаданные, репликация, диспетчер запросов, OLAP и data mining обеспечивают управляемость, устойчивость и анализ.
1. Почему недооценка ресурсов загрузки может обесценить аналитический ответ?
2. Как хранилище относится к корректности данных из первичных источников?
3. Какие меры снижают риск скрытых ошибок источников?
4. Почему отсутствие данных в архивах связано с проектированием бизнес-процессов?
5. Как рост требований пользователей влияет на выбор вендора хранилища?
6. Почему молодые стартапы редко становятся поставщиками корпоративных хранилищ?
7. В чем суть унификации данных и mapping?
8. Какие данные могут не попадать в хранилище из-за ограничений владения?
9. Почему сопровождение хранилища сложное и долговременное?
10. Как ODS связан с источниками и хранилищем?
11. Какие операции выполняет ETL и диспетчер загрузки?
12. Зачем нужны метаданные, архив, репликация и диспетчер запросов?
