Примерно 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.
Положение игроков в Gartner’s Magic Quadrant for Analytics and Business Intelligence Platforms***
Можно сказать, что компания 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) вместе с набором услуг на ней превращается в платформу управления данными.
Источники:
* 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
Можно долго рассуждать о том, как бизнес-аналитика помогает финансам или логистике. Способов применить информацию много, все время появляются новые. Но принцип работы разных аналитических решений один и заключается он в том, чтобы соединить данные из разных источников и посмотреть на них вместе — то есть целиком.
Чтобы воспользоваться информацией из нескольких источников, нужно к ним подключиться и извлечь данные. Но данные создавались разными способами, с разной периодичностью и хранятся в разных форматах. Поэтому прежде, чем визуализировать данные или передать другим системам для дальнейшей обработки, их придется объединить с помощью каких-то математических операций — трансформировать.
Технология 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.
Положение игроков в Gartner’s Magic Quadrant for Analytics and Business Intelligence Platforms***
Можно сказать, что компания 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) вместе с набором услуг на ней превращается в платформу управления данными.
Источники:
* 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
