1.
Change is the new normal

2.
Digital Integration Hub per il monitoraggio in near-real time della
logistica: il caso Arcese
CONFLUENT
Data In Motion Tour 2022
Milano

3.
Confluent Kafka
● Investimento sia tattico che strategico.
● Strategico: nuova piattaforma di gruppo “A-Platform”.
● Tattico: possibilità di trasformare il nostro sistema legacy in un sistema “event-driven”.
Transport and Logistics Industry
● Mercato frammentato ed altamente competitivo.
● Bassi margini.
● Servizi visti dai clienti come una “commodity”.
Arcese
● Sviluppo di una piattaforma interna che permetta di rispondere alle sfide di business.
● Basata su un nuovo data model che possa rappresentare tutte le declinazioni di ordine di trasporto che ci
inviano i clienti, senza perdita di informazioni.
● Tra i suoi pillar c’è quello di Orchestration (Kafka).

4.
Challenge
● Richiesta da parte del mercato di “real time visibility”.
● Tempi lunghi tra l’inserimento del dato e la sua disponibilità per successive elaborazioni.
Paradigm
● Il tempo tra l’inserimento del dato e la sua disponibilità deve essere di 5 minuti massimo.
Project Scope (Velocity)
● Trasformare un sistema legacy in un sistema “ad eventi”.
● Lavorando a livello di singola transazione sul database.
● Sfruttando tecnologie moderne di pub/sub (Kafka).

5.
Arcese Track&Trace data pipeline
Actual: il “data journey” può arrivare
a 30’.
New Track&Trace: mediamente
passa 1 minuto dalla produzione
del dato alla sua pubblicazione sul
T&T.

6.
Chi siamo?
Mauro Luchetti
Data Architect
mauro.luchetti@quantyca.it
Siamo un’azienda di consulenza tecnologica italiana specializzata
in data e metadata management.
Realizziamo data platform capaci di gestire l’intero ciclo di vita
del dato, dall'acquisizione fino ad arrivare all’utilizzo sia per finalità
analitiche (BI e AI) che operative (service integration), passando
per tutte le fasi intermedie di consolidamento.
La partnership con Confluent è sempre stata un punto di forza
nella realizzazione di architetture Event Driven.
quantyca.it

7.
Update, Insert, Delete
Entità Coinvolte
TMS
Transportation
Management System
Ordine di
Trasporto
Viaggio
Unità di
Movimentazione
Note
Merci
Pericolose
…
Addebiti
Eventi
Attività
Fermate
Tratte
…
Track & Trace
Stato Ordine
Posizione
dell’Unità di
Movimentazione
Eventi di
Tracking

8.
Problemi architettura AS-IS
Alta latenza verso gli applicativi consumatori del dato, siano essi a finalità
analitiche o operazionali. Per mantenere competitività nel mercato è necessario
pensare a soluzioni Real Time.
L’offloading del dato porta ad avere carico sul sistema sorgente.
Difficoltà nello sviluppo di nuove integrazioni, la messa in produzione di nuovi
servizi necessari al business richiede tempo ed è difficilmente scalabile.
Difficile gestione della Governance, l’accesso al database applicativo non è
univoco.
sistemi
gestionali
storage
operazionale
dati fruibili a
sistemi target
flussi batch

9.
Digital Integration Hub
System of Engagement System Of Insight
System of Records
Legacy
Systems
Application
Layer
Digital
Integration
Hub
Data Gateway
Event-Based Integration Layer
Workload Specific Data Stores
Microservices
Metadata Management
● Layer di Integrazione basato su Eventi
● Storage ad alte performance, sia in ottica di
lettura che di ingestion del dato, con tecnologie
specifiche in base ai casi d’uso
● Insieme di Microservizi cooperanti tra loro per
ricostruire le viste necessarie agli applicativi
● Forte disaccoppiamento tra chi produce e chi
consuma il dato, grazie alla presenza di un Data
Gateway
● Raccolta dei Metadati utili ai fini di avere un
processo di Governance ben definito

10.
Velocity
Legacy Confluent Cloud
Technical
Events
(Speed &
Fidelity)
Domain
Events
(Trusted
Views)
Business
Events
(Ease of
consumption)
Consumers
Data Science
Models
Microservices
Data Driven
Services
Reporting & SelfBI
Kafka
Stream
Kafka
Stream
Access Data Store
Governance
Data Quality Data Lineage Glossary Data Catalog
Analytical
Storage
Graph DB
Operational
Storage
Data Lake

11.
Gestione della Consistenza: Sfide
CONSISTENZA TRANSAZIONALE: Sia il sistema sorgente che
quello target sono costituiti da RDBMS. La consistenza nelle
entità lette è garantita dalla transazionalità, ad è necessario
mantenerla pur avendo nel mezzo Kafka, un sistema non
transazionale.
CONSISTENZA DI ORDINAMENTO: Gli aggiornamenti al
modello devono necessariamente essere eseguiti in modo da
sovrascrivere solo gli stati più aggiornati. Nel caso di viste
aggregate complesse sul sistema sorgente è facile che gli
eventi vengano elaborati in modo non ordinato all’interno di
Kafka.
CONSISTENZA STORICA: Deve sempre essere possibile
ricreare le entità target in qualsiasi momento e senza perdita
di informazione. Kafka permette di avere retention infinita nei
topic ma non sempre questa soluzione è percorribile o
adeguata.
Topic Kafka
Target
Read
Model
Source
Aggregate

12.
Gestione della Consistenza: Soluzioni
Technical
Events
(Speed &
Fidelity)
Domain
Events
(Trusted
Views)
Kafka Streams
Ecosystem
Buffering
Events
Closing
Transactions
Transactions
Metadata
Confluent Cloud
Unified Data Model
Buffering Layer
Business Events
(Ease of consumption)
Fast Storage
Integrità Transazione
Real Time Processing
Kafka Stream (Stateful)
Ordinamento /
Storicizzazione
Batch & near RT
processing
Spring Batch
✓ Soluzione Stateful che garantisce forte consistenza
✓ Fast Storage è un DB SQL compliant, facile integrazione
con le altre tecnologie e conoscenze aziendali
✓ Gli Eventi di Business possono essere arricchiti anche con
informazioni esterne
CDC
Governance

13.
Governance
Data Product
Unified Data Model
Legacy Confluent Cloud
Technical
Events
(Speed &
Fidelity)
Domain
Events
(Trusted
Views)
Business
Events
(Ease of
consumption)
Consumers
Data Science
Models
Microservices
Data Driven
Services
Reporting & SelfBI
Kafka
Stream
Kafka
Stream
Access Data Store
Data Quality Data Lineage Glossary Data Catalog
Analytical
Storage
Graph DB
Operational
Storage
Data Lake
Source aligned Consumer aligned
TMS Trip
(LTL)
TMS
Transport Order
(LTL)
Trip Execution
Transport Order
Management &
Tracking

14.
Open Data Mesh
Obiettivi
L’obiettivo del progetto Open Data Mesh è quello di
realizzare una piattaforma che permetta tramite una
serie di servizi implementati sia a livello di data product
experience plane che a livello di infrastructure utility
plane di gestire l’intero lifecycle di un data product a
partire dal deployment atomico fino ad arrivare alla
dismissione.
Principi
● Declarative
● Tech independent
● Standard agnostic
● Composable through templating
● Flexible in adoption
● Easily extensible
Componenti
● Data Product Descriptor Specification
● Open Data Mesh Platform (Core)
● Open Data Mesh Platform (Adapters)
In sintesi
Data Product Experience Plane
Data Product
Container
Data Product
Meta
App & Infra
Templates
Data Product Descriptor
/Create /Build /Deploy /Connect
Build
Descriptor
Deployment
Descriptor
/PolicyService /MetaService /BuildService /ProvisionService /IntegrationService
Infrastructure Utility Plane
Customer Infrastructure
Tech.
Independent
Adapters
Open Data
Mesh
Platform

15.
Takeaway
Il monitoraggio dell’Ordine di Trasporto e la sua esecuzione nell’ambito LTL è passato da decine di minuti a pochi secondi.
I servizi consumatori non sono più costretti nella rappresentazione dei dati presente sul sistema sorgente, ma leggono da
uno Unified Data Model che rispecchia al meglio i concetti di business.
L’architettura introdotta gestisce alti volumi di dati in real time grazie all’estesa distribuzione di calcolo.
I sistemi sorgenti vengono totalmente scaricati da operazioni di elaborazione dei dati, si effettua offloading verso Confluent
e si collegano dunque i diversi consumatori del dato.
I costi di integrazione si riducono notevolmente, il dato prodotto al fine di essere condiviso è uniforme, non ambiguo e di
qualità certificata, rendendolo facilmente estendibile e scalabile.
A tutti i livelli dell’architettura è possibile raccogliere metadati sempre più necessari ai fini dei processi di governance.
Gestire la transazionalità all’interno di Kafka non è un’operazione semplice, soprattutto quando si
parte da sistemi relazionali e si hanno modifiche a più entità che costituiscono un unico evento di dominio.

16.
Corso Milano, 45 / 20900 Monza (MB)
T. +39 039 9000 210 / F. +39 039 9000 211 / @ info@quantyca.it
www.quantyca.it