HUG France - 20160114 industrialisation_process_big_data CanalPlus
•Télécharger en tant que PPTX, PDF•
2 j'aime•1,071 vues
Industrialisation des processus Big Data chez CANAL+ par Pascal PERISSEAU et Stephen CLAIRVILLE (CanalPlus) L'intégration de la brique technique Big Data au sein d'une architecture décisionnelle déjà existante. Retour d’expérience sur les développements réalisés afin de faciliter l’intégration, la supervision, et l’exploitation des flux Hadoop dans notre écosystème décisionnel / présentation de la phase préparatoire de la mise à disposition des données aux data analysts et data scientists. Pascal PERISSEAU, responsable technique du pôle décisionnel et Big Data chez CANAL+ depuis 10 ans Stephen CLAIRVILLE, chef de projet tech. lead Big Data depuis 2 ans chez CANAL+
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à HUG France - 20160114 industrialisation_process_big_data CanalPlus
Similaire à HUG France - 20160114 industrialisation_process_big_data CanalPlus (20)
Plus de Modern Data Stack France
Plus de Modern Data Stack France (20)
HUG France - 20160114 industrialisation_process_big_data CanalPlus
- 1. Copyright Groupe CANAL+2016 –CONFIDENTIEL 1 HUG France – 14 Jan 2016 Industrialisation des processus Big Data chez CANAL+ Pascal PERISSEAU, Technical Architect B.I &Big Data CANAL+ @pperisseau Stephen CLAIRVILLE,Big Data Project ManagerCANAL+ @stefun_
- 2. 2 Copyright Groupe CANAL+2016 –CONFIDENTIEL 2 Sommaire • Pourquoile BIGDATAchezCANAL+? • Architecture etoutils • Intégration et industrialisation duSIBig DataauSIdécisionnel • Retours d’expériences
- 3. 3 Copyright Groupe CANAL+2016 –CONFIDENTIEL 3 Pourquoi le Big Data chez CANAL+ ? La collecte des données d’usages
- 4. 4 Copyright Groupe CANAL+2016 –CONFIDENTIEL 4 Les raisons du changement x3 STB collectésdepuis 2010 4M «devices» ≅200 Mlogs/jour Une croissance importante des « devices » connectés
- 5. 5 Copyright Groupe CANAL+2016 –CONFIDENTIEL 5 Les raisons du changement Mise enoeuvre d’unesolution permettant : • Accroîtrela capacité (tirer profit de l’historique de nos abonnés) tout enabaissant le coût destockage. • Réaliser des traitements complexes sur des volumes important de données. • Pérenniser le DataWareHouse historique (Teradata) sur le périmètre Legacy. • Choix d’unesolution distribuée sur Hadoop en 2013.
- 6. 6Copyright Groupe CANAL+ 2016 – CONFIDENTIEL 6 Architecture et outils • 1 cluster dans une Appliance H3 Teradata (Hadoop/Aster) • +2 millions de dossiers et fichiers • 20 serveurs de développement et production (MN, DN, ED, LD) • ≅32K runs de jobs mensuels 196.29 53.5 Capacité en To 79% 21% Statut HDFS Disponible Utilisé
- 7. 7Copyright Groupe CANAL+ 2016 – CONFIDENTIEL 7 Intégration et industrialisation duSIBig DataauSIdécisionnel Lignes directrices de l’industrialisation • Exploitation et supervision des flux • Homogénéisation et simplification des développements • Maintenabilité et évolution des plateformes • Intégration aux normes et standards existants • Interconnexion avec les flux du système Legacy (Control-M)
- 8. 8Copyright Groupe CANAL+ 2016 – CONFIDENTIEL 8 Mise en œuvre • Mise en place d’une météo de traitement et de suivi des runs des jobs • Développement de patterns de développement en shell/hql… • Utilisation de fonctions et utilitaires génériques • Versionning des scripts en cas de rollbacks • Ordonnanceur commun à tous les flux Intégration et industrialisation duSIBig DataauSIdécisionnel
- 9. 9Copyright Groupe CANAL+ 2016 – CONFIDENTIEL 9 Architecture et outils
- 10. 10Copyright Groupe CANAL+ 2016 – CONFIDENTIEL 10 Architecture et outils 1 1
- 11. 11Copyright Groupe CANAL+ 2016 – CONFIDENTIEL 11 Architecture et Outils Etat des lieux Arborescences et structures des fichiers en production /data ├── .snapshot ├── controlm ├── projet_hdp └── tmp /data/projet_hdp ├── 000_utilitaires └── 110_ceu /data/projet_hdp/110_ceu ├── 1101_ceu_ceu ├── 1102_ceu_wtr ├── 1107_ceu_erk ├── 1108_ceu_ofl ├──1109_ceu_usg └── … 4Projets Majeurs 9Sous-projets 155shells de flux 200fichiers .hql
- 12. 12Copyright Groupe CANAL+ 2016 – CONFIDENTIEL 12 Retours d’expériences Dos & Don’ts • Intérêt de l’Open Source et des distributions • Warning sur la pérennité des outils • Limitation des outils par rapport aux «Top Level Projects » et « early- releases » • Compatibilité des outils les uns avec les autres • Analyse d’impacts sur les traitements et optimisations
- 13. 13Copyright Groupe CANAL+ 2016 – CONFIDENTIEL 13 Retours d’expériences • En route vers le Dev-Ops Data Déploiement continu Livraison automatique des scripts Les + Les - Exploitation Niv.1 Expertise technique Niv.2/3 Uniformisation des dev. Diffusion et partage des normes aux équipes Facilité de migrations
- 14. Copyright Groupe CANAL+ 2016 – CONFIDENTIEL 14 Merci Questions ?
Notes de l'éditeur
- @PPE : Contexte et utilisation @SCL : Architecture et Outils @PPE : Industrisalisation : Points structurants @SCL : RetEx
- La collecte des données d’usages initiée chez C+ depuis 2010, sur un SGBD MPP, sur les données de Zapping, de navigation, de consommation (VOD, ALD), de programme (EPG) sur les données systèmes principalement, + collecte de navigation de nos abonnés sur les portails Web du groupe Traitement de la données brut (log) reconstruction des sessions, enrichissement de la donnée (EPG) Les usages : Analyse /connaissance client Moteur de recommandation Audience Limitations Physiques des systèmes existants (pour le stockage) nécessité d’effectuer des purges régulières, mais aussi pour le traitement (temps de traitement de plus en plus long),
- Aujourd’hui grâce au Big Data les données de l’entreprise deviennent un actif stratégique, un outil de création de valeur et donnent naissance à un nouveau paradigme d’organisation. Bien plus qu’une simple opportunité économique permise par des avancées technologiques, on parle aujourd’hui de démarche Big Data chez Canal+ avec l’idée de superviser les flux sur nos environnements de production. La matière première qu’est devenue la donné nous a conduit, à pousser notre réflexion sur le stockage de la donnée au vue de sa croissance exponentielle. Chez CANAL, elle se matérialise par l’arrivée de tous les « devices connectés », avec l’apparition de nouveaux flux comme l’OTT mais aussi de nouvelles définitions d’images FULL HD, voire 4K dans certains cas. Si nous couplons le tout à l’émergence des réseaux sociaux, et des objets connectés cela représente un volume de données de l’ordre de l’exaoctets (10^18 octets) et les prévisionnistes parlent de zettaoctets d’ici 2020 (10^21). En France, ce marché pourrait générer 2,8Milliars d’€ et plus de 100K emplois selon l’AFDEL; ----- Point de vue économique : low-cost data storage dans le sens ou HDFS est très attractif d’un point de vue économique par rapport à des infrastructures identiques massivement parrallèles de chez un éditeur lambda. Puissance de calcul : Capacité à traiter une masse et un volume important de données pour que des infrastructure traditionnelles ne soient plus des limitations en terme de temps de traitement. Alléger le DWH historique : Toutes les informations stockées sur DWH sont devenues de plus en plus volumineuses depuis l’arrivée des devices connectés et donc collectés.
- Pour vous faire un état des lieux au sein de notre DSI : Le Big Data chez CANAL+ aujourd’hui c’est 1gros cluster intégré dans une « appliance » dite Teradata Big Analytics Applicance H3 contenant plus de 2 millions de dossiers et fichiers répartis et splittés sur 20 serveurs distincts travaillant H24 et pouvant exécuter plus de +32000 runs de jobs mensuellement. Pour mener à bien nos tests, c’est 1 cluster de développement banalisé nous permettant de faire nos développements, nos recettes, et nos tests de montées en charge en vue de la prod. Tous ces fichiers sont répliqués au moins 3 fois sur les divers nœuds du cluster. Toute la démarche Big Data mise en place a été orientée de façon à être la plus transparente pour nos équipes de production qui ont l’habitude de travailler avec des outils d’ordonnancement et de supervision leur permettant de remonter rapidement différents niveaux d’alertes. C’est ce processus d’intégration de la brique Big Data qui a été le plus délicat à mettre en place, et ce surtout avec des technologies très modernes.
- Exploitation et supervision Standardisation du code (utilitaires et fonctions génériques) Météo /gestion des points de reprises / Statut des traitements intégration Control-M Simplification des développements Standardisation du code (utilitaires et fonctions génériques) Limitation des outils Maintenabilité et évolution (migration) Limitation des outils Standardisation du code (utilitaires et fonctions génériques) Intégration/interconnexion avec le système legacy Intégration au scheduler d’entreprise (Control-M vs Oozie), Codification des normes et standards Eviter la redondance des données entre systèmes
- D’un point de vue écosystème, ce graphique proposé par Hortonworks développe la stack de la distribution en version 2.1 des produits et versions que nous utilisons sur notre système en production. Effectivement, tous les outils qui existaient déjà en version 1, lorsque nous avons commencés notre démarche, restent présents en version 2 avec l’arrivée de nouveaux outils comme Ranger, Knox ou Falcon pour la sécurité par exemple et un moteur d’allocation de ressources dédié : Tez pour optimiser les requêtes Hive.
- Hive : Sur notre architecture de production, nous utilisons essentiellement des outils comme Hive en version 0.13 avec l’arrivée de ses nouvelles fonctions de Windowing, et le SQL-like qui a évolué sur « des features » et autres aspects pouvant paraître basique en SQL. Nous avons également fait les choix d’utiliser des options de tunning pour optimiser les jobs et les différentes requêtes. Les partitions et spécifications liées aux jobs Hive sont également des paramètres qui sont normés dans notre démarche d’industrialisation. Notre moteur d’exécution des requêtes est designé sur le modèle du « capacity scheduler » avec 4 types de file d’attente dites queue allouées en fonction des ressources et de la consommations des jobs en terme de CPU, RAM et container d’applications. Tez : Aujourd’hui, nous bénéficions des avancées technologiques proposées par Tez dans certains traitements et nous apprécions considérablement les faibles latences que nous connaissions sous MapReduce v1 grâce à YARN. Pig : Pour toutes les transformations ou encore les modifications des données brutes, nous utilisons Apache Pig en production. Le mode opératoire proposé par le shell « grunt » permet aux développeurs de monter rapidement en compétence sur la techno. et il est vrai que Pig est plus adapté à l’univers de l’informatique décisionnelle où dominent les développements en « step by step » par rapport à Hive. Pour vous citer l’un des exemples d’utilisation de Pig, nous l’avons utilisé afin de processer une routine de décryptage des informations personnelles (nom, prénom, numéro de téléphone portable/fixe, adresse, email..) des données issues de la collecte. En effet, dans le fichier json initial sont cryptées tous ces attributs, et sur l’algorithme AES 256/CBC/PKC7 base 64 nous décryptons à l’aide de la clé ces informations qui seront remontées aux analystes. SolR : De façon plus visuelle, nous alimentons des index et dashboards sur SolR à travers des datamarts qui sont modélisés et alimentés sur Hive. Ambari : L’interface d’administration proposée par Ambari nous permet de monitorer nos clusters, et c’est à travers cette interface que les DBAs peuvent superviser, installer, redémarrer, être alerté de l’état du cluster en temps réel, ou encore suivre l’avancé d’un job de production. Sqoop & Flume : Ces outils de streaming et d’intégration ont été utilisées à maintes reprises pour des POCs et autres développements, cependant nous ne les utilisons pas en production face à d’autres outils et ou librairies proposées par les éditeurs tiers. Nous avons fait le choix d’utiliser TDCH (Teradata connector for Hadoop) afin d’offloader ou encore de déverser les tables volumineuses de notres DWH historique. La migration de tout notre parc applicatif Big Data et du moteur en YARN ne seront que favorable à l’intégration d’une version Hadoop plus mûre dans nos environnements de production. Ce gap de génération entre le moteur Hadoop et ses applications natives est la preuve d’une amélioration de toute la plateforme et donc de l’écosystème OpenSource.
- Malgré un écosystème d’outils très récents, notre démarche qui a commencé il y a plus de 2 ans, a pris la direction des autres projets et workflows déjà existants chez CANAL+. Nous retrouvons donc de la même façon, une arborescence de répertoires identiques à celle qui existe déjà sur les environnements comme TD et Informatica. En intégrant cette brique Big Data, nous souhaitons que les processus de normes et de livraison des projets restent cohérents par rapport à l’existant. Ce sont tous ces développements adaptatifs qui nous mèneront à un niveau de service de production stable et équivalent à celui existant aujourd’hui.
- Intérêt de l’Open Source et diversification des outils proposés Warning sur le choix et la pérénité des outils Limitation des outils et sélection des outils sans se brider sur les opportunités apportées par le monde de l'OpenSource et TPL --> Complexité de migrations intrinsèques et compatibilités des outils les uns avec les autres Compatibilités des outils les uns avec les autres Analyse d’impacts pour éviter la réplication, et le syncrhonisme des systèmes
- L’industrialisation des processus Big Data chez CANAL+ nous a permis de nous concentrer sur des business cases à forts enjeux. Monétiser, et apporter une plus-value à notre donnée est devenu plus simple avec des processus normés. Nos prochains sujets autour de l’industrialisation des processus Big Data sont axés autour du déploiement continu, de la livraison automatique des scripts de nos développeurs, tout ce qui va dans le sens du mouvement DevOps. Monter un cluster est devenu assez facilement réalisable, et encore plus avec les “click-on-deploy” proposés par les clouds managés, même si nous attendons d’autres améliorations sur -la sécurité, sujet technique nécessitant une expertise -la gouvernance des données, peu présentes dans les distributions Open Source Notre niveau de confiance est plus important sur ces technologies et nous sommes fins prêts à répondre présents des problématiques métiers du Groupe. L’intérêt de l’Open Source est toujours présent au sein de la DSI, cependant la limitation des outils de l’écosystème nous permet : d’éviter la démultiplication des outils avec les dérapages technologiques de chaque développeur faciliter la maintenabilité des plateformes --> Gains sur les migrations dûs aux scripts et limitation du "rescripting" durant les phases de migration du core HDP
- Merci de votre attention. N’hésitez pas si vous avez des questions.?