良好的数据质量是微服务或数据网格等解耦架构中最关键的要求之一。Apache Kafka 成为这些架构的事实标准。但是，Kafka 是一个只存储字节数组的哑代理。架构注册表强制执行消息结构。这篇博文着眼于利用策略和规则的数据协定的增强功能，以在字段级和高级用例（例如将恶意消息路由到死信队列）上强制执行良好的数据质量。
使用 Apache Kafka 实现点对点和意大利面条到解耦的微服务
点对点 HTTP/REST API 创建紧密耦合的服务。数据湖和湖仓一体强制执行单体架构，而不是开放的数据共享和为问题选择最佳技术。因此， Apache Kafka 成为微服务和数据网格架构的事实标准。Kafka 的数据流是对 API、数据湖/湖仓一体和其他数据平台的补充（而不是竞争性！）。
可扩展且解耦的架构，作为单一记录源，用于对实时数据流的高质量自助访问，以及批处理和请求-响应通信。
Kafka 和 ETL/ESB/iPaaS 之间的区别
企业集成比以往任何时候都更具挑战性。IT 的发展需要集成越来越多的技术。公司跨边缘、混合和多云架构部署应用程序。
点对点集成还不够好。MQ、ETL 和 ESB 等传统中间件的扩展能力不够好，或者只能批量处理数据，而不是实时处理数据。集成平台即服务 （iPaaS） 解决方案是云原生的，但只允许点对点集成。
Apache Kafka 是集成项目的新黑板。数据流是一个新的软件类别。
领域驱动设计、微服务、数据网格…
这些方法使用不同的原则和最佳实践。但现实情况是，长寿命和灵活的企业架构的关键是解耦的独立应用程序。但是，这些应用程序需要彼此共享高质量的数据。
Apache Kafka 在这里大放异彩。由于其事件存储，它分离了应用程序。消费者不需要了解消费者。域使用自己的技术、API 和云服务构建独立的应用程序：
不同 Kafka 集群之间的复制可实现跨数据中心和多个云提供商或区域的全局数据网格。但不幸的是，Apache Kafka 本身缺少数据质量功能。这就是 Schema Registry 发挥作用的地方。
Kafka 主题中对良好数据质量和数据治理的需求
为了确保 Kafka 架构中的数据质量，组织需要实施数据质量检查、数据清理、数据验证和监控流程
Kafka 消息中需要良好的数据质量
数据质量对于大多数基于 Kafka 的数据流用例至关重要，原因如下：
- 实时决策：数据流涉及在生成数据时对其进行处理和分析。这种实时性使数据质量变得至关重要，因为基于错误或不完整数据的决策或行动可能会产生直接和重大的后果。
- 数据准确性：高质量的数据确保所流式传输的信息准确可靠。不准确的数据会导致不正确的见解、有缺陷的分析和糟糕的决策。
- 时效性：在数据流中，数据必须及时下发。数据质量差会导致数据传输延迟或中断，从而影响实时应用程序的有效性。
- 数据一致性：不一致的数据会导致处理过程中的混乱和错误。数据流系统必须确保数据遵循一致的架构和格式，以实现有意义和准确的分析。无论生产者或使用者是否使用实时数据流、批处理或与 API 的请求-响应通信。
- 数据集成：数据流通常涉及组合来自各种来源的数据，例如传感器、数据库和外部源。高质量的数据对于无缝集成和确保来自不同来源的数据可以协调进行分析至关重要。
- 法规遵从性：在许多行业中，必须遵守数据质量和数据治理法规。如果不能在数据流处理过程中保持数据质量，可能会导致法律和财务后果。
- 成本效益：数据质量差会导致数据处理和存储效率低下。对低质量数据的不必要处理可能会使计算资源紧张，并导致运营成本增加。
- 客户满意度：应用程序中数据质量受损会直接影响客户，可能导致不满意、失去信任，甚至流失。
Kafka 主题中的规则引擎和策略实施与架构注册表
Confluent 设计了 Schema Registry，用于管理和存储基于 Kafka 的数据流环境中不同系统之间共享的数据架构。来自 Kafka 生产者的消息将根据架构进行验证。
架构注册表为元数据提供服务层。它提供了一个 RESTful 接口，用于存储和检索 Avro、JSON 架构和 Protobuf 架构。它存储基于指定使用者名称策略的所有架构的版本化历史记录，提供多个兼容性设置，并允许根据配置的兼容性设置和对这些架构类型的扩展支持来演变架构。
架构注册表提供了插入 Apache Kafka 客户端的序列化程序，这些客户端处理以任何受支持格式发送的 Kafka 消息的架构存储和检索com/confluentinc/schema-registry#license“ rel=”noopener“ target=”_blank“>Schema Registry 在 GitHub 上根据 Confluent 社区许可证提供，该许可证允许在生产场景中部署，无需许可成本。它成为确保各行各业 Kafka 项目数据质量和治理的事实标准。
强制执行消息结构作为良好数据质量的基础
Confluent Schema Registry 通过在基于 Kafka 的数据流生态系统中充当架构的中央存储库来强制执行消息结构。
以下是 Confluent Schema Registry 如何强制执行消息结构并拒绝无效消息：
- Kafka 生产者生成的数据消息必须遵循已注册的架构。如果消息与架构不匹配，则拒绝消息。此行为可确保仅发布和处理结构良好的数据。
- Schema Registry 甚至 支持使用生产者和消费者中的不同架构版本进行数据互操作性的架构演变。在 Confluent 文档中查找详细说明和限制。
- 架构的验证在架构注册表的客户端进行。对于某些场景来说，这还不够好，例如受监管的市场，在这些场景中，基础设施提供商无法信任每个数据生产者。因此，Confluent 的商业产品增加了代理端架构验证。
数据协定中基于属性的策略和规则
消息架构的验证是很好的第一步。但是，许多用例需要在字段级别进行架构验证和策略实施，即使用自定义规则自行验证消息的每个属性。欢迎使用数据协定：
免责声明：以下 Confluent Schema Registry 加载项仅适用于 Confluent Platform 和 Confluent Cloud。如果您使用任何其他 Kafka 服务和架构注册表，请将此解决方案作为构建数据治理套件的灵感 – 或迁移到 Confluent ：-）
数据协定支持各种规则，包括数据质量规则、字段级转换、事件-条件-操作规则和复杂架构演变。查看 Confluent 文档“架构注册表的数据协定”，了解所有详细信息。
Kafka 消息的数据协定和数据质量规则
如 Confluent 文档中所述，数据协定指定并支持协议的以下方面：
- 结构： 这是架构所涵盖的协定部分，用于定义字段及其类型
示例：使用死信队列强制执行加密和错误处理的 PII 数据
其中一种内置规则类型是 Google Common Expression （CEL），它支持数据质量规则。规则可以强制执行良好的数据质量或对属性（如信用卡号）进行加密：
您还可以配置高级路由逻辑。例如，错误处理：如果表达式 “size(message. id) == 9” 未经过验证，则流式处理平台会将消息转发到死信队列，以便使用以下配置进行进一步处理： "dlq. topic": "bad-data"。
死信队列 （DLQ） 是一个复杂（但非常重要）的话题。
数据合约作为新数据流产品以及与 Apache Flink 集成的基础
Schema Registry 应该是任何 Kafka 项目的基础。数据 协定在独立微服务之间强制执行良好的数据质量和互操作性。每个业务部门及其数据产品都可以选择任何技术或 API。但是，与他人共享数据只有在良好的（强制）数据质量下才有效。
无论您是否使用 Confluent Cloud，您都可以从 SaaS 产品中了解架构和数据合同如何实现数据一致性并加快创新上市时间。数据目录、数据沿袭、Confluent 流共享或与无服务器 Apache Flink 的开箱即用集成等产品依赖于具有架构和数据协定的良好内部数据治理策略。
您是否已经在 Confluent 环境中利用了数据协定？如果您不是 Confluent 用户，如何解决数据一致性问题并实现良好的数据质量？让我们 在LinkedIn上联系 并讨论它！
