Аналитическая обработка данных — далеко не новая задача для департаментов ИТ. Однако сегодня в этой области предъявляются новые специфические требования, которые можно считать проверкой на прочность для существующих универсальных подходов и технологических решений.
Компании, особенно, те, что работают на высококонкурентных «клиентоцентрических» рынках, используют аналитику не только в процессе принятия долгосрочных стратегических, но тактических и даже оперативных решений. Число пользователей аналитических систем увеличивается — их берет на вооружение не только высшее руководство, но также менеджеры среднего звена и сотрудники подразделений. Объемы и сложность обрабатываемых данных, а также сложность аналитических запросов неуклонно растут.
Для обеспечения конкурентоспособности компании зачастую необходима очень высокая скорость реакции на происходящие изменения и способность быстро находить новые источники конкурентных преимуществ. Все это требует анализа любых данных в новых разрезах практически «на лету» (ad hoc). Следовательно, потребности бизнеса в аналитической информации становятся все менее предсказуемыми и оставляют ИТ-подразделениям все меньше времени на подготовку.
Нередко в организациях повышаются требования и к актуальности данных. Например, для идентификации мошеннических финансовых транзакций и своевременного реагирования на них необходим анализ транзакционных данных в режиме реального времени. В то же время, для управления складом такая степень актуальности явно избыточна.
Все вышеперечисленное предъявляет к системам аналитической обработки данных целый ряд жестких требований. Коротко говоря, это необходимость обеспечивать очень высокую производительность при обработке даже очень больших (и быстро растущих!) объемов данных и большом количестве пользователей при не всегда предсказуемых задачах.
Четыре подхода
Существуют четыре основных архитектурных подхода, которые используются для подготовки отчетности и выполнения аналитических запросов. Первый: выполнение аналитических запросов и отчетов непосредственно в транзакционных (Online Transaction Processing, OLTP) системах, таких как ERP, АБС, системы учета трафика и биллинга и др. В этом случае в одной и той же СУБД происходит обработка данных двух типов — транзакционная и аналитическая. Такой подход прост в управлении, поскольку приходится поддерживать всего одну копию базы данных. Однако аналитические запросы по своей природе очень сильно отличаются от транзакционной обработки данных. В отличие от операций вставки и обновления данных, характерных для транзакционной обработки, выборки данных в аналитических запросах часто включают множество сложных циклов. OLTP-системы с трудом справляются с аналитическими задачами, и рано или поздно наступает предел, после которого любые попытки оптимизировать производительность генерации отчетов становятся малоэффективными. Кроме этого, задачи аналитической обработки и генерации отчетности нередко вступают в конфликт с прямой задачей OLTP-системы — оперативной обработкой данных, производительность которой в периоды выполнения аналитических запросов резко падает.
Второй подход, применяемый для решения проблем с производительностью, — создание отдельной копии оперативной базы, предназначенной для генерации отчетов. Эти системы, как правило, называются отчетными серверами или оперативными складами данных. Традиционно при этом применяется односторонняя репликация данных без изменения их структуры. Обновление данных осуществляется в заданные интервалы, определяемые в зависимости от текущих аналитических потребностей бизнеса. Создание отчетных серверов – недорогой способ сохранения производительности оперативных систем за счет разделения двух принципиально разных типов рабочей нагрузки на СУБД. Возможности оптимизации таких отчетных серверов очень ограничены.
Третий подход — создание витрин данных, спроектированных специально для аналитической обработки и имеющих принципиально другие схемы данных, чем те, что применяются в OLTP-системах. Кроме того, данные транзакционных систем не просто реплицируются в витрины, а проходят определенную подготовку — процессы извлечения, преобразования и загрузки. Для повышения производительности и снижения затрат на создание и сопровождение в витринах хранятся в основном агрегированные значения, а не детальные данные. Витрины также содержат ограниченные наборы данных, необходимые для анализа в определенных предметных областях. С одной стороны, это позволяет сократить объем данных в витрине, с другой — накладывает ограничения на доступ к данным и, соответственно, на функциональные возможности для пользователей.
Четвертый подход — создание корпоративных хранилищ данных. На сегодня это самый эффективный путь интеграции всех корпоративных данных из различных оперативных систем с целью создания общедоступного единого источника данных, предназначенного для эффективного решения задач в области аналитики и отчетности в масштабах всей компании. Данные, поступающие в хранилище, проходят процедуры очистки, трансформации, агрегации и согласования, что должно обеспечить достоверность и прозрачность получаемой в результате информации.
Компоненты аналитических систем
Витрины и хранилища данных имеют сходную с точки зрения технологических компонентов структуру. В обоих случаях для извлечения данных из оперативных источников, их очистки, преобразования и загрузки в хранилище применяются специальные инструменты, такие как DataStage, Informatica, Sunopsis, Sybase ETL и др. Эти инструменты специально разработаны для высокопроизводительной загрузки больших объемов данных с необходимой частотой, вплоть до режима реального времени.
И в хранилище, и в витрине данные должны быть загружены в оптимальную для аналитических задач структуру и проиндексированы. Именно эта роль отводится СУБД. От этого компонента технологической структуры витрин и хранилищ данных в значительной степени зависит функциональность и стоимость аналитической системы, а также то, насколько полно пользователи смогут использовать богатые возможности, заложенные в средствах формирования запросов и генерации отчетов.
СУБД для витрин и хранилищ данных
Принимаясь за выбор технологических компонентов аналитических систем, ИТ-департамент, как правило, основное внимание уделяет инструментам подготовки отчетов и анализа информации, средствам интеграции данных.
Вопрос о выборе СУБД для аналитической системы в большинстве случаев вообще не стоит из-за кажущейся очевидности этого решения: в организации уже существует корпоративный стандарт, имеются сертифицированные специалисты по определенной СУБД, закуплена корпоративная лицензия. В результате в качестве платформы выбирается одна из традиционных «универсальных» СУБД (IBM DB2, MS SQL Server, Oracle, Sybase ASE), которые изначально создавались для обработки транзакций.
Несмотря на то, что все традиционные СУБД были оптимизированы вендорами для аналитической обработки, их внутренняя структура, созданная когда-то с учетом специфики задач транзакционной обработки данных, не могла быть принципиально изменена. Именно этим фактором обусловлены ограничения этих СУБД при использовании их для аналитических задач. Достижение приемлемой производительности загрузки и обработки данных требует высоких затрат на аппаратное обеспечение, сложные настройки и администрирование.
Структура и принципы работы «универсальных» СУБД диктуют необходимость создания сложных, занимающих большие объемы таблиц индексов и агрегатов для обеспечения производительной аналитической обработки. Эти таблицы значительно увеличивают объемы данных в аналитической системе по сравнению с объемом загружаемых «сырых» оперативных данных. Этот феномен известен под названием «взрыв данных». Коэффициент взрыва по статистике составляет пять-десять раз. Другими словами, 100 Гбайт «сырых» данных после помещения в «универсальную» СУБД для аналитической обработки превратятся в 0,5–1 Тбайт со всеми вытекающими последствиями в виде затрат на аппаратное обеспечение и обслуживание.
С ростом объемов данных, количества пользователей и запросов для оптимизации производительности потребуется дальнейшее наращивание аппаратных ресурсов и все более трудоемкие настройки СУБД. При этом интервал между появлением необходимости в новом отчете и его получением неуклонно возрастает, пока, наконец, не становится неприемлемым. Аналитическая работа пользователей с применением произвольных запросов чаще всего попросту запрещена, поскольку весьма проблематична.
Почему же «универсальные» СУБД, несмотря на перечисленные ограничения, остаются достаточно популярными в качестве основы для создания аналитических систем? На наш взгляд, в первую очередь это связано с тем, что альтернативные технологии пока менее известны на рынке. И все же необходимость решать аналитические задачи все чаще вынуждает компании искать специальные решения. Альтернативу «универсальным» представляют специализированные СУБД, которые изначально разрабатывались и проектировались в расчете на выполнение только аналитической обработки данных.
В чем же состоит специализация и принципиальные отличия аналитических СУБД от «универсальных»? В разных аналитических СУБД реализованы различные идеологии, которые объединяет то, что все они рассчитаны на специфику аналитической обработки данных.
Один из примеров — «инвертная» СУБД, то есть СУБД с «перевернутой» по сравнению с традиционной внутренней структурой. Построчное хранение данных, реализованное во всех «универсальных» СУБД и являющееся оптимальным для транзакционной обработки данных, для аналитики — источник серьезных ограничений. Применение одного только «инвертного» хранения данных не по рядам, а по колонкам позволяет получить в десятки раз более высокую производительность аналитической обработки в сравнении с «универсальными» СУБД, причем не за счет аппаратных мощностей, а за счет «специального» дизайна СУБД. Согласно данным исследования компании Bloor Research, проведенного по заказу Sybase, поколоночное хранение попросту приводит к сокращению в сотни раз количества необходимых операций ввода-вывода при поиске запрашиваемых значений.
«Инвертный» дизайн СУБД также позволяет применять для достижения очень высокой производительности аналитической обработки специальные индексы, учитывающие специфику этой задачи. В чем же их отличие от индексов, применямых в «универсальных» СУБД, ориентированных изначально на транзакционную обработку данных? Транзакционная обработка — это выборка конкретной записи (или их небольшого количества) с отбором по ключевой колонке. При такой обработке запросы всегда однотипны, и классические индексы, основанные на сбалансированных деревьях (B-tree), являются очень эффективными. Индексы, базирующиеся на битовых картах (bitmap), применяются в «универсальных» СУБД ограниченно, так как, во-первых, расширение их применения приводит к значительному увеличению объемов базы, и, во-вторых, использование этих индексов эффективно только для колонок с малым количеством уникальных значений (например, колонка «пол»), а между тем в запросах участвуют не только такие колонки.
В «инвертной» аналитической СУБД возможной становится индексация каждой отдельной колонки, и создавать индексы, группирующие несколько колонок для выполнения конкретного запроса (такие индексы называются композитными), не требуется. После того как отдельно проиндексирована каждая колонка, подбор комбинации индексов для конкретного запроса выполняется автоматически очень быстро непосредственно при выполнении любого нового незапланированного запроса.
Кроме этого, для аналитической обработки существуют специальные индексы, вообще не используемые в «универсальных» СУБД и позволяющие очень быстро проводить аналитические операции: индексы для даты времени, индекс, хранящий результат сравнения двух колонок, текстовый индекс для поиска слов в тексте (например, он применяется, если требуется найти людей, у которых в адресе их проживания указана определенная улица, но названия улиц не вынесены в отдельную колонку), расширенные индексы на базе битовых карт для работы с колонками, хранящими большое количество уникальных значений.
Таким образом, индексация производится на этапе построения хранилища, основываясь на знаниях о характере данных, а не о конкретных запросах. Это делает возможной высокопроизводительную обработку любых произвольных запросов.
Результатом использования поколоночного хранения в комбинации со специальными технологиями индексирования является то, что агрегаты могут формироваться «на лету». При том, что значительная часть работ по извлечению, преобразованию и загрузке данных состоит в предварительной агрегации транзакционных данных (расчет показателей в процессе загрузки данных в хранилище), необходимость в этой части работ во многом отпадает. Кроме прочего, этот подход также обеспечивает большую гибкость, поскольку не всегда заранее известно, что нужно агрегировать.
Как отмечают аналитики Bloor Research, поколоночное хранение данных позволяет избежать пресловутого «взрыва данных». Это объясняется тем, что при такой организации хранения алгоритм компрессии работает гораздо эффективнее и быстрее, поскольку применяется к каждой отдельной колонке, в которой хранятся абсолютно однородные данные. В большинстве случаев объем хранилища будет меньше или равен объему исходных данных, что позволяет уменьшить требуемое дисковое пространство и, как следствие, сократить необходимые объемы инвестиций в аппаратное обеспечение. Кроме того, в инвертной базе данных добавить и загрузить колонку данных к таблице так же легко, как добавить запись в традиционную базу данных. Эта гибкость может заинтересовать разных пользователей, в частности тех, кому нужен анализ в режиме реального времени.
Следует помнить о том, что любая специализированная технология хороша для определенного класса задач. Например, аналитическая СУБД Sybase IQ из-за своего инвертного дизайна практически непригодна и никогда не рекомендуется в качестве платформы систем, поддерживающих текущие операции. Транзакционная обработка данных выполнялась бы в этой СУБД крайне медленно.
И конечно, выбирая СУБД для витрин и хранилищ данных, следует критически относиться к заявлениям поставщиков СУБД и обращать особое внимание на нюансы их возможностей. Например, если специальная технология является слишком «экзотической» и сложной в усвоении для специалистов по «универсальным» СУБД, или если эта технология требует обязательного применения нестандартных дорогостоящих аппаратных платформ и операционных систем, стоит тщательно взвесить получаемые преимущества и необходимые затраты. Не менее важно, насколько «зрелой» является технология — как давно она представлена на рынке и сколько существует внедрений. Третий важный критерий — качество поддержки и надежность вендора.
Алена Еникеева — заместитель генерального директора, Business Development, Sybase CIS, Alyona.Yenikeyeva@sybase.ru
Максим Львов — менеджер по маркетингу, BI Practice, Sybase CIS, Maxim.Lvov@sybase.ru