哔哩哔哩数据服务中台建设实践( 三 ) _中台

离线场景：离线数据获取，一般访问原始hive数据源即可。
（2）API构建

文章插图
API构建方式有两种：一种是通过模型构建，这是一种可视化的配置方式，用户已经明确知道要对某一个模型进行数据服务化，不需要用SQL编码，通过拖拉拽的方式就可以配置出来。另一种是基于指标维度的构建，指标维度构建是在模型构建的基础上的一种更高级模式，用户无需实现指定模型进行构建，可以先配置请求参数及返回参数，系统根据管理的模型元数据信息，按照一定的规则自动筛选出可以服务化的模型列表并给出推荐优先级。
数据查询：

文章插图
下面介绍数据查询的能力，整体分为五个步骤。
步骤1：一个查询的DSL信息如下图图所示。解析的过程是把DSL信息与API配置进行匹配，并得出本次数据请求需要的模型。

文章插图
步骤2：任务拆分是把解析的结果拆成子任务查询，解决异构数据源的结果获取问题。因为一次查询中可能会从多个模型中获取，模型也可以在多个引擎或集群中。为保证结果的的准确获取及查询效率，我们采用了拆分子任务的方式进行并发数据查询，子任务的查询结果经过二次加工处理返回。
步骤3：结果处理器是一个内存计算器，负责把子任务的查询结果进行拼接、排序、分页及格式转换等，返回统一格式的数据结果，让下游无感知数据的处理过程。
步骤3-1：翻译模块是把子任务的查询信息翻译成对应引擎可以识别的sql语法。AST是abstract syntax tree的缩写，也就是抽象语法树。翻译模块区别于引擎对执行SQL进行语法树解析的过程，而是逆向从构建AST开始，并最终翻译成SQL的过程。构建AST的算法如下图所示：

文章插图
第一层AST从下面的"SELECT"开始，第一层语法树是构建出本次查询需要用的有效数据，包括构建模型关系、模型字段的筛选及数据范围的筛选
第二层AST从上面的"SELECT"开始，第二层语法树是基于第一层构建的有效数据，进行运算表达式计算，如 sum，count(distnct ..)，sum(case when then end)，sum()/count() 等其他一些自定义语法表达式。
通过两次的AST构建，可以完整表达一次原子计算所需的数据获取逻辑。根据构建的AST，系统会各个引擎的查询特性及方言，优化查询语法，提升查询性能，最终转化成可被引擎识别的查询SQL 。
步骤3-2：引擎层负责执行各个子任务的查询SQL，系统适配了目前公司内部多种数据引擎，包括自研KV、TiDB、Mysql、ClickHouse、Iceberg等。除接入不同的引擎连接协议，在不同引擎的连接方式上也做了优化，如：mysql、tidb 由单次短连接改为连接池，减少连接的频繁创建及销毁带来的开销问题；自研KV多可用区连接，扩大在线服务可用的服务范围；OLAP引擎如ClickHouse、Iceberg的超时自取消功能，减少服务占用及降低引擎压力等。
三、数据服务中台实践方案1、全链路管控在数据服务中台实践中，最重要的是实现全链路管控，让数据在服务化的过程中做到统一定义、统一生产、统一消费。

文章插图
统一定义：口径不易维护的原因之一是管理不统一，散落在各个地方，导致大家没有统一的视角管理及查看口径。我们的的解决方案是口径统一在指标平台管理，其中把指标的定义及模型的定义解耦。指标定义是对分析对象的业务过程进行描述，计算方法的定义约束，可在数据模型建设之前确定，一般有数据产品角色实施；模型定义是根据数据需求及指标定义进行构建生产，模型中指定了模型字段与指标的关系，决定了模型中哪些字段可以生产哪些指标，一般有数仓开发角色实施。通过把指标定义与模型定义解耦，减少了不同角色间的沟通成本，让口径的定义可以延续到数据生产中。
统一出口：口径不易维护的另外的一个原因是定义与生产分离，出口不可控。我们打通了指标的定义及生产流程：模型的出仓可以自动化完成，出仓过程中的计算逻辑是基于指标平台中的定义自动生成的，减少了人工的干预，避免定义与生产的不一致；其次，API的取数逻辑非人工定义，也是基于指标定义，自动翻译取数逻辑及路由计算引擎，避免生产与消费过程中的不一致。通过定义与生产的打通，生产与消费的打通，数据流通过程中完全基于统一的定义，达到了最终的定义与消费的一致性。