0x00 Предисловие

Часто эти незаметные особенности могут больше всего испортить вашу работу.

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

Структура статьи

Смысл и ценность мониторинга качества данных больше обсуждаться не будут, в этой статье в основном обсуждаются следующие три темы:

Что делать при мониторинге качества данных
Как сделать
Проверка достоверности данных

В этой статье будут затронуты некоторые другие аспекты хранилища данных, пожалуйста, обратитесь к предыдущим статьям.

0x01 Что стоит отслеживать

Я разделяю качество данных на три части, чтобы понять:

монитор
тревога
Несколько источников данных

Основное внимание уделяется мониторингу. Этот пункт будет расширен. Источник нескольких данных связан с тем, что в сценарии больших данных у нас слишком много компонентов с открытым исходным кодом на выбор, и данные многих компонентов необходимо отслеживать, и каждый из них Если единый мониторинг является важной темой.

Как показано на рисунке ниже, я сначала перечисляю общую ментальную карту, а затем подробно объясняю каждую часть.

1. Мониторинг

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

1. Ежедневный мониторинг

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

Ниже приведены некоторые из наиболее часто используемых материалов для мониторинга, на мой взгляд:

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

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

2. Согласование данных

В основном это отражается на данных в реальном времени, особенно на посадке данных Kafka.Должен быть механизм мониторинга, чтобы знать посадку наших данных.

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

3. Мониторинг производительности

Я понимаю это как мониторинг доступности данных, что я считаю важным моментом. Если данные, которые вы делаете, очень неудобны для использования другими или слишком медленны для использования вообще, в чем разница между тем, чтобы делать это, и не делать этого?

Похоже, есть несколько моментов, на которые следует обратить внимание при мониторинге производительности:

Необходимо обращать внимание на производительность запросов, таких как определенный индекс es, скорость ответа на запрос в разные периоды времени и тот же запрос presto, hive, kylin и т. д., что можно наблюдать с помощью мониторинга задач.
На влияние чтения и записи данных, а также на влияние сбоев машины обычно не обращают внимания.Однако, как и в случае с es, когда данные записываются, это фактически влияет на считываемые данные.Это необходимо отслеживать и соответствующим образом корректировать.

2. Предупреждение

Не говоря уже о предупреждениях, WeChat, текстовых сообщениях и телефонных звонках.

Также необходимы регулярные сводные оповещения по электронной почте.

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

3. Несколько источников данных

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

В настоящее время автор больше контактирует с Hive (presto, spark sql), Mysql, ES, Redis, Kylin (в основном встроенные кубы), которые обычно используются, но не могут быть исключены из графовых баз данных (neo4j, orientdb) и druid. возможность.

0x02 Как контролировать

Мониторинг данных — это относительно фоновая система, а не внешняя бизнес-система, и ее общая важность может быть поставлена под сомнение, но тем не менее ее стоит делать. Тем не менее, может возникнуть необходимость изменить некоторые идеи.О том, как быстро реализовать и понять основные функциональные точки, стоит подумать.

Здесь не будет реализации, только некоторые дизайнерские идеи, добро пожаловать к обсуждению.

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

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

Ниже эти компоненты будут проанализированы отдельно.

1. Движок правил

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

Дизайн этой части может быть очень гибким, или простой может быть разработан временно. Вот несколько моментов.

1. SQL-шаблон

В большинстве механизмов хранения данные, используемые Sql (например, Hive, Mysql), будут более важным типом данных, мы можем рассмотреть возможность использования шаблона Sql для данных такого типа.

У нас будет таблица или несколько файлов конфигурации для определения наших правил. Проще говоря, например, данные сравниваются по годам, мы можем написать шаблон presto sql для сравнения с историческими данными.Этот вид sql очень прост, просто напишите шаблон самостоятельно.

Этот шаблон самый простой и быстрый, и я думаю, что он решит большинство проблем.

2. Метаданные

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

Уведомление:Это очень важно, это может сэкономить нам большую часть работы, и это относительно стабильно, но может выполнять меньше функций. Его нужно использовать в сочетании с другими.

3. Пользовательские шаблоны

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

Основная нагрузка в этой области должна приходиться на механизм выполнения, но должен быть разработан механизм правил.

2. Исполнительный движок

Это должно быть важнее. Реализация может быть простой или сложной. Давайте поговорим об этом ниже.

1. SQL-выполнение

Многие правила могут быть выполнены через sql, который упоминается в механизме правил.

На самом деле очень рекомендую, это можно сделать для грубого мониторинга в начале.Мы заранее настраиваем большинство sql-шаблонов, а затем настраиваем, какую таблицу нам нужно мониторить.

Для конкретных механизмов выполнения можно рассмотреть presto или spark sql, а для особо крупных задач можно рассмотреть hive.

преимущество:

Просто и легко реализовать
Может удовлетворить большинство потребностей

недостаток:

Недостаточная гибкость, например es, плохая поддержка sql
Низкая скорость: многие SQL-запросы будут выполняться медленно, особенно при использовании движка кустов, это будет очень медленно.
Нестабильный: некоторый мониторинг будет нестабильным, например, повторный мониторинг данных.Для некоторых больших таблиц с помощью presto трудно получить результаты, и он часто зависает, но будет очень медленным, если его заменить на hive.

Итак, как решить эту проблему?

Ну, чтобы решить это, у меня есть только следующие идеи:

Разумное планирование задач. Как правило, кластеры могут выполнять множество задач. Более важно правильно запланировать задачи мониторинга.
Разумная замена исполняющего движка, в следующем разделе будет найдено решение.
Разумные зависимости задач, такие как мониторинг дубликатов данных, неизбежно будут зависеть от того, поступят ли данные.Если данные не поступят, нет необходимости выполнять программу мониторинга дубликатов данных.

2. Получите объем данных напрямую

Как упоминалось выше, упоминается проблема эффективности выполнения Sql, и в этом разделе мы предоставляем оптимизированный метод. Поскольку Hive в настоящее время является очень важным движком, давайте просто поговорим о Hive.

Hive управляется метаданными. В его базу данных метаданных записывается количество записей всех таблиц Hive. Эти записи могут быть непосредственно использованы для мониторинга, связанного с объемом данных, например потери данных, объема данных в годовом исчислении, динамики объема данных. Подождите.

3. Механизм выполнения алгоритма

Многие алгоритмы могут быть реализованы по-своему, что немного сложнее реализовать.

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

4. Несколько источников данных

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

При выполнении это может быть реализовано немного отдельно. Но это относительно не очень сложно.

0x03 Проверка данных

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

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

0xFF Сводка

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

Основная идея здесь есть идея, а конкретную реализацию больше писать не буду. Ведь по потребностям бизнеса степень реализации будет разной.