目錄：
1声畏、從需求說起
2、救星OlAP
3、新的問題插龄，高并發(fā)
隨著大數(shù)據(jù)技術的成熟愿棋，涌現(xiàn)了非常多的成熟框架和技術，在大數(shù)據(jù)存儲查詢引擎方面也有非常多的優(yōu)秀產(chǎn)品均牢。為什么出現(xiàn)這么多的優(yōu)秀產(chǎn)品糠雨，為什么不是一款功能非常全面的產(chǎn)品，一勞永逸地解決所有問題呢徘跪？下面來看看結合實際的應用情況的分析結論甘邀。
1、從需求說起
SAAS軟件模式+微服務的架構垮庐，最終導致數(shù)據(jù)分散在每一個DB中松邪，每個DB對應1個或多個領域，數(shù)據(jù)分散帶來的問題就是無法跨領域去進行分析和統(tǒng)計哨查；由于團隊獨立逗抑，產(chǎn)品規(guī)劃也可能沒有整體考慮業(yè)務規(guī)劃，最終結果是業(yè)務不通寒亥、數(shù)據(jù)不通邮府，客戶無法看到數(shù)據(jù)，特別是實時看到數(shù)據(jù)就更困難了溉奕。
基于上述的架構褂傀，需求有哪些呢，常見的有以下幾類：
1）數(shù)據(jù)洞察分析：一般借助于可視化報表工具加勤，比如帆軟仙辟、PowerBI，基于清洗好的數(shù)倉數(shù)據(jù)胸竞，進行拖拉拽的報表報告設計欺嗤，滿足定制化報表分析及洞察分析的要求。有2個基本要求卫枝，1個是數(shù)據(jù)要清洗準備到位煎饼，1個是報告報表的自助化、定制化校赤，而2者的結合點就是如何快速高效的將數(shù)倉里面的數(shù)據(jù)獲取出來吆玖，即使拖拉拽生成的SQL語句復雜、性能差马篮、條件隨意沾乘、關聯(lián)表多，客戶需求必須滿足浑测。
2）數(shù)據(jù)導出：同數(shù)據(jù)洞察分析類似翅阵，客戶希望將查詢報表中的明細數(shù)據(jù)歪玲，導出到本地或已有報表分析系統(tǒng)中，進一步分析或與已有數(shù)據(jù)進行融合分析掷匠，就需要將報表中生成的數(shù)據(jù)導出Excel滥崩，其邏輯與報表的邏輯一樣，一樣是SQL語句復雜讹语、性能差钙皮、條件隨意、關聯(lián)表多顽决。
3）提供營銷自動化數(shù)據(jù)支撐：為業(yè)務賦能短条，基本CDP提供客戶圈選，提供數(shù)據(jù)服務的支持能力才菠，實現(xiàn)層面依然是拖拉拽茸时。
基于拖拉拽的操作模式，以及無法提前清晰知道SQL語法鸠儿，提供什么樣的DB引擎非常重要屹蚊。
2、救星OLAP
業(yè)務系統(tǒng)一般用OLTP事務型數(shù)據(jù)庫进每，能保證業(yè)務邏輯的完整汹粤，并且有非常好的優(yōu)勢支撐高并發(fā)，長期以來都是業(yè)務系統(tǒng)DB的首選田晚。早期的數(shù)倉嘱兼，在數(shù)據(jù)量不是特別大的情況下，也是用OLTP進行數(shù)倉處理的贤徒。
隨著業(yè)務數(shù)據(jù)量的增大芹壕，數(shù)倉使用OLTP作為計算過程已經(jīng)基本退出了歷史舞臺，取而代之的是大數(shù)據(jù)的計算存儲組件接奈，數(shù)倉存儲也會根據(jù)不同的使用場景要求踢涌，采取不同的存儲引擎以滿足客戶的要求。
對于大數(shù)據(jù)量查詢且時效性高的場景來說序宦，OLAP是目前的首選睁壁，比如ADB、Kylin互捌、DWS潘明、ClickHouse、Doris等秕噪，當然為了進一步提升查詢性能和并發(fā)度钳降，引入緩存級的數(shù)據(jù)存儲Redis等也是非常好的一種方式，但緩存級的DB只能滿足數(shù)據(jù)量不太大的場景腌巾。
對于這些OLAP遂填，ADB非常好的支撐起定制SQL的查詢铲觉，無需增加任何索引，可以利用潛在機制及MPP的架構城菊，滿足查詢要求备燃；Kylin有著非常好的預計算機制，通過高效的匯總層凌唬、主題層，降低對于資源的使用漏麦，提升查詢性能客税；ClickHouse有著非常好的單表查詢性能，但是關聯(lián)查詢無法達到實踐級的要求撕贞「埽總的來說，沒有一款產(chǎn)品能滿足所有要求捏膨，銀彈確實很難找秧均。
所要做的就是根據(jù)不同的業(yè)務使用場景，尋找合適的OLAP引擎号涯，并通過適當?shù)木彺婕塂B提升不斷增長的需求目胡。
3、新的業(yè)務高并發(fā)問題链快，OLTP誉己？
基于上述的洞察分析場景，OLAP基本是可以滿足要求的域蜗，確實比較解決了定制化制作報告的問題巨双，收到了良好的反饋。
隨著業(yè)務的深入應用霉祸，業(yè)務也需要用到數(shù)倉（特別是實時數(shù)倉）的數(shù)據(jù)筑累，用于業(yè)務之間的邏輯處理。通過數(shù)據(jù)服務開放API是可以滿足相應的要求的丝蹭，但是核心問題是業(yè)務應用的高并發(fā)慢宗，ToB的業(yè)務還好，ToC的業(yè)務量對于OLAP的數(shù)據(jù)庫來說半夷，高并發(fā)無法滿足相應要求婆廊。只要高并發(fā)的新功能上線，DB宕機的概率非常大巫橄，這是非常大的挑戰(zhàn)淘邻。
如何應對？有幾個思路：
1）增加OLAP的硬件資源湘换，硬抗宾舅。
2）在第1種的情況下统阿，進行分庫分表的思路，所有SAAS在一個庫中相互影響太大筹我，可以分幾個或多個扶平，比如分級數(shù)據(jù)中心，極限是私有化蔬蕊；
3）引入OLTP數(shù)據(jù)庫（同樣支持分布式）结澄，以提升高并發(fā)的支撐度，滿足實際客戶的需求岸夯。相當于2種場景麻献，2類存儲，2份數(shù)據(jù)猜扮，也會帶來數(shù)據(jù)不一致的問題勉吻，最終造成數(shù)據(jù)準確性方面的問題。
嘗試的過程中旅赢，確實可以收獲很多的驚喜齿桃，確實是可以解決相應場景的問題的，繼續(xù)探索煮盼，繼續(xù)突破短纵。
總結下，不管是滿足一線孕似、客戶的定制化需求使用OLAP滿足快速高效的查詢需求踩娘，還是滿足業(yè)務應用之間邏輯處理的場景需求，都沒有一款DB產(chǎn)品可以解決單個場景的所有問題喉祭，都是具體問題具體分析养渴，針對性解決。當然泛烙，2類不同場景更是這個道理了理卑。我們希望找到銀彈，但這個證明好像不太現(xiàn)實蔽氨，唯有繼續(xù)努力藐唠！
