实时开发场景分析标准化模板

实时指标整个链路开发过程中的一些经验。

分析实时计算是否符合该需求场景，以及在该场景中实时指标能够发挥的价值。

实时计算的输出内容，以及提供的分析能力：OLAP 分析，key-value 实时数据服务，维度填充，数据打标等。

从需求出发，评估实时指标产出的维度和指标的合理性。

评估维度	评估指标
计算数据范围	计算数据范围动态配置改变？
计算起止时间	计算数据的起止时间动态配置改变？
计算数据的某些配置变量	当变量发生变动时，可能会对产出的实时数据有什么影响，对计算链路有什么影响，会决定实时计算链路的实现方式。

评估 SLA 等服务质量等级保障，以及提供的实时数据服务的可用性等级，并且提前和业务方确认可用性和出现故障时的恢复时间等问题。

评估维度	评估指标
时间语义	事件时间、处理时间？事件时间：可以通过获取数据的时间戳，使用处理时间来真实反映和还原事件，但是可能会出现数据条数过小窗口不能触发，或者在一些有截止日期的活动结束的最后一个窗口不能触发的问题；处理时间：处理时间一般和事件时间差距很小，经验值一般 diff 小于 1%，只能反映流式框架处理数据时的时间戳，但是不会出现上述事件时间的两个问题。因此需要评估需求的逻辑精确度是否要求很高？
数据一致性	至少一次、精确一次？至少一次：受限于目前的上下游以及依赖中间件的能力，比如 010 版本及以下的 Kafka 不支持两阶段提交，所以只能达到至少一次的语义；精确一次：整条实时计算链路中的所有组件都需要支持精确一次的语义（从技术层面或者业务逻辑层面达到精确一次）。评估需求逻辑是否可接受任务发生失败时有重复数据产生？
SLA 要求	评估需求的 SLA 要求，整条实时计算链路的 SLA 要求，产出数据最多延迟多长时间？数据准确率几个9？提供的接口服务是否需要考虑跨集群、机房备份、双写；是否需要建立多条计算链路以供故障切换？一旦发生故障，下游消费方能容忍的最大故障时长？下游消费方在发生故障时的兜底策略？

评估维度	评估指标
QPS	确定 QPS 以评估实时上下游以及依赖组件的选型以及能力。
数据输入	首先确定数据输入是否能够计算实时指标，然后评估上游提供的数据在计算实时指标时整个实时计算链路的逻辑以及复杂度。比如：是否需要用到双流 join，需要评估双流 join 所存在的误差是否在可接受范围内，一般可通过离线误差对比或经验值给出结论。常见输入中间件：消息队列，接口等，常用中间件：Kafka，rpc，http。
数据依赖	调研目前可用的哪些中间件可以提供能力来支持当前指标计算？举例：key-value等，常用依赖中间件：Redis。
数据输出	确定输出下游消费方的消费需求以及能力，以评估实时产出的数据以及存储组件是否能够满足其需求？常见输出中间件：消息队列，OLAP，key-value，接口等，常用中间件：Kafka，Druid，Redis，rpc。产出维度，一般场景下，维度值不建议是大数量级别的数据，比如说使用 user_id，device_id。

评估维度	评估指标
QPS	确定 QPS 以评估实时上下游以及依赖中间件的资源消耗。确定资源消耗是否在可接受范围之内？
数据源	确定整个实时计算链路的逻辑以及复杂度，来评估可能的资源消耗。
数据依赖	确定整个实时计算链路的逻辑以及复杂度，来评估可能的资源消耗。
数据汇	由输出内容以及存储组件来评估下游存储中间件的资源消耗。举例：维度值不建议是大数量级别的数据，比如说使用 user_id，device_id 作为维度或者产出明细数据，虽然使用 OLAP 在维度聚合场景下很灵活，但是这些场景下使用 OLAP 可能会造成很大的资源消耗。

综合以上技术和成本可行性以及需求收益等指标，以评估实时指标的 ROI。

最常见的实时数据源就是消息队列日志，首先我们需要确定日志类型，不同的日志类型决定了指标或者维度字段是否可以产出以及其准确性，一般情况下有以下三种类型日志：

日志类型	备注
埋点日志	维度最全，数据准确
web server log	维度次全，数据准确度一般
binlog	数据库真实数据，反映的是真实数据，数据最准确，维度信息一般很少

这里的接口一般是用来根据需求圈定一批需要进行监控的数据内容。接口的提供方式可以是 http，配置中心配置，rpc 接口等。

实时一般情况下都会或多或少依赖到外部组件，最常见的就是 key-value 存储。场景：很常见的一类需求就是对数据源中的数据进行打标然后产出，这里的标签数据就会存储在 key-value 中间件中。需要评估访问外存的 QPS，以及外存提供的能力。

0 人点赞