基于 Doris 构建实时统一的现代数据分析平台
导读： 本文将分享 SelectDB 公司对于现代数据分析栈的一些认识，以及SelectDB 公司围绕 Apache Doris 构建现代数据分析栈的一些工作。
今天的介绍会围绕下面四点展开：
-
当前数据分析栈的现状与挑战
-
基于 Apache Doris 构建实时统一的数据底座
-
Apache Doris 最新特性解读
-
关于 SelectDB
分享嘉宾｜衣国垒 SelectDB CTO &ApacheDoris Committer
编辑整理｜朱佳佳 北京航空航天大学
出品社区｜DataFun
01/当前数据分析栈的现状与挑战
1. 当前数据分析栈
当前数据分析栈可以分为两大类。
**第一类是以 Oracle 为代表的关系型数据库作为数据分析的数据源，**通过数据同步工具同步到数据仓库中，在数据仓库中做进一步的数据处理，如 ETL（抽取、转换、加载）或 ELT（抽取、加载、转换）。数据最后通过 BI 工具（Tableau、Quick BI 等）以报表的形式呈现给业务管理者。也有很多企业采用 Clickhouse 或 Apache Doris 这类的 OLAP 技术对处理进行加速。
第二类是以日志或者第三方数据的 API 作为数据分析的数据源，通过Kafka 或 Flink 流式处理系统把数据同步到 S3 或 HDFS 上，通过 DeltaLake、Hudi、Iceberg 这类湖仓方案对数据进行管理。然后通过批处理系统（Spark、MapReduce 等）、流式处理系统（Flink）、交互式分析系统（Impala、Presto）对数据进行处理，最终将数据存储到 OLAP 系统中。数据呈现方式也是多种多样的，如用户行为分析、ABTest 实验、基于日志的 Tracing 系统等。
2. 架构演进
从 2006 年 Hadoop 诞生开始，数据分析栈的演进可分为三个阶段。
① 第一阶段是以诞生 Hadoop 为界，它解决了移动互联网时代海量数据计算和分析的问题，数据处理不再受传统一体化架构的限制，可分析的数据量也从过去的 TB 级数据升级到 PB 级。
② 第二阶段大数据技术栈百花齐放，诞生了消息处理引擎 Spark，它超越了 Hadoop 的 Mapreduce 的分析速度；诞生了流式处理系统 Flink，加速了流式处理性能；同时也诞生了很多 OLAP 技术，如 Impala，Presto 这样的交互式分析引擎，可以直接对 HDFS 或 S3 上的数据进行分析；也有像 Doris、Kylin、Druid、Clickhouse 这样的系统，它要求把用户的数据灌入到自己的存储中，更高效地对数据进行分析。
③ 第三阶段结合云基础设施，大数据技术栈逐渐趋于统一。以 Snowflake 数据仓库技术为代表，用户只需要提供数据源，加工过程由 Snowflake 这样的 SaaS 技术解决，用户不需要感知各种大数据组件。
数据仓库技术和大数据技术越来越趋于融合，结合云的基础设施，在提升数据分析效率的同时，对资源的管理也会更加高效。
3. 现代数据分析需求，有哪些变与不变？
现代数据分析需求不变的方面：
- 性能，性能越好意味着单位成本下处理的数据量越多。
- 时效性，数据的价值会随着时间的推移而降低，实时数据的重要性已在越来越多的业务场景中得到验证。
现代数据分析需求的变化：
- 灵活，缩短需求交付周期，让用户尽快看到数据应用的效果。
- 全民化，企业中的任何一个人都可以无障碍地访问所需要的数据，并可以对数据进行探索，构建自己的业务认知。
4. 现代数据分析需求的挑战？
现代数据分析在以下四个场景面临的挑战如下：
① 多维报表：高并发，且查询需要响应毫秒级低延时。现在很多报表是面向 B 端的商户或终端消费者，它对访问量、并发度、系统的可用性的要求越来越高。
② 即席查询：这种查询模式相对灵活，没有办法预知，常常需要对数据进行大量扫描，然后再做出复杂计算，最后将结果呈现，所以它不论对于 IO 的压力还是对于 CPU 的压力都非常大的。
③ 统一数仓：为了减少业务运行维护代价，越来越多的企业将数据的加工糅合到一套系统中，该系统能同时具备在线查询和离线 ETL 能力，同时保证离线计算和在线服务的资源不抢占。
④ 湖仓加速：支持加载多种数据源，打破数据孤岛，呈现出统一的业务视图。
--
02/基于 Apache Doris 构建实时统一的数据底座
接下来介绍一下 Apache Doris 如何解决当前面临的数据分析栈的问题。
1. Apache Doris 是什么？
Apache Doris 在 2022 年 6 月正式从 Apache 社区孵化毕业，成为Apache 顶级项目。Apache Doris 是一个 MPP 架构的高性能实时分析型数据库，它主要应用在多维报表、即席查询、用户画像，实时大屏、日志分析、数据湖加速等业务场景。目前全球超过 700 多家企业在生产环境中使用 Doris，它的稳定性及服务质量都是非常有保证的。
2. Apache Doris 典型应用场景
第一类业务场景是把关系型数据库的数据源通过数据集成处理工具灌入到Apache Doris 中，它能支持 OLTP 这种频繁的交易型数据分析。第二类业务场景是把日志数据通过数据集成的工具灌入到 Doris 中，从而生成 PV、UV 等用户行为报表，此外还支持 IoT 的时序数据。
Doris 中的数据可以做很多场景的分析，如用户行为分析、AB test 实验、日志检索分析、订单分析、大屏驾驶舱等。此外，Doris 通过湖仓一体的查询引擎对 Hive、Iceberg、Hudi 等外部数据源进行分析。Doris 在 OLAP 领域已经做得相当好了，一些小规模数据量的 ETL 的问题是目前 Doris 努力的一个方向。
3. 场景案例一：互联网用户增长分析平台
在过去互联网用户增长分析平台的分析架构包含了 Kudu、Spark、YARN等框架，Doris 把这种复杂的多组件的架构统一到一个分析架构上，提供即席分析和多维报表等应用场景，在性能上也比过去提升 2-10 倍。Doris 的平均查询延时在 10 秒左右，95 分位的查询延时在 30 秒以内，每天可运行数万条 SQL 处理，集群规模可达数百台。
--
03/Apache Doris 最新特性解读
下面介绍 Doris 的一些最新特性。
1. Apache Doris 1.2 版本特性------主键模型优化
过去 Doris的Unique key 模型是一种 Merge on Read 模型，它的原理是把数据存储成 Segment，每个 Segment 都有一个版本号，在查询的时候通过 Merge 多个 Segment 数据，取版本号最大的数据做返回。在查询的时候，大规模数据的归并排序和比较是非常耗 CPU 的，同时不支持谓词下推，无法做 where 语句的提前过滤，导致扫描的数据量更多，查询过程会更慢，实时更新能力也会受限。Doris 1.2 版本中引入基于主键索引+Delete Bitmap 的方式来实现 Unique key 模型，在数据导入过程中，生成数据删除标记 Delete Bitmap，在查询时通过 Delete Bitmap 做数据过滤。
经过测试，在实时更新的场景下，新版本的Unique key模型比旧版本的性能提升了10倍以上。
2. Apache Doris 1.2版本特性------Light Schema Change
当把关系型数据库据同步 Doris 中时，可能由于 Schema 的变化导致数据流的中断，过去的 Doris Schema Change 把数据重新读一遍，再重新写一遍，整个过程是分钟级甚至小时级的，当数据特别大，有可能导致数据流中断的。在 Doris 1.2 版本中，引入了 Light Schema Change 新技术，对于加列、减列及变更列类型的数据处理，只需修改FE节点存储的元数据来实现，整个过程在毫秒级就可以完成。
3. Apache Doris 1.2 版本特性------Multi Catalog
在旧版本中，Doris 通过建立一张外表来实现 MySQL 或 Hive 中的数据源同步，如果有几万张表，在 Doris 中也需要建立几万张外表，而且一旦发生变更，就需要重新操作一次，同步的代价是非常大的。在 Doris 1.2 版本中，SelectDB 为 Doris 引入了 Multi Catalog 技术，用户可以把整个 Hive Metastore 映射到 Doris 中，Doris 自动将 Hive 中的 Schema 同步到 Doris 中，且会自动同步 Schema 的变更，整个同步过程是秒级或者分钟级的。同时也支持了新的数据库引擎，如 Iceberg、Hudi。
4. Apache Doris 1.2 版本特性------JDBC数据源
在旧版本中，Doris 通过 ODBC 的方式连接 MySQL、Oracle、PostgreSql等数据源，但在使用过程中经常因为驱动版本的不一致导致进程崩溃。在新版本中引入 JDBC 的方式，它对版本的兼容性更好，使得 Doris 更加稳定。
5. Apache Doris 1.2 版本特性------冷热数据分离
用户希望在有限的成本下存储更多的数据，因此 Doris 1.2 版本中引入了冷热数据分离的技术，把一段时间内访问较多的数据存储到本地磁盘上，把一段时间内访问较少的数据以对象存储的方式放到云端 S3 这种低成本的存储方式中，这种方式能将用户的存储成本降低 70%。
冷热数据分离支持的最细粒度为 Rowset 级别，将冷数据放到 S3 中，将热数据放到本地磁盘中，Doris 自动感知哪些 Rowset 是冷数据，哪些 Rowset 是热数据。冷数据全功能支持导入、查询、Schema Change。
当把数据搬迁到 S3 后，S3 是没有硬链机制的，如果 Schema Change还基于硬链实现的话，那冷热分离就实现不了了，这也是我们要实现 Light Schema Change 的一个原因。
后续还会继续对冷热分离技术做一些优化，如单副本存储，本地 File Cache。
6. Apache Doris 1.2 版本特性------New MemTracker
Doris 1.2 版本引入了 New MemTracter，因为 Doris 具备在线计算、离线 ETL 等能力，查询存在并发，如果对内存不加以限制，有可能一个查询把所有资源占满。New MemTracter 对内存进行三个粒度的限制，对进程级内存进行限制，对单查询内存限制，如果超过限制，会自动 Cancel 掉，保证查询不会把所有的资源占满，引入了算子粒度的内存统计，统计每一个算子分别使用多少内存，提供更好的可观测性。
7. Apache Doris 1.2 版本特性------其他重要新功能
此外 Doris 1.2 版本还有一些其他的功能，支持 Array 类型，支持嵌套、行列转换，支持 JSON 格式数据存储。同时引入了 New Decimal 数据类型，它支持更大的精度和更高的计算效率，开发了新的 Date 和 Datetime 类型数据。此外引入了 Java UDF，用户能够把已有的技术资产非常方便的引入到 Doris 中，1.2 版本目前已发布。
8. Apache Doris 1.2版本性能表现------持续优化中
我们对 Doris 做了 100 多处的性能优化，整体性能相较于 1.1 版本提升了近 4 倍，是业内标杆竞品的三倍以上。
近期，在 ClickHouse 发起的分析型数据库性能测试排行榜 ClickBench 中，基于 Apache Doris 的新一代云原生实时数仓 SelectDB 强势登顶，性能表现超越一众国内外产品，多项指标排行前列，并在业界最为通用的 c6a.4xlarge, 500gb gp2 机型下排行全球第一！
--
04/关于 SelectDB
SelectDB 公司的定位是 Apache Doris 背后的一个商业化公司，我们将大力投入研发力量，加强 Apache Doris 在数据分析技术上的创新力，使 Apache Doris 能成为世界领先的开源的分析型的数据库。
--
05/问答环节
Q1：Doris 冷热分离技术中，远端 S3 上的路径是存在 BE 节点中还是存在 FE 节点？
A1：是存在 BE 节点中的。
Q2：Doris 在 SaaS 多租户数据存储上面有什么演进吗？
A2：目前没有，但是在 SelectDB Cloud 上会有这部分功能。
Q3：冷热分离技术中，Rowset 分级会不会使得小文件变多？
A3：小文件问题并不会太多，因为冷数据用户访问的频率是比较低的，我们也会做本地 cache 的淘汰。
Q4：Doris 是否有一些云原生特性的规划？
在容器化方面，1.3 版本中，会对 K8S 做技术支持。在多租户问题上，因为考虑到现在很多云原生的技术的部署是比较复杂的，所以我们会把相应的接口放到 Doris 的代码中，大家可以参考实现。
Q5：在技术选型上如 Clickhouse、Doris、StarRocks 有什么建议？
A5：从我的角度来看，Doris 还是比较好。Doris 很多代码借鉴了Clickhouse，但是在代码基础上也做了很多改进，如 Group by 算子的性能、join 的能力，都是支持的非常好。我觉得 Doris 在整个 OLAP 领域还是比较领先的。
Q6：Doris 新版本的存储效率如何？
A6：在存储效率方面，我们引入了新的特性，对于 String 字符串，引入了 ZSTD 压缩技术，在 String 类型上数据存储效率是有提升的，但整数类型提升不大。
Q7：Doris 新版本能否解决内存管理上的一些问题吗？
A7：一方面，我们引入了 New MemTracter 限制内存，在 1.3 版本中还会继续对内存限制进行优化，当没有并发的时候，可以把所有内存用起来，当并发的时候，会按照用户设置的比例来 kill 掉一些比较大的查询，来保证就剩下的查询能够按照用户设置的比例这样来跑下来。
另一方面，在Doris 下一个版本中，我们会去把所有代码改造成异常安全代码，保证即使有任何错误，整个系统也可以继续稳定地运行。
Q8：新版 Unique key 模型是否会影响 Segment V2 数据存储？1.1 版本是否可以直接升级到 1.2 版本？
A8：新版 Unique key 模型不会影响 Segment V2 数据存储，因为新版Unique key 模型数据存储还是基于 Segment V2 的，只是增加了 Delete Bitmap 的实现，所以不会影响 Segment V2 的存储。
新版 Unique key 模型能够兼容老版 Unique key 模型，升级后，老版Unique key 模型仍可以继正常运行，这也是 Doris 每个版本的要求，保证升级过程是滚动升级，所以 Doris 连续两个版本之间升级是可以保证的。
今天的分享就到这里，谢谢大家。
分享嘉宾
衣国垒｜SelectDB CTO &ApacheDoris Committer
先后在百度、腾讯从事Doris，Elasticsearch，Clickhouse 相关的研发工作，Apache Doris Committer，负责研发了两阶段事务、并行导入、分布式集群管理、联邦查询等多个核心机制。现任 SelectDB 公司 CTO。
