Сначала было дорого
«Память — это новый диск», — заявил исследователь из Microsoft Джим Грей (Jim Grey) в начале нулевых. В 2003 году он опубликовал статью «Экономика распределенных вычислений»**, где сопоставил стоимость разных этапов компьютерной обработки данных. Джим Грей показал, что вычисления должны быть там же, где находятся данные — чтобы лишний раз их не перемещать. Он советовал передвинуть вычисления как можно ближе к источникам данных. То есть, отфильтровать данные как можно раньше и в результате сэкономить.
В течение нескольких следующих лет на рынке появились in-memory СУБД сразу от нескольких лидеров индустрии, включая Oracle, IBM, и SAP, а также несколько open source проектов — например, Redis и MemcacheDB.
Первой задачей, которую решали in-memory СУБД, оказалась не бизнес-аналитика и даже не бизнес-приложения, а возможности для электронной коммерции, открывающиеся в связи с мгновенным извлечением информации. Например, in-memory СУБД могла бы позволить интернет-магазину в реальном времени предложить покупателям товары на основе их предпочтений, либо показывать рекламу.
Рынок решений для анализа корпоративных данных тем временем развивался по другой траектории. Большинство предприятий неразрывно связаны с системами, использующими транзакционные СУБД, которые основаны на принципах, разработанных еще в 80-х годах прошлого века. Их задача — постоянно сохранять на диск идущие потоком небольшие порции данных и сразу подтверждать их целостность (OLTP-сценарий работы). Среди систем, использующих такие СУБД — ERP-решения, автоматизированные банковские системы, биллинг, POS-терминалы.
Но аналитические задачи требуют от базы данных совсем другое. Здесь нужно быстро извлекать ранее сохраненную информацию. Причем большими кусками — для каждого аналитического отчета понадобятся абсолютно все данные, которые должны быть в нем отражены. Даже если сам отчет состоит из одной цифры.
Причем выгружать данные хорошо бы как можно реже, потому что их объем может быть велик, а загрузка большого набора данных с помощью аналитических запросов натолкнется на несколько препятствий.
Во-первых, жесткий диск, хранящий информацию, является медленным накопителем. Во-вторых, сама структура хранения данных в традиционной СУБД не позволит ей быстро выполнить аналитический запрос. Данные сохранялись построчно — по мере их поступления, поэтому физически рядом находятся значения, которые относятся к одной строке. А в ответ на аналитический запрос базе данных требуется отдать значения одного столбца, но из разных строк. Поэтому такие запросы выполняются медленно и создают большую нагрузку на систему хранения данных. То есть, расположение информации на диске организовано неподходящим способом.
Таким образом, традиционные СУБД, в которых изначально сохранялась вся исходная для анализа информация, плохо подходили для того, чтобы выполнять роль источника данных, к которому аналитическая система подключается напрямую. Поэтому в прошлом веке для аналитических задач стандартной практикой было использование промежуточной модели данных, в которой все значения уже рассчитаны на какой-то момент времени. Такая модель данных называлась «аналитическим кубом», или OLAP-кубом. Для создания OLAP-куба разрабатывались так-называемые ETL-процессы (extract, transform, load) — запросы к базам данных в исходных системах и правила, в соответствии с которыми нужно осуществить преобразования данных. Очевидно, если в OLAP-кубе какой-то информации нет, то в отчете она появиться не может.
Проблема этого подхода заключалась в высокой стоимости решения. Во-первых, требовалось хранилище данных, куда будут помещаться пред-рассчитанные показатели. Во-вторых, если какой-то показатель понадобился нам в другом разрезе, то чтобы его получить, все процессы трансформации данных на пути от исходной системы к OLAP-кубу приходилось создать заново, переписав аналитические запросы. После чего пересчитать весь OLAP-куб, что занимало несколько часов.
Допустим, OLAP-куб содержит информацию о продажах по разным странам. Но финансовый директор вдруг захотел увидеть продажи в разрезе городов, а потом сгруппировать их по среднему чеку. Для получения такого отчета ему приходилось обращаться в ИТ-службу, чтобы она перестроила OLAP-куб. Либо он мог форсировать события и привлечь знатока MS Excel, который создал бы такой отчет вручную. Для этого ему приходилось выгружать с помощью аналитических запросов данные из исходных систем в таблицы и проделывать с ними ряд трудоемких и недекларируемых манипуляций.
В первом случае финансовому директору приходилось ждать. Во втором он получал цифры, которым трудно доверять.
К тому же, решение оказывалось очень дорогим. Нужно было потратить деньги на создание хранилища, которое надо администрировать. Требовалось нанять специалистов по СУБД для того, чтобы они занимались ETL — перестраивали OLAP-кубы под каждую из задач. Параллельно в компании обычно появлялись специальные аналитики, которые создавали отчеты по запросу (так-называемые ad-hoc отчеты). Фактически они изобретали разные способы получить нужный отчет с помощью MS Excel и преодолевали трудности, связанные с тем, что эта программа предназначена для других задач.
В результате путь получения отчетности был дорогим даже для крупных компаний. Менеджерам из небольшого и среднего бизнеса приходилось довольствоваться возможностями, которые есть в программе MS Excel.