干货 | 携程基于Kafka的数据校验代理在FinOps领域的应用

作者简介

懿涵，携程HybridCloud团队云原生研发工程师，关注云原生、IaC领域。

为了有效管理云成本，基于携程混合多云和自建PaaS为主的现状，混合云团队研发了FinOps计费系统。本文将介绍计费系统基于Kafka构建的接入体系在数据质量与治理方面的挑战，并分享基于自研Kafka Gatekeeper构建度量及治理自助化自动化的实践。

• 一、现状与问题

• 1.1 现状

• 1.2 问题描述

• 1.3 解决方案

• 二、设计与核心实现

• 2.1 Kafka的相关背景知识

• 2.2 Kafka Gatekeeper的设计和实现

• 三、总结

一、现状与问题

1.1 现状

图1-1

如图1-1所示，携程目前使用了混合多云的模式，同时也以自建PaaS服务为主，因此计费系统除了需要从云商获取账单等信息，还需要接入几十种自建PaaS服务的用量信息。其主要结构如下:

1）TripCostAllocationProtocol: 为了计费接入的扩展性，计费系统设计了计费协议，兼容混合多云模式，支持自建及原生PaaS/SaaS服务。

2）计费数据接入：云原生服务统一由计费系统处理，自建服务由各团队按TripCostAllocationProtocol定期打点的方式，将用量信息投递到Kafka中。

3）计费处理：计费系统根据接入的账单、用量以及服务间的关系，进行递归结算，并将结果落到内部数仓。

1.2 问题描述

计费系统上线后，成功为管理层、运营以及研发等角色提供了计费及成本分析的能力。在数据质量上，系统在数仓结果表上创建了对应的检测规则，针对明显违反业务逻辑的数据可以触发告警。但是，随着系统的推广，数据质量的问题仍然居高不下，具体表现如下：

问题发现：

a. 覆盖率低：针对数据错误程度在一定范围内，但仍然符合业务逻辑的问题，无法被检测到。

b. 及时性差：由于检测基于结果表，告警只能针对计费结果，告警结果有滞后性。

问题定位：

a. 效率低：检测是运行在计费系统内部的结果表上，需要多个数据接入方团队及计费系统开发人员共同排查，确定问题发生的源头及原因。

问题治理：

a. 责任不明：由于质量检测基于结果表，但造成问题的源头多样。无法通过对结果的检测直接将问题归属到对应团队，问题无法获得及时的关注与处理。

数据质量是计费系统的生命线，原有系统在质量上的问题导致计费系统开发团队大量的时间被消耗在对质量问题的响应、排查与修复，无法集中精力投入在产品迭代上，也无法应对更多服务的接入。

1.3 解决方案

针对以上问题，我们决定重新构建数据质量治理的能力。目标如下：

问题发现

a. 全问题覆盖：从数据源头出发，所有不符合校验规则的初始数据都可以被发现。

b. 及时性提高：数据异常在进入计费链路之前就可以被发现，而非通过计费结果告警。

问题定位：

a. 提高效率：无需多方团队协调排查，自动捕获问题源头及问题发生的原因。

问题治理：

a. 责任明确：问题产生的当下就告知相关责任人，明确问题治理的对应团队。

通过分析数据质量的案例，发现绝大部分数据质量的问题来自于几十个自建服务数据接入方。根据以上目标的梳理的问题的分析，我们决定引入Kafka Gatekeeper组件，重点解决自建服务接入的质量问题，如图1-2所示。该组件提供以下能力：

1）校验前置：打点数据在进入计费逻辑前，先进行规则校验，保证问题发现及时性。

2）规则可配置：校验规则可随时配置、随时更新，保证规则检测的全覆盖。

3）自助排查：提供自助查询看板，包括数据错误条数，问题发生原因等信息，研发可自助查询对应团队的相关信息，提高问题定位效率。

4）自动告警：检测发现不合规数据（如字段缺失、数据类型错误等）时，向数据来源的团队发送告警，明确问题治理责任。