Создание BigData-платформы для ФГУП Почта России / Андрей Бащенко (Luxoft)

Editor's Notes

• #2: Привет!Меня зовут Андрей Бащенко и я управляю Big Data направлением Почты России. Я собираюсь рассказать Вам о нашем кейсе построения Big Data платформы для Почты. У нас третий в России по мощности физический Big Data кластера (после Яндекс и Mail.ru). О тех проблемах с которыми мы столкнулись при росте нашей платформы и команды, о тех решениях, которые нашли. Это доклад по управлению разработкой, параллельно если вы интересуетесь, можете посмотреть материалы доклада моего коллеги Алексея Вовченко – Big Почта про архитектурную составляющую, сравнение и выбор компонент технологического стека. Для того, чтобы эта история имела для вас больший смысл, я сначала расскажу о том, что представляет из себя почта России, какие задачи наша платформа решает для почты. Из задач вытекают требования к платформе, к ее компонентам. Далее мы рассмотрим что из себя представляет платформа на данный момент, из каких компонент состоит и пройдем с вами по истории создания, проблемам в управлении разработкой и их решениям. 
• #3: Например: финансы, Телеком, E-commerce, Web: центральная сущность -клиент, связанные сущности – факты взаимодействия с ним.В основном внешние данные. Обучаем модели прогноза, выявляем зависимости, строим аналитику.
• #4: Почта России – это крупнейшая розничная сеть из + логистическая инфраструктура по всей стране. Почта России является естественным агрегатором данных по всем домохозяйствам, физическим и юридическим лицам страны.
• #5: Есть такая типовая для логистики задача: разворачивание вложений. Когда ваше долгожданное письмо или пакет упакованы в емкость (мешок, ящик, контейнер), и емкость проходит например сортузел, с ней делаются какие-то операции – само письмо не видно, видны операции над емкостью верхнего уровня. Если вы до 2015 года пользовались трекингом на сайте почты, вы бы увидели такую картину. После ввода в действие нашей платформы, мы одной из первых решили эту задачу. И теперь в трекинге вы видите и те точки, которые ваше отправление прошло транзитом. И хэппи-ендЭти данные мы предоставляем производственным системам, для оптимизации маршрутов, системам управления сортировками и многим другим внутренним потребителям.
• #6: Для каждого плеча логистики определены контрольные сроки для каждого вида отправлений. Сравнивая фактические сроки с контрольными, получаем: % соблюдения сроков по каждому отправлению – складывается в KPI каждого отдела, сотрудника, отвечающего за логистику. Контролируем массовые замедления на определенных маршрутах и получаем возможность оперативно реагировать - оптимизировать маршрут, решать проблему, вызвавшую замедление
• #7: Для некоторых инцидентов сценарий: пересчитали ночью данные, построили отчеты и смотрим вчерашние данные – не подходит, это слишком поздно. Нужно выявление и реагирование в реальном времени. Например инцидент зацикливание: емкость или посылка со сбойным штрих-кодом, ездят по кругу между двумя сортузлами. Жгут топливо, тратят рабочее время сотрудников и деньги Почты. Ранее определялось вручную: когда посылка просто намозолила глаза сотруднику и ее сняли и посмотрели чего это она тут ездит уже 10-й раз. Мы этот инцидент определяем, генерим тикет для СитЦентра и далее автоматически отправляем с сортировочной линии в отбраковку, чтобы переклеили штрихкод.
• #8: Используются алгоритмы кластеризации, Machine learning.Серая почта это ситуации, когда недобросовестные сотрудники получая на руки вознаграждение от коммерческих структур, подкидывают в систему почты «левые» объемы корреспонденции. Приводит к росту затрат, недополученной выручке. В частности много кейсов с нерегистрируемыми отправлениями – письма, рекламная продукция. Поскольку нет айди, они отслеживаются по массе.Тут мы выявляем отклонения массы и можем оперативно замечать такие кейсы. Эта тема еще в стадии разработки.
• #10: Данные нельзя терять. Потерянные данные это проблема по конкретным отправлениям, это боль для пользователей, для клиентов. Каждый кейс потери данных это дефект. В случае недоступности платформы страдает вся компания: - страдают производственные системы: замедляются сортировки, авральный ручной ввод в отделениях, сотрудники выводятся сверхурочно, возникают очереди в рабочие часы.- компания не имеет аналитики, встает управление и контроль, работа по оперативному анализу и поиску причин инцидентов. Значит нужна высокая доступность. Задачи предоставления данных в производственные системы, ситуационного реагирования решаются только стримингом. Каждая пришедшая операция например над емкостью где-то на сортировке может поменять ситуацию по сотням отправлений. Значит надо пересчитывать массив логистических данных полностью. Считаем каждую ночь.
• #11: Я не хочу показывать архитектуру платформы, так как этот доклад сфокусирован на управлении В основе платформы Data Lake на HDFS, сюда мы приземляем данные. Укрупненно в составе платформы выделяются три компонента: Фабрика данных: отвечает за интеграцию и обогащение данных, раздачу данных в виде потоков, витрин Лаборатория монетизации данных – внутренний инкубатор Data Driven продуктов Все сотрудники (более 300.000), клиенты Почты (150 млн) и все ИТ системы являются нашими потребителями и Заказчиками.Взаимодействие с системами-потребителями идет в основном через шину данных.
• #12: 7200 физических ядер – это один из крупнейших по мощности кластеров в России – после Yandex и Mail.ru Стартовали в 2015 году, накопили уже петабайт с лишним – и все это внутренние данные.
• #15: Команда выросла сильно за 10 человек, сложно управлять такой командой, надо делиться. Как? Классическое решение – делим на кроссфункциональные команды, которые пилят законченные фичи из общего бэклога. Реализовали и какое то время пожили так. Плюсы: Две команды делают бэклог в два раза быстрее Нагрузка распараллелилась; Здоровая конкуренция между командами за задачи; + бенчмаркинг, всегда можно сравнить команды между собой Минусы: Слишком длинный стек технологий - в команде тяжело собрать все компетенции, уникальные носители компетенций становятся узким местом; Подходы и стандарты разработки команд расходятся все сильнее – на общем кластере начинается хаос. Пробовали кросс-командное ревью – не работает вообще, приоритет отдается задачам команды, ревью по остаточному принципу.
• #16: Решение: делим продукт на компоненты так, чтобы разрезать по компонентам технологический стек. Выделяем общий компонент – платформу Data Warehouse (DWH), над ней компонент Operational Intelligence (OI). Что важно в разделении продукта на компоненты: Для каждого компонента продумать SLA. Это то, как вы сможете померять хорошо ли работает компонент и его команда. Для бэкендных компонентов продумать API наружу. DWH отвечает за стабильность платформы, принимает от OI Spark Jobs соответствующие определенным стандартам, деплоит их на платформу. SLA команды DWH – 1 неделя на релиз готовой проведенной по Delivery процессу через тестирование, UAT и т.д. API DWH команды: набор промежуточных витрин, из которых фронт-команда собирает витрины для решения конечных бизнес-задач.При этом от фронт команды скрыта физическая модель данных, то есть исходные витрины, куда данные сохраняются в форматах сообщений, скрыта вся валидация, очистка, интеграция данных из разных потоков, это все подробности имплементации в компоненте DWH. Плюсы: Получили большую скорость разработки в каждом конкретном компоненте за счет повышения специализации команд; Команда платформы DWH следит за стабильностью платформы и соблюдением требований к Spark Jobs для деплоя на платформу. Минусы: просела разработка конечных фич. Но это окупается повышением доступности платформы, снижением количества аварий.
• #17: Компонент OI представляет из себя набор конечных фич для пользователей, его можно делать параллельными командами – главное, чтобы команды следовали требованиям API компонента DWH! Плюсы: Команды разработки компонента OI можно масштабировать линейно – пользователи рады! Возможна вертикальная специализация команд OI – под конкретных заказчиков, пользователи опять рады!
• #18: Проблема: фокус и ресурсы постоянно смещается на то, чего требуют пользователи – новые витрины, новые обработки в фронтовом компоненте OI. При этом прием и заливка данных в платформу работает все хуже на старых костылях – руки не доходят. Решение: выделяем слои архитектуры внутри платформы. С отдельными SLA, бэклогом и API для других команд. Плюсы: Выделенная даже небольшая команда фокусируется только на своем компоненте и ликвидирует тех долг, своевременно рефакторит и развивает компонент, успевая за ростом платформы. Еще больше разрезаем тех стек по компонентам – сильнее специализация, производительнее каждая отдельная команда. Минус: увеличение цикла разработки если фича требует работ во всех компонентах.
• #19: Решение: организационно разделить на два разных компонента: Задачи обработки, интеграции, обогащения и предоставления внутренним потребителям данных - в Фабрику Данных (процессный подход, ориентация на стабильность, SLA, качество данных) Задачи идентификации перспективных идей, исследований, разработки и запуска новых продуктов на основе данных - в Лабораторию Монетизации Данных (подход экспериментальный, постановка исследований и разработок на поток). Бонус: разработчики из Фабрики Данных с удовольствием берутся за задачи Лаборатории Монетизации – это интересно, развивающие задачи и новые технологии.
• #21: Когда в компании кто-то начинает хорошо работать и выдавать результаты, к нему выстраивается очередь желающих со своими задачами. Иногда это даже не совсем релевантные задачи. Мы показываем результаты => вся компания начинает приходить к нам за данными (API, потоками, витринами, аналитикой). Наращивать свою команду такими темпами не успеваем. Отказывать внутренним клиентам значит отказывать в развитии собственному продукту. Решение: делаем платформу открытой – формализуем требования к Spark Jobs, аналитике, которые могут разрабатываться другими командами и после тестирования, отладки, оптимизации – деплоятся на нашу инфраструктуру. Таким образом мы позволяем расти другим командам, строим вокруг своей инфраструктуры экосистему.
• #22: Наращивать свою команду такими темпами не успеваем. Отказывать внутренним клиентам значит отказывать в развитии собственному продукту.
• #23: Решение: делаем платформу открытой – формализуем требования к Spark Jobs, аналитике, которые могут разрабатываться другими командами и после тестирования, отладки, оптимизации – деплоятся на нашу инфраструктуру. Таким образом мы позволяем расти другим командам, строим вокруг своей инфраструктуры экосистему.
• #24: Упрощенный универсальный процесс работы с back end