企业数据碎片化，Kafka作为共享开放平台，解耦源与目标，实现数据实时流与批处理，提升重用性，加速应用集成与创新，通过实体构建器模式渐进式现代化。
译自：How Kafka Simplifies Application Integration and Modernization
作者：Matthew O’Keefe
在企业中，应用程序执行业务流程，并通常以副作用的形式创建数据。传统的业务报告使用这些数据来提供财务洞察，并帮助改进流程和产品。但应用程序数据往往是碎片化的，分散在复杂的企业应用程序系统中。此外，从应用程序数据库或其所在的SaaS服务中提取数据可能很困难。
企业应用程序数据碎片化为不相连的孤岛。
个人用户和数据工程师通常会为特定用例构建定制的、批处理式的数据管道。这些应用程序数据孤岛和管道之间的碎片化、重复和不一致性阻碍了数据共享和重用。
锁定在单个应用程序中而无法与其他应用程序共享的数据，与可以在企业范围内轻松共享的数据相比，更难重用。共享数据可以成为新改进的应用程序、服务和产品的可重用构建块。这有助于更好的决策制定，改进业务流程和产品设计，并降低风险。
需要一种方法将企业应用程序数据迁移到一个集中式、共享的开放平台，该平台能够：
- 将源与目标解耦以降低复杂性。
- 存储可轻松被现有和新应用程序重用的共享数据。
- 利用共享数据作为事件来驱动应用程序行为。
- 将共享数据与现有应用程序数据源集成。
- 根据需要允许以实时流、历史批处理或两者兼有的方式访问共享数据。
- 通过利用简单、可重复的数据共享用例，在短时间内实现更多的重用。
与Kafka集成的企业数据。
Kafka是你所需要的集中式、共享、开放平台
数据架构师正在寻找被广泛使用、经过验证且开源或基于开源协议的共享、实时、事件驱动的开放数据平台。
Apache Kafka将数据源与目标解耦，消除了点对点集成复杂性。生产者将事件发布到主题，无需了解消费者，而消费者独立订阅，从而消除了直接依赖关系以及修改应用程序的需要。主题成为事件驱动应用程序和分析的构建块。
Kafka的事件驱动、发布-订阅模型允许团队添加或更改数据流，而无需触及源系统或现有管道。相比之下，REST API更加同步，需要与应用软件更紧密的集成。这可能会增加开发时间和风险。
作为拥有庞大连接器和工具生态系统的开源软件，Kafka支持企业范围的标准化，允许任何团队或应用程序以更少的定制集成或供应商锁定来共享和重用数据。
Kafka将数据作为不可变日志持久存储，将瞬态事件转化为现有和未来应用程序可访问的可重用构建块。通过可配置的保留策略，主题可以保留完整历史记录或最新时间窗口，从而支持新系统上线或从故障中恢复时的重放。
遗留的ERP系统也可以通过使用Kafka Connect流式传输订单事件来进行分析、欺诈检测或新的AI服务，而无需从源重新提取数据。这种共享的、持久的数据层打破了孤岛，并将应用程序数据转化为企业资本，随时可进行广泛共享和重用。
Kafka可以同时提供实时流和历史批处理访问，并通过使用简单、可重复的用例提高数据可重用性。实时消费者为仪表盘或警报提供支持。Kafka可以将数据移动到像Apache Iceberg这样的开放湖仓，用于报告和分析。
数据重用越快，新项目启动的速度就越快。通过使用预构建的连接器，可以快速部署数据库同步到搜索索引或将日志馈送到安全工具等快速成功案例。这些低风险、高影响力的模式可预测地扩展，降低集成成本并加速创新，包括AI实验和部署，所有这些都无需进行基础设施改造或颠覆性应用程序变更。
数据架构师如何使用Kafka进行应用程序集成
数据架构师可以使用Kafka进行应用程序集成、现代化和演进。一些公司正在使用一种简单的模式来实现这一点，称为实体构建器。
实体代表业务领域中的一个“名词”（例如客户、订单、产品、员工、部门、发票）。它是唯一的，由一组属性描述，并在系统中独立或依赖地存在。业务流程围绕实体、它们的关系和属性构建。
应用程序将实体及其关系存储在数据库中。在公司收购或新SaaS应用程序上线后，同一个实体（例如客户）分散在多个应用程序中是很常见的。合并应用程序通常是不切实际的。相反，架构师让每个应用程序将其操作专门化到特定的流程或服务，但使用Kafka来构建一个集中式日志，允许共享通用实体。
如果实体是“客户”，每个应用程序将其所有“客户”记录保存到一个主题，并记录对这些记录所做的任何更改。这些更改可以馈送到一个简单的事件驱动微服务，或者你可以编写或扩展一个单体应用程序来处理它。理想情况下，你预先做了一些数据建模工作，以确保业务所有者、数据工程师和开发人员对“客户”是什么以及客户在每个应用程序中拥有的属性达成一致。但是你不需要做大量的数据建模就可以开始并获得价值。
简单数据建模以支持数据解放
首先考虑简单的用例。召集应用程序所有者，围绕对“客户”实体的共同理解构建数据模型。他们需要识别并就“客户”是什么达成一致。听起来很简单，对吧？但事情很快就会变得复杂，你需要在开始设计工作之前尽可能精确地记录下来。
你的应用程序所有者可能不愿考虑共享他们的数据。如果劝说应用程序所有者合作不奏效，那就找一位高级主管，向他推销可以推动进展的业务效益。指出通过Kafka系统共享这些信息所带来的业务价值和机会可能会有所帮助。
例如，在金融服务行业，假设我们有银行、信用卡、投资和支付四个应用程序。为了更好地理解这些应用程序中“客户”实体的含义，数据建模过程可能会提出以下问题：
- 哪些客户标识符（社会安全号、出生日期、护照号）在应用程序之间共享，并且对每个客户来说都是唯一的？
- 与唯一标识符关联的哪些信息可以用于创建跨所有应用程序客户实体的连接主键？
- 哪些属性在特定应用程序之外最有用，应该被非规范化并与客户实体共享？
- 哪些客户信息可以提高其应用程序的业务影响力？
- 根据隐私、安全和合规性要求，哪些共享信息应该受到保护，防止不当访问？
- 在为数据模型开发派生或聚合值时，请确保值和维度计算一致。
通过Kafka共享的已解放应用程序“客户”实体。
一旦你有了共享数据模型和对客户实体的理解，你就可以根据这个共享模型从每个应用程序创建Kafka主题。然后可以将这些流连接起来，以便两个或更多的流，每个公司一个，都包含客户ID，并根据手头的用例使用特定的列/属性选择。这是一个例子，说明数据建模过程如何也包含了你希望用于下游应用程序的物化视图。它还展示了事件驱动数据集成支持新用例的能力，通过解放的数据实现。
简单应用程序开发，渐进式变更
对于“客户”而言，你可以检测任何变化（新地址、余额变化、新支付等），并生成一个事件到另一个微服务来处理该特定变化（向其他应用程序广播地址更新、根据新地址生成优惠、合规性相关工作等）。
这是一个简单的入门方法。
但请确保将项目完成到底。然后评估哪些地方做得对，哪些地方做得不对。用户请求中是否有因为事件模型或数据产品中缺少某些内容而无法满足的模式？最大的实现挑战是什么？你选择了正确的数据产品吗？你是否以符合消费模式的方式对事件进行了情境化？下一个可以在数据流中外部化并可能为现有数据流（在我们的案例中是“客户”）增加价值的实体是什么？
这种数据解放方法避免了更改像遗留应用程序或其数据模型这样的单体。你可以继续将其用于操作，但围绕它进行现代化。
它让你能够立即开始构建事件驱动的应用程序，简单但有用的应用程序。而且，应用程序之间的实时数据共享也成为可能。
结论
将新数据集成到现有成熟的应用程序中从来都不是一件容易的任务。但Kafka提供了解决此问题的机制，它使用强调共享和可重用性的构建块。
通过Kafka跨应用程序共享事件数据的简单行为，无需昂贵或复杂的应用程序更改即可创造业务价值。它提供了利用可重用数据构建块逐步实现企业数据现代化的机会。
