每一个大数据团队可能都尝试过市面上许多OLAP工具。以下内容是一个汽车大数据团队对四个OLAP工具的看法，包括优缺点和实际的OLAP经验。
一、将讨论的OLAP工具
- Apache Druid（和Apache Kylin）
- TiDB
- ClickHouse
- Apache Doris
1.1 Apache Druid（和Apache Kylin）
回到2017年，在市场上寻找OLAP工具就像在非洲大草原上寻找树一样——寥寥无几。目光锁定在Apache Druid和Apache Kylin上。首先选择了Druid，而Kylin虽然在预计算查询效率上非常出色，但还是有一些缺点。
Kylin的缺点：
- Kylin的最佳存储引擎为HBase，但引入HBase会带来新的运维负担。
- Kylin会预计算维度和指标，但它带来的维度爆炸会给存储带来很大压力。
至于Apache Druid，它使用列式存储，支持实时和离线数据摄取，并提供快速查询。
但是Druid也有一些缺点：
- 不使用标准协议如JDBC等，因此对初学者不太友好。
- 对Join支持较弱。
- 精确去重可能较慢，从而影响性能。
- 由于组件众多，需要各种安装方法和依赖，因此需要大量维护工作。
- 数据摄取时需要改变Hadoop集成和JAR包依赖。
1.2 TiDB
尝试TiDB后，它的优缺点如下。
优点：
- 是一个支持轻松更新的OLTP+OLAP数据库。
- 具有大数据团队需要的功能，包括聚合和分组查询、指标计算和仪表板。
- 支持标准SQL，易于掌握。
- 维护要求不高。
缺点：
- TiFlash依赖OLTP，可能给存储带来更大压力。作为非独立OLAP，分析处理能力并不理想。
- 性能在不同场景下的表现参差不齐。
1.3 ClickHouse与Apache Doris的比较
接下来，对比研究ClickHouse和Apache Doris。
ClickHouse出色的独立性能给此团队留下了深刻印象，但经过研究发现它有以下缺点。
- 在多表Join方面无法满足团队的需求(这是一个重要使用场景)。
- 并发性相对较低。
- 会带来较高的运维成本。
相比之下，Apache Doris似乎更符合大数据团队的需求。
- 支持高并发查询，这是大数据团队最大的关注点。
- 能够同时处理实时和离线数据。
- 支持聚合和分组查询。
- Unique模型(Doris中的一种数据模型，可确保键的唯一性)支持更新。
- 可以通过物化视图大幅加速查询。
- 兼容MySQL协议，开发和使用都很顺畅。
- 查询性能满足需求。
- 运维要求简单。
总之，Apache Doris似乎是Apache Druid+TiDB的理想替代方案。
二、OLAP实践经验
下图展示了OLAP系统中数据的流动方式：
图片
2.1 数据源
此团队将业务系统、事件跟踪、设备和车辆的数据汇集到大数据平台。
2.2 数据导入
此团队为业务数据启用CDC，这些数据的任何变化都会被转换成数据流存储在Kafka中，以便进行流式计算。至于只能分批导入的数据，会直接进入分布式存储。
2.3 数据处理
他们采用Lambda架构，而不是集成、流式和批处理。他们的业务现状决定了他们的实时数据和离线数据来自不同的环节，特别是以下几种情况。
- 部分数据以流的形式出现。
- 部分数据可以存储在流中，而部分历史数据不会存储在Kafka中。
- 某些场景需要高数据精度，为此有一个离线管道可以重新计算并刷新所有相关数据。
2.4 数据仓库
他们没有使用Flink/Spark-Doris连接器，而是采用Routine Load从Flink向Doris传输数据，Broker Load从Spark向Doris传输数据。Flink和Spark生成的批数据会备份到Hive，以满足其他场景的需求，这是提高数据利用率的方式。
2.5 数据服务
在数据服务层，通过数据源注册和灵活配置实现API自动生成，从而可以通过API管理流量和权限。结合K8s无服务器解决方案，整个系统运行得很好。
2.6 数据应用
在数据应用层，此团队有两类应用场景。
- 面向用户的场景，如仪表盘和指标。
- 面向车辆的场景，将车载数据收集到Apache Doris进行进一步处理。即使经过聚合，仍有以十亿计的数据量，但总体计算性能已经达标。
三、CDP实践
和大多数公司一样，此团队也建立了他们自己的客户数据平台（customer data platform，CDP）。
图片
通常情况下，CDP由以下几个模块组成：
- 标签（tags）：基础的组成模块，包括基本标签和客户行为标签。也可以根据需要定义其他标签。
- 分组（groups）：根据标签将客户划分为不同的分组。
- 洞察（insights）：对每个客户群体的特征进行分析。
- 接触（reach）：客户接触方式，包括短信、电话、APP通知和即时通讯。
- 效果分析（effect analysis）：对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架构。如果你也面临着和此团队类似的问题，这可能会为你提供一些参考。
