Le Big Data serait mort, d�apr�s Jordan Tigani, ing�nieur fondateur de Google BigQuery
Le Big Data serait mort, d�apr�s Jordan Tigani, ing�nieur fondateur de Google BigQuery,
alors que pour IDC, le march� du Big Data enregistrera une forte croissance dans les ann�es � venir
Dans un post publi� le 7 f�vrier, Jordan Tigani, l�ancien chef d'ing�nierie et ing�nieur fondateur de Google BigQuery, soutient que le big data est mort. Bien que cela contraste avec l�analyse de IDC, donc les r�sultats des recherches indiquent que le march� des logiciels de Big Data et d'Analytics enregistrera une forte croissance dans les ann�es � venir.
Le Big Data est compos� de jeux de donn�es complexes, provenant essentiellement de nouvelles sources. Ces ensembles de donn�es sont si volumineux qu�un logiciel de traitement de donn�es traditionnel ne peut tout simplement pas les g�rer. Si le Big Data ouvre des perspectives int�ressantes, il n�en pr�sente pas moins certains �cueils. Premi�rement, le Big Data est� volumineux. M�me si de nouvelles technologies ont �t� mises au point pour le stockage des donn�es, les volumes de donn�es doublent environ tous les deux ans. Les entreprises �prouvent toujours des difficult�s � ma�triser leur croissance et � trouver des moyens de les stocker efficacement.
Mais il ne suffit pas de stocker les donn�es. Pour �tre utiles, celles-ci doivent �tre exploit�es et, en amont, organis�es. Des donn�es propres, ou des donn�es pertinentes pour le client et organis�es de mani�re � permettre une analyse significative, n�cessitent beaucoup de travail. Selon Oracle, les sp�cialistes des donn�es passent 50 � 80 % de leur temps � organiser et � pr�parer les donn�es avant leur utilisation.
Enfin, la technologie du Big Data �volue rapidement. Il y a quelques ann�es, Apache Hadoop �tait la technologie la plus utilis�e pour traiter le Big Data. Puis, Apache Spark fit son apparition en 2014. Actuellement, l�association des deux infrastructures semble constituer la meilleure approche.
Le � cataclysme � des donn�es qui avait �t� pr�dit ne se serait pas produit
Selon Jordan Tigani, le monde en 2023 n'est plus le m�me qu'au moment o� les signaux d'alarme du Big Data ont commenc� � retentir. Le cataclysme des donn�es qui avait �t� pr�dit ne s'est pas produit. La taille des donn�es a peut-�tre augment� de fa�on marginale, mais le mat�riel s'est agrandi � un rythme encore plus rapide. � Les fournisseurs continuent de mettre en avant leur capacit� d'�volution, mais les praticiens commencent � se demander quel est le rapport entre tout cela et leurs probl�mes r�els �, �crit-il.
Bien que le concept de Big Data soit relativement nouveau, les grands ensembles de donn�es remontent aux ann�es 60 et 70, lorsque le monde des donn�es commen�ait � peine � d�marrer avec les premiers datacenters et le d�veloppement de la base de donn�e relationnelle.
En 2005, on assista � une prise de conscience de la quantit� de donn�es que les utilisateurs g�n�raient sur Facebook, YouTube et autres services en ligne. Hadoop (une infrastructure open source cr��e sp�cifiquement pour stocker et analyser les jeux de Big Data) fut d�velopp� cette m�me ann�e. NoSQL commen�a �galement � �tre de plus en plus utilis� � cette �poque.
Le d�veloppement d�infrastructures open source telle que Hadoop (et, plus r�cemment, Spark) a �t� primordial pour la croissance du Big Data, car celles-ci facilitent l�utilisation du Big Data et r�duisent les co�ts de stockage. Depuis, le volume du Big Data a explos�. Les utilisateurs g�n�rent toujours d��normes quantit�s de donn�es, mais ce ne sont pas seulement les humains qui les utilisent.
Jordan Tigani explique que, la chose la plus surprenante qu�il a apprise est que la plupart des personnes qui utilisent "Big Query" n'ont pas vraiment de Big Data. M�me ceux qui le font ont tendance � utiliser des charges de travail qui n'utilisent qu'une petite fraction de la taille de leurs ensembles de donn�es. � Lorsque BigQuery est apparu, c'�tait comme de la science-fiction pour beaucoup de gens - vous ne pouviez litt�ralement pas traiter les donn�es aussi rapidement d'une autre mani�re. Cependant, ce qui relevait de la science-fiction est aujourd'hui monnaie courante, et des m�thodes plus traditionnelles de traitement des donn�es ont rattrap� leur retard �, d�clare Tigani.
MongoDB serait la base de donn�es NoSQL ou autrement scale-out la mieux class�e et, bien qu'elle ait connu une belle ascension au fil des ans, elle a l�g�rement d�clin� r�cemment et n'a pas vraiment progress� face � MySQL ou Postgres, deux bases de donn�es r�solument monolithiques. Si le Big Data prenait vraiment le dessus, on � s'attendrait � voir quelque chose de diff�rent apr�s toutes ces ann�es �, indique Tigani.
Bien s�r, la situation est diff�rente en ce qui concerne les syst�mes analytiques, mais dans le domaine de l'OLAP, on constate un passage massif du sur site au cloud, et il n'existe pas vraiment de syst�mes analytiques cloud �volutifs auxquels se comparer.
Fonctionnement des syst�mes OLAP
OLAP (Online Analytical Processing) permet aux utilisateurs d'analyser des donn�es pr�sentes de plusieurs syst�mes de bases de donn�es en m�me temps. Alors que les bases de donn�es relationnelles sont consid�r�es comme bidimensionnelles, les donn�es OLAP sont multidimensionnelles, ce qui signifie que l'information peut �tre compar�e de nombreuses fa�ons diff�rentes. Par exemple, une entreprise peut comparer ses ventes d'ordinateurs en juin avec ses ventes en juillet, puis comparer ces r�sultats avec les ventes d'un autre endroit, qui pourraient �tre stock�es dans une base de donn�es diff�rente.
Un serveur OLAP est n�cessaire pour organiser et comparer les informations. Les clients peuvent analyser diff�rents ensembles de donn�es � l'aide des fonctions int�gr�es au serveur OLAP. En raison de ses puissantes capacit�s d'analyse de donn�es, le traitement OLAP est souvent utilis� pour le data mining, qui vise � d�couvrir de nouvelles relations entre diff�rents ensembles de donn�es.
L�OLAP fournit aux analystes, aux gestionnaires et aux cadres sup�rieurs l'information dont ils ont besoin pour prendre des d�cisions efficaces sur les orientations strat�giques d'une organisation. L�OLAP peut fournir des informations pr�cieuses sur la performance de leur entreprise, ainsi que sur les am�liorations qu'ils peuvent apporter.
Les outils OLAP sont optimis�s pour les requ�tes et le reporting. Ceci contraste avec les applications OLTP (Online Transactional Processing), qui s'occupent principalement des t�ches bas�es sur les transactions.
Les outils OLAP permettent aux utilisateurs d'analyser des donn�es multidimensionnelles de mani�re interactive � partir de perspectives multiples. OLAP peut �tre utilis� pour trouver des tendances et obtenir une vue d'ensemble des donn�es. Il peut �galement �tre utilis� pour des calculs complexes et pour cr�er des sc�narios " et si " pour la planification pr�visionnelle. Les applications OLAP typiques incluent les rapports d'affaires pour les ventes, le marketing, les rapports de gestion, la gestion des processus d'affaires, la budg�tisation et les pr�visions, les rapports financiers, et plus encore.
Pour faciliter ce type d'analyse, les donn�es sont recueillies � partir de multiples sources de donn�es et stock�es dans des Data Warehouse, puis nettoy�es et organis�es en cubes de donn�es. Chaque cube OLAP contient des donn�es class�es par dimensions (telles que les clients, la r�gion g�ographique de vente et la p�riode de temps) d�riv�es par tables dimensionnelles dans les Data Warehouse. Les dimensions sont ensuite compl�t�es par les membres (tels que les noms de clients, les pays et les mois) qui sont organis�s de mani�re hi�rarchique. Les cubes OLAP sont souvent pr�-r�sum�s dans toutes les dimensions afin d'am�liorer consid�rablement le temps de requ�te par rapport aux bases de donn�es relationnelles.
Le Big Data arrive�, une id�e jamais mat�rialis�e ?
Selon des analystes, l'id�e ma�tresse du graphique "Le Big Data arrive" �tait que, tr�s bient�t, tout le monde sera inond� de donn�es. � Dix ans plus tard, ce futur ne s'est tout simplement pas mat�rialis�. Nous pouvons le v�rifier de plusieurs fa�ons : en examinant les donn�es (quantitativement), en demandant aux gens si cela correspond � leur exp�rience (qualitativement) et en y r�fl�chissant � partir des premiers principes (inductivement) �, �crit Tigani. Tigani explique que lorsqu�il travaillait chez BigQuery, il y avait des clients avec d'�normes quantit�s de donn�es, mais la plupart des organisations, m�me certaines entreprises assez grandes, avaient des donn�es de taille mod�r�e.
� La taille des donn�es des clients suivait une distribution de type loi de puissance. Le client le plus important disposait d'une capacit� de stockage double de celle du client suivant, le client suivant disposait de la moiti� de cette capacit�, etc. Ainsi, m�me si certains clients disposaient de centaines de p�taoctets de donn�es, la taille de celles-ci diminuait tr�s rapidement. Plusieurs milliers de clients payaient moins de 10 dollars par mois pour le stockage, ce qui correspond � un demi-t�raoctet. Parmi les clients qui utilisaient beaucoup le service, la taille m�diane de stockage des donn�es �tait bien inf�rieure � 100 Go.
� Nous avons trouv� d'autres arguments en faveur de cette id�e en discutant avec des analystes du secteur (Gartner, Forrester, etc.). Nous vantions notre capacit� � traiter des ensembles de donn�es massifs, et ils haussaient les �paules. "C'est bien", disaient-ils, "mais la grande majorit� des entreprises ont des entrep�ts de donn�es inf�rieurs � un t�raoctet". Le feedback g�n�ral que nous avons obtenu en parlant aux gens du secteur �tait que 100 Go �tait le bon ordre de grandeur pour un entrep�t de donn�es. C'est sur ce point que nous avons concentr� une grande partie de nos efforts d'analyse comparative.
� L'un de nos investisseurs a d�cid� de d�terminer la taille r�elle des donn�es analytiques et a interrog� les entreprises de son portefeuille, dont certaines �taient en phase de sortie (elles avaient �t� introduites en bourse ou rachet�es par de plus grandes organisations). Il s'agit d'entreprises technologiques, qui ont tendance � utiliser des donn�es de plus grande taille. Il a constat� que les plus grandes entreprises B2B de son portefeuille disposaient d'environ un t�raoctet de donn�es, tandis que les plus grandes entreprises B2C disposaient d'environ 10 t�raoctets de donn�es. La plupart d'entre elles, cependant, avaient beaucoup moins de donn�es. �
Le rapport d�IDC contrast avec l�analyse de Jordan Tigani
Le rapport semestriel Big Data and Analytics Software Tracker publi� par International Data Corporation (IDC) pr�voit que les d�veloppements g�opolitiques actuels auront un l�ger impact sur la croissance du march�, avec des perspectives positives pour l'avenir. La tendance des entreprises � s'appuyer sur la manipulation des donn�es pour analyser, pr�dire et s'adapter rapidement � l'�volution des conditions du march� est l� pour rester, �tant aliment�e par les d�fis permanents de la cha�ne d'approvisionnement et de l'�volution de la demande.
Au cours du premier semestre 2022, le march� des Big Data et d'Analytics (BDA) de la r�gion EMEA a enregistr� une croissance du chiffre d'affaires de 10 % par rapport � l'ann�e pr�c�dente en dollars am�ricains, tandis que la croissance en monnaie constante a atteint 19,5 %. D'autre part, le march� des Am�riques a connu une croissance de 21 % en dollars am�ricains et en monnaie constante, ce qui repr�sente une l�g�re croissance par rapport au second semestre 2021. Le march� des BDA dans la r�gion Asie/Pacifique, y compris le Japon (APJ), a connu une croissance de 16 % en dollars am�ricains et de 23,3 % en monnaie constante pour cette p�riode.
Source : Jordan Tigani's post
Et vous ?
Trouvez-vous l'analyse de Jordan Tigani pertinent ?
Voir aussi :
R�pondre avec citation
Partager