Enabling a Data Mesh Architecture and Data Sharing Culture with Denodo
•
0 j'aime•123 vues
Watch full webinar here: https://bit.ly/3wATS7b Data Mesh presents a new distributed and decentralized paradigm for data management, where autonomous domains expose their own data as "data products" to the rest of the organization. It tries to reduce bottlenecks derived from an excessive dependance on centralized IT teams, and capitalizes on the specialized data knowledge that domain users already have. However, Data Mesh literature leaves the implementation of these ideas very open to each organization. Watch on-demand and learn: - Deep dive into the key ideas of Data Mesh - Understand how Denodo can help you implement a Data Mesh - Hear directly from a Denodo client, Landsbankinn, their journey from a traditional analytic architecture to Data Mesh using Denodo
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Enabling a Data Mesh Architecture and Data Sharing Culture with Denodo
Similaire à Enabling a Data Mesh Architecture and Data Sharing Culture with Denodo (20)
Plus de Denodo
Plus de Denodo (20)
Dernier
Dernier (20)
Enabling a Data Mesh Architecture and Data Sharing Culture with Denodo
- 3. ▪ ▪ ▪ ▪ ▪
- 4. ▪ ▪ ▪ ▪ ▪ ▪
- 10. ▪ ▪ ▪ ▪ ▪ ▪
- 13. ▪ ▪ ▪ ▪
- 14. ▪ ▪ ▪ ▪ ▪ ▪
- 16. ▪ ▪ ▪ ▪
- 17. ▪ ▪ ▪ ▪ ▪ ▪ ▪
- 18. ▪ ▪ ▪ ▪
- 19. ▪ ▪ ▪ ▪ ▪ ▪ ▪
- 20. ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪
- 21. ▪ ▪ ▪ ▪ ▪ ▪ ▪
- 22. ▪ ▪ ▪ ▪ ▪ ▪ ▪ ▪
- 26. Landsbankinn 26 • Leading financial institution in Iceland • 40% Market share Individual Banking • 33% Market share Corporate Banking • Best ESG risk ratings amongst European banks (Sustainalytics 2021) • Best bank at the Icelandic consumer satisfaction ratings (Ánægjuvogin / Stjórnvísi 2021)
- 27. SAS environment Year Zero - Before Data Virtualization 27 ▪ Too many query points ▪ Heterogenous technologies ▪ Complex source systems ▪ Scattered business rules ▪ Semantic layers in BI ▪ Business logics in DB views ▪ Many points of access control ▪ Audit points all over the place ▪ Each system has its own access control KPI DB Source DBs New DWH Old DWH Markets DB Views BO reporting Self-service BI PDF statements MS Office Integration Views Views Views General Reporting KPI Self-Service data Analytics Reports Analytics Server Risk Reporting Monitoring / Audit Business security Business rules Board Other DBs SAP BO Semantic Layer Data Sources Semantic Layer
- 28. Year 1 - The Logical Data Warehouse ▪ Unique point of query ▪ “Need data? LDW has the answer!” ▪ For reporting, analytics, APIs, … ▪ Unique point of truth ▪ Business logic repository ▪ Lineage available ▪ Unique point of access control ▪ Unified access to the data ▪ Unique point of auditing KPI DB Source DBs New DWH Old DWH Markets DB BO reporting Self-service BI MS Office Integration General Reporting KPI Self-Service data Analytics Reports Analytics Server Risk Reporting Board Other DBs Data Sources Logical Data Warehouse w/ Denodo Monitoring / Audit Business security Business rules PDF statements
- 29. Years 2 and 3 - Expansion and Modernization 29 ▪ Addition of data consumers ▪ Tableau ▪ REST / Restful APIs ▪ Addition of more data sources ▪ Where ETL is not required ▪ When history is provided in source ▪ Logical data pipelines ▪ Reduces the number of ETL jobs ▪ EDW gets data from LDW BO Reporting Tableau RestWS to Excel General Reporting KPI Self-Service data Analytics Reports Analytics Server Risk Reporting Board Data Sources Logical Data Warehouse w/ Denodo KPI DB Source DBs New DWH Old DWH Markets DB Other DBs Flat files Excel SaaS REST SOAP WWW Customers Domains Operational systems Monitoring / Audit Business security Business rules Customer statements
- 30. Year 4 - A flawed model 30 ▪ Source data is cryptic ▪ Data comes from software vendors ▪ Lots of meetings needed to establish the data mapping ▪ Domains know their source ▪ How to find data in the source ▪ When source changes ▪ Domains resort to creating views in the source ▪ Loss of lineage and governance ▪ What we wanted to get rid of in the first place LDW Source DBs Domains Operational systems Views
- 31. Year 4 - Implementing a Data Mesh model 31 ▪ A simplified process 1. Domains provided with a development space 2. LDW developers combine views 3. Domains publish data 4. Operational systems access the data ▪ Top-down modelling ▪ Using interface views (data contracts) Source system Base Data Mesh Domain A developer Business systems LDW developer LDW Requests (interface contracts) Shares Combines LDW Source DBs Operational systems Domains Domain B developer Requests (interface contracts) Publication Data Mesh Publishes LDW
- 32. Year 4 - Benefits of the Data Mesh w/ Denodo 32 ▪ Delegate the ownership of data to the domains ▪ Data is in the hands of its creator ▪ Give better overview of the pipeline ▪ Views lifecycle managed by the source developer ▪ Reduce data pipelines ▪ Fewer ETL jobs when available LDW Source DBs Operational systems Domains Savings domain Loans domain Cards domain Claims domain EDW domain LDW developer CRM Loan Online bank
- 33. 33 KPI DB New DWH Markets DB Other DBs Flat files SaaS REST SOAP WWW Source DBs Customers Risk Reporting Business Board ▪ Data Mesh conquers the bank ▪ Self-service for business ▪ Data API Year 5 - What lies ahead Logical Data Warehouse w/ Denodo API Self- Service Self- Service Self- Service Data Mesh Data Mesh Data Mesh Data Mesh Data Mesh Data Mesh Data Mesh Data Mesh Data Mesh Op. Systems Data Mesh