Один из наших кластеров для пилотных задач (Data node: 18 servers /2 CPUs, 12 Cores, 64GB RAM/, 12 Disks, 3 TB, SATA — HP DL380g)
— Что такое Big Data вообще?
Все знают, что это обработка огромных массивов данных. Но, например, работа с Oracle-базой на 20 Гигабайт или 4 Петабайта — это ещё не Big Data, это просто highload-БД.
— Так в чём ключевое отличие Big Data от «обычных» highload-систем?
В возможности строить гибкие запросы. Реляционная база данных, в силу своей архитектуры, предназначена для коротких быстрых запросов, идущих однотипным потоком. Если вы вдруг решите выйти за пределы таких запросов и собрать новый сложный, то базу придётся переписывать – или же она умрёт под нагрузкой.
— Откуда берётся эта новая нагрузка?
Если чуть углубиться в архитектуру, то можно увидеть, что традиционные базы данных хранят информацию очень дисперсионно. Например, у нас номер абонента может быть на одном сервере в одной таблице, а его баланс — в другой таблице. Быстродействие требует максимального разбиения данных. Как только мы начинаем делать сложные join'ы, производительность резко падает.
— Есть пример такой задачи?
Вот пример: нам стало интересно, когда люди переходят на современные смарфтоны с «кирпичей»-звонилок. Оказалось, что есть достаточно чёткий порог: для жителя Москвы, например, сочетание старого телефона 2007-го года и использования ряда сервисов вкупе с большим потреблением трафика может означать желание перейти на смартфон. Соответственно, увидев такую границу, мы посмотрели, на какие именно модели переходят люди. И пошли дальше – решили находить тех, кто готов прямо сегодня приобрести такой телефон. А дальше – вопрос техники. У нас есть около 250 офисов продаж в Москве. Мы выделяем группу тех, кто в течение недели решит перейти на смартфон по нашим данным. Мониторим, когда один из них подойдёт на 50 метров к нашему салону. А затем отправляем ему SMS с рекомендацией про «зайти посмотреть», если в данном салоне есть смартфон и если он готов к демонстрации. Традиционную систему такая задача просто взорвёт.
— И как это решается?
Нужна другая архитектура базы данных. Если вам нужны гибкие запросы, то проще всего хранить данные неструктурированно — потому что для каждого нового запроса придётся иначе строить новую оптимальную структуру. Обычные базы данных направлены на максимальное быстродействие в рамках ограниченных вычислительных ресурсов.
— Так давайте просто промасштабируем их — и проблема решится?
В целом, если есть куда масштабироваться — да, это выход. Согласитесь, проще докупить пару серверов или СХД, чем переписывать всю структуру БД. Однако в случае именно больших данных это не очень просто. Реляционные базы данных маштабируются достаточно сложно, как правило, до бутылочного горлышка в единой СХД. Есть горизонтальный порог масштабирования, после которого становится проще писать новую структуру, чем вводить очень сложные аппаратные комплексы.
— Так что получается в итоге?
В итоге у вас есть некий набор сырых данных, который прекрасно поддаётся анализу. По нему бегают роботы на Java-коде. Они прекрасно параллелятся, поскольку нет никаких специфических требований к архитектуре по железу. Если нужно добавить вычислительных мощностей — мы просто отдаём чуть больше ресурсов виртуальной среды или довозим и втыкаем железо. На боевой реляционной БД так не сделать.
— Но ведь это чудовищно медленно, разве не так?
Не всегда. Есть две ситуации, когда имеет смысл сравнивать:
- Короткие запросы с малым количеством join’ов. Здесь архитектура базы данных часто даёт выигрыш по времени, но мы платим за это резким увеличением нагрузки при запросах, которые не являются оптимальными для выбранной архитектуры.
- Сложные запросы разового типа. Иногда бывает проще составить запрос для реляционной базы за 10 минут и подождать два часа решения, чем писать Java-робота для Big Data 4 часа и ждать ответ 5 минут. Зависит от задач.
Поэтому, как правило, Big Data используется для задач, которые повторяются не очень часто и достаточно неординарны. Если мы вдруг решим сделать что-то из задач Big Data постоянным, и это будет возможно решить реляционной базой, то мы просто «захардкодим» это в обычную базу с фиксированной архитектурой.
— Какие есть известные примеры использования Big Data?
Рано или поздно практически все, кто работает с большими данными, приходят к примерно похожему подходу: структурированные и хорошо разбитые базы с грамотной архитектурой для быстрых запросов, неструктурированные сырые данные для сложных разовых. На Хабре было упоминание про подход Twitter к архитектуре — там используется нечто похожее.
— А почему тогда все на конференциях говорят про Big Data?
Потому что тренд модный, слово любят журналисты. Даже если вы обработаете 50 тысяч записей интернет-магазина и назовёте это Big Data — это будет достаточно пафосно, чтобы написать в пресс-релизе.
— Получается, что одна из целей Big Data — возможность уйти от долгих проектных циклов?
Да, и от массы костылей к традиционным БД. Java-методология давно известна, но в аналитике её стали применять сравнительно недавно. При решении каких-то аналитических задач традиционными методами, заранее не получается сказать, что будет работать не так. Иногда требуется несколько месяцев для анализа какой-то возникшей неприятной ситуации с использованием реляционной базы данных. Подход Big Data совсем иной, поскольку данные собираются в реальном времени, хранятся без обработки, а обрабатываются тогда и так, как это требуется исходя из текущих задач, которые могут постоянно меняться.
— Есть примеры уже решенных задач, где это было видно?
Да. Партнёры в Европе смотрели за устройствами в зоне покрытия LTE, но без подключённого по факту LTE. К примеру — владелец iPhone со старой SIM, владелец одного из китайских телефонов без знания того, что есть вообще такая веь как LTE. У партнеров программа заняла 6 месяцев. У нас этот проект тоже был реализован в рамках пилота на нашей платформе за 3 недели. В нашей реализации удалось обнаружить немало людей с устройствами с поддержкой LTE, которые этим функционалом не пользуются, возможно, даже не знают о нем. Или вот ещё пример. В ВымпелКоме есть подразделение, которое занимается анализом устройств, используемых абонентами. Это делается из соображений оптимизации оказания услуг. Например, если число аппаратов одной модели начинает быть больше 500, мы начинаем поддерживать такие устройства, в частности, запрашиваем информацию у производителя, чтобы уметь ответить на возможные вопросы клиента. Наш инструментарий позволяет очень быстро строить подобные разовые отчёты по использованию устройств в нашей сети.
— Какова структура платформы?
- Источники данных. Мы своим все данные в одно место, даже не думая о том, понадобятся они или нет — просто собираем сырой массив. Например, это события (вызовы, обрывы и т.п.), геолокационные, данные CRM, данные биллинга, данные о пополнении счета и так далее.
- Есть фабрика идей — это коммерческие идеи, которые могут быть реализованы, если на них выделить время разработчиков и вычислительные мощности.
- Есть зона пилотных проектов — это демо-версии, которые реализуются на малой выборке абонентов. И есть продуктив (про него ниже).
- Платформа. В систему работы с Big Data в ВымпелКоме интегрировано уже значительное число так называемых «узлов», машин, занимающихся сбором и анализом данных почти в реальном времени. Будем и далее наращивать эту сеть. Например, у компании Verizon уже около пятисот узлов задействовано в аналогичной системе. Платформа у нас разделена на кластер для пилотов (песочницу) и кластер для продуктивов. Принципиально они почти ничем не отличаются, кроме мощности и поддержки. Кластер для продуктивов более мощный, здесь уже не место для экспериментов, это «мельница» для концентрации и обработки данных. А в песочнице отрабатываются новые идеи, причем к ней подключены все источники данных, как и к кластеру для продуктивов.
— Есть примеры прогностических задач такого плана?
Да, нам очень интересно знать, когда человек едет в другую страну. Не сообщать ему на месте, что «Добро пожаловать в Казахастан», например, а ещё до начала поездки предлагать тарифные опции и информировать о ценах на месте. Один из проектов — анализ потока клиентов в аэропортах. Нужно отсечь тех, кто возвращается домой (это просто), отсечь персонал аэропорта и таксистов (по данным предыдущих визитов) и выделить тех, кто собирается сесть в самолёт через час-два. Вот пока они ждут самолёт — им и приходит SMS с предложением: иногда общим (где и как посмотреть информацию), в некоторых случаях — по конкретному региону или стране (если терминал работает только в этом направлении).
— Кто этим занимается в «Билайне»?
Вот я этим занимаюсь и мой коллега Виктор Булгаков. Я начинал в Нидерландах в телекоме, где был архитектором реалтайм-биллинга и MNP. Потом HP, KPN, отвечал за внедрение бизнес-аналитики и Data Mining в «Адидасе» — и теперь Билайн. А Виктор работал в «Инкомбанке» с ERP. Потом с 1999 года у нас занимается бизнес-аналитикой (по сути – всю её с нуля и делал) и теперь вот вплотную Big Data.
Думаю, вам может захотеться узнать про то, как мы работаем с данными на низком уровне, либо услышать про железо. Если тема интересна – пишите.
Автор: SergeyMarin
