[Techdays 2013] Bases et données : les propositions de Microsoft

Le cloud, le PaaS (Plateforme en tant que service), les BigData, le map/reduce… On n’a jamais eu autant de choix concernant le stockage de nos données. Mais on peut comprendre certains DBAs et décideurs informatique qui sont nostalgiques de l’époque où chaque investissement en stockage et traitement, correspondant certes à un montant à 6 chiffres mais signifiant aussi une certaine pérennité de leurs installations. Avoir le choix est-il alors une nouvelle source de stress ?

Si nous pouvons comprendre les choix disponibles, cela réduit le risque et le stress – parce qu’on a toujours un plan B, moins cher que jamais ! Ayant assisté à 4 sessions des Techdays liées au sujet (BI207,  BI208, DAT204 et DAT303), je vous propose de synthétiser cela et de vous livrer les clefs des différents choix concernant vos données.

Continuant une « tradition » que j’ai commencé dans un article du même genre, je vous propose :

Le tableau qui vous fait gagner du Temps !

Option	Recommandé pour	On-Premises	PaaS – Cloud
SQL Server DB Engine	Données structurées,  cohérence indispensable	Oui	Oui [1]
SSAS (Analysis)	BI, requêtes performantes et presque ad-hoc par des non-informaticiens	Oui	Non
SSIS (Integration)	Chargement et  transformation de données	Oui	Non [2]
MDM/DQS	Nettoyage et qualité des données	Oui	Non
SSRS (Reporting)	Reporting, requêtes prédéfinies, optimal pour impression	Oui	Oui
Excel	Reporting, BI, souvent frontal pour un autre service	Oui	SaaS, limité
PerformancePoint	Οptimal pour la visualisation des tableaux de bord interactifs. Il nécessite SharePoint	Oui	Non
Parallel Data Warehouse	>1TB, données structurées et non, solution « clé en main »	Oui	Non
Azure Storage (NoSql)	Données pas (ou peu) structurées,   performance plus importante que la cohérence, latence faible	Non [3]	Oui
HDInsight	>100TB, données non structurées, BI, requêtes ad-hoc, latence haute	Oui (voir PDW)	Oui

Même avec un tableau riche en informations, le choix n’est pas si facile. Chaque entreprise a des besoins multiples, donc il faut réfléchir à la combinaison des produits qui sera la plus appropriée pour ses besoins. J’essayerai de vous accompagner dans ces choix, en présentant les options possibles.

Question 1 : qu’est-ce que vous avez déjà ?

Si vous avez déjà une solution qui couvre 90% de vos besoins, il y a de fortes chances que votre chemin soit simple. Par exemple, l’installation standard de SQL Server contient déjà le moteur de base de données, Analysis Services, Integration Services et Reporting Services. Avec ce package attractif, la solution est souvent une question d’ajout de quelques disques dans un SAN, la montée en licence de SQL Server (passer par exemple de Standard vers BI) et un peu de configuration.

Avec un coût plus élevé (mais une migration relativement simple), vous pouvez acheter une licence plus récente de SQL Server, si vous y voyez quelque chose de très utile. La version 2012 de SQL Server, par exemple, avec les indexes COLUMNSTORE et la redondance active-active peut être rentable, en vous permettant d’utiliser votre équipement d’une façon plus efficace.

Mais souvent c’est ce chemin qui crée un faux sens de maîtrise des coûts. Les coûts d’achat et de maintenance (DBAs, support, hébergement, bande passante…) de vos propres serveurs sont assez élevés, et il est important de faire l’exercice de voir si un passage vers le cloud ne serait pas plus rentable – au moins une fois tous les 3 ans, quand vous renouvelez certaines de vos machines.

Question 2 : Azure ou on premises ?

C’est une grande question à laquelle vous ne pouvez pas répondre sans la découper en questions plus basiques :

Avez-vous des obligations légales ?

Il y a certaines classes de données qui ne doivent pas sortir de votre pays. Dans ce cas vous connaissez déjà la réponse à la question « cloud ou non ». C’est non ! Mais dans la plupart des cas, il vous suffit de garder vos données au sein de l’Union Européenne, ce qui rend Azure parfaitement pertinent (et en plus, il bénéficie des certifications de sécurité de très haut niveau, vous facilitant la vie concernant votre conformité légale).

Où sont les sources de vos données ?

Aujourd’hui, dans la plupart des cas vos données sont téléchargées depuis un site distant. Vous pouvez obtenir des améliorations importantes en terme de de performance et de coût si votre stockage et vos traitements sont proches de vos sources. Si vous avez un site sur Azure, vous ne payez pas la bande passante pour stocker les données sur Azure aussi.

Quelle est la périodicité de vos besoins ?

Disons que vous avez un travail intense en terme de calcul, qui est soit ponctuel, soit qui se fasse une fois par semaine ou par mois. Avez-vous vraiment besoin d’acheter et de maintenir des machines à temps plein, ou bien est-il plus rentable de « louer » du temps de calcul d’Azure Reporting ou Azure HDInsight, des services payés à l’heure ?

Avez-vous fait des investissements importants sur des technologies incompatibles avec le Cloud ?

Nous pouvons voir dans le tableau précédent une série de technologies qui ne sont pas disponibles dans le Cloud, notamment des outils de nettoyage et de chargement de données (Master Data Management, Data Quality Services, SQL Server Integration Services) et de requêtage analytique (SQL Server Analysis Services, PerformancePoint). Il y a beaucoup de sociétés qui ont investi sur ces technologies – et d’autres qui y investiront dans l’avenir. Il y a sûrement des solutions sur le Cloud mais la migration risque alors d’être un projet nécessitant de longs développements.

Il est alors tout à fait raisonnable de ne pas jeter à la poubelle tout cet investissement sur des outils bien utiles (j’ai des bons souvenirs de SSIS), juste pour être à la mode. Par contre, si, suite aux questions précédentes, vous avez décidé qu’Azure est une bonne option, il ne faut pas s’interdire de faire le saut vers le Cloud à cause d’un outil qui n’existe pas sur Azure : vous pouvez toujours migrer vos données vers le Cloud et déplacer par exemple votre SSIS vers une machine virtuelle sur Azure. Là, votre outil pourra profiter de la proximité de vos données.

Sinon, peut-être n’avez vous pas investi dans du matériel, ni les fonds pour le faire. Dans ce cas, Azure, avec son modèle « pay as you go » est vraiment ce que vous cherchez – vous permettant de commencer avec un budget aussi bas que 100€/mois pour l’infrastructure.

Qui sont vos ingénieurs ?

Si vous avez des administrateurs qui comprennent l’infrastructure, vous avez l’option de garder votre stockage en dehors du Cloud ou de les solliciter pour choisir la meilleure solution Cloud. Si vous n’en avez pas, vous pouvez commencer avec le cloud, où l’administration est simple, mais n’oubliez pas de recourir au conseil et à la formation de façon régulière. La maintenance d’Azure nécessite beaucoup moins de ressources qu’une solution interne à l’entreprise, mais il y a beaucoup de faux pas à éviter chaque fois que vous prenez une décision d’architecture – autant qu’en local, mais il y a moins d’experts sur le sujet. Il faut alors avoir des références dans lesquelles vous pouvez avoir confiance. Heureusement, au-delà d’un seuil d’abonnement Azure (je pense vers les 3000€/mois), Microsoft vous offre un accompagnement personnalisé.

L’autre question est : avez-vous plutôt des gens technico-fonctionnels et orientés BI, ou bien plutôt des développeurs ? Les premiers se sentent clairement plus à l’aise avec des outils graphiques qui leur permettent d’avoir une vision macroscopique de l’architecture. Les derniers préfèrent le code. C’est donc tout à fait naturel si les premiers sont plus à l’aise avec la suite SQL Server (SSAS/SSIS/MDM/QDS) et les langages très puissants mais spécifiques à un besoin (MDX/DAX) quand les développeurs préfèrent utiliser un langage comme C# pour tout faire. Ils sont donc plus à l’aise avec les solutions map-reduce de Hadoop.

Bien sûr, vous aurez beaucoup plus de flexibilité si vous avez des ressources humaines variées accompagnées par des plans d’échange d’informations et de partage de compétences.

Question 3 : qui sont vos utilisateurs ?

Cette question est intéressante pour toutes les solutions de Business Intelligence et de Reporting. Quel est le niveau d’expertise que vos utilisateurs ont ou pourraient atteindre avec une formation courte ?

1. Nul  : Ils peuvent juste remplir un ou deux champs et consommer des rapports tout prêts. Ils ne comprennent pas vraiment bien les relations entre les données. Reporting Services  ou l’équivalent Azure SQL Reporting sont appropriés pour eux, permettant la distribution des rapports par web ou email au format et type de fichier souhaité. Si vous avez SharePoint, PerformancePoint est aussi la meilleure façon de construire un tableau de bord relativement interactif avec des indicateurs de performance.

2. Pro  : Ils comprennent souvent les données mieux que les développeurs et peuvent apprendre à utiliser des outils relativement avancés (mais ergonomiques). Excel Pivot Tables et Power Pivot sont adaptés à ce type d’utilisateur. Pivot Tables est intégré à Excel, mais pour avoir de bonnes performances, il nécessite la liaison à un cube SSAS  qui doit être construit via la consultation des utilisateurs – c’est un projet qui peux alors prendre plusieurs mois. Une fois construit, le cube permet le filtrage et la navigation rapide dans les données et mesures collectées, permettant à l’utilisateur de faire ses propres rapports.
   Power Pivot est une étape plus « libre-service » pour l’utilisateur, lui permettant de créer lui-même sa propre base de données en mémoire. En utilisant le moteur xVelocity (ex-Vertipaq) il permet la compression et l’indexation de données. Sur un poste avec 6GB de mémoire vous pouvez naviguer avec fluidité dans des données provenant de multiples sources pouvant aller jusqu’à 30GB avant compression. Une fois que l’utilisateur aura commencé à stabiliser sa structure, il voudra peut-être partager son fichier. Au lieu de le copier, il peut le donner à un informaticien qui pourra créer, à partir de ce fichier, une nouvelle base SSAS Tabulaire qui sera mise à jour automatiquement et sur laquelle l’administrateur pourra contrôler les accès (par table etc…).
   L’utilisation de SharePoint facilite la détection des fichiers Excel candidats pour une mise en serveur.
   Pour ceux qui ne bénéficient pas d’Excel, Reporting Services PowerView peut être aussi branché sur un SSAS Tabulaire pour être utilisé pour créer des rapports interactifs.

Attention : à partir de là, il n’y a pas d’équivalent Azure pour ces solutions.

3. Presque informaticien  ! Les utilisateurs très avancés peuvent soit augmenter la puissance de leurs Power Pivot avec la création de mesures en langage DAX, soit utiliser le plugin Hive (pour Excel), avec lequel ils peuvent écrire des requêtes pseudo-SQL  qui se traduisent en jobs Map-Reduce pour HDInsight (Hadoop). Power Pivot donnera des résultats plus rapidement pour les bases pas trop larges, mais Hadoop peut gérer des volumétries plus grosses (>1PB).

On voit alors une multitude de choix qui permettent aux utilisateurs de garder leurs outils préférés.

Question 4 : pouvez-vous prévoir le schéma de vos données ?

Cette question ne s’applique pas, bien sûr, sur toutes vos données ! Si vous n’avez pas de tables avec des colonnes bien définies, vos architectes sont feignants ! Mais c’est normal d’avoir certaines entités importantes pour vos applications qui aient une variance en propriétés et relations trop élevé et imprévisible pour pouvoir les modéliser. Il y a 3 cas différents :

1. Les images, ou autre contenu binaire qui est pratiquement opaque pour une base de données. Ces données peuvent être sauvegardées en FILESTREAM sur un système local, ou sur Azure Blob Storage (qui peut être aussi branché au CDN d’Azure, pour réduire la latence de téléchargement de ces fichiers).
2. Les documents contenant du texte libre (ou autre donnée pas structurée mais analysable). Si vous les stockez sur un SQL Server classique, vous pouvez activer la recherche full-texte intégrée, qui est très optimisée (et permet aussi des scénarios très avancés en coordination avec le moteur FAST de SharePoint). Si vous les stockez sur Office 365, vous avez des capacités de recherche un peu plus réduites par rapport à un SharePoint local. Si vous les stockez dans Azure Blob Storage vous êtes obligés d’utiliser une librairie un peu moins flexible, comme Lucene, ou de coder votre propre traitement en HDInsight Map-Reduce. Le dernier est la seule solution pour les fichiers non-textuels (voir données de capteurs etc).
3. Les données semi-structurés, qu’on aurait pu imaginer en tant que classes ou objets Json, mais ont une forme qui change trop souvent (voir chaque mois), avec une multitude de propriétés optionnelles. Ces données peuvent être sauvegardées et requêtées dans Azure Table Storage. Parallel Data Warehouse, avec son moteur Polybase (bases relationnelles et non-relationnelles) propose aussi des solutions optimisées pour Hadoop, mais en restant chez vous. Si vous voulez quelque chose de plus petit et moins cher que Parallel Data Warehouse (qui nécessite la moitié d’un rack et son prix peut monter jusqu’à quelques millions d’euros), vous pouvez toujours choisir une base graph ou NoSQL open source.

Presque toutes ces solutions permettent relativement facilement la synchronisation avec un endroit géographiquement éloigné. Pour le faire avec SQL Server il faut une licence Enterprise. Pour le faire avec une base NoSql autre qu’Azure Storage, il faut choisir la bonne base (Cassandra est bien plus efficace pour ces scenarios que MongoDB).

Question 5 : quel est le goulot d’étranglement ?

Vous trouvez peut-être étonnant le fait que j’ai gardé les performances pour la fin, mais, avec les évolutions des technologies, les performances demandées sont rarement le facteur principal pour définir votre architecture. Une fois que vous avez décidé des outils de reporting et de l’utilisation ou pas du Cloud, il y a des solutions pour avoir les performances voulues pour chaque scénario. C’est souvent pratique d’avoir une seule base avec un seul exemple de vos données (plus les backups), mais souvent il y a des besoins spécifiques qui nécessitent une transformation et certaines conversions, et l’utilisation de moteurs différents pour l’écriture/lecture en temps réel et pour le reporting.

Grosses volumétries

Si vous dépassez les 100GB de base de données, vous devez commencer à réfléchir aux solutions pour sauvegarder cette volumétrie en gardant des performances acceptables.

Si vous devez mettre en place une solution pour votre reporting au sein de votre entreprise, les  solutions sont les suivantes :

1. SQL Server Analysis Services en mode multidimensionnel (cube). Ça consiste des structures dénormalisées en interne, mises à jour de façon périodique, et ayant un schéma bien défini. La compréhension des cubes nécessite un background théorique, et leur développement un travail important de modélisation. Le plus gros cube SSAS au monde est celui de Yahoo, avec 24TB de données de reporting (extraites d’une base d’à peu près 1PB), répondant en 2 à 6 secondes à une énorme série de requêtes différentes – et pas complètement prévues en avance.
   Vu que SSAS est compris  dans SQL Server, c’est une solution qui a du sens même si vous êtes encore dans des volumétries moyennes (~100GB).
2. Parallel Data Warehouse est  une solution plus récente destinée à des volumétries qui dépassent le TB et qui est fournie avec le matériel. La version qui sort en Mars 2013 inclut des indexes CLUSTERED COLUMNSTORE sur lesquels on peut faire des mises à jour. Elle permet une très bonne compression de données et des faibles temps de réponse pour les requêtes de reporting, même pour de très grosses volumétries et en nécessitant bien moins de modélisation et préparation qu’un cube SSAS. Elle gère aussi les données non-structurés, comme Hadoop, en permettant leur analyse.

Côté Cloud, vous serez soit obligés de monter un cube sur une machine virtuelle, soit de faire votre reporting en Hadoop/Hive. Je vous laisse revoir les questions précédentes pour faire votre choix.

Après un certain seuil, même vos flux transactionnels et applicatifs de base risquent d’être arrivés à une volumétrie trop grosse pour être gérée dans une base monolithique. Il faut alors séparer les tables en bases différentes, qui peuvent être utilisées en parallèle (ie faire du sharding). Ce moment vient assez tôt en mode Cloud (dès que vous arrivez à une table de 10GB), mais en local vous pouvez bien attendre d’arriver à une table de 200GB pour en ressentir le besoin. Pour le Cloud, Azure SQL les fédérations sont assez simple à mettre en place (mais nécessitent de revoir un peu votre façon de requêter pour en profiter au maximum). Parallel Data Warehouse offre aussi une solution presque transparente – compatible avec les outils comme SSIS et la géo-redondance. C’est la solution choisie pour le back-end d’Xbox Music, pour une volumétrie qui va vite arriver à 150TB.

Performances de ouf !

C’est bien connu, les systèmes transactionnels classiques arrivent à une limite de 3000 transactions par seconde et par base. En général ceci peut bien tenir quelques milliers d’utilisateurs très actifs, mais qu’est-ce qu’il se passe si vous en avez plus ?

C’est ce besoin qui a obligé de gros services comme Facebook et Twitter à se diriger vers les bases non-ACID, c’est à dire qui ne respectent pas de façon stricte la cohérence des données et les transactions. En enlevant une grosse partie des vérifications, ils ont pu paralléliser leurs flux sans contrainte. Vous tirez les mêmes bénéfices si vous utilisez Azure Storage. Par exemple vous pouvez sauvegarder 20000 entités par seconde sur Azure Table Storage (et beaucoup plus si vous répartissez votre trafic entre plusieurs comptes de stockage).

Mais êtes-vous obligés de sacrifier tous les contrôles très pratiques de cohérence de données et de relations pour avoir les performances voulues ? Peut-être que non. Les évolutions de SQL Server peuvent facilement augmenter de 10 ou 20 fois les capacités des systèmes transactionnels. Parallel Data Warehouse sait déjà gérer des flux de 2 TB/heure. Qui plus est, la prochaine version de SQL Server vous donnera aussi la possibilité d’avoir des tables chargées et indexées complètement en mémoire, avec le moteur xVelocity, permettant 60000 transactions / seconde.

Je voudrais rester un peu plus sur ce point, parce que c’est un changement important sur notre façon de comprendre les bases de données. La notion d’un moteur « in-memory » existe depuis longtemps, mais l’intégration à un moteur de base de données classique est quelque chose de récent. La « marque » xVelocity est basée sur le principe d’avoir des performances très élevées en ayant chargés les goulots d’étranglement complètement en mémoire. Elle est derrière Power Pivot et SQL Server Analysis Services en mode tabulaire, permettant d’avoir des temps de réponse phénoménaux pour des volumétries moyennes (au-dessous du TB), sans avoir recours à une indexation ou modélisation complexe.

Le même principe s’appliquera à SQL Server : vous serez capable de charger en mémoire les tables qui vous posent problème. En effet, la gestion de la concurrence est complètement différente et permet à plusieurs transactions de modifier la même cellule de données (avec un versioning par transaction). La gestion des indexes est aussi très différente et simplifiée (imaginez des hashs sur les colonnes intéressantes, mais pas sur des combinaisons de colonnes). En faisant appel au disque beaucoup moins fréquemment et en éliminant les verrous mémoire, le CPU devient maintenant le goulot d’étranglement. Pour alléger le CPU, cette version de SQL Server compile les procédures stockées en C. Et tout cela se fait sans abandonner la base, la syntaxe et la cohérence habituelle.

Pour finir avec les performances, je dois aussi faire référence à certains secteurs qui ne sont pas limités que par la performance des écritures, mais demandent aussi une gestion quasi-instantanée des notifications sur les flux de données. Par exemple, une assurance a besoin d’analyser les flux de données et lancer des alertes sur des évènements qui risquent de se passer. Les algorithmes d’analyse de ces évènements sont compliqués et ils s’appliquent sur une série de x données très récentes qui ne cesse de changer. Heureusement, SQL Server ET Hadoop peuvent se brancher sur StreamInsight, une extension de .NET Framework qui permet de déclarer de façon claire et courte les algorithmes à appliquer sur ces données. Un exemple concret se trouve ici, mais vous pouvez me laisser un message si vous avez besoin d’une explication du principe très intéressant de « LINQ to Events».

Épilogue avec deux exemples

Les choix sont très nombreux, même sans sortir de l’univers Microsoft. Pour vous aider à mieux schématiser le rôle de chacun et clairement inspiré par une proposition similaire aux TechDays, je vous présente deux architectures possibles, adaptées aux besoins d’une petite entreprise et disponibles à un faible coût. Elles peuvent servir comme des modèles d’architecture facile à gérer et peuvent avec peu de modifications s’étendre jusqu’à un TB de stockage :

Local

Vous pouvez commencer SSAS en mode tabulaire, avant modéliser un cube pour les besoins plus récurrents.

Cloud