HBase in Financial Industry par Pierre Bittner (Scaled Risk CTO) Le traitement et l’analyse de grand volume de données sont au cœur des activités des banques. Bon nombre d’acteurs des marchés financiers ont déjà adopté Hadoop sur de nombreux cas d’usage : gestion des risques, identification des opportunités commerciales, détection de fraude, surveillance des marchés… Une incroyable diversité de format doit être gérée. De ce point de vue, HBase est un choix naturel de base de données distribuée grâce à son modèle de donnée dynamique. Après une présentation générale des caractéristiques d’HBase, ce talk présente comment modéliser les informations traitées pour s’adapter à différents contextes d’utilisation. Pierre Bittner est le CTO de Scaled Risk, éditeur d’une plateforme Big Data dédiée aux institutions financières. Scaled Risk est bâtie sur HBase. Pierre intervient depuis 10 ans sur les SI bancaires.

1. HBase in Financial Services
Pierre Bittner
@BittnerPierre
Paris HUG Meetup
14/01/2016
SCALED RISK

2. Thèmes abordés lors de ce Talk
- 1ère Partie : la banque en 2016
- 2ème Partie: présentation d’HBase
- 3ème Partie: « Schema Free » au service de la finance
SCALED RISK 2

3. La banque en 2016

4. La banque n’a pas changé depuis des décennies
- Compte courant, plan d’épargne, crédit, hypothèques,
nous « consommons» la banque comme nos parents
- A présent, nous « consommons» le transport de
façons très différentes grâce à Uber et BlablaCar
- Tout comme AirBnb a changé notre vision de
l’hôtellerie
- Cette transformation n’est pas encore survenue dans
la banque
- De nouveaux acteurs, les « Fintech », ont l’objectif de
« révolutionner » la banque traditionnelle
4
SCALED RISK

5. La banque du futur?
- Google et Facebook sont des agences de publicité à l’instar de Publicis
- Apple Pay, Google Wallet et PayPal offrent des moyens de paiement
mais n’en font pas pour autant des banques
- Quel impact aura la technologie sur la banque?
Google’s disruption of financial services is
just getting started: Forrester
“Disruptors such as Google aren’t out to get
you” “Disruption is often a side effect of their
efforts to find a better way of doing something.”
5
SCALED RISK

6. Exemple de Fintech: Ripple et les paiements internationaux
- Cette startup a inventé sa propre monnaie digitale pour réaliser des
paiements à travers les frontières
- L’utilisation d’une crypto-monnaie permet à Ripple d’effectuer le
transfert rapidement, à bas prix et de limiter les risques de fraude
6
SCALED RISK
- Devenir riche en créant sa propre
monnaie?
- Ripple n’ajoute pas de frais sur les
transactions
- Il se rémunère sur l’augmentation de
la valeur de leur monnaie

7. 2015: Prise de conscience des banques
7
SCALED RISK

8. Le poids du « Legacy »
- EasyJet et RyanAir ont été capable de
bouleverser le secteur du transport aérien
- Ils ont été construits sur de nouvelles
plateformes, sans porter la « charge » du passé
- Architectures complexes, silos de données,
manque d’agilité et coûts d’opérations élevés
pèsent sur les capacités d’innovations des
banques
8
SCALED RISK
- Les banques se doivent de réaliser leur « transformation digitale »

9. Quelles innovations en Finance?
- Enquête Capital One sur les innovations en Finance
des 3 à 5 prochaines années (Money2020 - Oct 2015)
- Big Data Analytics et paiements alternatifs sont les
principaux vecteurs d’innovation selon les
participants, devant la blockchain
- La transformation digitale a bien débuté en Finance.
- Depuis 2000, 52% des sociétés cotées du Fortune 500
ont disparu par F&A ou faillite
- Cela ne veut pas dire que les banques traditionnelles
vont complétement disparaitre mais elles se doivent
d’innover.

10. HBase dans tout ça?

11. La Finance en quelques « Big » chiffres
- New York Stock Exchange génère entre 4-5 To de données par Jour
- Stress Test en Banque de Financement: 6 millions d’opérations, 750
scénarios
- 500 Gb de données bruts et 4 milliards de calculs par jour
- Marché Boursier: environ 200k ordres p. sec / 1m p. sec en pic
- Accélération générale des traitements et des reportings
- Pour le stockage de vos données, vous utiliseriez un SGBDR? HBase?
11
SCALED RISK

12. HBase en Finance et ailleurs
- Cohérence plutôt que disponibilité mais avec indisponibilité minimum
- Salesforce pour Merril Lynch Wealth Management
- http://fr.slideshare.net/salesforceeng/hbase-at-salesforcecom
- Bloomberg – The Problem is Medium Data
- Temps de reprise après incident (MTTR), Latence générale, Haute-disponibité
- http://fr.slideshare.net/HBaseCon/case-studies-session-4a-35937605
- Et beaucoup d’autres…
- Ailleurs: Yahoo, Facebook, Twitter, Meetup!
12
SCALED RISK

13. HBase: Random Access to your Planet-Wide Transaction
- C’est la base de donnée Hadoop
- Release 1.0 en février 2015 (Stable 1.1.2)
- Inspirée de BigTable de Google - NoSQL
- Cas d’usage: lectures/écritures temps-réel de données unitaires
- Haut débit, Faible latence, Forte concurrence d’accès
- Pas pour les analytiques complexes, les full-scan
- OpenSource, fortement consistant, distribuée, non-relationel, scalable
- Et libre de tout schéma!
13
SCALED RISK

14. HBase en bref
- « Wide-Column » store: chaque ligne contient un ensemble de K/V
(!= key/value store ou columnar datastore)
- Les tables sont des espaces de nommages
- Dispose de « column family» pour les grouper
- Chaque ligne est identifiée par une RowKey
- Assure un accès rapide et la distribution des données
- Chaque cellule porte un « timestamp »
- API: 4 opérations primaires: Get, Put, Delete et Scan
- Traitements côtés serveurs avec les coprosseurs
- Architecture Master<->Slave: HMaster / RegionServer
- Les RegionServers hébergent plusieurs régions
- Les tables sont réparties sur plusieurs Regions dans des HFiles
14
SCALED RISK

15. HBase au service de la Finance

16. HBase: Modélisation de données, challenges et opportunités
- Fast Data Company & Data Driven Decision
- Evénements financiers et multiplicité des modèles è Flexible Storage
- Optimisation des traitements : Sharding Strategy
- Workload Transactional / Analytics
- Données de références
- Gestions des relations: collection d’entités
- Abus de Marché & Vision 360° des clients
- ConsolidatedAudit Trail (CAT)
16
SCALED RISK

17. Trace d’exécution sur marché actions
• 2 Ordres Achat/Vente sur un même carnet qui se “matchent”, génèrent un prix et une
exécution si l’ordre totalement rempli
- Order : OrderBook, Sender, ExtId, OrderType, Quantity, Direction, Price, Validity
- Price : OrderBook, Price, ExecutedQty, Direction, ExtId1, ExtId2, BestAsk, BestBid
- Exec : OrderBook, Sender, ExtId
• Exemple de trace:
Order;AAPL;Agent75;3978;L;B;14;19;-1
Order;AAPL;Agent11;3976;L;A;19;44;-1
Price; AAPL;14;30;B;Agent75;3978;Agent11;3976;14;19
Exec;Agent75;3978
17
SCALED RISK

18. HBase: Wide-Column Store – Free your Schema!
RowKey Column Family Column Qualifier Timestamp Value
APPL-Agent11-3976-Order info MessageType 42007969375 Order
OrderBook 42007969375 AAPL
Sender 42007969375 Agent11
ExtId 42007969375 3976
OrderType 42007969375 Limit
Direction 42007969375 B
Quantity 42007969375 1
Price 42007969375 39
Validity 42007969375 -1
AAPL-Agent75-3978-Price info MessageType 42139416667 Price
OrderBook 42139416667 AAPL
Price 42139416667 14
ExecutedQty 42139416667 30
Direction 42139416667 HUAWEI
ExtId1 42139416667 Agent75-3978
ExtId2 42139416667 Agent11-3976
BestAsk 42139416667 14
BestBid 42139416667 19
AAPL-Agent75-3978-Exec info MessageType 42139416667 Exec
OrderBook 42139416667 AAPL
ExtId 42139416667 Agent75-3978
Cellule =
{row, cf, qualifier, timestamp}
Atomicité par ligne
§ Verrous par ligne
§ Toutes les KVs pour un “row”
sont co-localisées dans une région
§ Stockage en mémoire dans un
région server
Pas de contrainte sur les noms
de colonnes ou les valeurs.
18
SCALED RISK

19. 19
La RowKey dans la Conception des Tables
Nick Dimiduk : « In designing HBase tables, the rowkey is the single most important
thing. You should model keys based on the expected access pattern.»
Les Rowkeys déterminent la performance lors de l’interaction avec les tables, car :
- les Régions sont partitionnées par HBase suivant des intervalles de RowKeys
- La répartition des HFiles dépend aussi des Rowkeys ainsi que de la
Column Family .
RQ: - HBase indexe uniquement la RowKey pour toutes les lignes .
- Les lignes sont mises en ordres dans les régions selon leurs RowKeys .
SCALED RISK

20. 20
Row Key Design – Clustered Storage pour les analyses temps-réels
- Organisation des RowKeyde façon hiérarchique
- Toutes les lignes ayant la même racine forme un cluster
- Idéalement les clusters seront stockées sur la même machine (sauf si gigantesque)
- Les mises-à-jour dans un même cluster sont plus efficaces
- Performance des jointures pour les traitements et analyses au sein d’un même cluster (pas de Sort-Merge)
AAPL
AAPL-Ag11 AAPL-Ag75
AAPL-Ag11-35-Order AAPL-Agent75-65
AAPL-Ag11-35-Exec
Distribution des Rowkey
GOOG
GOOG-Ag11
GOOG-Ag11-35-Order
Organisation du Stockage
OrderBook (AAPL)
Agent (AAPL – Ag11)
Order (AAPL– Ag11 – 35)
Price (AAPL – Ag11 - 35)
Exec (AAPL – Ag11 - 35)
Agent (AAPL - Ag75)
Order (AAPL– Ag75 – 65)
AAPL-Ag11-35-Price
OrderBook (GOOG)
Agent (GOOG– Ag11)
Order (GOOG– Ag11 – 35)
RowKey : « OrderBook– Sender – ExtId – Type »
SCALED RISK

21. 21
Les Splits dans HBase
- Un « Split » dans HBase consiste à découper la table en plusieurs régions
- HBase répartie les tables automatiquement puis les déplace vers les autres nœuds une
fois qu’on commence à insérer un grand volume de données. Exemple :
- Un seul Split au niveau de la lettre «J» => « au milieu» pour bien répartir la charge
- On peut effectuer un « Split » manuel dans HBase à travers le HBase Shell : Split ‘table-name’
Commande : n_splits = 100
create ‘table_name', 'cf', {SPLITS => (1..n_splits).map {|i| "row-#{1000+i*(9999-1000)/n_splits}"}}
- Possibilité de paramétrer le split par script lors de la création de la table:
SCALED RISK

22. Static & Reference Data : Nested Entities
Column
Family
Column
(qualifier)
Value
cf1
TradeId 123
TradeVersion 1
TradeDate 03/09/2015
TradeQuantity 100
Side Buy
pGLE
{Equity,Société Générale, Euronext,
CAC40,45€}
mXPAR {Euronext Paris, France, Cash}
- Exemple: Définition du produitsur une transaction (Trade <-> Product – Relation n-m)
- Objectif: Eviter les étapes jointures è Dénormalisation des données
- Utilisationde « Nested entities » avec la RowKeycomme qualifier et ses attributs comme valeur
Le qualifier du produit
est son identifiant
GET ‘trade’, ‘123’
GET ‘trade’, ‘123’, {COLUMN=>’pGLE’}
Le qualifier est l’id
du marché
Tous les attributs d’une
nested entities sont
regroupés dans la même
cellule
TradeId comme
rowkey
Possibilité de filtrer sur le qualifier « Produit » lors des scans 22

23. Compositions : Nested Entities encore…
23
- Exemple: Ensemble des flux de paiement sur une Transaction(Trade <-Cashflow– relation 1-n)
- HBase: Les colonnes peuvent être définis dynamiquement à l’exécution
- Un ensemble de K/Vs peuvent représenter une sous-entité ou un ensemble…
1
n
SCALED RISK

24. Compositions: Nested Entities suite…
Row Key
Column
Family
Column
Qualifier Timestamp Value
GU002 info Counterpart 42139416667 HSBC
Way 42139416667 Buy
ValueDate 42139416667 25/10/2014
MaturityDate 42139416667 25/01/2015
Notional 42139416667 5333581,33
Ccy 42139416667 EUR
CashFlow_1_Date 42139416667 25/10/2014
CashFlow_1_Flow 42139416667 -5333581,33
CashFlow_2_Date 42139416667 25/01/2015
CashFlow_2_Flow 42139416667 5333581,33
Row Key
Column
Family
Column
Qualifier Timestamp Value
GU002_Trade info Counterpart 42139416667 HSBC
Way 42139416667 Buy
ValueDate 42139416667 25/10/2014
MaturityDate 42139416667 25/01/2015
Notional 42139416667 5333581,33
Ccy 42139416667 EUR
GU002_1_CF info Date 42139416667 25/10/2014
Flow 42139416667 -5333581,33
GU002_2_CF info Date 42139416667 25/01/2015
Flow 42139416667 5333581,33
- L’agencement est identique si on utilise des entités individuelles (1row par entité)
- Une seule ROW garantie les écritures et un stockage dans un même HFile
è Performance à la lecture pour les traitements
- Préparation pour persister le blocket limiter les contentions (BulkLoad;BufferedMutator)
- Stratégie à utiliser pour le stockage des stress tests (ex: agrégation des calculs de risque)

25. Consolidated Audit Trail : HBase Versionning
Ref Id Previous
Last
Version
Event EventDate Sender
Order
Book
Way Price Qty
AA001 1127 No Create
13/1/15
10:10
Agent12 GOOG Buy 100 250
AA001 2356 1127 No Decrease
13/1/15
17:59
Agent12 GOOG Buy 1 250
AA001 5467 2356 Yes Increase
13/1/15
18:01
Agent12 GOOG Buy 100 250
RowKey
Column
Family
Column
Qualifier Timestamp Value
AA001 info EventDate 42007969375 13/1/15 10:00
42017690972 13/1/15 17:59
42018475694 13/1/15 18:01
OrderBook 42007969375 GOOG
Sender 42007969375 Agent12
Way 42007969375 Buy
Quantity 42007969375 250
Price 42007969375 100,00
42017690972 1,00
42018475694 100,00
Event 42007969375 Create
42017690972 Increase
42018475694 Decrease
- Traçabilité des événements est obligatoire en Finance;
- Nouvelles réglementations imposent un marquage à la µs pour le HFT avec ±100 µsec de divergence!
- Les Events sont sources d’information pour l’anti-fraude et la connaissance client!
- SGBD: Logique à mettre dans l’applicatif
è Table Historique ou Flag Last Version (SQL Update n’aide pas!)
Agent12 asks for
250 GOOG at
100$ at 10:10am
Agent12
decreases ask
price for GOOG
to 1$ at 5:59pm
Agent12 increases
ask price on GOOG
to 100$ at 18:01pm

26. Pour conclure

27. HBase en Finance: Ce n’est que le début
- « Schema Free » offre de nombreuses possibilités de modélisations pour
répondre aux problématiques traitements/analyses des banques
- Gestion des schémas reste au cœur de la problématique
- Les données financières sont structurées mais sont évolutives et hétérogènes
èBesoin de schéma explicite et dynamique
- Méta modèle versionné pour décrire le modèle et l’associé aux données
- Data Sharding: Cohérence et isolation des traitements
èTimestamp + External consistent transaction log
- Accès aux données : Index secondaire / Search
- As-Of/As-At (bi-temporalité)
SCALED RISK

28. Questions? Merci!
Pierre Bittner - @BittnerPierre