Menu
What is data mesh? A data mesh is an architectural paradigm and organizational approach for managing and scaling data within an organization. Coined by Zhamak Dehghani, the concept of a data mesh challenges traditional centralized approaches to data architecture and promotes a decentralized and domain-oriented model. Data mesh is maintained and owned and productized by domain experts which is often lacking in the centralized data platforms that are monolithic, and often built around complex pipelines and a centralized data team trying to manage them with no sense of data ownership.
Advantages of data mesh:
Decentralization: Instead of having a single, monolithic data platform managed by a central data team, the data mesh approach advocates for distributing data ownership and management across different teams or domains within the organization. Each team becomes responsible for their own data products.
Domain-Oriented Data Products: The data mesh encourages the creation of domain-oriented data products. These are self-contained, high-quality data sets that are managed by individual teams. Each data product is treated as a standalone product with well-defined interfaces and documentation, making it easier for other teams to discover, understand, and consume the data.
Data as a Product: The data mesh treats data as a product, emphasizing that the data produced and managed by different teams should meet the needs and expectations of their consumers. This requires defining data product teams, setting up Service Level Agreements (SLAs), and ensuring that data products are valuable, reliable, and easy to use.
Federated Architecture: Instead of having a single, centralized data platform, a data mesh employs a federated architecture. It comprises a set of building blocks and standards that allow different data products to be discoverable, understandable, and interoperable. This often involves implementing metadata management, data cataloging, common APIs, and data quality monitoring.
Evolution of Roles: The adoption of a data mesh can lead to the emergence of new roles within an organization. Roles such as Data Product Managers, Data Consumers, and Data Ops Engineers become crucial for managing the lifecycle of data products, ensuring data quality, and facilitating collaboration.
Cultural Shift: Implementing a data mesh requires a cultural shift within the organization. It involves breaking down silos, promoting collaboration between teams, and fostering a data-driven mindset throughout the company.
The data mesh concept aims to address the challenges that arise when traditional centralized data architectures struggle to scale with the growing complexity and volume of data in large organizations. It offers a more flexible, scalable, and agile approach to managing data by empowering domain teams to take ownership of their data and enabling better collaboration across the organization.
Data warehouse:
The concept of a data warehouse is rooted in the traditional assumption that all data are highly structured. It serves as a repository of historical data collected from various subject areas over time, providing an enterprise-wide perspective for analytical purposes. Despite its inception over five decades ago, the evolution of the data warehouse has witnessed the emergence of numerous architectural patterns that dictate its design, management, and maintenance.
During its initial stages, various architectural patterns evolved to define the ideal structure and role of a data warehouse. One pivotal consideration was whether to have multiple data marts feeding into a central data warehouse or a central data warehouse feeding into multiple data marts. This decision largely hinges on factors like data complexity, organizational needs, and analytical objectives. The former approach, involving multiple data marts, offers greater specialization and agility for specific business units, while the latter provides a unified, standardized view of the organization’s data.
Additionally, questions arose about whether a data warehouse should incorporate operational data or real-time data alongside its traditional role as a historical store. This debate revolves around the balance between analytical needs and operational demands. Including operational or real-time data can enhance the organization’s ability to make informed decisions in the present moment, while a purely historical approach maintains the integrity and stability of the data warehouse’s analytical capabilities.
As the data warehouse landscape continues to evolve, the choices made regarding architecture, data inclusion, and integration reflect the ongoing tension between historical depth and real-time agility. Organizations must weigh the advantages of a unified historical view against the benefits of specialized data marts and the real-time insights offered by operational or real-time data integration.
Data Lake: The limitations of big data, the use cases driven by the need to store and process raw data are resolved by collecting and storing raw data in any format using the cloud storage solution is Data Lake. Mostly all cloud vendors are now providing data lake solutions.
Lake House: It is blend of both world Data Lake and data warehouse where one can use the power of structure query processing techniques as well as use single approach to go against any type data in the data lake. Data bricks is a leader in this space.
Data Fabric: Data fabric refers to a unified and integrated approach to managing and accessing data across various locations, formats, and systems within an organization. Again this is not a technology, it’s a concept that aims to provide a cohesive and agile way to handle data in modern, complex data environments. Data fabric technology is designed to address the challenges posed by the increasing volume, variety, and velocity of data generated by organizations.
Over time, the realm of analytics, particularly within structured data, has unveiled challenges with underperforming or less usable data stores. As a result, data engineering teams often undergo multiple iterations to curate data—embracing tasks like data transformation, flattening, denormalization, co-locating, merging, and so on. Considering this context, it remains crucial to explore how the principles of data mesh can lend support and resolution to these issues. Additionally, pertinent questions arise: Can the network efficiently manage the influx of extensive data flow? Must all domains possess equivalent power to ensure high-performing, federated data storage? And what contingencies exist if a data domain isn’t ready when its data is required? Few other challenges includes, data silos, coordination, ownership, accountability, data governance, data duplication/redundancy, and most importantly cultural shift.
In Summary , the idea of data federation isn’t novel. We’ve observed its application through linked tables, proxy tables, service bus, enterprise information integration (EII/EAI), data services layers (DSL), and the like. The hurdles predominantly resided in the technology sphere, not as much in policy or governance. Now, in the era of advanced cloud storage solutions, the feasible realization of a self-serve platform for publishing and consuming data as a product has come to a reality. No doubt data Mesh is a welcoming data management paradigm; however, we have yet to see how the data technology infrastructure can help achieve the true intent of this concept and the challenges listed above. According to Gartner data management hype cycle data mesh is obsolete. Please comment below if you disagree!
Regardless of the evolution of architectural concepts, the principle of treating data as a product and ensuring its quality and accuracy for consumers remains paramount. Would you like to more how RalanTech could help building your data asset with the combination of best practices and best data management principles? Email us: info@ralantech.com
At RalanTech, we firmly believe in the transformative power of technology. We are passionate about leveraging cutting-edge solutions to drive innovation, efficiency, and growth for our clients.
Copyright 2024 | All rights reserved.
Disclaimer: “All trademarks used are the property of their respective owners, and their use here does not imply endorsement.”
