sparksql工作原理剖析.png
執行計畫
只要是在資料庫型別的技術裡面，比如傳統的mysql、oracle等，包括現在大資料領域的資料倉儲，比如hive，它的基本的sql執行的模型，都是類似的，首先都是要生成一條sql語句的執行計畫
比如，select name from students => 從**去查詢，students表，在那個檔案裡，從檔案中查詢哪些資料，比如說是name這個列，還有，查詢時，是否對錶中資料進行過濾和篩選，複雜的sql，需要多表join，此外還有，執行計畫還涉及到如果掃瞄和利用索引
邏輯的執行計畫
邏輯的執行計畫，更多的是，偏向於邏輯，比如說，from table students => filter ...=>select name...
基本上，邏輯計畫，都是採用tree，樹形結構的
優化的邏輯計畫
如傳統的oracle資料庫，通常會生成多個執行計畫，然後，有乙個優化器，針對多個計畫，選擇乙個最好的計畫，而spark sql這的優化，指的是，剛生成的執行計畫中，有些地方的效能使顯而易見的不好，比如
有乙個sql語句 select name from (select ... from ...) where ... = ...，此時，在執行計畫解析出來的時候，還是按照它原封不動的樣子，來解析可以執行的計畫的，但是optimizer，在這裡，就會對執行計畫進行優化，比如說，發現where條件，其實可以放到子查詢裡面，這樣，子查詢的資料量大大變小，可以優化執行速度，此時，可能就會變成這樣，select name from (select ... from ... where ... = ...)
物理計畫
物理計畫，就是非常「接地氣」的計畫了，就是說，已經知道從哪個檔案讀取什麼資料，從那幾個檔案中讀取，如何進行關聯等
設定shuffle過程中的並行度：spark.sql.shuffle.partitions（sqlcontext.setconf()）
在hive資料倉儲建設過程中，合理設定資料型別，比如能設定為int的，就不要設定為bigint。減少資料型別導致的不必要的記憶體開銷。
編寫sql時，盡量給出明確的列名，比如select name from students。不要寫select *的方式。
並行處理查詢結果：對於spark sql查詢的結果，如果資料量比較大，比如超過1000條，那麼就不要一次性collect()到driver再處理。使用foreach()運算元，並行處理查詢結果。
快取表：對於一條sql語句中可能多次使用到的表，可以對其進行快取，使用sqlcontext.cachetable(tablename)，或者dataframe.cache()即可。spark sql會用記憶體列儲存的格式進行表的快取。然後spark sql就可以僅僅掃瞄需要使用的列，並且自動優化壓縮，來最小化記憶體使用和gc開銷。sqlcontext.uncachetable(tablename)可以將表從快取中移除。用sqlcontext.setconf()，設定spark.sql.inmemorycolumnarstorage.batchsize引數（預設10000），可以配置列儲存的單位。
廣播join表：spark.sql.autobroadcastjointhreshold，預設10485760 (10 mb)。在記憶體夠用的情況下，可以增加其大小，概引數設定了乙個表在join的時候，最大在多大以內，可以被廣播出去優化效能。
鎢絲計畫：spark.sql.tungsten.enabled，預設是true，自動管理記憶體。
最有效的，其實就是第四點、快取表和廣播join表，也是非常不錯的！
Spark SQL工作原理剖析和效能優化
一 工作原理剖析 spark sql 架構中主要有這幾個關鍵的元件 sqlparser sql分析程式 analyser 分析器 optimizer 優化器 sparkplan spark計畫 sparksql大致的執行流程是這樣的 1.sql 語句經過sqlparser 完成sql 語句的語法解析...
spark基礎之spark sql執行原理和架構
一 spark sql執行架構 spark sql對sql語句的處理和關係型資料庫類似，即詞法 語法解析 繫結 優化 執行。spark sql會先將sql語句解析成一棵樹，然後使用規則 rule 對tree進行繫結 優化等處理過程。spark sql由core catalyst hive hive ...
Zookeeper之工作原理
zookeeper是乙個分布式的，開放原始碼的分布式應用程式協調服務，它包含乙個簡單的原語集，分布式應用程式可以基於它實現同步服務，配置維護和命名服務等。zookeeper是hadoop的乙個子專案，其發展歷程無需贅述。在分布式應用中，由於工程師不能很好地使用鎖機制，以及基於訊息的協調機制不適合在某...