Привет, Хабр! Меня зовут Леонид Калядин, я Cluster Data lead в МТС Диджитал, занимаюсь развитием практики Data Governance и Data Quality в 25+ продукта кластера. Мне довелось долго работать в консалтинге и разбираться с проблемами в других системах. Вот смотришь со стороны на ИТ-продукт: все классно и продумано, должно работать как часы. А потом спускаешься на уровень данных и хватаешься за голову: как же допустили такую ошибку? Ее можно было избежать, если задать пару вопросов на стадии проектирования. Зато теперь переделывать все чуть ли не с нуля и ждать возможности вписать изменения в какой-нибудь релиз. Красота!

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

В общем,
Если вы сломать решили всю отчетность у коллег,
Обязательно зайдите в этой записи под кат!

Не используйте стандартов — Творчество важней всего

Зачем вам стандарты хранения истории данных, такие как SCD? Это лишние хлопоты: просто храните все пачкой и никогда не используйте идентификаторы изменения строк, вроде updated_at или created_at. Важно, чтобы хаос преобладал — пусть бизнес сам разбирается с данными. 

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

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

Их используют, например, чтобы вывести данные по состоянию на отчетную дату. Для этого фиксируемся на интервале where {{ your_date }} between valid_from and valid_to. Если отчет должен содержать актуальные записи, то можно фиксироваться на valid_to = ‘9999-12-31 00:00:00’.

Естественно, мириться с таким вопиющим непрофессионализмом никак нельзя. Ваша система же наверняка проработает и двести, и триста лет. Отличный выход — использовать вместо фиксированной даты переменное значение. Например, воспользоваться формулой now() + interval ‘1 day’. 

Очень удобное и надежное решение — при каждом пересчете эта дата будет изменяться. Если в отчете нужно показать актуальное состояние, то фиксироваться на определенную дату из будущего уже не получится, только на интервал now() between valid_from and valid_to, только хардкор. Если же пересчет сломается и наступит дата, большая, чем now()+ inteval’1 day’, то запрос ничего не вернет. Представьте радость бизнес-пользователя, который вместо надоевших данных увидит наконец пустую выгрузку и сможет смело идти пить чай. Главное, не поддаваться давлению коллег: это абсолютно логичное решение, которое, наверное, можно доказать математически.

Данные не изучайте, так грузите. Бизнес разберется сам

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

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

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

Про проверки и ошибки Вы не думайте впустую: Пусть искрится и горит В закромах системы

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

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

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

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

Повеселились и хватит: вместо заключения

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

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

Как именно это делать, какие вопросы задавать и на что смотреть, можно будет узнать и обсудить 17 сентября на конференции Flowconf. Мой доклад — с 15:45 до 16:30. Готов ответить на ваши комментарии, и до встречи в онлайне!