1. La couche source de données: y compris les bases de données traditionnelles, les entrepôts de données, les bases de données distribuées, les bases de données NOSQL, les données semi-structurées, les données non structurées, les robots d'exploration, les systèmes de journalisation, etc., est le mécanisme de génération de données de la plate-forme Big Data.
2. Couche de tri des données: y compris le nettoyage des données, la conversion des données, le traitement des données, l'association des données, l'annotation des données, le prétraitement des données, le chargement des données, l'extraction des données, etc. Le rôle de cette couche est de traiter les données brutes en données de produit.
3. Couche de stockage des données (centre de données): stocke les données nettoyées qui peuvent être utilisées dans les systèmes de production, tels que les métadonnées, les bases de données commerciales, les bases de données de modèles, etc. Cette couche fait directement face au système d'application et nécessite une haute fiabilité, une concurrence élevée et une Précision.
4. Couche de modélisation et d'exploration de données: cette couche met en œuvre un traitement approfondi des données. En fonction des besoins de l'entreprise, elle établit un modèle d'analyse statistique adapté aux entreprises, établit une plate-forme de traitement et d'exploitation des données volumineuses et utilise l'analyse des données, l'exploration de données, l'apprentissage en profondeur et d'autres algorithmes. Les données de production découvrent la valeur intrinsèque des données pour fournir des données et une aide à la décision pour les systèmes d'entreprise.
5. Couche d'application de l'industrie: analyse approfondie des caractéristiques des données de l'industrie, analyse des besoins des produits de données de l'industrie et établissement de produits d'application de données adaptés aux différentes industries.
6. Visualisation des données: fournir des services d'affichage et de partage de données de diverses manières telles que des rapports intelligents, des rapports spéciaux, des affichages BI, des interfaces de plate-forme, etc.
Il n'y a pas de norme pour la division hiérarchique de l'architecture de la plateforme de Big Data. Dans le passé, j'ai fait la planification d'applications Big Data, qui est également très enchevêtrée, car la classification des applications est également verticale et horizontale, et je pense toujours qu'elle reflète un principe "utilisable", clair et facile à comprendre. Peut guider la construction, ici la plate-forme Big Data est divisée en "cinq horizontales et une verticale".
Pour plus de détails, voir l'exemple ci-dessous. Cette image est plus classique et résulte d'un compromis. Elle peut être mappée à de nombreux diagrammes d'architecture de Big Data sur Internet.
Selon le flux de données, il est divisé en cinq couches de bas en haut. Il est en fait très similaire à l'entrepôt de données traditionnel. Les systèmes de données sont conceptuellement connectés. Il s'agit de la couche d'acquisition de données, de la couche de traitement des données, de la couche d'analyse des données, de la couche d'accès aux données et des applications. Couche.
Dans le même temps, l'architecture de la plateforme Big Data est différente de l'entrepôt de données traditionnel au même niveau. Afin de répondre à différents scénarios, des composants plus techniques seront utilisés pour refléter les caractéristiques d'une centaine de fleurs. C'est une difficulté.
Couche de collecte de données: elle comprend à la fois la collecte hors ligne ETL traditionnelle, la collecte en temps réel, l'analyse du robot Internet, etc.
Couche de traitement des données: selon différents scénarios de traitement des données, elle peut être divisée en HADOOP, MPP, traitement de flux, etc.
Couche d'analyse des données: contient principalement des moteurs d'analyse, tels que l'exploration de données, l'apprentissage automatique, l'apprentissage en profondeur, etc.
Couche d'accès aux données: elle consiste principalement à réaliser la séparation de la lecture et de l'écriture, et à supprimer les capacités de requête orientées application et les capacités informatiques, y compris la requête en temps réel, la requête multidimensionnelle, la requête conventionnelle et d'autres scénarios d'application.
Couche d'application de données: selon les caractéristiques de l'entreprise, différents types d'applications sont divisés. Par exemple, pour les opérateurs, il y a le marketing de précision, les réclamations du service client, l'analyse des stations de base, etc., le flux de passagers basé sur la localisation, les applications publicitaires basées sur les étiquettes, etc.
Gestion des données: Il s'agit d'une verticale, principalement pour réaliser la gestion et l'exploitation et la maintenance des données, elle s'étend sur plusieurs couches pour réaliser une gestion unifiée.
1. Couche de collecte de données
La collecte par lots hors ligne utilise HADOOP, qui est devenu le moteur principal de la collecte rationalisée actuelle. Sur cette base, des applications ou des outils de collecte de données doivent être déployés.
Par exemple, BAT est un produit développé par lui-même. Les entreprises générales peuvent utiliser la version commerciale. Il existe maintenant de nombreuses options pour ce type, comme Huawei BDI, etc. De nombreuses entreprises ont des atouts techniques, mais lorsqu'elles commencent, elles ont souvent une faible compréhension des scénarios d'application et travaillent avec les détails. Très médiocre, ce qui rend difficile de répondre aux exigences des produits fabriqués, comme le manque de fonctions statistiques, qui est très différent des MTD.Les entreprises traditionnelles doivent être prudentes lors de l'achat de ces produits.
Être capable de fabriquer et de fabriquer des produits est une question de deux domaines. Bien sûr, les petites sociétés Internet peuvent également se faire des outils de collecte utiles, mais il est difficile de résumer et de créer un vrai produit. L'auto-recherche BAT a en fait constitué un énorme Avantage.
L'acquisition en temps réel est désormais standard sur les plateformes de Big Data. On estime que le courant dominant est FLUME + KAFKA, puis combiné avec le traitement de flux + la base de données en mémoire. Cette technologie est certainement fiable, mais ces choses open source sont bonnes, mais une fois que des problèmes surviennent Le cycle de résolution est souvent plus long.
En plus d'utiliser FLUME, afin de réaliser la collecte en temps réel de la table de base de données ORACLE, vous pouvez également utiliser OGG / DSG et d'autres technologies pour réaliser la collecte de journaux en temps réel, ce qui peut résoudre le problème de charge de l'entrepôt de données traditionnel pour dessiner la pleine échelle.
Les robots d'exploration sont progressivement devenus la norme pour de nombreuses entreprises à collecter, car les nouvelles données sur Internet en dépendent principalement, vous pouvez obtenir beaucoup d'informations en ligne grâce à l'analyse de la page Web, à l'analyse de l'opinion publique, au classement du site Web, etc. Il est recommandé que chaque entreprise établisse un niveau d'entreprise. Si ce n'est pas dans la planification de votre plateforme Big Data, vous pouvez y penser. Si vous ne pouvez pas obtenir les données, il n'y a rien à dire.
La construction d'un centre de crawler au niveau de l'entreprise est assez difficile, car non seulement le crawler est nécessaire, mais aussi la création d'URL et de bases de connaissances d'application, le besoin de segmentation des mots chinois, le tri inverse et l'exploration de texte basée sur le texte de la page Web. Cet ensemble est très difficile. À l'heure actuelle, il existe de nombreux composants open source, tels que solr, lucent, Nutch, ES, etc., mais pour bien l'utiliser, la route est longue.
L'autre chose est, si possible, l'auteur recommande de mettre à niveau la plate-forme de collecte de données vers une plate-forme d'échange de données, car en fait, il y a beaucoup de données qui circulent dans l'entreprise, non seulement la collecte de données à sens unique, mais aussi beaucoup d'échange de données, comme la nécessité d'ORACLE Versez des données vers GBASE, versez des données de HBASE vers ASTER, etc. Pour l'application, cette valeur est excellente.
Étant donné que la collecte et l'échange de données ont de nombreuses fonctions très similaires, pourquoi ne pas l'intégrer est également pratique pour la gestion unifiée, je pense que beaucoup d'échanges de données d'entreprise sont axés sur les applications, la gestion des interfaces est compliquée, c'est aussi ma suggestion.
En général, il est très difficile de construire une plateforme de collecte de Big Data. Du point de vue du client, au moins les trois conditions suivantes doivent être remplies:
Capacités de collecte de données diversifiées: prennent en charge la collecte de données incrémentielles en temps réel (à l'aide de flume, file d'attente de messages, OGG et d'autres technologies) et les capacités de collecte distribuée de données par lots (SQOOP, FTP VOER HDFS) pour plusieurs données telles que des tableaux, des fichiers, des messages, etc. Il y a un ordre de grandeur d'amélioration des performances par rapport à l'ETL traditionnel, ce qui est fondamental.
Capacité de configuration visuelle rapide: fournit une interface graphique de développement et de maintenance, prend en charge le développement graphique par glisser-déposer, sans écriture de code et réduit la difficulté de collecte. Chaque interface de données de configuration prend peu de temps pour réduire les coûts de main-d'œuvre.
Capacités de gestion et de contrôle de planification unifiée: pour obtenir une planification unifiée des tâches de collecte, il peut prendre en charge plusieurs composants techniques de Hadoop (tels que MapReduce, Spark, HIVE), des procédures stockées de base de données relationnelles, des scripts shell, etc., et prendre en charge plusieurs stratégies de planification (notification de temps / interface / Manuel).
2. Couche de traitement des données
Le HIVE de Hadoop est une alternative distribuée aux entrepôts de données traditionnels. Des scénarios tels que le nettoyage, le filtrage, la conversion et la synthèse directe des données utilisés dans l'ETL traditionnel conviennent. Plus la quantité de données est grande, plus les performances de coût sont élevées. Mais jusqu'à présent, les scénarios d'analyse de données qu'il prend en charge sont également limités. Une analyse et un calcul massifs hors ligne simples sont ce qu'il est bon de faire. En conséquence, la vitesse des opérations de corrélation croisée complexes est très lente.
Dans une certaine mesure, par exemple, la table large unifiée des clients d'entreprise est relativement inefficace avec HIVE, car elle implique l'intégration de données multipartites, mais il n'est pas impossible de le faire. Le plus lent au plus, il doit encore être équilibré.
Hadoop ne pouvait pas prendre en charge l'échelle des clusters X000. À l'heure actuelle, le volume de données de nombreuses entreprises devrait dépasser ce montant. En plus des entreprises telles qu'Ali et de leurs propres capacités de R & D (telles que ODPS), devraient-elles également déménager pour répartir les clusters Hadoop en fonction des activités? Des routes telles que Zhejiang Mobile ont divisé plusieurs clusters hadoop tels que le réseau fixe, le réseau mobile et l'innovation.
Hadoop SPARK est très approprié pour l'itération de l'apprentissage automatique, mais il peut être nécessaire de vérifier s'il peut être appliqué à une analyse de corrélation de données à grande échelle et s'il peut remplacer MPP dans une certaine mesure.
MPP devrait être considéré comme la meilleure alternative aux entrepôts de données traditionnels utilisant une architecture distribuée. Après tout, il s'agit en fait d'une base de données relationnelle très variée. Il fournit un support complet pour SQL. Après l'analyse de conversion de HIVE, la fusion des entrepôts de données La modélisation est plus que suffisante pour l'utiliser pour les performances et ses performances en termes de coûts sont meilleures que les DB2 traditionnelles. Par exemple, après une utilisation pratique, les clusters Gbase30-40 peuvent dépasser 2 IBM 780 montés sur le dessus.
MPP a maintenant de nombreux produits, il est difficile de juger des avantages et des inconvénients, mais certains résultats pratiques peuvent être dits, GBASE est bon, de nombreux systèmes de la société ont été exécutés dessus, principalement nationaux, la garantie de service technique est relativement fiable, ASTER n'a pas encore attendu et vu, car Apporter des bibliothèques d'algorithmes présente certains avantages: GreenPlum et Vertica n'ont jamais été utilisés, c'est difficile à dire.
On dit maintenant que MPP sera éventuellement remplacé par le framework Hadoop. Après tout, comme SPARK et d'autres sont progressivement stables et matures, mais à court terme, je pense qu'il est toujours très fiable. Si l'entrepôt de données doit adopter une méthode d'évolution progressive , MPP est en effet un bon choix.
Aujourd'hui, de nombreuses sociétés telles que China Mobile et eBAY adoptent ce type de structure de mashup pour s'adapter à différents scénarios d'application, ce qui est évidemment un choix naturel.
La troïka de la plateforme Big Data est indispensable pour le traitement des flux.
Pour de nombreuses entreprises, il s'agit évidemment d'une existence semblable à une arme nucléaire, et un grand nombre de scénarios d'application l'exigent, elle doit donc être construite. Par exemple, les scénarios d'entrepôt de données en temps réel et quasi en temps réel inimaginables à l'ère de l'OIE sont devenus très importants dans le traitement des flux. C'est simple. Avant, il était difficile de compter un indicateur en temps réel. Actuellement, comme un système anti-fraude en temps réel, le système est appliqué pour un déploiement en une journée.
Je n'ai essayé que STORM et IBM STREAM. Je recommande IBM STREAM. Bien qu'il s'agisse d'une version commerciale, sa capacité de traitement n'est pas un peu plus que STORM. On dit que STORM n'est fondamentalement pas mis à jour, mais en fait, la quantité de données n'est pas grande. Tout peut être utilisé. D'un point de vue, une version commerciale telle qu'IBM est un bon choix, plus que suffisant pour prendre en charge divers scénarios d'application en temps réel.
Les clusters de traitement de flux utilisent une technologie de traitement de flux combinée à des bases de données en mémoire pour le traitement des données en temps réel et quasi-réel. Les clusters de traitement de flux IBM Streams assurent les activités en temps réel de l'entreprise:
3. Couche d'analyse des données
Parlons d'abord du langage. R et Python sont une paire d'amis actuels dans le domaine open source de l'exploration de données. Si je veux faire un choix, je ne peux pas le dire. Je pense que Python est plus enclin à l'ingénierie. Par exemple, il existe un support direct pour la segmentation des mots et le dessin R. La capacité est exceptionnellement puissante. Mais ils se concentraient auparavant sur des exemples de statistiques, de sorte que la prise en charge des données à grande échelle est limitée.
SPARK est une option. Il est recommandé d'utiliser SPARK + scala. Après tout, SPARK est écrit en scala et peut rapidement prendre en charge de nombreuses fonctionnalités natives.
La base de données MPTER de TD, ASTER, contient également de nombreux algorithmes. Elle devrait être optimisée sur la base d'une architecture parallèle. Cela semble être une option. J'ai déjà fait quelques degrés de communication dans le passé. La vitesse est en effet très rapide, mais l'utilisation de données est rare. Des étrangers sont également requis. Support.
Après que les outils d'exploration de données traditionnels ne soient pas disposés, SPSS dispose désormais d'IBM SPSS Analytic Server, qui renforce la prise en charge du hadoop Big Data, et le personnel de l'entreprise utilise les retours d'expérience.
Peut-être que le futur apprentissage automatique formera également un mélange d'utilisateurs haut et bas, les utilisateurs haut de gamme utilisent spark, les utilisateurs bas de gamme utilisent SPSS, mais aussi pour s'adapter à différents scénarios d'application.
Dans tous les cas, l'outil n'est qu'un outil et dépend en fin de compte de la capacité de l'ingénieur en modélisation à contrôler.
4. Couche ouverte de données
Certains ingénieurs produisent directement HIVE sous forme de requête. Bien que cela soit déraisonnable, cela montre également que le calcul et la requête nécessitent des capacités techniques complètement différentes. Même dans le domaine de la requête, différentes technologies doivent être sélectionnées en fonction de différents scénarios.
HBASE est très facile à utiliser, basé sur le stockage de colonnes, la vitesse de requête est de l'ordre de la milliseconde, et c'est également un levier pour la requête générale de dizaines de milliards d'enregistrements. Il a une certaine haute disponibilité. La requête de liste détaillée et la requête de bibliothèque d'index dans notre production sont très bonnes. Scénarios d'application. Mais la lecture des données ne prend en charge que la lecture par clé ou plage de clés, donc rowkey doit être conçu.
Redis est une base de données KV, et la vitesse de lecture et d'écriture est plus rapide que HBASE. La plupart du temps, HBASE peut le faire, Redis peut aussi le faire, mais Redis est basé sur la mémoire, principalement utilisée dans le cache de mémoire de valeurs-clés, il y a la possibilité de perdre des données, le courant Il sera utilisé pour l'interrogation en temps réel des balises. La plupart des sociétés Internet ou publicitaires qui ont coopéré utilisent cette technologie, mais si les données augmentent, alors HBASE est la seule option.
En outre, des applications de requête en ligne en temps réel basées sur les journaux Internet fournis par IMPALA sont également utilisées pour implémenter une analyse de corrélation SQL basée sur la mémoire distribuée sur la plate-forme marketing à l'aide de SQLFire et GemFire. Bien que la vitesse puisse être, mais il existe de nombreux BUG, le coût d'introduction et de transformation est relativement important .
Kylin est actuellement un outil de tueur basé sur l'analyse multidimensionnelle de hadoop / SPARK. Il existe de nombreux scénarios d'application, et j'espère avoir l'occasion de l'utiliser.
5. Couche d'application des données
Chaque entreprise doit planifier sa propre application en fonction de sa situation réelle. En fait, il est difficile de développer un plan d'application. Plus la couche supérieure de l'architecture Big Data est élevée, plus elle est instable, car le changement est trop rapide. Figure pour référence:
6. Gestion des données
La gestion de la plate-forme Big Data est divisée en gestion d'application et gestion de système. Du point de vue de l'application, par exemple, nous avons mis en place la plate-forme de gestion visuelle DACP, qui peut s'adapter à 11 composants technologiques Big Data et assurer la transparence de divers composants techniques. Accédez aux capacités, en même temps à travers la plate-forme pour réaliser la gestion complète du cycle de vie de la conception des données, du développement à la destruction des données, et les normes, les règles de qualité et les stratégies de sécurité sont solidifiées sur la plate-forme, pour réaliser la pré-gestion, le contrôle en cours et l'audit post-audit, l'audit Gestion complète de la qualité et gestion de la sécurité.
D'autres, comme la gestion des horaires, la gestion des métadonnées et la gestion de la qualité, bien sûr, il va sans dire que, comme la source du développement est contrôlée, la complexité de la gestion des données sera considérablement réduite.
Du point de vue de la gestion du système, la société intègre la plate-forme Big Data dans une gestion de plate-forme de gestion unifiée du cloud (cloud privé). La plate-forme de gestion du cloud comprend des outils de fonctionnement et de maintenance visuels qui prennent en charge le déploiement en un clic et le déploiement incrémentiel, ainsi qu'un système de gestion et de contrôle des ressources informatiques orienté vers plusieurs locataires. (Gestion multi-locataire, gestion de la sécurité, gestion des ressources, gestion de la charge, gestion des quotas et gestion des compteurs) et un système complet de gestion des droits des utilisateurs fournissent une prise en charge de la gestion de l'exploitation et de la maintenance de la plateforme de Big Data au niveau de l'entreprise. Bien sûr, de tels objectifs ambitieux doivent être atteints. Une journée de travail.
Résumez quelques valeurs révolutionnaires de la plate-forme Big Data.
À l'ère des mégadonnées, l'architecture de la plupart des entreprises sera inévitablement distribuée, évolutive et diversifiée. La soi-disant séparation à long terme n'est plus une technologie qui peut dominer le monde. Cela a un impact sur le modèle traditionnel d'externalisation technologique des entreprises centralisées. Le défi est Énorme.
À l'ère du big data et du cloud computing, il y a tellement de composants technologiques, et une nouvelle technologie doit être adoptée. Les opportunités et les risques coexistent:
Pour la version commerciale de la plateforme big data, l'entreprise est confrontée aux services des partenaires ne peut pas suivre, car le développement est trop rapide, pour la version open source, l'entreprise est confrontée au défi de ses propres capacités de fonctionnement et de maintenance et des capacités techniques, des exigences plus pratiques pour les capacités autonomes Élevé.
À l'heure actuelle, des entreprises telles que BAT, Huawei et le nouvel Internet balayent les talents. Le défi pour les talents tels que les opérateurs est énorme, mais il contient également des opportunités. En fait, pour ceux qui sont engagés dans les mégadonnées C'est également un bon choix pour dialoguer avec les opérateurs et d'autres entreprises, car d'une part les entreprises se transforment, d'autre part le volume de données est suffisamment important et les opportunités de domination technologique sont plus nombreuses.
