Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
•Als PPTX, PDF herunterladen•
0 gefällt mir•1,330 views
HighLoad++ 2017 Зал «Калининград», 8 ноября, 13:00 Тезисы: http://www.highload.ru/2017/abstracts/3010.html В этом докладе я расскажу, как BigData-платформа помогает трансформировать Почту России, как мы управляем построением и развитием платформы. Расскажу про найденные удачные решения, например, как разбиение на продукты с понятными SLA и интерфейсами между ними помогло нам сохранять управляемость с ростом масштабов проекта. ...
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
Ähnlich wie Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft) (20)
Mehr von Ontico
Mehr von Ontico (20)
Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)
- 1. Управление разработкой Big Data платформы Почты России Андрей Бащенко
- 2. Простая Big Data история Собираем все данные, до которых можем дотянуться Данные избыточны, можно терять Высокая доступность не требуется В основном достаточно батч-обработки
- 3. 47.000 + отделений 300.000 + сотрудников Логистическая сеть Ретейл с необходимостью отслеживать каждый Item Разделить данные по географиям невозможно
- 4. Разворачивание вложений Мультиплицирование операций Мы повторяем операцию над емкостью для каждого вложения. Получаем 400 млн логистических операций в сутки.
- 6. Ситуационное реагирование Идентификация и разрешение инцидентов, для которых нужно реагирование в real-time. Пример: зацикливание
- 7. Process mining Выявление и устранение ошибок и неэффективностей в процессах. Выявление и пресечение злоупотреблений. Пример: «серая» почта Потери от «серой» почты: 2015 год – 5,8 млрд руб. 2016 год – 3 млрд руб.
- 8. И еще задачи.. Управление по KPI Прогноз нагрузки и оставление графика сотрудников Аналитика «Невозможно управлять тем, что ты не можешь измерить» (С) Peter Drucker Геомаркетинг – оптимизация сети
- 9. Из задач вытекают требования к решению: Сохранность данных >= 99,999 Доступность >= 99,9 Нужны и батч и стриминг обработки Надо успевать пересчитать ВСЕ данные за ночь
- 10. Big Data Платформа Фабрика Данных Стриминг + Батч Лаборатория Монетизации Данных Внутренний инкубатор Data Lake Сортировочные машины Логистика Бухгалтерия Ретейл Фронт система Мобильное приложение Подписка онлайн Вызов курьера ПочтаМаркет Электронные письма Личный кабинет Transport Management System Переводы и Платежи Кадры Поиск Отправлений Рекламные услуги Финансовые услуги ИТ системы и сервисы Предприятия Шина Данных Big Data платформа Почты России
- 11. Big Data платформа Почты России – Факты Обрабатывается до 1 млрд событий в сутки 1+ Pb данных 7200 VCPU, 25 Tb RAM, 2,5 Pb HDD Линейное горизонтальное масштабирование
- 12. Разработка Big Data платформы 36 человек в команде разработки: Architects, Product Owners, Analysts, Sen. Devs, QA 100% Seniors + leads, 0% Regulars, 0% Juniors. Основная единица разработки: Spark ETL Job на Scala
- 13. Стадия стартапа Разработка v.0 Стадия стартапа. Атмосфера творчества. 2015 год, Команда <10 человек
- 14. Кросс-функциональные команды Cross-functional Team 1 Cross-functional Team 2 FrontendBackend Плюсы Две команды делают бэклог в два раза быстрее Нагрузка распараллелилась Здоровая конкуренция между командами за задачи Февраль 2016, Команда 12 человек Минусы В команде сложно собрать все компетенции по тех. стэку Уникальные носители компетенций становятся узким местом Подходы и стандарты разработки команд расходятся все сильнее –> на общем кластере хаос
- 15. Разделение по компонентам SLA Front End Team Back End Team FrontendBackend Плюсы Увеличена скорость разработки в каждом компоненте за счет специализации команд Команда платформы DWH следит за стабильностью платформы и соблюдением требований к артефактам для деплоя на платформу Март 2016, Команда 15 человек Минусы Просела разработка конечных фич
- 16. Масштабирование команд Back End Team … Front End Team 1 Front End Team 2 Front End Team N Плюсы Команды разработки «фронта» можно масштабировать линейно – пользователи рады! Возможна вертикальная специализация команд «фронта» под конкретных заказчиков – пользователи очень рады! SLA Июнь 2016, Команда 18 человек Минусы Тех. долг накапливается в бэкенде
- 17. Тех долг накапливается в бэкенде SLA Back End Teams: … Front End Team 1 Front End Team 2 Front End Team N Инфраструктура и управление кластером Прием данных Промежуточный слой и стриминг SLA SLA Плюсы Выделенная даже небольшая команда фокусируется только на своем компоненте и ликвидирует тех долг, своевременно рефакторит и развивает компонент, успевая за ростом платформы. Еще больше разрезаем тех стек по компонентам – сильнее специализация, производительнее каждая отдельная команда. Январь 2017, Команда 25 человек Минусы Увеличение цикла разработки если фича требует работ во всех компонентах
- 18. Лаборатория монетизации данных. Внутренний стартап акселератор. Пилот Прототип Концепт Команда разработки Инвестиции
- 19. Лаборатория монетизации данных. Data-Driven продукты. Лаборатория монетизации данных Оптимизация работы, повышение качества услуг, снижение издержек Увеличение выручки, рост доли рынка Сервис «черный список адресов» Оперативный мониторинг Логистики Центр управления почтовой сетью Конструктор почтовых продуктов Аналитика по клиентам Борьба с серой почтой Геоаналитика по развитию сети
- 20. Мы центральный компонент ИТ ландшафта. Чем больше мы делаем, тем больше новых задач... ИТ системы Почты Бизнес-блоки и подразделения Другие команды Бэклог Потоки данных, интеграции Витрины, аналитика ETL обработки Триггеры …. Продукты, выросшие из нашего инкубатора
- 21. Наращивать команду чтобы угнаться за бэклогом? Отказывать? Спихивать задачи на другие продукты? Брать в бэклог, называть сроки в годах? Что делать? Варианты.
- 22. Открытая экосистема вокруг общей платформы SLA Front End Team 1 Front End Team 2 External Team 1 Инфраструктура и управление кластером Прием данных Промежуточный слой и стриминг SLA SLA … Ситуационный центр
- 23. Открытый процесс разработки DEV TEST UAT Pre-PROD PROD Завершена разработка, пройдено ревью, отчет работает на тест, построение автомати- зировано в Oozie теста Пройдено тестирование Получен апрув от пользователей, работающий Oozie Поток работ Получен апрув на вывод в прод Стадии разработки окружения: Master Feature 1 Feature 2 Release Deploy Merge Deploy Master to Prod, UAT, Test Tag
- 24. Спасибо! Андрей Бащенко Руководитель направления Big Data ABashchenko@luxoft.com
Hinweis der Redaktion
- Привет! Меня зовут Андрей Бащенко и я управляю Big Data направлением Почты России. Я собираюсь рассказать Вам о нашем кейсе построения Big Data платформы для Почты. У нас третий в России по мощности физический Big Data кластера (после Яндекс и Mail.ru). О тех проблемах с которыми мы столкнулись при росте нашей платформы и команды, о тех решениях, которые нашли. Это доклад по управлению разработкой, параллельно если вы интересуетесь, можете посмотреть материалы доклада моего коллеги Алексея Вовченко – Big Почта про архитектурную составляющую, сравнение и выбор компонент технологического стека. Для того, чтобы эта история имела для вас больший смысл, я сначала расскажу о том, что представляет из себя почта России, какие задачи наша платформа решает для почты. Из задач вытекают требования к платформе, к ее компонентам. Далее мы рассмотрим что из себя представляет платформа на данный момент, из каких компонент состоит и пройдем с вами по истории создания, проблемам в управлении разработкой и их решениям.
- Например: финансы, Телеком, E-commerce, Web: центральная сущность -клиент, связанные сущности – факты взаимодействия с ним. В основном внешние данные. Обучаем модели прогноза, выявляем зависимости, строим аналитику.
- Почта России – это крупнейшая розничная сеть из + логистическая инфраструктура по всей стране. Почта России является естественным агрегатором данных по всем домохозяйствам, физическим и юридическим лицам страны.
- Есть такая типовая для логистики задача: разворачивание вложений. Когда ваше долгожданное письмо или пакет упакованы в емкость (мешок, ящик, контейнер), и емкость проходит например сортузел, с ней делаются какие-то операции – само письмо не видно, видны операции над емкостью верхнего уровня. Если вы до 2015 года пользовались трекингом на сайте почты, вы бы увидели такую картину. После ввода в действие нашей платформы, мы одной из первых решили эту задачу. И теперь в трекинге вы видите и те точки, которые ваше отправление прошло транзитом. И хэппи-енд Эти данные мы предоставляем производственным системам, для оптимизации маршрутов, системам управления сортировками и многим другим внутренним потребителям.
- Для каждого плеча логистики определены контрольные сроки для каждого вида отправлений. Сравнивая фактические сроки с контрольными, получаем: % соблюдения сроков по каждому отправлению – складывается в KPI каждого отдела, сотрудника, отвечающего за логистику. Контролируем массовые замедления на определенных маршрутах и получаем возможность оперативно реагировать - оптимизировать маршрут, решать проблему, вызвавшую замедление
- Для некоторых инцидентов сценарий: пересчитали ночью данные, построили отчеты и смотрим вчерашние данные – не подходит, это слишком поздно. Нужно выявление и реагирование в реальном времени. Например инцидент зацикливание: емкость или посылка со сбойным штрих-кодом, ездят по кругу между двумя сортузлами. Жгут топливо, тратят рабочее время сотрудников и деньги Почты. Ранее определялось вручную: когда посылка просто намозолила глаза сотруднику и ее сняли и посмотрели чего это она тут ездит уже 10-й раз. Мы этот инцидент определяем, генерим тикет для СитЦентра и далее автоматически отправляем с сортировочной линии в отбраковку, чтобы переклеили штрихкод.
- Используются алгоритмы кластеризации, Machine learning. Серая почта это ситуации, когда недобросовестные сотрудники получая на руки вознаграждение от коммерческих структур, подкидывают в систему почты «левые» объемы корреспонденции. Приводит к росту затрат, недополученной выручке. В частности много кейсов с нерегистрируемыми отправлениями – письма, рекламная продукция. Поскольку нет айди, они отслеживаются по массе. Тут мы выявляем отклонения массы и можем оперативно замечать такие кейсы. Эта тема еще в стадии разработки.
- Данные нельзя терять. Потерянные данные это проблема по конкретным отправлениям, это боль для пользователей, для клиентов. Каждый кейс потери данных это дефект. В случае недоступности платформы страдает вся компания: - страдают производственные системы: замедляются сортировки, авральный ручной ввод в отделениях, сотрудники выводятся сверхурочно, возникают очереди в рабочие часы. - компания не имеет аналитики, встает управление и контроль, работа по оперативному анализу и поиску причин инцидентов. Значит нужна высокая доступность. Задачи предоставления данных в производственные системы, ситуационного реагирования решаются только стримингом. Каждая пришедшая операция например над емкостью где-то на сортировке может поменять ситуацию по сотням отправлений. Значит надо пересчитывать массив логистических данных полностью. Считаем каждую ночь.
- Я не хочу показывать архитектуру платформы, так как этот доклад сфокусирован на управлении В основе платформы Data Lake на HDFS, сюда мы приземляем данные. Укрупненно в составе платформы выделяются три компонента: Фабрика данных: отвечает за интеграцию и обогащение данных, раздачу данных в виде потоков, витрин Лаборатория монетизации данных – внутренний инкубатор Data Driven продуктов Все сотрудники (более 300.000), клиенты Почты (150 млн) и все ИТ системы являются нашими потребителями и Заказчиками. Взаимодействие с системами-потребителями идет в основном через шину данных.
- 7200 физических ядер – это один из крупнейших по мощности кластеров в России – после Yandex и Mail.ru Стартовали в 2015 году, накопили уже петабайт с лишним – и все это внутренние данные.
- Команда выросла сильно за 10 человек, сложно управлять такой командой, надо делиться. Как? Классическое решение – делим на кроссфункциональные команды, которые пилят законченные фичи из общего бэклога. Реализовали и какое то время пожили так. Плюсы: Две команды делают бэклог в два раза быстрее Нагрузка распараллелилась; Здоровая конкуренция между командами за задачи; + бенчмаркинг, всегда можно сравнить команды между собой Минусы: Слишком длинный стек технологий - в команде тяжело собрать все компетенции, уникальные носители компетенций становятся узким местом; Подходы и стандарты разработки команд расходятся все сильнее – на общем кластере начинается хаос. Пробовали кросс-командное ревью – не работает вообще, приоритет отдается задачам команды, ревью по остаточному принципу.
- Решение: делим продукт на компоненты так, чтобы разрезать по компонентам технологический стек. Выделяем общий компонент – платформу Data Warehouse (DWH), над ней компонент Operational Intelligence (OI). Что важно в разделении продукта на компоненты: Для каждого компонента продумать SLA. Это то, как вы сможете померять хорошо ли работает компонент и его команда. Для бэкендных компонентов продумать API наружу. DWH отвечает за стабильность платформы, принимает от OI Spark Jobs соответствующие определенным стандартам, деплоит их на платформу. SLA команды DWH – 1 неделя на релиз готовой проведенной по Delivery процессу через тестирование, UAT и т.д. API DWH команды: набор промежуточных витрин, из которых фронт-команда собирает витрины для решения конечных бизнес-задач. При этом от фронт команды скрыта физическая модель данных, то есть исходные витрины, куда данные сохраняются в форматах сообщений, скрыта вся валидация, очистка, интеграция данных из разных потоков, это все подробности имплементации в компоненте DWH. Плюсы: Получили большую скорость разработки в каждом конкретном компоненте за счет повышения специализации команд; Команда платформы DWH следит за стабильностью платформы и соблюдением требований к Spark Jobs для деплоя на платформу. Минусы: просела разработка конечных фич. Но это окупается повышением доступности платформы, снижением количества аварий.
- Компонент OI представляет из себя набор конечных фич для пользователей, его можно делать параллельными командами – главное, чтобы команды следовали требованиям API компонента DWH! Плюсы: Команды разработки компонента OI можно масштабировать линейно – пользователи рады! Возможна вертикальная специализация команд OI – под конкретных заказчиков, пользователи опять рады!
- Проблема: фокус и ресурсы постоянно смещается на то, чего требуют пользователи – новые витрины, новые обработки в фронтовом компоненте OI. При этом прием и заливка данных в платформу работает все хуже на старых костылях – руки не доходят. Решение: выделяем слои архитектуры внутри платформы. С отдельными SLA, бэклогом и API для других команд. Плюсы: Выделенная даже небольшая команда фокусируется только на своем компоненте и ликвидирует тех долг, своевременно рефакторит и развивает компонент, успевая за ростом платформы. Еще больше разрезаем тех стек по компонентам – сильнее специализация, производительнее каждая отдельная команда. Минус: увеличение цикла разработки если фича требует работ во всех компонентах.
- Решение: организационно разделить на два разных компонента: Задачи обработки, интеграции, обогащения и предоставления внутренним потребителям данных - в Фабрику Данных (процессный подход, ориентация на стабильность, SLA, качество данных) Задачи идентификации перспективных идей, исследований, разработки и запуска новых продуктов на основе данных - в Лабораторию Монетизации Данных (подход экспериментальный, постановка исследований и разработок на поток). Бонус: разработчики из Фабрики Данных с удовольствием берутся за задачи Лаборатории Монетизации – это интересно, развивающие задачи и новые технологии.
- Когда в компании кто-то начинает хорошо работать и выдавать результаты, к нему выстраивается очередь желающих со своими задачами. Иногда это даже не совсем релевантные задачи. Мы показываем результаты => вся компания начинает приходить к нам за данными (API, потоками, витринами, аналитикой). Наращивать свою команду такими темпами не успеваем. Отказывать внутренним клиентам значит отказывать в развитии собственному продукту. Решение: делаем платформу открытой – формализуем требования к Spark Jobs, аналитике, которые могут разрабатываться другими командами и после тестирования, отладки, оптимизации – деплоятся на нашу инфраструктуру. Таким образом мы позволяем расти другим командам, строим вокруг своей инфраструктуры экосистему.
- Наращивать свою команду такими темпами не успеваем. Отказывать внутренним клиентам значит отказывать в развитии собственному продукту.
- Решение: делаем платформу открытой – формализуем требования к Spark Jobs, аналитике, которые могут разрабатываться другими командами и после тестирования, отладки, оптимизации – деплоятся на нашу инфраструктуру. Таким образом мы позволяем расти другим командам, строим вокруг своей инфраструктуры экосистему.
- Упрощенный универсальный процесс работы с back end