引文：

本文总结了笔者在阿里、网易以及目前在滴滴实时数仓开发工作中对于技术选型“道”与“术”的一点思考。抛砖引玉，以供参考。

一、道：灵活性与低延迟的对立统一

实时数仓的核心构成，就像离线数仓一样，由计算引擎+存储引擎组成。

计算引擎实现了数据的实时计算。分流式、微批不同计算模式。

存储引擎实现了数据的实时存储和实时查询。分预计算、MPP(大规模并行处理)、搜索引擎等不同存储架构。

计算引擎的选型业界已经基本形成统一（离线Hive、Spark，实时Flink）。相对而言，存储引擎基于不同需求衍生而出的架构百家争鸣。

在我看来，存储引擎的选型主要是这两方面侧重：灵活性和低延迟。

结合我国传统文化的太极阴阳的辩证思维去理解的话，灵活性是阴，低延迟是阳，一阴一阳之谓道，万物负阴而抱阳。不同的存储引擎正是基于不同应用场景，对这两方面进行的不同权衡。

（万物皆阴阳）

具体来讲：

• 侧重灵活性，则需要在查询时对数据进行计算，直接对明细数据进行各种分析查询。当数据量（达PB以上）和计算复杂度增加后，响应时间会变慢，从秒级到分钟级，甚至小时级。

• 侧重低延迟，则需要在入库时对数据进行预计算，通过keyvalue存储结果数据。进一步牺牲灵活性换取性能，以实现对超大数据集的亚秒级响应。

在天猫建设实时数仓时，实时大屏需要较低的查询延迟，而对灵活性的要求相对不高。因此主要选择了侧重低延迟的Flink+Hbase组合，将经过Flink聚合后的结果数据存储到Hbase，提供低延迟的查询。

而在网易严选和滴滴两轮车，业务的灵活性较高，而对查询延迟的相对要求不高。因此选择了侧重灵活性的Tidb、ClickHouse等MPP架构的OLAP引擎，存储的实时明细数据，直接查询明细数据，极大缩短开发周期，提供较高的灵活性。 

二、术：不同技术选型及其应用场景

1. 第一大类：即席查询（查询时计算）

(1). MPP（大规模并行计算）架构

代表：ClickHouse、Tidb、Doris、Presto、Impala

原理：MPP架构是将任务并行的分散到多个服务器和节点上，在每个节点上计算完成后，将各自部分的结果汇总在一起得到最终的结果。

应用场景：有很好的数据规模和灵活性支持，但是对响应时间是没有保证的。当数据量（达PB以上）和计算复杂度增加后，响应时间会变慢，从秒级到分钟级。

(2). 搜索引擎架构

代表：ElasticSearch

原理：基本思路是在入库时创建索引，基于各自的存储模型进行优化，查询时做并行计算。侧重数据规模和灵活性，查询延迟较差，特别是涉及join操作。

应用场景：无schema扩展十分灵活，且支持全文检索。缺点是join支持不友好、查询性能较差、HLL++去重不精确。

2. 第二大类：预计算（入库时计算）

这里说的是广义的预计算，包含借助计算引擎的预计算和存储引擎自身的预计算：

(1). 借助计算引擎的预计算

代表：Flink+Hbase、Flink+mysql、Flink+KV数据库。

原理：Flink计算出结果数据进行落库，若数据量不大直接用mysql存储，若数据量较大（百万级）则用Hbase，若对查询延迟要求极高（微秒级）则用KV数据库。

应用场景：侧重数据规模、查询延时，灵活性差。可实现极低的查询延迟。

(2). 存储引擎自身的预计算

代表：Druid、Kylin。

原理：实时明细导入druid，在入库时对数据进行预聚合、构建cube，通过keyvalue存储结果集。

应用场景：侧重数据规模、查询延时，灵活性差。

三、习：滴滴两轮车冲单期的实时数据实践

子曰：学而时习之，不亦说乎。 掌握道和术之后，还能在适当的时机来实践运用，真是件令人愉悦的事。

10月金秋是两轮车业务的冲单季，在冲单期间急需看到城市当天的用户订单和运维干预的实时数据，以便业务及时进行干预调整。

需求包含多个维度、多种时间统计周期的多个指标。对灵活性的要求较高，且开发时间非常紧张（一周时间）。

因此技术选型上用了更侧重灵活性的ClickHouse。

同时，由于CK多表join的性能限制，尽量在落库前，先通过flink关联维表数据后再写入CK，减少CK查询时不必要的维表关联。

此外，还需要一条离线链路，将历史数据写入ck。一来计算同环比指标需要较早的历史数据，二来当实时链路异常时可以进行快速恢复。

最终得以保质保量地产出4张ck宽表，顺利支撑了两轮车业务冲单期的实时数据需求。

近期文章：《一文教你如何用统计数据去“说谎”》