1.4 為什么要調優

在深入了解了大數據生態使用SQL作為統一查詢語言的優勢和局限性后，我們深知編寫并運行一段高效且穩定的SQL代碼并非易事，同樣的統計需求，要面對不同的開發人員、不同的數據集、不同的執行引擎，甚至隨著業務量增加以及業務復雜度的加深，所消耗的資源和運行時長都是截然不同的。因此，為了消除這些變量帶來的影響，必須提高任務的穩定性和時效性，這就需要對SQL進行調整和優化。

1.4.1 降本提效

所謂降本提效，降的可以是資源成本，例如執行任務時的計算資源、存儲開銷等，也可以是人力成本，例如同樣的需求或查詢，可以用更少的人天來完成。同理，提效提升的可以是計算資源的利用率，也可以是開發人員的開發效率。數據源自業務，也期望能夠賦能業務甚至驅動業務，毫無疑問，時間更短、產出更快、開銷更少的數據應用或查詢，更符合使用方或者業務方的要求。

而SQL查詢作為許多應用程序的核心，其性能直接影響到用戶體驗和系統成本。不經優化的查詢可能導致計算和存儲資源的浪費、響應時間延遲以及系統不穩定性的增加。例如圖1-3中監控訂單表每日增量Binlog統計分布的看板。

如圖1-4所示，約24s才將數據全部查詢、加載完畢。對于業務方或使用方而言，這是難以接受和容忍的。

報表的數據源是ClickHouse，經過排查，我們發現是未設置索引所導致的慢查詢問題。如圖1-5所示，優化后的查詢耗時從24.39s降低至850ms，查詢體驗大大改觀。

隨著互聯網大數據的興起和數據量的爆炸式增加，系統的響應速度成為目前各類數據應用需要解決的最主要的問題之一。毫無疑問，高質量的SQL語句能夠提升系統的可用性。在現在日新月異的時代，更穩健的數據應用、業務系統和更加高效的數據產出，使得業務決策快人一步，從而產生截然不同的結果。

1.4.2 知其然并知其所以然

在實際工作中，數據倉庫、非平臺功能的數據開發以及數據分析崗位的大部分工作內容都是建表或者用SQL將數據接入、導出，再根據業務需求產出數據報表或數據指標。正因為如此，我們被稱為“表哥”“表姐”“SQL Boy”“茶樹菇（查數據的小姑娘）”，連職位也會被人戲稱為“臨時取數員”。時間長了，難免有些人會對自己的工作產生疑問，懷疑自己的工作是否有意義，懷疑自己的發展前景是什么，以及思考怎么才能不做工具人。

誠然，SQL極低的使用門檻帶來了極大的便捷性和受眾群體。但也必須承認，正是因為其易用性，導致除了底層開發和DBA外，大多數人對SQL和引擎沒有一個良好的認知，或者說了解深度不夠。這導致的問題無外乎以下幾類。

? 不理解什么是調優，也不知道該如何調優。SQL任務跑不出來或跑不動的時候，往往只能夠采用加內存、加并行度等“水多加面，面多加水”的笨方法，從而導致了資源的無端浪費。

? 極端的SQL查詢或者ETL任務會嚴重影響整個系統的穩定性甚至造成宕機。例如不限制分區的全表掃描、笛卡兒積、全外連接等。

? 在項目或團隊成立初期，時間緊、任務重，需求倒排，來不及思考可擴展性和復用性，往往都會先交付了事，再加上開發人員的專業素養參差不齊、人員流失等各種因素的影響，最終就會演變成飽受詬病的“祖傳”代碼難以維護和迭代。

總的來說，就是“只得其形，未得其意”。工作不能只浮于表面，要清楚地了解背后的原理，才能對需求或出現的問題有準確判斷，不至于被他人所左右。要清楚地了解使用場景、存在的瓶頸或局限性，才能做到游刃有余、有的放矢。

下面將正式開始剖析在實際工作中，在電商、內容、支付等業務場景和領域下，關于數據分析、數據倉庫建設，以及在流批一體探索的客觀問題和這些問題出現的原因，并提供解決這些問題的實際策略、最佳實踐和案例研究，以幫助讀者更好地理解和應對這些問題。

正如前文所述，大數據引擎自優化的理念和經驗均來自關系型數據庫，因此在深度剖析的理論部分，筆者不刻意區分或強調兩者的差異。理論不僅適用于大數據引擎，同樣適用于關系型數據庫，例如子查詢展開（Subquery Unnesting）和去重遷徙（Distinct Placement）。而在具體實踐中，例如在離線批處理的計算場景中，主要使用Apache Spark（2.x版本）來講解案例；在實時流計算的場景中，主要使用Apache Flink（1.13.x版本）來講解案例。