Старые данные — новые смыслы: как разобрать корпоративные хранилища?

Для погружения в тему используем аналогию с машинами — они универсальны и понятны большинству. 

Хранилище данных ближе не к легковушке, а к грузовику. У кого-то это небольшая «Газель», у кого-то многотонный «КамАЗ» — все зависит от масштаба.

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

Дальше наступает период активной эксплуатации. Здесь все знакомо любому владельцу «рабочей лошадки». Машина постепенно теряет скорость, появляются посторонние звуки, а в углы кузова лучше не заглядывать — там можно найти что угодно и далеко не всегда приятное. 

Ремонт чаще всего делают своими силами, это помогает, но наслоения все равно накапливаются. Со временем они превращаются в настоящие авгиевы конюшни.

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

В целом «аптечка первой помощи» при таких проблемах понятна:

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

Это поможет решить технические проблемы (или как минимум забыть о них на какое-то время). Но сами проблемы в данных или, что еще хуже, расхождения показателей без глубокого погружения не разобрать.

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

С одной стороны, для определения качественных данных выделяют семь критериев: точность, полнота, непротиворечивость, достоверность, своевременность, уникальность и доступность. 

В реальности проверять каждую таблицу на эти показатели трудозатратно, тем более часть показателей для задачи «чистки» не очень релевантна.

На первом этапе стоит выделить два технических ключевых показателя и один стратегический. К ним относятся: 

• - Качество данных, как некоторая объединенная метрика «точности» и «достоверности». Ведь если данные некачественные, то и «хорошими» они быть не могут.
• - Доступность данных в широком смысле слова — это и описание, доступы и частота запросов. Если данные описаны плохо, используют их редко, то вряд ли они сильно нужны и есть риск, что их используют некорректно.
• - Стратегический критерий — критичность (востребованность) данных с точки зрения бизнеса. Этот показатель можно использовать как приоритет в процессе разбора хранилища.
• 
  

Так, если говорить «за все хорошее, против всего плохого», то базовый ответ на вопрос раздела такой:

• - «хорошие» данные качественны, важны для бизнеса и хорошо описаны; 
• - «плохие» данные — это когда бизнес ничего не знает о них, качество вызывает вопросы и они не имеют никакого описания.
• 
  

Хорошо, если таким образом можно будет разделить 20–30% данных, а остальное будут «другие» данные, которые используются периодически, имеют несколько версий (никто не знает, какая из них верная), и описание для них создавалось при добавлении новой информации. И чтобы разобрать их придется сделать еще несколько шагов:

• - по-прежнему используем бизнес как приоритет;
• - если данные лежат в нескольких версиях — нужно разобраться, в чем разница, и оставить только одну, самую важную;
• - все те данные, которые будут признаны «полезными», тоже должны быть описаны. 

Очевидно, что все данные, которые имеются сейчас в хранилище, через такой процесс не пропустишь. Но по большому счету в этом нет необходимости — цель всех этих действий отделить «зерна от плевел».

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

Для этого и существуют практики Data Governance. Они охватывают почти все, что нужно для того, чтобы поддерживать данные в «опрятном» виде. 

Часто можно услышать: «DG слишком сложно, слишком дорого и в реальной жизни не встречается», и отчасти это правда. Это действительно непросто и требует ресурсов, но качественные данные всегда стоят дорого. 

Важно другое: Data Governance не бывает только «включен» или «выключен». Его можно внедрять частично, выбирая подходящие практики. Более того, для разных типов данных внутри организации уровень контроля может быть разным.

В этом контексте уместно говорить об уровнях зрелости. Пятая ступень — это полная реализация всех практик DG, но до нее доходят немногие. В большинстве случаев компаниям достаточно уровня где-то между 2,5 и 3,5. Главное — уйти от нулевой или первой ступени, когда данные либо совсем не контролируются, либо управляются от случая к случаю.

Если говорить о базовом уровне, то рекомендованный стартовый набор практик выглядит следующим образом: 

• - Data Quality — контроль качества данных. Если данные используются в работе, нужно быть уверенным, что они корректные. 
• - Data Catalog — единый справочник и глоссарий имеющихся данных. В нем должно быть описание таблиц и атрибутов: что и где лежит, бизнес-описания, логика вычислений и источники. Без этого бизнес рано или поздно начнет брать данные «откуда попало». Результат предсказуем: на один и тот же вопрос разные люди дадут разные ответы.
• - Ролевая модель. Здесь все просто: если никто не отвечает за актив, он неизбежно деградирует и превращается в пассив. У данных должен быть владелец, а иногда и несколько — с четко прописанными ролями и зонами ответственности. 
• 
  

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

Если такие процессы внедрены с самого начала (или хотя бы после генеральной уборки), то «плохие» данные легко отсеивать при регулярных проверках, в том числе автоматически. 

Наладить все это быстро и дешево не получится, но результат того стоит: бизнес получает только качественные данные, а значит — правильные решения.