- "POC DataStorm", quezako ?
- #1 Vue d’ensemble
- #2 : Récupération des données via le module
sql - #3 : parallélisation du traitement (transformation des données + appel des API + export CSV)
- #4 : use the framework, Luke!
- #5 : tests
- #6 : monitoring avec la console Spark
- #7 : monitoring avec les outils devops
- #8 : exécution
- #9 : devops rulez!
- #10 : regrets ?
But : analyser un an de sécurisation, via des fichiers CSV fournis à DataStorm
Comment : application Spark Java secu-replay, lancée via Jenkins sur le cluster "val"
Spark ?
pas nécessaire (facteur limitant : latence des API de sécurisation) 😇
on apprend (équipes dév / data / infra) et on renforce le socle technique 🤓
Une appli s’exécutant dans un cluster Spark avec :
-
entrée : base de donnée SQL Server
-
traitements en parallèle :
-
appel d’API de sécurisation karadoc (cluster d’API)
-
sortie : fichiers CSV (HDFS)
-
Terminologie Spark :
-
cluster : contient n workers
-
worker Spark : m cœurs (cores)
cf. glossaire
#2 : Récupération des données via le module sql
Utilisé pour lire les données (équivalent à l’instruction SQL select) : DataSet User Guide
Montre moi le code ! 👓
Facile à utiliser (DSL façon SQL) 👍
Remarques :
-
on n’a pas eu besoin de paralléliser le chargement (comme le fait vidal-express via le
MongoDB Connector for Spark) -
toutes les données d’entrée tiennent en mémoire
-
d’abord dans le code (codé en dur 🤔) cf. DataSet#repartition(Int)
-
dans les paramètres de l’appli 👍
exemple 1 👓 : https://github.com/softwarevidal/secu-replay/blob/sprint-poc.datastorm/docker/docker-compose.yml#L114(dockeer-compose)
exemple 2 👓 :
/usr/local/bin/spark-submit \
--class com.vidal.SecuReplayApp \
--deploy-mode cluster \
--master spark://val-spark.vidal.net:7077 \
--executor-memory 4g \
--num-executors 6 \ # 6 EXECUTEURS...
--executor-cores 3 \ # et 3 COEURS PAR EXECUTEUR => 18 EXECUTIONS PARALLELES MAX
--conf spark.default.parallelism=1500 \ # 1500 FICHIERS CSV
http://nexus.vidal.net/service/local/repositories/vidal-snapshots/content/com/vidal/secu-replay/1.1.0-SNAPSHOT/secu-replay-1.1.0-20181213.105335-29.jar \
--api.url http://preprod-haproxy-secureplay.vidal.net \
--input.sqlserver.criteria yearWeek >= 200003 AND yearWeek <= 201727 \
--input.sqlserver.database VIGI2_DSA \
--input.sqlserver.domain FRANCE \
--input.sqlserver.password **** \
--input.sqlserver.table dbo.v_UnifiedPrescription \
--input.sqlserver.url jdbc:jtds:sqlserver://srv-vid-valbi01:1433;databaseName=VIGI2_DSA \
--input.sqlserver.user **** \
--output.csv file:///mnt/Datastorm/2018-12-14T12_08_01_00Don’t: recoder la désérialisation/désérialisation pour les formats supportés nativement (JSON, CSV) cf. PrescriptionJsonDeserializer.java 💣
Pourquoi ? scalabilité (et ne pas perdre de temps)
Do: utiliser la API DataSet (exemple) 👍
⇒ moins de boulot
⇒ scalabilité "gratos"
Tests d’intégration avec Docker via testcontainers
Librairie facile à utiliser. 👍
avec Docker Compose
Quelques problèmes avec les tests Spark avec Docker dans Jenkins. 💣
la console Spark web UI :
-
navigation WTF? (cluster 8080 / worker 8081 driver 4040 etc.) cause : mauvaise configuration ? 💣
-
logs : sortie standard avec logs applicatif et Spark mélangés 🤔
-
métriques Java sur les API via glowroot (pour monitoring MySQL + JVM)
API de sécurisation car :
-
1 ordonnance à la fois
-
100 ms mini par requête
En augmentant le nombre d’appels aux API (+ de cœurs Spark sur le cluster) le débit d’appel/secondes n’augmentait pas ⇒ hypothèse confirmée
On a donc ajouté des instances karadoc au cluster d’API (load balancer haproxy)
Augmentation progression du débit requête API/s : https://grafana.vidal.net/d/XMHIRzYik/haproxy-metric-eng?orgId=1&from=1542628179190&to=1545209001148
L'évolution du débit des API (requêtes par seconde) durant un mois :
