近实时指标管理在流利说的实践
目录：
背景
工程实践
指标的生产与维护
调度与计算
展望
1. 背景
流利说离线数仓开发维护中，数仓工程师扮演了维护数仓公共层明细与维表的角色，更上层直接面向需求方的数据由分析师进行计算。不同于离线指标计算，实时指标在计算逻辑之外的部分更加复杂，这对分析师等不擅长开发而又希望进行灵活数据分析的角色很不友好。基于此背景，数仓开发了一套近实时指标管理系统。
2. 工程实践
近实时指标的整体数据流图如下
指标查询整体流程：
业务库数据和日志数据等全部集中于 Kafka； Flink SQL 消费 Kafka 数据到 Hudi 的 COW (Copy On Write) 类型表中； 近实时指标系统按照规则发送 Job 到 Trino 服务； Trino 服务查询 Hudi 表得到结果。
3. 指标的生产与维护
3.1 配置指标基础信息
数据源准备完成后，分析师们可以直接使用 Trino SQL 配置汇总指标的计算逻辑。对于公共的数据清洗逻辑，可以由数仓编写视图再由指标编写者引用。
除了计算逻辑外还需要配置更多指标信息以方便数据的使用者理解数据，包括：
指标单位； 指标标签； 所属域； 业务过程； 计算口径； 其他额外扩展信息。
如果是非分析师用户想要配置指标时，还需要由创建者来指定审核人进行指标合理性的确认。
完成基础信息配置后还可以选择设置指标的初始化开始日期以追溯历史数据。
整体指标信息如下图：
指标完成配置并上线后会根据计算逻辑为每一个指标产生一个唯一的 code，这个 code 可以被引用并通过 Aviator 表达式计算生成复合指标，生成的复合指标又可以继续被其他的复合指标所引用。
示例：
--汇总指标
SELECT COUNT(DISTINCT xxx)
FROM DB.TABLE
WHERE xxx
--复合指标
${3gdlYrl7} / ${FMxGYvw3}
3.2 指标血缘
这样一系列的指标引用关系便可以生成指标的血缘，当在指标监控中发现异常指标值时便可以根据血缘找出问题数据，如下图：
3.3 指标可视化
每一个指标可由创建者为其配置查看权限信息，拥有查看权限的用户可以自定义关注的指标、列表的顺序和选择标注颜色，并进行灵活的数据分析，如下图：
3.4 指标 Q&A
有指标查看权限的的用户若在指标的使用过程中对其有疑问，可以在指标的问答页面添加问题，创建者可根据情况回答问题并向所有人展示以减少沟通成本，如下图：
3.5 配置告警信息
创建者在指标正式上线后可以使用 Aviator 表达式和预先提供的前 N 日同期数据占位符来配置指标告警。当表达式计算结果小于0时系统触发告警，并通过创建者预先配置的告警方式（邮箱、 webhook 等）方式向指定人发送告警。
4. 调度与计算
近实时指标计算任务每 5 分钟触发一次，每小时计算的结果覆写本小时的计算结果，计算结果保存至 MySQL 供用户查询。每次完成计算后再将数据一次性写入数据库，防止先后写入造成查询时短时不一致现象。
完成计算后触发调度结束 Trigger，开始告警处理。
在发生数据重跑或新增指标补数据情况时，会向补数据监控线程提交一次重跑任务，监控线程会获取监控补数据任务提交情况并执行。
5. 展望
目前的缺点也很明显，近实时数据的公共层没有落盘，这会导致当多个指标拥有相同的明细清洗逻辑时造成计算性能的浪费。未来可以在指标上传合并调度时对计算 SQL 进行语法解析，将有着相同底层数据清洗逻辑的 SQL 进行合并计算，上层差异的部分分开计算并最终合并起来生成新 SQL ，参与合并的指标最后再在合并后的新 SQL 计算结果中取出自己的一部分。