La fin du Big Data (2023)
(motherduck.com)- D’après l’expérience d’un des premiers ingénieurs de BigQuery, le goulot d’étranglement de nombreuses organisations tenait moins à la taille des données qu’à leur façon de les exploiter et à leur structure de coûts
- Les retours des clients BigQuery et du secteur indiquaient que la grande majorité des data warehouses faisaient moins de 1 To, et que même chez les gros utilisateurs, la médiane était très inférieure à 100 Go
- La séparation du stockage et du calcul dans le cloud a fortement accru les volumes stockés, mais la demande de calcul analytique, centrée sur les données récentes et les agrégats, n’a pas augmenté dans les mêmes proportions
- Dans BigQuery, 90 % des requêtes des clients dépensant plus de 1 000 dollars par an traitaient moins de 100 Mo, et même les clients disposant d’énormes jeux de données n’exécutaient pas souvent de grosses requêtes
- Les données anciennes peuvent devenir une dette à cause de la réglementation, des litiges, de la perte de sens et de logiques de traitement spécifiques ; il faut donc vérifier s’il ne vaut pas mieux agréger, supprimer ou résumer plutôt que conserver les données brutes
Écart entre la peur du Big Data et les vrais goulots d’étranglement
- Depuis plus de dix ans, un message revient sans cesse : si obtenir des insights exploitables à partir des données est difficile, c’est à cause de la taille des données
- La prescription qui l’accompagnait était d’acheter de nouvelles technologies capables de gérer le passage à grande échelle, mais même après l’achat de nouveaux outils et la migration depuis des systèmes legacy, beaucoup d’organisations peinent encore à comprendre leurs données
- En 2023, la situation n’est plus celle des débuts des mises en garde autour du Big Data
- Le grand bouleversement des données annoncé n’a pas eu lieu
- Les volumes de données ont certes augmenté, mais le matériel a progressé plus vite encore
- Les fournisseurs continuent de mettre en avant la scalabilité, mais les praticiens commencent à se demander en quoi cela répond à leurs problèmes réels
Ce que l’expérience BigQuery montre sur la taille des données des clients
- L’auteur, ingénieur fondateur de Google BigQuery, avait démontré la capacité de traitement à grande échelle du service lors de présentations publiques en exécutant des requêtes de 1 Po
- Il a ensuite débogué des problèmes clients de BigQuery, coécrit deux livres et, à partir de 2018, pris en charge les échanges avec les clients et l’analyse des métriques produit comme product manager
- L’observation la plus surprenante : la plupart des utilisateurs de « BigQuery » n’avaient en réalité pas de Big Data
- Même chez les clients disposant de gros volumes, beaucoup de workloads n’utilisaient qu’une petite partie du jeu de données total
- Au lancement de BigQuery, sa vitesse de traitement paraissait relever de la science-fiction, mais des approches plus traditionnelles ont ensuite rattrapé leur retard
- Les graphiques de l’article ne sont pas des mesures exactes, mais des dessins faits de mémoire ; l’important n’est pas la valeur précise, mais la forme de la distribution
- Les éléments avancés proviennent de logs de requêtes, d’analyses post-transaction, de résultats de benchmarks, de tickets de support client, d’échanges avec des clients, de logs de service, de billets de blog publics et de l’intuition
La plupart des organisations n’ont pas tant de données que ça
- Les slides commerciales annonçant « le Big Data arrive » laissaient entendre que tout le monde serait bientôt submergé par les données, mais dix ans plus tard, ce futur ne s’est pas matérialisé
- Chez les clients BigQuery, la grande majorité stockaient au total moins de 1 To de données
- Il existait des clients avec des centaines de Po, mais les tailles suivaient une loi de puissance décroissant rapidement
- Des milliers de clients payaient moins de 10 dollars par mois de stockage, soit environ 0,5 To
- Même parmi les clients utilisant fortement le service, le volume médian stocké était très inférieur à 100 Go
- Lors de discussions avec des analystes du secteur comme Gartner ou Forrester, le retour était aussi que la grande majorité des data warehouses d’entreprise faisaient moins de 1 To
- L’intuition du secteur situait la taille raisonnable d’un data warehouse autour de 100 Go
- L’équipe BigQuery a fait de cette échelle un axe majeur de ses efforts de benchmark
- Un investisseur ayant étudié les sociétés de son portefeuille a constaté que, même parmi des entreprises technologiques susceptibles d’avoir des volumes relativement importants, la plus grande société B2B était autour de 1 To et la plus grande société B2C autour de 10 To, la plupart étant bien plus petites
- Même dans l’exemple d’une entreprise de taille moyenne, les données ne deviennent pas facilement gigantesques
- Même si 1 000 clients passent chacun une commande par jour avec 100 lignes d’articles, cela représente moins de 1 Mo par jour et environ 1 Go au bout de trois ans
- Même avec 1 million de leads et des dizaines de campagnes dans une base marketing, la table des leads fait moins de 1 Go, et le suivi des campagnes n’occupe probablement que quelques Go
- Même lorsque SingleStore était une licorne de Series E en forte croissance entre 2020 et 2022, son data warehouse financier, ses données clients, son suivi de campagnes marketing et ses logs de service totalisaient seulement quelques Go
L’illusion créée par la séparation du stockage et du calcul
- Les plateformes modernes de données cloud adoptent toutes la séparation du stockage et du calcul, pour éviter d’enfermer les clients dans un form factor unique
- Ce changement est probablement plus important que le scale-out dans les architectures de données des vingt dernières années
- À la place d’une architecture shared-nothing difficile à administrer, une architecture shared disk permet de faire évoluer indépendamment le stockage et le calcul
- Les stockages objet scalables et suffisamment rapides comme S3 et GCS allègent les contraintes de conception des bases de données
- En pratique, la taille des données augmente beaucoup plus vite que la taille du calcul
- Les données sont produites au fil du temps, et même dans une activité statique, le volume stocké augmente linéairement avec le temps
- L’analyse porte généralement sur des données récentes, donc la demande de calcul n’a pas besoin de croître comme le stockage
- Les données anciennes ne changent pas ; les rescanner en permanence ressemble à du gaspillage, et les réponses importantes peuvent être produites sous forme d’agrégats
- Les clients passés de l’on-premises au cloud avec séparation du stockage et du calcul voyaient souvent le stockage exploser sans que la demande de calcul change beaucoup
- Un grand client retail de BigQuery avait un data warehouse on-premises d’environ 100 To, qui est passé à 30 Po après la migration cloud
- Le stockage a été multiplié par 300, mais les coûts de calcul n’ont pas augmenté dans les mêmes proportions, et il n’a pas dépensé des milliards de dollars en analyse
- Cette architecture montre qu’en utilisant un object store scalable, beaucoup moins de calcul que prévu peut suffire, et qu’un traitement distribué peut même ne pas être nécessaire
Les workloads de requêtes réels sont bien plus petits que les données totales
- Le volume de données traité par les workloads analytiques est probablement plus faible qu’on ne l’imagine
- Les dashboards sont souvent construits à partir de données agrégées
- Les utilisateurs consultent surtout les données de la dernière heure, du dernier jour ou de la dernière semaine
- Les petites tables sont interrogées plus souvent, tandis que les très grandes tables le sont de façon plus sélective
- Lors de l’analyse des requêtes de clients dépensant plus de 1 000 dollars par an sur BigQuery, 90 % des requêtes traitaient moins de 100 Mo
- L’analyse a été découpée de plusieurs façons pour éviter qu’un client particulier ne fausse les résultats par son volume de requêtes
- Les requêtes purement métadonnées ne lisant aucune donnée ont été exclues
- Les requêtes de l’ordre du Go n’apparaissaient qu’à des percentiles élevés, et celles de l’ordre du To étaient très rares
- Même les clients disposant d’énormes volumes de données interrogeaient rarement d’énormes volumes
- Lorsqu’ils lançaient de grosses requêtes, c’était surtout pour générer des rapports, et la performance n’était pas prioritaire
- Une grande entreprise de réseaux sociaux lançait de très grosses requêtes le week-end pour le reporting exécutif du lundi, mais cela ne représentait qu’une infime partie des centaines de milliers de requêtes exécutées en semaine
- Les bases analytiques modernes utilisent plusieurs techniques pour réduire les données réellement lues
- La projection de colonnes ne lit que les champs nécessaires
- Le partition pruning ne lit qu’une plage de dates restreinte
- L’élimination de segments via le clustering ou le micro-partitionnement automatique exploite la localité des données
- Le calcul sur données compressées, les projections et le predicate pushdown réduisent aussi les I/O au moment de la requête
- La réduction des I/O diminue la quantité de calcul nécessaire, ainsi que les coûts et la latence
- Ressource associée : réduire les coûts d’un data warehouse cloud
- Ressource associée : diagnostiquer les goulots d’étranglement de performance d’un data warehouse
Le coût du traitement pousse à faire de petites requêtes
- Le fait de pouvoir traiter rapidement via scale-out ne signifie pas que le traitement est bon marché
- Si 1 000 nœuds sont utilisés pour obtenir un résultat, le coût peut devenir très élevé
- La requête de 1 Po exécutée dans les démonstrations BigQuery coûtait 5 000 dollars au prix public
- Cette inefficacité fait partie de la taxe Big Data qui pèse sur les équipes n’opérant pas à l’échelle du Po
- Les incitations financières à réduire le volume de données traité s’appliquent même sans modèle de facturation au nombre d’octets scannés
- Qu’il s’agisse du coût de scan de BigQuery ou du coût d’inactivité d’une instance Snowflake, les principaux data warehouses cloud peuvent faire gonfler la facture
- Des requêtes plus petites permettent d’utiliser des instances plus petites, s’exécutent plus vite et autorisent davantage d’exécutions concurrentes
La plupart des données sont rarement interrogées
- Une grande part des données traitées correspond à des données très récentes, de moins de 24 heures
- Une fois les données âgées d’environ une semaine, elles ont environ 20 fois moins de chances d’être interrogées que les données du dernier jour
- Au bout d’un mois, les données restent généralement en place et ne sont interrogées que lors de rares exécutions de rapports
- La distribution par âge des données stockées est bien plus progressive que les schémas d’accès
- Beaucoup de données sont rapidement supprimées, mais beaucoup continuent aussi d’être ajoutées en bout de table
- Même si les données de l’année écoulée ne représentent que 30 % du total, elles peuvent concentrer 99 % des accès
- Même si les données du dernier mois ne représentent que 5 % du total, elles peuvent concentrer 80 % des accès
- Quand les données se calment avec le temps, le working set réel devient bien plus maîtrisable qu’on ne l’imagine
- Même avec une table de 1 Po couvrant dix ans, seules les données du jour peuvent être consultées fréquemment
- Les données du jour peuvent représenter moins de 50 Go compressés
Les limites d’une machine unique ne cessent de reculer
- Si l’on définit le Big Data comme « ce qui ne tient pas sur une seule machine », le nombre de workloads concernés diminue chaque année
- En 2004, lorsque l’article Google MapReduce a été écrit, il était courant que des workloads de données ordinaires ne tiennent pas sur une seule machine généraliste
- En 2006, quand AWS a lancé EC2, les instances proposées n’avaient qu’un seul cœur et 2 Go de RAM, et beaucoup de workloads ne tenaient pas sur cette machine
- Aujourd’hui, les instances standard d’AWS utilisent, à l’échelle d’un serveur physique, 64 cœurs et 256 Go de RAM
- La RAM est supérieure de plusieurs ordres de grandeur aux premières instances EC2 de 2006
- En payant davantage pour des instances optimisées mémoire, on peut encore augmenter la RAM de plusieurs ordres de grandeur
- Cela amène à se demander combien de workloads ont réellement besoin de plus de 24 To de RAM ou de 445 cœurs CPU
- Dans le cloud, le coût des grosses VM augmente presque linéairement avec la puissance de calcul
- Une VM qui occupe tout un serveur ne coûte que 8 fois plus qu’une VM qui utilise 1/8 du serveur
- Des performances proches du benchmark à 3 000 nœuds parallèles de l’article Dremel original semblent aujourd’hui atteignables sur un seul nœud
Les données peuvent être une dette plutôt qu’un actif
- Une autre définition du Big Data est un état où le coût de garder les données reste inférieur au coût de décider quoi jeter
- Les data lakes de nombreuses organisations ressemblent davantage à d’immenses marécages qui ont grossi non parce qu’ils étaient nécessaires, mais parce que personne n’a supprimé les données
- On ne sait pas ce qu’ils contiennent
- On ne sait pas s’il est sûr de les nettoyer
- Le coût de conservation des données dépasse le simple coût physique de stockage des octets
- Des réglementations comme le RGPD ou le CCPA imposent de suivre certains usages des données
- Certaines données doivent être supprimées dans un délai donné
- Si des numéros de téléphone restent trop longtemps dans des fichiers parquet d’un data lake, cela peut enfreindre des obligations légales
- Les données anciennes peuvent aussi se retourner contre l’organisation lors de litiges
- De même que beaucoup d’organisations limitent la durée de conservation des e-mails pour réduire leur responsabilité potentielle, les données d’un data warehouse peuvent devenir des preuves défavorables
- Si des logs vieux de cinq ans révèlent un bug de sécurité dans le code ou un SLA non respecté, les conserver plus longtemps prolonge l’exposition juridique
- Comme le code subit le bit rot, les données peuvent perdre leur signification
- Les gens peuvent oublier le sens exact de champs spécifiques
- D’anciens bugs de données peuvent disparaître de la mémoire collective
- Par exemple, il a pu exister une courte période où tous les customer id ont été définis à null, ou une énorme transaction frauduleuse a pu donner une image trop favorable des résultats du T3 2017
- La logique métier qui récupère des données anciennes peut devenir de plus en plus complexe, du type « avant 2019 : revenue ; de 2019 à 2021 : revenue_usd ; à partir de 2022 : revenue_usd_audited »
Vérifier si l’on fait partie du 1 % du Big Data
- Le Big Data existe réellement, mais la plupart des gens n’ont peut-être pas besoin de s’en inquiéter
- Pour savoir si l’on fait partie des Big Data One-Percenters, on peut se poser les questions suivantes
- Générez-vous vraiment des quantités énormes de données ?
- Si oui, devez-vous vraiment utiliser une quantité énorme de données en une seule fois ?
- Si oui, est-ce vraiment trop volumineux pour tenir sur une seule machine ?
- Si oui, n’êtes-vous pas simplement en train d’empiler les données ?
- Si oui, ne vaudrait-il pas mieux les résumer ?
- Si la réponse à l’une de ces questions est « non », vous pouvez être candidat à une nouvelle génération d’outils de données adaptés à la taille réelle de vos données
- Un exemple associé mentionne les alternatives modernes à BigQuery
- Les organisations devraient choisir leurs outils et leurs politiques de conservation en fonction de la taille réelle de leurs données et de leurs schémas de requêtes effectifs, plutôt que de se laisser effrayer par une taille de données qu’elles auront peut-être un jour
1 commentaires
Avis de Hacker News
Dans mon ancien poste, quand on recrutait des data scientists, une question piège qu’on aimait poser était : « si l’exigence indique jusqu’à 6 TiB de données, quelle stack/architecture construiriez-vous ? »
En entendant de grands discours sur BigQuery, Hadoop, etc., puis en demandant aussi les coûts matériels/logiciels/licences, on obtenait souvent des estimations à plusieurs dizaines de milliers de dollars par an.
Au final, les candidats retenus étaient ceux qui comprenaient que 6 TiB, c’est une quantité que six personnes dans une pièce peuvent se répartir sur leurs smartphones ; qu’un disque dur d’entreprise à 199 dollars, ou trois pour la redondance, suffisent ; et qu’on peut même traiter le tout en CSV en le chargeant plusieurs fois en mémoire avec des scripts
awk.Moi aussi, quand j’apprends à manier un marteau, je tombe facilement dans l’erreur de voir des clous partout, mais en recrutement, ne pas avoir le sens des ordres de grandeur de ce qu’est le « vrai big data » était un motif d’élimination.
Plutôt que de conclure, à partir de cette seule réponse, qu’il sur-conçoit tout, il vaut mieux considérer qu’il est tombé dans une question piège, dans une situation artificielle où l’intervieweur est en position de force.
J’ai récemment passé un entretien technique avec un intervieweur ayant à peu près la même ancienneté et la même expérience que moi, et j’ai raté ma réponse ; l’intervieweur s’est montré jugeant vis-à-vis de ma mauvaise réponse. Si les rôles avaient été inversés, j’aurais pu le mettre tout aussi mal à l’aise sur un sujet que je connais mieux.
En tant qu’intervieweur, il faut faire particulièrement attention à ne pas abuser de sa position de supériorité. C’est contre-productif pour l’entreprise, et ce n’est pas bon non plus pour la personne en face.
« Service de conseil : vous m’apportez un problème de big data, je vous dis “votre jeu de données tient en RAM”, et vous me versez 10 000 dollars pour vous avoir fait économiser 500 000 dollars. »
Il y a quelques années, un directeur m’a montré un système construit par l’IT avec Hadoop, une passerelle API, plusieurs développeurs et des coûts annuels de plusieurs centaines de milliers de dollars. Quand je lui ai dit qu’au vu de l’échelle actuelle et de l’échelle prévisible à l’avenir, une clé USB branchée sur son laptop et quelques scripts Python suffiraient à le faire tourner, il s’est fortement agacé, et je n’ai plus jamais été impliqué dans ce projet.
Je vois cela comme une partie du cycle de frime généralisé dans l’entreprise. C’est une structure dans laquelle on ne peut pas admettre : « nous faisons quelque chose de simple ».
awk, et même s’ils le voulaient, parcourir 6 To à chaque requête sur un seul CPU, sans partitionnement ni stockage orienté colonnes, sera toujours lent.Pour ce genre d’usage, BigQuery convenait généralement bien. L’interface console suffit pour l’analyse ad hoc, et on peut aussi y connecter beaucoup d’outils comme Metabase ou Tableau.
Avec un partitionnement correct, les coûts ne sont pas excessifs, et si cela devient un problème, il suffit d’ajouter des tables de rollup.
.parquetsont totalement sous-estimés, et beaucoup de gens ne connaissent toujours pas ce format.Contrairement au CSV, ils préservent les types de données ; ils sont 10 fois plus petits que le CSV, ce qui transforme 6 To en 600 Go ; et la lecture est 50 fois plus rapide. C’est aussi un standard ouvert de l’Apache Foundation.
On ne peut pas les inspecter aussi facilement qu’un CSV, mais ce compromis en vaut la peine. J’aimerais que partout où l’on propose du CSV en téléchargement, on propose aussi du
.parquet.Dans l’ensemble, je suis d’accord avec une grande partie du texte, mais il y a quelques réserves. Premièrement, MongoDB est un mauvais point de référence. Je n’ai jamais vu quoi que ce soit que MongoDB fasse et que PostgreSQL ne fasse pas mieux ; et les solutions big data ne sont généralement pas NoSQL/MongoDB, mais plutôt des bases de données orientées colonnes, du MapReduce, Cassandra, etc.
Deuxièmement, il faut planifier le succès. 95 % des entreprises ne deviennent pas des licornes, mais si l’on vise les 5 % restantes, on ne peut pas y arriver sans s’y préparer. La raison pour laquelle on conçoit en tenant compte de la scalabilité dès qu’on a 5 clients, c’est pour pouvoir saisir le moment où la croissance exponentielle arrive.
Cela dit, la leçon principale est juste. La plupart des données ne sont pas volumineuses, et même des données sur chaque personne dans le monde peuvent tenir sur un Chromebook à 100 dollars. La plupart des données sont consultées rarement, les requêtes sont petites, et la première étape d’un travail de big data consiste souvent à réduire des téraoctets à des gigaoctets, mégaoctets, voire parfois kilooctets réellement nécessaires. Avec la réglementation, le coût des données augmente aussi.
Les gens ne se contentent pas de planifier : en général, ils implémentent aussi. Si l’on planifie les trois prochains mois, on peut être bien plus agile et productif. Si l’on n’exécute pas, on ne peut pas devenir une licorne.
On dirait une combinaison du syndrome du deuxième système et du biais du survivant. Les personnes qui ont nettoyé le bazar d’un bon MVP se plaignent en disant « on aurait dû faire ça avant », mais les entreprises qui avaient effectivement tout planifié et conçu à l’avance n’ont pas survécu, donc elles ne sont même pas là pour faire l’objet de plaintes.
Je suis d’accord avec presque tout le reste, mais ce point me semblait faux, et je ne pouvais pas le laisser passer.
La piste d’atterrissage d’une startup est limitée, et si les ingénieurs dépensent de l’argent sur des choses qui ne porteront leurs fruits que des années plus tard, cela augmente les chances d’échouer avant d’atteindre ce moment-là.
Quand un produit obtient une traction aussi forte, c’est généralement dû à un effet composé lié à l’existence et aux besoins de sa base d’utilisateurs. Même si l’ajout de nouveaux utilisateurs se passe mal pendant la croissance, il est peu probable que les utilisateurs existants reviennent à l’ancien produit ou aillent ailleurs.
À l’époque, voir la fail whale de Twitter tous les jours faisait partie du quotidien, mais la plupart des gens ne sont pas partis, et il n’y a pas non plus eu de migration massive vers une alternative qui scalait mieux. Les produits qui connaissent ce genre de croissance exponentielle sont rares, et pendant ce processus, il est courant de souffrir sur la montée en charge et de voir la disponibilité se dégrader. Je me demande quels produits en croissance exponentielle ont réellement échoué parce qu’ils n’arrivaient pas à scaler.
À l’époque où le « big data » était à la mode, j’étais chercheur au Large Hadron Collider. Pour nous, analyser toutes les données était un cas d’usage pertinent, et en statistiques fréquentistes, plus on a de données, mieux c’est.
Mais même en utilisant un réseau mondial de supercalculateurs, nous avons compris qu’un stockage local rapide valait mieux que d’attendre la fin d’énormes jobs. Au bout du compte, chaque doctorant a réussi à réduire les données pertinentes à précisément 1 à 5 To, sans perdre beaucoup de flexibilité d’analyse.
Il semble y avoir là quelque chose comme une loi de la commodité, comparable à la loi de passage à l’échelle d’Amdahl.
Cela ressemble davantage à une limite humaine qu’à une limite mathématique. Il existe clairement un plafond à la flexibilité que nous pouvons exploiter. Cela changera peut-être si l’on trouve des moyens d’exécuter plus facilement de nouveaux types d’analyses, mais la croissance semble plutôt logarithmique par rapport au nombre de choses que l’on veut faire.
Les gens sont très doués pour trouver des moyens pratiques d’améliorer un peu les choses chaque année, mais toute idée demande un temps minimal pour être mise en œuvre.
Si ma mémoire est bonne, la file d’attente de cette machine était aussi longue, voire plus longue, que le temps nécessaire pour exécuter les jobs sur du matériel bon marché, et des systèmes massivement parallèles comme Beowulf sont nés de ce type d’efforts.
Réduire la taille des bases de données stockées et des calculs est un excellent moyen de minimiser la facture mensuelle du client.
D’après mon expérience, les données continuent de croître de façon exponentielle, mais pas la quantité d’information.
En finance, si on le souhaite, on peut facilement obtenir 100 millions de points de données par jour pour une seule série temporelle, et travailler avec des milliers de séries temporelles. Mais cette fréquence d’échantillonnage et ce nombre de séries sont généralement redondants à 99,99 %. Les valeurs propres tombent presque à zéro après environ 10 dimensions, parfois bien plus tôt.
Il y a très peu de raisons de stocker des pétaoctets de données tick que l’on ne consultera jamais. Dans beaucoup de cas, il est bien plus raisonnable de faire, dès la collecte, une réduction de dimension agressive et avec perte, de ne stocker que les premières composantes principales et les valeurs aberrantes, et de surveiller la stabilité des valeurs propres pour détecter si un nouveau facteur jusque-là négligeable devient important.
Au final, le jeu de données devient beaucoup plus petit et plus facile à manipuler, et il apporte souvent davantage d’insights précisément parce qu’il est réellement exploitable.
Cela a l’air intéressant, mais c’est un sujet complètement nouveau pour moi.
Ce qu’il y avait de drôle avec le « big data », c’est qu’il créait une incitation perverse à éviter même les optimisations les plus élémentaires et évidentes au niveau logiciel. Plus les exigences matérielles étaient élevées, plus on pouvait prouver à quel point on était impressionnant.
Par exemple, si quelqu’un disait : « Chef, au lieu de calculer sur l’ensemble du jeu de données, on peut lire un échantillon et calculer les moyennes de ce rapport sur un simple ordinateur portable », le chef l’entendait comme : « Qu’est-ce que ça veut dire, un échantillon ? Qu’est-ce que tu essaies d’insinuer avec ton baratin de mathématicien/ingénieur ? Tu ne veux quand même pas dire que j’ai gaspillé des millions de dollars ? »
Le discours commercial exagéré et le bruit autour du big data, ainsi que la compétition de frime pour savoir qui avait des données suffisamment volumineuses, ont été très intenses pendant un temps.
Pendant longtemps, il a été très difficile d’obtenir plus de 64 Go de mémoire sur une seule machine, et quand on se heurte à une limite dure, la complexité d’implémentation grimpe très vite.
Un processus qui échoue 1 fois sur 50 parce que les données ont légèrement grossi est extrêmement destructeur. Les équipes font tourner des dizaines de jobs cron réguliers de ce type, et si chacun casse souvent, on finit en astreinte à ne faire que découper des morceaux.
Hadoop et MapReduce n’étaient pas extrêmement efficaces, mais utilisés correctement ils étaient acceptables, et le fait qu’ils tournent de manière fiable comptait beaucoup plus. C’était préférable à du code C++ optimisé au bit près, auquel personne ne faisait confiance ni ne savait maintenir, et qui mourait tous les jeudis avec une erreur de segmentation bizarre.
Aujourd’hui, on utiliserait simplement Snowflake, mais à l’époque c’était un outil raisonnable.
Cet article n’est pas totalement exact. À l’origine, le big data était défini selon trois dimensions : volume, vélocité, variété
Le volume a globalement été résolu, la vélocité aussi, mais à un coût élevé. La variété, elle, ne l’est toujours pas
Aujourd’hui, le big data relève moins de « nous manquons de stockage ou de calcul » que de « nous manquons de capacité cognitive pour intégrer et comprendre tout cela »
Je recommande aussi vivement ses conférences connexes. La plupart sont sur YouTube
[1] https://www.youtube.com/watch?v=KRcecxdGxvQ
[2] https://amturing.acm.org/award_winners/stonebraker_1172121.c...
Chaque avion possède un système radar, et chacun contient 8 unités de stockage SSD RAID-0 à 16 disques de 20 TiB. En général, nous ne remplissons pas complètement le RAID, ce qui donne environ 176 TiB par jour ; avec 7 vols sur deux semaines, cela fait 1,2 PiB par campagne, soit environ 7,2 PiB par an
La raison pour laquelle il faut laisser une journée de repos entre les vols, c’est que nous devons décharger les données par fibre optique vers un serveur de stockage plus ou moins poussé dans un coin du hangar à côté du tarmac. Ensuite, nous les répliquons sur un second serveur par sécurité, et une fois la mission terminée, tout est envoyé au siège pour stockage et traitement
Ces données ont de la valeur, mais pas au niveau de « dizaines de milliards de dollars ». Elles servent à l’extraction de ressources, à la cartographie, à des études environnementales et géodésiques, et nous conservons chaque octet depuis 2008. Quand de nouveaux algorithmes apparaissent, nous pouvons retraiter les anciennes données selon les nouveaux standards
Les fichiers, de 800 GiB à 2 TiB, sont streamés vers des serveurs de traitement GPU, et ils ne se compressent pas. La majeure partie de ce que nous captons, le fond diffus cosmologique, est assez aléatoire. À une époque, nous avons cru à tort qu’écrire sur bande permettrait de diviser l’infrastructure par deux, mais la capacité des bandes semblait être calculée comme lorsqu’on stocke des fichiers texte de plusieurs gigaoctets remplis de zéros
Les GPU sont lents, les CPU sont lents, les bus PCIe sont lents, la RAM est lente, et même ma vitesse de frappe est lente. Tout doit toujours aller plus vite
Tout est trop lent, trop difficile, trop petit. Les disques durs sont trop petits, le réglage fin du noyau Linux et la configuration d’un réseau rapide et fiable vers le cluster de traitement sont trop difficiles. Même de simples mises à jour du noyau ou de paquets, qui ne sont que des changements internes, cassent nos systèmes d’une façon qui semble n’arriver qu’à nous
Les paramètres par défaut vivent dans l’illusion que la RAM est rare, et économisent donc la mémoire pour les opérations réseau. Mais le serveur de fichiers a 0,5 To de RAM, alors j’aimerais qu’il l’utilise entièrement pour accélérer le réseau et le système de fichiers. Au final, il faut passer 6 heures à lire la documentation de la pile réseau pour ramener les E/S à un niveau de bon sens en 2024
Je connais probablement
sysctl.confmieux que presque n’importe qui sur TerreLes stockages d’objets persistants distribués qui se prétendent conçus pour le big data s’effondrent complètement sous notre charge de travail, ou coûtent des centaines de millions de dollars. Quand on dit aux commerciaux de systèmes de fichiers distribués que la taille des objets est d’environ 1 To, ils cessent de répondre. Un fournisseur, après avoir lu les exigences, nous a même mis en relation avec son responsable des clients du renseignement. Je ne suis pas la NSA et je n’ai pas le budget de la NSA
De temps en temps, un MBA ou un PMP qui a lu un article de Bloomberg sur le cloud regarde le coût du datacenter on-premise et demande si l’on ne devrait pas migrer vers AWS ou Azure ; quand on lui montre les chiffres, en argent comme en temps, il prend un air nauséeux et change de sujet
En plus, les fournisseurs sautent tous dans le train de l’IA et du cloud et abandonnent les gammes de produits qui nous convenaient. Désormais, nous devons nous battre pour les GPU avec des hedge funds et des startups d’IA qui veulent extraire les données de leurs clients pour leur montrer des publicités
Nous manquons de stockage et de calcul, et le stockage et le calcul que nous avons sont trop lents. Les DPU/IPU sont intéressants, mais dès que les objets deviennent plus gros que des requêtes de bases SQL ou que des fragments de vidéo compressée en streaming, ils atteignent rapidement leurs limites
J’ai travaillé autrefois dans une entreprise qui produisait 20 Go de données d’analyse par jour ; c’était sans doute le plus gros volume de données que j’aurai jamais manipulé
Pour un projet junior, j’ai écrit un traitement de données avec des agrégations batch et temps réel, et stocké les résultats dans des blobs Parquet sur Azure
Mon manager était assez malin pour organiser régulièrement des réunions avec les parties prenantes afin de décider quoi conserver et quoi jeter, et grâce à de bons algorithmes, nous pouvions réduire les données à environ 200 Mo par jour
Les deux derniers mois étaient chargés dans SQL Server, les deux dernières années étaient davantage agrégées et placées sur un autre serveur, et toute l’entreprise pouvait les interroger depuis Excel dans un délai raisonnable. Les données brutes de big data pourrissent dans un stockage sur bande au cas où elles serviraient un jour
Mon manager était un mauvais gestionnaire, mais il connaissait bien les données ; avec le recul, il a fait beaucoup de choses correctement, et j’ai beaucoup appris
Pendant des années, j’ai vu de la sur-ingénierie dans les outils et pipelines de « gros » volumes de données. Dans beaucoup de cas d’usage, les data warehouses et data lakes se situent dans une plage de quelques Go à quelques To à un chiffre, et peuvent donc être simplifiés énormément, par exemple en faisant tourner DuckDB sur une instance EC2 correcte
D’après mon expérience, avec cette approche, on obtient les résultats avant même que d’autres systèmes aient commencé à exécuter la requête. Je pense à Athena
Ces temps-ci, je pense qu’on peut exécuter beaucoup de requêtes même dans le navigateur ; avec l’aide de DuckDB WASM(https://github.com/duckdb/duckdb-wasm) et de perspective.js(https://github.com/finos/perspective), j’ai donc créé https://sql-workbench.com/
Ce cycle de hype semble finalement avoir atteint son « plateau de la mort ». Ce n’est pas une fin rare dans ce secteur extrêmement soumis aux modes
L’IA aussi utilise toutes les données, puis y ajoute des réseaux de neurones magiques pour en comprendre le sens
Personnellement, je pense que le principal moteur du big data était l’ego des fondateurs d’entreprise. L’idée était en gros : notre entreprise va évidemment connaître une croissance explosive et réussir à l’échelle mondiale, donc il faut la concevoir pour cette échelle.
C’est tragique de commettre ce genre d’erreur alors qu’une seule base SQLite suffirait jusqu’à ce que le produit atteigne la Series C. Toute l’énergie devrait encore être concentrée sur le produit, pas sur le passage à l’échelle.
Hadoop est né en s’inspirant de ce qui existait chez Google, puis a gagné en popularité auprès d’entreprises du monde entier qui voulaient traiter leurs données d’une manière moins chère et meilleure qu’avec Oracle.
Spark est apparu comme une réponse à la complexité de Hive/Pig et autres, et une fois que les entreprises ont pu construire des pipelines de données fiables, elles ont pu y ajouter de l’IA.
Les modèles de données générés par des actions humaines intentionnelles, comme cliquer sur un lien, envoyer un message ou acheter, sont généralement petits. Il y a en effet une limite au nombre d’humains et au nombre d’événements intentionnels qu’un humain peut générer par seconde.
En revanche, les modèles de données générés par des machines peuvent avoir des débits et des volumes supérieurs de plusieurs ordres de grandeur, et la taille de ces modèles n’a pas de frontière nette. Ces données font souvent partie des plus intéressantes et des plus sous-exploitées, car elles permettent d’obtenir de nombreux faits sur le monde que les modèles de données intentionnelles humaines ne permettent pas d’acquérir.