Великі дані: внутрішня кухня або наш досвід впровадження методології розробки під 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 комерційних сервісів у світі — одиниці.
 
Завдяки сервісу геопросторових аналітики ми сподіваємося внести свій вклад у покращення якості планування міського середовища у великих мегаполісах, таких як Москва і Санкт-Петербург.
 
 

Команда

Окремо хотілося б розповісти про нашу команду, яка втілює в життя настільки складну систему та інструменти. У нас зібралася група фахівців-розробників і аналітиків, що займалися реалізацією аналітичних проектів в абсолютно різних індустріях від телеком-компаній, банків, роздрібних мереж до лідерів Інтернет галузі в Росії та Європі.
 
 
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.