Всем привет! Хочу поделиться с теми, кто интересуется большими данными, своей работой. Дело в том, что довольно часто, когда мы читаем какую-либо статью или техдоку по этой предметной области, приводимые примеры опираются на крохотные наборы данных. И это не даёт понимания и погружения в специфику — напоминает обучение вождению на Need for speed. Более того, я не смог найти более-менее крупные наборы реальных бизнесовых данных или те, что были хотя бы похожи на реальные. Ну и как это часто бывает, пришлось сделать самому. Если вас интересует эта тематика, проследуйте под кат.

Предыстория

Я являюсь преподавателем по продуктам в компании Arenadata, а также веду занятия в нескольких вузах. Ну и, коль скоро, погружен в оба этих мира, то естественным образом мне в компании поручаются всякие совместные с вузами активности. И вот в начале 2024 года МГПУ проводил ДатаХакатон, в котором Arenadata была кейсодержателем. В рамках хакатона нужно было предложить кейс, позволивший бы протестировать скилы студентов по использованию инструментов и подходов для анализа данных, особенно больших данных. И тут возникает вопрос: а что, собственно говоря, студенты будут обрабатывать? Нам нужны данные, и не просто данные, а те самые — с тремя V. То есть с большой скоростью поступления, большим объёмом и большим разнообразием форматов. Есть множество доступных датасетов, например. Однако большинство представленных наборов данных в основном предназначены для задач машинного обучения и мало привлекательны для дата-инженеров, особенно в сфере работы с большими объёмами данных. Кроме того, многие из этих датасетов недостаточно крупные — даже такие, как датасет «Вышки сотовой связи». Там всего один CSV-файл, в котором около 40 млн записей. Для разрабатываемого кейса хотелось иметь более объёмный и реалистичный пример, так как в реальной жизни задачи всегда сложнее, чем в учебных примерах.

Поэтому я решил пойти другим путём и попробовать найти реальные данные. К сожалению, это оказалось непросто: ни одна компания не смогла предоставить значимый объём продуктовых данных. Даже обезличенных. Жаль, что тут опенсорса гораздо меньше, чем в разработке ПО. Тогда я решил взять за основу продуктовую задачу и сгенерировать под неё синтетический набор данных, максимально имитирующих реальные. Проведя опрос своих знакомых-инженеров, я определился с задачей: это будет анализ данных телеком-компаний на предмет выявления аномалий в данных. Формулировку задачи и образцы данных я провалидировал у двух своих коллег — инженеров, которые обеспечивали пайплайны и инструменты обработки данных в телеком-компаниях России и Америки.

Задача построения модели комплексная, поэтому начнём с главного. С линейного оборудования узлов связи раз в какое-то время (например, раз в 10 минут) снимаются логи, содержащие информацию об интернет-соединении абонентов, как то номер сеанса связи, дата начала, конца и его продолжительность, а также номер абонента и количество скачанного и переданного им трафика. Эти данные могут извлекаться из контура узлов связи различным образом (например, NetFLow) и приземляются на хранилище в виде текстовых файлов, в имени которых прописан номер линейного коммутатора, а также дата и время создания файла. Как часто бывает в жизни, разное оборудование выдаёт данные в разном формате, а именно это касается разделителя полей в текстовом файле, формата даты, единиц измерения трафика (биты или байты). В представленном наборе данных есть дополнительная табличка (psxattrs.csv) в которой указаны атрибуты конкретных коммутаторов.

Собственно говоря, именно подобные данные и собирались в задаче, о которой мне рассказали мои коллеги. Когда данные прилетали на хранилище, они обрабатывались аналитическим пайплайном для выявления аномалий потребления трафика абонентами за последнее время. В частности, если характер потребления трафика кардинально изменился в сторону увеличения потребления по сравнению с предыдущим за аналогичный период, то есть подозрение на то, что оборудование абонента взломано и превратилось, например, в узел DDOS-сети или в спам-сервер. Такой пайплайн запускался каждый час, и результатом его работы была плоская таблица — витрина данных, в которой представлен список работавших в последний час абонентов (с их контактными данными) и их предполагаемый статус: was hacked или нет. Специалисты компании просматривали эту витрину и абонентам с подозрением на взлом временно ограничивали доступ в интернет, после чего связывались с абонентом, чтобы уточнить, что именно произошло. Но это уже не наш вопрос.

Для имитации этой задачи я и написал программу для генерации синтетического набора данных. В данный момент создано три набора:

• Telecom10k — телеком-компания с 10 000 абонентов, 1 млн записей, 51 Мб данных.

• Telecom100k — телеком-компания с 100 000 абонентов, 11 млн записей, 688 Мб данных.

• Telecom1000k — телеком-компания с 1 000 000 абонентов, 117 млн записей, 7,2 Гб данных.

При этом во всех случаях данные представлены за семь дней c шести коммутаторов. Поскольку данные генерируются программно, то можно было сделать и гораздо больше данных, но тяжело было бы их опубликовать для публичного потребления при слишком большом объёме. Я опубликовал все три варианта датасета под лицензией CC BY 4.0 на платформе Mendeley Data — со ссылкой на GitHub.

Выше я описал данные, снимаемые с оборудования, которые имеют специфику потоковых данных. И хотя сами данные представлены в виде текстовых файлов, совсем несложно превратить их именно в потоковые — например, написав утилитку в три строчки, которая будет отправлять строки файлов в виде сообщений через какой-либо брокер сообщений (например, Apache Kafka). Тем не менее упомянутые оперативные данные — это далеко не все. В реальной жизни данные разного вида хранятся и обрабатываются в разных системах. Например, информация о клиентах, такая как мастер-данные, хранится в MDM-системах. А, например, данные о состоянии абонентского тарифного плана — это бизнесовые данные, то есть они хранятся в OLTP-системе. Все эти данные нужны для построения витрины, глядя на которую оператор увидит не просто безымянного абонента со статусом, а сводную информацию с контактными данными и параметрами тарифного плана, что нужно для общения с абонентом. Именно это и воспроизводится в представленном датасете, в котором представлены семь таблиц с данными из разных систем.

Посмотреть детальное описание схемы данных и форматов файлов можно тут.

Собственно, теперь поговорим о том, что же мы хотели увидеть от команд, участников ДатаХакатона. В общем, те самые этапы обработки данных: загрузку, очистку, эксплоративный анализ, выдвижение гипотез о методе обнаружении аномалий из проверки и, конечно же, создание пайплайна для генерации витрин — бизнесовой цели. Бонусом предполагались визуализация данных и использование инструментов Data Governance. В случае успешного и полного выполнения задания студент получал комплект витрин (из расчёта по одной за час), в которых приведены описание подключавшихся клиентов с их реквизитами и статусом подозрения на взлом. Для того чтобы себя проверить, можно воспользоваться файлом RESULT, в котором приведён список ID всех взломанных абонентов.

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

Предложенное решение

В заключение хотел бы отметить, что у меня, кажется, получилось создать набор данных, который позволит дата-инженеру оценить эффективность применяемых методик и (или) инструментов. Собственно, на этом заканчиваю описание набора данных TelecomX и надеюсь, что он пригодится для совершенно различных применений. И да, information wants to be free, поэтому представленный набор данных публикуется под открытой лицензией, а уж если найдутся желающие присоединиться к проекту и улучшить датасет, то это было бы здорово.