DataGovernance с наши собствени усилия

Здравей, Хабр!

Данните са изключително ценен актив на компанията. Това твърди почти всяка фирма с цифрова насоченост. Трудно е да се спори с това: без обсъждане на подходите за управление, съхранение и обработка на данни не минава нито една голяма IT конференция.

Данните идват при нас отвън, но също така се формират и вътре в компанията. Говорейки за данните на телекомуникационната компания, това е истинско хранилище на информация за клиента, неговите интереси, навици и местоположение. При правилно профилиране и сегментиране рекламните предложения са най-ефективни. Въпреки това, на практика не всичко е толкова радостно. Данните, които компаниите съхраняват, могат да бъдат безнадеждно остарели, излишни, повтарящи се или да са известни само на тесен кръг потребители. ¯_(ツ)_/¯

С други думи, данните трябва да се управляват ефективно – само по този начин те ще станат актив, донесващ на бизнеса реална полза и печалба. За съжаление, за решаването на въпросите за управлението на данни трябва да преодолеем доста усложнения. Те се дължат основно както на историческото наследство под формата на "зоопаркове" от системи, така и на липсата на единни процеси и подходи за управление. Но какво означава "управление на данни"?

Точно за това ще говорим по-долу, както и за това как ни помогна стекът с отворен код.

Концепцията за стратегическо управление на данни Data Governance (DG) вече е достатъчно известна на руския пазар, а целите, които бизнесът постига в резултат на нейното внедряване, са ясни и точно декларирани. Нашата компания също не стана изключение и си постави за задача да внедри концепцията за управление на данни.

И така, откъде започнахме? Първо, формулирахме основните цели:

1. Да осигурим достъпност на нашите данни.
2. Да осигурим прозрачност на жизнения цикъл на данните.
3. Да предоставим на потребителите на компанията последователни и непротиворечиви данни.
4. Да предоставим на потребителите на компанията проверени данни.

Към днешна дата на пазара на софтуер има десетина инструмента от класа Data Governance.

Но след подробен анализ и изследване на решенията, ние фиксирахме редица критични забележки:

• Повечето производители предлагат комплексен набор от решения, което за нас е излишно и дублира вече съществуваща функционалност. Плюс това, интеграцията в текущата ИТ среда е скъпа по отношение на ресурсите.
• Функционалността и интерфейсът са предназначени за технологи, а не за крайни бизнес потребители.
• Ниска жизнеспособност на продуктите и липса на успешни внедрения на руския пазар.
• Висока цена на софтуера и последващото му поддържане.

Озвучените по-горе критерии и препоръки относно импортозамяната на софтуера за руските компании убедиха нас да се насочим към собствена разработка на opensource стек. Като платформа избрахме Django – безплатен и отворен фреймворк, написан на Python. По този начин определихме ключовите модули, които ще спомагат за посочените по-горе цели:

1. Реестр на отчетите.
2. Бизнес глосар.
3. Модул за описание на техническите трансформации.
4. Модул за описание на жизнения цикъл на данните от източника до BI инструмента.
5. Модул за контрол на качеството на данните.

Реестр на отчетите.

Според резултатите от вътрешни изследвания в големи компании, служителите харчат 40-80% от времето си за търсене на данни при решаване на задачи, свързани с данни. Затова поставихме задачата да направим информацията за съществуващите отчети, които преди са били достъпни само за клиенти, обществено достъпна. По този начин намаляваме времето за създаване на нова отчетност и осигуряваме демократизация на данните.

Реестрът на отчетите стана единен прозорец за отчетност за вътрешни потребители от различни региони, департаменти и подразделения. В него е консолидирана информация за информационните услуги, създадени в няколко корпоративни хранилища на компанията, а такива в Ростелеком има доста.

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

• кратко описание на отчета;
• дълбочина на достъпност на данните;
• сегмент на клиента;
• инструмент за визуализация;
• наименование на корпоративното хранилище;
• бизнес функционални изисквания;
• връзка към отчета;
• връзка към заявка за достъп;
• статус на изпълнението.

Чрез отчетите е налична аналитика на ниво на използваемост, а отчетите попадат в топ списъка на базата на аналитиката на логовете по броя на уникалните потребители. И това не е всичко. Освен общите характеристики, ние предвидихме и детайлно описание на атрибутния състав на отчетите с примери за стойности и методология на изчисленията. Такава детайлност веднага дава на потребителя отговор дали отчетът е полезен за него или не.

Разработката на този модул се оказа важна стъпка в посока демократизация на данните и значително съкрати времето за търсене на необходимата информация. Освен съкращаването на времето за търсене, намаля и броят на запитванията към екипа по поддръжка за предоставяне на консултации. Няма как да не споменем още един полезен резултат, който постигнахме, разработвайки единен регистър на отчетите – предотвратяване на разработването на дублиращи се отчети за различни структурни единици.

Бизнес-глосар

Всички вие знаете, че дори в рамките на една и съща компания бизнесът говори на различни езици. Да, използват се едни и същи термини, но се разбират под тях напълно различни неща. За решаването на този проблем е създаден бизнес-глосар.

За нас бизнес-глосарът не е просто справочник с описание на термините и методологията на изчисление. Това е пълноценна среда за разработка, одобрение и утвърдяване на терминологията, изграждане на взаимовръзки между термините и другите информационни активи на компанията. Преди да попадне в бизнес-глосара, терминът трябва да премине през всички етапи на одобрение с бизнес-заказчиците и центъра за качество на данните. Само след това той става достъпен за използване.

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

Това стана възможно благодарение на използването на идентификаторите на термините от глосара в детайлното описание на отчетите от регистъра и описанието на физическите обекти на базите от данни.

В момента в Глосаpията са определени и одобрени над 4000 термина. Неговото използване опростява и ускорява обработката на постъпилите искания за промяна в информационните системи на компанията. Ако изискваният показател вече е реализиран в някой от отчетите, потребителят моментално ще види набор от готови отчети, където този показател е използван, и ще може да вземе решение за ефективно повторно използване на наличната функционалност или за минимална доработка, без да иницитира нови искания за разработка на нов отчет.

Модул за описание на техническите трансформации и DataLineage

Ще попитате, какви са тези модули? Самото внедряване на Регистър на отчета и Глосария е недостатъчно, необходимо е също така да се приземират всички бизнес термини върху физическата модел на базите данни. По този начин завършихме процеса на формиране на жизнения цикъл на данните от източниковите системи до BI визуализацията, преминавайки през всички нива на хранилището на данни. С други думи – изградихме DataLineage.

Създадохме интерфейс, в основата на който лежеше използвания преди това в компанията формат за описание на правилата и логиката на трансформацията на данни. Чрез интерфейса се въвежда същата информация като преди, но задължително условие е определянето на идентификатора на термина от бизнес глосарията. Така изграждаме връзка между бизнес и физическите слоеве.

Кому е необходимо това? Какво не беше наред със стария формат, с който работихме няколко години? Колко се увеличиха разходите за работа по формулирането на изискванията? С такива въпроси трябваше да се сблъскваме при внедряването на инструмента. Отговорите на тези въпроси са достатъчно прости – необходимо е на всички нас, на дата офиса на нашата компания и на нашите потребители.

Наистина, на служителите им се наложи да се адаптират, в началото това доведе до незначително увеличаване на трудовите усилия за подготовка на документацията, но този въпрос бе решен. Практиката, откритията и оптимизацията на проблемните места свършиха работа. Постигнахме основното – повишихме качеството на разработваните изисквания. Задължителните полета, унифицираните справочници, маските за въвеждане, вградените проверки – всичко това позволи многократно да повишим качеството на описанията на трансформациите. Изоставихме практиката за предаване на скриптове под формата на изисквания за разработка и споделихме знания, които бяха достъпни само за екипа, отговарящ за разработката. Сформираното хранилище на метаданни значително намалява времето за провеждане на регресивен анализ, осигурявайки възможност за оперативна оценка на въздействието на промените на всеки от слоевете на ИТ ландшафта (отчети от витрини, агрегати, източници).

А каква е връзката за обикновените потребители на отчети, какви ползи имат те? Благодарение на възможността за изграждане на Data Lineage, нашите потребители, дори и далеч от SQL и други езици за програмиране, бързо получават информация за източниците и обектите, на базата на които се формира даден отчет.

Модул за контрол на качеството на данните

Всичко, което обсъждахме по-горе относно осигуряването на прозрачност на данните, е без значение без разбирането, че данните, които предоставяме на потребителите, са коректни. Един от основните модули на нашата концепция за управление на данните – модулът за контрол на качеството на данните.

В момента това е каталог с проверки за избрани сущности. Най-близката цел за развитие на продукта е разширяването на списъка с проверки и интеграцията с регистъра на отчетите.
Какво ще ни донесе това и на кого? За крайния потребител на регистъра ще бъде достъпна информация за планираните и фактическите дати на готовност на отчета, резултатите от проведените проверки с динамика, данни за заредените в отчета източници.

За нас интегрираният в работните процеси модул за качество на данните е:

• Оперативно формиране на очакванията на клиентите.
• Вземане на решения относно по-нататъшното използване на данните.
• Получаване на предварителен набор от проблемни точки в ранните етапи на работа за разработване на регулярни проверки на качеството.

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

Екипът на DataOffice

Източник: habr.com