• 体系建设阶段，2019年—至今，即席查询、自助邮件报表、数据报表系统 V3 、 OLAP(CRM) ；子系统互联互通、全面对接指标系统建设标准化指标。

总结后我们发现，业务的快速发展不是借口，这种方式并不快而是痛苦，亟需明确分工，通过平台建设将大量堆积的数据需求转化成用户部分自助。

关键词：分工明确、部分自助

随着业务和数据团队的发展，数据仓库和数据平台建设同样重要，从此分化两个方向，一个是偏向于业务数据的团队，可以将更多的精力放在业务和数据本身以及数仓模型建设上；另一个是偏向于数据平台的团队，将报表、权限等等系统重构并专门负责，有利于将数据平台建设得更加易用，提升用户取数看数分析数效率。因此此阶段除了重构报表系统将报表的配置工作交给用户外，还搭建了自助数据分析系统和 OLAP 系统，进一步提升取数看数分析数的自助率。

1）报表系统 V2

2）自助数据分析

①场景痛点

如下图的界面功能是从 SQL 语法中抽象而来，用户只需点选即可自助完成常规的聚合查询分析。

②整体架构

结合实际痛点分析出有以下必要的诉求点：

针对同时查离线和实时数据的诉求，首先得有个统一的查询入口，然后对亿级别以内量级的数据做数据分析要保障效率，由此可以想到 Impala+Kudu 和 Impala+HDFS（ Parquet ）组合（ Kudu 只存当天的实时数据，离线数据从原有的 HDFS 上读取）。这个方案相对把两类数据都导入到某个其他引擎中，从存储和实现成本上是较小的。

Apache Kudu 是介于 Hadoop 和 Hbase 之间的，既能满足高吞吐量的数据分析需求又能满足快速的数据随机读写需求。基于 Impala 和 Kudu 的系统架构图如下：

3）实时OLAP

业务上出现了两个典型的 OLAP 场景，一个是收益团队需要对历史全量订单，亿级别的数据量进行全维度分析后制定策略，待策略上线后，再进行实时监控成单收益效果，通过多维分析定位到具体哪个渠道、城市、星级等等维度效果不佳，指导及时调整策略。

另一个是酒店业务团队，我们知道用户预定酒店的过程中涉及搜索、列表页、详情页、预定页、成单等主要环节，需要针对各个阶段的业务系统进行实时顺畅度监控，就是将用户每次请求在各个阶段的顺畅度情况实时收集，这个数据量是亿级别的，然后进行多维统计分析和实时监控，有问题能够及时告警甚至需要阻断发布和自动报故障，辅助业务团队定位问题解决问题，提升用户在预定酒店过程的体验感受。

从这些场景中可以提炼出一些关键点：数据实时性要求高，数据量为亿级别，维度指标上百个，数据存储适合大宽表，查询要秒级响应。

①计算引擎

为满足上述诉求OLAP引擎的选择是关键，我们对比当时常用的引擎如下：

通过多种维度的比较，我们最终选择了能支撑亿级别数据量、支持实时数据、在近百个维度指标情况下查询性能依然很高的Apache Druid，来支撑这类实时 OLAP 场景。

②数据可视化

数据可视化方面选择开源的 Superset ，主要原因是其深度支持 Apache Druid，并支持其他众多数据源，能很好的兼容历史数据。Superset 具有较强的数据分析能力，且有丰富的可视化图表类型，另外也支持将图表配置成数据看板，将固化的分析口径以报表的形式呈现。

至此 OLAP 解决方案如下：

4）阶段总结

在此阶段通过明确的分工，将特定资源集中在数据平台建设上，解决了用户大部分取数看数分析数场景的诉求，包括报表配置、自助数据分析、实时 OLAP 等，用户能够通过工具自助获取，不再完全依赖数据开发同学，效率相对有很大的提升；数据开发同学也大大减少了临时性琐碎的取数需求，把更多的精力放到业务本身和数仓建设上。

然而我们面对用户多种多样的诉求，不断投入专门的资源来满足，不断推翻迭代造成资源浪费，这就引发了接下来的BI平台体系化建设。

关键词：多元化、个性化、标准化、体系化

用户的诉求是多样化的，但又不可能都得开发相应的系统来对应满足，伴随以下痛点我们当前需要统筹思考、整体设计、一劳永逸，做体系化建设。

经历之前两个阶段后 BI 平台雏形已现，下图中展示了当前阶段 BI 平台的整体架构概略设计，本文将着重介绍本阶段的建设和实践，接下来分场景模块来介绍。

1）即席查询与自助邮件报表

即席查询在之前基本通过登录客户机或开源的 HUE 来写 SQL 取数，这种方式会面临很多问题，例如权限控制无法很好地保障有数据安全风险、SQL 脚本无法管理随着人员流失就流失掉了、写 SQL 用到的日期变量没有灵活的支持等等个性化需求，因此结合业务诉求搭建了即席查询与自助邮件报表系统。

2）数据报表模块

数据报表模块是迭代的第三个版本，除了贴合业务需求外，我们在重构前需要思考第三版能用多久，带着这个问题提炼出以下原则：

作为数据平台开发同学，以平台建设思维，一次性搭建，将图表组件化。

作为数据开发同学，开发维护好数据模型，基于此可支撑各种口径各种类型图表的配置。

作为产品运营等同学，不必写SQL，通过拖拽，所见即所得。

业务内部管理权限以及数据看板等繁杂事务，完全自助。

①架构设计

离线数据支持从 MySQL 、离线数仓以及指标系统中同步，也支持业务系统的监控数据同步；

实时数据从实时数仓提供的 Kafka 接入，基本是 DWD 层数据；

专门的导数平台，支持离线和实时数据导入到各种存储中；

离线数据导数任务完成后会进行数据校验，失败则告警给导数任务的开发同学以及引用本数据源的图表负责人；

实时数据由 Kafka 导入 ClickHouse 或 Apache Druid 。

根据不同场景选择不同的存储，离线结果数据推荐 PostgreSQL ，数据量大推荐 GP ；实时统计数据存入 Druid ，多维数据分析场景存入 ClickHouse ；

为提升查询效率，离线导数任务成功后，触发引用当前数据源的图表数据刷入缓存中，另外用户自主查询后的结果也都存入临时性缓存；

基于导入的底层数据表，设置维度、指标定义数据模型，根据业务需求抽象合理的模型，这是数据报表模块的核心，也是数据开发同学工作的重点；

可视化图表，提供了常用图表模板近十种类型，基于数据模型可以自由拖拽维度指标；最上层将多图表组成数据看板用于报表展示，支持常用的上卷下钻；对于实时数据大屏场景，通过拖拽也可高效完成。

②自助拖拽配置

针对可视化图表，由前端实现拖拽效果，用户在前端的所有拖拽和配置信息构建成一个 Json 形式的 Config 中，传到后端存储；打开可视化图表时前端获取 Json 形式的 Config ，解析后渲染展示。

自由拖拽实际上是降低了图表配置门槛，提升了配置效率。原报表系统 V2 配置步骤繁杂，大部分还是由数据开发同学配置的，开发工期长。为提升整体效率，首先将此模块抽象成四部分，存储/引擎、数据模型、可视化图表、看板/大屏，上一节已详细介绍过。

其次明确分工，数据开发同学主要做的事情是，根据需求场景将数据引入到合适的存储/引擎中，根据需求内容抽象合理的数据模型，剩下的配置可视化图表和看板皆由产品、运营等自助拖拽完成。

③业务自主管理

各业务整合后面对的用户涉及全司全业务，各业务对报表在组织和权限管理方面差异很大，希望能够独立自主管理，因此我们加入了 BU 的概念，按 BU 从逻辑上完全隔离开，包括导入后的存储和引擎、数据模型、可视化图表、数据看板，以及在权限系统中所有相关的资源。

④亮点功能

作为数据报表系统，除了常规的功能例如看板/大屏、上卷下钻、同环比等之外，还重点支持了以下几个重要的功能点。

对于已有指标 PV、UV，需要二次计算 PV/UV 得出人均浏览次数这种新指标。

针对某个特定（或一批）维度，对任意多个指标设置组合规则进行报警，支持发送报警信息到 Qunar 内部即时通讯 QTalk 和企业微信。

用户在看板中可对某个指标或某个图表，查看上游的血缘信息，包括底表生产信息、底表质检信息、底表接入信息，做到了血缘信息一目了然，提升了数据可信度。数据有问题也方便定位，提升了问题解决效率。

3）OLAP模块

①需求场景

基于原实时 OLAP 模块的升级，以酒店 CRM 系统数据部分为例。每逢节日做活动，运营、销售、管理层等角色的用户，需要在活动期间实时分析所负责酒店在各种维度下的各种数据指标，以便做策略调整和决策。

具体形式如上所示（截取了部分），针对酒店用户任意勾选二十多个维度、近百个指标，要求 3 秒内出结果展示图表。通过对需求的详细分析归纳，得出以下技术挑战点：

②引擎选型

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

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

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

③架构设计

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

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

④场景应用和优化

整个集群部署如上图，访问入口由 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 对应的右表全量数据一定都在本地）来提升查询的整体性能。

4）标准化指标

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

①数据分析场景

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

②数据报表场景

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

5）互联互通

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

QBI 目前服务于 Qunar 全司十几条业务线，整体 MAU 三千，现已形成较为完善的产品矩阵，包括以下场景：

基于公司自研 IM 工具，支持订阅数据看板、交互式数据分析、业务指标监控告警等，随时随地关注业务数据动态。

QBI 各个模块由实际业务需要从历史发展而来，目前虽已形成体系但从抽象的角度来看数据接入层、引擎层、查询层可以合并同类项，抽象出公共的组件化服务，降低维护成本。

目前数据分析模块对事件分析和漏斗分析的支持已比较完善，后续可扩展更多的用户分析场景，例如留存分析、归因分析、分布分析、用户路径分析等等，支撑全业务各种细分场景需求，助力业务决策。