基于 Apache Doris 打造离在线一体化实时数仓

最新推荐文章于 2024-08-02 20:17:58 发布

FreeOnePlus

最新推荐文章于 2024-08-02 20:17:58 发布

阅读量1.1k

点赞数 19

分类专栏： Apache Doris 文章标签： apache 数据库数据仓库大数据

本文链接：https://blog.csdn.net/qq_38312629/article/details/138821936

版权

Apache Doris 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

本文作者：苏奕嘉
公众号：Apache Doris 补习班

引言

如标题所述，本篇主要从架构设计角度来阐述一下，Doris 在中小型数据体量（总数据 100TB 内，热数据 30TB 内）的场景中，如何设计一站式的低成本高性能的离在线一体化实时数据仓库。

首先不是造词，只是通过命名的方式来阐述清楚这种设计方案和思路的主要特征，本篇将尽可能的从架构角度、开发角度、使用角度以及运维角度来充分阐述清楚该方案的利弊点，让各位看官老爷可以感受到到有价值的参考意义。

本篇我将从道（设计思路）和术（具体案例）两方面来进行阐述，分享一些自己的认知和看法。

设计思路

要解决问题，第一要义是先清楚认知到具体问题是什么。

探寻问题本身

一体化数仓，或者叫轻量级数仓，主要解决的问题痛点有以下几点：

运维复杂度：组件过多，运维成本高，兼容性问题大，往往开发或者升级会牵一发而动全身
数据冗余度：一份数据多份存储，而且可能还割裂成孤岛没法统一使用
数据时效性：对低可见性要求的业务场景，组件多就可能意味着整体数据流转变长，时效性就不太能有可靠保证
开发复杂度：以 Lambda 架构为例，若使用离线修正实时方案，那很可能一套业务要开发两套代码，工作量妥妥 Double，但从业务角度看，开发同学做的事情是事倍功半的，因为他只觉得他拿到了一份数据……
故障恢复率：组件多、链路长，已发布的任务出现异常，或者组件异常导致的数据行为异常，往往需要全链路排查来确定问题，定位修复以后重新流转一遍的速度往往无法让业务方满意（像大部分离线数仓得数小时级别来修复和恢复）

在这里插入图片描述

其他点还有，但是主要的问题本身就这五个方面，所以回头来看本身的诉求是什么，就显得清晰易见：

希望有一个组件，既可以完成实时计算，又可以参与离线计算，数据只存储一份，计算时实时业务和离线业务不能互相影响，计算速度要快，同时还要极简运维，最好大部分运维工作都交由自己来完成。

寻找解决方案

既然明确了诉求，那我们进一步将诉求点拆解转化为技术语言，就可以更直观的从组件特性层面判断目标组件是否满足了我们的诉求。

具备高可用和高可靠能力，可分布式部署，单点故障不会引起整体服务不可用
具备多租户和资源组隔离能力，硬限必须要有，软限尽可能有，同时使用起来不能太麻烦，最好能支持自动升降级资源组的能力
具备数据实时导入能力，能接入的数据源要广，上游生态要好，最好尽可能一肩挑不使用其他组件就可以完成导入
具备结构化和半结构化的数据处理能力，半结构化数据要能支持倒排索引检索能力，如果能具备非结构化的数据存储最好不过，进一步若能解析非结构化数据那就是遥遥领先的存在了
具备数据实时处理能力，应有实时或者近实时手段完成加速计算，时延越低越好，为了能流式计算，最好能支持 Binlog 解析能力
具备数据批式处理能力，尤其是在 TB 级，应有比较好的 CBO 优化器等灵魂 Feature，可以跑几千行的复杂 SQL 而不出现异常，同时跑的速度要比 Hive 和 Spark 要快，就算不快最起码得持平
具备高并发的查询能力，常规的 AdHoc、BI 看板、驾驶舱等数据核心应用场景的 QPS 要一定能保证，同时最好满足对外 API 的点查诉求，因为会有用户画像等场景需要高并发点查
具备极简的运维能力，如组件本身的自愈能力：数据的重分布、坏数据分片的调度修复等能力，组件部署和运维的生态工具要完善
如果是商业化产品，公司技术实力和公司可持续服务能力要强，如果是社区开源产品，社区要活跃，要能保证 BUG 的迭代修复和新功能的开发，最好有诸多大厂参与，保证社区的持续发展能力

那么 Doris 是否能解决以上分析的九大问题点，胜任离在线一体化实时数据仓库一岗呢？

评测组件能力

高可靠和高可用能力

Doris 主要进程有两个：FE 和 BE。

FE 负责查询解析和元数据存储，BE 负责数据存储和物理执行计划执行，为保证高可靠和高可用，那就得保证最少两处的高可用：查询高可用和存储高可用。

在 Doris 的架构设计中，FE 和 BE 都可以通过多节点部署来完成高可用配置，同时在存储端还具备节点间存储负载均衡和磁盘间负载均衡的能力，所以充分满足高可用和高可靠要求。
多租户和资源隔离能力

Doris 在资源隔离场景中，提供了三种解决方案：Resource Group、WorkLoad Group、CCR。

Resource Group 提供物理节点级别的资源隔离，属于资源硬限，适合固定场景。

WorkLoad Group 是将整个集群的资源池子视为一个整体资源对象，在这个大蛋糕上按组划分，同时可以将用户绑定到指定的资源组上，以此保证资源的隔离能力，既可以实现资源软限，又可以实现资源硬限。

CCR 提供了双集群之间的数据同步能力，借助以 Binlog 能力为基准的能力，可设计读写分离、异地多活、主备容灾等多种场景的应用。

故此在多租户和资源隔离角度而言，Doris 完全满足需求。
实时导入能力

在导入方面，Doris 一直以来在做各种生态和加强，根据数据量大小，可以做不同时间可见度的方案设计，比如秒级的微批次数据同步，比如大批次的分钟级、小时级的同步，Doris 提供了诸多的数据同步能力，无论是对接外部同步组件，还是诸如 RoutineLoad、StreamLoad、Catalog、TVF等等能力，可以让数据同步在不同场景下设计不同使用方案。
实时计算能力

Doris 本身具备了强大的向量化计算引擎，同时由于当时设计时就充分考虑到了 Join 算子的处理能力，所以当下无论是大宽表场景、Join 场景、联邦查询场景，还是日志检索场景、高并发点查场景以及 ELT/ETL 跑批任务场景，Doris 都有很强的计算效果。
结构化与半结构化数据处理能力
Doris 做了以 Loki 为代表的轻量级的倒排索引，主要对标的就是 ElasticSearch 倒排索引的分词检索能力，当前可以做中文和英文的分词检索以及模糊匹配，在百亿级以上的日志查询表现中非常亮眼，同时为了日志数据中数据类型的自动兼容，还做了 Varient 新数据类型，可以轻松应对字段数据类型不断变更的场景，非常适合日志数据的存储和查询。
跑批计算能力

本章讲的内容暂不涉及湖仓一体化架构，故此不展开讨论联邦湖仓的能力，会另起章节独立来讲

既然要满足离在线一体化，那么跑批注定是一个非常重要的考量场景，在很多业务场景中，一些指标的计算往往要涉及到多张数据量庞大的大表进行全表扫描，在传统数据处理过程中，我们就是使用离线数仓建模的方式来完成分层加工，而要进行平替或者升级的话，这部分能力一定得靠得住，得满足，所以 Doris 有三大特性来保证这一块的计算效果：
1. 部分算子落盘：在 Doris 2.1.3 版本开始，部分算子落盘的 Feature 已成功合入发行版本，这个特性带来的将是跑批能力的重大提升，过去因为 Doris 是全部将计算过程放到内存里完成的，所以在计算时若内存有明显瓶颈，跑复杂的、数据量过大的场景，往往无法顺利成功执行下去，但有了算子落盘以后，算子中间计算结果有了缓存的地方，这下小内存集群也具备了跑大规模和复杂Query的批计算能力。
2. 向量化引擎及CBO：向量化引擎最早是 ClickHouse 团队提出来并实现的，是非常棒的一项计算加工提效的方式，Doris 站在 ClickHouse 这个巨人的肩膀上借鉴了很多向量化的思想，所以 Doris 本身具备的向量化引擎处理能力就是 T0 级的，同时在 2.0 版本开始，Doris 发布了研发一年半之久的新 CBO，CBO 是一个数据库对处理复杂查询逻辑的灵魂所在，在新优化器的加持下，Doris 对几千行的 SQL 查询解析没有任何压力，而且尽可能的减少了 SQL 调优的动作。
3. Pipeline和PipelineX：Pipeline及X都是为了解决CPU使用时的效率问题，减少计算时 CPU 被异常抢占导致的浪费或者阻塞，这样就可以大幅度提升整体CPU的使用率和计算效率。
综上三大点几其他未枚举的各种小点所述，在实际测试过程中，Doris 比等资源下的 Hive 跑批快 8-10 倍，比 Spark 快 2-3 倍，所以基于此可以得到一个结论：Doris 跑批用更少的资源可以达到更好的性能，具备跑批能力。
高并发点查能力

高并发场景其实在不同业务形态需求下，可以分为两类：
1. 在用户画像或者 API 场景，往往需要针对主键等值点查场景进行高并发低延迟的查询优化，这类并发一般是上万甚至几十万QPS，延迟要求需要在毫秒级
2. 在 AdHoc 或者 BI 报表场景，往往查询复杂度相对中等，但是根据公司规模不同，QPS可能在100到1000之间不等，延迟要求需要在秒级
而这两点，Doris 分别有行列混存、短路径优化以及分区分桶、索引加速来解决。
极简运维能力

用过 Doris 或者了解过 Doris 的同学都清楚，Doris 最大的优势之一就是运维简单，进程就两个，一个 FE 一个 BE，只需要有 Ubuntu 或者 CentOS 之类的 Linux 系统，再加上 JDK 的环境，那么就可以快速部署运行起来一套集群，而且 FE 和 BE 都是独立进程，可以独立做高可用部署。

如果再加上 Doris Manager 的可视化管控能力，那么整体 Doris 的运维难度将会降到非常低的一个程度。
社区生态

Doris 从2022年4月截止现在，已经连续两年位列活跃大数据项目开发贡献者排行榜第一了，是当之无愧当前最活跃的开源大数据项目，而且当前有包括百度、美团、字节、腾讯、阿里、华为等一线大厂的深度实践以及贡献，整个社区生态非常繁荣，已有超 4000 家企业在核心数据分析场景应用 Doris 来解决业务问题。

通过以上论证，从理论角度而言，Doris 是具备了离在线一体化实时数据仓库的构建能力的，但不能说理论可以，那就一定能行，那么我们举个实际场景案例来做架构设计参考。

案例解析

本来准备写以金融、互联网、制造业、食品加工等多个领域的多个设想案例（实际案例没经过允许是不可以发的哦，各位见谅），但是因为精力和篇幅关系，就简单以相较通用的例子给大家 YY 一个。

项目背景

某XX集团在过去几年中初步完成了集团数字化的战略转型，但是随着业务发展，发现过往的数据基础平台的建设成本逐年增高，且数据时效性、数据准确性、数据一致性、数据冗余度以及实际应用效果等方面需要进一步优化，希望可以在集团级别升级打造一套性能提升明显、使用成本节省的数据基础平台，以应对集团在接下来整体发展建设过程中的数字化、智能化的要求。

当前集团数据总量在70TB内，每年增长5-10TB。

过往架构

PS：由于时间关系，为了表述方便，我就画个简图表达一下基本意思，这并不是完整架构图哈，数据导入部分就不做多余赘述了，主要讲讲从架构层面考虑了哪些问题。
在这里插入图片描述

从上述架构图中可以看到，整个数据平台部分有诸多组件来组合完成平台建设，同时根据不同业务使用的特性，划分为三大块来进行分组管理：

比如 AdHoc 探索式查询场景中，使用了 Impala + Kudu 的经典组合，同时使用 Kylin 做 CUBE 来构建维度分析数据魔方，最后为了统一查询网关层，用了 Presto 作为智能路由进行向下屏蔽。
在高并发点查的应用场景中，着重使用了 ElasticSearch 和 MySQL 来完成高并发等值点查场景，这类场景一般是 CDP 这类画像系统使用居多，也有很多特殊业务，比如供应链数据校验、IOT日志观测等，也可能会用到，在这一层若使用 ElasticSearch 和 MySQL，那上层一定使用了 Redis 做架构工程级的容灾设计。
离线数仓就是典型的 Hadoop 中 Hive on Spark 模式。

在很多传统建设的数据平台架构中，这类架构非常常见，随着业务方要求越来越高和数据的量级不断增长，整个运维成本和开发成本逐步走高，所以一起看看上述架构中会遇到哪些问题。

痛点解析

要分析痛点，就先按照数据流流转的思路来步步分析，我们正常的数据流向应该是【数据源】->【数据抽取/ETL组件】->【数据平台组件|组件内部发生数据流转】->【数据应用查询抽取】->【业务使用】

数据源：在整体数据源处理过程中，已约定好入仓数据为结构化数据、半结构化数据和非结构化文本数据，非结构化非文本数据，如音视频等，在当下并为发生实际的业务价值，数据归档数据，故此将全部存储至 NAS 系统中提供网络资源地址使用。
数据抽取/ETL组件：在导入时不同组件和不同业务条线对数据的格式要求不尽相同，在导入任务开发时需要一份数据多次开发，一份数据维护多条数据链路，有实时部分有离线部分，整体开发工作量和维护工作量比较繁重，经常进行数据核对工作，同时由于有 CAN 总线 IOT 日志，数据量比较大，在写入时也遇到各种瓶颈问题。
数据平台组件：根据不同的数据业务条线分别进行数据加工，离线数仓存储所有的完整数据，并根据分层建设思路进行数仓模型构建，其他数据组件有直接拉取原始数据自己完成加工计算的，有拿离线数仓调度完成后的上层报表的，还有其他组件计算完成结果同步后对外提供查询的，不一而足，每个业务开发线上都根据自己的业务逻辑构建出了一套数据加工方法论，在整体开发管理过程中非常困难，而且数据平台组件过多，导致数据冗余度非常高，一份数据多份存储，同时不同组件之间的兼容性问题也经常导致服务不稳定。
数据应用查询抽取：AdHoc 场景使用 Presto 做了智能路由的网关层，所有查询皆可通过 Presto 进行联邦查询，但是在并发变高的业务高峰期，明显Presto的查询时延有比较大的提升，甚至有些时候会导致查询失败或者服务中断。

使用 ES 和 MySQL 进行 DMP/CDP 以及其他场景应用时数据的变更时效性跟不上，容易出现缓存未更新导致业务查询结果相悖的情况。

使用 HiveSQL 进行一些复杂报表查询时，一般都是分钟级响应，有一些复杂的 SQL 需要小时级的任务执行，所以对开发效率比较影响。
业务使用：感觉集群服务的时效性、稳定性、可靠性都比较存疑，往往当天的一些活动数据报表需要周级别才能反馈到业务方手中，又或是在不同库中查询出的数据有不一致的情况出现，不知道以哪一份计算结果为准，对数据基建的数据可靠性不太信任。

架构选型

其他架构我就不对比了，咱们就直接了当的选择引入 Doris 来解决上述问题

实际落地

一般的架构设计演进分为两种情况：完全新基建、老架构改造。

那么很明显这个例子适用于老架构改造，那老架构改造时一定切记不可一蹴而就，无论你选择的这个组件你觉得多信任，都应该循序渐进的去做铺展，从它最擅长的部分进行引入，逐步切换业务，分多期来完成架构平滑升级。

一期架构

在这里插入图片描述

可以看到，第一期的架构演进过程中，我们采取使用 Doris 来替换原本的 Presto、Kylin、Impala 及 Kudu，这样设计的原因有以下几点：

能力平替评估：
1. Presto 主要是联邦查询能力，这一点 Doris 的 Catalog 能力可完美替代，虽然 Doris 的 Catalog 数据源当前还没有 Presto/Trino 那么多，但是在当前这个应用案例中，他完全可以做平行替代，且替代以后的查询性能会有突破
2. Kylin 主要是使用 Cube 做多维度预计算，典型的使用空间换时间的方案，也就是把可能查询的所有聚合方式都预先跑一遍，这样直接查询结果集一定是非常快的，在这一点上 Doris 的异步物化视图可平行替代，且整体灵活度更高，按需进行预计算
3. Impala + Kudu 是以前典型的 AdHoc 查询场景组件，主要表现在 Join 方面要比一部分组件效果好，灵活性强，但是相较于 Doris，这一点就从长板变成短板了，Doris 相较于 Impala 的查询速度，实测有5-6倍的提升，所以使用 Doris 替换 Impala + Kudu 组合是非常有性价比的选择
问题解决评估：
1. Doris 是完整具备查询引擎和计算引擎的一体化数据库，那么在整个查询优化方式中，手段很多，比如建立物化视图、构建索引、分区分桶、缓存加速等等，同时和 Presto 相较，由于统一了多个组件，数据都不再零散至各个组件内，所有查询的数据都将是查询 LocalDisk 的数据，相较于网络传输速度，本地盘的传输速度一定是占优的，再加之根据自己的 SQL 优化器来进行谓词下推做分区裁剪，效果一定优于兼容性语法的下推，所以综上所述，无论是查询时间或者是查询并发度，Doris 替换以上组件以后都会有比较明显的性能提升。
2. 数据存储冗余度下降，从原本四个组件可能都互有冗余的情况，变为单一组件统一存储管控，哪怕是从 Hive 数仓里抽取部分表的数据作为查询数据，那也只是相较于 Hive 数仓多了一份数据，整体存储成本得到了降低。
3. 开发成本下降，以前不同的业务线上需要学习不同的组件语法以及不同的开发逻辑，有些时候同一套业务逻辑可能会使用不同的组件进行重复开发，人效比比较低下，同时再储备团队技术人才时，往往很难储备成功比较全能的人才，招人时也很难找到多组件都精通同时可以快速熟悉业务的人才，现在这些痛点都可以统一解决，Doris 使用高度兼容的 MySQL 协议作为开发客户端协议，MySQL 标准语法的学习成本极低，同时一套逻辑只需要开发一遍，整体开发成本得到极大降低。
4. 运维成本下降，Impala + Kudu 组合的开源社区活跃度比较低，往往有了问题无法寻求帮助，只能尽可能查询现有网络资料，如果解决不了，就只能硬抗挨批，同时维护多个组件要非常熟悉多个组件才行，每个组件的运维成本叠加在一起将会非常高昂，切换至 Doris 以后，只需要维护这个社区异常活跃的单一组件即可，且 Doris 本身的运维难度就非常低，叠加以后的收益非常显著。

综上，使用 Doris 替换 Presto、Kylin、Impala + Kudu 的组合，整体实施是完全可靠的，唯一需要花时间和精力的就是业务平行迁移工作，由于这部分业务暂未涉及到复杂的分层建模，故此只需要把聚合后的离线数据导至 Doris，再改造查询语句即可完成平行迁移。

在这里改造查询语句的过程中，由于 Doris 提供了 SQL 方言转换器，可以直接兼容识别 Presto 的 SQL 语法，所以一期工程的实施过程非常丝滑，搭建 Doris 集群后建表将 Hive 的数据使用 BrokerLoad 方式进行批导入，然后使用 SQL 方言转换器直接传入之前 Presto 的 SQL，即享受到了初步融合统一的快乐，后续逐步对 Presto 语法任务进行 Doris 化改造。

二期架构

在这里插入图片描述

二期在一期的基础上进行了进一步的扩容，这个扩容有两层含义：资源扩容和业务场景扩容。

可以对比看到，Doris 在这一期平行替换了 ElasticSearch 和 MySQL 在高并发点查以及日志检索业务上的应用，Doris 能做到这一点的原因其实在最上面回答九个问题的时候有提过，一来 Doris 具备对标 ES 的倒排索引能力，二来 Doris 具备行列混存的高并发点查能力，同时 Doris 还具备了大规模吞吐以及实时更新的能力，在这几方面的加持下，平行替换 ES 和 MySQL 完全不是问题，这里就不展开阐述利弊了，关于单独的特性应用细节我们在其他章节再一一阐述。

三期架构

在这里插入图片描述

在解决完数据平台中偏上层的组件统一后，我们使用 Doris 一并将 Spark 和 Hive 这套 Hadoop 体系的离线数仓做了完整替换，在替换之前做了严格的 POC 验证：使用同等数据量、同等资源量、同等查询逻辑进行对比查询，发现 Doris 的跑批能力比 Spark 快 2-3 倍，比 Hive 快 8-10 倍，加上开发成本、运维成本、存储成本等，换算后整体收益比超过5倍！

那除去速度和性价比提升以外，还有哪些相关性工作或者组件指的关注呢？

多租户之间的资源隔离：我们使用 WorkLoad Group 进行资源隔离划分，白天给 AdHoc 划分了整个集群 40% 的资源，给高并发检索和日志检索划分了 20% 的资源，给微批调度划分了 40% 的资源，同时在凌晨跑一些大规模批任务时，微批调度的 Group 会软限侵占其他两块 60% 无人使用的资源来加速完成离线任务调度，综合下对于资源利用率、资源隔离度，都有很好的保障。
部分算子落盘：由于有了部分算子落盘，整体集群资源量不必按照最高峰值运行内存进行设计了，用之前几分之一的资源即可完成整体任务调度，对成本节省有巨大的应用价值。
数据库表和权限的统一管理：由于数据全部都进入到一个统一数仓内了，所以库表权限以及数据本身的冗余度都可以有非常好的一个管控保证，一份数据多套业务线共同使用，资源利用率大幅度增高，成本下降。
优化策略：Doris 对于不同场景有很多的优化手段可以使用，从建表时的分区分桶以及Key键设计，再到索引加速和物化视图加速，同时还能做分层建模的微批调度，通过 Partition 级别进行快速数据更新，整体时效性从过往 T+1 下降到平均分钟级甚至秒级。
运维成本大幅度下降：从维护八个甚至更多组件，九九归一，只需要维护 Doris 即可。
调度平台：Doris 本身内部虽然内置了 Job 任务，但是 DAG 类的依赖调度任务，还是选用 DolphinScheduler 作为统一的调度平台来进行任务编排开发，Doris 和 DolphinScheduler 的结合非常丝滑。

案例总结

至此，使用 Doris 改造传统离线数仓为离在线一体化实时数仓的设计已阐述完毕，我们稍微总结一下改造思路和实施过程：

先依据数据流转完成整体架构痛点分析，这个分析不要仅局限于技术上，还有业务、使用体感、运维难度、团队成本等，全方位考虑到以后，才能知道自己应该做点啥事来解决。
评估选型组件是否可以完成分析以后的痛点，甚至对更未来的场景的延拓，是不是选型的组件也可以有比较好的拓展性？如果都满足，那就选定开始设计实施方案。
从实施角度而言，不要着急一蹴而就，要循序渐进徐徐图之，无论如何要保证业务的连续线和稳定性，无论你采用并跑结构还是灰度方案，都一定不要因为追求技术就忘记了技术是服务业务这件很重要的事情，一个模块使用稳定了，再考虑下一个模块的切换，最好就是可以做到无感切换，这就需要组件具备强大的生态兼容能力了。

以上案例就是一个根据自己主导和参与了很多很多数仓的架构升级改造，以及从零到一搭建实时数仓的经验 YY 而来的一个案例，如有雷同纯属巧合~