Краткий обзор рынка
Сегодня можно уже с уверенностью говорить, что СУБД (DBMS, Data Base Management System) для Хранилищ из традиционных средств хранения данных, поддерживающих BI-пользователей, эволюционировали в аналитические инфраструктурные репозитории предприятий.
Рынок находится в постоянном движении, потому что, несмотря на активные разработки и маркетинговые кампании крупных поставщиков, появляются все новые и новые участники. Многие организации внедряют технически тонкие решения, но большинство все-таки следует девизу: «простота внедрения, быстрый запуск, удовлетворение 80% требований».
Конечно, крупные DBMS-поставщики за этот год многого добились, пытаясь достичь баланса между масштабом и инновационной функциональностью. Однако мелкие разработчики часто предлагают более целенаправленное и продуманное решение. Пока особый статус и хорошие шансы на выживание имеют некоторые компании, специализирующиеся в области устройств для ХД.
Клиенты выдвигают все более серьезные требования (даже по сравнению с прошлым годом), и не так уж много поставщиков, которым удается их удовлетворить.
Среди традиционных лидеров на данном рынке (IBM, Oracle, Teradata) теперь присутствует и Microsoft SQL Server 2005. (Продукт Microsoft SQL Server 2008, выход которого планируется на первую половину 2008 года, обеспечит ряд новых возможностей, отвечающих требованиям к современной СУБД для ХД, а следовательно, упрочит позицию производителя).
Для организаций, которым нужно точечное решение для конкретной аналитической задачи или группы конечных пользователей, могут оказаться полезными средства Netezza, DatAllegro, Sybase и ряд других.
Кроме того, можно заметить, что рынок переходит от исполнения обычных функций СУБД (в том числе и поддержки аналитических приложений в реальном времени) к решению критически важных для бизнеса задач путем автоматизации ключевых процессов. Некоторые поставщики, ставящие перед собой именно такую задачу, за минувший год существенно продвинулись и занимают лидерские позиции на рынке.
Примером может быть перенос вычислительных мощностей на уровень ближе к уровню хранения (например, вертикальные СУБД фирм Sand technology, Sybase IQ и Vertica поддерживают эффективные подбор (sub-selection) хранимых данных и сокращение ввода/вывода). Кроме того, размер баз становится менее важным. В прошлом, покупатели считали, что лидером является поставщик СУБД, поддерживающей самое крупное хранилище. Однако сегодня и средние ХД (5-20Тбайт) решают основные аналитически задачи организации.
В целом, все эти проблемы усложняют задачу IT по удовлетворению клиентского видения Хранилища, в том числе и по уровню сервиса.
По мнению экспертов и аналитических компаний, в наступившем 2008 году на рынке появятся новые поставщики СУБД (например, EnterpriseDB GridSQL, i-lluminate, ParAccel and Vertica), которые сегодня уже удовлетворяют множеству, хотя и не всем требованиям.
Продолжается и «лихорадка» с устройствами для ХД, которые впервые прочно укрепились на этом рынке только в 2006 году. Успех DATAllegro и Netezza на почве предоставления преконфигурированных, сбалансированных решений в виде устройств подстегнул ряд поставщиков оборудования и программного обеспечения к сотрудничеству на данном рынке. В 2007 году эта тенденция получила дальнейшее развитие. Например, появившийся в конце 2006 года продукт, созданный компанией Greenplum в сотрудничестве с Sun, также занял достойное место среди конкурентов.
Смешанная нагрузка
Еще большее значение приобретает «изменяющаяся смешанная нагрузка» (changing mixed workload), влияющая на эффективность ХД. Это одна из первых проблем, с которой сталкиваются поставщики и о которой мы уже упоминали в прошлогоднем обзоре. Серьезные аналитики применяют структурированные сложные запросы, а также быстро выполняемые тактические запросы, что требует больших ресурсов процессоров, памяти и дискового пространства. У всех компаний свои требования к уровню сервиса, но с каждым годом длительность задержки данных сокращается.
Подводя итоги за позапрошлый 2006 год, мы упоминали четыре типа нагрузки:
- непрерывная (почти в реальном времени) загрузка данных - похожа на загрузку при оперативной обработке транзакций (OLTP), требует постоянного обновления индексов и других оптимизационных структур. Ставит дополнительные задачи управления суммарными и агрегированными данными, в частности в плане поддержки инструментальных панелей и готовых отчетов;
- большое количество стандартных отчетов, исчисляемых тысячами в день, требующих настройки SQL и создания индексов, новых типов оптимизационных структур в Хранилищах;
- растущее число пользователей, выполняющих нерегламентируемые запросы. Это, в свою очередь, создает неопределенность в отношении использования данных, а значит, невозможность их специальной настройки (оптимизации) для этих запросов;
- растущий объем аналитики и BI-ориентированной функциональности в OLTP-приложениях, требующий тактического использования ХД в качестве источника информации для транзакционных приложений, где важной задачей является быстрое выполнение запросов.
Сегодня нужно упомянуть еще два типа нагрузки:
- пакетная загрузка данных, которая все еще продолжает применяться, поскольку стало очевидно, что отнюдь не все данные обязательно получать с минимальной задержкой: если какие-то данные меняются не часто, значит, не все записи необходимо обновлять в реальном времени;
- тактическая бизнес-аналитика, где специалисты в области бизнес-процессов, не имеющие достаточного опыта создания собственных запросов, используют готовые аналитические объекты с агрегированными или детализированными данными. Они пользуются разработками BI-архитектора, который заранее готовит наиболее часто используемые OLAP-кубы или таблицы.
Шесть типов нагрузки ставят перед поставщиками существенно более сложные задачи, чем раньше. Ближайшие 2-3 года эффективность обработки смешанной нагрузки останется самой главной проблемой. Критически важной является и балансировка физического перемещения данных в электронной и цифровой среде, распределения дисковых и оперативных ресурсов памяти.
В связи с нарастанием смешанной нагрузки, которая сопровождается непрерывной загрузкой данных и ростом числа автоматизированных транзакций из функциональной аналитики в OLTP, получат преимущество транзакционные СУБД, позволяющие добиться более высокой эффективности в этой ситуации.
Оптимизация и эффективность
Еще один из эффектов растущей сложности и объема данных заключается в том, что компании по-разному оценивают необходимые ресурсы для поддержки корпоративного Хранилища и сопутствующих витрин данных.
Частично, такие отличия можно связать с сочетанием:
- ресурсов, необходимых для поддержки физического Хранилища (например, для управления и реорганизации базы данных, для балансировки нагрузки),
- и ресурсов, требующихся для логического моделирования, понимания бизнес-процессов, оптимизации и повышения эффективности.
Однако все ХД требуют оптимизации. В некоторых случаях сочетание логических дизайнов создает физические подходы в базе, такие как автоматизированные итоговые таблицы и различные типы физических представлений.
В иных случаях оптимизация требует проектирования и разработки физических таблиц, формируемых в результате ETL-процессов в микропакетах, в течение дня или даже часа. СУБД, ранее классифицировавшиеся как «общецелевые» (такие как DB2, Oracle и SQL-сервер), требуют небольших административных ресурсов, поскольку поставщики автоматизировали большое количество служебных и управляющих функций. В то же время, даже специализированные DBMS требуют более автоматизированного системного управления. Так как объемы данных, извлеченных из исходных систем, колеблется в среднем от 5 до 20 Тбайт, то особенно важным в проектировании ХД становится применение отраслевых стандартов.
Доступ к Хранилищу необходим для множества приложений, оптимизация которых является важным моментом. Фактически, методы оптимизации и уровни доступа нужно рассматривать как информационные семантические уровни, которые повышают возможности использования данных в Хранилище. Эти приложения могут запускать сложные последовательности запросов существенно быстрее, чем это сделает конечный пользователь вручную.
Возрастают проблемы, связанные с необходимым для оптимизации Хранилища объемом физического носителя, который, по оценкам, на порядок больше, чем объем извлеченных исходных данных. Важно заметить, что поскольку оптимизация может и должна применяться ко всем СУБД, то все Хранилища по объему больше, чем исходно загруженные в них данные. Соотношение оптимизационных требований в Хранилище к исходным данным, извлеченным из системы, изменяется в течение жизненного цикла ХД. Исходно требуется полная оптимизация, когда множество различных приложений требует множества стратегий оптимизации.
По мере старения ХД, соотношение падает, так как более детальные объемы данных не обязательно требуют дополнительного пространства для оптимизации. Кроме того, поскольку размер всего Хранилища растет, то объем пространства для хранения индексов начинает падать и, соответственно, снижается и коэффициент. И поэтому очень важна работа с бизнес-подразделениями, чтобы можно было выявить реальную необходимость в детальных данных и в итоговых данных в Хранилище. Многие клиенты сообщают о хранении информации за десять лет, хотя на практике вполне достаточно сведений за последние пять лет.
Кроме того, чем больше компаний, внедряющих ХД, тем больше меняются требования к квалификации внедряющего персонала: неквалифицированный архитектор данных может испортить самую лучшую платформу.
Новые разработки и оптимальные методики
Недавние разработки (2006-2007 гг.) указывают на рост популярности «распределенных Хранилищ данных», использующих единую логическую модель со множеством физических мест расположения. Данные логически разделяются на домены (например, все записи, относящиеся к конкретному региону, ко всем данным клиентов из одного места и т.п.) и распределяются без дублированных записей по различным точкам (locations). Причин для использования такого подхода множество - начиная от создания физических зон безопасности данных и заканчивая аналитическими операциями, основывающимися на временных зонах. Нельзя путать этот подход с интегрированной моделью (federated), которая включает дискретные логические модели с использованием таблиц транслитерации и является не лучшим практическим методом технологии ХД.
В 2006 году (по инициативе компании Kognitio) появилась практика предоставления Хранилищ данных в качестве управляемого сервиса. Поставщик СУБД разрабатывает и обеспечивает функционирование Хранилища на своем сервере и предлагает его клиенту. Первые подобные проекты появились на уровне бизнес-подразделений (так как отдельному подразделению дешевле и удобнее приобрести услугу, вместо того чтобы использовать корпоративное хранилище и постоянно прибегать к IT- и консалтинговым услугам).
Однако такие разработки не всегда оказывались удачными и экономичными. В 2007 году данная модель была расширена: предложено (в частности, компанией Greenplum) использование Хранилища в виде услуги в масштабах организации. И теперь предполагается дальнейшее расширение доли рынка, где будет применяться такая модель, особенно для конкретных отделов или специфических DW-приложений. Вероятно, все это переродится в SaaS-модель (модель использования ПО в качестве услуги) для организаций малого и среднего бизнеса, которым не хватает опыта и средств для поддержки собственного крупного Хранилища.
Витрины данных
В результате более широкого распространения и разнообразия различных приложений, основанных на технологии ХД, а также в связи с разнообразными смешанными нагрузками, распространение витрин данных вновь становится важной задачей. Витрину данных можно считать аналитическим репозиторием для конкретной прикладной сферы, любого размера, но, как правило, с ограниченной, небольшой группой пользователей. Витрины могут применяться для оптимизации корпоративных Хранилищ (EDW) за счет частичного снижения нагрузки путем переноса ее в витрину, что повышает эффективность ХД в целом.
Кроме того, в последнее время наблюдается рост витрин данных, специально использующихся в аналитических целях. Это связано не только с аналитической нагрузкой Хранилища, но и с тем, что ряд СУБД теперь обладает развитой аналитической функциональностью, особенно СУБД, ориентированные на хранение данных по колонкам (ParAccel, Sand/DNA Analytics, Sybase IQ), которые дают существенно более высокие результаты в отношении эффективности по сравнению с традиционными СУБД. Однако выполнение сложной системы запросов со множественными операциями объединения (joints) при таком подходе дает отнюдь не лучшие, а иногда и худшие результаты. Поэтому СУБД, где применяется хранение по колонкам, не идеальны для корпоративных Хранилищ.
Заключение
В целом рынок СУБД для Хранилищ данных продолжает активно развиваться и решать все новые и новые задачи, возникающие вследствие повышения бизнес-требований и нарастания конкуренции среди поставщиков.