Какой инструмент будет подходящим для сбора аналитики структуры данных в потоках данных?

Мы обрабатываем довольно большое количество объектов JSON (сотни тысяч ежедневно), и нам нужно собирать данные о обработанных объектах. Нас интересует получение следующей аналитики по каждому полю обработанных объектов JSON:

• Процент присутствия и отсутствия (null/пустое значение можно считать эквивалентом отсутствующего)
• Возможные значения и процент при использовании значения для высокочастотных значений
• Возможное количество элементов в массиве и процент при возникновении этого количества

Поскольку обработанные объекты JSON поступают из разных источников, нам нужно иметь возможность фильтровать статистику на основе источника. Также нам нужно фильтровать статистику на основе времени (например, “эта неделя”, “последние 90 дней”, “этот год” и т. д.) и на основе определенных предопределенных значений некоторых полей (например, поле A == “X” или поле B == “Y”). Фильтры предопределены, и нам не нужно много из них.

Идеальным результатом для “запроса”, такого как “последние 30 дней из источника S1, когда A == X”, будет выглядеть следующим образом:

• a – присутствует 90%
• a.b – присутствует 40%, перечисляемые значения: A – 30%, B – 25%, C – 10%, D – 5%
• a.c – присутствует 80%, массив, длина: 1 – 90%, 2 – 2%, 3 – 1%
• d – присутствует 40%, перечисляемые значения: X – 50%, Y – 40%, Z – 5%
• e – присутствует 5%, int
• g – присутствует 10%, строка

Структура объектов JSON известна, и она одинакова для всех источников, но мы не обязательно знаем значения перечислений (даже если их относительно немного).

Будут полезны любые подсказки о специализированных инструментах, которые мы могли бы использовать для обработки, хранения и запроса таких статистических данных.

Одним из возможных вариантов может быть Apache Kafka, платформа потоковой передачи событий с открытым исходным кодом, которая поддерживает интеграцию данных, потоки данных и стриминг аналитики. С помощью Kafka можно выполнять окна запросов на потоковых JSON.

Добро пожаловать на datascience.stackexchange,

В вашем проекте есть 3 фазы: Сбор, Хранение и Запрос. Но с точки зрения различных технологических элементов вы можете рассматривать это как 2: Потоковый процессор и No-SQL БД.

Обработка потока имеет множество вариантов, и в общем случае может быть выбрана по:

1. Технологии конечной точки издателя (источник) (служба очередей сообщений, облачное хранилище и т. д.)
2. Объему и скорости потока (остальные “Vs” больших данных здесь четко определены) с учетом SLA вашей системы
3. Целевой No-SQL БД (может требовать / исключать этап предварительной обработки, различные свойства кластера для обработки “Vs” потока и т. д.)

No-SQL БД имеет еще больше вариантов, и в общем случае может быть выбрана по:

1. Типу семейства данных No-SQL (табличный, документный, ключ-значение, временные ряды, граф и т. д.)
2. Пользовательским историям использования (типы запросов, частота использования и т. д.)
3. Требованиям к масштабу (требования к пропускной способности чтения/записи, в основном связанные с “Vs”, но также и с использованием запросов)

=====

Варианты No-SQL могут быть лучше отфильтрованы на этой ранней стадии, поскольку вы предоставили много сведений о природе ваших данных. Поэтому я бы начал с этого:

Природа ваших данных имеет 2 важных элемента: чистый формат json и сильное использование, похожее на временные ряды.

Это в основном предполагает, что вам нужна No-SQL БД, которая:

1. На базе документов (похожих на json)
2. На базе временных рядов
3. Масштабируемая

Я могу подумать о 2 сильных кандидатах:

ElasticSearch против MongoDB

Оба являются:

• Масштабируемыми документными БД с первого дня, при этом Elastic является временной ря牌 с первого дня, а MongoDB добавила поддержку временных рядов начиная с версии 5.
• Оба имеют бесплатную версию с открытым исходным кодом против управляемой платной службы, которую вы можете выбрать

Elastic

• Сильная встроенная статистика по его полям – может быть полезной для вашей статистики по атрибутам
• Возможность делить БД на различные индексы по временной оси (каждый представляет собой БД с временной нарезкой). Это способствует повышению производительности при запросах с временными нарезками (как в вашем случае). Это можно еще больше улучшить, нарезая индексы по источнику, по временной нарезке

MongoDB

• Практически стал пионером типа данных BSON, широко известным своей эффективностью при обработке хранимого бинарного json.

=====

Я рекомендую начать тестировать один из вышеупомянутых вариантов (или другой, который соответствует категории, использованию и т. д.).
Посмотрите, можете ли вы найти более общий подход для любого из них, чтобы поддерживать технологии потребления различных источников, требования “Vs” и SLA.
Например: Elastic имеет компонент Logstash, который утверждает, что поддерживает различные плагины источников данных. Это может помочь вам дополнительно отфильтровать варианты обработки потока.

Здесь нет окончательных вариантов, и вам также следует учитывать текущие знания персонала, которые у вас есть в распоряжении.
(существующие языки клиентской стороны, знакомство с технологией серверной стороны dev-ops, существующие навыки DBA и т. д.).

Кстати, возможность фильтрации по “источнику” может быть реализована либо добавлением атрибута источника к вашему json, либо исключением этого в случае выбора решения с индексом для каждого источника.