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. 總結
是不是使用非常簡單方便，同時對于數據湖外表計算需要快速彈性擴縮容的場景，既簡單又快捷，快快體驗起來吧
