介紹：
SQL over Hadoop 領域的早期採用者現在正在創建大型數據庫來存儲他們更珍貴的商品和數據。 IBM在2014年10月發佈了第一個（也是唯一一個）經過獨立審計的Hadoop-DS基準測試時預測了這一趨勢.Hadoop-DS是行業標準TPC-DS基準測試的衍生產品，經過定製，可以更好地匹配SQL over Hadoop空間的功能在Data Lake環境中。那時，IBM使用10TB的比例因子來比較Big SQL與其他領先的SQL Over Hadoop解決方案，即Hive 0.13和Impala 1.4.1。從那時起，所有產品都在性能和可擴展性方面取得了重大進步。 HortonWorks和Cloudera也投入了大量資金來豐富他們對SQL語言的支持（IBM已經在那裡）。
Spark已成為開源社區中分析的最愛，Spark SQL允許用戶使用熟悉的SQL語言向Spark提出問題。因此，有什麼更好的方法來比較Spark的功能，而不是通過它的步伐，並使用Hadoop-DS基準來比較性能，吞吐量和SQL與Big SQL的兼容性。由於這是2017年，Data Lakes日漸變大，我們選擇使用100TB的比例因子。
本研究將再次強調SQL over Hadoop引擎的需求，該引擎不僅快速高效，而且更重要的是可以成功地對大數據執行復雜查詢。在選擇SQL over Hadoop解決方案時，性能不是唯一的因素。該解決方案還需要由成熟且強大的運行時環境進行備份。成本仍然是採用SQL Over Hadoop解決方案的企業的主要吸引力之一（特別是與傳統的RDBM相比），但無論出於何種原因，失敗的查詢將嚴重影響生產力並降低這些SQL相對於Hadoop解決方案的成本效益。沒有交付。
摘要
在項目過程中，我們發現Big SQL是唯一能夠在100 TB下執行所有未修改的99個查詢的解決方案，可以比Spark SQL快3倍，同時使用更少的資源。 這些事實使我們得出結論，使用Big SQL的Data Professional比使用Spark SQL的數據提高了3倍。
測試環境：
Big SQL和Spark SQL測試都在同一個集群上執行。 該集群的構建基於Spark; 也就是說，它有大量的內存和SSD取代了傳統的旋轉磁盤。
使用了28節點集群，包括：
- 2 management nodes (Lenovo x3650 M5), collocated with data nodes
- 28 data nodes (Lenovo x3650 M5)
- 2 racks, 20x 2U servers per rack (42U racks)
- 1 switch, 100GbE, 32 ports, 1U, (Mellanox SN2700)
每個數據節點包括：
- CPU: 2x E5-2697 v4 @ 2.3GHz (Broardwell) (18c) Passmark: 23,054 / 46,108
- Memory: 1.5TB per server, 24x 64GB DDR4 2400MHz
- Flash Storage: 8x 2TB SSD PCIe MVMe (Intel DC P3700), 16TB per server
- Network: 100GbE adapter (Mellanox ConnectX-5 EN)
- IO Bandwidth per server: 16GB/s, Network bandwidth 12.5GB/s
- IO Bandwidth per cluster: 480GB/s, Network bandwidth 375GB/s
配置和調整：
產品的配置和調整由兩個不同的團隊進行; IBM的Big SQL性能團隊和Spark SQL性能團隊。
Spark團隊使用了最新發布的Spark SQL 2.1版。 Spark的調優符合Hadoop-DS規範中規定的規則，但有一個關鍵的例外。傳遞給Spark SQL shell的執行程序屬性的數量針對單流和4流運行進行了不同的調整。 4流運行中的每個流都傳遞了執行器值，該值是用於單個流運行的值的四分之一。這阻止了4流中的任何一個流都抓住了集群上的所有執行槽，這實際上會導致每個查詢串行執行。雖然這很簡單，有些人可能會說邏輯調整，但實際上不可能在生產集群上有效地執行此操作，在生產集群中不會知道併發執行查詢的數量。但是，該團隊決定，如果沒有這一調整，就無法與Big SQL進行公平的比較。
Big SQL Worker
Big SQL團隊使用了Big SQL版本4.3的技術預覽版。技術預覽包含對新功能的支持，其中每個物理節點可以託管多個Big SQL工作進程（以前，每個物理節點上只允許一個Big SQL工作進程）。單個物理節點上的多個Big SQL工作程序在Big SQL環境中提供了更大的操作並行化，從而提高了性能。考慮到測試集群中計算機的大量內存和CPU資源，團隊將每個物理節點配置為包含12個Big SQL worker - 如圖1所示。
與Spark SQL不同，Big SQL不需要基於併發查詢流的數量進行微調，因此使用了單流和4流運行的相同配置。這是可能的，因為Big SQL具有成熟的自治，包括：
- 自調整內存管理器（STMM），它根據查詢併發性動態管理消費者之間的內存分配
- 一個複雜的工作負載管理器（WLM），可以控制工作負載優先級，有助於維持一致的響應時間並實施SLA
- 在查詢執行時自動調整並行度以考慮系統活動
這些都是關鍵功能，可以解決調整Big SQL的痛苦 - 無論是在基準測試環境還是現實環境中 - 多年來，組織一直認為這些功能在關係數據庫中是必不可少的，以支持生產環境。那麼為什麼在Big SQL中找到這些功能而在Hadoop解決方案中找不到大多數其他SQL？簡而言之，這是因為IBM圍繞我們現有的關係數據庫技術（已經在生產系統中運行了25年）構建了Big SQL的核心。因此，Big SQL具有強化，成熟且非常高效的SQL優化器和運行時，以及一組支持生產級部署的功能 - 這些是Big SQL世界級可伸縮性和性能的關鍵。
對於此基準測試，大多數Big SQL調優工作都集中在單個節點上共存的多個Big SQL工作者（這是此功能首次在此規模上進行了道路測試）。此功能在Big SQL v4.3 Technology Preview中可用，並且可以在安裝後通過Ambari手動添加邏輯Big SQL worker。 Big SQL工程團隊正在利用從本練習中獲得的經驗來改進自動化，併為Big SQL v4.3版本設置有意義的開箱即用默認值。因此，Big SQL客戶不必自己進行任何調整。 Spark SQL團隊的經驗被用於創建一組最佳實踐。在Spark SQL具有一組成熟的自我調整和工作負載管理功能之前，必須手動應用這些最佳實踐。
查詢執行：
使用100TB數據，使用Big SQL v4.3在4個併發查詢流中成功執行了源自TPC-DS工作負載的所有99個查詢（總共創建了396個查詢）。在第一次運行三個Big SQL查詢時，執行時間比預期的要長。使用統計視圖和列組統計信息調整這些查詢。這些獨特的功能對Big SQL客戶來說非常寶貴;允許他們收集有關複雜關係的詳細信息，這些信息通常存在於現實數據中，從而提高性能。跨比例因子的Spark查詢失敗
圖3：跨不同比例因子的Spark SQL查詢
圖4：Spark SQL查詢失敗的分類
雖然Spark SQL v2.1可以在1GB和1TB上成功執行所有99個查詢（並且自v2.0以來已經能夠執行），但是在10TB時兩個查詢失敗，並且在100TB時失敗的次數明顯更多。在花費大量精力調整Spark（由Spark工程師，而不是Big SQL工程師）之後，總共可以在100TB的4個流中成功執行83個查詢。為了確保蘋果與蘋果的比較，這組83個查詢被用作比較Big SQL與Spark SQL性能的基礎。圖4：100TB的Big SQL vs Spark SQL查詢細分
圖5：100TB的Big SQL和Spark SQL查詢細分
Spark故障可分為2大類; 1）查詢未在合理的時間內完成（少於10小時），以及2）運行時故障。此外，幾乎一半（7）的Spark SQL查詢在100TB時失敗，本質上是複雜的。事實的這種組合表明Spark SQL在更大規模的因素下與更復雜的查詢鬥爭;因為Spark是一種缺乏現代RDBMS成熟度的相對較新的技術，所以這應該不會讓人感到驚訝。這些發現也與2014年最初的Hadoop-DS工作一致; Hive和Impala都在使用複雜的查詢（所有這些都是10TB），但Big SQL能夠成功執行所有99個查詢，在30TB的4個流中。
數據專業人員或任何用戶的主要抑制因素是浪費寶貴的時間將有效查詢重寫為SQL解釋器可以理解的表單，以及執行引擎可以成功完成的表單。重要信息本研究中的數據表明，使用Spark SQL的Data Professional將花費寶貴的時間重新編寫或調整，每10個查詢中有1個或2個（確切地說是16％）。不幸的是，對於不成熟的SQL引擎，尤其是SQL over Hadoop空間中的那些，通常就是這種情況。在10TB的原始Hadoop-DS評估中，Hive和Impala首先突出了這個問題，今天仍然適用於Spark SQL。值得注意的是，對於許多SQL over Hadoop引擎，以較低比例因子成功執行查詢並不能保證真正的大數據成功。
構建一個100TB的數據庫
毫無疑問，100TB這是一個大數據工作負載 - 最終數據庫包含超過五萬億行：
大事實表被分區以利用Big SQL v4.2以後的新“分區消除串聯連接密鑰”功能。所有銷售表都在各自的'* _SOLD_DATE_SK'列上進行了分區，並在各自的'* _RETURN_DATE_SK'列中返回表。以這種方式進行分區符合原始TPC-DS規範，並允許在查詢執行期間刪除分區 - 這可以極大地提高查詢的時間和效率。圖7：100TB數據庫構建
圖7：100TB數據庫構建時間（秒）
數據庫構建包括兩個不同的操作，即加載階段和統計信息收集階段。加載階段從數據生成器生成的原始文本中獲取數據，並將其轉換為Parquet存儲格式。 Parquet是Big SQL和Spark SQL中查詢的最佳存儲格式，是這些測試的理想選擇。加載階段對於Big SQL和Spark SQL都是通用的，只需要超過39個小時即可完成。
39小時中的大部分用於加載STORE_SALES表的NULL分區（SS_SOLD_DATE_SK = NULL）。事實證明，STORE_SALES表在空分區上嚴重偏斜（大小約為570GB，而其他分區大約為20GB）。由於查詢是重複執行的，而數據庫構建是一次性操作，因此兩個團隊都沒有專門用於提高負載性能的資源。但實際數據集中的嚴重偏差很常見。此數據集中所選分區列的嚴重偏差給執行某些更復雜的查詢帶來了挑戰。工程團隊致力於改進Big SQL Scheduler以應對這些挑戰，這些改進將在Big SQL v4.3中提供。
收集統計信息使Big SQL基於成本的優化器能夠就最有效的訪問策略做出明智的決策，並且是Big SQL可以執行具有領先性能的所有99個TPC-DS查詢的關鍵原因。目前，Spark SQL不需要收集相同級別的統計信息，因為它的優化程序還不夠成熟，無法使用這些詳細的統計信息。但是，隨著Spark優化器的成熟，它對詳細統計數據的依賴性會增加，收集所述統計數據的時間也會增加，但查詢過程時間也會隨之改善。
比較Big SQL和Spark SQL性能：
在現實生活中，單個用戶不能單獨使用組織的Hadoop集群。因此，我們專注於比較4個併發查詢流中Big SQL和Spark SQL的性能。為了進行蘋果與蘋果的比較，生成的工作負載僅包括在合理的時間內（少於10小時）在Spark SQL中成功完成的83個查詢。刪除Spark SQL無法在10小時內完成的查詢會使結果偏向於Spark，因為保留四個超時的查詢幾乎會使Spark SQL執行時間翻倍。
圖8比較了在Spark SQL和Big SQL中完成所有4個流（總共332個查詢）的83個查詢所用的時間，以及Big SQL在4個流中完成所有99個查詢所用的時間（總計396個查詢）。 Spark SQL花了超過43個小時來完成測試，而Big SQL在13.5個小時內完成了相同數量的查詢 - 使Big SQL比Spark SQL快3.2倍。
圖8：4個查詢流的100TB工作負載經歷時間
圖8：100TB的工作負載經歷時間
事實上，Big SQL能夠完成一個4流工作負載，每個流執行99個查詢的完整補充，幾乎比Spark SQL每個流執行83個查詢快2倍。當您考慮到Spark SQL無法執行的16個查詢中的7個是工作負載中最複雜的查詢時，這會更令人印象深刻。
雖然對於Big SQL來說令人印象深刻，但如果查詢集包含來自99的原始集合中的那些查詢，那麼性能差異會大得多，這些查詢在10小時後在Spark SQL中超時。
重要信息將這些結果輸入到現實環境中意味著使用Big SQL的數據專業人員的效率比使用Spark SQL的數據專業人員高三倍。圖9：平均CPU消耗的比較
圖9：100TB的4流的平均CPU消耗
對整個群集的CPU消耗的分析表明，Big SQL在工作負載持續時間內平均為76.4％，Spark SQL為88.2％。雖然Big SQL和Spark SQL之間消耗的用戶CPU百分比大致相同，但Spark SQL的系統CPU幾乎是Big SQL的3倍。系統CPU週期是不合需要的CPU週期，它們沒有代表您的應用程序執行有用的工作。注意：兩種產品的IO等待CPU時間可以忽略不計。
當然，由於Spark SQL測試需要花費3倍的時間才能完成，因此在執行工作負載中的所有332個查詢的過程中，Spark SQL實際上消耗的CPU週期比Big SQL多3倍，系統CPU週期比Big SQL多9倍 - 突出顯示隨著Big SQL優化器和運行時的成熟，效率更高。 Big SQL不僅比Spark SQL快3.2倍，而且使用更少的CPU資源也實現了這一點。
圖10：100TB（每個節點）的4個流的平均I / O速率
在檢查測試期間進行的I / O量時，Big SQL的效率也會突出顯示。 Spark SQL的平均讀取速率平均比Big SQL大3.6倍，而其寫入速率平均高出9.4倍。在測試期間推斷平均I / O速率（Big SQL比Spark SQL快3.2倍），然後Spark SQL實際讀取的數據幾乎是Big SQL的12倍，並且寫入數據增加了30倍。
圖11：100TB（每個節點）的4個流的最大I / O速率
有趣的是，Big SQL具有更高的最大I / O吞吐量，表明在需要時，Big SQL可以通過I / O子系統提高吞吐量，而不是Spark SQL。
讀取/寫入的數據量的巨大差異，以及Big SQL可以更加強大地驅動I / O子系統的事實，是Big SQL中更高效率的簡單但有效的指標。
重要信息將這一點重新回到現實生活中，我們的Data Professional不僅使用Big SQL提高了三倍的效率，而且使用更少的資源來完成工作，這反過來又允許其他數據專業人員在集群上運行更多分析同時.
是什麼讓這份報告有所不同？
已經有越來越多的基於Hadoop解決方案的SQL基準測試報告;一些顯示解決方案x比y快許多倍，而其他人表明y比x快 - 但兩者都是如此？我是許多競爭基準的老手，我可以誠實地說，通過定義測試的範圍來贏得和失去基準。每個供應商都會最大限度地影響基準規範，以突出其自身產品的優勢以及競爭對手的弱點。這正是今天SQL over Hadoop空間正在發生的事情，也是組織面對這些解決方案時過多的衝突性能信息的原因。那麼，是什麼讓這份報告與眾不同：
比例因子 - 畢竟，我們正在談論大數據！這是唯一一份以100TB發佈的報告。以較小比例因子發佈的許多其他報告甚至不使用整個數據集。
它很全面。它不會挑選查詢來強調一種解決方案相對於另一種解決方案的好處。根據最初的Hadoop-DS基準測試，IBM將蘋果與蘋果進行了比較，比較了適用於這兩種產品的所有查詢。
這些產品由兩個競爭（但友好）的IBM團隊調整，兩者都在努力突出其產品的優勢。最後，兩個團隊的經驗將使他們各自的產品受益。
它遵循Hadoop-DS規範的規則（基於行業標準TPC-DS基準）
摘要：
毫無疑問，Spark SQL在很短的時間內已經走過了漫長的道路。 Spark SQL可以在100TB完成99個查詢中的83個，這是開源社區推動這個項目的證明。但是，仍然沒有替代產品的成熟度，而Big SQL的優勢在於它建立在IBM的數據庫技術之上。正是這種譜系在SQL over Hadoop空間中將Big SQL提升到了其他供應商之上。
圖12：作者在Hadoop Marketplace上的SQL視圖
圖12：作者在Hadoop Marketplace上的SQL視圖
作者對此空間的看法雖然相當不科學，如圖12所示.Big SQL優於Hadoop解決方案的開源SQL包，主要是因為Big SQL繼承了IBM數據庫的大量豐富功能（和性能）。遺產。假設Spark SQL保持其當前的勢頭，它可能最終超過Big SQL的速度，可擴展性和功能。然而，隨著技術的成熟，它們的改進速度會慢下來 - 畢竟，對於一年前的產品而言，僅僅因為在產品生命的早期階段，將十年的產品改進10倍就更容易了 - 酒吧的週期要低得多。
總而言之，這份報告顯示了Big SQL：
可以在100TB，4個併發流中執行所有99個TPC-DS查詢，以及
可以這樣做至少比Spark SQL快3倍，而且
使用較少的群集資源來實現此類領先的性能。
但對於考慮購買SQL over Hadoop解決方案的組織來說，這意味著什麼呢？重要的是，簡單來說，這意味著Big SQL使他們的數據專業人員和業務分析師的工作效率（至少）提高了3倍。使用Big SQL可能需要3個小時才能完成深度分析，使用Spark SQL需要9個小時（或一個工作日）。在一天內，Big SQL用戶可以使用不同的輸入組合運行3次分析，以模擬不同的場景。使用Spark SQL完成相同的分析至少需要3個工作日;可能更長，因為查詢無法完成的可能性更高，調整Spark SQL查詢所需的持續時間通常更長。
我們還提供YouTube視頻(https://www.youtube.com/watch?v=M5zqykmEu9U)，詳細介紹了我們的體驗。
閱讀更多 智能時刻 的文章
