Architecture Big Data

En tant qu'architecte de logiciels, mon objectif est de réaliser des tâches compliquées par le biais de solutions simples. Les différents éléments d'une solution ont chacun des avantages et des inconvénients, l'art consiste à les combiner de manière à ce que la somme des avantages soit conservée et que les inconvénients s'annulent mutuellement.

Pour de nombreux utilisateurs SAP, il s'agira dans un premier temps de permettre l'Analytics avec Big Data, c'est-à-dire de trouver des informations intéressantes dans ces énormes quantités de données.

Mais au lieu de construire une infrastructure entièrement nouvelle pour les utilisateurs, je combine le système de big data avec l'entrepôt de données existant.

Le Data Scientist reçoit le Data Lake, une zone de données dans laquelle se trouvent toutes les données brutes, et un outil puissant qui lui permet également de préparer ces données brutes. Le résultat de ses activités sont de nouveaux indicateurs que j'ajoute dans le data warehouse. Cela présente plusieurs avantages :

• L'utilisateur professionnel continue à utiliser ses outils habituels pour l'analyse, mais il dispose désormais de plus d'indicateurs.
• Le Data Scientist a accès à toutes les données, Big Data et données ERP.
• Pour l'IT, l'effort est gérable.

Cette solution est également intéressante du point de vue des coûts par rapport aux avantages et aux probabilités de réussite : en m'appuyant sur ce qui existe déjà, j'ai une portée de projet réduite, donc un risque de projet minimisé et une mise en œuvre moins coûteuse, tout en exploitant pleinement les avantages potentiels.

Ainsi, une solution Big Data ne se compose plus que de deux éléments : le Data Lake avec les données brutes et un cluster de serveurs dans lequel se fait la préparation des données.

Data Lake ou SAP Vora

Par le passé, SAP a proposé SAP Vora comme Data Lake et commercialise la solution Altiscale sous le nom de Big Data Services. Mais au fond, le Data Lake n'est qu'un grand système de fichiers. Si malgré tout, le service commercial de SAP propose Vora, Altiscale ou DataHub, il convient de poser un regard très critique sur le prix et la prestation.

Pourquoi ne pas commencer tout simplement dans la première phase du projet avec un disque dur local ou le serveur de fichiers central ? Tant qu'il y a suffisamment de place et que le coût de l'espace de stockage n'est pas trop élevé, c'est tout à fait valable. Copier les fichiers peut se faire à tout moment et sans problème, c'est pourquoi je ne bloque rien pour l'avenir.

Préparation avec Apache Spark

Pour le traitement de ces données, la plupart des projets utilisent aujourd'hui le framework open source Apache Spark. Il permet d'écrire en quelques lignes de code des programmes pour la préparation des données et de les exécuter en parallèle dans un cluster de serveurs.

Il n'y a aucune raison pour moi de réinventer la roue, d'autant plus qu'une telle installation est très simple et peut être effectuée en dix minutes : télécharger le paquet sur un petit ordinateur Linux, l'extraire et lancer un maître et un premier travailleur via la commande start-all.

Défi : algorithme

La technique est gérable avec l'approche ci-dessus. C'est le développement des algorithmes pour les nouveaux indicateurs qui est la partie la plus difficile : comment obtenir des informations à partir des données de masse, qui se traduiront finalement par des bénéfices pour l'entreprise ?

C'est précisément là que se joue la réussite d'un projet de big data. C'est pourquoi je pense qu'il est judicieux d'investir dans ce domaine, par exemple dans la formation de data scientists.

Dans les chroniques suivantes, je répondrai entre autres aux questions suivantes : Pourquoi utiliser Apache Spark et non un outil ETL ? Pourquoi a-t-on besoin du Data Lake alors que les données se trouvent déjà dans le Data Warehouse ? Etc.