Как было устроено хранилище DWH в TELE2

в 15:54, , рубрики: apex, big data, database design, dwh, edw, oracle, oracle application express, Tele2 Россия, архитектура, база дынных, биллинг, биллинговая система, биллинговые системы, теле2, телекоммуникации и связь, хранение данных, хранилища данных, хранилище данных

Здравствуйте, дорогие друзья.

Сегодня хочу поделиться историей из жизни, как было устроено хранилище DWH в Tele2 до внедрения КХД (EDW). А в следующих статьях рассказать, как внедрялись ETL-инструменты, EDW и BI решения в Tele2.

Поступил я в ИТ подразделение Tele2 в 2012 в отдел по системам отчетности. На тот момент в компании уже было создано хранилище DWH, на котором уже крутилось много процессов по предоставлению отчетности и не только.

Немного по поводу технического стека, который там использовался на тот момент. Для хранилища использовалась Оракловая база объемом 60-100 Тб сервер T4-4 c оперативой под 1 Тб. Туда загружались данные из различных источников. Но основными из них были 4 оракловые биллинговые базы, которые были по сути платформой тарификации. И был отдел ЕРЦ (Единый расчетный центр), который занимался поддержкой этих баз и предоставлением сервисов. Разделение этих баз было по макрорегионам. Причина: слишком большие объемы. Т.е если абонент звонит, скажем, из Московской сим-карты то и расчет стоимости звонка производится в соответствующем биллинге.

Самое топовое железо всегда доставалась биллинговым базам, а на остальные системы выделялось ресурсов по остаточному принципу. Обычно для DWH всегда доставался сервер немного слабее. Т.е. у биллинга стоит железка Т5-4, то у DWH — Т4-4 в наследство.

Но этих ресурсов всегда хватало на покрытие текущих задач и сворачивание отчетности. Данные из биллинга загружались по DB-link-ам. Были настроены классические ETL-процессы, когда ежедневно проходила ночная загрузка данных с небольшими преобразованиями (например, добавление суррогатных ключей). ETL был 2-х видов: полная загрузка для небольших объемов и инкрементальная для больших таблиц таких как например, звонковая детализация, начисления, платежи и т.д. Также еще был такой большой источник, как cdr-файлы которая загружает звонковую информацию и интернет-трафик из коммутаторов и базовых станций. Данные загружаются в виде текстовых файлов с помощью загрузчиков oracle sql loader. Приращение к базе обычно составляло 10-20 Гб в день.
Партиционирование таблиц, индексы, оптимизация планов запросов, хинты в DWH использовать приходилось постоянно. Не было ни дня без зависших либо долгоиграющих сессий, в которых нужно было лезть в план запроса.

image
Структура хранилища DWH в Tele2 до внедрения EDW.

Также одним из основных задач DWH было формирование ежемесячной финансовой отчетности (ЕФО). Она считалась на сервере DWH целых 4 дня из-за больших объемов. Для представления что это такое, скажу что это пакет Oracle в 5 тыс. строк кода на PL/SQL со сложной витиеватой логикой и все это сворачивается в динамике. А потом отчет выгружается на FTP либо на сетевую шару в виде CSV файлов. И все это без использования коробочных решений. Т.е. руками написанный, годами оптимизированный и автоматизированный функционал.

Но база DWH использовалась не только для предоставления регулярной отчетности но и как операционное хранилище. Например, на нем крутился процесс предоставления детализации абонентам из личного кабинета на сайте Tele2. Или передача личных данных в системы СОРМ для служб безопасности.

Также стоит отдельно рассказать про систему Oracle Application Express (APEX) которое имеет особое место для предоставления отчетности. APEX — это среда для быстрой разработки WEB-интерфейсов, либо для предоставления отчетности либо для того, чтобы настроить какой-либо бизнес-процесс. На нем было создан, руками написанный функционал "Запрос данных", где пользователи могли сами себе создать отчет. Т.е. человек заходит, выбирает набор полей для своего отчета, при желании может притянуть первоисточник в виде excel файла, и потом ему приходит отчет на почту в виде заархивированного csv файла. А внутри DWH написано огромное количество PL/SQL процедур и функций которые было по сути встроенным скриптогенератором для отчетов. При этом этот инструмент был настолько популярен внутри компании, что за 8 лет на нем было сформировано более полу миллиона отчетов с разной степенью важности.

Также в APEX было разработано еще много чего интересного. Например, руками написанный функционал для документооборота (DOCOUT) и система Campaign Management (автоматизация маркетинга). В DOCOUT бухгалтера и директора визироавали документы. А в Campaingn Management отдел CBM проводил различные мероприятия для клиентов. Например, выполнял массовую смс-рассылку абонентам о новых тарифах и услугах. И все это проходило через DWH и была интеграция с смс-каналом.

Плюс пара систем для предоставления отчетности таких как Crystal Reports и IBM Lotus RS-отчеты подключались к DWH через RPT-файлы.

На приложенной схеме выше можно посмотреть старую структуру хранилища DWH и движение потоков данных.

Все это более ли менее успешно работало до того момента, пока бизнес не понял что предоставление отчетности уже недостаточно и приняли решение внедрять КХД, BI-системы и BigData.

В общем было много всего интересного. Пожалуй, остановлюсь на этом. А в следующих постах подробно расскажу о том, как внедрялось EDW в Tele2.

Автор: Пудеян Михаил

Источник


* - обязательные к заполнению поля