Oracle Parallel Execution解決的問題是：在shared-disk架構下，如何進行大查詢。
整體思路是：存儲上是共享的，記憶體中是MPP share-nothing的計算模型。
Oracle PX基于shared-disk做了2大優化：
- 動态掃描資料，解決資料傾斜問題；
- full partition-wise join，加速分區表join；
此外，Oracle是OLTP型資料庫，沒有按照AP性能最大化來設計PX，在優化器和執行器上和MPP系統都有比較大的不同：
- 優化器：Oracle PX的優化器是基于TP優化器的改進，優化器先按照非PX模式執行計劃的探索，然後在此基礎上插入DFO，資料分布等邏輯，而不是像GPORCA等為AP重新設計的cascade優化器；
- 執行器：2-DFO排程，非全流水線排程，節省PES程序資源，防止對TP造成太高的資源競争；
下面是正文：
ABSTRACT
Oracle7基于shared-disk架構初步實作了并行執行，Oracle 10g重構了并行執行架構實作了全局并行計劃樹，更易于維護和對SQL特性的擴充，加速了Oracle的并行執行的演進。
1. Introduction and Overview
并行執行是處理大規模資料的關鍵技術。一個先進的執行引擎能夠支援節點的彈性擴充，動态的申請和釋放。
Oracle 10g是基于shared-disk，每個節點可以通路所有的資料，資料無需事先分區。
通過優化器産生高性能的并行計劃樹以及Parallel Execution執行期優化（簡稱PX）能夠把負載打散在幾個節點上，同時降低節點間網絡開銷。對關鍵資源比如記憶體以及鎖等通過execution-constructs做限制。
Oracle 10g的PX引入了PSC機制（Parallel Single Cursor)，各個執行節點共享同一份計劃樹。解決了之前使用Oracle PX時的手工運維管理，手工監控，手工性能診斷等問題。
2. Concepts and key abstractions
Oracle PX支援兩種并行機制：intra和inter。
1. intra：同一個節點，通過共享記憶體通信；
2. inter：跨節點，通過網絡通信；
由PEC（Parallel Execution Coordinator）和PES（Parallel Execution Server）組成。
Oracle PX支援所有SQL功能：
1. relation操作符；
2. DML，DDL，分區表；
3. bulk load（外表）；
4. AP類SQL；
5. data mining；
PEP（parallel execution plan）由4部分組成：
1. Dataflow operators（DFOs），由多個row source組成，類似slice，fragment的概念；
2. Table Queues（TQs），類似motion，shuffle，Exchange的概念；
3. GRA（granule interators控制水準動态切分表），shared-disk架構特有的功能，一個woker可以從其他worker上steal任務；
4. Parallelizer row source（控制并行度）；
3. Parallel Single Cursor Model
在PSC（Parallel Single Cursor）模型中，使用單個全局的plan樹表達并行執行所需的所有資訊。計劃樹由PEC生成，PEC和PES同時排程執行該計劃樹。
3.1 Generation of a Single PEP
先生成邏輯計劃樹，然後再生成實體計劃樹
3.1.1 邏輯優化
-
first pass
考慮join順序；
考慮access nethod；
考慮開啟并行的代價：節點數，每個對象的分區數，分布方式；
-
second pass：
計算最優的distribution算法，使得plan被parallel化；
3.1.2 實體優化：
把1中的邏輯計劃中，相關的算子（row source）組織成DFO，考慮clustering，排序屬性，data-frag特性；
這個階段不會考慮DOP（應該啟動多少個并行度），優化器對并行的感覺和share-nothing的引擎如：DB2-PE，Teradata類似。
和MPP的火山全流水模型不同的是，Oracle的并行的程序數目是固定的：2倍的DOP。
所有PES程序分成2個集合，每個集合下面有DOP個PES程序。執行時一個集合做為生産者，一個集合做為消費者；
生産者執行完目前DFO算子之後，切換成消費者；
原來的消費者，變成了生産者；
3.2 Implication of a Single Global PEP
由于并行需要在多個PES程序之間共享DFO計劃，在經過實體優化之後得到一個可執行的計劃樹後，大多數DB的并行執行引擎，會使用中間語言或者更進階别的SQL結構來表達DFO樹（序列化和反序列化），Oracle在實踐中發現随着執行引擎不斷的疊代和增大，中間語言和SQL表達DFO的邏輯維護異常複雜，需要時刻維護SQL和plan的序列化和反序列化相關邏輯群組件的一緻性：
1. 中間語言：每個DFO用中間語言表達和執行過程極易出錯（一旦出錯，整個大查詢終止）；
2. 使用SQL描述DFO：先生成計劃樹，再把一個個DFO翻譯成SQL，DFO是實體執行層面的樹，SQL是聲明式語言，無法建立一一對應的關系；
Oracle的并行執行引擎的做法是：
1. QC分發原始的SQL給PES程序組；
2. 每個節點上的一個PES程序再執行一次優化器生成plan；
3. 該節點上其他PES程序直接使用生成的plan；
好處：
1. 提升并行查詢期間的管理和監控：所有的并行相關結構在實體計劃中也被抽象成了算子（row source）；每個算子的統計（記憶體，消息數，負載傾斜）等可以記錄在算子上，最後可以把所有PES程序上的所有算子做聚合，得到計劃樹在多個節點上的執行情況；
2. 支援新的px算子時，無需修改序列化和反序列化相關的相容問題，隻要定義新算子的相關屬性即可（類似單機算子）；
3. 代碼可維護性，友善調試，同時減少中間plan樹的記憶體；
4. Execution of a Parallel Single Cursor
- PEC和PES共享相同的plan；
- PEC先給PES發送排程DFO的控制資訊（啟動PES程序組）；
- PES掃描一個fragment info，通過GRA算子實作，每次消耗完一個granule就向PEC請求下一個granule（比如：一個granule代表一批block），生産的資料往對端PES消費者程序組發送，隻有消費程序組消費完了後，才請求後續的granule。通過這種方式實作了動态的負載均衡；
在shared-nothing的系統中，每個表都必須使用分區存儲，是以每個節點隻能通路一個分區的資料（Teradata和GP預設是Hash的方式）。
排程器必須感覺資料分區和節點的靜态的映射關系，一個分區上的資料不能被其他節點通路。
Oracle PX不要求資料一定是分區存儲的，Oracle的分區表隻是用來高可用和性能，Oracle的PX引擎不受使用者如何分區的限制（實際上分區的使用應該僅僅考慮業務上的特性，而不需要和性能綁定）。
Oracle的PX同樣會對分區做優化：Full Partition-wise join，每個PES程序隻掃描2個表的特定的分區資料直接join，而不用和其他PES程序之間互動資料。而且任何一個PES都可進行partition-wise join，是以底層是共享存儲。
4.1 Cluster-aware PX
4.1.1 partition-wise join
在優化器階段，考慮能啟動的PES數目，以及query中掃描到的分區數目，盡量的在資料的流動的垂直方向進行切分，以減少橫向的資料流動。
2個表分别有4個分區表，為了減少資料的橫向流動使用partition-wise join。每個節點處理2個成對的分區表。
partition-wise join時，一個PES程序隻處理一個分區表，最大的并行度是有限制的，比如上圖中，DOP不能超過4。
也許使用更多的DOP能提高整體性能，多個DOP同時掃描一個分區表，這樣就需要橫向的資料流動了，是以，最終應該通過優化器來決定DOP的數目。
和shared-nothing的系統又本質的差別，shared-nothing的并行度是固定的，一個程序隻處理一個分區表。
4.1.2 px hash join
下圖是DOP=8，一共16個PES程序的執行過程。8個生産者8個消費者，生産者在發送資料時需要根據join key進行hash（這個過程叫重分布），幾個PES生産程序共同掃表一個分區表。
4.1.1 hybrid partition-wise join
在partition-wise中，如果分區數目比較少，那麼就無法啟動更多的DOP來計算。
hybrid的模式：把PES程序根據分區表的數目進行分組。多個PES程序處理partition-wise join中的一對分區表。1個分區表的多個PES程序之間需要shuffler（如果在一台機器上，無需網絡及，直接sharememory），而分區表之間的PES程序組不需要；
好處是：無需all node data tansform，尤其是有大量的小節點；
hybrid模式：
1. 可以看做是， partition-wise join執行模式的擴充，partition-wise join中一個PES程序處理一個分區，現在是多個PES程序處理一個分區；
2. 也可以看做是，對普通PX執行的限制，PES之間增加一個映射關系，使得集合内部是普通的PX執行；
hybrid模式通過PES-mapper機制來實作：
1. 根據實體限制（分區表），把pes分成組，組之間無聯系，組内在一台機器上，通過共享記憶體通信；
2. 優化器提供一個PES mapper函數，每行資料經過PES mapper之後找到相應的組内的消費者PES程序；
PES-mapper優化：表現如同share-nothing，同時可以利用shareddisk來負載均衡；
PES Mapper方式類似MPP中：一個分區啟動多個worker。
4.2 PM Performace
PES mapper機制提升30%，pm機制保證節點間沒有資料流動，可以友善的擴充節點數。
4.3 Resource-Aware PX
PX是資源消耗性查詢，不能影響正常的TP查詢，是以PX需要做嚴格的資源管理：
1. 記憶體：統計每個節點記憶體情況，動态配置設定DOP，比如：對分區表執行parallel INSERT，可以每個PES程序處理一個分區，但是如果分區特别多，PES就會很多，記憶體占用就會很大，PES mapper把一個PES處理多個獨立的分區表；；
2. 鎖：parallel DELETE/UPDATE在并行執行時會對同一個block上鎖，PES mapper機制限制每個object被上鎖的次數，控制PES數目；
3. 自适應DOP和PES配置設定：
1. 先确定參與px的節點：計算節點按照業務編号，支援隻在固定node上服務固定業務的sql，
2. 确定inter和intra；
4. granule：配置設定unit時，考慮data locality和affinity；也可以根據SQL特點，配置設定unit；
5. A feature-rich Parallel Engine
5.1 Flexible data distribution and pipeline
如果多個表join後的結果集進行group-by和order-by，那麼優化器會考慮把hash重分布替換成range分布模式（Oracle獨有的技術），同時消除底層DFO的order-by；
ETL場景，對table function的輸入使用px掃描：
1. 多PES程序掃描一個分區；
2. 掃描時外部資料進行granule切分（動态平衡）；
3. 再按照partition by傳給對應執行function的PES程序組；
4. 如果輸入的hash和導入新表的partition by的hash是一緻的，無需資料重分布；
5.2 Cost-based Parallelization of Subqueries
Oracle支援大部分子查詢轉join和agg的邏輯優化技術。
對于實在不能去關聯化的子查詢，可以對子查詢部分獨立的啟動并行度PX或者串行執行，這取決于啟動px的代價；
5.3 Recursive and Interative Computation
通過DFO之間傳輸中間結果集的temp table，以支援px+遞歸；
5.4 Load-Balanced Table Queues
對資料分布敏感的分布政策，進行動态的sampling，防止range傾斜；
6. Conclusions
本文講解了Oracle10g的并行執行引擎技術：
1. Oracle10g對OPS進行了重構，替代了原來使用DSL對plan進行序列化和反序列化，PEC和PES節點之間傳輸SQL，每個節點獨自執行優化得到single-plan，每個節點上不同PES共享一份single-plan；
2. 執行模型和資料分布解耦合。底層資料是shared-disk存儲，而不是share-nothing系統中的分片存儲。PX可以在任意節點掃描任意資料集合，是以PES-mapping機制可以更加靈活的在PES程序和節點上進行重新安排，充分的考慮叢集記憶體，鎖，網絡等因素；
3. Oracle10g借助PX架構對大量的SQL場景進行了并行優化；