快手统一分析服务建设实践

01

分析领域介绍

分析服务发展历程

分析服务 3.0 建设实践

• 标准指标中台+BI，形成快手特色 BI。
• 统一分析+低代码，构造了数据应用工厂，可以短而快地构建数据应用产品。
• 两套引擎分别提供了开放能力。统一分析引擎提供了统一分析语言 OAX，即快手的分析表达式；统一查询引擎，抽象出了统一查询语言 FQL，即联邦查询语言。

• 首先是数据解耦，业务无需关心底层数据，降低物理数据和上层应用的耦合。
• 第二是效率提升，包括消费效率的提升，一处定义的数据集可以在多处使用；分析效率的提升，对于一些符合的指标计算，以及高级分析，无需对物理数据再进行重复加工；还有生产效率的提升，由一处定义数据集，避免重复加工。
• 第三是质量提升，统一指标的定义加工和消费，从源头保证指标数据准确。

• 智能缓存
  智能缓存是通过智能预热来实现的。一般查询缓存是在查询过后，缓存这个结果，便于提升下次同一查询的速度。但是这存在一个问题，就是无法解决首次查询慢的问题。之前的版本中通过人工配置和周期性的预热来触发查询，以解决首次查询慢的问题。但是覆盖场景较少，主要针对大屏或者可视化的大屏看板，其他场景不支持。另外，这种对于天级别的数据，分钟级别的预热可能会造成一些不必要的资源浪费。数据准确性也难以保证，可能出现数据更新不及时，会预热缓存一些不准确的结果。并且预热没有处理限流的管控能力。
  智能预热通过三个执行器，即触发器、计算器和执行器，来解决上述问题。其中，触发器支持触发式预热。比如通过消费元数据，变更事件能及时预热，避免天级数据、分钟级数据的频繁更新问题。第二是覆盖了更多场景，根据比较 Top 的查询来支持更多的场景。第三是执行性方面，增加了相关的执行限流和管控，以及降级等操作。一个是持续分片处理，还有一个是指标维度。分片处理过后，会把相应的结果缓存起来。缓存数据主要包括三个粒度，一个是整体查询缓存，一个是时序缓存，还有一个指标维度的分片缓存。
• 模型物化
  第二块是通过模型物化来进行数据加速。主要解决大表或多表交换场景下查询慢或查询失败的问题。模型物化分为三个阶段，一个是分析阶段，主要是找出可以加速的查询模型。第二是加速阶段，根据查询模型，得到要生产加速的元数据提供给自动化生产底座，生产完得到一些小表，并反注射到模型里进行模型更新。第三是应用阶段，主要是参与模型构建和筛选，以便小表可以在下次查询中被命中，进而解决查询慢以及查询失败的问题。
  
• 查询优化
  第三，通过查询优化实现数据加速。分析引擎侧主要是面对查询。如上图所示，输入OAX 分析源，通过解析得到一个 AST 抽象语法树。同时抽象语法树内部会进行两阶段处理，一是分析编排，针对高级分析能力，比如 LOD 粒度计算以及同环比，进行编排处理。二是模型构建，之前处理的都是一层数据集，需要进行模型的二次计算得到逻辑层，即 AST。接下来将 AST 转换成逻辑计划。这个逻辑计划根据物理编排得到物理计划，最终输出 FQL。整个语言的解析是基于 Calcite 来实现的。
  
  下面详细介绍三个阶段的优化。首先是分析编排的优化。这个优化主要解决的是比如前面提到的高级分析能力，LOD 粒度计算等问题。我们之前的实现会拆成多个物理子查询下载到引擎，查询完会对这些子查询的结果在内存里面进行二次加工计算。在数据量较大的情况下，会面临两个问题，首先数据计算不准确，由于物理查询限制了返回结果，因此无法做到全局排序；其次是大数据量导致整个处理性能会比较慢。因此我们针对分析编排进行了下推优化。从之前下推到多个物理子查询，进行视图抽象。经过后续模型构建处理，下推到引擎得到一个大的产品，避免了多次物理子查询。
  第二块是构建优化模型。模型构建主要分为两个步骤，一个是模型筛选，一个是模型展开。针对模型筛选我们做了一系列优化，如果模型涉及到多张表，会选择一些就续时间比较早的。有些表可能是热引擎，有些表可能是冷引擎，我们会优先选择热引擎的表。同样，针对不同的粒度，有一些维度粒度比较粗，有些粒度比较细，我们会优先选择粒度比较粗的小表。针对模型展开构建优化，一方面是事实维度，组合条件整体下推。另一方面是针对事实维度表通过关联键进行相应的一些过滤条件下推，还有子查询消除。
  第三块是基于 Calcite 实现优化。Calcite 自身支持的优化规则也比较多，有几十种。常见的比如位次下推，会把过滤条件下推到数据源，减少读取函数。还有列剪枝，过滤掉不需要的列。除了基于自身的一些规则之外，我们还扩展了一些优化规则。比如 groupby bitmap 来替换精确系统的查询实现。另外，还通过 local query 这种模式来进行优化。

总结和展望