Мария Ришняк
Автор: Мария Ришняк, заместитель директора по развитию бизнеса компании PARMA TG

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

Для того, чтобы аналитика приносила реальную отдачу, необходимо выполнить два главных условия — достаточный объем и высокое качество данных.

  1. Объем данных. Аналитика будет богаче и объективнее, если использовать несколько источников информации. В отделе продаж, в бухгалтерии и технической поддержке хранятся разные данные об одном и том же клиенте. Объемный портрет заказчика можно создать, если объединить эту информацию. Однако данные в каждом подразделении обрабатываются, хранятся и генерируются по-разному. При этом часть информации дублируется.
  2. Качество данных. Достоверность информации обеспечивается в том числе верификацией и сопоставлением. Несмотря на техническую направленность этой работы, выбор инструментов и методов является завершающей частью проекта. Гораздо важнее определить стратегию и подходы к обработке данных, учитывая их разнообразие и особенности поставленных задач.

 

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

В материале расскажем о важных этапах работы, которые обеспечат достоверные и качественные аналитические данные.

Этап 1. Организационные вопросы

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

Руководителю проекта стоит подумать о мотивации владельцев данных во время подготовки к интеграции. По нашему опыту, хуже всего работают административные мотиваторы — приказы и распоряжения руководства. Лучше показать, какую ценность принесет интегрированная система. Например, снизятся трудозатраты сотрудников на выполнение работ, потому что им будут доступны новые аналитические инструменты.

Этап 2. Разработка модели данных

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

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

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

Этап 3. Определение технологического стека

Выбор правильного технологического стека зависит:

1. от объема данных;
2. количества и характеристик интегрируемых систем;
3. регламентов обмена данными.

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

Пример одного из технологических стеков PARMA TG
Рис. 1. Пример одного из технологических стеков PARMA TG для построения интеграционных систем управления данными.

Этап 4. Стандартизация данных

Единые стандарты нужны, чтобы обеспечить качество и совместимость информации из разных источников в системе. Стандарты содержат правила работы с данными: сбор, хранение, обработку и передачу. Например, в них подробно описан порядок преобразования и верификации информации. Чтобы стандарт стал рабочим документом, обратите внимание на следующие моменты:

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

 

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

Пример 1 описания стандартов для пространственных данных

Пример 2 описания стандартов для пространственных данных

Пример 3 описания стандартов для пространственных данных
Рис. 2. Примеры описания стандартов для пространственных данных

Этап 5. Верификация и сопоставление данных

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

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

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

Примеры отчетов по результатам верификации
Рис. 3. Примеры отчетов по результатам верификации

На этапе верификации мы рекомендуем обратить внимание на три аспекта:

  1. Объем данных. Если аналитическая система работает с большим объемом информации, стоит подумать о проверке дублирующихся элементов до верификации. В одном из проектов в единый контур управления мы интегрировали систему, которая содержала более 150 млн записей — риски потери производительности были крайне высоки. По результатам нагрузочного тестирования, мы приняли решение вынести проверку дублирующихся решений в отдельный этап и провести его до верификации.
  2. Обучение правилам валидации и запросам к базам данных. Сотрудники заказчика должны уметь самостоятельно изменять формулы и включать в систему новые данные, если это потребуется.
  3. Работа с ошибками в данных. Как правило, интегратор выявляет ошибки и передает отчет о них заказчику. В ряде проектов мы представляли отчет в виде дашбордов — так удобнее понимать характер ошибок и системы, в которые они допущены. Однако дальнейшую работу с ошибками заказчик определяет сам. Например, он может ввести регламенты по работе с данными в системах-источниках.

Этап 6. Нормализация данных

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

Например, в колоночную СУБД ClickHouse невозможно загрузить данные в иерархическом формате XML — их надо преобразовать в вид плоской таблицы. ClickHouse ориентирован на высокопроизводительные запросы к большим объемам данных, и работа с иерархическими структурами может замедлить производительность.

Для изменения форматов данных используют разные инструменты. В наших крупных проектах лучше всего зарекомендовала себя Apache Kafka — платформа на основе открытого ПО для обработки потоков данных в реальном времени.