利用 AWS 的事件驱动数据网格架构应对现代数据挑战

背景

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

数据困境

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

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

传统架构故障压力点

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

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

大数据带来的挑战

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

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

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

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

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

Data Mesh数据网格

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

Data Mesh现代方法

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

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

适用场景

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

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

Databricks 的Data Mesh架构

ConfluentCloud事件数据流

事件如何帮助Data Mesh？

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

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

国內基于Kafka案例

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

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

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

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

Kinesis 提供多个组件：

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

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

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

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

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

用于实时数据管理的 AWS DynamoDB
在分散式架构中，DynamoDB 提供了一个可扩展、低延迟的 NoSQL 数据库，可实时存储事件数据，是存储数据处理管道结果的理想选择。它支持 “发件箱 ”模式，即应用程序生成的事件存储在
存储在 DynamoDB 中，然后由流服务（如 Kinesis 或 Kafka）消费。

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

用于数据湖的 AWS Lake Formation 和 S3
在数据网格架构脱离集中式数据湖的同时，S3 和 AWS Lake 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 DataZone架构

data.all

如果您了解开源并想要构建和管理自己的解决方案，请考虑使用诸如 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 用例。

基于DataMesh实时同步场景

数据血缘

结论

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

---

今天先到这儿，希望对云原生，技术领导力， 企业管理，系统架构设计与评估，团队管理, 项目管理, 产品管理，信息安全，团队建设 有参考作用 , 您可能感兴趣的文章:
构建创业公司突击小团队
国际化环境下系统架构演化
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变

如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。