Время фундаментальных исследований и тестирований различных алгоритмов в области Big Data, по всей видимости, подошло к логическому завершению: уже существующие решения на базе Fast Data (быстрых данных) тихо совершают свою революцию в переработке гигантских объёмов запросов и информации в минимальные отрезки времени, приближая бизнес к идее ответов и регуляции процессов в режиме реального времени.
Разумеется, если посмотреть, как устроен любой сервис с применением подобных технологий, становится понятно, что всё далеко не так просто, как может подумать при звонке, например в банк или транспортную компанию.
Если даже навскидку определить, какое число сервисов задействовано в макросервисе компании: например, при звонке клиента, он попадает сначала в голосовой центр, где происходит аутентификация абонента в несколько стадий, затем, уже при полноценном участии голосового робота, происходит интеллектуальное распознавание вопроса, ответ, вообще диалог.
Самое интересное – потом, то есть сам процесс принятия решения по тем вопросам, которые озвучены клиентом: получение какой-то услуги, уточнение, предложение похожего варианта, и- как крайний случай – переключение на оператора в случае отсутствия готового решения в алгоритме робота.
Конечно, это крайне упрощённое описание процесса, есть и запросы в различные собственные и общедоступные базы, поиск пересечений, аномалий и многое другое.
То есть приоритет Fast Data в доступе и обработке потока информации очевиден, машинное обучение смогло уже дойти до того уровня, когда система сама может для принятия решения брать информацию из открытых источников, корректно интерпретировать её и выносить независимое решение.
Несомненное преимущество такого подхода – в быстроте обработки, когда информация перерабатывается не в объёмных хранилищах, а приходит в момент запроса и, за счёт снижения количества внутренних обработок хранилища и, самое главное, в скорости получения данных внутри корпоративной сети: если взять за идеальный запрос получение данных в течение 1 секунды, то в неё нам нужно вместить: скорость принятия решения о запросе, отправку, получение, попадание в нужное ранжирование для лучшей скорости в приоритете ответа на именно наш запрос, затем – при согласовании всех параметров – отправка запроса к хранилищу данных (если повезёт – к уже кэшированной информации), получение объёма ответа, формирование пакета, и наконец – отправка нам, опять же с учётом выделенной скорости на запросы такого уровня.
То есть, нужно понимать, что, несмотря на скорость, например, 1 терабит в сети, пакет физически не пойдёт с такой скоростью – вмешаются другие параллельные данные, разбиение на части и сборка в конечном узле.
То есть, Fast Data даёт возможность существенно снизить нагрузку на систему с количеством запросов, превышающих десятки тысяч в одну секунду.
Если представить себе, что сервис получает только 1000 запросов в секунду, и соотнести с количеством фильтров (в том же банке, например) – то есть опознавание, удостоверение, распределение, и это только названия процессов – а в каждом находится сложный алгоритм, который на каждом шагу генерирует множество логических развилок, проверок и своих внутренних запросов, то становится понятно, что такой вал данных в рамках одного центра в концепции «всё в одном» сейчас не выдерживает никакой конкуренции.
Поэтому виртуализация и набирает обороты – скорость доступа к данным и пропускная способность внутренних и внешних сетей до сих пор остаются лимитирующими процессами, которые Fast Data пока успешно преодолевают.
