什么樣的SQL引擎能挑戰運營、報表、分析三位一體化？

近幾十年，企業級的IT架構最常見的是把業務運營和分析分開。業務運營系統包括ERP、CRM、安全事件管理、和企業自己開發的交易系統。 這些的核心特質是和客戶打交道，最重要，對可靠性要求也最高。以呼叫中心的CRM為例：手機用戶打10086查詢某筆費用，辦理國際漫游業務等，都需要重要的業務數據。為了避免BI、報表等干擾業務運營，這些分析型任務往往放在另外的系統里，這就需要將數據從一個或多個運營系統，復制到Data Mart、Data Lake或者數據倉庫里。

早在2005年，Google的Alon Halevy和加州大學伯克利分校的Michael Franklin提出，來自于企業、政府機關、圖書館、智能家居等機構依賴于大量分散而相互關聯的數據源，而缺乏一種方便、集成、有序的辦法來管理他們的“數據空間”，在搜索和查詢、規則的實施，一致性和約束，找尋關聯、可用性和災后恢復等等方面有諸多挑戰。

Hadoop憑借優秀的海量存儲能力和適應于業務增長的線性拓展性，贏得大量的業界部署。越來越多用戶開始地嘗試在業務運營平臺上部署事務型引擎，比如大家熟知的12306訂票系統就采用了Geode。剛剛結束的2016年3月的Apache Geode Summit所展示的高并發和不可出錯的事務型場景，包括Credit Suisse的證券交易和Southwest Airline的訂票系統，讓開發者更有信心在核心運營業務系統里實現運營、分析和報表一體化。

新數據類型的出現，讓這一進程充滿挑戰。在大數據發展初期，很多應用，比如線上媒體，簡單到僅需要按ID查詢，產生相應網頁，對事務處理和一致性的要求幾乎沒有。Key-Value就比關系型數據庫實用多了。隨著社交媒體、移動設備、物聯網的爆炸式發展，新穎的數據類型和數據模型逐漸誕生，比如互動型和觀察型。 社交媒體產生的是典型的互動型數據，圍繞某話題展開，記錄用戶的活動、互動和行為，包括文字內容，語音，視頻和圖像等等；觀察型數據常常由設備產生，提供大量的記錄，可用于重構現場，記錄用戶行為等一系列新應用場景。目前半結構型和非結構型數據大致有5ZB，是結構型數據的1.4倍。非結構型數據不僅包括多種數據類型，而且內容意義（WORD文檔里的文字，視頻里的幀等）和所處的上下文關系很大。 XML、JSON等輕量級數據交換格式的半結構型數據，因為結構可變，也不能簡單粗暴地用傳統的關系型數據庫存儲和分析。

這些趨勢對數據庫提出了大量挑戰，也帶來重大機遇，2014年Gartner明確提出了用大數據運營和分析的一體化-Hybrid Transactional and Analytical Processing (HTAP)。其首要任務是在確保便宜且能夠線性拓展的前提下，達到符合用戶實際情況的原子性、一致性和并發性，并提供一系列機制來靈活運用各種結構型、半結構型和非結構型數據，包括社交媒體的互動型和物聯網的時序數據。

通過多語言編程來實現的實例和問題 

阿里為代表的互聯網企業代表了一個重要的技術流派–Martin Fowler等提出的PolyGlot Programming多語言編程。用最適合的語言完成相應的任務，編寫相應代碼。 比如，Redis處理用戶會話，關系型數據庫管理財務和報表，Riak負責購物車，Neo4J負責推薦系統，MongoDB負責產品，Cassandra負責分析和用戶行為日志。這一做法的挑戰也是巨大的，學習新的API和語言并不復雜，第一步是如何調校好不同的存儲引擎，解決好分區擴展、定制自己的數據結構、索引管理、將應用和存儲去耦合等。接著還需要解決高可用、災備恢復、多數據中心異地雙活、在線升級等，頭疼一個接一個。同時，會有太多的數據移動，從一個結構到另一個，以便滿足運營、報表和分析等不同任務流的需要。

就拓展而言： 當每日訂單二三十萬以內，問題不大，但一旦上升到百萬級別萬左右，核心數據庫的TPS可能承壓，常見的處理方式是分庫分表，Sharding，按業務和TPS比例垂直切分，有時會形成超過10個集群，而且需要自己解決sharding, 重寫代碼。為了保證對應用透明，需要增加Data Access Layer等中間件。即使這樣，升級、回滾、可用性等仍需要耗費大量精力權衡各種影響。 數據一致性、容災機制、維護難度等等還需要一系列開發解決，多數據中心異地雙活、全面的事務保障機制等高級機制甚至自行無法實現。

前幾年的互聯網應用，抽象出來的數據對象之間的關聯很小，比如博客、文章、電商客戶，完全可以獨立存儲，一個表寫滿再寫下一個，因此分表分庫是個不錯的方案。這幾年統計、搜索范圍要求更大，需結合的內外部額外數據更多，行為分析、推薦系統、風控、預警等多維度應用越來越多，數據對象之間關聯越來越重要，數據模型也越來越復雜。許多開發團隊逐漸意識到，這TMD不是成了開發數據庫了嗎？

因此，還不如一開始就采用一個運營和分析相結合的一體化數據庫，讓它在處理各種數據組織層面的事情，比如利用不同的數據模型的強處，如Key-value、文檔存儲、列存儲和關系型結構等，透明處理分區和擴展，確?？鐢祿行?、跨表、跨區的一致性、災備等。因此，我們開始看到重新崛起的SQL和關系型數據庫功能，和NoSQL功能，達到強強結合。

基于SQL的新型一體化技術

傳統的關系型數據庫雖然在解決大數據問題上力不從心，而SQL卻是經過幾十年考驗的成熟技術。 使用SQL來訪問盡可能多的存儲系統，包括Hive, HBase, Cassandra,云等，能帶來很多好處。

途牛采用基于SQL的分布式數據庫，而不是自行搭建復雜的NoSQL平臺，就是一個聰明的選擇：旅游產品的屬性多變，自由行的屬性和組團游不同，比如無需當地導游相關的項目，因此需支持列可變的半結構數據以及list, set, hash等類型。所需的數據庫操作比較簡單：許多任務由簡單的Get/Put結合實時價格計算即可完成，但必須跨多個系統進行聚合和實時查詢，這也是SQL的優點。 因此，找一個基于SQL的技術，并行支持多種存儲系統，足夠的并發數，一定的數據一致性，拓展性價比高，能隨著訂單數、并發度、數據量的增大，非常方便地擴容，保證系統性能在安全區內，就可以滿足目前業務需求，并享受x86和線性拓展的成本優勢，而且無需考慮分表分庫、主從模式，數據一致性、多集群事務處理等麻煩。

架構設計上，可以將查詢和存儲分開，NoSQL的成功證明了不同的應用應采用不同的數據結構和模型，因此就讓數據呆在他們該呆的地方好了，比如Key-value存儲，內存存儲，列存儲，全文搜索系統，圖形數據庫等等?？梢赃x擇一個優秀的查詢引擎在同一套數據上運行事務、實時報表和BI任務流，而無需搬動、轉換、復制或考驗耐心。在多種真實任務流并存時，比如大并發、事務型的短增刪改查、隨機復雜的長查詢、和定期批量報表并存的條件下，無論用戶場景需要采用哪種數據模型和存儲結構，這一查詢引擎都應該能夠有相應的機制，來提供盡可能好的性能，達到安全、可靠性、可用性、災備、線性拓展等等大型數據庫必備要求。來自Facebook的分布式內存SQL引擎PrestoDB，MapR支持SQL和NoSQL的Drill，和以惠普大型商用SQL引擎為核心的Trafodion都是這一新型查詢引擎的領導者。

SQL引擎處理各種挑戰的不同方式

這樣的SQL引擎的成熟度非常重要，必須有10年左右的積累，提供豐富的語句，能兼顧運營型和分析型任務流，達到皆大歡喜的性能。運營型任務流數據量很大，高并發，要求響應時間在一秒之內，而分析型任務流的響應時間在秒到分鐘級，并發度相對低，需要訪問運營、歷史和第三方數據。要支持運營型、批量報表或分析型任務流的任一種，已經相當困難了，比如NonStop SQL/MX擅長OLTP或運營型任務流， Teradata 和HP Neoview擅長BI和數據倉庫， Vertica, Aster Data, Netezza, Greenplum等以分析為主。要用一個查詢引擎來服務所有這些任務流意味著需要滿足一大堆需求。

具體來說，查詢引擎必須能分辨需要全表掃描還是單行訪問。假設是訪問單行，即使數據結構沒有提供主鍵，也應該有辦法縮小掃描范圍，避免全表掃描。查詢引擎需要掌握表的主鍵結構，以便判斷是按整個主鍵還是主鍵的一部分來匹配，如果是整個主鍵，則是單行訪問，可選用最小開銷的機制，得到結果。 按主鍵前面的列、還是后面的列？大概涉及多少行，這些數據分布于哪些節點，在各硬盤、節點上如何分布？都將決定它采用何種方式獲得最佳的訪問性能。

運營型任務流無需每次處理大量的數據，因此產生執行計劃時，無需過多考慮數據傾斜，事先做好分區的主鍵就行了。但對于BI和分析型任務，數據傾斜就是一個重要因素。而并行度也需要考慮到數據傾斜，比如某些節點處理某個大數據集的query時，需要其他節點等待，而影響整個集群的任務流。

不同的任務流在JOIN類型、多層級管線的數據流等方面也有很大區別。需要視情況使用nested join，merge join和其他join類型。 對于每種備選JOIN不能僅僅按預估成本來選擇，還需要結合在悲觀情況下的性能惡化程度。 在處理大數據集的BI和分析時，對內存壓力的檢測也很重要，以便及時主動釋放至磁盤，而對運營型查詢往往無需處理大量數據，則可采取更簡化的檢測。

內部數據流方式也截然不同。 對于大數據集的BI和分析類場景，應由多個進程和運算子并行進行掃描、JOIN和Aggregate，讓數據以Pipeline形式流動，來達到高性能。而事務型則應采取截然不同的數據流方式，來獲得最短的路徑，快進快出。

這種引擎最大的挑戰在于處理“混合數據流”。實驗室的性能報告都將失去意義，引擎直面真實、不可預知、不可專門調優的事務型和復雜查詢相混合。這就需要專門的任務流管理能力。 它將所有查詢按數據源、用戶、角色等分類，允許用戶將某些任務流賦予更高的優先權，以便獲得更多的計算、內存和I/O資源。 同時，在存儲引擎上也需要相應優化—大查詢可以自動讓路給短增刪查改事務，可以被暫停和繼續。

如前文所述，對不同存儲引擎的支持尤為重要。 運營型任務需要大量單行增刪改，適合行存儲，而BI和分析型任務含有大數據集的聚集，更適合列存儲。寫操作較多的任務適合逐行寫。同樣的數據用不同的方式訪問， 性能會大打折扣。HBase可以滿足低延遲，而列存儲的ORC文件或Parquet更適合BI和分析。

開源的Presto，Trafodion和Drill等優秀的引擎也受到了普遍關注。他們的共性在于，無需移動數據，可以訪問不同數據源，如Hive、ORC、關系型數據庫和HBase等，并在一秒內到幾分鐘內得到結果，很好地兼顧Ad-hoc即席查詢和大表掃描或aggregate，更能在實時發生的業務數據上進行分析，比如及時捕捉用戶行為，推薦內容，即時風控等。

不過多數引擎主要用于分析，比如Presto和Drill, 在兼容各種存儲類型上下了大力氣，涵蓋Hadoop, Cassandra, MapR, MongoDB等等，而對業務運營的支持相對薄弱。來自HP的開源Trafodion在OLTP繼承了大型機的引擎，更勝任運營、分析和報表相結合的場景。該項目在國內的落地比較好，有上海易鯨捷等專業團隊支持。

結合內存型數據庫，一體化引擎的前景相當激發想象力。Oracle, SAP Hana, Vertica統治的金融、電信IT架構，已經逐漸被新技術替代。前文提到的內存式Apache Geode商業版Gemfire常用于證券交易系統，經過10多年，在事務處理上已經相當成熟，能確保高并發交易處理、合規監察、交割保障等，并被中國12306鐵路票務系統所采納。 結合Trafodion這樣的一體化數據庫引擎，能享受到Hadoop便宜的拓展性，并確保持久化的安全、高可用、異地雙活，全程ACID保障等特點。僅用一個SQL引擎，操作同一套內存和Hadoop系統，無需移動數據和多套系統，即能滿足監管、合規、交割安全、個股分析，批量報表、BI等各種監管和創新。