WHITE PAPER. Des roues de données pour l analyse temps réel

Transcription

1 WHITE PAPER Des roues de données pour l analyse temps réel Mai 2007

2 introduction Visual Sciences a créé une nouvelle génération de moteur d analyse de données temps réel qui fait appel au concept des roues de données. Les roues de données autorisent une vitesse fulgurante pour les requêtes de type analytique. Cette vitesse permet aux architectes et aux utilisateurs d éviter les compromis imposés en matière de conception lors de l utilisation de solutions moins efficaces (bases de données relationnelles et outils OLAP, par exemple). Les roues de données constituent une technologie mûre, utilisée avec succès depuis des années dans des entreprises de haut niveau par les équipes informatiques, les cadres, et les directeurs pour donner du sens aux innombrables informations qui leur parviennent. 2

3 Une analyse des données nécessaire Les décideurs d aujourd hui font face à une explosion de données. Non seulement le nombre d éléments suivis clients, produits, campagnes et transactions prolifère, mais la quantité d information enregistrée pour chaque événement augmente avec l introduction accrue de technologies de capture automatique de données. Les grandes entreprises génèrent des téraoctets voire des péta-octets de données vitales concernant chaque aspect de leurs clients et des opérations qui les concernent. Dans de nombreuses industries, la capacité à assimiler ces données pour optimiser les performances de l entreprise est devenue une arme concurrentielle essentielle. Bases de données Une base de données relationnelle est ce qui se rapproche le plus d un outil universel en ce qui concerne le traitement de «données». Des années de progrès ont doté les systèmes de gestion de bases de données tels qu Oracle, Microsoft SQL Server et MySQL de fonctionnalités couvrant quasi tous les scénarii d analyse imaginables. Les bases de données conviennent particulièrement aux applications de traitement transactionnel en ligne (OLTP) insertion de nouveaux enregistrements, extraction d enregistrements existants et suppression d enregistrements. Bien conçues, elles se chargent de ces opérations en garantissant sécurité absolue, intégrité des transactions, piste d audit et haute disponibilité. Toutefois, étant donné que les bases de données relationnelles sont optimisées pour le traitement des transactions, leurs structures de données et leurs capacités de calcul ne conviennent souvent pas bien à une application analytique lorsqu il s agit de traiter l ensemble des données et non plus un enregistrement individuel. Dans la terminologie des bases de données, on dit que ces requêtes de type analytique nécessitent un «balayage complet des tables», une opération lente qui ne peut pas faire appel aux index et partitions que les bases de données utilisent généralement pour accélérer leurs requêtes OLAP L utilité des applications analytiques a fait émerger l idée du traitement analytique en ligne (OLAP). Les systèmes OLAP fonctionnent au-dessus des bases de données existantes pour fournir des réponses rapides à des questions analytiques, et sont construits selon le principe des «cubes». Les cubes récapitulent les réponses à ces questions fréquentes sous la forme d ensembles numériques comprenant des totaux précalculés (par exemple le nombre d unités vendues) pour chaque combinaison de chaque dimension (telle que le jour, le produit et le magasin). Les cubes sont généralement construits la nuit à partir de la base de données et sont ajoutés à un entrepôt de données, qui n est pas soumis aux exigences du traitement transactionnel en temps réel. Étant donné que les totaux de chaque combinaison ont été précalculés, les cubes fournissent des réponses rapides à n importe quelle requête qui peut être définie par les dimensions du cube. Combien d unités de produits détergents ont été vendues à Paris en Mars? Le cube donne la réponse immédiatement. 3

4 Les cubes souffrent toutefois de quatre limitations pénibles : La vitesse: Bien qu un cube précalculé fournisse des réponses rapides, la création de ce cube est une opération qui prend du temps et qui comprend de multiples étapes. Le système transactionnel doit traiter de nouvelles transactions, ce qui signifie que les données transactionnelles doivent être extraites et chargées régulièrement dans l entrepôt de données, et que les cubes doivent être recalculés régulièrement aussi. Cela implique également que les données des cubes sont dépassées, généralement entre un jour et une semaine. L échelle: Les cubes, qui sont censés fournir une synthèse compacte de données, peuvent eux-mêmes devenir assez volumineux. Leur taille peut même devenir supérieure à celle des données détaillées à partir desquelles ils sont compilés! Par conséquent, le matériel, le logiciel, l espace de stockage et le personnel requis sont substantiels, et peuvent occasionner des coûts se calculant en millions d euros. De plus, à mesure que les ensembles de données grandissent et que la complexité des requêtes croît, le coût de la mise à l échelle d un système de cubes peut augmenter de manière exponentielle (voir encadré). Complexité: Les cubes reposent sur le concept théorique selon lequel, en anticipant les critères utilisés fréquemment dans les requêtes et en effectuant des calculs préalables basés sur ces dimensions, il est possible de répondre rapidement aux requêtes anticipées. Cependant, dans ce schéma, il n est tout simplement pas possible d obtenir de réponse pour les requêtes qui n ont pas été anticipées (les ventes par heure plutôt que par jour) ou pour les requêtes complexes (parmi ceux qui ont acheté des marteaux, combien ont aussi acheté des scies). Les données nécessaires ont été synthétisées, et ne sont donc plus disponibles. Non, vraiment de manière exponentielle Exemple: Base de données simple contenant un million de transactions, chacune définissant l âge, le sexe, la référence produit, avec le code postal et le revenu. Votre objectif: Obtenir des chiffres de revenu décomposés selon chacune de ces quatre dimensions. HYPOTHÈSES: Soit 100 âges possibles, 2 sexes, produits et codes postaux. Pour une analyse sans limitation, un cube doit calculer une valeur pour chacune des combinaisons possibles. Combien cela va-t-il faire? 100 x 2 x 10,000 x 43,000 = 86 milliards de combinaisons (Le même genre de calcul qui fait dire aux constructeurs automobiles qu ils ont configurations possibles.) Comme chaque réponse correspond à quelques octets, cela engendre un cube d un téraoctet et demi. Mais ce n est pas tout à fait juste. Si les systèmes OLAP étaient si mauvais, ils ne fonctionneraient pas réellement, n estce pas? Eh bien, en réalité, un système OLAP laisserait probablement tomber les produits «moins importants» parmi les qui sont gérés. C est un principe bien connu qu on appelle «roll off» dans l industrie. Cela permet de rationaliser les calculs (le cube ne fait que 2 Go maintenant), mais l inconvénient est évident. Autrement, vous pouvez décider de ne pas décomposer les produits par code postal, dans la mesure où ce sont ces deux dimensions qui font exploser les données. Cela nous laisse deux petits cubes (de 15 Mo et de 65 Mo), mais sans possibilité de déterminer quel revenu vient de quel code postal pour un produit particulier. Imaginez les défis qui se dressent à mesure que le nombre de dimensions croît, de 4 à 5, ou 6. En situation réelle, de nombreuses entreprises ont des dizaines voire des centaines de dimensions. Un cube complet, nécessaire pour un accès sans limitation et une analyse sans compromis, devient alors incroyablement volumineux. Comme vous pouvez l imaginer, les entreprises OLAP ont usé de beaucoup de subtilité pour que ces compromis restent invisibles en concevant des interfaces qui restreignent par nature l analyse ou, si nécessaire, en construisant de nouveaux cubes qui seront disponibles le lendemain de façon à pouvoir à nouveau répondre rapidement aux questions. Bien entendu, à mesure que l espace se remplit, d autres éléments doivent disparaître. Même avec cette sophistication, le principe mathématique de base demeure et, en réalité, les options de filtrage et d analyse restent très limitées. 4

5 La granularité : Il existe des limites pratiques au nombre de valeurs d une quelconque dimension, ce qu on appelle la «cardinalité» d un cube, qui correspondent généralement à quelques centaines voire milliers d unités. Si une entreprise gère dix milles articles, ou dix millions de clients, ou dix milliards de transactions, il n est pas possible de capturer dans le cube les détails granuleux de chaque article, client ou transaction. Les cubes engendrent une perte d information. Ils ne sont pas en mesure de suivre les transactions individuelles, les clients individuels ou les groupes de clients qui présentent un comportement précis. Pour une analytique robuste, cet aspect est quasi fatal. Des roues Le concept de «roues» que nous souhaitons introduire comme solution supérieure pour l analyse de données présente un ensemble fondamentalement différent de compromis en termes de performance, avec une analyse quasi sans limitation. Illustrons la roue en prenant l exemple d un tapis bagages à l aéroport, les valises en circulation étant les données individuelles. Pour introduire une question sur les données, vous marchez jusqu au tapis, vous notez la valise devant vous et vous comptez en additionnant les résultats. Lorsque vous revoyez la première valise, vous arrêtez de compter et vous montrez les résultats : 34 valises noires et 14 valises rouges. Si deux personnes doivent introduire une question, elles peuvent toutes deux accéder au tapis et rester durant un tour complet. Elle peuvent aussi commencer à observer le tapis tourner à différents moments. Une roue de données ne cesse jamais de tourner ; une requête peut intervenir à n importe quel moment et attendre la fin d un tour. Dans cette analogie, la base de données correspond à un grand nombre de rayonnages portant des valises classées par ordre alphabétique suivant le nom de famille du client. Ce système permet d insérer ou de trouver une nouvelle valise rapidement, mais examiner toutes les valises prendrait beaucoup de temps il faudrait les retirer des rayonnages l une après l autre. Le système OLAP quant à lui consisterait à avoir une feuille de papier récapitulant certaines statistiques concernant les valises qui se trouvaient sur le tapis bagages le jour précédent (avec une note dans le bas indiquant «pour en savoir plus, voir les rayonnages»). L implémentation du principe des roues par Visual Sciences autorise la mémorisation d une hiérarchie flexible d informations dans chaque «valise». Par exemple, imaginons que chaque valise représente un client. La valise peut contenir la liste de toutes les transactions précédentes concernant le client, avec les postes individuels de chacune de ces transactions. Il est bien sûr possible d associer des centaines d informations avec chaque client, transaction et poste individuel. Par ailleurs, Visual Sciences garantit que les valises sur le tapis apparaîtront dans un ordre complètement aléatoire (la compagnie aérienne se charge très bien de cela!). C est une propriété très intéressante : à tout moment, une requête considérant les données a vu un instantané aléatoire de la base de données totale. Cela permet de calculer des réponses approximatives très rapidement en extrapolant le résultat à l ensemble des données. Ce mode de fonctionnement ne se révélera pas nécessairement efficace avec 50 valises mais, avec des millions ou des milliards de données, il permet d obtenir une estimation très précise du compte final quasi instantanément. 5

6 Faire tourner les roues à toute vitesse L implémentation des roues par Visual Sciences se concentre sur la vitesse. Le concept des roues autorise des vitesses élevées, mais ne les ordonne pas d avance. Visual Sciences a ainsi optimisé considérablement ses roues pour les faire tourner à haute vitesse avec une foule de données. Pour cela, elle a mis au point plusieurs technologies qui constituent de réelles percées: des algorithmes et des structures de données sophistiqués pour optimiser les volumes de requête sur disque dur afin de garantir un débit maximum une technologie de génération de code natif qui compile le code optimisé à la volée afin d accélérer les performances des requêtes des systèmes de fichiers, une gestion de la mémoire et une mise en cache des disques exclusifs des techniques de compression hautes performances une extensibilité par la mise en œuvre de processeurs multiples une extensibilité par agrégation de multiples systèmes Ensemble, ces technologies nous permettent de tirer le maximum de l architecture des roues sur du matériel courant. Au final, il est souvent possible de répondre aux requêtes des centaines voire des milliers de fois plus vite qu avec des systèmes de bases de données poursuivant les mêmes buts. Par exemple, des clients nous ont confié que des questions qui recevaient auparavant une réponse deux jours plus tard sont maintenant réglées en quatre minutes. Nos clients utilisent plus souvent notre plate-forme pour se libérer des chaînes de l OLAP et analyser leurs données sans agrégation préalable et sans les limitations associées en ce qui concerne les requêtes. L élimination du «roll off» permet d analyser et de décortiquer l énorme réserve de vos données. L inclusion de l intégralité de vos dimensions dans votre ensemble de données autorise une analyse enrichie et permet d étudier des relations moins évidentes. Les réponses correspondent toujours aux données les plus récentes. La segmentation s effectue à la volée, jusqu aux éléments les plus fins des données pour une analyse chirurgicale. En bref, la vitesse fait tout : la capacité à répondre aux requêtes à la vitesse de l OLAP avec la flexibilité des bases de données procure un avantage concurrentiel substantiel. Conclusion La nouvelle architecture en «roues» de Visual Sciences déplace fondamentalement l ensemble de compromis lors du choix d une solution d analyse de données. Cette capacité à traiter des volumes élevés de données en temps réel sans agrégation préalable renvoie les solutions existantes à leurs limites : les bases de données relationnelles sont trop lentes, et les cubes OLAP trop limités. 6

7 Corporate Headquarters Telesis Court San Diego, CA [P] [F] EMEA Headquarters Neptunusstraat JA Hoofddorp [P] +31 (0) [F] +31 (0) UK Headquarters Chandos Place Covent Garden London, WC2N 4LP [P] +44 (0) [F] +44 (0)