1. Superbe maison d’architecte avec vue sur le lac
Des chantiers concrets pour démarrer

2. À propos...
Thomas VIAL
11 ans chez
Tribu Big Data & Analytics
depuis sa création en 2013
Consultant data geek
Architecture & data science
Auteur principal du livre blanc
Hadoop, feuille de route
Formateur Hadoop pour
Speaker au Hadoop Summit
2015 à Dublin, avec EDF

3. Au commencement était une ambition
"Le data lake Hadoop doit rationaliser la BI du Groupe et
porter les use cases analytiques, grâce à une démarche
agile centrée sur la gouvernance des données"

4. Et finalement… an architect’s dream come true
3 fichiers intégrés
1 score calculé, restitué dans une application BI
2 utilisateurs
3 noeuds Hadoop pour un cluster sur-dimensionné
0,2 ETP pour administrer la bête
1 application métier en semi-production=

5. Data lake
=
Concentrateur de données
+
Plateforme
pour favoriser l’émergence de projets s’appuyant
sur des données désilotées
Caractérisation

6. L’enjeu d’adoption
Construire une offre de services
Ingérer pour pouvoir publier
Gouverner

7. Offrir des services

8. Formaliser une offre de services
Valider l’intérêt du data lake J
Impliquer les “clients” : sponsors, utilisateurs, applications du SI,
public…
Décliner les services à tous les niveaux :
Mise à disposition et publication de données
Plateforme de construction d’applications orientées données
Soutien affiché aux projets utilisateurs du data lake

9. Organisation des données
Anticiper plusieurs fournisseurs et plusieurs projets
Anticiper les futures (?) exigences de sécurité
Privilégier la lisibilité et la simplicité (règle des 80/20) en proposant des
standards
Objectif : un script d’administration qui crée un espace projet en 5 min

10. Architecture de la plateforme
Analyser les besoins architecturaux à court terme
Prioriser les clients en fonction de l’enjeu, pas de la “hype”
technologique – Big data <> Hadoop
Faire des POC techniques pour mesurer la complexité des solutions
dans votre contexte

11. Architecture de la plateforme (suite)
Combiner les solutions techniques lorsque nécessaire répondre aux
besoins
Favoriser le prototypage et le self-service avec des API techniques
standards
Faire un état des lieux fréquent des usages et ajuster la trajectoire

12. Soutien & visibilité
Constituer un data lab faisant le pont entre les projets et les données
Publier : offre, projets, catalogue, documentation, backlog du datalab
Autoriser les dérogations aux standards, quitte à baisser le niveau de
support
Allouer du temps (~ 10%) à la formation et la veille technique continue

13. Ingérer

14. Premières sources de données
Cibler les 3-4 use cases les plus importants
Mettre ensemble les données de différents domaines
Inclure une source historiquement “difficile”

15. Bâtir un framework d’intégration
Commencer par le batch
Intégrer au format le plus brut possible
Archiver les données brutes
Objectif : une nouvelle source industrialisée en moins d’une semaine

16. L’intégration des données comme projet
Une équipe dédiée pour démarrer le framework, faire contribuer les
projets métier plus tard
Construire de manière itérative, au gré des besoins
Comme tout code applicatif, le framework est bien sûr testé

17. Gouverner

18. Des comités réguliers, même informels
Donner de la visibilité aux sponsors qui fédèrent les acteurs
Mettre en place des règles d’éligibilité des projets (accès ou
hébergement)
Définir quelques KPI simples à suivre pour ajuster l’offre de services

19. Environnements...
Comprendre l’importance de la pré-production technique
Envisager la mutualisation d’environnements sur une plateforme
Inclure le cycle de vie des données dans la définition des
environnements

20. Un SLA fort, ça coûte cher !
Un SLA modeste au début pour appréhender la complexité
Ne pas hésiter à dupliquer la donnée pour les SLA de restitution plus
critiques
Prendre acte des impacts de l’organisation sur le SLA

21. Gouvernance des données
Pas encore de solution miracle… ni open source ni commerciale
Chercher à répondre à des besoins simples avec des solutions simples
Le modèle d’organisation des données fait une partie du travail

22. Premiers plans

23. Premiers plans
Si vous avez besoin d’un data lake, bien étudier les besoins, et
comprendre les forces et faiblesses des solutions big data dans votre
contexte
Se fixer quelques objectifs pour les 2 premiers mois :
Des sponsors, une offre de services, et un embryon de data lab
Un modèle d’organisation des données, documenté dans un wiki
Un use case “étendard” en production (SLA réduit) s’appuyant sur un framework testé
Une architecture capable de traiter les tout prochains use cases sur la liste …
… et une méthodologie pour instruire les suivants

24. Merci