轉自：https://mp.weixin.qq.com/s/Hgjd8kWMDQufSHIigo3_HQ
隨着業務的不斷增多，為滿足不同場景下對計算時延和吞吐的需求，各式各樣的數據源大顯身手。然而，由於不同數據源的發展歷程不同，迭代速度不一，無法向用戶提供統一的數據處理范式。且數據源所處介質天然隔離，交叉關聯分析阻礙重重，導致數據人員要為此承擔高額的學習和分析成本。
那么面對這些問題，360 是如何構建高效統一的 SQL 查詢引擎呢？以下內容來自 ArchSummit 全球架構師峰會 奇虎 360 大數據中心資深研發工程師 劉思源的演講內容整理，以饗讀者。日益復雜的場景讓業務加工數據效率低下
360 內部有很多業務線，除了大家平時熟知的 PC 安全衛士、360 瀏覽器、360 搜索以及移動端的手機衛士等應用軟件之外，還有很多其他領域的業務產品。下圖為整個公司從資產角度呈現出的業務線概況。
從圖中可以看到，公司內業務方向主要分為搜索、安全、視頻信息流、游戲、金融和 IoT 六個領域，以這些領域為核心由向外衍生出諸多產品，這些產品每日新增打點數據 300T+，換算后有接近 100 億 + 條記錄，覆蓋用戶數達到 10 億 +。由於業務對數據的使用場景在時延和量級上有不同的需求，所以數據往往分散存儲在諸多存儲介質上，在進行數據產出時需要抽取合並不同介質的數據，以公司內部場景為例。
某業務線要處理一定周期內各渠道活躍、下載數據的指標，由於渠道信息數據量較小，且往往會涉及頻繁增刪改，這部分數據通常存放於 MySQL 中，而用戶的活躍下載數據實時打點寫入，最終會落地 HDFS，一旦兩部分數據需要關聯分析時流程通常很冗長，對於業務人員而言處理難度較高。此外，在用戶畫像的場景下，由於行為數據和屬性數據處於異構數據源，業務人員也會面臨類似的問題，導致處理數據的效能低下。
使用統一的抽象屏蔽底層計算存儲細節
針對業務痛點進行深入分析后，我們發現：數據分析人員的技能樹通常向兩個方向發展，一類是技術型，Spark、Flink 信手拈來，Python、R 語言一日千行，他們對業務和數據的理解可能不深入，但他們一定懂得怎樣快速清洗加工數據；另一類是業務型，線性回歸、殘差網絡各類算法應用自如，方差期望、概率分布准確求解，他們對技術棧的了解可能不完備，但他們可以從海量數據中抓出關鍵的信息打動老板。
然而，日趨復雜的數據分析場景逐步提升了處理數據的難度，如果底層數據處理平台無法跟隨場景進行演進，業務會陷入數據加工細節，導致產品迭代速度變緩，最終湮沒在互聯網快速迭代的大潮中。
因此，我們考慮對外提供統一的查詢范式，屏蔽底層數據源和操作細節，讓業務人員擺脫加工數據的技術束縛，不論是對成本控制還是效率提升都是一本萬利的事情。
二次解析銜接所有數據源和引擎
對於統一查詢的場景，我們參考了業界已有的引擎，調研發現：受限於當下計算體系結構，每一種引擎都存在優劣勢。面臨選擇的場景，我們考慮使用動態調度的思想，使用 Apache Calcite 作為上層解析器，通過多一次解析搞清楚用戶的查詢意圖，再向對應引擎解釋路由，讓合適的引擎做合適的事兒。
QuickSQL 是我組自行研發的開源多引擎聯邦查詢門面，對外提供統一標准的 SQL，針對聯邦查詢進行了邏輯樹級別優化，與引擎完全解耦合，可在運行時動態選取引擎執行。業務通過統一的 SQL 門面，能夠處理各類復雜的數據加工場景。其基礎架構如下：
QuickSQL 對外提供多種接口，用戶可以直接通過 CLI 進行分析，也可以在平台中通過其他接口進行遠程調用。
整體架構包含三層：解析層，解釋層和運行時層。
解析層主要通過與元數據庫交互進行語句解析和校驗，結合獨立的權限系統，可以在校驗時進行表和字段級別的權限判斷。解析生成的邏輯計划會經歷聯邦查詢優化和邏輯樹切分。切分后的邏輯子樹由解釋層進行方言解釋和語句路由。對於特定源的查詢直接由 JDBC 完成，混查場景則借助 Spark 或 Flink 作為分布式計算中間引擎進行數據周轉處理。運行時層提供了下推語句的預聚合及抽取計算。
以上圖中混查場景為例，語句包含兩張同庫 Hive 表，一份 Elasticsearch 的 index。
經過詞法語法分析后，生成右圖虛線連接的原始邏輯計划樹，在聯邦查詢優化場景下，針對這棵不尋常的邏輯樹進行分析優化，采用后序遍歷的方式，根據定義好的切點類型在指定位置進行切分。
切點的類型包含：1. 跨數據源，跨庫的關聯或子查詢；2. 數據源不支持的操作和函數。
切分后再向切點處補足相對應節點使各邏輯計划整體完整, 經過切分后的邏輯計划會成為計划森林，包含一個父計划和多個子計划，針對每個邏輯計划再向相應數據源的方言進行轉換，由中間計算引擎的臨時表查詢能力進行數據匯總和再加工。
應用統一查詢門面構建交互式查詢引擎
QNote 是數據中心基於統一 SQL 查詢引擎開發的交互式分析平台，主要面向數據分析、產品、運營和開發人員，通過統一的 SQL 語法對各類數據源包括 Hive、MySQL、Elasticsearch 等進行查詢，基於底層查詢引擎 QuickSQL，用戶還可以進行跨源、跨庫關聯查詢，甚至可以二次導入 CSV 文本與其他數據源進一步關聯分析，能夠覆蓋絕大多數查詢分析場景。
QNote 的業務架構圖如上，主要包含三層：查詢服務層，混合計算層，運行時層。
查詢服務層主要提供用戶側與查詢交互相關的功能，包括查詢管理、監控大盤、編輯器、訂閱服務及例行化調度等。
混合計算層主要分為兩部分，一部分為執行器代理，主要對查詢服務提供 SDK，幫助外部服務理解 SQL，並進行初步校驗。另一部分為執行器，主要針對用戶大批量的查詢進行資源調度，統一解析，和狀態同步等。兩部分由中間消息隊列作銜接，達成負載均衡和雙向解耦。
運行時層包含所有接入聯邦查詢的數據源，各數據源提供語句的下推執行和結果抽取。
初版技術架構
初版的 QNote 架構設計參考了 Zeppelin 模式，整體結構為基於 Thrift RPC 長連接的查詢處理方式，主體分為兩部分，查詢服務和執行器代理，雙方由 Zookeeper 提供負載均衡。
查詢服務主要提供查詢管理，語句校驗推導等。執行器代理集成了 QuickSQL 統一查詢能力，對外提供標准化 SQL 查詢支持，每個用戶對應一條 3 小時租約的查詢連接。通過在多客戶端部署並向 Zookeeper 同步並發量做到對大量查詢的分流。
這樣的結構看似簡單直接，但在實際生產環境中遇到很多問題，諸如：部署困難，資源易泄漏，資源利用率低，查詢並行度差，服務端無法擴展等等。面對種種問題，開發人員開始琢磨系統重構，針對性能、可用性和擴展性三方面進行調整。
舊版架構的核心問題在於雙端耦合過緊，無法橫向擴展，其他問題均為此問題的衍生。於是考慮通過引入消息隊列一招制敵，將服務端計算端解耦，讓查詢能夠完全並行。此外借助消息隊列提供的具備 Rebalance 機制的發布 - 訂閱模式，可以讓計算端輕松達成高可用，甚至計算端可以自行調度資源，達到開源節流的目的。
改進后技術架構
經歷重構后的系統架構如上，查詢服務，消息隊列和執行器代理三部分共同支撐整個交互式查詢平台，查詢服務與執行器的交互間接通過向隊列投擲 SUBMIT，CANCEL 消息來完成，由執行器代理拉取消息並調度資源進行處理，結果集回寫公共存儲。
此外，雙端都會注冊至 Eureka，由 Eureka 對多實例進行心跳檢測。該架構基本解決了之前遇到的問題，達成服務與計算分離，查詢全並行，資源充分利用等目的。
實際場景中的統一查詢性能怎樣？
上面四張圖展示了 QuickSQL 統一查詢的性能比較，由於 QuickSQL 會犧牲一次解析的時間輔助查詢，所以在 MySQL 和 Elasticsearch 的查詢中會慢 0.5 s，在 Hive 查詢中由於底層使用了 Spark-Hive 作引擎，因此性能會稍優於 Hive 原生查詢。
最后一張圖展示了在混查場景下的性能比較，可以看到在處理 MySQL 和 Elasticsearch 的關聯查詢時，由於數據源自身具備索引，QuickSQL 能夠充分利用數據源本身的能力實現下推執行，性能會遠遠優於 Hive 數據源與其他數據源在同等規模數據下關聯的性能。
實際場景中的統一查詢性能怎樣？
QuickSQL 統一查詢下階段開發將主要關注以下幾方面：
- 接入流式 SQL 場景，將離線數據和流式數據的處理范式歸一化。
- 豐富 SQL 操作語法，引入 UDF，構建更完善的查詢引擎。
- 接入 MongoDB 和 Druid 等常見數據源，滿足更多查詢場景。
- 提供更為豐富的應用接入方式，引導應用快速接入。
希望感興趣的朋友可以一起參與開發討論。
附 QuickSQL 開源地址：
https://github.com/Qihoo360/Quicksql
演講嘉賓介紹：
劉思源，奇虎 360 大數據中心資深研發工程師，現負責交互式查詢平台和數據聯邦查詢引擎的設計和研發，對大數據計算平台和微服務有深入研究。見證了 360 大數據平台從無到有，從單一到生態，從集成到服務化的演化過程。致力於推動 SQL 在大數據平台中多種場景的落地，Apache Calcite 貢獻者。
隨着業務的不斷增多，為滿足不同場景下對計算時延和吞吐的需求，各式各樣的數據源大顯身手。然而，由於不同數據源的發展歷程不同，迭代速度不一，無法向用戶提供統一的數據處理范式。且數據源所處介質天然隔離，交叉關聯分析阻礙重重，導致數據人員要為此承擔高額的學習和分析成本。
那么面對這些問題，360 是如何構建高效統一的 SQL 查詢引擎呢？以下內容來自 ArchSummit 全球架構師峰會 奇虎 360 大數據中心資深研發工程師 劉思源的演講內容整理，以饗讀者。日益復雜的場景讓業務加工數據效率低下
360 內部有很多業務線，除了大家平時熟知的 PC 安全衛士、360 瀏覽器、360 搜索以及移動端的手機衛士等應用軟件之外，還有很多其他領域的業務產品。下圖為整個公司從資產角度呈現出的業務線概況。
從圖中可以看到，公司內業務方向主要分為搜索、安全、視頻信息流、游戲、金融和 IoT 六個領域，以這些領域為核心由向外衍生出諸多產品，這些產品每日新增打點數據 300T+，換算后有接近 100 億 + 條記錄，覆蓋用戶數達到 10 億 +。由於業務對數據的使用場景在時延和量級上有不同的需求，所以數據往往分散存儲在諸多存儲介質上，在進行數據產出時需要抽取合並不同介質的數據，以公司內部場景為例。
某業務線要處理一定周期內各渠道活躍、下載數據的指標，由於渠道信息數據量較小，且往往會涉及頻繁增刪改，這部分數據通常存放於 MySQL 中，而用戶的活躍下載數據實時打點寫入，最終會落地 HDFS，一旦兩部分數據需要關聯分析時流程通常很冗長，對於業務人員而言處理難度較高。此外，在用戶畫像的場景下，由於行為數據和屬性數據處於異構數據源，業務人員也會面臨類似的問題，導致處理數據的效能低下。
使用統一的抽象屏蔽底層計算存儲細節
針對業務痛點進行深入分析后，我們發現：數據分析人員的技能樹通常向兩個方向發展，一類是技術型，Spark、Flink 信手拈來，Python、R 語言一日千行，他們對業務和數據的理解可能不深入，但他們一定懂得怎樣快速清洗加工數據；另一類是業務型，線性回歸、殘差網絡各類算法應用自如，方差期望、概率分布准確求解，他們對技術棧的了解可能不完備，但他們可以從海量數據中抓出關鍵的信息打動老板。
然而，日趨復雜的數據分析場景逐步提升了處理數據的難度，如果底層數據處理平台無法跟隨場景進行演進，業務會陷入數據加工細節，導致產品迭代速度變緩，最終湮沒在互聯網快速迭代的大潮中。
因此，我們考慮對外提供統一的查詢范式，屏蔽底層數據源和操作細節，讓業務人員擺脫加工數據的技術束縛，不論是對成本控制還是效率提升都是一本萬利的事情。
二次解析銜接所有數據源和引擎
對於統一查詢的場景，我們參考了業界已有的引擎，調研發現：受限於當下計算體系結構，每一種引擎都存在優劣勢。面臨選擇的場景，我們考慮使用動態調度的思想，使用 Apache Calcite 作為上層解析器，通過多一次解析搞清楚用戶的查詢意圖，再向對應引擎解釋路由，讓合適的引擎做合適的事兒。
QuickSQL 是我組自行研發的開源多引擎聯邦查詢門面，對外提供統一標准的 SQL，針對聯邦查詢進行了邏輯樹級別優化，與引擎完全解耦合，可在運行時動態選取引擎執行。業務通過統一的 SQL 門面，能夠處理各類復雜的數據加工場景。其基礎架構如下：
QuickSQL 對外提供多種接口，用戶可以直接通過 CLI 進行分析，也可以在平台中通過其他接口進行遠程調用。
整體架構包含三層：解析層，解釋層和運行時層。
解析層主要通過與元數據庫交互進行語句解析和校驗，結合獨立的權限系統，可以在校驗時進行表和字段級別的權限判斷。解析生成的邏輯計划會經歷聯邦查詢優化和邏輯樹切分。切分后的邏輯子樹由解釋層進行方言解釋和語句路由。對於特定源的查詢直接由 JDBC 完成，混查場景則借助 Spark 或 Flink 作為分布式計算中間引擎進行數據周轉處理。運行時層提供了下推語句的預聚合及抽取計算。
以上圖中混查場景為例，語句包含兩張同庫 Hive 表，一份 Elasticsearch 的 index。
經過詞法語法分析后，生成右圖虛線連接的原始邏輯計划樹，在聯邦查詢優化場景下，針對這棵不尋常的邏輯樹進行分析優化，采用后序遍歷的方式，根據定義好的切點類型在指定位置進行切分。
切點的類型包含：1. 跨數據源，跨庫的關聯或子查詢；2. 數據源不支持的操作和函數。
切分后再向切點處補足相對應節點使各邏輯計划整體完整, 經過切分后的邏輯計划會成為計划森林，包含一個父計划和多個子計划，針對每個邏輯計划再向相應數據源的方言進行轉換，由中間計算引擎的臨時表查詢能力進行數據匯總和再加工。
應用統一查詢門面構建交互式查詢引擎
QNote 是數據中心基於統一 SQL 查詢引擎開發的交互式分析平台，主要面向數據分析、產品、運營和開發人員，通過統一的 SQL 語法對各類數據源包括 Hive、MySQL、Elasticsearch 等進行查詢，基於底層查詢引擎 QuickSQL，用戶還可以進行跨源、跨庫關聯查詢，甚至可以二次導入 CSV 文本與其他數據源進一步關聯分析，能夠覆蓋絕大多數查詢分析場景。
QNote 的業務架構圖如上，主要包含三層：查詢服務層，混合計算層，運行時層。
查詢服務層主要提供用戶側與查詢交互相關的功能，包括查詢管理、監控大盤、編輯器、訂閱服務及例行化調度等。
混合計算層主要分為兩部分，一部分為執行器代理，主要對查詢服務提供 SDK，幫助外部服務理解 SQL，並進行初步校驗。另一部分為執行器，主要針對用戶大批量的查詢進行資源調度，統一解析，和狀態同步等。兩部分由中間消息隊列作銜接，達成負載均衡和雙向解耦。
運行時層包含所有接入聯邦查詢的數據源，各數據源提供語句的下推執行和結果抽取。
初版技術架構
初版的 QNote 架構設計參考了 Zeppelin 模式，整體結構為基於 Thrift RPC 長連接的查詢處理方式，主體分為兩部分，查詢服務和執行器代理，雙方由 Zookeeper 提供負載均衡。
查詢服務主要提供查詢管理，語句校驗推導等。執行器代理集成了 QuickSQL 統一查詢能力，對外提供標准化 SQL 查詢支持，每個用戶對應一條 3 小時租約的查詢連接。通過在多客戶端部署並向 Zookeeper 同步並發量做到對大量查詢的分流。
這樣的結構看似簡單直接，但在實際生產環境中遇到很多問題，諸如：部署困難，資源易泄漏，資源利用率低，查詢並行度差，服務端無法擴展等等。面對種種問題，開發人員開始琢磨系統重構，針對性能、可用性和擴展性三方面進行調整。
舊版架構的核心問題在於雙端耦合過緊，無法橫向擴展，其他問題均為此問題的衍生。於是考慮通過引入消息隊列一招制敵，將服務端計算端解耦，讓查詢能夠完全並行。此外借助消息隊列提供的具備 Rebalance 機制的發布 - 訂閱模式，可以讓計算端輕松達成高可用，甚至計算端可以自行調度資源，達到開源節流的目的。
改進后技術架構
經歷重構后的系統架構如上，查詢服務，消息隊列和執行器代理三部分共同支撐整個交互式查詢平台，查詢服務與執行器的交互間接通過向隊列投擲 SUBMIT，CANCEL 消息來完成，由執行器代理拉取消息並調度資源進行處理，結果集回寫公共存儲。
此外，雙端都會注冊至 Eureka，由 Eureka 對多實例進行心跳檢測。該架構基本解決了之前遇到的問題，達成服務與計算分離，查詢全並行，資源充分利用等目的。
實際場景中的統一查詢性能怎樣？
上面四張圖展示了 QuickSQL 統一查詢的性能比較，由於 QuickSQL 會犧牲一次解析的時間輔助查詢，所以在 MySQL 和 Elasticsearch 的查詢中會慢 0.5 s，在 Hive 查詢中由於底層使用了 Spark-Hive 作引擎，因此性能會稍優於 Hive 原生查詢。
最后一張圖展示了在混查場景下的性能比較，可以看到在處理 MySQL 和 Elasticsearch 的關聯查詢時，由於數據源自身具備索引，QuickSQL 能夠充分利用數據源本身的能力實現下推執行，性能會遠遠優於 Hive 數據源與其他數據源在同等規模數據下關聯的性能。
實際場景中的統一查詢性能怎樣？
QuickSQL 統一查詢下階段開發將主要關注以下幾方面：
- 接入流式 SQL 場景，將離線數據和流式數據的處理范式歸一化。
- 豐富 SQL 操作語法，引入 UDF，構建更完善的查詢引擎。
- 接入 MongoDB 和 Druid 等常見數據源，滿足更多查詢場景。
- 提供更為豐富的應用接入方式，引導應用快速接入。
希望感興趣的朋友可以一起參與開發討論。
附 QuickSQL 開源地址：
https://github.com/Qihoo360/Quicksql
演講嘉賓介紹：
劉思源，奇虎 360 大數據中心資深研發工程師，現負責交互式查詢平台和數據聯邦查詢引擎的設計和研發，對大數據計算平台和微服務有深入研究。見證了 360 大數據平台從無到有，從單一到生態，從集成到服務化的演化過程。致力於推動 SQL 在大數據平台中多種場景的落地，Apache Calcite 貢獻者。