Привіт, Хабре!
Дані – це найцінніший актив компанії. Про це заявляє чи не кожна компанія із цифровим ухилом. З цим складно сперечатися: без обговорення підходів управління, зберігання та обробки даних зараз не відбувається жодна велика IT-конференція.
Дані до нас надходять зовні, також вони формуються всередині компанії, а якщо говорити про дані телеком-компанії, то це для внутрішніх співробітників джерело інформації про клієнта, його інтереси, звички, місцезнаходження. При грамотному профілюванні та сегментації рекламні пропозиції вистрілюють найефективніше. Однак, на практиці не все так райдужно. Ті дані, які зберігають компанії, можуть бути безнадійно застарілими, надмірними, повторюваними, або про існування нікому не відомо, крім вузького кола користувачів. ¯_(ツ)_/¯
Одним словом, даними потрібно ефективно керувати – тільки в такому разі вони стануть активом, який приносить бізнесу реальну користь та прибуток. На жаль, для вирішення питань управління даними потрібно подолати чимало труднощів. Зумовлені вони переважно як історичною спадщиною у вигляді «зоопарків» систем, так і відсутністю єдиних процесів та підходів до управління ними. Але що означає «керувати даними»?
Саме ми про це ми і поговоримо під катом, а також про те, як нам допоміг opensource-стек.
Концепція стратегічного управління даними Data Governance (DG) вже досить відома на російському ринку, і цілі, що досягаються бізнесом в результаті її впровадження, зрозумілі та чітко декларовані. Наша компанія не стала винятком і поставила собі завдання впровадження концепції управління даними.
Тож з чого ми почали? Для початку ми сформували собі ключові цілі:
- Забезпечити доступність наших даних.
- Забезпечити прозорість життєвого циклу даних.
- Дати користувачам компанії узгоджені несуперечливі дані.
- Дати користувачам компанії перевірені дані.
На сьогоднішній день на ринку програмного забезпечення представлено десяток інструментів класу DataGovernance.
Але після детального аналізу та вивчення рішень ми зафіксували для себе низку критичних зауважень:
- Більшість виробників пропонують комплексний набір рішень, який для нас є надлишковим та дублює вже існуючу функціональність. Плюс дорога з погляду ресурсів інтеграція до поточного ІТ-ландшафту.
- Функціональність та інтерфейс призначені для технологів, а не кінцевих бізнес-користувачів.
- Низька приживаність товарів хороших і відсутність успішних впроваджень російському ринку.
- Висока вартість програмного забезпечення та подальшого супроводу.
Озвучені вище критерії та рекомендації щодо імпортозаміщення софту для російських компаній переконали нас піти у бік власної розробки на opensource-стеку. Як платформу вибрали Django – безкоштовний та вільний фреймворк, написаний на Python. І таким чином ми виділили для себе ключові модулі, які сприятимуть озвученим вище цілям:
- Реєстр звітів.
- Бізнес-глосарій.
- Модуль опису технічних трансформацій.
- Модуль опису життєвого циклу даних від джерела до BI інструменту.
- Модуль контролю за якістю даних.
Реєстр звітів
За результатами внутрішніх досліджень великих компаній, вирішуючи завдання, пов'язані з даними, співробітники витрачають 40—80% часу з їхньої пошук. Тому ми поставили собі завдання зробити відкритої інформацію про існуючі звіти, які раніше були доступні тільки замовникам. Тим самим ми скорочуємо час формування нової звітності і забезпечуємо демократизацію даних.
Реєстр звітів став єдиним вікном звітності для внутрішніх користувачів із різних регіонів, департаментів, підрозділів. У ньому консолідована інформація щодо інфосервісів, створених у кількох корпоративних сховищах компанії, а їх у Ростелекомі чимало.
Але реєстр – це не просто сухий список розроблених звітів. Для кожного звіту ми надаємо інформацію, необхідну для самостійного знайомства з ним:
- короткий опис звіту;
- глибина доступності даних;
- сегмент замовника;
- інструмент візуалізації;
- найменування корпоративного сховища;
- бізнес-функціональні вимоги;
- посилання на звіт;
- посилання на заявку на доступ;
- статус реалізації.
За звітами доступна аналітика рівня використання, і звіти потрапляють у топ списку на основі аналітики логів за кількістю унікальних користувачів. І це не все. Крім загальних характеристик, ми передбачили і детальний опис атрибутного складу звітів з прикладами значень та методикою розрахунків. Подібна деталізація вже відразу дає користувачеві відповідь, чи корисний для нього звіт чи ні.
Розробка цього модуля стала важливим кроком у частині демократизації даних та значно скоротила час пошуку необхідної інформації. Крім скорочення часу пошуку, знизилася кількість звернень до команди супроводу на надання консультацій. Не можна не відзначити ще один корисний результат, якого ми досягли, розробивши єдиний реєстр звітів – запобігання розробці дублюючих звітів для різних структурних одиниць.
Бізнес-глосарій
Всі ви знаєте, що навіть у рамках однієї і тієї ж компанії бізнес говорить різними мовами. Так, використовують одні й самі терміни, але розуміють під ними зовсім різні речі. Вирішити цю проблему покликаний бізнес-глосарій.
Для нас бізнес-глосарій — не просто довідник із описом термінів та методологією розрахунку. Це повноцінне середовище розробки, погодження та затвердження термінології, побудови взаємозв'язків термінів з іншими інформаційними активами компанії. Перед тим як потрапити до бізнес-глосарій, термін повинен пройти всі етапи узгодження з бізнес-замовниками та центром якості даних. Тільки після цього він стає доступним для використання.
Як я вже написав вище, унікальність даного інструменту в тому, що він дозволяє проводити зв'язки від рівня бізнес-терміну до конкретних звітів користувача, в яких він використовується, а також до рівня фізичних об'єктів баз даних.
Це стало можливим через використання ідентифікаторів термінів глосарію в детальному описі звітів з реєстру та описі фізичних об'єктів баз даних.
Зараз у Глосарії визначено та узгоджено вже понад 4000 термінів. Його використання спрощує і прискорює обробку запитів, що надходять, на зміну в інформаційних системах компанії. Якщо необхідний показник вже реалізований у будь-якому звіті, користувач відразу побачить набір готових звітів, де цей показник використаний, і зможе прийняти рішення про ефективне повторне використання наявної функціональності або про її мінімальну доопрацювання, не ініціюючи нових запитів на розробку нового звіту.
Модуль опису технічних трансформацій та DataLineage
Ви спитаєте, що це за модулі? Мало легко впровадити Реєстр звіту і Глосарій, потрібно ще приземлити всі бізнес-терміни на фізичну модель баз даних. Тим самим ми змогли завершити процес формування життєвого циклу даних від систем джерел до BI-візуалізації через усі шари сховища даних. Іншими словами, побудувати DataLineage.
Ми розробили інтерфейс, в основі якого лежав формат опису правил і логіки трансформації даних, що використовується раніше в компанії. За допомогою інтерфейсу заводиться та сама інформація, що й раніше, але обов'язковою умовою стало визначення ідентифікатора терміну з бізнес-глосарію. Так ми і вибудовуємо зв'язок між бізнес- та фізичними верствами.
Кому це потрібно? Чим не влаштував старий формат, із яким працювали кілька років? Наскільки збільшилися трудовитрати формування вимог? З такими питаннями нам доводилося стикатися у процесі впровадження інструменту. Тут відповіді досить прості – це потрібно всім нам, дата-офісу нашої компанії та нашим користувачам.
Справді, співробітникам довелося перебудовуватись, спочатку це призвело до незначних збільшення трудовитрат на підготовку документації, але з цим питанням ми розібралися. Практика, виявлення та оптимізація проблемних місць зробили свою справу. Ми домоглися головного — підвищили якість вимог, що розробляються. Обов'язкові заповнення поля, уніфіковані довідники, маски введення, вбудовані перевірки – усе це дозволило в рази підвищити якість описів трансформацій. Ми пішли від практики передачі скриптів у вигляді вимог на розробку, розшарили знання, які були доступні лише команді, яка займається розробкою. Сформована база метаданих скорочує час на проведення регрес-аналізу, забезпечує можливість оперативної оцінки впливу змін на будь-якому з шарів ІТ-ландшафту (звіти вітрини, агрегати, джерела).
А до того ж тут звичайні користувачі звітів, які плюси для них? Завдяки можливості побудови DataLineage наші користувачі, навіть далекі від SQL та інших мов програмування, оперативно отримують інформацію про джерела та об'єкти, на основі яких формується той чи інший звіт.
Модуль контролю якості даних
Все, про що ми говорили вище щодо забезпечення прозорості даних, не важливо без розуміння того, що дані, які ми надаємо користувачам, — коректні. Один із важливих модулів нашої концепції Data Governance – модуль контролю якості даних.
На поточному етапі це каталог перевірок щодо вибіркових сутностей. Найближча мета розвитку продукту – це розширення переліку перевірок та інтеграція з реєстром звітів.
Що це дасть і кому? Для кінцевого користувача реєстру буде доступна інформація про планові та фактичні дати готовності звіту, результати відпрацьованих перевірок з динамікою, відомості щодо завантажених у звіт джерел.
Для нас інтегрований у робочі процеси модуль якості даних:
- Оперативне формування очікування замовників.
- Прийняття рішень щодо подальшого використання даних.
- Отримання попереднього набору проблемних точок на початкових етапах роботи розробки регулярних контролів якості.
Безумовно, це перші кроки у вибудовуванні повноцінного процесу управління даними. Але ми впевнені, що тільки цілеспрямовано займаючись цією роботою, активно впроваджуючи інструменти DataGovernance у робочий процес, ми забезпечимо нашим клієнтам інформативність, високий рівень довіри до даних, прозорість їх отримання та підвищимо швидкість виведення нової функціональності.
Команда DataOffice
Джерело: habr.com