Примерно 5 миллисекунд проходит от запроса до ответа, если данные хранятся на жестком диске. SSD отвечает в 30 раз быстрее — за 150 микросекунд. Оперативной памяти требуется в 300,000 раз меньше времени — лишь 15 наносекунд.*
Можно долго рассуждать о том, как бизнес-аналитика помогает финансам или логистике. Способов применить информацию много, все время появляются новые. Но принцип работы разных аналитических решений один и заключается он в том, чтобы соединить данные из разных источников и посмотреть на них вместе — то есть целиком.
Чтобы воспользоваться информацией из нескольких источников, нужно к ним подключиться и извлечь данные. Но данные создавались разными способами, с разной периодичностью и хранятся в разных форматах. Поэтому прежде, чем визуализировать данные или передать другим системам для дальнейшей обработки, их придется объединить с помощью каких-то математических операций — трансформировать.
Технология in-memory заключается в том, что для трансформации в оперативную память единовременно загружаются все данные из разных источников. После этого трансформацию можно выполнить «на лету», без запросов к диску. Например, кликом выбрать измерение и сразу получить график, который будет отображать значения показателей в нужном разрезе. Благодаря тому, что все данные уже в оперативной памяти, аналитическому приложению не нужно делать запросы к жесткому диску для получения новой информации.
Это вступление должно помочь мне рассказать о том, как и почему менялись технологии, лежащие в основе современных аналитических решений.
Сначала было дорого
«Память — это новый диск», — заявил исследователь из 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.
Решение нашлось в другом месте
В 1994 году тогда еще шведская компания QlikTech из небольшого города Лунд выпустила программу QuikView, которую позже переименовали в QlikView. Приложение было разработано для оптимизации производства. Оно позволяло узнать, использование каких деталей и материалов связано между собой, а каких — нет. То есть, от программы требовалось визуализировать логические взаимосвязи между частями, материалами, агрегатами и продуктами. Для этого она загружала в оперативную память наборы данных из разных источников, сопоставляла их и мгновенно показывала связи.
Например, есть несколько таблиц с актерами, их ролями в фильмах, режиссерами, жанрами, датой выхода, сборами — с чем угодно. Все они загружаются в оперативную память. Теперь можно кликом по любому параметру выбрать его и сразу увидеть все другие, которые с ним связаны. Кликаем по Брэду Питту — получаем кассовые сборы всех фильмов, в которых он снимался. Выбираем комедии — получаем сумму кассовых сборов комедий с Брэдом Питтом. Все это происходит мгновенно, в реальном времени.
Хотя в те годы на рынке корпоративных информационных систем аналитические задачи решались с помощью промежуточных моделей данных — OLAP-кубов, подход QlikTech оказался значительно удобнее. Он позволял отказаться от промежуточного этапа в виде расчета OLAP-куба и в результате сильно сэкономить.
Аналитическое приложение напрямую подключалось к источникам и периодически загружало все нужные для отчета данные в оперативную память. Исчезла необходимость каждый раз менять ETL-процессы для того, чтобы получить значения показателей в новых разрезах — теперь они подсчитывались в реальном времени в момент запроса. Отпала необходимость создавать и администрировать хранилище данных. Стоимость владения аналитическим решением резко снизилась.
С распространением 64-разрядных серверов, которые позволяли работать с большим объемом оперативной памяти, технология in-memory стала быстро менять бизнес-аналитику. Это хорошо иллюстрируют отчеты Magic Quadrant исследовательской компании Gartner. В 2016 квадрант лидеров покинуло сразу 6 разработчиков BI-платформ, среди которых оказались такие ветераны отрасли, как IBM, Oracle и SAP. Осталось лишь три игрока, сделавших ставку на технологию in-memory и отказавшихся от OLAP-кубов. Это Microsoft, Qlik и Tableau.
Можно сказать, что компания Qlik стала пионером и лидером трансформации рынка. К 2016 платформу для анализа данных QlikView использовали заказчики по всему миру, а годовой объем продаж превысил $600M.
От отчетов к управлению на основе данных
С распространением аналитических решений, основанных на технологии in-memory, перед огромным числом компаний открылась недоступные раньше способы использовать корпоративные данные. Появилась возможность не ограничиваться управленческими отчетами, которые стандартны для каждой из отраслей. Самые разные процессы стали «измерять» — вводить метрики и использовать их для описания процессов. Стало гораздо проще пользоваться объективной информацией, чтобы принимать более обоснованные решения. Резко выросло число работающих с данными бизнес-пользователей.
Огромное влияние на интерес к использованию данных оказали изменения потребительского поведения и маркетинга, который стал цифровым — то есть основанным на метриках. Много новых людей привлекли в Data Science ожидания от того, как мир изменит Big Data.
В результате всех этих процессов быстро произошла «демократизация» корпоративных данных. Раньше данные принадлежали ИТ-службам. Маркетинг, продажи, бизнес-аналитики и руководители обращались для получения отчетов в ИТ-службу. Теперь сотрудники работали с данными самостоятельно. Оказалось, прямой доступ сотрудников к данным способен повысить продуктивность работы и дать конкурентное преимущество.
Однако, первое поколение основанных на технологии in-memory аналитических решений давало бизнес-пользователям очень ограниченные возможности использовать данные. Они могли работать только с готовыми панелями и дэшбордами. Технология in-memory позволяла им «провалиться» вглубь любого показателя и увидеть, из чего он складывается. Но речь всегда шла о тех показателях, которые определены заранее. Исследование ограничивалось уже размещенными на дэшборде визуализациями. Такой способ использования данных получил название «направленная аналитика» и он не предполагал, что бизнес-пользователь самостоятельно займется подключением новых источников и будет сам создавать показатели и визуализации.
Следующим этапом на пути демократизации данных стало самообслуживание. Идея самообслуживания заключалась в том, что бизнес-пользователи исследуют данные, создавая визуализации и вводя новые показатели самостоятельно.
Стоит заметить, к моменту, когда технология in-memory стала менять бизнес-аналитику, уже не было серьезных технологических препятствий перед тем, чтобы дать пользователям доступ ко всем данным. Возможно, у самых консервативных заказчиков был вопрос о целесообразности такой функции. Но мир уже повернулся в сторону желания «посчитать все». Теперь менеджерам, не имеющим математического образования и навыков программирования, тоже требовался инструмент, который позволил бы говорить на языке данных.
Бизнес-аналитикам прямой доступ к данным открывал много новых возможностей. Они могли выдвигать и проверять любые гипотезы, применять методы Data Science, выявлять такие зависимости, существование которых трудно предположить заранее. Появилась возможность объединять внутренние корпоративные данные с внешними — полученными из сторонних источников.
В сентябре 2014 компания Qlik выпустила второе поколение своей платформы, которое получило название Qlik Sense. В Qlik Sense применялась та же архитектура и те же технологии. Отличие было в новом подходе к созданию визуализаций. Теперь стандартные визуализации можно было создавать «на лету», просто перетаскивая на лист поля с нужными измерениями. Это упростило исследование данных благодаря очень резкому сокращению цикла исследования. Проверка гипотезы стала занимать лишь пару секунд.
Возможно, быстрый рост продаж аналитических платформ с самообслуживанием во многом был связан с простотой демонстрации. Если раньше заказчику приходилось принимать решение о покупке, рассматривая слайды презентации, то теперь он мог сам установить на компьютер программу, подключиться к источникам и за пару часов пройти весь путь от создания дэшборда до открытия в своих данных.
Данные есть. Что теперь?
Технология in-memory сильно повлияла на то, как сегодня бизнес пользуется информацией. Объединять и исследовать данные стало проще, и это был сильный толчок бизнеса в сторону цифровой трансформации. Однако, глупо утверждать, будто цифровая трансформация превратилась в обыденность и теперь любая компания способна запросто ее осуществить.
С точки зрения технологий все просто до тех пор, пока объем изучаемых данных ограничивается несколькими Excel-таблицами. Если речь заходит об объединении миллиардов записей, то скорее всего задача по-прежнему окажется сложной с технической точки зрения, а ее решение потребует экспертизы в области BI и инженерных находок. Особенно если при этом еще требуется управлять качеством данных, что является обычной задачей для большинства средних и крупных компаний.
С точки зрения бизнеса все просто до тех пор, пока нужна отчетность или дэшборды со стандартными для отрасли показателями. Если же речь об аналитической системе, к которой постоянно добавляются новые источники, вводятся новые метрики, и во всем этом задействованы специалисты из разных областей, то здесь тоже нет никакой простоты.
Однако, это уже не те трудности, которые преодолевали заказчики несколько лет назад. Уровень зрелости аналитических платформ сегодня такой, что даже если исходных данных очень много, то ждать подсчета показателей больше не нужно, а полученным цифрам можно доверять. В основе случившейся трансформации — вычисления in-memory.
Следующей технологией, которая будет менять рынок аналитических решений, наверняка станут облачные платформы. Уже сегодня инфраструктура облачных сервис-провайдеров (CSP) вместе с набором услуг на ней превращается в платформу управления данными.
Опубликовано на Habr.ru
Источники:
* IDC, «Market Guide for In-Memory Computing Technologies», www.academia.edu/20067779/Market_Guide_for_In-Memory_Computing_Technologies
** Jim Gray «Distributed Computing Economics», www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2003-24.doc
*** Посмотреть, как менялось с 2010 по 2019 положение разработчиков BI-платформ в отчетах Gartner Magic Quadrant можно на интерактивной визуализации: qap.bitmetric.nl/extensions/magicquadrant/index.html