BI-системы: альтернативные решения

Будучи технологическим приоритетом № 1 для ИТ-директоров, системы класса Business Intelligence в прошлом году пользовались спросом в мире. Хотя традиционные подходы и инструментарий по-прежнему остаются популярными, заказчики все чаще склоняются к альтернативным вариантам. Их мы сегодня и рассмотрим.

Дело в том, что нестабильность экономической обстановки, породившая острую потребность в поиске резервов сохранения прибыли, подстегнула интерес организаций к инструментам бизнес-анализа. Это явление, в свою очередь, наложилось на продолжающийся бурный рост объемов данных, накапливаемых в учетных системах предприятий. На предпочтения потребителей BI-средств в мире сильное влияние оказала часто критикуемая ценовая политика крупных поставщиков корпоративного ПО (в основном из-за проблем заказчиков с технической поддержкой их аналитических систем, вызванных масштабным переделом рынка в 2007–2008 гг., когда Oracle приобрела Hyperion, SAP поглотила Business Objects, а IBM купила Cognos). Клиенты стали все чаще рассматривать альтернативные BI-технологии.

Рис.1. Традиционные BI-инструменты являются лишь визуальными механизмами построения SQL-запросов

Напомним, что в настоящее время наиболее распространенный способ построения систем бизнес-анализа – это сочетание BI-инструмента, такого как, например, SAP BusinessObjects XI, IBM Cognos BI, Oracle BI EE, и одной из реляционных СУБД – в Украине популярны Oracle Database и Microsoft SQL Server, а также MySQL, Sybase, IBM DB2 и пр. С технической позиции в такой связке BI-средство, по существу, выполняет роль визуального интерфейса. С его помощью пользователи формируют SQL-запросы, незаметно для них передаваемые на выполнение сервером СУБД. Отработанные последним результаты отправляются обратно в BI-инструмент, который и визуализирует их (рис. 1). В этом процессе этапы построения SQL-запроса и отображения результатов его работы являются относительно легкими с точки зрения ресурсоемкости – при количестве пользователей до полусотни с такой задачей под силу справиться BI-серверу, созданному на базе среднего десктопа. Основная нагрузка ложится на СУБД, которой требуется обработать иногда довольно сложные запросы на таблицах с сотнями тысяч и даже миллионами записей. Таким образом, именно СУБД представляет собой «сердце» аналитической системы, определяющей ее производительность и масштабируемость.

Немного истории

Популярные в наше время реляционные СУБД являются достаточно развитыми технологиями, отсчитывающими свою историю c начала 1970-х годов, когда радиоприемники были транзисторными, бакенбарды длинными, брюки расклешенными, а в мире баз данных преобладали иерархические и сетевые системы управления. Именно тогда в IBM стартовал проект System R, в рамках которого Дональд Чамберлин (Donald D. Chamberlin) и Реймонд Бойс (Raymond F. Boyce) работали над созданием реляционной СУБД и языка запросов Structured English Query Language (SEQUEL, позднее превратившийся в SQL). В 1977 г. Ларри Эллисоном (Larry Ellison) и его друзьями Бобом Майнером (Bob Miner) и Эдом Оатсом (Ed Oats) былa образована компания SDL, впоследствии переименованная в Oracle Corporation – в 1979 г. она разработала первую коммерческую реляционную СУБД, основанную на некоторых наработках System R.

Почти одновременно с этими событиями в 1975 г. в Университете Беркли профессорами Майклом Стоунбрекером (Michael Stonebraker) и Юджином Уонгом (Eugene Wong) был запущен исследовательский проект INGRES (INteractive Graphics and REtrieval System) с целью создания функционирующей реляционной СУБД, пригодной для использования в промышленных масштабах. Наработки, полученные проектной группой в INGRES, нашли дальнейшее распространение в ПО Informix и Sybase (к слову, одноименная компания в 1992 г. лицензировала свой продукт SQL Server корпорации Microsoft, которая стала развивать его самостоятельно под своим брендом).

Рис.2. Построчные СУБД читают с диска все поля таблицы независимо от запроса

Все эти проекты объединяет одно – стоящие за ними специалисты были вдохновлены материалами исследователя из IBM Эдгара Кодда (Edgar F. Codd), опубликованными еще в 1970 г. В них он предлагал хранить информацию в виде записей в таблицах, из которых одна или несколько записей могли быть извлечены с помощью запроса на языке высокого уровня, причем результаты запроса также могли быть представлены в табличном виде.

Главная задача баз данных тогда заключалась в том, чтобы поддержать начавшийся в 1960-х годах массовый переход от бумажного учета хозяйственной деятельности к компьютерному. Огромное количество информации из бумажных документов переносилось в БД учетных систем, которые должны были надежно хранить все входящие сведения и при необходимости быстро находить их. Такие требования обусловили архитектурные особенности СУБД того времени, оставшиеся до настоящего времени практически неизменными: построчное хранение данных, индексирование записей и журналирование операций. Хранение всей строки таблицы физически в виде одной записи, в которой поля идут последовательно одно за другим, а за последним полем записи идет первое следующей записи, чрезвычайно удобно для частых операций добавления новых строк в базу данных, хранящуюся на жестком диске – ведь в этом случае новая запись может быть добавлена целиком всего за один проход головки накопителя. Ограничения по скорости, накладываемые этими устройствами, вызвали необходимость введения специальных индексов, которые позволяли бы отыскивать нужную запись на диске за минимальное количество проходов головки HDD. Обычно формируется несколько индексов, в зависимости от того, по каким полям требуется делать поиск.

Однако в 1990-х, с распространением аналитических информационных систем и хранилищ данных, применявшихся для управленческого анализа накопленных в учетных системах сведений, стало понятно, что характер нагрузки в этих двух видах решений радикально отличается.

Если транзакционным приложениям свойственны очень частые массивные мелкие операции добавления или изменения одной или нескольких записей, то в случае аналитических инструментов картина противоположная – наибольшая нагрузка создается сравнительно редкими массивными выборками сотен тысяч и миллионов записей, часто с группировками и расчетом итоговых значений (так называемых агрегатов). Количество операций записи при этом невысоко, нередко менее 1% общего числа.

Естественно, разработчики СУБД не могли оставить без внимания запросы клиентов на оптимизацию производительности в аналитических приложениях. Одним из основных предложенных ими средств стали материализованные представления и многомерные кубы, которые могут использоваться для создания витрин данных (data marts) с предварительно рассчитанными результатами отдельных частых запросов, а также дополнительные аналитические функции в языке SQL. Эти новшества действительно помогли частично решить вопрос быстродействия, но не стали панацеей, так как эффект от их применения ограничивался небольшим набором запросов. Значительное же увеличение количества кубов и витрин приводит к экспоненциальному росту трудозатрат на поддержку и внесение изменений в систему. Архитектурные ограничения традиционных СУБД оставались, поэтому компании наращивали производительность по старинке, закупая более дорогое мощное оборудование.

Рис.3. Хранение данных по колонкам позволяет избежать чтения полей, не указанных в запросе

Отметим, что у аналитических выборок есть одна важная особенность – как правило, они содержат мало полей (по статистике в аналитическом SQL-запросе пользователя их редко бывает больше 7–8). Это объясняется тем, что человеческий разум не в состоянии нормально воспринимать информацию больше чем в 5–7 разрезах. Однако что произойдет, если выбрать, например, только 3 поля из таблицы, в которой их всего 50? В силу построчного хранения данных в традиционных СУБД (необходимого, как мы помним, для частых операций добавления новых записей в учетных системах) будут прочитаны абсолютно все строки целиком со всеми полями. Это значит, что не важно, нужны ли нам только 3 поля или 50, с диска в любом случае они все будут прочитаны полностью, пропущены через канал дискового ввода-вывода и переданы процессору, который уже отберет только необходимые для запроса (рис. 2). К сожалению, каналы дискового ввода-вывода обычно являются самым узким местом в общей производительности аналитических систем. Как результат, эффективность традиционной СУБД при выполнении данного запроса может снизиться в 10–15 раз. Причем действие закона Мура на скорость ввода-вывода дисковых накопителей куда слабее, чем на скорость процессоров и объемы памяти. Так что, видимо, дальше ситуация будет только усугубляться.

Что же делать? Благодаря агрессивным законам рынка в течение последних 5–10 лет появилось по меньшей мере полтора десятка новых игроков, предлагающих вполне работоспособные альтернативы аналитическим системам с традиционной архитектурой. Эти альтернативы можно сгруппировать в несколько категорий: суперконтроллеры ввода-вывода (Super I/O), колоночные СУБД (column-oriented DBMS), нереляционные in-memory BI-средства и комбинированные решения. Рассмотрим их детальнее.

Супер-контроллеры ввода-вывода

Один из способов решения описанной выше проблемы состоит в том, чтобы запрограммировать контроллер ввода-вывода на отсев ненужных полей еще во время выполнения низкоуровневых операций чтения. Для этого стандартные контроллеры заменяются на чипы FPGA (Field-Programmable Gate Array), которые становятся, по сути, суперконтроллерами. Микрокод такого устройства можно изменять «на лету». Так, настроив в FPGA отсеивание ненужных полей непосредственно перед отработкой SQL-запроса на выборку данных, мы получаем частичное выполнение запроса на аппаратном уровне. В приведенном выше примере использование суперконтроллера позволит передать через канал ввода-вывода между контроллером и процессором не 50 полей, а только 3. Программно-аппаратные решения, построенные по такому принципу, производит, например, компания Netezza. Как правило, это преднастроенные серверы на платформе Intel с дисковыми хранилищами, где развернута собственная СУБД Netezza. Большинство BI-средств имеют драйверы, позволяющие им подключаться к Netezza как к любой традиционной системе управления базами данных. Загрузка информации в систему может осуществляться как средствами самой Netezza, так и сторонними ETL-инструментами.

Колоночные СУБД

Существует класс специализированных СУБД, разработанных специально для сферы бизнес-анализа, ключевой особенностью которых является хранение данных не по строкам, как в традиционных системах, а по колонкам. Рассмотрим принцип действия такого решения на примере перспективной аналитической СУБД Vertica. Она берет свои истоки из академического проекта C-store, в котором участвовали студенты и преподаватели Массачусетского технологического института, Университета Брауна и Университета Брандейса под управлением Майкла Стоунбрекера, того самого, который когда-то организовал проект INGRES.

Несмотря на то что логически данные представлены в Vertica в виде таблиц, как и в любой другой реляционной СУБД, физически таблицы разделены на отдельные колонки, в каждой из которых находятся значения только одного поля. Такая организация хранения данных имеет несколько преимуществ для аналитических систем. Во-первых, при выполнении SQL-запросов с диска читаются только те поля, которые, собственно, и фигурируют в запросе. Если вернуться к рассмотренному выше примеру, это будет означать, что вместо 50 полей с диска будут прочитаны только 3. Следовательно, скорость выполнения такого запроса посредством Vertica может быть в 10–15 раз выше, чем с использованием традиционной СУБД (рис. 3). Во-вторых, хранение данных по колонкам позволяет гораздо лучше сжимать их, ведь сведения в одном поле (колонке), как правило, одного типа, а значит, они намного более однородны, чем данные в строке. Это позволяет подвергать их компрессии, достигая 8–10-кратного уменьшения объемов информации. Сжатие не только обеспечивает экономию места на диске, но и в разы снижает нагрузку на каналы ввода-вывода за счет незначительного ее увеличения на процессор (который, как мы помним, редко является узким местом в производительности BI-систем). Благодаря однородности данных можно использовать оптимальные алгоритмы сжатия. Например, если у нас есть таблица со 100 млн записей, сделанных в течение одного года, то в колонке «Дата» на самом деле будет храниться не более 366 возможных значений. Поэтому мы можем 100 млн отсортированных значений в этом поле заменить на 366 пар <дата, количество раз> и хранить их на диске в таком виде. При этом они будут занимать приблизительно в 100 тыс. раз меньше места, что также способствует повышению скорости выполнения запросов. Достаточно интересной особенностью Vertica является возможность выполнения некоторых итоговых вычислений непосредственно на сжатых данных без их декомпрессии.

Рис. 4. QlikView отличают удобный интерфейс пользователя и высокое быстродействие, получаемое в результате обработки всех данных в оперативной памяти

Во всем остальном Vertica является обычной реляционной СУБД, которая отвечает «классическим» требованиям ACID (atomicity, consistency, isolation, durability, т. е. атомарность, цельность, изолированность, отказоустойчивость) к обработке транзакций и поддерживает стандарт SQL-99, так что может использоваться совместно с любыми традиционными SQL-ориентированными BI-инструментами и ETL-средствами. Из других подобного рода СУБД стоит также отметить ParAccel и Sybase IQ.

Нереляционные in-memory BI-инструменты

До этого момента мы рассматривали примеры, где традиционное BI-приложение работало с альтернативной, но все же реляционной СУБД, применяемой для обработки запросов. Теперь настало время упомянуть BI-инструменты, такие как QlikView, Tibco Spotfire и Cognos TM1, которым вообще не нужна СУБД, – они используют собственный механизм обработки информации, работающий по принципу in-memory. Он предполагает загрузку всех данных в оперативную память и последующее исполнение аналитических запросов на них без потребности в обращении к дисковой подсистеме. Этот принцип позволяет ликвидировать проблему медленных каналов ввода-вывода, так как шина обмена данными процессора с оперативной памятью работает намного быстрее дискового ввода-вывода даже при использовании SSD-накопителей. Естественно, при этом возникает другая проблема – высокая стоимость памяти, но благодаря действию закона Мура и тайваньским производителям, постоянно снижающим цены на платы, ее актуальность постепенно снижается. Уместно заметить, что, конечно же, терабайты данных по технологии in-memory обработать пока не получится. Но это только пока.

В остальном же спрос на такие инструменты, как QlikView, быстро растет благодаря феноменально высокой скорости их работы, удобному интерфейсу (рис. 4) и довольно сжатым срокам проектов построения BI-систем, которые стали возможны из-за отсутствия необходимости в построении кубов, агрегатов или каких-либо других промежуточных структур данных.

Комбинированные решения

И, наконец, есть комбинированные решения, которые могут объединять в разных вариациях упомянутые выше концептуальные подходы, например Kickfire, совмещающий специализированный сервер с технологией in-memory. Moжно также отметить попытки SAP задействовать технологию in-memory в своем продукте BusinessObjects Explorer, для которого требуется соответствующая аппаратная поддержка в виде BW Accelerator. Впрочем, комбинированные решения пока только начинают набирать популярность и число их внедрений в мире все еще незначительно.

Резюме

Интересно наблюдать за рождением нового поколения архитектур и решений для аналитических систем, уже прошедших промышленную апробацию в рамках нескольких тысяч внедрений, но еще не ставших стандартом де-факто. Но, вполне вероятно, что сбудется предсказание Карла Олофсона (Carl Olofson), вице-президента по исследованиям в области СУБД и интеграции данных IDC, который сказал: «В течение следующих пяти лет многие из этих новых систем заставят вас забыть о дисковых схемах разделения данных, стратегиях индексирования и управления буферами и откроют мир возможностей больших объемов оперативной памяти многопроцессорности и многоядерности, кластеров и высококомпрессированного колоночного хранения информации».

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365