Temps réel ou streaming de données : préparation et optimisation
Derrière le buzz word « IOT » (Internet Of Things) se trouve la notion de temps réel. Celle-ci permet par exemple de récupérer des données de téléphones, de géolocalisation (etc.) en continu et de les stocker dans un Datalake à des fins d’analyse. Ces systèmes sont de plus en plus utilisés pour gérer les événements des différents systèmes d’un S.I (mise à jour de base de données, interaction utilisateur avec un site web, etc.). La technologie phare étant Apache Kafka, voici ce que nous avons retenu au mois de Juin sur cette technologie et le concept de temps réel qui y est lié.
Réfléchir à son système de fichiers pour bien le préparer
Bien préparer son datalake est essentiel. Après avoir installé les systèmes et les outils nécessaires, il est intéressant de se pencher sur des concepts simples, avant de commencer à vouloir optimiser les outils.
Plusieurs aspects sont à prendre en compte :
- Le format de données
Stocker des csv en brut ? JSON ? Parquet ou ORC ?
- Le besoin de compression
Ai-je beaucoup de données à traiter d’un coup ? Est-il nécessaire de fragmenter ?
Quel format de compression pour quelle donnée ?
- Le besoin d’accès à la donnée
Doit-je utliser des partitions Impala ? Faire des buckets sur mes tables ?
Est-ce que je passe 80% de mon temps en lecture sur des données statiques ?
Autant de questions qui impactent la manière dont sera organisé et rangé l’information.
Databricks en parle très bien dans ces slides, mais n’hésitez pas à nous contacter si vous cherchez des réponses plus poussées, à ces questions.
Si vous souhaitez découvrir un autre format, jetez donc un œil à Apache CarbonData (il s’agit d’un format orienté colonne, indexé et particulièrement adapté à Hadoop, Spark, etc.) Les slides de présentation se trouvent ici
Optimisation Kafka
Dans certains cas il est intéressant de modifier le nombre de partitions d’un topic Kafka, afin d’optimiser le parallélisme des tâches. L’article du blog Confluent donne de bonnes pistes de réflexion sur ce point.
Et pour mieux s’en rendre compte, voici un cas d’utilisation dans les télécommunication où un retour sur leurs optimisations Spark/Kafka est présenté : article à lire ici.
Voici quelques éléments sur lesquels se base ce cas d’utilisation :
- Nombre de partitions Kafka
- RPC Timeout exception
- Mémoire du driver et des conteneurs
- Taille de la fenêtre du batch
D’autres ajustements ont également été effectués sur la base des outils suivants : Ignite, Mesos ou encore Zookeeper.
Leur conclusion est prévisible mais intéressante aux vues des modifications apportées.
Le temps réel, un enjeu de taille
On remarque de plus en plus que les grands acteurs du Big Data s’y mettent. L’exemple même avec Talend, qui vient de lancer la Talend Integration Suite RTx. Cette plateforme devrait permettre une meilleure intégration des systèmes, basée sur du temps réel. Affaire à suivre.
Lien de l’article : ici
Intéressé ?
Si vous êtes intéressés par ces problématiques, n’hésitez pas à nous contacter, sur notre site, ou sur twitter via @cyresgroupe
___
Explore, enrich, make data yours !
___
