每一个大数据团队可能都尝试过市面上许多OLAP工具。以下内容是一个汽车大数据团队对四个OLAP工具的看法，包括优缺点和实际的OLAP经验。

1.1 Apache Druid（和Apache Kylin）

回到2017年，在市场上寻找OLAP工具就像在非洲大草原上寻找树一样——寥寥无几。目光锁定在Apache Druid和Apache Kylin上。首先选择了Druid，而Kylin虽然在预计算查询效率上非常出色，但还是有一些缺点。

Kylin的缺点：

至于Apache Druid，它使用列式存储，支持实时和离线数据摄取，并提供快速查询。

但是Druid也有一些缺点：

尝试TiDB后，它的优缺点如下。

优点：

缺点：

接下来，对比研究ClickHouse和Apache Doris。

ClickHouse出色的独立性能给此团队留下了深刻印象，但经过研究发现它有以下缺点。

相比之下，Apache Doris似乎更符合大数据团队的需求。

总之，Apache Doris似乎是Apache Druid+TiDB的理想替代方案。

下图展示了OLAP系统中数据的流动方式：

2.1 数据源

此团队将业务系统、事件跟踪、设备和车辆的数据汇集到大数据平台。

2.2 数据导入

此团队为业务数据启用CDC，这些数据的任何变化都会被转换成数据流存储在Kafka中，以便进行流式计算。至于只能分批导入的数据，会直接进入分布式存储。

2.3 数据处理

他们采用Lambda架构，而不是集成、流式和批处理。他们的业务现状决定了他们的实时数据和离线数据来自不同的环节，特别是以下几种情况。

2.4 数据仓库

他们没有使用Flink/Spark-Doris连接器，而是采用Routine Load从Flink向Doris传输数据，Broker Load从Spark向Doris传输数据。Flink和Spark生成的批数据会备份到Hive，以满足其他场景的需求，这是提高数据利用率的方式。

2.5 数据服务

在数据服务层，通过数据源注册和灵活配置实现API自动生成，从而可以通过API管理流量和权限。结合K8s无服务器解决方案，整个系统运行得很好。

2.6 数据应用

在数据应用层，此团队有两类应用场景。

和大多数公司一样，此团队也建立了他们自己的客户数据平台（customer>

通常情况下，CDP由以下几个模块组成：

此团队希望在CDP中实现实时+离线集成、快速分组、快速聚合、多表连接和联合查询。下面是具体实现这些功能的方法。

3.1 实时+离线

有实时标签和离线标签，需要将它们结合在一起使用。同时，对于同一份数据的不同列，更新频率也可能不一样。一些基本标签(客户身份相关)需要实时更新，而其他标签(年龄、性别)则可以每日更新。他们希望将客户的所有基础标签放在同一张表中，因为这样可以减少维护成本，并且在添加自定义标签时大大减少所需表的数量。

为了实现这一点，使用Apache Doris的Routine Load方法更新实时数据，使用Broker Load方法批量导入离线数据，还可以利用这两种方法分别更新同一张表的不同列。

3.2 快速分组

分组的本质是将某些标签组合在一起，找到重叠数据。这可能会很复杂，Doris通过SIMD优化加快了这一过程。

3.3 快速聚合

需要更新所有标签，重新计算客户群体分布，并分析效果，这需要快速高效的处理。因此，他们根据时间将数据划分为多个Tablet，以减少数据传输，提高计算速度。在计算客户群体分布时，在每个节点预先聚合数据，然后收集它们进行进一步聚合。此外，Doris的向量化执行引擎也大大提高了性能。

3.4 多表连接

由于此团队的基础数据存储在多个数据表中，因此当CDP用户自定义需要的标签时，需要进行多表连接。Doris出色的多表连接能力是选择它的一个重要因素。

3.5 联合查询

目前，此团队将客户接触相关记录存储在TiDB中，将积分和优惠券等数据也在TiDB中处理，因为TiDB是一个更好的OLTP工具。对于更复杂的分析，如监控客户运营的有效性，需要整合任务执行和目标群体的信息，这就需要在Doris和TiDB之间进行联合查询。

这就是从Apache Druid、TiDB到Apache Doris（中间对ClickHouse进行了短暂的了解）的转变历程，研究了各自的性能、SQL语义、系统兼容性和维护成本，最终形成了现在的OLAP架构。如果你也面临着和此团队类似的问题，这可能会为你提供一些参考。