Commençons par le point de vue : parce que je n'en ai pas trouvé de meilleur.
Ensuite, parlons des raisons.D'abord, regardons ce que font les plateformes de big data.
raison
Le calcul des données structurées reste une priorité absolue
La plate-forme Big Data est principalement destinée à répondre aux besoins de stockage et d'analyse de données massives. Le stockage massif de données est en effet vrai. Outre les données structurées générées par la production et l'exploitation, il existe également de nombreuses données non structurées telles que l'audio et la vidéo. Cette partie des données est très volumineuse et occupe une grande quantité de données. Il y a aussi beaucoup d'espace, et parfois plus de 80% des plateformes de big data stockent des données non structurées. Cependant, le stockage des données ne suffit pas, et ce n'est que lorsqu'il est utilisé qu'il peut générer de la valeur, ce qui nécessite une analyse.
L'analyse des mégadonnées doit être discutée en deux parties : les données structurées et non structurées.
Les données structurées sont principalement des données commerciales générées dans le processus de production et d'exploitation d'une entreprise, qui peut être considérée comme le cœur de l'entreprise. Dans le passé, lorsqu'il n'y avait pas de plate-forme de mégadonnées, l'entreprise utilisait principalement ou complètement cette partie de les données. Avec l'accumulation continue d'activités, cette partie des données devient de plus en plus grande, et les solutions de base de données traditionnelles sont confrontées à de grands défis. La construction d'une plate-forme de mégadonnées doit naturellement résoudre cette partie du problème d'analyse des données de base.
Avec la plateforme de big data, il y a aussi plus de place pour l'imagination de chacun.Des données non structurées telles que les journaux, les images, l'audio et la vidéo qui ne pouvaient pas être utilisées dans le passé généreront également de la valeur, ce qui implique l'analyse de données non structurées. Par rapport à l'analyse des données métier de base, l'analyse des données non structurées ressemble plus à la cerise sur le gâteau. Pour autant, l'analyse de données non structurées n'existe pas de manière isolée, et elle s'accompagnera également d'un grand nombre de traitements de données structurées. Lors de la collecte de données non structurées, cela s'accompagne souvent de la collecte de nombreuses données structurées connexes, telles que le producteur de l'audio et de la vidéo, le temps de production, la catégorie, la durée, ... ; certaines données non structurées seront également transformées en structure après traitement. Données, telles que le démantèlement de l'adresse IP du visiteur, le temps d'accès, les termes de recherche clés, etc. du journal Web. L'analyse dite des données non structurées vise souvent en fait ces données structurées d'accompagnement.
L'analyse de données structurées reste une priorité absolue pour les plateformes de mégadonnées. La technologie de traitement des données structurées est relativement mature, comme notre base de données relationnelle (SQL) couramment utilisée basée sur le modèle de données relationnelles.
SQL reste la technologie de calcul de données structurées la plus largement utilisée
Le retour à SQL est une tendance de développement de la syntaxe actuelle du Big Data Computing. Dans le système Hadoop, le premier latin PIG a été éliminé, mais Hive a toujours été fort ; Spark SQL est également davantage utilisé sur Spark, tandis que Scala l'est beaucoup moins (Scala est facile à apprendre et difficile à maîtriser, et en tant que langage compilé ne prend pas en charge le déploiement à chaud, il y a aussi de nombreux inconvénients). Certains autres nouveaux systèmes informatiques de big data utilisent généralement SQL comme syntaxe de calcul préférée.Après plusieurs années de mêlée, SQL a progressivement repris l'initiative.
Il y a probablement deux raisons à ce phénomène :
1. Il n'y a vraiment rien d'autre d'utile
Les bases de données relationnelles sont trop populaires, les programmeurs sont assez familiers avec SQL et même leurs habitudes de pensée ressemblent à SQL. Il est également relativement simple d'utiliser SQL pour effectuer certaines requêtes générales. Bien qu'il ne soit pas pratique de gérer des calculs procéduraux complexes ou des opérations ordonnées, d'autres technologies alternatives ne sont pas beaucoup mieux. Lorsqu'il s'agit d'opérations difficiles à écrire en SQL, il il faut écrire la même chose qu'UDF Code assez complexe, c'est gênant quand même, il vaut mieux continuer à utiliser SQL.
2. Un soutien solide de la part des fournisseurs de Big Data
L'essence technique du Big Data est la haute performance, et SQL est la position clé pour la concurrence en matière de performance. Faire face à la même opération que la performance n'a de sens que si les opérations trop spécialisées et complexes impliquent trop de facteurs d'influence, et il n'est pas facile d'évaluer les capacités de la plate-forme Big Data elle-même. Et SQL a une série TPC standard internationale, que tous les utilisateurs peuvent comprendre, de sorte qu'il y ait une comparabilité claire, et les fabricants se concentreront également sur l'optimisation des performances sur SQL.
Compatible avec SQL est plus propice au portage
Les avantages d'une plate-forme Big Data compatible avec SQL sont évidents. SQL est largement utilisé et de nombreux programmeurs connaissent SQL. Si vous continuez à utiliser SQL, vous pouvez éviter de nombreux coûts d'apprentissage. Il existe également de nombreux logiciels frontaux prenant en charge SQL, et les plates-formes de données volumineuses utilisant SQL peuvent facilement être intégrées dans cet écosystème prêt à l'emploi. La base de données traditionnelle que la plateforme de big data entend remplacer utilise également la syntaxe SQL, donc la compatibilité sera très bonne, et le coût de la greffe sera relativement faible.
Eh bien, nous avons fini pourquoi la plate-forme Big Data reviendra au modèle de données relationnelles. Alors, quels sont les problèmes liés à l'utilisation continue du modèle de données relationnelles (SQL) ?
question
faible niveau de rendement
Le plus gros problème avec la poursuite de l'utilisation de SQL est qu'il est difficile d'obtenir les hautes performances dont l'informatique Big Data a le plus besoin.
L'absence de certains types de données nécessaires et de définitions d'opérations en SQL rend impossible la description de certains algorithmes performants, et ne peut qu'espérer l'optimisation du moteur de calcul en ingénierie. Après des décennies de développement de bases de données commerciales traditionnelles, l'expérience d'optimisation a été assez riche, mais même ainsi, il existe encore de nombreux scénarios difficiles à optimiser, et les problèmes au niveau théorique sont en effet difficiles à résoudre au niveau de l'ingénierie . Cependant, l'expérience en matière d'optimisation des plates-formes émergentes de big data est bien inférieure à celle des bases de données traditionnelles.Si l'algorithme n'est pas dominant, il ne peut que s'appuyer sur le clustering de plusieurs machines pour améliorer les performances. De plus, la capacité de SQL à décrire le processus n'est pas très bonne, et il n'est pas bon pour spécifier les chemins d'exécution.Pour obtenir des performances élevées, un chemin d'exécution spécialement optimisé est souvent nécessaire, ce qui nécessite l'ajout de nombreux modificateurs spéciaux pour l'intervention humaine. Il est préférable d'utiliser directement procédural, la syntaxe est plus simple, ce qui évite également d'écrire du code très performant en SQL.
Au début de l'invention de SQL, les capacités du matériel informatique étaient relativement faibles. Pour garantir la praticabilité, la conception de SQL doit être adaptée aux conditions matérielles de l'époque, ce qui rendait difficile pour SQL d'utiliser pleinement les capacités matérielles des technologies contemporaines. ordinateurs, en particulier la grande mémoire, le parallélisme et les clusters. JOIN en SQL correspond à la valeur de la clé, mais dans le cas d'une grande mémoire, il peut être directement mis en correspondance avec l'adresse, sans qu'il soit nécessaire de calculer la valeur HASH et la comparaison, les performances peuvent être considérablement améliorées ; la table de données SQL est hors service, et il est facile de faire un calcul de table unique Lorsqu'il s'agit de parallélisme segmenté, dans les opérations d'association multi-tables, seuls les segments fixes peuvent généralement être effectués à l'avance, et il est difficile d'obtenir une segmentation dynamique synchrone. En théorie, il n'y a pas de distinction entre les tables de dimension et les tables de faits. L'opération JOIN est simplement définie comme un post-filtrage de produit cartésien. Pour implémenter une grande table JOIN, une action HASH Shuffle qui utilise beaucoup de ressources réseau se produira inévitablement. Lorsque le nombre de nœuds de cluster est trop grand, le réseau Le retard causé par la transmission l'emportera sur les avantages d'avoir plus de nœuds.
Pour donner un exemple spécifique, nous voulons extraire les 10 premières données dans 100 millions de données, qui sont écrites en SQL comme ceci :
select top 10 x,y from T order by x desc
Il y a un ordre par dans cette instruction. Son exécution stricte impliquera un tri important, et le tri est très lent. En fait, nous pouvons proposer un algorithme qui ne nécessite pas de grands tris, mais il ne peut pas être décrit en SQL, et nous ne pouvons compter que sur l'optimiseur de base de données. Pour le cas simple décrit par ce SQL, de nombreuses bases de données commerciales peuvent en effet être optimisées, et les performances sont généralement très bonnes en utilisant des algorithmes qui ne nécessitent pas de grands tris. Mais la situation est un peu plus compliquée. Par exemple, pour prendre le top 10 de chaque groupe, utilisez les fonctions de fenêtre et les sous-requêtes pour écrire du SQL comme ceci :
select * from
(select y,*,row_number() over (partition by y order by x desc) rn from T)
where rn<=10
À ce moment, l'optimiseur de base de données sera étourdi, incapable de deviner le but de cette instruction SQL, et ne pourra honnêtement exécuter que la logique de tri (il y a toujours le mot order by dans cette instruction), ce qui entraînera une forte baisse des performances.
faible efficacité de développement
Non seulement fonctionne lentement, mais aussi l'efficacité du développement n'est pas élevée, surtout en termes de calculs complexes, l'implémentation SQL est très lourde. Par exemple, pour interroger les jours de hausse continus les plus longs d'un titre à partir des registres boursiers, le SQL (oracle) s'écrit comme suit :
select code, max(ContinuousDays) - 1
from (
select code, NoRisingDays, count(*) ContinuousDays
from (
select code,
sum(RisingFlag) over (partition by code order by day) NoRisingDays
from (
select code, day,
case when price>lag(price) over (partittion by code order by day)
then 0 else 1 end RisingFlag
from stock ) )
group by NoRisingDays )
group by code
Il est mis en œuvre de manière très alambiquée, sans parler de l'écrire, il faut compter une demi-journée pour le comprendre.
De plus, SQL est difficile à mettre en œuvre des calculs procéduraux. Qu'est-ce que l'informatique procédurale ? Autrement dit, il ne peut pas être écrit en une seule étape et plusieurs opérations pas à pas sont nécessaires, en particulier celles liées à l'ordre des données.
Prenons quelques exemples :
Proportion d'utilisateurs qui se sont connectés plus d'une heure par semaine, à l'exclusion des erreurs de manipulation avec une durée de connexion inférieure à 10 secondes
La répartition des jours consécutifs de consommation de cartes de crédit les plus longs au cours des trois derniers mois, compte tenu de la mise en œuvre de la promotion des points triples après 10 jours consécutifs
Combien d'utilisateurs au cours d'un mois effectuent en continu l'action d'ajouter au panier et d'acheter après avoir consulté le produit pendant 24 heures, et combien d'utilisateurs abandonnent à mi-chemin ?
...
(Pour faciliter la compréhension, ces exemples ont été simplifiés et le fonctionnement réel est beaucoup plus compliqué)
Ce type d'opération procédurale est très difficile à écrire en SQL, et il est souvent nécessaire d'écrire UDF pour le compléter. Si vous ne pouvez pas écrire de SQL, l'effet de SQL sera considérablement réduit.
Une faible efficacité de développement entraîne de faibles performances
L'efficacité d'exécution du SQL complexe est souvent très faible, ce qui renvoie au problème des performances. En effet, efficacité de développement et performances de calcul sont étroitement liées, et de nombreux problèmes de performances sont essentiellement dus à l'efficacité de développement.
L'effet d'optimisation du SQL complexe est très faible.Après quelques couches d'imbrication, le moteur de base de données s'affaiblit et je ne sais pas comment l'optimiser. Pour améliorer les performances d'opérations aussi complexes, il n'est pas fiable d'attendre l'optimisation automatique de la plate-forme de calcul, et le moyen fondamental est d'écrire des algorithmes performants. Par exemple, dans les opérations procédurales, il est souvent nécessaire d'enregistrer les résultats intermédiaires pour les réutiliser. SQL doit utiliser des tables temporaires, et davantage d'opérations d'E/S affecteront les performances. Ce ne sont pas des problèmes que l'optimisation du moteur peut résoudre, et le processus de calcul doit être réécrit. .
Par conséquent, essentiellement, améliorer les performances ou réduire la difficulté de développement. Le logiciel ne peut pas améliorer les performances du matériel. Il ne peut que trouver des moyens de concevoir des algorithmes moins complexes. Si ces algorithmes peuvent être mis en œuvre rapidement et à moindre coût, l'objectif d'amélioration des performances peut être atteint. Si le système de syntaxe est difficile, voire impossible, à décrire des algorithmes performants, et que les programmeurs doivent être contraints d'adopter des algorithmes plus complexes, il sera difficile d'améliorer les performances. L'optimisation des opérations SQL n'aidera pas à réduire la difficulté de son développement. Le système de syntaxe SQL est juste comme ça. Peu importe comment optimiser ses performances, la difficulté de développement ne changera pas. De nombreux algorithmes hautes performances ne peuvent toujours pas être implémentés, et il est difficile d'améliorer sensiblement les performances de calcul.
L'écriture d'UDF peut en effet améliorer les performances dans de nombreux scénarios, mais d'une part, elle est très difficile à développer, et d'autre part, elle est écrite en dur par les programmeurs, et elle ne peut pas tirer parti des capacités d'optimisation du moteur SQL. . De plus, il n'est souvent pas possible d'écrire l'opération complète en UDF, seule l'interface fournie par la plateforme de calcul peut être utilisée, et son type de données doit encore être utilisé dans le framework SQL, ce qui limitera la mise en œuvre d'algorithmes performants. .
La solution fondamentale est de laisser la plate-forme Big Data avoir une meilleure syntaxe.
la solution
L'utilisation de l'open source esProc SPL peut être utilisée comme un bon remplacement et une extension de SQL. En tant que langage informatique spécial pour les plates-formes Big Data, il peut continuer les avantages de SQL et améliorer ses inconvénients.
SPL est un moteur de calcul de données open source professionnel qui fournit une syntaxe de calcul indépendante. L'ensemble du système ne dépend pas de modèles de données relationnelles, il a donc fait de grandes percées dans de nombreux aspects, notamment en termes d'efficacité de développement et de performances de calcul. Voyons quelles fonctionnalités de SPL conviennent aux plates-formes Big Data contemporaines.
Forte intégration
Le premier est l'intégration : quelle que soit la qualité du SPL, il sera vain s'il ne peut pas être utilisé conjointement avec la plate-forme Big Data. Il est en fait très pratique d'utiliser SPL dans la plate-forme Big Data. Il peut être utilisé en introduisant un package jar (il est également open source, vous pouvez l'utiliser comme vous le souhaitez). SPL fournit un pilote JDBC standard, qui peut exécuter directement des scripts SPL ou appeler des fichiers de script SPL.
…
Class.forName("com.esproc.jdbc.InternalDriver");
Connection conn =DriverManager.getConnection("jdbc:esproc:local://");
//PreparedStatement st = (PreparedStatement)conn.createStatement();;
//直接执行SPL脚本
//ResultSet rs = st.executeQuery("=100.new(~:baseNum,~*~:square2)");
//调用SPL脚本文件
CallableStatement st = conn.prepareCall("{call SplScript(?, ?)}");
st.setObject(1, 3000);
st.setObject(2, 5000);
ResultSet result=st.execute();
...
Développement efficace
Grammaire agile
En termes de calcul de données structurées, SPL fournit une syntaxe de calcul indépendante et une riche bibliothèque de classes de calcul, et prend en charge le calcul de processus pour rendre la mise en œuvre du calcul complexe très simple. L'exemple précédent de calcul de la plus longue série de jours pour un stock est implémenté à l'aide de SPL comme suit :
| UN | |
|---|---|
| 1 | =db.query("select * from stock order by day") |
| 2 | =A1.group@i(prix<prix[-1]).max(~.len())-1 |
Organisez-les en fonction du jour de négociation, regroupez les enregistrements de hausse consécutifs en un seul groupe, puis trouvez la valeur maximale de -1, qui correspond aux jours de hausse continus les plus longs.
Un autre exemple consiste à répertorier le dernier intervalle de connexion de chaque utilisateur en fonction de l'enregistrement de connexion de l'utilisateur :
| UN | ||
|---|---|---|
| 1 | =ulogin.groups(uid;top(2,-logtime)) | 2 derniers enregistrements de connexion |
| 2 | =A1.new(uid,#2(1).logtime-#2(2).logtime:intervalle) | intervalle de calcul |
Il est pratique de prendre en charge la syntaxe SPL étape par étape pour effectuer des calculs procéduraux.
SPL fournit une riche bibliothèque de classes informatiques, qui peut encore simplifier l'opération.
Environnement de développement intuitif et facile à utiliser
Dans le même temps, SPL fournit également un environnement de développement concis et facile à utiliser, une exécution en une seule étape, la définition de points d'arrêt et une fenêtre d'aperçu des résultats WYSIWYG... et l'efficacité du développement est également plus élevée.
Prise en charge de plusieurs sources de données
SPL prend également en charge diverses sources de données, et plusieurs sources de données peuvent être utilisées directement.Comparé aux plates-formes de mégadonnées, qui nécessitent que les données soient "stockées" avant d'être calculées, le système de SPL est plus ouvert.
Certaines sources de données prises en charge par SPL (toujours en expansion...)
Non seulement cela, SPL prend également en charge le calcul mixte de plusieurs sources de données, en tirant pleinement parti des avantages de diverses sources de données et en élargissant l'ouverture de la plate-forme Big Data. Dans le même temps, il est plus simple d'utiliser directement plusieurs sources de données pour le développement et la mise en œuvre, ce qui améliore encore l'efficacité du développement.
échange à chaud
SPL est interprété et exécuté, et prend naturellement en charge la commutation à chaud, ce qui est un avantage majeur pour la plate-forme Big Data sous le système Java. L'écriture, la modification, l'exploitation et la maintenance de la logique informatique Big Data basée sur SPL n'ont pas besoin d'être redémarrées et prennent effet en temps réel, ce qui rend le développement, l'exploitation et la maintenance plus pratiques.
Hautes performances de calcul
Comme nous l'avons dit précédemment, hautes performances et haute efficacité de développement sont essentiellement la même chose, et il est plus facile d'écrire des algorithmes hautes performances basés sur la syntaxe concise de SPL. Dans le même temps, SPL fournit également de nombreux mécanismes de stockage de données et d'algorithmes hautes performances. Les algorithmes hautes performances et les solutions de stockage difficiles à implémenter en SQL peuvent être facilement implémentés avec SPL. La clé de l'amélioration des performances logicielles réside dans algorithmes et stockage.
Par exemple, l'opération TopN mentionnée ci-dessus, dans SPL, TopN est comprise comme une opération d'agrégation, qui peut convertir un tri de haute complexité en une opération d'agrégation de faible complexité, et peut également étendre le champ d'application.
| UN | ||
|---|---|---|
| 1 | =file(“data.ctx”).create().cursor() | |
| 2 | =A1.groups(;top(10,montant)) | Top 10 des commandes |
| 3 | =A1.groups(superficie;haut(10,montant)) | Top 10 des commandes par région |
Il n'y a pas de mot de tri dans l'instruction ici, et aucune action de tri importante ne se produira. La syntaxe de calcul de TopN dans l'ensemble ou le regroupement complet est fondamentalement la même, et les deux auront de meilleures performances.
Voici quelques cas de calcul haute performance implémentés avec SPL :
SPL open source améliore l'analyse en libre-service bancaire de 5 à 100 simultanéités
Le SPL open source accélère de plus de 20 fois les rapports sur la position du capital des banques
Le SPL open source accélère plus de 10 fois les accords de prêt bancaire
SPL open source optimise les courses de la compagnie d'assurance de 2 heures à 17 minutes
Le SPL open source accélère les tâches d'approbation des prêts bancaires de plus de 150 fois
L'open source SPL accélère le bilan 60 fois
Encore quelques mots, SPL n'est pas basé sur un modèle relationnel de données, mais adopte un système théorique innovant, qui est innovant sur le plan théorique. La raison de l'espace ne sera pas trop mentionnée ici. Il est écrit simplement et fonctionne rapidement . Le langage de base de données SPL a une introduction plus détaillée ici, et les partenaires intéressés peuvent également rechercher et télécharger par eux-mêmes.