使用AWS实现基于事件驱动的数据网格架构以应对现代数据挑战

在当今的数据驱动世界中，企业必须适应数据管理、分析和利用方式的快速变化。传统的集中式系统和单体架构，虽然历史上足够使用，但已不再能满足需要更快、实时访问数据洞察的组织日益增长的需求。在这个领域，一种革命性的框架是事件驱动的数据网格架构，当与AWS服务结合时，它成为解决复杂数据管理挑战的有力解决方案。

数据困境

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

集中式、单体式、领域无关的数据湖

一个集中式数据湖是所有数据的单一存储位置，这使得管理和工作变得容易，但如果没有适当扩展，可能会导致性能问题。一个单体式数据湖将所有数据处理过程整合成一个集成的系统，这简化了设置，但可能难以扩展和维护。一个领域无关数据湖旨在存储任何行业或来源的数据，提供灵活性和广泛适用性，但可能难以管理，且对特定用途的优化程度不高。

传统架构失败的压力点

在传统的数据系统中，会出现几个问题。数据生产者可能会发送大量的数据或带有错误的数据，从而在下游造成问题。随着数据复杂性的增加和更多不同的来源贡献于系统，中央数据平台可能难以应对日益增长的负载，导致崩溃和性能下降。快速实验的需求增加可能会压垮系统，使其难以快速适应和测试新想法。数据响应时间可能成为一个挑战，导致访问和使用数据的延迟，从而影响决策和整体效率。

运营和分析数据景观之间的差异

在软件架构中，诸如数据孤岛、数据使用不明确、数据管道紧密耦合等问题会引起重大问题。当不同团队在孤岛中工作时，会导致协调问题和低效率。缺乏对数据使用或共享的明确了解会导致重复努力和不一致的结果。耦合的数据管道使得组件之间的依赖过强，难以适应或扩展系统，导致延迟。最后，系统固有的限制会减缓新功能和更新的交付速度，阻碍整体进展。解决这些压力点对于更高效和响应迅速的开发过程至关重要。

大数据的挑战

在线分析处理（OLAP）系统以一种方式组织数据，使得分析师能够更容易地探索数据的不同方面。为了回答查询，这些系统必须将操作数据转换为适合分析和处理大量数据的形式。传统的数据仓库使用ETL（提取、转换、加载）过程来管理这些数据。像Apache Hadoop这样的大数据技术通过解决可扩展性问题并且是开源的，使得任何公司只要能管理好基础设施就可以使用它。Hadoop通过允许非结构化或半结构化数据，而不是提前强制实施严格的模式，引入了一种新方法。这种灵活性使得数据工程师在数据查询过程中可以不必事先定义模式就能写入数据，并在查询时进行结构化，从而使得数据工程师处理和集成数据变得更加容易。采用Hadoop通常意味着需要成立一个独立的数据团队：数据工程师负责数据抽取，数据科学家负责数据清洗和重构，数据分析师负责分析。这种设置有时会导致数据团队与应用开发者之间沟通有限，常常是为了避免影响生产系统。

问题1：数据模型边界问题

分析所用数据与其原始结构紧密相关，这在复杂且经常更新的模型中可能存在问题。数据模型的更改会影响所有用户，使他们容易受到这些变化的影响，尤其是在模型涉及许多表时。

问题2：忽视问题的代价，劣质数据

劣质数据往往在它引起架构问题时才被注意到，导致例如数据类型错误等问题。由于验证通常直到过程的最后阶段才会进行，劣质数据可能会通过管道传播，导致昂贵的修复和不一致的解决方案。劣质数据可能导致重大商业损失，例如计费错误造成数百万损失。研究表明，劣质数据每年让企业损失数万亿美元，浪费了知识工作者和数据科学家大量时间。

问题3：缺乏单一所有权

应用程序开发者通常是源数据模型的专家，但他们通常不会将此信息传达给其他团队。他们的职责往往只限于他们的应用程序和数据库边界。负责数据提取和移动的数据工程师通常是被动工作，对数据源的控制有限。远离开发者的数据分析师面临接收到的数据方面的挑战，导致协调问题和需要单独的解决方案。

问题4：自定义数据连接

在大型的组织中，多个团队可能使用相同的数据，但是各自创建管理数据的流程。这导致了数据的多个副本，每个副本都独立管理，形成了一团糟的局面。跟踪ETL作业和确保数据质量变得困难，从而由于同步问题等因素导致不准确，数据来源也不够安全。这种分散的方法浪费了时间、金钱和机会。

数据网格(Data Mesh)通过将数据视为具有明确模式、文档和标准化访问的产品，解决了这些问题，减少了不良数据风险，提高了数据准确性和效率。

数据网格：一种现代方法

数据网格架构

数据网格通过去中心化所有权和将数据视为产品，并提供自助式基础设施支持，重新定义了数据管理。这种转变使团队能够完全控制自己的数据，而联合治理确保了组织范围内的质量、合规性和可扩展性。

简单来说，它是一种架构框架，旨在通过使用去中心化所有权和分布式方法解决复杂的数据挑战。它用于整合来自各个业务领域的数据，进行综合数据分析。它还建立在强有力的数据共享和治理政策之上。

数据网格的目标

数据网格有助于各种组织深入了解大规模数据,简而言之,处理不断变化的数据环境、不断增加的数据源和用户、需要的各种数据转换以及快速适应变化的需求。

数据网格通过去中心化控制来解决上述所有问题,使团队能够管理自己的数据,而不会被隔离在单独的部门中。这种方法通过分配数据处理和存储来提高可扩展性,有助于避免单一中心系统的速度降低。它允许团队直接使用自己的数据,减少等待中央团队造成的延迟,从而加快了洞察。每个团队都对自己的数据负责,这提高了质量和一致性。通过使用易于理解的数据产品和自助服务工具,数据网格确保所有团队都可以快速访问和管理自己的数据,从而实现更快、更高效的操作和更好的业务需求对齐。

数据网格的关键原则

• 去中心化的数据所有权:团队拥有和管理自己的数据产品,负责其质量和可用性。
• 数据即产品:数据被视为一种产品,具有标准化的访问、版本控制和模式定义,确保跨部门的一致性和易用性。
• 联邦治理:制定政策以维护数据完整性、安全性和合规性,同时仍然允许去中心化的所有权。
• 自助基础设施：团队可以访问支持数据摄取、处理和查询的可扩展基础设施，而不会出现瓶颈或依赖集中的数据团队。

事件如何帮助数据网格？

事件通过允许系统不同部分之间实时共享和更新数据来帮助数据网格。当一个区域发生改变时，事件会通知其他区域，这样每个人都能保持最新，而无需直接连接。这使得系统更加灵活和可扩展，因为它可以处理大量数据并容易适应变化。事件还使跟踪数据的使用和管理变得更加容易，并允许每个团队处理自己的数据，而不依赖其他人。

最后，让我们来看看基于事件的数据网格架构。

这种基于事件的方法允许我们将数据的生产者与消费者分开，随着域随着时间的推移而演变，而无需对架构进行重大更改，从而使系统更加可扩展。生产者负责生成事件，然后发送到数据传输系统。流式平台确保这些事件可靠地传递。当生产者微服务或数据存储发布新事件时，它会存储在特定的主题中。这会触发消费者侧的监听器，如Lambda函数或Kinesis，来处理事件并按需使用。

利用AWS实现事件驱动的数据网格架构

AWS 提供了一系列服务，这些服务完美地补充了事件驱动的数据网格模型，使组织能够扩展其数据基础设施，确保实时数据交付，并保持高水平的治理和安全。

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

AWS Kinesis 用于实时事件流

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

Kinesis 提供了几个组件：

• Kinesis 数据流：同时与多个消费者一起摄取和处理实时事件。
• Kinesis 数据防火墙：将事件流直接传输到 S3、Redshift 或 Elasticsearch 以进行进一步处理和分析。
• Kinesis 数据分析：实时处理数据以获得即时的洞察力，允许在数据处理管道中立即反馈循环。

AWS Lambda 用于事件处理

在数据网格架构中，AWS Lambda 是无服务器事件处理的基础。凭借其自动扩展和无需服务器管理即可处理传入数据流的能力，

Lambda 是理想的选择：

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

AWS SNS 和 SQS 用于事件分发

亚马逊云服务（AWS）简单通知服务（SNS）作为主要的事件广播系统，能够在分布式系统中发送实时通知。亚马逊云服务简单队列服务（SQS）确保在部分系统故障的情况下，解耦服务之间的消息传递是可靠的。这些服务允许解耦的微服务在没有直接依赖关系的情况下交互，确保系统保持可扩展性和容错性。

亚马逊云服务DynamoDB实时数据管理

在去中心化架构中，DynamoDB提供了一个可扩展、低延迟的非关系型数据库，能够实时存储事件数据，因此非常适合存储数据处理管道的结果。它支持Outbox模式，其中应用程序生成的事件存储在DynamoDB中，并由流服务（例如Kinesis或Kafka）消费。
在DynamoDB中。

亚马逊云服务Glue用于联合数据目录和ETL

亚马逊云服务Glue提供了一个完全托管的数据目录和ETL服务，对于数据网格中的联合数据治理至关重要。Glue帮助在分布式领域中编目、准备和转换数据，确保组织内发现、治理和集成的统一性。

亚马逊云服务Lake Formation和S3用于数据湖。

当数据网格架构逐渐远离集中式数据湖时，S3和AWS湖 formation 在存储、保护和编目在不同领域间流动的数据方面发挥着关键作用，确保了长期存储、治理和合规性。

使用AWS和Python实现的事件驱动数据网格实战

事件生产者：AWS Kinesis + Python

在这个示例中，我们使用AWS Kinesis在创建新客户时流式传输事件：

import boto3

import json

​

kinesis = 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 creation

create_customer_event('123', 'ABC XYZ')

事件处理：AWS Lambda + Python

这个Lambda函数消耗Kinesis事件并实时处理它们。

import json

import boto3

​

dynamodb = 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']}")

结论

通过利用AWS服务如Kinesis、Lambda、DynamoDB和Glue，组织可以充分发挥事件驱动数据网格架构的潜力。这种架构提供了灵活性、可伸缩性和实时洞察力，确保组织在当今快速发展的数据景观中保持竞争力。采用事件驱动数据网格架构不仅是技术上的提升，而且是希望在大数据时代和大系统分布式系统时代繁荣发展的企业的战略必需。