doris调研

一、官方定位

“Doris is a MPP-based interactive SQL data warehousing for reporting and analysis.” Doris 是一个用于报告和分析的基于 MPP 的交互式 SQL 数据仓库。

Doris 主要集成了 Google Mesa 和 Apache Impala 的技术。

二、主要用途

提供 OLAP 数据分析。（同时支持聚合和明细查询分析）

三、实现原理

架构

Doris 的整体架构分为两层。多个 FE 组成第一层，提供 FE 的横向扩展和高可用。多个 BE 组成第二层，负责数据存储于管理。

FE 节点分为 follower 和 observer 两类。follower 节点通过选举，其中一个 follower 成为 leader 节点，负责元数据的写入操作。当 leader 节点宕机后，其他 follower 节点会重新选举出一个 leader，保证服务的高可用。observer 节点仅从 leader 节点进行元数据同步，不参与选举。可以横向扩展以提供元数据的读服务的扩展性。

后端守护进程负责数据存储和执行 SQL 查询。可以部署多个后端守护进程以提供可伸缩性和容错性

前端(FE)

元数据

Doris 的元数据是全内存的。每个 FE 内存中，都维护一个完整的元数据镜像。

Doris 的元数据主要存储4类数据：

用户数据信息。包括数据库、表的 Schema、分片信息等。
各类作业信息。如导入作业，Clone 作业、SchemaChange 作业等。
用户及权限信息。
集群及节点信息。

元数据的数据流具体过程如下：

只有 leader FE 可以对元数据进行写操作。写操作在修改 leader 的内存后，会序列化为一条log，按照 key-value 的形式写入 bdbje。其中 key 为连续的整型，作为 log id，value 即为序列化后的操作日志。
日志写入 bdbje 后，bdbje 会根据策略（写多数/全写），将日志复制到其他 non-leader 的 FE 节点。non-leader FE 节点通过对日志回放，修改自身的元数据内存镜像，完成与 leader 节点的元数据同步。
leader 节点的日志条数达到阈值后（默认 10w 条），会启动 checkpoint 线程。checkpoint 会读取已有的 image 文件，和其之后的日志，重新在内存中回放出一份新的元数据镜像副本。然后将该副本写入到磁盘，形成一个新的 image。之所以是重新生成一份镜像副本，而不是将已有镜像写成 image，主要是考虑写 image 加读锁期间，会阻塞写操作。所以每次 checkpoint 会占用双倍内存空间。
image 文件生成后，leader 节点会通知其他 non-leader 节点新的 image 已生成。non-leader 主动通过 http 拉取最新的 image 文件，来更换本地的旧文件。
bddje 中的日志，在 image 做完后，会定期删除旧的日志。

元数据流图

后端(BE)

后端守护进程负责数据存储和执行 SQL 查询。

四、对比分析

kylin与doris对比分析
	kylin	doris
底层存储	hbase	google Mesa +ORCFile/Parquet
数据导入	离线hive和实时kafka导入	离线hive和实时kafka导入
聚合计算配置方式	页面配置（聚合组和维度组合方式）	手工创建（多张rollup博安排）
聚合计算配置灵活性	控制聚合的维度	控制聚合的维度和指标
数据构建	构建时间较长，一般为20min~50min	构建时间一般在10min内
数据查询接口	自带web查询，提供jdbc和odbc接口	使用mysql查询引擎
计算效率	毫秒~秒级返回结果	毫秒~秒级返回结果（性能高于kylin）
支持的计算方式	sum/min/max/count/count distinct	sum/min/max/count（不支持精确去重）
学习成本	维度、指标强制维度、层级维度、关联维度 rowkey和全局字典等诸多概念	维度、指标数据模型 rollup表