4. Avertissement
Subjectif ?
“Qui fait une part exagérée aux opinions
personnelles ; partial : Une critique subjective.”
Merci Josette Larousse!
Ce sera surtout d’une totale mauvaise foi !
6. Stream processing = traitement temps réel des data
Mais pour quels besoins ?
- Import continue des données
pour analyse en temps réel
- Construction de dashboards
live
- Exploration immédiate des
données
Exemples:
- Monitoring de logs pour
surveillance de menaces
- Moteur de recommandations
- Analyse de sentiment
- Prévention d’anomalies avec
alertes
« A l'horizon 2020, 70 % des organisations et des entreprises adopteront le
streaming des données pour permettre des analyses en temps réel » (Gartner)
7. Traitement sur un stream ?
weblogs
url status
/help 200
Compter les nombres
de requêtes pour
chaque URL
/help 1
/help 1
/products 1
/help 1
/products 2
/products 200
/products 500
Réception ➜ Traitement ➜ Mise à jour du résultat
8.
9. Mais en avez-vous vraiment besoin ?
Exemple du réel vrai de vrai:
- Le client: "Je veux faire du streaming, j’ai besoin de traiter en temps réel pas mal de
messages, et j’ai vu ce que fait Uber, ça me parait bien adapté”
- Le fournisseur: “Et combien de messages ? C’est pour voir quelle plateforme on va pouvoir
vous proposer, dimensionner…”
- Le client: “Plusieurs centaines !”
- Le fournisseur: “Par millisecondes ?”
- Le client: “Non, quand même pas, on débute, ce sera... par jour !!"
10. Un Kafka en PROD ? Mais bien sûr, monsieur le client !
$ vi kafka-server.sh
#!/bin/bash
echo "[" $(date) "] INFO starting (kafka.server.KafkaServer)"
sleep 3
echo "[" $(date) "] INFO Awaiting socket connections on 0.0.0.0:9092. (kafka.network.Acceptor)"
while [ true ]
do
nc -l 9092 >> trash.txt 2>&1
done
11. Architecture vue de loin
Data delivery
Kafka
HDFS
Processors / Analytics Sinks
Kafka
HDFS
MongoDB
Hive
Cassandra
Elasticsearch
Schema
registry
Data sources
Logs
Social
Bases de
données
Evénements
Capteurs
...
S3
DB
...
Data Viz
Data
storage
Data processing
Aggregate
Join
Branch ...
Projection
Filter
MySQL ...
16. Largement adopté par tous (même si on peut/veut l’éviter…)
○ Développeur
○ Architecte data
○ Data scientist
○ Et des beaucoup moins techniques !!
Pourquoi SQL in 2018 ?
C’est un standard !
Les streams sont des données comme les autres !
Alors pourquoi ne pas utiliser SQL pour les requêter ?
17. SQL vs. Stream processing
Relational Algebra / SQL Stream Processing
Relations (or tables) are bounded (multi-)sets of
tuples.
A stream is an infinite sequences of tuples.
A query that is executed on batch data (e.g., a table
in a relational database) has access to the
complete input data.
A streaming query cannot access all data
when is started and has to "wait" for data to
be streamed in.
A batch query terminates after it produced a fixed
sized result.
A streaming query continuously updates its
result based on the received records and
never completes.
Source: https://ci.apache.org/projects/flink/flink-docs-release-1.5/dev/table/streaming.html
18. Requêter en SQL un stream ?
weblogs
url status
/help 200
Compter les nombres
de requêtes pour
chaque URL
/help 1
/help 1
/products 1
/help 1
/products 2
/products 200
/products 500
Réception ➜ Traitement ➜ Mise à jour du résultat
SELECT
url,
count(*) as nb_req
FROM
weblogs
GROUP BY
url
20. Apache Calcite
● Catalogue des metadatas
● Parsing SQL
● Validation des requêtes SQL
● Optimisation des requêtes SQL
○ Plan d’exécution
● Adaptateurs pour différentes sources de données (MongoDB, Elastic, …)
Pour les streams: définition d’un minimum de mots-clés et de fonctions
pour les requêter
L’exécution des requêtes est à la charge du système utilisant Calcite
21. THE keyword !
SELECT STREAM * FROM weblogs;
weblogs est un stream
Requêtes ne se terminant pas
Sur quelles données ? de maintenant à ...
SELECT STREAM url, status_code, nb_bytes FROM weblogs;
SELECT STREAM url, nb_bytes FROM weblogs WHERE status = 500;
22. Jointure avec une table
Et si la table bouge ?
Une solution: stocker
l’historique dans la table pour
l’utiliser dans la requête
SELECT STREAM c.id_pizza, p.prix
FROM commandes_pizza AS c
JOIN pizzas AS p
ON c.id_pizza = p.id_pizza;
Simple pour une table qui
ne change pas
SELECT STREAM c.id_pizza, p.prix
FROM commandes_pizza AS c
JOIN pizzas AS p
ON c.id_pizza = p.id_pizza
AND c.rowtime
BETWEEN p.dateDebut AND p.dateFin;
23. Group by, order by: quelques contraintes
SELECT STREAM status, count(*) FROM weblogs
GROUP BY status;
Non autorisé par Calcite
Le GROUP BY doit inclure une valeur monotone (par ex, rowtime)
SELECT STREAM status, count(*) FROM weblogs
GROUP BY rowtime, status;
24. Windowing
sum() 3 12 13 8
Tumbling window
SELECT STREAM
TUMBLE_END(rowtime, INTERVAL '10' SECOND),
url,
SUM(nb_bytes) AS total_bytes
FROM weblogs
GROUP BY TUMBLE(rowtime, INTERVAL '10' SECOND), url;
1
2 3
5
4 6
7
8
t
0 10 20 30 40
25. Windowing
Hopping window
SELECT STREAM
HOP_END(rowtime, INTERVAL '10' SECOND , INTERVAL '15' SECOND ) AS rowtime,
SUM(nb_bytes) AS total_bytes
FROM weblogs
GROUP BY HOP(rowtime, INTERVAL '5' SECOND , INTERVAL '10' SECOND );
sum() 6 18 21 17
1
2 3
5
4
6
7
8
t
0 10 20 30 40
9
28. Storm SQL
CREATE EXTERNAL TABLE weblogs
(ID INT PRIMARY KEY, TS BIGINT, IP_ADDRESS VARCHAR,
URL VARCHAR, STATUS INT, NB_BYTES INT)
LOCATION 'kafka://localhost:2181/brokers?topic=weblogs'
CREATE EXTERNAL TABLE errorlogs
(ID INT PRIMARY KEY, TS BIGINT, URL VARCHAR,
STATUS INT, NB_BYTES INT)
LOCATION 'kafka://localhost:2181/brokers?topic=errorlogs'
TBLPROPERTIES
'{"producer":{"bootstrap.servers":"localhost:9092","acks":"1",
"key.serializer":"org.apache.storm.kafka.IntSerializer",
"value.serializer":"org.apache.storm.kafka.ByteBufferSerializer"}}'
INSERT INTO errorlogs
SELECT ID, TS, URL, STATUS, NB_BYTES
FROM weblogs
WHERE STATUS >= 400
Kafka
spout
Filtre
erreurs
Kafka
producer
tupletuple
29. Storm SQL
Logical Plan
Table Scan
Filter
Projection
Table Modify
Physical Plan
Storm Spout
Filter
Projection
Storm Sink
INSERT INTO errorlogs
SELECT
ID, TS, URL, STATUS, NB_BYTES
FROM weblogs
WHERE STATUS >= 400
topo.newStream()
.filter(...)
.projection(...)
.persist(...)
On retrouve Apache Calcite à
peu près par là (construction du
plan d’exécution logique)
30. L’exemple Uber: Athenax
The mission of Uber is to make transportation as reliable as
running water. The business is fundamentally driven by real-time
data — more than half of the employees in Uber, many of whom
are non-technical, use SQL on a regular basis to analyze data and
power their business decisions. We are building AthenaX, a stream
processing platform built on top of Apache Flink to enable our
users to write SQL to process real-time data efficiently and reliably
at Uber’s scale.
“
”
35. Ouais, bon, coder c’est
quand même mieux !
(et hop, un p’tit peu de dette technique en prod!)
36. Conclusion
Certes, SQL et le drag&drop, ce n’est pas du rêve de développeurs
!
Mais n’oubliez pas les personnes qui vont
“développer” les traitements.
Le SQL et un framework comme Flink
permettent de réunir tous les acteurs
autour d’un outil commun pour traiter
les données, streams ou pas !