去哪儿网BI平台建设演进与实践

1. 数据看板作为资源接入统一的权限系统进行管理

2. 离线导数任务通过调度系统周期调起任务

3. 各层均有系统性能监控，时刻关注平台性能状态

4. 用户使用平台的行为通过埋点记录，用于掌握用户使用情况，尤其是对无人访问的看板做下线参考

5. 支持图表和看板嵌入到第三方系统，目前已嵌入机酒业务多个平台中

2.3.4.2.引擎选型

引擎选型调研 ES、Presto、Kylin 在前面对比过结论是不适用当前场景，本次选型主要对比了在用的 Apache Druid、Impala 和新增的 Apache Doris、ClickHouse。

对 Impala、Doris、ClickHouse 三种引擎做 Benchmark ，保证相同的数据表（需求相关的真实数据和量级）和相同的 SQL（按需求实际需要编写），在各个引擎上做了简单的测试（Impala 用 Parquet，ClickHouse 用 MergeTree 表引擎），查询多次取均值结果如下：

通过直观的性能对比结果，ClickHouse 的查询性能表现很好，另外实际测试发现随着查询指标数量的增多对 ClickHouse 的性能影响也并不是很大，再结合我们的实际场景需求（主宽表查询，带小表 Join ）、硬件条件、开发成本以及业界经验综合对比，ClickHouse 成为了不错的选择。

2.3.4.3.架构设计

数据写入

离线数据通过导数平台的 Waterdrop 从 Hive 中导入ClickHouse；实时数据通过导数平台 ClickHouse 的 Kafka   Engine从Kafka 中实时消费，再由物化视图将数据实时写入 MergeTree 的单机表，然后基于此建分布式表。

数据读取

用户在页面上任意勾选想要看的维度和指标，提交查询到数据查询服务，然后解析、拼装查询 SQL ，提交到 ClickHouse 执行 SQL ，最后拿到结果数据返回到前端页面展示成图表。

2.3.4.4.场景应用和优化

整个集群部署如上图，访问入口由 Nginx 做负载均衡， CHProxy 代理用于管理集群用户、限制并发、设置请求超时等，而集群的大部分分布式功能，则需要通过 ZooKeeper 来完成。结合 CRM 项目本身诉求以及性能要求设计了两种表，整体原则是充分利用 ClickHouse 的单机计算性能强的优势。

第一种分布式表，通常用来存储指标数据和关联用的维度字段（如日期及酒店维度字段加到订单流量数据），这种表通常数据量很大（ TB 甚至 PB 级别），需要用多台机器分散存储。分布式表需要设置 Sharding Key 来决定，由于涉及到查询优化，Sharding Key 最好是对应场景中出现频率最高的查询维度（比如日期），这样能够保证 Group By 的时候同一组维度数据一定在同一台物理机上，然后通过修改配置 distributed_group_by_no_merge=1 将所有的聚合转成本地操作，避免了额外的网络开销，提升查询性能。

第二种单机表，通常用来存储非静态的维表，这类维表包含随时间更新的维度（比如酒店星级，HOS 分等），需要在查询的时候取维表数据和主表进行 Join 操作。通过设置一表多备的方式，我们让每一台机器都持有全量且一致的维表数据，这样在Join的时候就可以将 Shuffle Join 优化成 Local Join （因为每一个 Join Key 对应的右表全量数据一定都在本地）来提升查询的整体性能。

2.3.5.标准化指标

基于 OneData 方法论，数仓建模通过指标系统最终产出的是标准化指标，定义和统一口径，数仓同学为标准化指标数据负责。QBI 各个模块从指标系统中获取标准化数据，或分析或展示，以保障所有人看到同一个指标时数据是一致的，从根源上进一步提升了数据可信度。具体关系的细节如下图所示。

2.3.5.1.数据分析场景

数据分析模块引入指标系统管理的 DIM 表、DWD 表明细数据，获取指标系统构建的原子指标、复合指标、派生指标信息，用户在进行事件分析时可自由选择来自指标系统的标准化指标，实际查询相应底层的明细表进行分析，使用效果如下图所示。

2.3.5.2.数据报表场景

指标系统产出的标准化ADS表，通过导数平台导入数据报表模块，然后根据指标系统里定义的维度指标自动生成数据模型，基于此可实现自由拖拽可视化报表配置看板，相反在看板的图表里可以查看底表和指标的来源信息，使用效果如下图所示。

2.3.6.互联互通

QBI 已形成多个模块的全场景数据消费形态，但模块之间并不是割裂的反而是互联互通的，而且关系非常紧密，围绕标准化的指标系统为核心如下图所示。