---

Connect(); 2016

Volume 31, numéro 12

Cet article a fait l'objet d'une traduction automatique.

Applications intelligentes : le développement Big Data facilité

Par Omid Afnan ; 2016

Il est grand bruit autour du concept de données volumineuses dans les discussions d’entreprise aujourd'hui. Aussi variées que les services publics, des cabinets médicaux et caritatives sont illustrant l’utilisation de données à grande échelle pour découvrir les modèles, les organisations déduire des relations et prédire les résultats. Les entreprises et les services en ligne ont été les motifs de développement précoce de données volumineuses et restent ses premiers utilisateurs plus stricte. Scénarios tels que la recommandation du produit, la détection des fraudes, prédiction de défaillance et sentiments sont devenus des noyaux de la révolution de données volumineuses.

Données volumineuses sont souvent définies comme ayant les caractéristiques de la « trois V » — intense, haute vitesse et divers. While massive volume est l’association commune pour les données volumineuses, la nécessité d’effectuer une opération sur les données reçues dans quasiment en temps réel et traiter divers volumineuse et change dans le format et la structure sont également défini pour les données volumineuses. En fait, l’un de ces caractéristiques présentes dans les données peut être suffisant pour créer un scénario de données volumineuses avec les autres souvent suivant juste après. Le désir — et de plus en plus la nécessité, pour tirer parti de données qui a trois V sont la motivation derrière l’intérêt accru des données volumineuses.

Alors que la science des données, des analyses statistiques et apprentissage ont tous apprécié attention renouvelée et la croissance, l’utilisation des données volumineuses a véritablement été déverrouillée par avance sous-jacent de l’informatique distribuée. Cela inclut le développement de piles de logiciels que vous pouvez combiner les clusters à partir de matériel économique. Compilateurs associées et des planificateurs de tâches permettent de répartir la charge de travail informatique sur ces clusters. Cela met les calculs proches où les données sont stockées et rassemble plusieurs serveurs pour obtenir de meilleures performances. Ces plateformes de données volumineuses ont été développés par des sociétés telles que Microsoft, Yahoo et Google à un usage interne, mais sont devenus disponibles pour une utilisation publique via des plateformes telles que Azure Data Lake (ADL), Hadoop et Spark.

Il est donc pas surprenant, puis qui route les données volumineuses signifie un investissement dans la création d’une plate-forme de données basée sur ces nouvelles technologies. Au niveau de système d’entreprise, cela signifie l’introduction d’un lac de « données » en plus de l’entrepôt de données traditionnel. Le lac est basé sur le concept de stockage pour un large éventail de types de données à très grande échelle et dans leur format d’origine. Contrairement au modèle de l’entrepôt de données, les données sont capturées tout d’abord sans aucun nettoyage ou de mise en forme et est utilisé avec un schéma de liaison tardive. Ce type d’architecture requiert l’adoption de nouvelles plates-formes logicielles, ADL, Hadoop ou Spark. Pour les développeurs, les données, cela signifie que de devoir apprendre de nouveaux modèles de programmation et les langues tout affaire d’exécution plus complexe et débogage des situations.

Heureusement, les systèmes de données volumineuses ont déjà bien avancé. Supposons que vous voulez créer un système de recommandation de produits avec les informations collectées à partir du site d’achat en ligne vous faire fonctionner. Votre plan consiste à envoyer des e-mails aux acheteurs pour promouvoir les nouveaux produits en fonction des modèles de fêtes précédentes. Vous pouvez être amené à recommander des produits alors que le client souhaite acheter sur le site en fonction de ce que font les autres clients. Les deux scénarios adapté avec les techniques de données volumineuses. Jusqu'à récemment, vous devez commencer par sélectionner une pile spécifique de données volumineuses, conception et acquisition du matériel de cluster, l’installation et réglage du logiciel, puis vous pouvez commencer à développer le code pour la collecte, d’agrégation et de traitement des données que vous possédez. En fonction de votre investissement, probablement avoir verrouillé dans la pile matérielle et logicielle particulière, que vous avez choisi.

Piles comme Hadoop et Spark sont plus simples à installer et à gérer, l’entrée des données volumineuses dans les services de cloud computing est un vrai bonus encore plus importante. Comme un service cloud, ADL alimente le stockage et les calculs nécessaires pour résoudre les problèmes de données volumineuses. Plus important encore, un de ses principes clés est que les données volumineuses développement doit être facile.

Obtient les données volumineuses plus facile

ADL est un environnement en nuage qui offre un service de requête de données volumineuses. Cela signifie que vous n’êtes pas obligé de configurer et gérer n’importe quel matériel. Lorsque vous êtes prêt à faire du développement de données volumineuses, vous créez simplement les comptes ADL sur Azure et le service s’occupe de l’allocation de stockage, des calculs et des ressources réseau. En fait, ADL va plus loin et élimine la vue matériel presque entièrement. Stockage ADL (ADLS) fonctionne comme un système de stockage flexible, étirement pour prendre en charge les fichiers de taille arbitraire et nombre. Pour exécuter des requêtes et la transformation de ces données de la couche Analytique ADL (ADLA) alloue dynamiquement en fonction des besoins pour les calculs donnés de serveurs. Il est inutile de créer ou de gérer n’importe quelle infrastructure — simplement recevoir des données dans ADLS et exécuter des requêtes avec ADLA. Du point de vue du développeur, ADL crée quelque chose qui ressemble et se comporte bien comme un serveur avec la puissance de calcul et de stockage infinie. C’est une simplification puissante pour la configuration de l’environnement et de présentation du modèle d’exécution.

La simplification suivante provient de la langue U-SQL. U-SQL est une combinaison unique de SQL et c#. Une infrastructure déclarative de SQL est utilisée pour générer une requête ou un script. Cette partie masque la complexité qui produit de l’environnement réel distribuée d’exécution parallèle en coulisses. Vous, le développeur, n’avez à dire comment générer un résultat. Vous spécifiez le résultat souhaité et les chiffres système le plan de requête à faire. Cela est identique à ce qui se produit avec SQL dans un SGBDR mais différent de celui des autres piles de données volumineuses où vous devrez définir le mappage et réduire les phases ou gérer la création de différents types de nœuds de travail. Le système du compilateur, runtime et optimiseur dans ADL crée toutes les étapes pour générer les données souhaitées, ainsi que de la parallélisation possible de l’exécution de ces étapes sur les données.

Notez qu’une requête peut être en fait un ensemble de transformations de données et les agrégations très complexe. Le travail de développement de programmes de données volumineuses avec SQL-U est en fait, les scripts potentiellement complexe que les données de forme nouveau, sa préparation pour l’interaction utilisateur dans les outils décisionnels ou un traitement ultérieur par les autres systèmes tels que les plates-formes d’apprentissage. Alors que de nombreuses transformations peuvent être effectuées avec les constructions d’un langage SQL, la variété de formats de données intégrées et transformations possibles, la possibilité d’ajouter du code personnalisé. C’est c# en U-SQL, ce qui vous permet de créer une logique personnalisée, mais peut toujours être répartie sur l’environnement de traitement parallèle sous-jacent. Extensibilité SQL-U est examinée en détail dans l’article en ligne de Michael Rys, « Applications d’extensibilité dans U-SQL Big Data, » (msdn.com/magazine/mt790200), qui fait partie de cette édition spéciale.

La prise en charge dans le développement d’outils, tels que Visual Studio fournit un autre simplification critique : la possibilité d’utiliser des outils familiers et les modèles d’interaction pour créer votre base de code de données volumineuses. Dans le reste de cet article, j’aborderai les fonctionnalités de programmation U-SQL dans Visual Studio et comment, conjointement avec les fonctionnalités mentionnées précédemment, ils fournissent un changement majeur dans la simplicité d’utilisation de données volumineuses globale.

Développement d’U-SQL

Pour faciliter le développement de données volumineuses, vous démarrez avec la possibilité de construire facilement des programmes. Le fait que U-SQL combine deux langues très familiers comme point de départ rend très facile à apprendre et supprime l’une des barrières pour l’adoption des données volumineuses. Dans le cas des outils de développement tels que Visual Studio, il rend également facile de réutiliser des expériences familières telles que la prise en charge intégrée pour le développement c# et débogage. Les outils de LAC de données Azure pour le plug-in Visual Studio (bit.ly/2dymk1N) fournit le comportement attendu dans IntelliSense, la gestion des solutions, intégration du contrôle de source et le code exemple.

ADL étant un service cloud, les outils Visual Studio dessiner sur l’intégration à Azure via le serveur et les explorateurs de cloud. Autres expériences doivent être étendus ou modifiés : IntelliSense pour U-SQL inclut une compréhension des tables et des fonctions définies dans le cloud dans ADLS, fournissant des saisies semi-automatiques appropriés en fonction de leur. Un autre jeu de clés de fonctionnalités se trouve dans Figure 1, qui est une représentation sous forme de graphique d’exécution de requête qui se produit lorsque la compilation d’une requête pour l’exécution dans l’environnement cloud distribuées, parallèlement.

Figure 1 graphique de travail U-SQL affiché dans Visual Studio

Lorsque vous développez un script SQL-U, démarrez-le comme vous le feriez dans d’autres langues. Vous créez un projet où vous pouvez ajouter des fichiers de type U-SQL. Vous pouvez insérer des extraits de code dans des fichiers de requête pour vous aider à démarrer, ou accéder à des exemples de code à partir d’un exemple de projet. Une fois que vous avez écrit du code, il est naturel pour compiler et exécuter votre code pour rechercher et corriger les erreurs et tester votre logique. Cela devient alors la boucle serrée pour votre travail jusqu'à ce que le code atteint un niveau fonctionnel globale.

Cette boucle de travail a des complications pour les données volumineuses. Code de données volumineux s’exécutant dans les clusters de données volumineuses, la situation est destiné aux développeurs d’exécuter son code dans un cluster. Souvent, cela nécessite l’installation et la maintenance d’un cluster de développement. Elle peut également prendre plus de temps à passer par le cycle complet d’envoi, l’exécution et recevoir des résultats. Dans ce cas, la boucle serrée devient trop lente. Dans certaines technologies d’une installation « une boîte » d’un cluster est disponible. Cela nécessite probablement des outils d’installation spécial, mais il peut être installé sur l’ordinateur de développement que vous utilisez.

U-SQL simplifie cette situation en fournissant un compilateur et le runtime qui peut s’exécuter sur un ordinateur local. Alors que le plan d’exécution (y compris des éléments tels que des degrés de parallélisme, le partitionnement et donc sur) pour un ordinateur local et l’environnement en nuage sont susceptibles d’être très différentes, le graphique de flux de données et de calcul doivent être identiques. Par conséquent, bien que les performances de la série locale sera comparable à celle du service cloud, il fournit une expérience de débogage fonctionnelle. Les outils nécessaires pour l’exécution locale sont installés avec les outils de LAC de données Azure pour le plug-in Visual Studio et sont disponibles immédiatement. Ils peuvent également être installées comme package NuGet et exécuter à partir de la ligne de commande pour des fins d’automatisation.

L’environnement d’exécution local ressemble à un autre compte ADLA. Vous pouvez le voir dans la fenêtre Explorateur de serveurs sous la section Analytique lac de données, où vos comptes en nuage sont répertoriées. Boîtes de dialogue de soumission, il est représenté par une option dans la liste des comptes cible avec l’étiquette « (Local) ». Tson compte local peut avoir tous les nœuds enfants qui ont des comptes réels. Cela signifie que vous pouvez définir des objets de métadonnées telles que les bases de données, des tables et des vues. Vous pouvez également enregistrer des bibliothèques c# ici pour prendre en charge l’exécution des scripts U-SQL dont le code défini par l’utilisateur. Cela est nécessaire pour établir une correspondance avec l’environnement cloud pour la testabilité complète de votre code U-SQL.

La boucle de développement U-SQL puis ressemble beaucoup à autres langages. Vous pouvez créer un projet U-SQL et une fois que suffisamment de code est prêt, vous pouvez compiler pour rechercher des erreurs de syntaxe. Vous pouvez également exécuter localement via le débogage (F5) et l’exécuter sans débogage (Ctrl + F5) les commandes de Visual Studio. Cela exposera des erreurs d’exécution tels que les problèmes d’analyse de données pendant ingestions fichier (commande EXTRAIT dans SQL-U), débogage très courant. À tout moment, vous pouvez passer à soumettre le code à exécuter dans votre compte ADLA dans Azure. Notez que cela entraîne des frais en fonction de la durée globale de la requête.

La gestion des données

Étant donné que les jeux de données pour les scénarios de données volumineuses est souvent trop importante pour l’utiliser sur un ordinateur de développement, il devient nécessaire de gérer les données de test et à des fins de débogage. Une technique courante pour gérer cela consiste à faire référence à des fichiers de données par les chemins d’accès relatifs. Le compilateur U-SQL interprète des chemins relatifs à la racine du stockage par défaut pour un environnement d’exécution. Chaque compte ADLA a un compte de stockage par défaut associé (vous pouvez le voir dans la fenêtre Explorateur de serveurs). Pour une exécution dans le cloud, les chemins d’accès sont trouvent dans cette racine. Lorsqu’elle est exécutée localement, les chemins sont recherchés dans le répertoire racine de données globales figurant sous Outils | Options | Lac de données Azure.

Pour le développement, une pratique courante consiste à spécifier un chemin d’accès relatif à un fichier qui existe à la fois localement et dans le cloud. Le script peut ensuite être exécuté sans modification à la fois localement ou comme soumis à ADLA. Dans le cas où les données d’entrée existent déjà dans Azure, vous pouvez télécharger une partie du fichier. L’expérience ADL dans Visual Studio vous permet de le faire en accédant au fichier à partir du graphique de travail ou l’Explorateur de fichiers (dans le menu contextuel sur les comptes de stockage dans l’Explorateur de serveurs) et en sélectionnant l’option de téléchargement. Si les données n’existent pas encore, un fichier de test doit être créé. Avec les données en place, la boucle de développement local peut continuer comme avant.

Débogage avec Code défini par l’utilisateur

Le fait que U-SQL vous permet d’utiliser c# pour définir le code de client introduit des fonctionnalités de débogage supplémentaires. En bref, les extensions c# doivent être enregistrées dans une base de données dans le compte ADLA où la requête associée sera exécutée. Comme mentionné précédemment, peuvent également être cela dans le scénario d’exécution local en utilisant le compte « (Local) ». Générale est que vous créez un distinct c# projet bibliothèque de classes (il est un type de projet pour ce sous la zone ADL), puis inscrivez.

Il existe également une autre façon de définir le code utilisateur et gérer l’inscription pour vous de Visual Studio. Vous remarquerez que, dans un projet SQL-U, chaque fichier a automatiquement un fichier code-behind associé. Il s’agit d’un fichier c# où vous pouvez ajouter du code pour les extensions simples qui ne sont pas destinés à être partagé avec d’autres projets. Dans les coulisses, Visual Studio gère création d’une bibliothèque, l’enregistrement et annulation de l’enregistrement pour vous lors de l’envoi de la requête pour l’exécution. Cela fonctionne à nouveau, avec un compte de « (Local) », également.

Quelle que soit la façon dont le code défini par l’utilisateur est créé, il peut être débogué comme tout autre code c# pendant l’exécution dans l’environnement local. Points d’arrêt peuvent être définies dans le code c#, examinés de traces de pile, variables espionnées ou inspectés et ainsi de suite. Cette fonctionnalité lance la commande Démarrer le débogage (F5).

Débogage à l’échelle

À ce stade, j’ai abordé les fonctionnalités qui vous permettent de générer du code U-SQL dans les projets spécifier des sources de données, compiler et exécuter localement et parcourir le code c#. Si vous pensez, « Que phonétique de toutes les autres langues que je code dans », c’est génial ! J’ai mentionné que l’objectif ici est de prendre un environnement complexe par nature distribué et d’exécution parallèle et de faire croire que vous codez pour une application de bureau. J’ai également abordé un peu comment gérer des sources de données et les extensions c# dans votre code entre locaux et les environnements de cloud. À présent, examinons un nom unique pour le débogage de tâches données volumineuses à l’échelle (autrement dit, en cours d’exécution dans le cloud).

Si vous avez suivi l’approche du développement de votre code et de débogage sur votre ordinateur local, puis à ce stade vous avez sans doute compris les erreurs de logique et obtenez les sorties. En d’autres termes, votre logique métier doit être son. Des données volumineuses, cependant, vous disposerez d’énormes quantités de données et le format des données est susceptible de changer. N’oubliez pas que dans l’architecture de LAC de données, vous stockez les données dans son format natif et que vous spécifiez structure ultérieurement. Cela signifie que les données ne peut pas être considérées comme correctement mise en forme jusqu'à une fois que vous avez traité pour qu’elle soit de cette façon.

Maintenant, lorsque vous exécutez votre code testé à grande échelle dans le cloud et que vous essayez de traiter toutes vos données, vous verrez les nouvelles données et pourrez démarrer sur les problèmes que vous ne trouvez pas avant. En outre, votre requête compilée, optimisée et distribuée sur peut-être des centaines ou des milliers de nœuds, chacun d'entre eux exécuter une partie de la logique sur une partie des données. Mais si un de ces segments de travail échoue de manière irrécupérable, comment pouvez vous déterminer ce que s’est-il passé ?

La première que U-SQL et ADLA vous y aideront consiste à gérer comme prévu qu'est un service de tâche de rapport d’erreurs. Si une exception se produit en dehors de code utilisateur, puis le message d’erreur qui accompagnent la trace de la pile, et les données détaillées sont collectées à partir du nœud qui posent problème et stockées par rapport à la tâche d’origine (envoi de requêtes). À présent, lorsque vous affichez le projet dans Visual Studio ou le portail Azure, vous devez immédiatement affichera les informations d’erreur. Pas besoin d’analyser des fichiers journaux ou de stdout pour essayer de décrypter l’emplacement de l’erreur.

Un cas encore plus intéressant et courants est lorsque vous avez un code personnalisé et l’échec se produit il. Par exemple, vous traitez un format de fichier binaire avec votre propre extracteur et il échoue sur une entrée particulière à mi-chemin durant l’exécution du travail. Dans ce cas, ADLA effectue à nouveau un lot de travail pour vous. Les parties du graphique de l’exécution de requête qui réussissent, l’image du code, ni les données intermédiaires sont conservées dans le système. Toutefois, si un sommet (une instance d’un nœud dans le graphique de l’exécution) échoue avec une erreur dans la partie du code utilisateur, le fichier binaire exécutable et les données d’entrée sont conservées pendant une période de temps pour permettre le débogage. Cette fonctionnalité est intégrée à Visual Studio, comme indiqué dans Figure 2.

Figure 2 un sommet échec localement le débogage

En cliquant sur le bouton de débogage démarre une copie des fichiers binaires, des ressources et des données à partir du sommet ayant échoué sur votre ordinateur local. Une fois la copie est téléchargée, un projet temporaire est créé et chargé dans une nouvelle instance de Visual Studio. Vous avez la version exécutable du nœud défaillant et faire toutes le débogage normal prévue, par exemple en cours d’exécution à l’exception, placer des points d’arrêt dans le code c# et inspecter les variables. N’oubliez pas que les sommets individuels dans les clusters utilisés pour exécuter des tâches de données volumineuses sont réellement serveurs et sont susceptibles d’être similaire à votre ordinateur de développement. Étant donné que vous avez également un runtime U-SQL local sur votre ordinateur, cette fonctionnalité devient possible. 

Une fois que vous avez débogué le problème sur votre ordinateur local, vous allez mettre à jour votre code source séparément. Le projet et le code indiqué dans l’instance de débogage sont des artefacts à partir d’une requête exécutée précédemment et les modifications que vous apportez sont locale. Si vous avez une bibliothèque de code c# inscrite, puis vous devrez reconstruire et mettre à jour de la bibliothèque dans ADLA. Si vous avez apporté des modifications à vos fichiers de script ou code-behind U-SQL, vous devez mettre à jour votre projet.

Pour résumer

Plateformes de données volumineuses ont été systèmes hautement spécialisés nécessitant l’apprentissage des technologies, des modèles et des nouveaux concepts. La plupart des premiers utilisateurs a dû se rendre dans les coulisses pour découvrir le fonctionnement interne de ces systèmes, tout d’abord à les configurer, puis être en mesure de raisonner sur la programmation dans ces environnements. Alors que le champ a été déplacé vers l’avant jusqu'à ce que l’installation de ces plates-formes sont devenus plus simple, une plus grande équipe est en cours d’exécution. L’opportunité doit aujourd'hui par permutation à un modèle de service de données volumineuses dans le cloud où l’abstraction du système est à un niveau supérieur. Cela permet l’installation d’un environnement de données volumineuses trivial, un résultat encore plus fort impact n’est que le modèle de développement est considérablement simplifié.

La combinaison de LAC de données Azure et U-SQL simplifie le modèle de l’exécution, de programmation paradigme et des outils utilisés pour développer des applications et des requêtes de données volumineuses. Cela a pour effet de permettre aux développeurs plus prise en main des données volumineuses et aux développeurs de créer plus rapidement des solutions plus complexes de données volumineuses double. ADL est pris en charge par un large éventail de services analytique dans Azure qui prennent en charge la gestion de flux de travail, le déplacement des données, visualisation des business intelligence et bien plus encore. U-SQL est le meilleur point de départ pour le développement d’applications de données volumineuses, recherchez à ces autres services que vos besoins évoluent.

---

Omid Afnan est responsable de programme principal dans l’équipe de données volumineuses Azure travaillant sur des implémentations des systèmes de calcul distribué et des chaînes d’outils populaires connexes pour les développeurs.  Il réside et fonctionne en Chine. Contactez-le à omafnan@microsoft.com.

Merci à l'expert technique Microsoft suivant d'avoir relu cet article : Yifung Lin