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

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

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

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

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

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

通過多語言編程來實現(xiàn)的實例和問題 

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

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

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

因此，還不如一開始就采用一個運營和分析相結(jié)合的一體化數(shù)據(jù)庫，讓它在處理各種數(shù)據(jù)組織層面的事情，比如利用不同的數(shù)據(jù)模型的強(qiáng)處，如Key-value、文檔存儲、列存儲和關(guān)系型結(jié)構(gòu)等，透明處理分區(qū)和擴(kuò)展，確?？鐢?shù)據(jù)中心、跨表、跨區(qū)的一致性、災(zāi)備等。因此，我們開始看到重新崛起的SQL和關(guān)系型數(shù)據(jù)庫功能，和NoSQL功能，達(dá)到強(qiáng)強(qiáng)結(jié)合。

基于SQL的新型一體化技術(shù)

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

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

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

SQL引擎處理各種挑戰(zhàn)的不同方式

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

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

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

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

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

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

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

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

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

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