Привет, Хабр!  На связи команда разработки «МосТрансПроекта».

Наш институт является интеллектуальным центром транспортного планирования Москвы, и для решения задач нам постоянно нужны данные. Для запуска компенсационных автобусов во время ремонта станции метро необходимо знать ее пропускную способность, пиковую нагрузку, конфигурацию переходов и парность поездов. А при проектировании благоустройства транспортного хаба нужна информация о пассажиропотоках, интервалах движения городского транспорта и интенсивности автомобильного трафика.

Необходимые данные (а их суммарный объем измеряется в петабайтах) собирают ЦОДД, Московский метрополитен, «Организатор перевозок», «Мосгортранс», «Администратор московского парковочного пространства» и другие структуры транспортного комплекса. В целом, ничего сложного: получаем доступ к базам, берем информацию, «причесываем», анализируем, действуем, решаем задачу. Но, как обычно это бывает с данными, все не так просто.

В поисках склада

Проблема в том, что для неподготовленного специалиста обособленные друг от друга базы напоминают склады с наваленными коробками — чтобы быть уверенным в результате, нужно заглянуть в каждую. Старожилы «МосТрансПроекта», конечно, знают, где взять ту или иную информацию, но без их помощи работать с данными было трудно. Иногда нужно было пройти увлекательный квест, чтобы забрать сведения, которые есть лишь у конкретного специалиста.

Кроме того, применялись разные подходы в расчете той или иной цифры. Исходные данные все использовали плюс-минус одни и те же, но в зависимости от задачи по-разному их обрабатывали и интерпретировали, а привычки документировать и делиться методиками еще не было.

В какой-то момент необходимость в изменении подхода стала очевидна: требовался нормальный, быстрый доступ к верифицированным, регулярно обновляемым данным и знаниям о том, как эти данные сформированы. Чтобы повысить эффективность работы Института мы запустили проект, который назвали просто и не слишком заумно — Data Project.

На момент старта проекта в «МосТрансПроекте» работало несколько команд аналитики, разделенных по направлениям. Поскольку все аналитики были тогда перегружены оперативными задачами, Data Project поручили залидировать еще только формируемой на тот момент IT-команде, как самой непуганой и замотивированной на изменения.

В начале 2022 года небольшим коллективом сначала в полтора, а потом в три человека, мы приступили к аудиту данных и выяснение, откуда что берется и куда складывается. За три месяца мы собрали файл из 180 источников данных и наименований датасетов. Каждой позиции дали оценку ее востребованности по шкале от «часто» до «редко». Коллеги из аналитических блоков института хоть и не могли по-прежнему посвящать много времени проекту, но все же здорово помогли нам обогатить таблицу данными, избавиться от дубликатов, проставить связи и т.д.

Табличка и очки

Окей, начало положено, вершина айсберга уже виднеется. Мы получили один большой файл с очищенной и относительно систематизированной информацией. Что дальше?

Для начала нужно было нормальным человеческим языком описать, о чем эти данные, как их получить, где, кем и с какой целью могут использоваться. Так у нас появилась Data Wiki – корпоративная база знаний о данных и системах, используемых в «МосТрансПроекте», одна из важнейших частей Data Project.  Вообще, любые специальные знания полезно документировать. Даже если в моменте польза неочевидна и вообще лень, впоследствии не раз порадуетесь возможности обратиться к готовым текстам и графике.

В Data Wiki мы описываем нюансы, которые без погружения в специфику нашей работы узнать сложно. Например: как считать пассажиропоток на пересадочных станциях. Или вообще, пассажиропоток – это что? Данный термин (на профессиональном сленге его в целях экономии времени называют «пасспоток») включает целое семейство показателей. Чаще всего речь идет о количестве поездок, совершенных за определенный период времени с использованием конкретного транспортного объекта. Поэтому, когда вы в новостях прочитаете о 8 млн поездках в метро за сутки, то стоит понимать, что речь идет именно о поездках, а не об уникальных жителях и гостях города, которые за 24 часа воспользовались подземкой. Кто-то мог совершить поездку два и более раз.

В качестве платформы для Data Wiki мы использовали бесплатный вики-движок Outline.  У него простой и приятный интерфейс, позволяющий обычным пользователям сходу комфортно искать и потреблять информацию; достаточно простое разворачивание системы (есть удобный вариант установки с помощью Docker); привычный и достаточно многофункциональный Markdown редактор. Кроме того, сервис написан на node.js и react, что позволяло нам при необходимости корректировать код, самостоятельно дописывать функционал. Мы, к примеру, достаточно быстро прикрутили LDAP авторизацию, чтобы все сотрудники могли понятным образом регистрироваться в системе. Так же улучшили стандартные возможности поиска за счёт elastic search. Это сильно улучшило качество поиска, пользователи быстрее и с большей вероятностью находят нужную информацию. Для размещения и хранения востребованных статичных датасетов «под рукой» мы развернули и настроили облако NextCloud.

Осторожно, дашборды открываются

Когда уже существовала DataWiki и достаточно активно наполнялась знаниями, а наши коллеги по-прежнему тонули в нескончаемом потоке срочных аналитических задач, мы решили выделить из всего массива данных условные "Топ-30" самых востребованных метрик и визуализировать их. Мы хотели сэкономить ценное время коллег, особенно в случаях, когда поступает вопрос типа «Какой точно пасcпоток на Чистых прудах был в прошлый понедельник и в этот же день год назад? Срочно!».

Сначала нам пришлось самим разобраться с данными, которые используют коллеги из смежных отделов для такой «быстрой аналитики».

Первым вызовом для нас стали колоссальные объемы данных, которые, как оказалось, нужны «под рукой». К примеру, архив одних только сведений о валидациях на городском транспорте содержит более 27 млрд. строк. Привычные для аналитиков реляционные БД «переварить» такие объемы (а точнее — справиться с поддержанием целостности связей между данными) не в состоянии. Поэтому мы выбрали колоночную СУБД (ClickHouse), хотя обычно использовали строковые БД, типа PostgreSQL. Смена привычной модели БД бесследно, конечно же, не прошла, поскольку мы лишились той самой целостности — выстроенных дорожек между табличками.  Это привело к тому, что каждое присоединение таблицы в запросе таило в себе неизвестность и потенциальные ошибки из-за возможных дубликатов или неверно подобранных внешних ключей. Довольно быстро мы создали ER-диаграммы связей наших таблиц, проложив тем самым невидимые дорожки между ними.

Разобравшись с данными, мы были готовы приступить к созданию инструмента для их визуализации в виде дашбордов. У наших коллег-транспортных аналитиков, конечно, уже был их рабочий и настроенный инструмент – BI Metabase. Но он на то и рабочий, что требовал специальной подготовки.

Сначала мы пробовали делать первые дашборды также на Metabase, но затем перешли на Apache Superset, который проще кастомизировать под свои нужды. Несколько раз от любви до ненависти менялось наше отношение к этому решению, но плюсов оказалось по итогу больше.

Первое, с чем мы столкнулись, – это избыточное количество данных, генерируемых каждым из наших запросов. Решение мы нашли в создании скриптов в Apache AirFlow, позволяющих провести предварительную агрегацию сырых данных, уменьшая время выполнения финальных запросов. Это позволило нам рассчитывать метрики достаточно быстро (на этом этапе под «быстро» мы договорились считать 3 и менее секунд).

Вторым неотъемлемым элементом дашбордов стали фильтры, которые позволяют сужать (или расширять) временной период для расчета конкретных показателей, или углубляться, «спустившись», к примеру, с уровня целой линии метро до уровня отдельной станций.

Ниже — пример SQL кода для учета временного промежутка в запросе, выводящим количество валидаций за выбранный период.

WHERE 1=1
{% if filter_values('year')|length > 0%}
AND year IN {{ filter_values('year')|where_in }}
{% endif %}
{% if filter_values('month_name_year')|length > 0%}
AND month_name_year IN {{ filter_values('month_name_year')|where_in }}
{% endif %}

Таким образом мы внедрили внутрь статичных запросов динамическую обработку значений, выбранных в фильтрах. Также нам удалось внедрить обработку фильтров на самых первых этапах работы SQL запросов, дополнительно уменьшая общее время их работы.

Сегодня самый популярный дашборд – «Пассажиропотоки Метро». Он показывает динамику потоков по дням и часам, аналитику по типам билетов, загруженность линий, станций и перегонов, информацию по типам вагонов, пропускную способность вестибюлей, отображает данные на карте.

Кроме него у нас есть панели «Пассажиропоток Автобусы», «Пассажиропоток Трамваи», «Пассажиропоток БКЛ» и другие.

Мы делаем разные по сложности дашборды под разные группы пользователей. Например, «сложные» панели – для аналитиков, позволяющие гибко настраивать фильтры, чтобы получать очень точный ответ даже на очень специфичные и узкие вопросы. Такие дашборды сложны в использовании без хорошей подготовки. Есть и «простые» панели, которые подходят неискушенному пользователю. Они имеют минимум фильтров, максимум защиты от нелогичных действий и позволяют получить ответ на самые популярные, обычно очень простые и общие вопросы.

После появления дашбордов Data Project получил максимальное ускорение. Нам стало проще собирать обратную связь, потребности, просьбы и рекомендации от коллег.

Систематизируй это

Теперь у нас есть единый источник информации, из которого аналитики из разных команд получают данные, имеющие общий «знаменатель». Не нужно выискивать коллег из других блоков, чтобы узнать, где можно получить какие-то специфические сведения и задаваться вопросом, верны ли они. Большое количество данных теперь можно найти и забрать самостоятельно — всё, что мы могли, выложили в удобном формате и подробно описали.

Параллельно мы помогаем поддерживать хороший уровень коммуникаций между командами транспортных аналитиков — а это самые настойчивые скептики, которым обычно никто другой не нужен. В этом нам помогает наша роль — мы строим инфраструктуру данных и ищем решения, которые удовлетворят всех наших коллег.

Дополнительно мы создали новый сервис — к нам можно прийти с запросом на «добычу» данных, которых ещё нет в Институте. Например, кому-то нужна матрица корреспонденции на основе GSM данных. Сотрудник обращается к нам за помощью, мы прорабатываем варианты получения этих данных, получаем их, отдаем заказчику и описываем в Data Wiki, дополняя информацией о типах задач, где эта информация может быть полезна.  К нам можно прийти и с обычной аналитической задачей, которую с ходу не понимаешь, как решить. Мы предложим свои варианты, на основе каких данных можно это сделать, и привлечём коллег, у которых есть опыт в этом вопросе.

Для сотрудников «МосТрансПроекта» мы создали телеграм-канал с новостями DataProject – там рассказываем о свежих публикациях в Data Wiki, новых дашбордах, объясняем, как пользоваться внешними ресурсами, например, публичными системами Роскадастра, Росстата и ЦОДД. Существует также чат для пользователей наших сервисов, где можно оперативно обсудить какой-то вопрос, получить совет. Там же сидят люди, которые развивают Superset, и предупреждают о проведении технических работ на сервисе. Идея в том, чтобы создать долгосрочное комьюнити специалистов, которые так или иначе работают с данными, делятся методиками, подходами, инструментами, совместно решают задачи. Для новичков и состоявшихся аналитиков мы разработали обучающий курс об основных инструментах работы с данными и применяемых системах.

Мы проделали большую работу и уже достигли значимых результатов, но время итоговой оценки пользы проекта еще не пришло. Пока что мы опираемся на обратную связь от коллег и понимаем, что движемся в верном направлении, а значит — продолжим. Мы уверены, что в любой более-менее крупной организации, работающей с данными, нужен некий аналог Data Project: это сильно упрощает повседневную работу и позволяет избежать драматичных ошибок на пустом месте.

А сегодня предлагаем ознакомиться с нашим опытом, возможно, это то, что нужно вам. Команда Data Project – Юрий Бутенко, Руслан Габдрахманов, Ксения Семенова, Алёна Кочеткова и Кирилл Вихров.