交易分析混合負載HTAP方興未艾時，同時，還有一個新的概念在業界流轉，即HSAP，Hybrid Serving & Analytical processing 服務分析混合負載。

1. 概念

在討論HSAP之前，首先需要了解其概念中對服務與分析的區分。相當多從應用角度對數據處理分類的劃分，大致分為Transaction交易與Analysis分析兩大類，一類位于企業數據架構的上游用于生產數據，一類位于企業數據架構的下游用于數據價值的利用。而HSAP則對位于下游的數據價值利用進行了進一步的區分：簡單查詢與復雜的分析查詢，前者涉及的數據范圍小，實質上是傳統TP系統擅長的點查，或者簡單聚合查詢，后者涉及的數據范圍大，需要掃描大量數據，實質上是傳統AP系統擅長的分析類查詢。在HSAP的概念中，將簡單點查稱為“數據服務”，將”復雜查詢“稱為“分析”，而兩者的混合負載就稱為HSAP，這就是HSAP概念的解釋。

2. HSAP需求分析

初看起來，HSAP的需求，HTAP也能實現：Transaction交易機制滿足QPS類點查需求，Analysis分析機制滿足復雜查詢需求。而在標準的HTAP數據庫（一般是指分布式數據庫，不包括那些自稱是HTAP但實際是傳統單體數據庫架構的產品）中，一般都存在兩套技術機制，即基于行存的交易機制與基于列存的分析機制，兩者采用分離且實時一致的存儲引擎，或者統一且行列混布的共享存儲引擎。

但為什么又會有HSAP的提法呢？其核心的原因實際上來源于：HSAP的出現是為了滿足企業對“大數據”的需求。也就是說，HTAP雖然同時滿足交易類數據的分析查詢需求，但對更大范圍的大數據，比如來自日志等非交易系統（用戶行為）的數據，則不能很好的滿足。因為HTAP系統設計的基石和優勢是支持細粒度的分布式事務，交易型數據往往以大量分布式小事務的方式寫入HTAP系統。而來自日志等系統的數據，大多并沒有分布式事務的需求，以HTAP系統來處理它們，顯然會帶來不必要的開銷，從而降低了系統效能；更重要的是，這類非交易型大數據的體量，要比交易數據大的多，甚至是好幾個數據級，這就帶來了HSAP系統的另一個技術要求：動輒每秒鐘數千萬甚至上億條事件的極高吞吐數據實時寫入，包括海量單條與低頻批量。只有能夠與HTAP一樣，實時的承載大數據+交易數據的寫入，并在秒級甚至亞秒級就能被服務與分析所消費，而不是需要一個冗長的離線ETL過程，HSAP的概念才真正有意義。

相當長一段時間以來，企業面向這種HSAP的需求都是采用一套復雜的技術棧組合來完成的，例如用Flink+HBase+Hive/Druid等等形成一個集成系統，其間不可避免的數據孤島、數據同步、一致性等問題對開發與運維都帶來了巨大的復雜性，而HSAP即是用一套系統來滿足這種要求。

在如上討論中，分布式是一個隱含的條件，因為彈性與擴展需求是不言而喻的，這里就不再贅述。

3. HSAP技術特性

至此，關于HSAP不僅是概念清楚了，即“服務分析混合負載的分布式數據系統”，而且對其技術特性與要求也清楚了：

HSAP要求極高的實時數據載入吞吐量。每秒數千萬、上億甚至更高的數據載入能力，同時這些數據對服務與分析來講必須是實時可消費（秒級、亞秒級）的；

HSAP要求極高并發、極高性能的簡單查詢能力，需要輕松支撐每秒數千萬甚至上億次簡單查詢，并且延遲極低；

HSAP要求相對高并發、極致性能的復雜分析能力。也就是說，HSAP要具有傳統MPP架構OLAP數據庫（如GP）的同等能力；

HSAP的上述一個特性是混合負載的，對用戶來講是一套系統實現的。

4. HSAP與HTAP

再來看看HSAP與HTAP的區別。本質上，HSAP的出現，是因為在應對更大數量的非交易型大數據需求時，HTAP中Transaction的分布式小事務能力，其實是不需要的，但卻會帶來不必要的開銷。從而，HSAP為了滿足這一類的需求，對HTAP中的分布式小事務能力進行了妥協，從而帶來了吞吐、性能的提升，這實際上是繼Hadoop類大數據系統與分布式事務型數據庫之后，CAP理論的又一產出。

這樣看來，HSAP與HTAP都會成為企業數據架構中不可或缺的重要組成部分，而在應對有規模企業，特別是當互聯網/物聯網應用不斷擴大時，企業分析查詢對大數據有著越來越高的需求，那么這時，HSAP就有了其更加不可或缺的作用。而對HTAP數據庫來講，雖然在技術實現上并不會太簡單，但從本質上講，HTAP在對其分布式事務能力進行妥協后，應該也有同時具備HSAP能力的潛能。

總結

以上是生活随笔為你收集整理的关于HTAP与HSAP的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。