Bonjour chers amis.
Aujourd'hui, je veux partager une histoire de vie sur la façon dont le stockage DWH a été organisé dans Tele2 avant l'introduction de QCD (EDW).
J'ai intégré le département informatique de Tele2 en 2012 au sein du département des systèmes de reporting. À cette époque, le référentiel DWH était déjà créé dans l'entreprise, sur lequel de nombreux processus de reporting et plus tournaient déjà.
Un peu sur la pile technique qui y était utilisée à l'époque. Pour le stockage, la base de données Oracle a été utilisée avec une capacité de 60 à 100 To de serveur T4-4 avec 1 To de fonctionnement. Des données provenant de diverses sources y ont été téléchargées. Mais les principaux étaient 4 bases de facturation Oracle, qui étaient essentiellement une plateforme de facturation. Et il y avait un département qui s'occupait de soutenir ces bases de données et de fournir des services. La séparation de ces bases s'est faite par macro-régions. Raison: les volumes sont trop importants. Autrement dit, si un abonné appelle, par exemple, à partir d'une carte SIM de Moscou, le coût de l'appel est calculé dans la facturation correspondante.
Le matériel haut de gamme est toujours allé aux bases de données de facturation et les ressources ont été allouées aux systèmes restants selon le principe résiduel. Habituellement, pour le serveur DWH, le serveur est toujours un peu plus faible. C'est-à-dire la facturation a un matériel T5-4, puis DWH a un héritage T4-4.
Mais ces ressources ont toujours été suffisantes pour couvrir les tâches courantes et réduire les rapports. Les données de facturation ont été téléchargées via DB-link. Les processus ETL classiques ont été mis en place lorsque des téléchargements de données nocturnes ont eu lieu avec de petites conversions (par exemple, l'ajout de clés de substitution). ETL était de 2 types: pleine charge pour les petits volumes et incrémentielle pour les grandes tables telles que, par exemple, les détails des appels, les frais, les paiements, etc. Il existe également une source aussi importante que les fichiers texte qui téléchargent les informations sur les appels et le trafic Internet à partir des commutateurs et des stations de base. Les données sont téléchargées sous forme de fichiers texte à l'aide des chargeurs d'Oracle SQL Loader. L'incrément à la base était généralement de 10 à 20 Go par jour.
Les partitions de partitionnement, les index, l'optimisation des plans de requête, les indices dans DWH devaient être utilisés en permanence. Il n'y avait pas une journée sans sessions suspendues ou de longue durée où il fallait monter dans le plan de demande.
La structure de stockage DWH dans Tele2 avant l'introduction d'EDW.
En outre, l'une des principales tâches de DWH était de générer des états financiers mensuels (ETF). Il a été considéré sur le serveur DWH pendant 4 jours entiers en raison des volumes importants. Pour imaginer ce que c'est, je dirai qu'il s'agit d'un package Oracle de 5 000 lignes de code PL / SQL avec une logique ornée complexe et tout cela est minimisé en dynamique. Et puis le rapport est téléchargé sur FTP ou sur un partage réseau sous forme de fichiers CSV. Et tout cela sans l'utilisation de solutions en boîte. C'est-à-dire fonctionnalités manuscrites, optimisées et automatisées au fil des ans.
Mais la base de données DWH a été utilisée non seulement pour fournir des rapports réguliers, mais aussi comme stockage opérationnel. Par exemple, il a tourné autour du processus de fourniture de différentes informations aux abonnés à partir d'un compte personnel sur le site Web de Tele2.
Il convient également de mentionner séparément le système Oracle Application Express (APEX), qui a une place particulière pour les rapports. APEX est un environnement pour le développement rapide d'interfaces WEB, soit pour le reporting, soit pour mettre en place un processus métier. Sur celui-ci a été créé, à la main, une fonctionnalité écrite "Report upload", où les utilisateurs pouvaient créer un rapport pour eux-mêmes. C'est-à-dire une personne entre, sélectionne un ensemble de champs pour son rapport, si elle le souhaite, elle peut extraire la source sous forme de fichier excel, puis elle reçoit un rapport par courrier électronique sous la forme d'un fichier csv archivé. Et à l'intérieur de DWH, un grand nombre de procédures et de fonctions PL / SQL sont écrites, qui étaient essentiellement un générateur de script intégré pour les rapports. De plus, cet outil était si populaire au sein de l'entreprise que plus de huit ans plus d'un demi-million de rapports avec différents degrés d'importance y ont été générés.
APEX a également développé beaucoup d'autres choses intéressantes. Par exemple, une fonctionnalité manuscrite pour le workflow et le système d'automatisation du marketing. Dans le premier, le personnel a approuvé les documents. Et deuxièmement, le département marketing a organisé divers événements pour les clients. Par exemple, il a effectué une distribution de masse de SMS aux abonnés sur les nouveaux tarifs et services. Et tout cela est passé par DWH et il y a eu intégration avec le canal SMS.
De plus, un couple de systèmes de rapports tels que Crostal Reports et IBM Lotus connectés à DWH via des fichiers RPT.
Dans le diagramme ci-dessus, vous pouvez voir l'ancienne structure du référentiel DWH et le flux de données pour 2012. Avec la structure actuelle, cela n'a rien à voir.
Tout cela a fonctionné avec plus ou moins de succès jusqu'au moment où l'entreprise s'est rendu compte que le reporting n'était plus suffisant et a décidé d'introduire QCD, BI-systems et BigData.
En général, il y avait beaucoup de choses intéressantes. Je m'attarderai peut-être là-dessus. A bientôt.