Le big data est mort
Qui suis-je et pourquoi j’écris cet article ?
- Depuis plus de 10 ans, j’insiste sur l’importance du big data
- En tant qu’ingénieur fondateur de Google BigQuery, j’ai promu les technologies permettant de traiter le big data
- À travers les échanges avec les clients et l’analyse produit, j’ai réalisé que la plupart des gens ne traitent pas réellement de big data
La diapositive d’introduction obligatoire
- Les présentations de nombreux produits big data véhiculent le message que « le big data arrive »
- Pourtant, dans la réalité, la plupart des applications n’ont pas besoin de traiter des données à grande échelle
- Les systèmes de bases de données traditionnels reviennent en force
La plupart des gens n’ont pas tant de données que ça
- La plupart des clients disposent de moins de 1 To de données
- Même parmi les clients qui possèdent de gros volumes de données, seuls de petits sous-ensembles sont réellement utilisés
- La taille des données suit la loi de Pareto, et l’essentiel des données est concentré chez une minorité de clients
Le biais en faveur du stockage dans la séparation entre stockage et calcul
- Les plateformes modernes de données dans le cloud séparent le stockage et le calcul
- Le volume de stockage augmente rapidement, mais les besoins en calcul changent peu
- Il n’est pas forcément nécessaire de recourir au traitement distribué pour gérer de grands ensembles de données
La taille des tâches est plus petite que la taille totale des données
- La plupart des tâches analytiques portent sur de petits ensembles de données
- Les requêtes qui traitent de gros volumes sont rares et servent principalement à générer des rapports
- Pour réduire les coûts de traitement des données, on privilégie les petites requêtes
La plupart des données sont très rarement interrogées
- La plupart des données ne sont souvent interrogées que dans les 24 heures suivant leur création
- Les données anciennes sont rarement consultées et n’occupent que de l’espace de stockage
La frontière du big data ne cesse de reculer
- La définition du « big data » évolue au fil du temps
- Le matériel moderne peut traiter des volumes bien plus importants qu’auparavant
Les données sont une responsabilité
- Le coût de conservation des données dépasse le simple coût du stockage
- Il faut tenir compte de la conformité réglementaire et de la responsabilité juridique
- Les anciennes données sont difficiles à maintenir
Faites-vous partie du 1 % du big data ?
- La plupart des gens n’ont pas besoin de traiter du big data
- Il faut se demander si les données sont réellement volumineuses, si elles peuvent être résumées, etc.
L’avis de GN⁺
- Importance de la gestion des données : plus que la taille des données, c’est leur qualité et leur gestion qui comptent. Supprimer les données inutiles et se concentrer sur les données importantes est plus efficace.
- Approche réaliste : la plupart des entreprises n’ont pas besoin de technologies big data. Il est important de choisir des outils adaptés à la taille réelle des données et aux besoins concrets.
- Réduction des coûts : dans le cloud, séparer le stockage et le calcul peut réduire les coûts. Limiter les traitements de données inutiles est économiquement pertinent.
- Responsabilité juridique : conserver des données implique une responsabilité juridique. Il faut prêter attention à la conformité réglementaire et à la sécurité des données.
- Progrès technologiques : les avancées du matériel et des logiciels rendent possibles des traitements de données qui ne l’étaient pas autrefois. Tirer parti des technologies récentes permet d’améliorer l’efficacité.
1 commentaires
Avis sur Hacker News
Expérience de recrutement de data scientists : à la question sur une architecture capable de gérer 6 TiB de données, le candidat le plus impressionnant était celui qui avait compris qu’un smartphone ou un disque dur bon marché pouvait suffire.
Comparaison entre MongoDB et PostgreSQL : MongoDB n’a rien de mieux à offrir que PostgreSQL, et les solutions big data utilisent surtout des bases de données en colonnes, Map/Reduce, Cassandra, etc.
Planifier pour réussir : la plupart des entreprises ne deviennent pas des licornes, mais il faut viser cet objectif, et une architecture pensée pour le passage à l’échelle est nécessaire dès le départ.
Taille des données et fréquence des requêtes : la plupart des jeux de données ne sont pas volumineux, et la majorité des requêtes restent de petite taille. Au début, il faut surtout travailler à réduire les données.
Big data et coût de la régulation : le coût des données augmente à cause des réglementations.
Expérience d’analyse big data : d’après l’expérience au Grand collisionneur de hadrons, un stockage local rapide était préférable à un réseau mondial de supercalculateurs.
Le paradoxe du big data : il y avait une tendance à éviter les optimisations logicielles de base pour mieux mettre en avant les besoins matériels.
Contenu informationnel des données : les données augmentent de façon exponentielle, mais pas leur contenu informationnel. Dans la finance, la plupart des données sont redondantes, et une réduction de dimension est nécessaire.
Définition du big data : le big data n’est pas simplement un problème de capacité de stockage ou de vitesse de traitement, mais de capacité cognitive à intégrer et comprendre les données.
Surconception des outils big data : dans bien des cas, des data warehouses et data lakes à l’échelle du gigaoctet ou du téraoctet suffisent, et une architecture simple offre de meilleures performances.
La mode du big data : l’engouement pour le big data est terminé, ce qui est un résultat fréquent dans les secteurs sensibles aux effets de mode.
Big data et ego des fondateurs : le principal moteur du big data était l’ego des fondateurs, et au début, une simple base SQLite suffit.
Le problème du traitement du big data : le big data est davantage un problème de traitement que de stockage, et la plupart des requêtes ne portent que sur les données récentes. Si traiter l’ensemble des données était plus simple, on peut se demander pourquoi la plupart des entreprises continueraient malgré tout à n’interroger que de petits volumes de données.