Description assez intéressante de la naissance et de la 'mort' du concept de Big-Data, et notamment Hadoop. Bien sûr, le Big-Data n'est pas mort, mais son utilisation en tant que domaine global l'est. Ce concept est maintenant suffisamment implanté pour qu'on utilise des concepts plus spécifiques, comme le streaming, le multi-cloud...
Article que je comprend parfaitement mais qui me rend un peu triste, ayant commencé à travailler comme ingénieur big-data (maintenant plus data-engineer), quand le domaine était encore en pleine expansion (et totalement en mode fare-west). Maintenant les choses se sont un peu stabilisées : c'est à la fois plus simple et moins fun. Enfin, il reste encore de nombreux beaux challenges à adresser !

Le futur système pouvant potentiellement (je ne suis pas devin) remplacer la lambda architecture. En gros, la lambda architecture permet d'une part d'envoyer en streaming des données dans une base finale, qui peut-elle être utiliser pour faire du batch et vous renvoyer des analytics rapidement. On a ici le meilleur des deux mondes : streaming et batch. Le problème c'est que cela implique beaucoup de contrainte, pouvant être potentiellement résolues par l'ALT.

Les agriculteurs font de la résistance au Nebraska contre les grandes firmes. Au programmes de celles-ci : verrouillage des logiciels des tracteurs, brevets à gogo, et récupération à tout va de big-date dans le but à terme de remplacer l'humain. Encore une fois où je n'approuve pas l'usage non éthique des big-data, même si c'est mon boulot (quant aux brevets, n'en parlons pas). Assez moche mais au moins les gens essaient de s'organiser contre eux. Affaire à suivre

Pourquoi les architectures Big-Data finissent par échouer en général. Un truc que j'avais déjà entendu il y a peu (par Gartner, qui a sorti que 70% des projets échoueront cette année !). C'est vrai que c'est un truc que j'ai souvent vu : des projets qui ne passent jamais l'étape du PoC. À cela plusieurs raisons selon moi :
- qui dit Big-Data dit Big-Architecture. Et donc difficile à maintenir. Un PoC ça va, mais maintenir ensuite demande du temps, des compétences, des gens et de l'argent. Ce que les entreprises ne sont pas prêtes à mettre
- ce qui amène au deuxième point : le manque de formation. Les projets sont en général faits par des externes qui maitrisent le sujet, et il y a peu de passation de connaissance. Que ce soit la faute de l'un ou de l'autre. Du coup, on se retrouve souvent avec des gens qui quand ils doivent s'éloigner d'une procédure établie, où on leur a donnée chaque commande, sont perdus. Le mieux est selon moi d'intégrer un interne lors du développement du projet afin qu'il puisse se faire la main dessus. Et ça, c'est rarement fait (par manque de temps, de budget, et à cause du "on verra bien plus tard" Trop tard souvent)
- les projets sont trop aboutis. La faute au effet hype (avec des articles qui promettent monts et merveille) et des boites qui mettent des étoiles dans les yeux des clients pour réussir la vente. Sauf qu'il faut ensuite réaliser le produit, et que ça s'avert beaucoup moins performant qu'annoncé, ce qui décoit le client. Les prestataires se disent que si elles ne font pas cela, elles n'auront pas de projets, mais c'est faux : une personne technique d'une boite sera toujours rassuré quand on lui dit qu'on va d'abord mettre un truc simple en place pour voir, et qu'ensuite on avisera (et c'est ces personnes-là qu'il faut viser !). C'est selon moi la meilleure façon de procéder : d'abord résoudre un problème que les gens ont, avec un projet simple, ce qui mettra le client en confiance, et lui donnera ensuite envie de signer pour plus gros (et le fidélise donc !). Personne n'a envie de tout changer d'un coup (surtout dans une grande entreprise, qui sont la majorité des clients en Big-Data !), donc l'approche petit à petit donne une chance de réussir, alors qu'un gros changement a toutes les chances d'échouer (quelque chose pour moi qui est très vrai dans beaucoup de situations).

La version Open-Source de Spanner (évoqué dans l'article précédent). Pas aussi efficace, bien sûr (car eux ne maitrise pas le hradware), mais quand même. L'article évoque notamment les différences majeures entre les deux outils.

Un podcast fait sur le big-data par mon ancien chef et un de ses amis. Ils rassemblent des articles de news sur le big-data, et les aborde en les analysant. Un très bon moyen de se tenir au courant du monde du big-data !
PS : dorénavant, tous les articles provenant de ce podcast seront taggés bigdatahebdo

La vidéo de ma présentation sur Python et Big Data à pydata 2016. Ok, mon accent est pas terrible mais c'est ma première présentation dans un évènement de cette envergure !
Pour résumer, j'explique en quelques points pourquoi Python me semble être un excellent langage pour faire du Big-Data.

Avec l'explosion des outils Big-Data, arrive l'explosion des architectures différentes. Et autant pas mal de gens arrivent à maitriser le batch, autant les autres types (streaming, lambda...) sont encore assez exotiques en dehors de grosses grosses entreprises. C'est là-dedans qu'il y a du boulot marrant du coup :)

Un peu de Hadoop, ça faisait longtemps ! C'est vrai que, travaillant actuellement moins avec cet écosystème, je tombe sur moins d'articles. L'occasion de me rattraper avec un article pointant vers un grand nombre d'autres articles centrés sur des outils de l'écosystème Hadoop. À Consommer sans modération

Un article du JDN sur le concept de Data Lake écrit par mon chef, et relu et corrigé par moi-même ! Vraiment intéressant comme concept, en gros on regroupe toutes les données d'une entreprise dans une plateforme sans trop les structurer pour les avoir directement pour un usage futur (à la différence d'un datawarehouse où on les structure directement en vue d'un usage prévu).