數據倉庫架構的變遷

引言

第八屆中國架構師大會（SACC2016）10月27號到29號在北京萬達索菲特大飯店成功舉辦。大會以「架構創新之路「爲主題，雲集了國內外頂尖專家，共同探討雲計算和大數據等技術背景下，如何經過架構創新及各類IT新技術來帶動企業轉型增效。做爲一家專一於雲端數據倉庫的初創公司，酷克數據受邀在SACC2016 「數據庫平臺架構及變遷」分會場做了題爲「數據倉庫架構及變遷」的演講。如下是此次演講的PPT。

這個日程安排同時也是咱們公司核心團隊的技術進階史。公司創始團隊成員有幸以核心開發者的角色參與，從單機版的關係型數據庫（PostgreSQL），大規模並行處理（MPP）數據庫（Greenplum Database）到SQL on Hadoop解決方案（Apache HAWQ），以及最新的SQL on Cloud數據倉庫（HashData）。經過回顧這個技術演進的歷程，咱們將闡述如何一步一步地解決聯機分析（OLAP）系統低延遲、高併發以及擴展性問題。

PostgreSQL

因爲後面討論的全部的分佈式數據庫，包括Greenplum Database，Apache HAWQ以及HashData雲端數據倉庫，都是基於單機版關係型數據庫PostgreSQL的，因此咱們首先簡單介紹一下PostgreSQL，做爲後續討論的基礎。

每一個PostgreSQL數據庫的實例包含一個PostMaster的damon進程和多個子進程,包括負責寫出髒數據的BG Writer進程，收集統計信息的Stats Collector進程，寫事務日誌的WAL Writer進程，等等。

客戶端應用經過libpq協議鏈接到PostMaster進程；PostMaster收到鏈接請求後，fork出一個子進程Postgres Server來處理來自這個鏈接的查詢語句。Postgres Server進程的功能組件能夠分紅兩大類：查詢執行和存儲管理。查詢執行組件包括解析器、分析器、優化器以及執行器。在查詢執行過程當中，須要訪問和更新系統狀態和數據，包括緩存，鎖，文件和頁面等等。

Greenplum

做爲一個單機版的關係型數據庫，PostgreSQL更多地是做爲聯機事務處理（OLTP）系統使用的。固然，因爲其豐富的分析功能，不少企業也會基於PostgreSQL來構建數據倉庫，特別是在數據量不大的狀況下。可是，隨着數據量的增大，基於單機PostgreSQL構建的數據倉庫就沒法知足企業用戶對查詢響應時間的要求：低延遲。

爲了解決這個問題，MPP架構就被引入了。這是MPP架構分佈式數據庫的簡單示意圖。MPP數據庫經過將數據切片分佈到各個計算節點後並行處理來解決海量數據分析的難題。每一個MPP數據庫集羣由一個主節點（爲了提供高可用性，一般還會有一個從主節點）和多個計算節點組成。主節點和每一個計算節點都有本身獨立的CPU，內存和外部存儲。主節點負責接收客戶端的請求，生成查詢計劃，並將計劃下發到每一個計算節點，協調查詢計劃的完成，最後彙總查詢結果返回給客戶端。計算節點負責數據的存儲以及查詢計劃的執行。計算節點之間是沒有任何共享依賴的（shared nothing）。查詢在每一個計算節點上面並行執行，大大提高了查詢的效率。

咱們接下來要講的開源Greenplum Database就是基於PostgreSQL的MPP數據庫。對應到這個架構圖，每一個節點上面的數據庫實例能夠簡單的認爲是一個PostgreSQL實例。

咱們首先經過一條簡單的查詢，感性地認識一下Greenplum Database是如何執行一條查詢的。

這是一條簡單的兩表等值鏈接語句。其中，customer表是維度表，表數據以cust_id做爲hash分佈的key；sales表是事實表，在這個例子中，咱們能夠認爲它的表數據是round-robin的方式隨機分佈的，不影響查詢的執行。

每一個查詢執行是一個由操做符組成的樹。只看其中一個節點的話（如前面所說，每一個計算節點就是一個PostgreSQL的實例），爲了執行兩表的等值鏈接，咱們首先會將兩表的數據分別掃描出來，而後基於維度表customer創建hash桶。對於每一條從sales表掃描出來的紀錄，咱們都會到hash桶去查。若是知足匹配條件，數據鏈接結果；不然，直接pass。

如前面提到的，在Greenplum Database中，每張表的數據按照hash分佈或者隨機分佈打散到每一個計算節點上面。在這個例子中，因爲sales表是隨機分佈的，爲了正確執行基於cust_id的等值鏈接，生成的執行計劃會在table scan上面添加一個Redistribution motion節點。這個motion節點根據cust_id的hash值對數據做重分佈，相似MapReduce中的shuffling。因爲hash join操做是在每一個節點上面分佈式執行的，在將結果返回給客戶端的時候，須要在主節點上面執行彙總操做。Gather motion的做用就在於將每一個節點上面的中間結果集中到主節點上面。

對於這樣一個並行的查詢計劃，咱們會根據數據重分佈的操做將整棵查詢執行樹切割成不一樣的子樹。每一個子樹對應查詢計劃的一個階段，咱們稱爲slice。查詢計劃和slice是邏輯上的概念。

在物理層面，對應的是並行執行計劃和gang。gang指的是執行同一個slice操做的一組進程。MPP數據庫的一個重要特徵是，計算和存儲是緊耦合的。每一張表的數據打散存儲到每一個計算節點上面。爲了確保查詢結果的正確性，每一個計算節點都須要參與每條查詢的執行中。在Greenplum Database的架構設計中，對於每一個slice執行子樹，在每一個計算節點中會啓動一個相應的Postgres Server進程（這裏稱爲QE進程）來執行對應的操做。執行同一個slice的一組QE進程咱們稱爲gang。對應於查詢計劃中的三個slice，在執行計劃中，相應有三組gang。其中底下的兩個gang，咱們稱之爲N-gang，由於這種類型的gang中，包含了每一個計算節點上面啓動的一個QE進程。頂上的gang，咱們稱之爲1-gang，由於它只包含了一個進程。

通常來講，對於N張表的關聯操做，執行計劃中會包含2N個gang，其中1個1-gang，對應主節點上面的進程；2N-1個N-gang，對應每一個計算節點上面啓動的2N-1個QE進程。在這2N-1個gang中，其中N個用於掃描N張表，中間N-1個gang用於兩表關聯。也就是說，對於一條涉及到N表關聯操做的查詢語句，咱們須要在每一個計算節點上面啓動2N-1個QE進程。

不少用戶在評估Greenplum Database的併發數，也就是支持的最大同時運行的查詢數量，首先會擔憂主節點會成爲瓶頸，直觀緣由是全部用戶鏈接請求都首先會到主節點。其實，從資源使用的角度看，計算節點會首先成爲瓶頸。由於在執行涉及多表關聯的複雜查詢時，計算節點上面啓動的進程數量會遠多於主節點。因此，Greenplum Database系統架構決定了它不能支持很是高的併發訪問。

前面咱們簡單闡述了MPP分佈式數據庫的架構，並經過一條簡單的查詢語句解釋了分佈式的執行計劃。接下來咱們深刻討論一下Greenplum Database的重要組件。

首先是解析器。從使用者的角度看，Greenplum Database跟PostgreSQL沒有明顯差異。主節點做爲整個分佈式系統集羣的大腦，負責接收客戶鏈接，處理請求。跟PostgreSQL同樣，對於每個鏈接請求，Greenplum Database都會在主節點上面fork一個Postgres Server（咱們稱之爲QD）進程出來，負責處理這個鏈接提交的查詢語句。對於每一條進來的查詢語句，QD進程中的解析器執行語法分析和詞法分析，生成解析樹。雖然在一些DDL語句上面，Greenplum Database跟PostgreSQL會有一些語法上的小不一樣，例如建表語句能夠指定數據進行hash分佈的key，但整體上，在解析器這個組件上面，二者的差異不大。

優化器根據解析器生成的解析樹，生成查詢計劃。查詢計劃描述瞭如何執行查詢。查詢計劃的優劣直接影響查詢的執行效率。對於一樣一條查詢語句，一個好的查詢執行效率比一個次好的查詢計劃快上100倍，也是一個很正常的事情。從PostgreSQL到MPP架構的Greenplum Database，優化器作了重大改動。雖然二者都是基於代價來生成最優的查詢計劃，可是Greenplum Database除了須要常規的表掃描代價、鏈接和聚合的執行方式外，還須要考慮數據的分佈式狀態、數據重分佈的代價，以及集羣計算節點數量對執行效率的影響，由於它最終是要生成一個分佈式的查詢計劃。

調度器是Greenplum Database在PostgreSQL上新增的一個組件，負責分配處理查詢須要的計算資源，將查詢計劃發送到每一個計算節點。在Greenplum Database中，咱們稱計算節點爲Segment節點。前面也提過，每個Segment實例實際上就是一個PostgreSQL實例。調度器根據優化器生成的查詢計劃肯定執行計劃須要的計算資源，而後經過libpg（修改過的libpg協議)協議給每一個Segment實例發送鏈接請求，經過Segment實例上的PostMaster進程fork出前面提到過的QE進程。調度器同時負責這些fork出來的QE進程的整個生命週期。

每一個QE進程接收到從調度器發送過來的查詢計劃以後，經過執行器執行分配給本身的任務。除了增長一個新的稱謂Motion的操做節點（負責不一樣QE進程間的數據交換）以外，整體上看，Greenplum Database的執行器跟PostgreSQL的執行器差異不大。

MPP數據庫在執行查詢語句的時候，跟單機數據庫的一個重要差異在於，它會涉及到不一樣計算節點間的數據交換。在Greenplum Database系統架構中，咱們引入了Interconnect組件負責數據交換，做用相似於MapReduce中的shuffling階段。不過與MapReduce基於HTTP協議不同，Greenplum Database出於數據傳輸效率和系統擴展性方面的考慮，實現了基於UDP協議的數據交換組件。前面在解析執行器的時候提到，Greenplum Database引入了一個叫Motion的操做節點。Motion操做節點就是經過Interconnect組件在不一樣的計算節點之間實現數據的重分佈。

前面講到的解析器、優化器、調度器、執行器和Interconnect都是跟計算相關的組件，屬於無狀態組件。下面咱們再看一下跟系統狀態相關的組件。首先是，系統表。系統表負責存儲和管理數據庫、表、字段等元數據。主節點上面的系統表是全局數據庫對象的元數據，稱爲全局系統表；每一個Segment實例上也有一份本地數據庫對象的元數據，稱爲本地系統表。解析器、優化器、調度器、執行器和Interconenct等無狀態組件在運行過程當中須要訪問系統表信息，決定執行的邏輯。因爲系統表分佈式地存儲在不一樣的節點中，如何保持系統表中信息的一致性是極具挑戰的任務。一旦出現系統表不一致的狀況，整個分佈式數據庫系統是沒法正常工做的。

跟不少分佈式系統同樣，Greenplum Database是經過分佈式事務來確保系統信息一致的，更確切地說，經過兩階段提交來確保系統元數據的一致性。主節點上的分佈式事務管理器協調Segment節點上的提交和回滾操做。每一個Segment實例有本身的事務日誌，肯定什麼時候提交和回滾本身的事務。本地事務狀態保存在本地的事務日誌中。

介紹完Greenplum Database的查詢組件和系統狀態組件後，咱們再看看它是如何提供高可用性的。首先是管理節點的高可用。咱們採起的方式是，啓動一個稱爲Standby的從主節點做爲主節點的備份，經過同步進程同步主節點和Standby節點二者的事務日誌，在Standby節點上重作系統表的更新操做，從而實現二者在全局系統表上面的信息同步。當主節點出故障的時候，咱們可以切換到Standby節點，系統繼續正常工做，從而實現管理節點的高可用。

計算節點高可用性的實現相似於管理節點，可是細節上有些小不一樣。每一個Segment實例都會有另一個Segment實例做爲備份。處於正常工做狀態的Segment實例咱們稱爲Primary，它的備份稱爲Mirror。不一樣於管理節點日誌重放方式，計算節點的高可用是經過文件複製。對於每個Segment實例，它的狀態以文件的形式保存在本地存儲介質中。這些本地狀態能夠分紅三大類：本地系統表、本地事務日誌和本地表分區數據。經過以文件複製的方式保證Primary和Mirror之間的狀態一致，咱們可以實現計算節點的高可用。

HAWQ

Hadoop出現以前，MPP數據庫是爲數很少的大數據處理技術之一。隨着Hadoop的興起，特別是HDFS的成熟，愈來愈多的數據被保存在HDFS上面。一個天然的問題出現了：咱們怎樣才能高效地分析保存在HDFS上面的數據，挖掘其中的價值。4，5年前，SQL-on-Hadoop遠沒有如今這麼火，市場上的解決方案也只有耶魯大學團隊作的Hadapt和Facebook作的Hive，像Impala，Drill，Presto，SparkSQL等都是後來纔出現的。而Hadapt和Hive兩個產品，在當時不管是易用性仍是查詢性能方面都差強人意。

咱們當時的想法是將Greenplum Database跟HDFS結合起來。與其餘基於connector鏈接器的方式不一樣，咱們但願讓HDFS，而不是本地存儲，成爲MPP數據庫的數據持久層。這就是後來的Apache HAWQ項目。但在當時，咱們把它叫作Greenplum on Hadoop，其實更準確的說法應該是，Greenplum on HDFS。當時的想法很是簡單，就是將Greenplum Database和HDFS部署在同一個物理機器集羣中，同時將Greenplum Database中的Append-only表的數據放到HDFS上面。Append-only表指的是隻能追加，不能更新和刪除的表，這是由於HDFS自己只能Append的屬性決定的。

除了Append-only表以外，Greenplum Database還支持Heap表，這是一種可以支持增刪改查的表類型。結合前面提到的Segment實例的本地狀態，咱們能夠將本地存儲分紅四大類：系統表、日誌、Append-only表分區數據和非Append-only表分區數據。咱們將其中的Append-only表分區數據放到了HDFS上面。每一個Segment實例對應一個HDFS的目錄，很是直觀。其它三類數據仍是保存在本地的磁盤中。

整體上說，相對於傳統的Greenplum Database， Greenplum on HDFS架構上並無太多的改動，只是將一部分數據從本地存儲放到了HDFS上面，可是每一個Segment實例仍是須要經過本地存儲保存本地狀態數據。因此，從高可用性的角度看，咱們仍是須要爲每一個實例提供備份，只是須要備份的數據少了，由於Append-only表的數據如今咱們是經過HDFS自己的高可用性提供的。

Greenplum on HDFS做爲一個原型系統，驗證了MPP數據庫和HDFS是能夠很好地整合起來工做的。基於這個原型系統，咱們開始將它當成一個真正的產品來打造，也就是後來的HAWQ。

從Greenplum on HDFS到HAWQ，咱們主要針對本地存儲作了系統架構上的調整。咱們但願將計算節點的本地狀態完全去掉。本地狀態除了前面提到的系統表（系統表又能夠細分紅只讀系統表（系統完成初始化後不會再發生更改的元數據，主要是數據庫內置的數據類型和函數）和可寫系統表（主要是經過DDL語句對元數據的修改，如建立新的數據庫和表））、事務日誌、Append-only表分區數據和非Append-only表分區數據，同時還有系統在執行查詢過程當中產生的臨時數據，如外部排序時用到的臨時文件。其中臨時數據和本地只讀系統表的數據都是不須要持久化的。咱們須要考慮的是如何在Segment節點上面移除另外四類狀態數據。

Append-only表分區數據前面已經提到過，交給HDFS處理。爲了提升訪問HDFS的效率，咱們沒有采用Hadoop自動的HDFS訪問接口，而是用C++實現了原生的HDFS訪問庫，libhdfs3。針對非Append-only表數據的問題，咱們的解決方案就比較簡單粗暴了：經過修改DDL，咱們完全禁止用戶建立Heap表，由於Heap表支持更新和刪除。因此，從那時起到如今最新的Apache HAWQ，都只支持表數據的追加，不支持更新和刪除。沒有了表數據的更新和刪除，分佈式事務就變得很是簡單了。經過爲每一個Append-only表文件對應的元數據增長一列，邏輯EoF，即有效的文件結尾。只要可以保證EoF的正確性，咱們就可以保證事務的正確性。並且Append-only表文件的邏輯EoF信息是保存在主節點的全局系統表中的，它的正確性經過主節點的本地事務保證。爲了清理Append-only表文件在追加新數據時事務abort形成的髒數據，咱們實現了HDFS Truncate功能。

對於本地可寫系統表，咱們的作法是將Segment實例上面的本地可寫系統表放到主節點的全局系統表中。這樣主節點就擁有了全局惟一的一份系統表數據。查詢執行過程當中須要用到的系統元數據，咱們經過Metadata Dispatch的方式和查詢計劃一塊兒分發給每一個Segment實例。

經過上述的一系列策略，咱們完全擺脫了Segment節點的本地狀態，也就是實現了無狀態Segment。整個系統的高可用性策略就簡單了不少，並且也不須要再爲Segment節點提供Mirror了，系統的利用率大大提高。

數據的高可用交給了HDFS來保證。當一個Segment節點出故障後，咱們能夠在任意一臺有空閒資源的機器上從新創始化一個新的Segment節點，加入到集羣中替代原來出故障的節點，整個集羣就可以恢復正常工做。

咱們也作到了計算和存儲物理上的解耦合，往完全擺脫傳統MPP數據庫（例如Greenplum Database）計算和存儲緊耦合的目標邁出了有着實質意義的一步。

雖然在HAWQ 1.x的階段，咱們作到了計算和存儲物理上的分離，可是邏輯上二者仍是集成的。緣由是，在將本地表分區數據往HDFS上面遷移的時候，爲了避免改變原來Segment實例的執行邏輯流程，咱們爲每一個Segment指定了一個其專有的HDFS目錄，以便跟原來本地數據目錄一一對應。每一個Segment負責存儲和管理的數據都放在其對應的目錄的底下，並且該目錄底下的文件，也只有它自身可以訪問。這種HDFS數據跟計算節點邏輯上的集成關係，使得HAWQ 1.x版本依然沒有擺脫傳統MPP數據庫剛性的併發執行策略：不管查詢的複雜度如何，全部的計算節點都須要參與到每條查詢的執行中。這意味着，系統執行一條單行插入語句所使用的計算資源，和執行一條對幾TB數據進行復雜多表鏈接和聚合的語句所使用的資源是同樣的。這種剛性的並行執行策略，極大地約束了系統的擴展性和吞吐量，同時與Hadoop基於查詢複雜度來調度計算資源的彈性策略也是相違背的。

咱們決心對HAWQ的系統架構作一次大的調整，使其更加地Hadoop Native，Hadoop原生，而不只僅是簡單地將數據放到HDFS上面。當時，咱們內部成爲HAWQ 2.0，也就是你們如今在github上面看到的Apache HAWQ。

其中最重要的一步是，咱們但願計算和存儲不只物理上分離，邏輯上也是分離。數據庫中的用戶表數據在HDFS上再也不按照每一個Segment單獨來組織，而是按照全局的數據庫對象來組織。舉個例子，咱們將一張用戶表對應的多個數據文件（由於當往該表插入數據的時候，爲了提升數據插入的速度，系統會啓動了多個QE進程同時往HDFS寫數據，每一個QE寫一個單獨文件）放到同一個目錄底下，而不是像原來那樣，每一個QE進程將文件寫到本身對應的Segment目錄底下。這種改變帶來的一個直觀結果就是，因爲全部文件的數據文件都放一塊兒了，查詢執行的時候，根據須要掃描的數據量不一樣，咱們既可使用一個Segment實例去完成表掃描操做，也可使用多個Segment實例去作，完全擺脫了原來只能使用固定個Segment實例來執行查詢的剛性並行執行策略。

固然，HDFS數據目錄組織的改變只是實現HAWQ 2.0彈性執行引擎的一步，可是倒是最重要的一步。計算和存儲的完全分離，使得HAWQ能夠像MapReduce同樣根據查詢的複雜度靈活地調度計算資源，極大地提高了系統的擴展性和吞吐量。

咱們簡單比較一下HAWQ 1.x和HAWQ 2.0的資源調度。

左邊展示的是HAWQ 1.x在同時處理三個查詢（分別來自三個不一樣的會話）時的資源調度狀況。與傳統的MPP數據庫同樣，不管查詢的複雜度怎樣，每一個Segment實例都會參與到這條查詢的執行中。換句話說，每一個Segment實例都會啓動一個QE進程處理分配給它的任務。在這種狀況下，系統可以支持的併發查詢數量，跟集羣的計算節點數沒有任何關係，徹底由一個計算節點決定（這裏，咱們先不考慮主節點成爲瓶頸的問題）。一個4個節點的HAWQ集羣可以支持的併發查詢數量和一個400個節點的集羣是同樣的。

右邊展示的是HAWQ 2.0在一樣併發查詢下的資源調度狀況。和Hadoop的MapReduce同樣，咱們可以根據查詢的複雜度決定須要調度多少計算資源參與到每條查詢的執行中。爲了簡化闡述，咱們這裏假設每條查詢只須要兩個計算資源單元。並且，執行單元能夠根據資源管理器的調度算法分配到不一樣的物理計算節點上面。這兩點靈活性：計算資源的數量可變和計算資源的位置可變，正是HAWQ 2.0彈性執行引擎的核心。在這種狀況下，系統可以支持的併發查詢數量，跟集羣的計算節點數量呈線性關係：計算節點越多，系統可以支持的併發查詢數量越多（再次提醒，這裏，咱們先不考慮主節點成爲瓶頸的問題）。

因此，能夠說，HAWQ 2.0成功解決了傳統MPP數據倉庫中計算節點首先成爲吞吐量瓶頸的問題。同時，因爲並非全部計算節點都須要參與到每條查詢的執行中，HAWQ 2.0同時也解決了傳統MPP數據庫因爲單個計算節點性能降低直接影響整個集羣性能的問題（這致使MPP集羣不能包含太多的計算節點，由於根據機率，集羣節點到達必定值後，出現單個計算節點性能降低的機率將會很是高），從而也很大程度上解決了擴展性問題。

雲端數據倉庫

經過將計算和存儲完全分離成功解決了計算節點成爲系統吞吐量瓶頸的問題後，如今系統的惟一瓶頸就剩下主節點。

如前面提到，主節點的功能主要分紅兩類：元數據管理，包括系統表存儲和管理、鎖管理和分佈式事務等等，和計算資源調度管理和執行。前者咱們能夠當作是狀態管理，後者是沒有狀態的組件。經過將狀態管理提取出來成爲單獨一個功能層，咱們讓主節點跟計算節點同樣變得沒有狀態。這樣，咱們可以根據系統併發查詢的變化，動態增長或者減小主節點的數量。這個設計借鑑了Hadoop YARN的設計，將原來的Job Manager的功能分紅了Resource Manager和Application Manager，從而解決Hadoop集羣吞吐量的問題。

這是一個雲端數據倉庫的架構圖。其實，咱們在HashData但願經過雲端數據倉庫解決企業用戶使用數據倉庫時碰到的多種難題，包括商業上和技術上。在這裏，咱們只關注技術上的。

在這個系統架構中，咱們將管理即元數據、計算和存儲三者分離了，每一層都能單獨動態伸縮，在解決系統吞吐量和擴展性問題的同時，提供了多維度的彈性。

咱們利用雲平臺的對象存儲服務，如AWS的S3和青雲QingCloud的QingStor，做爲系統數據的持久層。除了按需付費的經濟特性外，雲平臺的對象存儲服務在可擴展性、穩定性和高可用性等方面遠勝於咱們本身維護的分佈式文件系統（如HDFS）。雖然對象存儲的訪問延遲遠高於本地磁盤訪問，可是咱們能夠經過本地緩存的策略很大程度減輕延遲問題。

一樣的，咱們利用雲平臺提供的虛擬機做爲咱們的計算資源，也可以必定程度上實現資源的隔離，從而保證不一樣的工做負載之間沒有相互影響。

雲平臺提供的近乎無限的計算和存儲資源（相對於數據倉庫應用來講），使得雲端數據倉庫可以存儲和處理的數據達到一個全新的高度。

總結

最後，咱們作一個簡單的總結。從PostgreSQL到Greenplum Database，咱們經過大規模並行處理（MPP）技術，實現了處理海量數據時的低延遲目標。從Greenplum Database到Apache HAWQ，經過計算和存儲分析的策略，咱們提高了系統的併發處理能力和擴展性。從Apache HAWQ到Cloud Data Warehouse，咱們藉助雲平臺近乎無限的計算資源和存儲資源，以及管理、計算和數據三者分離，還有計算資源嚴格隔離，咱們可以取得近乎無限的併發處理能力和擴展性。

MPP數據庫採起的是流水式的執行引擎，中間的每一個階段是不帶檢查點的。這意味着，只有有一個參與到查詢執行的QE進程出錯，整條查詢將會失敗，只能從頭開始從新執行這條查詢。而咱們知道，當參與到查詢執行的QE進程達到必定數量的時候，QE進程出錯將是必然的，特別是在一個資源共享的環境中。這時候，即便是從新提交查詢重跑，失敗仍是必然的。換句話說，咱們幾乎沒法成功執行須要調度大量計算資源的查詢。

展望將來，咱們但願實現帶檢查點的流水式執行引擎，從而使得系統可以處理任意大的查詢（單個查詢須要同時調度成千上萬的計算資源）。