613 小米小米6

HiStore：阿裏巴巴海量數據場景下的OLAP解決方案

摘要：7月27日，雲棲社區、阿裏中間件舉辦了首屆阿裏巴巴中間件技術峰會，揭秘阿裏10年分布式技術幹貨。在首屆阿裏巴巴中間件技術峰會上，阿裏巴巴中間件技術專家焦方飛為大家分享阿裏巴巴海量數據場景下的OLAP解決方案，此外還對阿裏新推出的高性能時序數據庫進行了簡單介紹，精彩不容錯過。

以下內容根據演講嘉賓現場視頻以及PPT整理而成。

本次分享的主題是阿裏巴巴海量數據場景下的OLAP解決方案，主要是也為大家介紹一下阿裏巴巴OLAP存儲的一款產品——HiStore。大家都知道海量數據，包括大數據和數據倉庫這些在當下都是非常熱門的話題，大家都比較關心這個領域，所以這個領域也成為了各大廠商的必爭之地，為什麼？原因很簡單，就是在未來，大家的不同就在於對於數據理解的不同，換句話說就是未來屬於能夠真正地讀懂數據的人。

本次的分享將主要圍繞以下四個方麵進行：
一、HiStore產品的由來以及它所能夠應對的場景以及能夠解決的痛點
二、結合現實已經落地的成功案例幫助大家理解HiStore的應用場景以及HiStore能夠為業務帶來什麼樣的價值
三、HiStore在目前海量數據、大數據以及數據倉庫領域的定位
四、HiStore的核心技術、架構設計以及優化思路

一、Why HiStore？
業界的痛點

86a720c6c530381a6d70755be23f8068fc313f7b

那麼業界的痛點在哪裏呢？從傳統互聯網數據到移動互聯網數據，再到現在很熱門的IoT，實際上隨著每一次業界的進步，數據量而言都會出現兩到三個數量級的增長。而且現在的數據增長呈現出的是一個加速增長的趨勢，所以現在提出了一個包括移動互聯網以及物聯網在內的互聯網大數據的5大特征：Volume、 Velocity、 Variety、 Value、 Veracity。同時也出現了一些問題，第一問題就是成本，成本問題是一個日益突出的問題，大家也知道，就是半年前SSD的硬盤架構飆漲了一倍，可以說已經趕上了房價的漲幅，現在的情況是硬件成本如此之高，即便是再土豪的公司也需要考慮成本的問題。另外一個問題就是在這麼大的數據量的背景下，讓數據發揮出自己應該有的價值，實際上需要高效的聚合和查詢分析。如果想要讓大數據分析出來的趨勢更加精確，能夠帶來更高的參考價值，就需要更多的維度，但是維度更多則會帶來更多技術上的困難。另外就是實時性，在某些場景下需要大數據呈現實時或者準實時的結果。另外就是遷移和學習的成本，其實很多公司也都在考慮怎樣去遷移數據以及怎樣更加方便的接入大數據的產品。

現在提到大數據，其實大家第一反應就是Hadoop體係的產品非常之多，讓人眼花繚亂。在這裏也為大家簡單地梳理一下Hadoop技術棧的主要產品：第一代的HDFS、MapReduce產品，可以說太慢了，逐漸引進到第二代，第二代就是通過內存cache等增加吞吐量的方式產生了Spark等產品，這時候性能得到了進一步的提升。再往後就是如果想要實現一個複雜任務的話，使用MapReduce就會是一個比較複雜和麻煩的事情，那麼就會考慮到是不是使用腳本或者SQL的方式就會更簡單呢？因為SQL比較簡單，那麼就產生了Hive和Pig，而且現在逐漸比較流行了，到了這一步就已經引入了SQL了。SQL已經比較好用了，但是這時候在某些場景下實際的性能還不夠，應該怎麼辦呢？其實性能還不夠的原因在於之前的MapReduce以及Spark這種模型做的太通用、太健壯、太保守了，實際上我們應該在某種程度上更激進地獲取數據，實際上這時候就產生了一些計算層的產品，比如Presto，Drill，Impala。

實際上就是Hadoop體係從下往上看就是從最底層的HDFS或者其他的一些分布式文件係統，到上層的第一代的MapReduce、Spark，在往上就是到Pig或者Hive；另外就是HDFS或者其他文件係統上直接跑Presto，Drill，Impala；那大規模數據處理的另外一個領域——大規模分布式MPP架構，比如SAP的HANA，HP的Vertica，開源的GreenPlum等等。

集團內的痛點

6f99d8c76e1b2bf0da1b2a30f407b93573f33b6c

那麼，反映到集團內是什麼樣痛點呢？以集團內的某個日誌係統為例，它每天會產生幾萬億條日誌，每產生的數據將近PB級別的量級，如果使用MySQL可能會需要使用數千台，這個成本是不言而喻的。從公司層麵看，存儲領域有數十萬台物理機，其中的大概50%用於存儲離線數據，包括曆史數據、日誌、軌跡、用戶行為分析數據。其實這部分數據是符合OLAP的場景的，因為這部分數據的增長速度是加速增長的，所以這部分數據存儲的成本是要控製住的，也是需要關注的。另外就是在如此大的數據量的情況下，在降低成本的同時要保證數據分析的時效性和高性能。

什麼是HiStore
為了解決前麵提到的業內以及集團內麵臨的痛點，HiStore產品就應運而生了。HiStore產品的定位是分布式低成本OLAP分析型數據庫產品，是一款基於獨特的知識網格技術的列式數據庫，定位於海量數據高壓縮比列式存儲，是低存儲成本，低維護成本，海量數據OLAP存儲引擎；有效的解決了海量數據存儲的成本問題，以及在百億數據場景下支持實時高效的多維度自由組合的檢索。而且通過近兩三年的發展，HiStore在阿裏內部已經應用於多個核心應用，包括菜鳥、 B2B、阿裏媽媽、聚劃算、天貓等，也應用於很多外部用戶，比如在人社部，上海新能源汽車，新零售等超大數據量測試環境都取得了令人信服的結果，無論成本、性能、穩定性都表現完美。

HiStore提供哪些特性來解決相關問題呢？HiStore所具有的特性如下圖所示：

6b60c0d38cd7d97179ee1719c16862c98062e0df

基於上麵的這些特點，HiStore具有如下的這些優勢：

海量數據存儲: PB級數據大小，百億條記錄，數據量存儲主要依賴自己提供的高速數據加載工具（TB/小時）和高數據壓縮比（>10:1）。
高壓縮比：平均壓縮比>10:1，遠高於常規壓縮算法，甚至可以達到40:1，極大地節省了數據存儲空間。
基於列存儲：無需建索引，無需分區。即使數據量十分巨大，查詢速度也很快，用於數據倉庫、查詢性能強勁、穩定：億級記錄數條件下，同等的SELECT查詢語句（這裏主要是聚合查詢，多維查詢等等），速度比MyISAM、InnoDB等普通的MySQL存儲引擎快數十倍。
高性能數據導入：基於MySQL協議的並行導入，以及專門的數據預處理入庫工具。
多維分析查詢：實時性的多維度數據檢索；海量數據聚合秒級計算；為實時業務提供保障。
線性擴展：用戶可以輕鬆實現存儲容量和處理能力的線性提升。
係統易用：遷移成本低，無其它依賴獨立部署，MySQL工具及應用可直接無縫運行其上。
快速響應複雜的聚合類查詢：適合複雜的分析性SQL查詢，如SUM, COUNT, AVG, GROUP BY。

二、案例分析
接下來會借助一些成功落地的案例幫助大家深入地理解HiStore產品的使用場景。首先看下圖將HiStore產品的應用場景做了簡單的分類，這部分場景包括數據分析與商業智能、用戶畫像和用戶行為、曆史數據、分析應用與廣告數據、日誌，軌跡，記錄，監控，歸檔、數據倉庫、物聯網數據、存儲成本敏感等。

9422ae16f7c0d1de6c82369d0d600bceeed8a6d0

而以上所有分類的場景都基本具備以下的特點：海量存儲、快速導入、低存儲成本、低接入成本、多維度檢索和複雜分析、並發訪問量大、數據實時分析、響應低延遲、數據自動過期、深度挖掘、線性擴展以及生態兼容等。

案例1：高德熱力圖
接下來結合幾個實際的案例來分析，第一個案例就是高德熱力圖。大家都知道高德的產品是與地理相關的，它可以拿到每個人的地理信息，那麼通過這種人地關係以及用戶畫像相結合，就可以實現如下圖中右側所示的界麵這樣的顯示出用戶的職業、性別、年齡、教育水平、資產等的用戶畫像。高德能夠將地理位置與用戶畫像結合起來，那麼就能夠迸發出很多的商業價值，比如在確定了目標人群之後，對於商鋪或者商品而言就可以通過這樣的應用分析出潛在的客戶，這樣的產品目前也是高德目前的拳頭級產品。那麼對於這樣的產品而言，在技術實現上有哪些難點呢？第一就是數據量大，萬億級別，導入速度要求高；除此之外就是想要在這麼大的數據量上進行這樣多維度聚合查詢得出趨勢和結論，傳統的MySQL數據庫將無法完成，簡單來說傳統MySQL數據庫的InnoDB引擎是B+樹的改進，B+樹實際上是磁盤不友好的數據結構，其在數據查詢和導入的時候會產生大量的隨機IO，而且隨著數據量的增加，B+樹的分列會越來越多，就會導致數據導入越來越慢，查詢起來也會越來越慢，甚至無法得出結果。

5a23f7d7a92cb068d2b41f026cf4ef84f695f8d6

HiStore產品的引入幫助高德解決的第一個問題就是不管數據量多大，能穩定的在秒級別完成多維度Adhoc查詢。其次就是實現了高性能數據導入，實際部署時的百億級別增量數據在兩小時之內就可以完成導入，而之前卻需要至少一兩天的時間，這也是一個非常明顯的優勢。還有就是高壓縮比，機器成本低，可以幫助高德將機器成本降低到原來的十分之一。

案例2：禦膳房項目

禦膳房策略中心項目是阿裏巴巴集團“品銷全營銷，unimarketing”項目中的一部分，產品定位是品牌商品牌發展策略的支持平台，通過從淘寶、天貓、聚劃算等平台收集的海量實時數據，幫助品牌商更高效，更明智地做出品牌發展相關的商業決策。

禦膳房這個項目的第一個特點就是數據量大，另外一個很明顯的特點就是需要聚合的維度非常多，在下圖中就可以看出有非常多的維度，可以到幾百個維度，而且他還需要動態地增加維度，這是什麼意思呢？也就是說可能今天隻有200個屬性，需要在這200個屬性維度上進行數據分析，而明天可能表立馬擴展成300個屬性，那就需要在這300個屬性維度上做數據分析，也就是這種動態地擴充表的維度，以前是沒有辦法實現的，維度上限也很低，一般幾十個維度就到上限了。所以禦膳房在業務上難點和痛點就是商品屬性的維度是動態的,需要支持多維查詢；另外就是查詢的數據量很大，還涉及到了一張8億條數據的表和一張1億條數據的表之間的join。還有就是目前存儲成本太高、穩定性不好且數據導入實時性不夠。

b817d13be190386472c0a28890808cc2f4f655ad

而HiStore引入的價值和意義就是秒級別的高效穩定的多維查詢，可以支持多達4096列，基本上可以滿足大多數的場景，另外還可以動態增刪列: 標準MySQL語句ALTER TABLE就能夠搞定了，而不需要再進行複雜的操作。至於在動態增刪列之前的那些數據，比如像null填充、以及默認值等都是可以實現的。另外就是高性能數據導入，十億數據在一個小時加載完成，相對當前方案提升十倍。最後一點就是在存儲成本上有明顯的降低，禦膳房二期全鏈路和透視項目從原來400台高配物理機集群，替換為50台HiStore docker機器部署。可以看出使用HiStore為禦膳房解決了非常大的痛點，帶來了非常大的價值。

案例3：螞蟻體驗平台
我們再來看一個例子-螞蟻體驗平台，這個產品是為了構建一套包含“問題收集、分析、推進、協作、價值衡量”的體係，幫助螞蟻金服自己的產品做良性的改進；方便螞蟻小二對集團的數據進行分析，比如對花唄的幾千萬上億的會員進行畫像分析，從而對於產品做一些改進，這是用戶行為分析以及商業智能的又一個典型的場景。

f225e4ef24a7f3b59d095dcfcc86e1675b9dadb9

螞蟻體驗平台所麵對的業務痛點就是之前使用MySQL方案，單表數據大於2000萬時，查詢經常超時；特征列不能超過100列，查詢條件越多越慢擴展不方便，並且維護索引非常麻煩。在上圖中右邊這張表中，包含有count (*) [where]條件，有一列、五列和十列的結果，如果使用MySQL的話就會隨著查詢列數的增加查詢時間明顯增加，從15秒到65秒再到150秒，然而對於HiStore的單機或者集群而言，卻可以隨著查詢條件的增多查詢的速度反而更快，可以從一個查詢條件時的1秒到5個條件時的0.5秒，再到10個條件的時候不到0.3秒就搞定了，這是一個正好與MySQL相悖的情況，這是為什麼呢？其實這與HiStore的存儲結構相關，簡單講HiStore的查詢是通過粗糙集過濾的方式實現的，也就是查詢的條件越多，在內存時就能夠過濾越多的數據包，最後實際上真正需要解壓做查詢的數據包就會越來越小，這就是為什麼隨著查詢條件越多，查詢速度越快的原因。

案例4：全鏈路追蹤係統EagleEye
EagleEye是集團內一款應用廣泛的分布式調用跟蹤係統，主要幫助用戶方便地查看應用的實時數據及快速定位線上問題，為全鏈路壓測、跨單元分析、鏈路梳理提供數據支撐。而EagleEye係統日誌量非常之大，大到每天近萬億條，大概每天會產生數千TB的數據，這個數據量在業內也屬於頂級的一個水平了。另外就是EagleEye係統的數據峰值很高可以達到數千萬的TPS，如果使用傳統的MySQL成本太高，這樣是吃不消的。

066472cba2f1ef621a3a3b565abaaf0052a5ee49

而HiStore在如此大數據量的場景先，能夠為EagleEye係統實現秒級別的多維度Adhoc查詢，做到單機支持數十萬TPS寫入，並且實現高壓縮比存儲，為集團節省數千台機器的成本。

三、競品分析
接下來為大家簡單介紹一下大數據領域以及數據倉庫領域，HiStore產品的定位以及競品分析。

be5c041982641c76925fdc70da64ae260f89a6db

上圖的縱坐標表示的是產品的成熟度，橫坐標表示的是趨勢。從這張圖的最左邊的最傳統的OLAP的數據庫解決方案，一直到中間第二階段的基於列式存儲的大規模MPP架構的分布式存儲引擎，這部分主要是針對結構化數據，這部分包括惠普的Vertica以及SAP的HANA等都是業內著名的數據倉庫解決方案。大家可以看到HiStore也在這一部分，但是要偏向於下麵一下，因為HiStore的定位是一個存儲引擎，所以其產品化程度不如Vertica以及HANA，因為大家都知道HANA在上層的數據抽取和數據展現都比較好的。再往右這部分就是Big Data這部分，這部分主要是解決存儲計算分離，這種半結構化數據或者非結構化數據這樣的異構源，什麼意思呢，舉個例子就是，有一部分非結構化數據存儲在HBase上，另外一部分結構化的數據存儲在MPP架構的HiStore上麵，那如果對於這兩段數據進行join的話，實際上就會使用大數據計算層的技術（如Presto，Drill）解決這些問題。HiStore這個產品在大規模MPP架構場景下和Hadoop體係以及Big Data體係下的這兩個方向其實都是有適用場景的，這就是HiStore的定位。其實大家也能夠感覺到，很多技術的邊界變得越來越模煳，很多組件之間可以相互融合或者相互組合，這也是未來技術的一個大趨勢。

以下是針對於MPP架構的同類產品分析：

fbaa7e3826ec6d554482c07bcb54a867e3939b72

但是如果拿HiStore與上述的這些產品進行比較，HiStore有什麼優勢呢？舉一個新零售行業的例子，之前它可能會使用SAP的HANA做數據分析和報表展現，之前的成本可能是一次性花費了500萬，成本非常高。當使用HiStore評估其場景後發現，其業務與之前提到的一些銷售的單據展現以及BI類似，HiStore對於其場景以及功能性支持都是可以的，根據數據量來看，使用兩個實例就搞定，每個實例15萬，30萬就搞定了，也就是可以將原來500萬的成本降低到50萬之內，這也是一個很典型的例子。也就是HiStore能夠在同樣滿足用戶數據分析需求的前提下將成本盡可能地降低，這也是HiStore在業內最大的優勢所在。

四、核心技術

下麵簡單介紹一下HiStore的架構和一些核心的技術點：
列式存儲引擎

184e4dc65f03f0af4c85b2f946da952d6e616d08

HiStore使用的是列存，也就是Column-based，它與傳統的Row-based不同。如果需要查詢數據表的某一列，傳統方式是使用Row-based，也就是將每一行數據都取出來，然後取出其中的某一列，這樣做其實磁盤的效率很低。而使用Column-based則可以直接取這一列，這樣可以節省很大的磁盤IO，從而間接地提升磁盤性能。另外按列可以對於相同數據進行壓縮，特別是數值相同的情況，這也就是為什麼推薦用戶使用數值型的來做，因為使用數值型可以壓縮的更高。另外就是看起來可能需要使用文本，比如String類型的省份信息，這一類看起來好像是文本類型，但是36個省份可以在內部優化轉化成為36個整型數據，實際上這個壓縮也是非常占優勢的，也就是說，重複的數據越多，壓縮就會越高效，這也是Column-based數據庫的優勢。

數據組織結構

26899df68906395377f4615bc6919a78c568ea3e

數據組織結構就是知識網格，每一列大概是64K條數據做壓縮，做壓縮之後每一列會產生兩個數據結構，一個叫做Metadata，另外一個是KG。Metadata存儲了這一列64K條數據裏麵的最大值、最小值、和以及平均值等預統計信息，這就是為什麼在進行預聚合的時候會非常快，因為不需要解壓數據，隻要將這些統計信息全拿到就可以了，而且執行時間是不會隨著數據量增加而增加的，因為Metadata和知識節點都是內存裏麵的，不需要跑磁盤，不需要解壓，所以速度非常快，這就是秒級聚合快的根本原因。另外一個就是查詢時候用到的知識網格KG，這也是進行高效查詢過濾壓縮包的關鍵技術，後麵我們也會詳細介紹一下KG。

整體架構
下麵這張圖大家可以從左上角開始看起，標準的MySQL客戶端以及標準的JDBC和ODBC客戶端都可以進來，其下麵就是Parser以及Optimizer，也就是解析和優化器根據HiStore獨特的數據結構來進行優排。再往下就是KG Manager，也就是知識網格和MetaData，這塊內容也是數據結構最為核心的部分，也是高速數據導入最核心的部分，也包括Succinct Data。Succinct也是最近比較火的一個技術，它可以實現更好的數據壓縮以及基於壓縮包的檢索，也就是說它可以在不需要解壓數據的前提下就進行檢索，HiStore中對於Succinct Data的數據結構實現了其C++版本。再往下的Memery Manager，也就是對於內存進行更加高效的加載，使得更多的數據存在內存裏以實現更高效的數據查詢和導入，然後右邊這部分就是一些並行計算，比如sharding，也就是一條SQL語句進來之後如何實現分片，以及在分片之後進行並行處理。因為現在機器高配都是多磁盤的，那麼可以實現充分利用多核、多磁盤以及這種並行計算的硬件優勢。再往下就是壓縮、解壓，包括LZ4或者是PPM這種壓縮解壓算法。到最底下的落盤，HiStore支持與MySQL相同標準的Binlog以及自己的Hilog，這樣可以方便的通過DRC以及阿裏內部的精衛等進行數據同步，同步到其他數據源都是沒有任何問題的。

d85dad20e9597961a955dfeb6f160d2db0767b24

再看一下數據的導入，這部分可以使用HiStore高效的導入工具從HBase、ODPS以及Oracle DB等導入數據。另外就是最右邊的運維、管控這部分內容，HiDAS可以實現對於數據庫的運維、監控、報警、部署等一體化操作，方便地實現對於數據庫的運維，以上這些就是HiStore整體的架構設計。

接下來為大家分享一下HiStore的核心技術點。
核心技術1：HiStore查詢優化器

cb2d9c20ddf3a4f363f330fd0d81db6e07d31363

大家可以從下圖中看到從上麵的HiStore查詢優化器下來之後到中間有三種過濾器，也就是前麵提到的KG部分，包括位圖索引，bloom filter過濾器，以及直方圖，可以更好地實現粗糙集過濾。實際上在查詢的時候最高效的就是這三個部分：位圖索引、bloom filter過濾器以及直方圖，這部分都是在內存裏麵可以過濾大部分無效的包，真正可以被命中的壓縮包才會從磁盤中被讀取出來，然後進行解壓去尋找。

往右邊看的話，就是接下來準備做的按列索引，因為原來的時候是沒有索引的。再右邊是基於代價的關聯方法，也就是表與表之間的join，在普通的表與表之間可以使用Hash join，在大表之間可以使用Map join或者Merge join。

核心技術2：執行優化

86ff085ff106e4ea8d6b3100dde3e74c816a536a

HiStore對於很多SQL語句都實現了執行優化，可以理解成可以根據HiStore的存儲結構做一些語句上的查詢條件的優化，比如讓哪些查詢條件優先執行，其實這與SQL優化的核心思想是基本一樣的，就是讓更苛刻的條件優先執行，可以過濾更多的包，這其實也是目前通用的做法。

核心技術3：壓縮數據實時檢索

4bcc7dae8771d984a5598109ae3f42561d017bbc

這個部分主要采用Succinct技術，針對不同類型的字段進行了單獨的優化處理。這個算法非常複雜，其實簡單而言就是通過原始數據的BWT變換，能夠將字典排序做的很好，更加高效地壓縮，並且通過遊程編碼以及Checkpoint來加快檢索，實現不需要解壓數據就可以實現檢索。

核心技術4：高性能數據寫入

e4186e6b1feb78f21e904fb1415a734bf8cf2057

之前也有所提及，HiStore在數據導入這部分也做了重點的優化。簡單而言就是兩點：第一點就是CPU的每個核與每一列、每一個磁盤都進行綁定，實現了多線的並行的導入，充分利用多核和多磁盤的硬件特性進行高效導入；另外一點就是在內存裏基於mmap實現一個ringbuffer無鎖隊列，這個是非常高效的。大家都知道mmap在Linux用戶態和內核態之間進行切換的時候可以減少一次內存拷貝，於是就能夠使得磁盤IO更加高效。通過以上的兩個方麵，單機數據導入可以達到每秒70萬條數據，除此之外，insert的功能可以達到每秒10萬+這樣的級別，並且數據是實時導入，實時生效的。

核心技術5：MVCC無鎖讀事務

67ec029dd9f564bda52a1d1f6a856ac12392c0db

這部分的技術主要是解決了數據導入的讀寫鎖對於並發查詢的阻塞，以前的並發查詢的性能不是太好，就是因為讀寫鎖會造成阻塞。其實簡單來講，HiStore實現了Snapshot隔離級別，每個事務每次進來的時候看到的數據都是一個單獨的copy，這也就是copy-on-write，直到事務的整個生命周期結束、修改完成，下一個事務進來的時候才會看到新的copy，這就是Snapshot隔離級別的MVCC。怎麼做的呢？其實還是計算機領域那句經典的話“All problems in computer science can be solved by another level of indirection”，也就是說所有的計算機問題都可以通過添加一層中間層來解決，在這裏的應用就是通過添加一個Request Proxy這樣一個中間層來解決問題。

核心技術6：硬件加速

88dde717bfbb75e804451a146f5bb934b4322a0d

目前這部分是HiStore在嚐試進行實現的，現在就是包括FPGA、GPU等技術都在進行嚐試，在FPGA方麵的嚐試是基於Intel的QAT技術，實際上QAT這個技術成功的落地場景主要有三個：編解碼、壓縮解壓以及加解密。我們就是應用Intel QAT的FPGA板來分擔CPU的壓縮解壓這部分，這樣就可以釋放部分CPU的能力，因為之前壓縮解壓是非常消耗CPU的工作。這樣有什麼好處呢，一個就是傳統的GZIP算法的壓縮率是很高的，但是大家卻不常使用GZIP壓縮，因為其壓縮解壓的效率太低，而在使用了Intel QAT技術之後，就可以將這部分工作放到FPGA板上去做，實際上就可以讓壓縮的吞吐量增加，那我們就可以重新啟用GZIP的壓縮方式，這樣就可以在獲得更好的壓縮率的同時讓吞吐量也有明顯的提升。

核心技術7: 聚合計算(group by)查詢優化

61caf2b6c614fbaf1edbaeb415dd3117e0cd752c

group by的時候會將數據分片，然後每個片單獨進行計算，之後在進行聚合，這樣可以優化group by場景下的查詢，就不詳細介紹了。

核心技術8：生態兼容

7d3a1c46b7e637f56495de6c56b1c3b76cbc6d4e

在這部分主要做與Binlog的兼容，做主備之間同步，以及與其他數據源之間打通，通過Binlog方式結合精衛以及DRC等已有的工具實現多數據源的同步。

技術部分就先分享到這裏，那海量數據OLAP產品HiStore也就分享到這裏。

那麼除此之外，我還想借此機會分享另外一個產品，就是高性能時序數據庫HiTSDB。大家知道，目前在監控以及IoT場景下，時序數據庫是一個非常熱門的話題，在這樣的背景下，阿裏也推出了一款產品叫做HiTSDB，也就是Hi-performance Time Series Database，並且在7月31日在阿裏雲公網上已經開始進行公測了，大家可以在阿裏雲官網上留意一下。

HiTSDB主要解決的是時序場景，那麼什麼是時序場景呢？實際上就是在時間上分布的一係列數值，其實這個場景也非常多，比如股票、氣溫變化以及網站的PV、UV、IOT的工業傳感器數據以及整個服務器監控的數據、硬件指標等等以及車聯網等基於時間維度的一係列數值。