Большие данные: внутренняя кухня или наш опыт внедрения методологии разработки под Big Data
Здравствуйте. Про BigData не пишет только ленивый. Нельзя сказать, что мы очень ленивы, но это первая наша статья на тему Больших Данных. За пару лет существования в компании «МегаФон» направления исследований и разработки аналитических сервисов мы попробовали и сделали многое и, главное, успели понять, что количество Hadoop-серверов и прочих элементов инфраструктуры под Big Data — только полдела. Когда количество серверов в вашем кластере превышает 100, а использующие его промышленные сервисы исчисляются десятками, управление всем этим «железом» и «софтом» становится ответственным, но, тем не менее, будничным делом.
Мы расскажем и методологии и опыте организации процесса внутренней разработки. Не секрет, что большинство телеком операторов — как в России, так и в мире — привыкли покупать готовые решения от производителей или интеграторов, и не склонны создавать компетенции внутри. Долгий путь сокращения издержек дает о себе знать.
Мы пошли совершенно другим путем и, как результат, на текущий момент имеем одну из самых сильных команд по анализу больших данных в телекоммуникационной отрасли России.Первой задачей, которую нам пришлось решать в процессе создания направления с нуля, стало построение процесса разработки под выбранный программный стек (у нас это Java и Scala, плюс Data Science ориентированные функциональные языки).
Уже этот первый шаг, с учетом законодательных ограничений, принятых в телеком отрасли в соответствии с законами «О связи» и «О персональных данных», заставил изменить стандартный подход. Дело в том, что в РФ для сотовых операторов, в отличие от WEB-компаний, существует достаточно строгая законодательная база. Детально прописаны процедуры обращения с данными и информацией, которую накапливает оператор в процессе оказания услуг связи, — что можно хранить и анализировать, а что нельзя.
Безусловно, это большой плюс для клиента, он действительно может быть спокоен. Но, с точки зрения разработчика, это означает, что ему никто не даст доступ к реальной клиентской информации для отладки и тестирования только что написанного кода. Для сравнения, в WEB-ориентированном стартапе в этой ситуации, скорее всего, просто возьмут так называемый сэмпл из набора реальных данных.
Методология, или Опыт — сын ошибок трудныхВо многих компаниях применяется так называемая каскадная (водопадная) методология разработки ПО.
Однако у этой схемы есть существенный недостаток: заложенные в самом начале сроки выполнения каждого этапа практически никогда не совпадают с реальностью и, самое главное, требуют детальной и фиксированной проработки постановки задачи не входе. Поэтому в последние годы большую популярность приобрел другой подход.
В самом начале пути, когда наша команда была небольшой, а заказчики функционала и разработчики сидели за соседними столами, быстрая обратная связь между ними обеспечивалась естественным образом. В условиях, когда изначальные постановки задач не были четкими, когда заказчики хотели «посмотреть, что получится» и «подкорректировать требования», SCRUM напрашивался сам собой. Напросился, стал методологией де-факто и почти год служил «верой и правдой». Мы не осознавали тогда, что наш SCRUM не был полноценным SCRUM«ом, а только его адаптированной версией. Правильнее сказать — вольной, «Мойшей напетой» интерпретацией. Что не мешало, однако, получать ожидаемые плоды: разработка шла быстро, на непаханом Big Data-поле мы успевали и экспериментировать, и делать работающий продукт. Единая команда заказчиков и разработчиков в полном составе участвовала в обсуждении задач, в декомпозиции требований на технические составляющие. В результате были и «волки сыты, и овцы целы»: заказчики видели, как выходящие у них из-под пера требования материализовывались, высеченные в коде, а разработчики решали интересные задачи, работая по совместительству аналитиками, архитекторами и проектировщиками, а не просто механически «кодили». Всем было интересно, все были при своих. Делали быстро, не оглядываясь «на обозы», не успевая или отмахиваясь от проработки, шлифовки решений. Очень хотели увидеть и показать результат.
Между тем, время шло. Росли аппетиты заказчиков. Усложнялись требования. Появлялись заказчики, которые были хоть и не страшно, но далеки от понимания технических деталей, а у тех, что понимали детали, становилось все меньше времени на участие в технических дебатах. Накапливался бэклог. Рос технический долг. Ужесточались требования к надежности, производительности решений, часть из которых уже вышла в промышленную эксплуатацию и приносила прибыль. И тут наш недоSCRUM стал давать сбои. За большим количеством задач команда стала терять общую картину, перестала видеть и понимать направление движения. Прилетающие «из ниоткуда» ad hoc задачи с высоким приоритетом заставляли команду переключаться между задачами и терять производительность, к тому же в ущерб качеству результата. И мы решили, что SCRUM — это не то, что нам нужно.
Свято место пусто не бывает: на место одной линовой технологии пришла другая — Канбан (яп. カンバン камбан). Мы перестроили наш процесс, снова привлекли к обсуждению требований самих бизнес-заказчиков. На еженедельных встречах решали, что из «хотелок» брать в работу, а что отложить в сторону, в бэклог, или вовсе исключить из рассмотрения. На какое-то время эти изменения поменяли график нашей производительности: количество выполненных задач увеличилось, несколько уменьшился бэклог. Правда, почти не «растаял» айсберг технического долга, при этом вырос новый — количество задач в работе (WIP, Work In Progress). Все чаще не хватало аналитика, который бы фильтровал поток требований, да и размер самой команды не позволял делать все, что наваливалось заказчиками в To Do. Становилось очевидно, что и Канбан не работает; осталось понять, почему.
Ответ оказался прост: наш Kanban не был Канбаном, а только так назывался. Нужен был взгляд со стороны, чтобы увидеть и понять ошибки нашего подхода. Мы пригласили людей, которые сделали обучение линовым технологиям своей профессией. И эти люди показали, что не зря едят свой хлеб. Очень скоро они указали на явные пробелы в нашем понимании Канбана. Точнее будет сказать, они подтвердили наши эмпирические выводы. Одновременно с этим они «реабилитировали» SCRUM: и он бы прекрасно удовлетворил нашим запросам, если бы мы довели его внедрение до конца.
Мы решили больше не метаться и «докрутить» Канбан. Мы снова в процессе изменений: вводим ограничения на WIP, строже подходим к постановке задач, учимся работать с пользовательскими историями. Неизменным остается наша приверженность линовому подходу. Он позволяет, при всех наших ошибках, сохранять высокую скорость работы, быструю реакцию на изменения, гибкость в поиске решений. Это особенно заметно на контрасте с другими подразделениями и внешними партнерами.
Continuous Delivery
Для эффективной работы методологии Канбан необходим процесс поставки результатов разработки, который предполагает очень короткий период обратной связи, в идеале — часы. Этим требованиям отвечает концепция Continuous Delivery (CD), которую можно представить в виде конвейера: 
Принятая нами методология разработки подразумевает очень короткие периоды итераций. То есть мы не можем позволить себе растянуть каждый этап во времени. По этой причине конвейер CD максимально автоматизирован. В чем это выражается: все три этапа тестирования проводятся без участия человека, с помощью сервера непрерывной интеграции. Он берет все изменения, внесенные на этапе «Разработка», применяет их, проводит тесты, после чего выдает отчет об успешности прохождения тестирования. Последний этап, «Внедрение», делается также автоматически на тестовых средах разработчиков, для развертывания на пользовательских средах нужна команда человека.
Процесс CD не представляет большой сложности, если речь идет о каком-то одном приложении, например, несложном веб-сайте. Обычно последствия внесенных разработчиками изменений можно оценить довольно быстро, на примере работы тех или иных функций приложения. Но в случае разработки платформы ситуация многократно осложняется, поскольку платформа может иметь множество разных применений. И еще труднее протестировать все изменения при создании платформы для обработки данных. Какие-то ощутимые результаты будут получены только после загрузки нескольких десятков терабайт. Поэтому цикл непрерывной интеграции сильно удлиняется. Чтобы это отчасти компенсировать, его разбивают на более мелкие составляющие, проводят тесты на небольших объемах данных.
Предметы поставки Что именно поставляется в рамках процесса CD: • Регулярные процессы, работающие на Hadoop (отчасти похоже на ETL)• Аналитические сервисы реального времени• Интерфейсы для потребителей результатов аналитики
Типичное бизнес-требование охватывает все три комплекта поставки: нужно наладить регулярные и онлайновые (реального времени) процессы, а также предоставить доступ к результатам, то есть создать интерфейсы. Разнообразие интерфейсов существенно усложняет процесс разработки. Все они требуют обязательного тестирования в рамках процесса CD.
Непрерывная интеграция Тестируемость вообще является одним из главных требований CD. Для этого нами был создан инструментарий, позволяющий автоматически тестировать предметы поставки на машине разработчика, на сервере непрерывной интеграции и в среде приемочного тестирования. Например, для процессов, разработанных на языке программирования Apache Pig, мы разработали maven-плагин, который позволяет локально тестировать скрипты, также написанные на Apache Pig, как будто бы они работают на большом кластере. Это позволяет заметно экономить время.Также мы разработали собственный инсталлятор, который аккуратно разворачивает на среде все предметы поставки. Он выполнен в виде DSL-языка на базе Groovy, и позволяет очень просто и наглядно указать, куда нужно отправить каждый предмет поставки. Вся информация об имеющихся средах, — тестовых, preproduction и production, — хранится в созданном нами конфигурационном сервисе. Этот сервис является исполнительным посредником между инсталлятором и средами.
После развертывания предметов поставки проводится автоматизированное приемочное тестирование. В ходе него эмулируются всевозможные действия пользователя: тестовые процедуры двигают курсором мыши, жмут кнопки и ссылки в интерфейсах и на веб-страницах. То есть проверяется корректность работы системы с точки зрения пользователя. По сути, бизнес-требования однозначно фиксируются в виде приемочных тестов.Предметы поставки подвергаются также автоматизированному нагрузочному тестированию. Его цель: подтвердить соблюдение требований по производительности. Для этого у нас выделена специальная среда.
Следующим этапом является статистический анализ качества кода: на стиль и типичные ошибки кодирования. Код может быть верен с точки зрения компилятора, но содержать логические ошибки, плохие имена и прочие огрехи стиля. Качество кода так или иначе контролируют все разработчики, но в нашей сфере применение подобного анализа к предметам поставки не является стандартным шагом.
Инфраструктура После прохождения всех тестов наступает этап развертывания. Конечно, при условии успешного тестирования. В процессе отправки объектов поставки в промышленную эксплуатацию управление происходит автоматически, без участия человека. Наш серверный парк состоит из более чем 200 машин, и для управления конфигурациями серверов используется система Puppet. Достаточно физически установить сервер в стойку, указать системе управления среду для подключения и роль сервера, а дальше все происходит автоматически: скачивание всех настроек, установка ПО, подключение к кластеру, запуск серверных компонентов, соответствующий нужно роли. Такой подход позволяет подключать и отключать серверы десятками, а не поштучно.Мы используем простую конфигурацию среды:
• Рабочие серверы (worker nodes) в виде обычных «железных» машин.• Облако виртуальных машин для различных утилитарных задач, не требующих больших мощностей. Например, управление метаданными, репозиторий артефактов, мониторинг.
Благодаря такому подходу, утилитарные задачи не занимают физические серверы, а облачная структура надежно защищена от сбоев, виртуальные машины перезапускаются автоматически. При этом рабочие серверы не являются единственными точками сбоя и могут быть безболезненно заменены или переконфигурированы.
Во многих компаниях упор делается на облачную экосистему при построении кластеров. Но использование облака для решения «тяжелых» аналитических задач с большими объемами данных менее эффективно с точки зрения стоимости. Используемая нами схема построения среды дает экономию в расходах на инфраструктуру, поскольку обычная, не виртуальная, машина эффективнее на операциях ввода-вывода с локальных дисков.
Каждая наша среда состоит из части облака виртуальных машин и некоторого количества рабочих серверов. В том числе у нас есть тестовые среды на виртуальных машинах по запросу, которые временно разворачиваются для решения каких-то задач. Эти машины можно создать даже на локальной машине разработчика. Для автоматического развертывания виртуальных машин мы используем систему Vagrant.
Помимо тестовых сред разработчиков мы поддерживаем три важных среды:
• Среда приемо-сдаточных испытаний — UAT• Cреда для нагрузочного тестирования — Performance• Промышленная среда — Production
Переключение рабочих серверов из одной среды в другую занимает считаные часы. Это простой процесс, требующий минимального вмешательства человека.
За мониторинг у нас ответственна распределенная система Ganglia, а алертингом заведует Nagios. Вся информация выводится на видеостену, состоящую из больших телевизоров, каждый из которых управляется Raspberry Pi. Каждый из этих микрокомпьютеров отвечает за отдельную часть общего большого изображения. Эффективное и очень доступное решение. На панель выводится состояние сред и процесса непрерывной поставки. Достаточно одного взгляда, чтобы получить представление том, как проходит процесс разработки, как чувствуют себя сервисы в промышленной эксплуатации.
Метрики Объем обрабатываемых данных превышает 200 000 сообщений/сек. По 50 000 сообщений система реагирует менее чем за секунду. Накопленная база данных для анализа занимает около 800 терабайт, к концу 2014 года она вырастет до 1,5 петабайт.Каждый из более чем двухсот серверов отправляет в мониторинг в среднем 50 метрик в минуту. Количество показателей, по которым осуществляется контроль допустимых параметров и алертинг — более 1600.
Open source Часть своих разработок мы планируем выложить в открытый доступ под открытыми лицензиями, как только они станут достаточно зрелы. Мы заинтересованы в том, чтобы эти инструменты развивались с поддержкой сообщества сторонних разработчиков.Использование результатов анализа В первую очередь, анализ больших данных развивается для решения задач «внутри».Несколько примеров из достаточно большого списка:
• Геопространственный анализ распределения нагрузки на сеть — где и почему клиенты испытывают сложности с качеством мобильного интернета или приема• Поведенческий анализ устройств в сотовой сети• Динамика появления новых устройств (актуально для службы поддержки)
В частности, мы используем результаты анализа больших данных при модернизации собственной сетевой инфраструктуры — базовых станций и передатчиков. Также нами создан ряд сервисов, предоставляющих различную аналитику в режиме реального времени.
Для открытого рынка мы первым из операторов в России в ноябре 2013 года запустили Геопространственный сервис анализа городских потоков, включая пешеходов и общественный транспорт. Примеров таких не-GPS-based коммерческих сервисов в мире — единицы.
Благодаря сервису Геопространственной аналитики мы надеемся внести свой вклад в улучшение качества планирования городской среды в крупных мегаполисах, таких как Москва и Санкт-Петербург.
Команда
Отдельно хотелось бы рассказать о нашей команде, которая воплощает в жизнь столь сложную систему и инструменты. У нас собралась группа специалистов-разработчиков и аналитиков, занимавшихся реализацией аналитических проектов в совершенно разных индустриях от телеком-компаний, банков, розничных сетей до лидеров Интернет отрасли в России и Европе.
