我們上文提到了實時數據分析時當前熱點。我們先舉一個例子來看看當下的實時數據分析是怎樣的一種情景。我們通過對經典統計分析案例——“啤酒尿布”的全新闡釋來表述這點。我們看看如何在時下最流行的電商O2O如何實現一次成功的“實時在線版的啤酒尿布”案例：
● 在某個經濟不景氣時期，上海的一個普通中產家庭，男主面臨程序員35歲職業警戒線待業在家帶娃，金融女主只得拼命賺錢，典型的一個女主外男主內的CP組合；
● 這位爸爸白天在家照看寶寶時，在河馬鮮生上下了一份啤酒+滷煮訂單。這條訂單信息實時進入到阿里數據中臺，經過統計分析，將結果發送到了阿里其他事業部；
● 天貓接受到這條數據，即時通過APP向男主推送一條紙尿褲促銷信息，男主看到已經所剩無幾的紙尿褲，立即完成了這條推送商品的下單。
我們可以看到實時數據分析使得數據流轉不再受數據同步的時效性所限，真正實現了數據應用的全鏈路打通。
“Online啤酒尿布”的案例表明，大數據發展到現在必須精耕細作，這也對大數據平臺研發的從業者有了更高的要求。
過去的大數據平臺（MPP+Hadoop）只支持批量插入，寫入失敗容易產生髒數據，導致查詢分析失敗；現在，實時數據分析要求支持事務更新，允許一邊讀一邊更新，甚至多個 writer 同時操作，ACID 的那種，保證一致性地讀取和分析查詢。怎麼實現呢？我們先來看看開源界的大大數據組件是否能滿足。
開源組件
首先，開源大數據領域的 Hive、SparkSQL比較難以滿足，只能提供批處理，分析和查詢不是強項，由於大家對Hive、SparkSQL都很熟悉，這裡就不再贅述。
開源大數據領域一枝獨秀算是 Cloudera 的 Kudu + Impala 組合，可以一邊做些記錄更新，一邊 Impala 查詢馬上就能得到最新結果。具體說，Kudu的列式存儲對分析有很大的性能提升，它的記錄是直接以行式寫到內存上的 B 樹，然後再異步刷到磁盤；後臺再對這些增量數據進行合併，寫列式存儲文件。這個時候如果啟動 Impala 查詢，就會高效讀取到這些列式存儲文件，但是對於還沒有合併的行式增量更新文件，則只有全部讀進來自己合併得到完整結果。如果還在內存裡面呢？更甚者，如果還在分佈式一致性寫入協議過程中呢？也就是說還沒有 committed。這樣的話，Kudu可能會很難單獨發揮出優勢來，畢竟分析引擎和過程是另外的，跟存儲系統分開了。只能構成一個方案，但由於跑批處理並不擅長，還需要與Hive、SparkSQL先計算完了導入Kudu，或者從Kudu導出Hive等跨庫操作。
所以，從本質上來講，這類系統因為分析時可能讀取不到最新更新操作，可能並不算是最嚴格意義上的實時。不過在開源大數據領域，在原有的海量數據分析上面支持更新操作，能夠按照版本或者時間支持 snapshot isolation 一致性地讀，已經是個很大的進步了，畢竟主要還是解決大數據場景問題。
除此之外，國內這兩年比較活躍的MySQL，微軟的 SQL Server，阿里巴巴的DRDS等，原本是 OLTP 為主，也都想辦法配備上了 Spark，支持分析負載。思路都大同小異，通過技術棧方式搭配發揮作用。CAP問題不能融為一體地去解決。
在大家都從開源世界裡尋找各種組件來搭建自己的實時數據分析系統的這個前提下，TA融合漸漸走入了大家的眼界中。
TA融合
什麼叫TA融合？TA 融合是指事務（Transaction）與分析（Analysis）的融合機制。傳統的業務應用在做技術選型時，會根據使用場景的不同選擇對應的數據庫技術，當應用需要對高併發的用戶操作做快速響應時，一般會選擇面向事務的OLTP 數據庫；當應用需要對大量數據進行多維分析時，一般會選擇面向分析的OLAP 數據庫。
在數據驅動精細化運營的今天，海量實時的數據分析需求無法避免。分析和業務是強關聯的，但由於這兩類數據庫在數據模型、行列存儲模式和響應效率等方面的區別，通常會造成數據的重複存儲。事務系統中的業務數據庫只能通過定時任務同步導入分析系統，這導致了數據時效性不足，無法實時地進行決策分析。
有了TA融合的這一技術驅動，HTAP數據庫就呼之欲出了。數據庫經過40年的發展，經過從RDMS到MPP到NoSQL數庫，即將進入到HTAP數據庫的時代。
HTAP——混合分佈式數據庫
混合事務/分析處理（HTAP）是Gartner 提出的一個架構，它的設計理念是為了打破事務和分析之間的那堵“牆”，實現在單一的數據源上不加區分的處理事務和分析任務。這種融合的架構具有明顯的優勢，可以避免頻繁的數據搬運操作給系統帶來的額外負擔，減少數據重複存儲帶來的成本，從而及時高效地對最新業務操作產生的數據進行分析。現階段主流的實現方案主要有三種：一是基於傳統的行存關係型數據庫（類似MySQL）實現事務特性，並在此基礎上通過引入計算引擎來增加複雜查詢的能力；二是在行存數據庫（如Postgres-XC 版本）的基礎上增加列存的功能，來實現分析類業務的需求；三是基於列存為主的分析型數據庫（如Greenplum），增加行存等功能優化，提供事務的支持。但由於沒有從根本上改變數據的存儲模式，三種方案都會在事務或分析功能上有所側重，無法完美的在一套系統裡互不干擾地處理事務和分析型任務，無法避免對數據的轉換和複製，只能在一定程度上縮短分析型業務的時延。
我們本篇講述了TA融合的訴求促使HTAP數據庫的到來。我們下一章將詳細講述HTAP代表新一代數據庫——NewSQL，如何從一個理論到真正實現落地的。
轉載天貓接受到這條數據，即時通過APP向男主推送一條紙尿褲促銷信息，男主看到已經所剩無幾的紙尿褲，立即完成了這條推送商品的下單。
我們可以看到實時數據分析使得數據流轉不再受數據同步的時效性所限，真正實現了數據應用的全鏈路打通。
“Online啤酒尿布”的案例表明，大數據發展到現在必須精耕細作，這也對大數據平臺研發的從業者有了更高的要求。
過去的大數據平臺（MPP+Hadoop）只支持批量插入，寫入失敗容易產生髒數據，導致查詢分析失敗；現在，實時數據分析要求支持事務更新，允許一邊讀一邊更新，甚至多個 writer 同時操作，ACID 的那種，保證一致性地讀取和分析查詢。怎麼實現呢？我們先來看看開源界的大大數據組件是否能滿足。
開源組件
首先，開源大數據領域的 Hive、SparkSQL比較難以滿足，只能提供批處理，分析和查詢不是強項，由於大家對Hive、SparkSQL都很熟悉，這裡就不再贅述。
開源大數據領域一枝獨秀算是 Cloudera 的 Kudu + Impala 組合，可以一邊做些記錄更新，一邊 Impala 查詢馬上就能得到最新結果。具體說，Kudu的列式存儲對分析有很大的性能提升，它的記錄是直接以行式寫到內存上的 B 樹，然後再異步刷到磁盤；後臺再對這些增量數據進行合併，寫列式存儲文件。這個時候如果啟動 Impala 查詢，就會高效讀取到這些列式存儲文件，但是對於還沒有合併的行式增量更新文件，則只有全部讀進來自己合併得到完整結果。如果還在內存裡面呢？更甚者，如果還在分佈式一致性寫入協議過程中呢？也就是說還沒有 committed。這樣的話，Kudu可能會很難單獨發揮出優勢來，畢竟分析引擎和過程是另外的，跟存儲系統分開了。只能構成一個方案，但由於跑批處理並不擅長，還需要與Hive、SparkSQL先計算完了導入Kudu，或者從Kudu導出Hive等跨庫操作。
所以，從本質上來講，這類系統因為分析時可能讀取不到最新更新操作，可能並不算是最嚴格意義上的實時。不過在開源大數據領域，在原有的海量數據分析上面支持更新操作，能夠按照版本或者時間支持 snapshot isolation 一致性地讀，已經是個很大的進步了，畢竟主要還是解決大數據場景問題。
除此之外，國內這兩年比較活躍的MySQL，微軟的 SQL Server，阿里巴巴的DRDS等，原本是 OLTP 為主，也都想辦法配備上了 Spark，支持分析負載。思路都大同小異，通過技術棧方式搭配發揮作用。CAP問題不能融為一體地去解決。
在大家都從開源世界裡尋找各種組件來搭建自己的實時數據分析系統的這個前提下，TA融合漸漸走入了大家的眼界中。
TA融合
什麼叫TA融合？TA 融合是指事務（Transaction）與分析（Analysis）的融合機制。傳統的業務應用在做技術選型時，會根據使用場景的不同選擇對應的數據庫技術，當應用需要對高併發的用戶操作做快速響應時，一般會選擇面向事務的OLTP 數據庫；當應用需要對大量數據進行多維分析時，一般會選擇面向分析的OLAP 數據庫。
在數據驅動精細化運營的今天，海量實時的數據分析需求無法避免。分析和業務是強關聯的，但由於這兩類數據庫在數據模型、行列存儲模式和響應效率等方面的區別，通常會造成數據的重複存儲。事務系統中的業務數據庫只能通過定時任務同步導入分析系統，這導致了數據時效性不足，無法實時地進行決策分析。
有了TA融合的這一技術驅動，HTAP數據庫就呼之欲出了。數據庫經過40年的發展，經過從RDMS到MPP到NoSQL數庫，即將進入到HTAP數據庫的時代。
HTAP——混合分佈式數據庫
混合事務/分析處理（HTAP）是Gartner 提出的一個架構，它的設計理念是為了打破事務和分析之間的那堵“牆”，實現在單一的數據源上不加區分的處理事務和分析任務。這種融合的架構具有明顯的優勢，可以避免頻繁的數據搬運操作給系統帶來的額外負擔，減少數據重複存儲帶來的成本，從而及時高效地對最新業務操作產生的數據進行分析。 現階段主流的實現方案主要有三種：一是基於傳統的行存關係型數據庫（類似MySQL）實現事務特性，並在此基礎上通過引入計算引擎來增加複雜查詢的能力；二是在行存數據庫（如Postgres-XC 版本）的基礎上增加列存的功能，來實現分析類業務的需求；三是基於列存為主的分析型數據庫（如Greenplum），增加行存等功能優化，提供事務的支持。但由於沒有從根本上改變數據的存儲模式，三種方案都會在事務或分析功能上有所側重，無法完美的在一套系統裡互不干擾地處理事務和分析型任務，無法避免對數據的轉換和複製，只能在一定程度上縮短分析型業務的時延。
我們本篇講述了TA融合的訴求促使HTAP數據庫的到來。我們下一章將詳細講述HTAP代表新一代數據庫——NewSQL，如何從一個理論到真正實現落地的。
END
閱讀更多 MaskVC 的文章
