1. 概览
我们都知道Doris 目前是一个典型的Share-Nothing的架构，Doris 通过绑定数据和计算资源在同一个节点获得非常好的性能表现. 但随着Doris 计算引擎性能持续提高, 越来越多的用户也开始选择使用Doris直接查询数据湖数据. 这类场景是一种Share-Disk场景, 数据往往存储在远端的 HDFS/S3 上, 计算在 Doris 中, Doris 通过网络获取数据, 然后在内存完成计算. 而如果这两个负载都混合在同一个集群时, 对于目前 Doris 的架构就会出现以下不足:
- 资源隔离差, 两个负载对集群的响应要求不一, 混合部署会有相互的影响，
- 数据湖场景下磁盘利用率低：集群扩容时, 数据湖查询只需要扩容计算资源, 而目前只能存储计算一起扩容, 导致磁盘使用率变低
- 扩容效率差: 扩容后会启动Tablet数据的迁移, 整体过程比较漫长. 而数据湖查询有着明显的高峰低谷, 需要小时级弹性能力.
Shared Nothing：各个处理单元都有自己私有的CPU/内存/硬盘等，不存在共享资源，类似于MPP（大规模并行处理）模式，各处理单元之间通过协议通信，并行处理和扩展能力更好。典型代表DB2 DPF和Hadoop ，各节点相互独立，各自处理自己的数据，处理后的结果可能向上层汇总或在节点间流转。我们常说的 Sharding 其实就是Share Nothing架构，它是把某个表从物理存储上被水平分割，并分配给多台服务器（或多个实例），每台服务器可以独立工作，具备共同的schema，比如MySQL Proxy和Google的各种架构，只需增加服务器数就可以增加处理能力和容量。
针对上面这些不足的地方，我们专门设计出来一种用于联邦计算的 BE 节点角色：计算节点，这种角色的 BE 节点，专门处理数据湖这类远程的联邦查询. 原来的BE节点类型称为混合节点, 这类节点既能做SQL查询, 又有Tablet数据存储管理. 而计算节点只能做SQL查询, 它不会保存任何数据.
有了计算节点后, 集群部署拓扑也会发生变: 混合节点用于OLAP类型表的数据计算, 这个节点根据存储的需求而扩容, 而计算节点用于联邦查询, 该节点类型随着计算负载而扩容.
此外, 计算节点由于没有存储, 因此在部署时, 计算节点可以混部在HDD磁盘机器或者部署在容器之中
这样这种节点其实就变成了一个无状态的 BE 节点，我们可以非常容易的进行弹性伸缩，不需要想之前混合节点那样，在扩展集群的时候，需要等待 tablet 副本均衡完成，这个节点才能进行有效的负载。
2. 弹性节点使用
Doris的安装这里我就不做太多详细介绍了，具体的可以参照: Apache Doris 系列：入门篇-安装部署
需要注意的点：
FE 配置
在 fe.conf 里添加下面俩个配置
prefer_compute_node_for_external_table=true min_backend_num_for_external_table=1
- prefer_compute_node_for_external_table : 如果设置为 true，对外部表的查询将优先分配给计算节点。计算节点的最大数量由
min_backend_num_for_external_table控制。如果设置为 false，对外部表的查询将分配给任何节点 - min_backend_num_for_external_table : 仅在
prefer_compute_node_for_external_table为 true 时生效。如果计算节点数小于此值，则对外部表的查询将尝试使用一些混合节点，让节点总数达到这个值。如果计算节点数大于这个值，外部表的查询将只分配给计算节点， 默认值是3，这里我演示因为节点数量问题，我设置成了1，
BE 配置
在be.conf 里添加下面配置，
be_node_role=computation
该配置项默认为mix, 即原来的BE节点类型, 设置为computation后, 该节点为计算节点.
我这里是将，192.168.0.128 和 192.168.0.129 这两个节点设置成计算节点
然后我们将节点加入到集群之后，并启动节点，查看 BE 的信息，可以看到，NodeRole 这个字段，如果是 mix 表示为混合节点，如果是computation表示为计算节点
mysql> show backends\G; *************************** 1. row *************************** BackendId: 11007 Cluster: default_cluster IP: 192.168.0.114 HostName: 192.168.0.114 HeartbeatPort: 9050 BePort: 9060 HttpPort: 8040 BrpcPort: 8060 LastStartTime: 2023-06-03 21:51:24 LastHeartbeat: 2023-06-03 21:51:40 Alive: true SystemDecommissioned: false ClusterDecommissioned: false TabletNum: 21 DataUsedCapacity: 0.000 AvailCapacity: 177.323 GB TotalCapacity: 196.735 GB UsedPct: 9.87 % MaxDiskUsedPct: 9.87 % RemoteUsedCapacity: 0.000 Tag: {"location" : "default"} ErrMsg: Version: doris-2.0.0-alpha-a925ec9 Status: {"lastSuccessReportTabletsTime":"2023-06-03 21:51:26","lastStreamLoadTime":-1,"isQueryDisabled":false,"isLoadDisabled":false} HeartbeatFailureCounter: 0 NodeRole: mix *************************** 2. row *************************** BackendId: 11026 Cluster: default_cluster IP: 192.168.0.128 HostName: 192.168.0.128 HeartbeatPort: 9050 BePort: 9060 HttpPort: 8040 BrpcPort: 8060 LastStartTime: 2023-06-03 21:50:34 LastHeartbeat: 2023-06-03 21:51:40 Alive: true SystemDecommissioned: false ClusterDecommissioned: false TabletNum: 0 DataUsedCapacity: 0.000 AvailCapacity: 177.323 GB TotalCapacity: 196.735 GB UsedPct: 9.87 % MaxDiskUsedPct: 9.87 % RemoteUsedCapacity: 0.000 Tag: {"location" : "default"} ErrMsg: Version: doris-2.0.0-alpha-a925ec9 Status: {"lastSuccessReportTabletsTime":"2023-06-03 21:51:38","lastStreamLoadTime":-1,"isQueryDisabled":false,"isLoadDisabled":false} HeartbeatFailureCounter: 0 NodeRole: computation *************************** 3. row *************************** BackendId: 11045 Cluster: default_cluster IP: 192.168.0.129 HostName: 192.168.0.129 HeartbeatPort: 9050 BePort: 9060 HttpPort: 8040 BrpcPort: 8060 LastStartTime: 2023-06-03 21:49:52 LastHeartbeat: 2023-06-03 21:51:40 Alive: true SystemDecommissioned: false ClusterDecommissioned: false TabletNum: 0 DataUsedCapacity: 0.000 AvailCapacity: 177.319 GB TotalCapacity: 196.735 GB UsedPct: 9.87 % MaxDiskUsedPct: 9.87 % RemoteUsedCapacity: 0.000 Tag: {"location" : "default"} ErrMsg: Version: doris-2.0.0-alpha-a925ec9 Status: {"lastSuccessReportTabletsTime":"2023-06-03 21:51:02","lastStreamLoadTime":-1,"isQueryDisabled":false,"isLoadDisabled":false} HeartbeatFailureCounter: 0 NodeRole: computation 3 rows in set (0.00 sec)
3. 测试
下面我们以 MySQL Catalog 外表为例来测试弹性节点的使用
创建MySQL Catalog
CREATE CATALOG mysql properties ( "type"="jdbc", "jdbc.user"="root", "jdbc.password"="NewPass4321!", "jdbc.jdbc_url"="jdbc:mysql://192.168.0.250:3306/test", "jdbc.driver_url"="mysql-connector-java-8.0.25.jar", "jdbc.driver_class"="com.mysql.cj.jdbc.Driver" )
查询 Catalog 外表
mysql> set enable_profile = true; Query OK, 0 rows affected (0.00 sec) mysql> select date,user_src,new_order,payed_order from mysql.test.order_analysis limit 2; +---------------------+-------------------------+-----------+-------------+ | date | user_src | new_order | payed_order | +---------------------+-------------------------+-----------+-------------+ | 2015-10-12 00:00:00 | 广告二维码 | 15253 | 13210 | | 2015-10-14 00:00:00 | 微信朋友圈H5页面 | 17134 | 11270 | +---------------------+-------------------------+-----------+-------------+ 2 rows in set (0.03 sec)
查看 FE Web UI QueryProfile
查看我们刚才执行的 SQL Profile 可以看到，这个Catalog外表的计算是在计算节点上进行的，并不是在混合节点上
将外部表的数据导入到 Doris 内表里
mysql> create table test_01 as select * from mysql.test.order_analysis; ERROR 1105 (HY000): Unexpected exception: errCode = 2, detailMessage = Failed to execute CTAS Reason: errCode = 2, detailMessage = Failed to find 3 backend(s) for policy: cluster=default_cluster | query=false | load=false | schedule=true | tags=[{"location" : "default"}] | medium=HDD mysql>
这里可以看到通过Create table as Select这种才做是失败的，原因是因为，我这个时候只有一个混合BE节点，默认三副本，所以失败。同时也说明的弹性计算节点是不带存储的，不存储tablet副本信息。
下面在创建表的时候指定副本是 1 就可以正常创建表，并将数据导入进去。因为这里只有一个（192.168.0.114）节点是mix类型的节点，其他两个节点都是计算节点。
mysql> create table test_01 PROPERTIES("replication_num" = "1") as select * from mysql.test.order_analysis; Query OK, 5061 rows affected (0.29 sec) {'label':'insert_9c013d7ccf064a16_a7ca128d72869a35', 'status':'VISIBLE', 'txnId':'1'} mysql> select count(*) from test_01; +----------+ | count(*) | +----------+ | 5061 | +----------+ 1 row in set (0.07 sec) mysql>
下面我们在 Doris 内表上执行查询
我们在Web UI上同样可以看到内表执行的节点是在Mix类型的节点上。
计算节点下线
下线操作和之前 BE 节点的下线一样，只不过这个下线速度会非常的快，这是因为这个节点不保存 tablet 数据，下线的时候不需要进行tablet 副本的均衡操作。
alter system DECOMMISSION backend "192.168.0.128:9050";
4. 总结
是不是使用非常简单方便，同时对于数据湖外表计算需要快速弹性扩缩容的场景，既简单又快捷，快快体验起来吧
