Построение хранилищ данных (Оптимизация СХД для

Построение хранилищ данных (для Cnews)
Гаяне Арутюнян, архитектор решений по бизнес аналитике IBM в России и СНГ.
Какие существуют инструменты и способы для построения (оптимизации) хранилищ
данных?
Необходимость оптимизации хранилищ данных возникает в том случае, когда данных
становится на порядок больше: наблюдается их рост, либо расширяется круг бизнес-задач.
Это приводит к резкому увеличению потока данных, который
компания должна
обрабатывать за единицу времени. В этом случае встает вопрос о трансформации
существующей архитектуры. Процесс оптимизации (трансформации архитектуры)
затрагивает все звенья цепочки создания хранилища данных отвечающего требованиям
бизнес-пользователей. Если немного затронуть теорию построения хранилищ данных, то
можно выделить 6 последовательных уровней архитектуры.На практике, однако, нашим
заказчикам не всегда требуются все уровни.. Первый уровень – это, безусловно, сами
источники данных, с которыми нам предстоит в дальнейшем работать. Второй уровень
называется ETL (Extract Transform Load). На этом уровне происходит извлечение и
трансформация данных, иначе говоря: приведение данных к согласованному виду и их
загрузка в новое хранилище. Третий уровень – уровень подготовки правильных данных для
загрузки в хранилище, и их защита от несанкционированного доступа. На этом уровне
формируется нормативно справочная информация (НСИ), создаются метаданные, и идет
процесс доставки данных в хранилище. Четвёртый уровень – это уровень подготовки
данных и их доставки в так называемые витрины данных с учётом задач, которые будут
выполняться в витринах. Пятый уровень – предоставление данных. Его роль заключается в
формировании
витрины данных, которые формируются уже по высокоуровневым
функциональным и прикладным признакам. При формировании витрин данных заказчик
руководствуется знаниями о том, кто будет использовать эти данные, и какая именно
информация должна содержаться в витринах. Шестой уровень – это уже непосредственно
бизнес приложения, которые являются потребителями данных. Уровень бизнес-приложений
представлен сценарными расчетами, статистическим анализом, многомерным анализом,
средствами планирования и подготовки отчетности.
Портфолио IBM предлагает реализацию перечисленных уровней построения хранилища в
виде целого набора программных продуктов из семейства Information management IBM
InfoSphere Warehouse. По существу, это законченная платформа, имеющая модульную
архитектуру и позволяющая автоматизировать многие задачи и реализовать практически все
аспекты интеграции данных при построении крупных хранилищ.
В идеале, возможность оптимизации закладывается на этапе планирования системы, в
процессе разработки архитектуры будущего решения. Кроме того, правильно
спроектированная система должна предусматривать возможность масштабирования
хранилища. Именно на этом раннем этапе должны обсуждаться ключевые вопросы: какие
задачи должно решать хранилище? Возможна ли интеграция данных из различных
приложений? Каким образом будет обеспечиваться передача данных в хранилище? Какие
механизмы будут задействованы в процессе очистки данных? какие требуются референсные
модели и НСИ? какой должна быть скорость передачи данных? Решение этих вопросов на
раннем этапе позволит создать хранилище данных изначально оптимизированным. В
противном случае, заказчик приобретёт некий набор программных и аппаратных средств,
хороших по отдельности, но при этом не способных удовлетворить требованиям заказчика.
Когда возникает необходимость в этом и существует ли возможность избежать столь
трудоемкой процедуры?
Необходимость оптимизации возникает при увеличении объемов данных, усложнении или
расширении количества бизнес-процессов, или при увеличении количества систем.
Типичный случай, когда без оптимизации не обойтись — слияние бизнеса компаний.
Избежать оптимизации хранилищ данных (ХД) при слиянии компаний практически
невозможно, поскольку происходит трансформация самих данных в источнике.
При решении задачи такого типа наиболее важно сохранить чистоту данных, перемещаемых
в объединенное хранилище. Нередко задачу консолидации и масштабируемости пытаются
решить на аппаратном уровне. Это приводит к потере доверия бизнес-пользователей к той
информации, которая помещается в хранилище. Поэтому особое внимание следует уделять
так называемому процессу ETL.
Средства извлечения, преобразования и загрузки данных (ETL) должны
обладать полной мета-информацией об источниках данных. В первую очередь, к метаинформацией относятся структуры и форматы хранимых данных, различия в алгоритмах
обработки данных, смысл хранящихся данных, график выполнения обработки
информации в транзакционных системах. Игнорирование этой мета-информации неизбежно
приводит к ухудшению качества данных, загружаемых в
хранилище. Как следствие, пользователи пытаются настроить прямой доступ к источникам
данных в обход многоуровневой системы фильтрации, что приводит к неоправданным
временным затратам специалистов, эксплуатирующих системы – источники данных.
Мой коллега Сабир Асадуллаев привел образную иллюстрацию современного хранилища
данных, которой я бы хотела с вами поделиться.
Хранилища данных похожи на системы очистки воды. Вода собирается из разных
источников с разным химическим составом. Поэтому в каждом конкретном случае
применяются свои методы очистки и обеззараживания воды. Вода, отвечающая строгим
стандартам качества, поступает к потребителям. И как бы мы ни жаловались на качество
воды, именно такой подход предотвращает распространение эпидемий в большом городе.
И никому не приходит в голову обогатить очищенную воду водой из ближайшей лужи.
По вашему мнению, крупный российский бизнес уже дорос до того, чтобы уйти от
принципа "хранить все" к принципу "хранить только необходимое"? Сравните,
пожалуйста, ситуацию на отечественном и развитых рынках.
Существуют внешние факторы, которые определяют рамки и объемы хранения информации.
Одним из таких факторов являются нормативные требования, законодательная база,
отраслевые требования, внутренние распорядки компании. Примером могут служить
требования, предъявляемые к хранению информации о пациентах, установленные
министерством здравоохранения.
В остальном требования к хранилищу данных
формируются самим заказчиком согласно требованиям бизнеса. Часть данных должна
храниться в оперативном хранилище, потому что качество бизнес-процессов зависит от
быстроты доступа к ним. В некоторых бизнес-областях бывает что необходимо «хранить
всё», но эта формулировкаобычно затрагивает конкретную задачу, которую необходимо
решить в определённый момент времени. С другой стороны, существуют виды деятельности,
в которых заказчик принципиально не знает, какая информация может потребоваться в
следующий момент. В таком случае требования к хранилищу могут содержать некоторую
избыточность.
Сравнивая российский рынок с другими, можно отметить недостаточную подготовленность
российского заказчика к вопросу о том, какая информация ему нужна. Западный заказчик, как
правило, формулирует критерии более четко и заранее их продумывает. Наши заказчики
часто формируют свои требования уже на этапе проектирования решения.
Кроме того необходимо учесть что построение корпоративных хранилищ данных требует
усилий не только ИТ специалистов.
В первую очередь это потребует ряд организационных мероприятий для понимания
функциональных подразделений компаний их задач и ролей.
Затем потребуется выполнение ряда методологических мероприятий направленных на
разработку НСИ и стандартов.
И лишь в последнюю очередь задача построения хранилища данных затронет ИТ
специалистов, которые будут должны обеспечить исполнение организационных и
методологических мероприятий.
Опираясь на какие методы, можно определить, какую информацию не нужно хранить,
какая должна быть в оперативном доступе, какую можно архивировать?
Самый распространённый метод – беседа с заказчиком. Хотя есть и инструментальные
методы оценки востребованности данных. Инструментальный мониторинг помогает
выстроить жизненный цикл данных, понять, кто и насколько часто ими пользуется. Однако,
система мониторинга способна определить лишь формальную частоту обращения к данным, ,
но не реальную важность этих данных для бизнеса. Следовательно, требуется сочетание
инструментальных методов и беседы с заказчиком.
Автоматизированная оценка
востребованности данных в чистом виде подходит лишь для узкоспециальных задач, таких,
как архивация данных или построение многоуровневых файловых систем.
На основании чего выбираются способы архивации данных? Какие из этих способов
самые дорогостоящие? Лучше пояснить на примере.
Отталкиваться нужно на такие параметры как частота и скорость доступа к данным,
надежность и срок хранения данных. Например, есть ленточные хранилища для
долгосрочного хранения данных, время жизни которых достигает десятка лет, однако время
доступа к ним исчисляется минутами, а иногда и часами. Жесткие диски обеспечивают
сравнительно быстрый доступ к данным и сравнительно высокую степень надежности
хранения. Типичное время жизни жестких дисков составляет 3 года, оптимистичная оценка –
5 лет. Активно набирает темп и наиболее дорогостоящий на данный момент вид носителей:
твердотельные диски. Они обеспечивают чрезвычайно высокую скорость доступа, однако
срок хранения данных на них и количество обращений пока недостаточно велики, для их
повсеместного использования.
"Чистят" ли ваши заказчики базы данных (хранилища данных)? Если да, то по каким
принципам осуществляется поиск ненужных данных, отчетов?
Как правило, осуществлять очистку внутри хранилища, если в нём уже содержаться не
нормированные данные, очень сложно. Если такая необходимость возникла, то, скорей всего,
придется перестраивать хранилище и проводить этап ETL для всех источников данных
повторно. Жизненный цикл информации должен устанавливаться на этапе планирования
СХД, тогда «чистка» данных будет автоматизирована и не потребует дополнительных
манипуляций со стороны заказчика. В принципе, для хранилищ данных, как и для многих
других систем, применимы функции архивирования что позволяет снизить нагрузку на
системы.
Также просьба предоставить комментарии 2-3-х клиентов.
Вопросы:
Охарактеризуйте, пожалуйста, масштаб баз данных, используемых вашей BI-системой.
Сейчас крупные заказчики IBM достигли 10-ков террабайт данных, обычно это суммарные
величины от нескольких систем. Что касатся BI-систем, то представители SMB (Small and
medium business) работают с объёмами в пределах 500Gb, более крупный бизнес может
выдвигать требования по 2-3 ТБ для хранения и обработки данных в BI-системах. Но время
идёт и мы выдим что требования завакчиков очень быстро изменяются, возрастают.
Для решения каких задач используется аналитика?
Аналитика прежде всего используется для оценки эффективности деятельности компании.
Пожалуй есть три ключевых вопроса для ответа на которые используются
аналитические системы:
Как мы работаем? Это достигается путём контроля за текущим состоянием бизнеса и
мониторинга ключевых показателей бизнеса
показателям.
Почему мы так работаем? Понимание этого приходит, когда мы получаем отчёты и
анализируя ситуацию ищем закономерности и причины успеха или неудач.
Что нужно делать? Пожалуй, это самый сложный вопрос и здесь мы руководствуемся и
учитываем ряд рыночных факторов, изучаем прогнозы аналитиков, строим статистические
модели, которые позволят нам оптимальным образом сделать выводы и, как следствие,
распределять ресурсы организации, корректировать стратегию бизнеса и предпринимать
управляющие воздействия.
Большинство пользователей систем занимаются созданием отчетов, отвечая на вопросы: как
мы работаем,и почему мы так работаем? И лишь 8-10%
процентов занимается
предиктивным анализом, отвечая на вопрос:что же делать?
Сталкиваетесь ли вы с проблемой неконтролируемого роста данных? Если да, то
почему она появилась, и как вы пытаетесь ее решить?
Неконтролируемый рост данных может возникнуть в контексте укрупнения, расширения
бизнеса, когда внедряются новые системы, или когда речь идёт о переход с одной
программной платформы на другую. И некоторые экономические факторы, например
вовремя кризиса в определённых отрослях мы наблюдали активные действия связанные со
слиянием различных компаний И как следствие увеличение нагрузки на ИТ и чрезмерный
рост объёмов данных.