点击上方蓝字关注我们

    在当今数据驱动的世界中，企业必须适应数据管理、分析和利用方式的快速变化。传统的集中式系统和单片式架构虽然在历史上已经足够，但已无法满足企业日益增长的需求，因为企业需要更快地实时获取数据见解。事件驱动数据网格架构是这一领域的革命性框架，与 AWS 服务结合后，它将成为应对复杂数据管理挑战的强大解决方案。

许多组织在依赖过时的数据架构时都面临着巨大的挑战。这些挑战包括

 集中式数据湖是所有数据的单一存储位置，易于管理和访问，但如果扩展不当，可能会导致性能问题。单体数据湖将所有数据处理流程整合到一个集成系统中，简化了设置，但可能难以扩展和维护。与领域无关的数据湖旨在存储来自任何行业或来源的数据，具有灵活性和广泛的适用性，但管理起来可能比较复杂，对特定用途的优化程度也较低。

在传统数据系统中，可能会出现一些问题。数据生产者可能会发送大量数据或有错误的数据，从而给下游带来问题。随着数据复杂性的增加和系统中数据来源的多样化，集中式数据平台可能难以应对不断增长的负载，导致系统崩溃和性能缓慢。快速实验需求的增加可能会使系统不堪重负，难以快速适应和测试新想法。数据响应时间可能会成为一个挑战，导致访问和使用数据的延迟，从而影响决策和整体效率。

 在软件架构中，孤岛式所有权、不明确的数据使用、紧密耦合的数据管道以及固有的局限性等问题都可能导致重大问题。当不同团队各自为政时，就会出现各自为政的情况，从而导致协调问题和效率低下。对如何使用或共享数据缺乏清晰的认识，会导致工作重复和结果不一致。耦合的数据管道，即组件之间过于依赖，会使系统难以调整或扩展，从而导致延误。最后，系统固有的局限性会减缓新功能和更新的交付，阻碍整体进展。解决这些压力点对于提高开发流程的效率和响应速度至关重要。

在线分析处理 (OLAP) 系统组织数据的方式使分析人员更容易探索数据的不同方面。为了回答查询，这些系统必须将操作数据转换为适合分析和处理大量数据的格式。传统的数据仓库使用 ETL（提取、转换、加载）流程来管理这些数据。Apache Hadoop 等大数据技术通过解决扩展问题和开放源代码改进了数据仓库，只要能够管理基础设施，任何公司都可以使用。Hadoop 引入了一种新方法，允许使用非结构化或半结构化数据，而不是预先执行严格的模式。这种灵活性使数据工程师更容易处理和整合数据，因为数据可以在没有预定义模式的情况下写入，并在以后的查询过程中进行结构化。采用 Hadoop 通常意味着组建一个独立的数据团队：数据工程师负责数据提取，数据科学家负责数据清理和重组，数据分析师负责数据分析。由于数据团队与应用开发人员之间的沟通有限，这种设置有时会导致问题，通常是为了防止影响生产系统。

 用于分析的数据与其原始结构密切相关，这对于复杂且经常更新的模型来说是个问题。数据模型的更改会影响所有用户，使他们容易受到这些更改的影响，尤其是当模型涉及许多表时。

 错误数据通常不会被注意到，直到它在模式中产生问题，导致错误数据类型等问题。由于验证通常会推迟到流程的最后阶段，因此不良数据会在管道中传播，导致昂贵的修复费用和不一致的解决方案。不良数据会导致重大业务损失，例如造成数百万美元损失的计费错误。研究表明，不良数据每年会给企业造成数万亿的损失，浪费知识工作者和数据科学家的大量时间。

 应用程序开发人员是源数据模型方面的专家，但他们通常不会将这些信息传达给其他团队。他们的责任往往止于应用程序和数据库边界。数据工程师负责管理数据提取和移动，但他们通常是被动工作，对数据源的控制有限。数据分析师与开发人员相距甚远，他们在接收数据时面临挑战，从而导致协调问题，并需要单独的解决方案。

 在大型企业中，多个团队可能使用相同的数据，但却创建各自的流程来管理这些数据。这就会产生多个数据副本，每个副本都独立管理，造成混乱。由于同步问题和数据源不安全等因素，跟踪 ETL 作业和确保数据质量变得十分困难，从而导致数据不准确。这种分散的方法浪费时间、金钱和机会。

       可以解决这些问题，它将数据视为一种产品，具有清晰的模式、文档和标准化访问，从而降低了不良数据风险，提高了数据准确性和效率。Data Mesh 是一种分布式数据架构，旨在解决传统集中式数据架构面临的挑战。它将数据视为一个产品，由不同的团队负责特定领域的数据治理和管理。

数据网格重新定义了数据管理，它将所有权下放，并将数据视为一种产品，由自助式基础设施提供支持。这种转变使团队能够完全控制其数据，同时联合治理确保了整个组织的质量、合规性和可扩展性。简单地说，它是一种架构框架，旨在通过使用分散所有权和分布式方法来解决复杂的数据难题。它用于整合来自不同业务领域的数据，以进行全面的数据分析。它还建立在强大的数据共享和治理政策之上。

数据网格可帮助各种组织大规模地深入了解数据，简而言之，就是处理不断变化的数据环境、日益增多的数据源和用户、所需的各种数据转换，以及快速适应变化的需求。

数据网格通过分散控制解决了上述所有问题，因此团队可以管理自己的数据，而无需将数据隔离在不同的部门。这种方法通过分散数据处理和存储来提高可扩展性，有助于避免单一中央系统的运行速度减慢。它允许团队直接处理自己的数据，减少了因等待中央团队而造成的延误，从而加快了洞察力的提高。每个团队对自己的数据负责，从而提高质量和一致性。通过使用易于理解的数据产品和自助服务工具，数据网格可确保所有团队都能快速访问和管理自己的数据，从而提高运营速度和效率，更好地满足业务需求。

• 领域导向：将数据管理责任分配给领域团队，促进对数据的深入理解和责任感。
  
  

• 自服务平台：提供工具和平台，支持团队独立处理数据，而无需依赖中央数据团队。
  
  

• 数据作为产品：将数据作为产品对待，采用标准化的访问、版本和模式定义，每个领域团队将其数据视为产品，关注数据质量、可发现性和易用性。
  
  

• 跨域互操作性：确保不同领域的数据能够有效交互和集成，促进整体数据生态的协同工作。
  
  

• 分散的数据所有权： 团队拥有并管理自己的数据产品，对其质量和可用性负责。
  
  

• 联合治理： 制定政策以维护数据完整性、安全性和合规性，同时仍允许分散所有权。
  

• 大规模组织：在大型企业中，各个部门可能会产生大量数据，Data Mesh 允许不同团队独立管理数据，避免了传统架构中的瓶颈。
  
  

• 敏捷开发：支持敏捷开发模式，领域团队可以快速迭代，提供高质量数据产品，满足快速变化的业务需求。
  
  

• 多样化数据源：随着数据源的多样化，Data Mesh 提供灵活性，让团队能够根据特定需求选择和管理数据源。

• 金融行业：某金融机构实施 Data Mesh，将信贷、风险管理、客户数据等领域的团队赋权，使他们能够独立管理和使用数据，从而提高了决策的速度和准确性。
  
  

• 电商平台：一个大型电商平台通过 Data Mesh 实现了各个产品线的数据独立管理，促进了个性化推荐系统的优化，提升了用户体验。

Data Mesh 通过分散数据管理，提高了数据治理的灵活性和响应速度，适用于需要快速适应变化和处理复杂数据环境的组织。通过将数据视为产品，Data Mesh 鼓励团队主动管理数据，提升数据的价值和可用性。

架构设计

• Data Mesh：强调分散化和领域导向的数据管理。数据被视为产品，由各个业务领域团队负责管理和维护。每个团队独立处理其领域的数据，促进快速响应和创新。

• Data Lake：通常是一个集中式的存储系统，用于存储各种格式的原始数据（结构化、半结构化和非结构化数据）。数据湖的设计目的是将所有数据集中存储，以便于后续分析和挖掘。

数据治理

• Data Mesh：鼓励领域团队对其数据负责，强调自服务和透明性。每个团队负责确保其数据的质量、可用性和安全性，同时提供清晰的文档和接口，便于其他团队使用。

• Data Lake：通常由中央数据团队负责数据治理。数据湖中的数据治理可能会较为复杂，尤其是在数据集成和数据质量管理方面，容易出现“数据孤岛”现象。

数据处理和访问

• Data Mesh：支持灵活的数据访问方式，团队可以根据业务需求快速发布和更新数据产品，促进跨团队协作和数据共享。

• Data Lake：数据处理通常是批处理或流处理的结合，用户需要一定的技术能力来提取和分析数据，可能需要依赖数据科学家或工程师进行数据准备和分析。

适用场景

• Data Mesh：适合大型、复杂的组织，尤其是在不同业务部门有独立数据需求和创新能力时。它能够支持快速变化的业务需求和灵活的团队结构。

• Data Lake：适合需要集中存储大量数据的组织，特别是在数据分析和机器学习等应用场景中。它可以作为数据分析和挖掘的基础。

Databricks 的Data Mesh架构

ConfluentCloud事件数据流

事件允许系统的不同部分实时共享和更新数据，从而帮助实现数据网格。当某一区域发生变化时，事件会通知其他区域，因此每个人都能及时了解最新情况，而无需直接连接。这使得系统更加灵活和可扩展，因为它可以处理大量数据并轻松适应变化。事件还能让我们更轻松地跟踪数据的使用和管理情况，让每个团队都能处理自己的数据，而无需依赖他人。

最后，让我们来看看事件驱动的Data Mesh架构：

通过这种事件驱动方法，我们可以将数据生产者与消费者分离开来，从而使系统随着领域的不断发展更具可扩展性，而无需对架构进行重大改动。生产者负责生成事件，然后将事件发送到在途数据系统。流平台可确保这些事件的可靠交付。当生产者微服务或数据存储发布一个新事件时，它会被存储到一个特定的主题中。这会触发消费者端的监听器（如 Lambda 函数或 Kinesis）来处理事件并根据需要使用它。

 AWS 提供的一整套服务完美地补充了事件驱动数据网格模型，使企业能够扩展其数据基础架构，确保实时数据交付，并保持高水平的治理和安全性。

以下是各种 AWS 服务如何融入此架构：

 在事件驱动的数据网格中，实时流是一个关键因素。AWS Kinesis 提供了大规模收集、处理和分析实时流数据的能力。

Kinesis 提供多个组件：

Kinesis 数据流：接收实时事件并与多个消费者并发处理这些事件。
Kinesis Data Firehose：将事件流直接传送到 S3、Redshift 或 ElasticSearch，以便进一步处理和分析。
Kinesis 数据分析：实时处理数据，即时获得洞察力，实现数据处理管道中的即时反馈回路。

用于事件处理的 AWS Lambda
AWS Lambda 是数据网格架构中无服务器事件处理的支柱。它能够自动扩展和处理传入的数据流，无需服务器管理、

Lambda 是以下方面的理想选择：

实时处理 Kinesis 数据流
针对特定事件调用 API 网关请求
与 DynamoDB、S3 或其他 AWS 服务交互，以存储、处理或分析数据

 AWS Simple Notification Service (SNS) 是主要的事件广播系统，可在分布式系统间发送实时通知。AWS Simple Queue Service (SQS) 可确保解耦服务之间的消息得到可靠传递，即使在部分系统故障的情况下也是如此。这些服务允许解耦的微服务在没有直接依赖关系的情况下进行交互，确保系统保持可扩展性和容错性。

 在分散式架构中，DynamoDB 提供了一个可扩展、低延迟的 NoSQL 数据库，可实时存储事件数据，是存储数据处理管道结果的理想选择。它支持 “发件箱 ”模式，即应用程序生成的事件存储在

存储在 DynamoDB 中，然后由流服务（如 Kinesis 或 Kafka）消费。

 AWS Glue 提供全面管理的数据目录和 ETL 服务，对于数据网格中的联合数据治理至关重要。Glue 可帮助对分布式域中的数据进行编目、准备和转换，确保整个组织的可发现性、治理和集成。

 在数据网格架构脱离集中式数据湖的同时，S3 和 AWS Lake Formation 在存储、保护和编目各个域之间流动的数据、确保长期存储、治理和合规性方面发挥着至关重要的作用。

事件生产者：AWS Kinesis + Python
在本示例中，当创建新客户时，我们使用 AWS Kinesis 对事件进行流式处理：

import boto3import jsonkinesis = boto3.client('kinesis')def send_event(event):kinesis.put_record(StreamName="CustomerStream",Data=json.dumps(event),PartitionKey=event['customer_id'])def create_customer_event(customer_id, name):event = {'event_type': 'CustomerCreated','customer_id': customer_id,'name': name}send_event(event)# Simulate a new customer creationcreate_customer_event('123', 'ABC XYZ')

此 Lambda 函数消耗 Kinesis 事件并对其进行实时处理

import jsonimport boto3dynamodb = boto3.resource('dynamodb')table = dynamodb.Table('CustomerData')def lambda_handler(event, context):for record in event['Records']:payload = json.loads(record['kinesis']['data'])if payload['event_type'] == 'CustomerCreated':process_customer_created(payload)def process_customer_created(event):table.put_item(Item={'customer_id': event['customer_id'],'name': event['name']})print(f"Stored customer data: {event['customer_id']} - {event['name']}")

    如果您了解开源并想要构建和管理自己的解决方案，请考虑使用诸如 data.all 之类的开源框架。Data.all 是一个现代数据市场，支持不同用户之间的协作。Data.all 简化了数据发现、共享和精细的数据访问管理，而构建者则使用数据和 AWS 分析服务组合。下图显示了基于 data.all 的数据网格参考架构

架构图包含以下组件：

1. 数据生产者在 data.all 前端提供的目录中发布数据产品。data.all 的前端和后端托管在中央治理账户中。
2. 数据使用者（用户）使用其单点登录或 Amazon Cognito 凭证登录 data.all 前端。他们可以浏览目录并搜索自己感兴趣的数据产品。他们可以筛选搜索结果。
3. 属于消费者团队的数据用户找到他们感兴趣的数据产品后，他们可以请求访问数据。Data.all 有一个内置的访问管理工作流程，数据所有者可以使用该工作流程来审查和批准访问请求。
4. 消费者团队可以利用这些数据来增强他们的 AI/ML、分析和报告以及 ETL 用例。

      通过利用 Kinesis、Lambda、DynamoDB 和 Glue 等 AWS 服务，企业可以充分发挥事件驱动数据网格架构的潜力。这种架构具有敏捷性、可扩展性和实时洞察力，可确保企业在当今快速发展的数据环境中保持竞争力。对于希望在大数据和分布式系统时代蓬勃发展的企业来说，采用事件驱动数据网格架构不仅是技术上的提升。