Alimenter un entrepôt de données par des données issues de services web. Une approche médiation pour le prototype DaWeS

Transcription

1 Alimenter un entrepôt de données par des données issues de services web. Une approche médiation pour le prototype DaWeS John Samuel LIMOS (Laboratoire d Informatique, de Modélisation et d Optimisation des Systèmes), Ecole Doctorale Sciences Pour l Ingénieur Université Blaise Pascal, Aubière Résumé Toute entreprise a besoin d optimiser son fonctionnement afin d être la plus compétitive possible. Les plus grandes d entre elles ont les ressources pour maintenir d énormes bases (appelées entrepôts) de données d exploitation. Ces données permettent de calculer des indicateurs de performance, induisant une meilleure compréhension du fonctionnement des processus métier sous-jacents. Ceci aboutit à un meilleur pilotage d entreprise ainsi qu à un meilleur respect des normes internationales de qualité. Les petites et moyennes entreprises ont quant à elles des moyens plus réduits pour conserver et utiliser leurs données d exploitation. Par ailleurs, elles dépendent de plus en plus de multiples services web pour leurs tâches quotidiennes. Ne pouvant pas assumer le coût d un entrepôt de données, il serait intéressant qu elles puissent disposer d un autre service capable de gérer lui-même les statistiques sur leur utilisation. DaWeS est une plateforme gérant des entrepôts de données dynamiques, alimentés automatiquement par des services web hétérogènes via leur API (c est-à-dire les interfaces logicielles permettant d accéder à ces services web), et ayant la capacité de réagir (le plus) automatiquement (possible). 1 L entrepôt de données et Les Services Web L arrivée d internet et des smartphones a changé nos vies quotidiennes. On est toujours connecté sur internet avec nos amis et notre famille grâce à beaucoup de services web. Également les entreprises, en particulier les petites entreprises utilisent beaucoup de services web de manière quotidienne. Les services web permettent aux entreprises de se recentrer sur leur coeur de métier plutôt que de dépenser temps et argent à gérer un parc matériel et logiciel complexe. Dans ce contexte, quelle que soit sa taille, une entreprise est confrontée au problème de l accès à ses données de fonctionnement. Ces dernières sont souvent réparties sur toute la surface du globe, comme par exemple pour une grande entreprise. Université de Lyon, CNRS, INSA-Lyon, LIRIS, UMR-CNRS 5205, Labex IMU, john.samuel@liris.cnrs.fr

2 qui a des filiales internationales, ou une PME qui utilisent des services web sans même connaître leur localisation. Les entreprises sont dépendantes de nombreux services maitrisent communément dans une seule spécialité. Par exemple, il y a divers services web pour faire la gestion des ressources humaines, l organisation de campagnes marketing, la gestion de projets, les réseaux sociaux etc. Ces entreprises perdent du même coup le contrôle direct, complet et sans restriction de leurs propres données métier ainsi que des données relatives à leur utilisation. L accès aux données sauvegardées sur les services web par le navigateur internet n est pas faisable à l échelle. Les fournisseurs de services web offrent les API (interfaces de programmation d application) pour permettre l accès aux données à distance. L API autorise seulement les propriétaires et les sites webs autorisés par des propriétaires d accéder aux données. Les API diffèrent significativement d un service web à l autre, en raison de l usage de différents formats de message, mécanismes d authentification, accords de niveau de service, limitations d accès, types de données, et choix des entrées, sorties et erreurs associées aux services. Les API sont majoritairement décrites en langue naturelle dans des pages web. Ainsi, intégrer plusieurs services au sein d une même application demande un effort de développement certain. En vue de pallier à ce problème, la communauté académique et industrielle a mis au point des langages standards et compréhensibles par les machines pour la description des API, comme notamment WSDL, SAWSDL, hrests [6]). L usage de ces langages doit permettre une automatisation de l intégration des services web au sein d applications plus complexes. Dans les faits, ils ne sont encore que très peu utilisés par l industrie de par l investissement en temps d apprentissage qu ils nécessitent. Les développeurs dans une entreprise ecrivent des logiciels (applications) utilisant des APIs de leur services d utilisation pour accéder et manipuler des données. Souvent les services web évoluent considerant les besoins de leur nombreux clients. Ils changent non seulement l interface de service web accessible par le navigateur internet mais également l API. Ils ajoutent des nouveux options et enlèvent les options les moins utilisées. Cette évolution de services est un grande problème car les développeurs d entreprise ont besoin de reprogrammer les logiciels pour garder l accès aux données. Le pire des cas c est lorsque les services web ferment leur site web et les API, alors les entreprises perdent l integralité de leurs données. Dans une entreprise, chaque département/équipe à sa propre base de données et des fichiers pour gérer des données concernant leurs besoins quotidiens. L entrepôt de données [4, 5] offre un endroit unique pour accéder et comprendre la démarche de l entreprise et de ses départements. Habituellement, et en simplifiant, alimenter un entrepôt de donnée nécessite un certain nombre d opérations en partie manuelles, comme le nettoyage (pour enlever certaines données erronées) ou la restructuration des données (pour qu elles s adaptent à l organisation interne dans l entrepôt). Ceci vient du fait qu on veut intégrer des données de sources très différentes comme des bases de données relationnelles, des fichiers texte, des tableaux de données, des fichiers XML,... Dans notre cas, les données

3 proviennent de services web, c est-à-dire qu on les obtient en faisant appel aux fonctions disponibles dans les API correspondantes. Ces fonctions nécessitent souvent des paramètres en entrées. Par exemple, un service de gestion de projets pourra nous permettre d obtenir les statistiques des projets terminés sur une certaine période. Il faut cependant lui préciser la date de début et la date de fin de la période afin qu il fournisse les données associées. Initié par la société Rootsystem 1, ce travail est centré sur la création d une solution logicielle pour Littlecrowd 2, nommée DaWeS pour Data Warehous fed with Web Services, c est-à-dire entrepôt de données alimenté par des services web. DaWeS est capable de fournir en ligne un entrepôt de données personnalisé pour les petites et moyennes entreprises qui utilisent des services web et qui souhaitent avoir un meilleur archivage et contrôle de leurs données métier. Son intérêt est double : d abord proposer un archivage pérenne des données passées et présentes de l entreprise, et ensuite permettre la définition et le calcul faciles d indicateurs de performance métier en cachant à l utilisateur la complexité inhérente à ces tâches effectuées à partir des données hétérogènes de nombreux services web. Cette solution respecte les deux contraintes suivantes : 1. elle permet l intégration de services web réels, c est-à-dire dont les API sont décrites sur des pages web en langage naturel et non par des langages complexes compréhensibles par les machines (mais très peu utilisés) 2. et elle doit pouvoir être administrée par un petit nombre de personnes. Il doit en effet être facile d ajouter, modifier ou supprimer une API, rendant ainsi possible la gestion d une large offre d API. La nécessité de la première contrainte vient du contexte que l on a décrit plus haut, renforcée par une étude [9, 11] que nous avons effectuée sur une douzaine de services web issus de trois domaines (marketing en ligne, gestion de projets et support aux utilisateurs). En termes techniques, cette étude nous a permis de faire le profil type d un service web actuel : décrit en langage naturel dans une page HTML, respectant une plus ou moins grande partie de l architecture REST, utilisant un mécanisme d authentification HTTP simple avec GET, utilisant XML ou JSON comme formats de message, les types de données chaîne de caractères, date et énumération, et l invocation de ressources dynamiques et de séquence d opérations. Ces caractéristiques sont focalisées sur la simplicité. Cette situation est d ailleurs confirmée par ProgrammableWeb 3, un annuaire en ligne de plus de dix mille API dans lequel une grande majorité sont des services REST qui partagent le profil précédent. La nécessité de la seconde contrainte vient de la société Rootsystem qui ne compte que deux salariés à temps complet. Permettre à une équipe d administrateurs réduite de gérer une offre de services réels étendue est tout l enjeu scientifique et industriel de cette thèse http ://

4 Rêquêts API Services Web Réponse API Extraction et Transformation de Réponse Traitement des Requêtes Indicateurs de performance Requête d'archives Requête d'indicateurs de performance Données Historique Schéma d'archives Données d'archives Base de Données pour archives Schéma d'i.p Données d'i.p. Base de Donnés Pour I.P Étage d'archives Étage d'indicateurs de performance Figure 1. DaWeS : Architecture 2 DaWeS : Architecture, Expériences et Résultats Le prototype (Fig. 1) que nous avons développé DaWeS [8, 9, 11] et démontré [12] est basé sur trois modules principaux : un adaptateur générique pour relier le médiateur aux API des services web et permettre l extraction et la transformation de réponses API, un module de réécriture de requêtes contenant les liens entre le médiateur et les sources et permettant de définir les données à récupérer (cf. l étage des archives), et un module de calcul des indicateurs de performance (cf. l étage d indicateurs de performance). Relier des sources de données en se basant sur leur structure, avant même de manipuler les données, est l approche dite «virtuelle» du problème de l intégration de données[3]. De nombreux travaux ont été menés relativement à ce problème, en particulier centrés sur la notion de médiateur. La principale question est ici de concevoir une interface de requête (le médiateur) permettant d interroger facilement (en une seule requête) un ensemble de sources hétérogènes et autonomes. Dans notre cas, les ressources sont les services web, avec la particularité que ceux-ci imposent des schémas de requêtage bien précis (paramètres en entrées) appelés «access patterns» [7]. Une deuxième particularité de notre problème est que notre médiateur doit pouvoir être souple et nous renvoyer toutes les informations possibles, même en l absence de certains paramètres d entrée. On dit qu il doit gérer des «informations incomplètes» [2]. Enfin la troisième exigence est de concevoir un médiateur pouvant réagir le plus automatiquement possible aux évolutions des sources afin, par exemple, qu une même requête puisse être réexécutée telle quelle même après un changement de structuration dans les données d une source.

5 Pour répondre à ce problème, sans utiliser les standards les plus avancés en matière de description d API de services web, nous proposons une approche semi-automatique caractérisée par la volonté de réduire autant que possible les étapes de développement traditionnel dans l administration de DaWeS. Pour ce faire nous proposons une approche par médiation pour la partie ETL (extraction, transformation et chargement des données) de DaWeS (c est-à-dire le lien entre DaWeS et les services web). L approche médiation est bien connue dans le domaine de l intégration d informations depuis une quinzaine d années. Au sein de DaWeS, elle permet de clairement identifier les tâches automatisables de celles devant être faites manuellement. De plus elle permet l usage de langages déclaratifs uniquement pour les étapes manuelles (SQL, datalog, XML, XSLT). Ainsi, la gestion de DaWeS, qui est a priori un travail de développement pour intégrer des API à la plateforme, devient une tâche d administration et de paramétrage de composants. Le temps nécessaire à sa réalisation en est grandement amoindri et c est ce qui permet à une petite équipe d administrateurs de pouvoir gérer des centaines d API de services web. Ainsi, dans DaWeS, est implementé un module d ETL complet basé sur une approche médiation et sur l usage d un wrappeur HTTP d API de services web générique. Le résultat est un entrepôt d entrepôts de données dont une part du schéma de stockage des données est dynamiquement créé en fonction des API intégrées. D un point de vue théorique, DaWeS a fait émerger deux problèmes importants. Le premier est celui du traitement des valeurs incomplètes. L approche médiation [3] respecte un traitement rigoureux des données issues des services web, impliquant, en résumé, que certaines données, pourtant présentes dans les services, ne peuvent pas être utilisées parce qu elles ne sont pas confirmées par d autres services vus comme incomplets. Justifiée sur le plan théorique, cette contrainte n est pas satisfaisante dans le contexte industriel où l on veut pouvoir récupérer toutes les données possibles. Pour pallier à ce problème nous proposons dans DaWeS une heuristique [8] de relaxation de l algorithme de réécriture de requêtes [1] qui est au coeur de la médiation. Le deuxième problème rencontré est celui du nombre d accès aux API. En simplifiant, une requête posée à DaWeS, par exemple pour l obtention de données pour la construction d un indicateur de performance, est réécrite en plusieurs requêtes chacune d elle étant traduite par un certain nombre d appels aux services web via leurs API. Or appeler un service web peut-être très coûteux. Cela dépend de la politique de tarification du fournisseur de ce service qui dépend elle-même de nombreux paramètres (qualité du service demandé, de la connexion réseau, du nombre d appels déjà effectués,...). Il devient donc nécessaire d optimiser la réécriture de la requête initiale afin de minimiser le nombre de ces appels tout en conservant les mêmes résultats. Face à cette problématique, nous ne proposons pas, dans ce travail, d optimisation en tant que telle. Par contre nous proposons une méthodologie pour l obtention d une borne supérieure [10] sur le nombre d appels requis après réécriture. Cette borne se veut un outil d évaluation des futures méthodes d optimisation de réécriture.

6 Nous avons validé DaWeS par les tests suivants. D abord, des expérimentations qualitatives ont été menées sur des services web réels dans les trois domaines précédemment cités. Puis, une première série de tests aléatoires quantitatifs a été effectuée pour tester le passage à l échelle. 3 Conclusion et perspectives L offre de services web disponibles étant en constante progression, l adéquation avec les demandes des PME étant croissante, les besoins d avancées dans le domaine de l intégration de données sont de plus en plus importants. Cette thèse [8] traite de l établissement d une plateforme logicielle nommée DaWeS permettant le déploiement et la gestion en ligne d entrepôts de données alimentés par des données provenant de services web et personnalisés à destination des petites et moyennes entreprises nécessitant moins d effort de programmation. Ce travail s articule autour du développement et de l expérimentation de DaWeS. L idée principale implémentée dans DaWeS est l utilisation d une approche virtuelle d intégration de données (la médiation) en tant que processus ETL (extraction, transformation et chargement des données) pour les entrepôts de données gérés par DaWeS. A cette fin, un algorithme classique de réécriture de requêtes (l algorithme inverse-rules) a été adapté et testé. Une étude théorique sur la sémantique des requêtes conjonctives et datalog [10] exprimées avec des relations munies de limitations d accès (correspondant aux services web) a été menée. Cette dernière permet l obtention de bornes supérieures sur les nombres d appels aux services web requis dans l évaluation de telles requêtes. Des expérimentations ont été menées sur des services web réels dans trois domaines : le marketing en ligne, la gestion de projets et les services d aide aux utilisateurs. De nombreuses questions ouvertes se posent alors à la recherche et à l industrie. Premièrement, comment peut on réduire ou optimiser le nombre d appel à l API? Puis, Est ce que l ajout d un mécanisme avancé de traitement des erreurs peut il aider à réagir automatiquement aux échecs de l API? Finalement, qu elle interface d intégration visuelle et quels outils de visualisations pertinents sont nécessaires à l utilisateur afin d améliorer et d accélérer l analyse du contenu de son entrepôt de données? Remerciements Je souhaite remercier la Région Auvergne et le FEDER pour le financement de ce projet de recherche. Je voudrais également remercier Farouk Toumani et Christophe Rey de LIMOS, Université Blaise Pascal pour leur direction ainsi que Rootsystem pour avoir initié ce travail. Enfin merci à A. Duranthon pour la relecture. Références [1] Duschka, O.M., Genesereth, M.R., Levy, A.Y. : Recursive query plans for data integration. J. Log. Program. 43(1), (2000)

7 [2] Grahne, G., Kiricenko, V. : Towards an algebraic theory of information integration. Inf. Comput. 194(2), (2004) [3] Halevy, A.Y. : Answering queries using views : A survey. VLDB J. 10(4), (2001) [4] Inmon, W.H. : Building the Data Warehouse. John Wiley & Sons, Inc., New York, NY, USA (1992) [5] Kimball, R. : The Data Warehouse Toolkit : Practical Techniques for Building Dimensional Data Warehouses. John Wiley (1996) [6] Kopecký, J., Gomadam, K., Vitvar, T. : hrests : An html microformat for describing restful web services. In : Proceedings of the 2008 IEEE/WIC/ACM International Conference on Web Intelligence and Intelligent Agent Technology - Volume 01. pp WI-IAT 08, IEEE Computer Society, Washington, DC, USA (2008), [7] Rajaraman, A., Sagiv, Y., Ullman, J.D. : Answering queries using templates with binding patterns (extended abstract). In : Proceedings of the fourteenth ACM SIGACT-SIGMOD-SIGART symposium on Principles of database systems. pp PODS 95 (1995) [8] Samuel, J. : Feeding a data warehouse with data coming from web services. A mediation approach for the DaWeS prototype. Theses, Université Blaise Pascal - Clermont-Ferrand II (Oct 2014), tel [9] Samuel, J. : Towards a data warehouse fed with web services. In : The Semantic Web : Trends and Challenges - 11th International Conference, ESWC PhD Symposium Lecture Notes in Computer Science, vol. 8465, pp Springer (2014), [10] Samuel, J., Momège, B. : An upper bound on the number of accesses for Datalog α Last queries. In : Base de Données Avancés (BDA 2014) (2014), session Jeune Chercheur [11] Samuel, J., Rey, C. : Dawes : Datawarehouse fed with web services. In : Actes du XXXIIème Congrès INFORSID, Lyon, France, Mai pp (2014), [12] Samuel, J., Rey, C., Martin, F., Peyron, L. : Mediation-based web services fed data warehouse. In : 10e journées francophones sur les Entrepôts de Données et l Analyse en ligne (EDA 2014), Vichy. RNTI, vol. B-10, pp Hermann, Paris (Juin 2014), démo