介紹一個有趣的數據系統Operational Analytics Processing，OPAP系統。不同於傳統的OLTP和OLAP，它更注重於實時數據的即時分析。下面這篇文章加了我自己的一些理解和實踐經驗，原文請參考：https://www.rockset.com/blog/operational-analytics-what-every-software-engineer-should-know/
OPAP系統特徵
OPAP系統構建了一個實時查詢的系統可以使用者立馬能夠查詢到實時數據。舉個簡單的例子，當用戶參加一項活動時，產品經理或者是運營人員希望能夠馬上獲得用戶的參與效果，並且快速的探索用戶的行爲特徵，從而立馬改進活動以獲得更好的效果。正所謂：越來接近實時的數據，越有價值。OPAP系統的意義便在於此。
爲了達到這樣的效果，OPAP系統必須具有以下的幾個特徵：
- 支持複雜查詢：例如 joins, aggregations, sorting等類型的查詢，最好能是SQL語句。
- 低數據延遲: 數據的任何變化都能夠在幾秒鐘內被查詢到。因爲主要是用於分析，所以OPAP系統無需像OLTP系統一樣支持事務。基於此，OPAP系統可以保持高吞吐的寫入和在幾秒鐘內看到最新的數據（即最終一致性）。
- 低查詢延遲：可以在幾百毫秒內返回一個簡單的查詢結果。這一點類似於OLTP系統，每一次的查詢都只牽扯到很少的數據量。
- 支持併發查詢: 能夠支持幾百條每秒的併發查詢。OPAP系統不追求高併發，但是需要支持用戶可以進行頻繁的查詢。
- 數據源實時同步：能夠持續的同步外部數據源，這個是保持OPAP系統的實時性的核心。
- 混合類型：允許在同一列出現不同類型的數據。可以避免OPAP系統無須在數據寫入時對數據進行清理,這樣就可以儘可能的實現數據低延遲。
架構設計的要點
The Database is the LOG。
從這個角度來看OLTP還是OLAP數據系統，數據都會先經過數據庫客戶端，然後將事務信息寫入到log當中。此時的log是事務引擎。
而OPAP系統追求的是更低的時延，所以數據會先寫入到log，然後再由數據庫客戶端處理後返回結果。這裏的log只是數據緩衝。
查詢的時候綁定數據類型而不是寫入時
由於OPAP架構的獨特性，導致了傳統數據系統先定義表和數據類型的方式不再適用，而是允許數據以任意方式寫入log，數據庫客戶端在查詢數據時才綁定數據類型。
目前主流數據庫的實現
與OLTP數據庫的比較
OLTP要支持事務，每一次的更新和插入都是少量數據；但是OPAP系統不需要事務，且支持大規模寫入數據。
與OLAP數據倉庫比較
OPAP和OLAP數據倉庫都支持複雜的查詢和大規模寫入，但是OLAP不能做到實時數據的即時查詢，而OPAP系統可以。然後，OLAP系統在寫入數據支持就需要很嚴格的格式，OPAP系統只在查詢時檢查數據格式並處理。
與HTAP系統比較
HTAP是OLTP和OLAP系統的混合物，因此上述提到的區別適用於HTAP。
與 key-value 存儲的比較
像 Cassandra 和 HBase 之類的KV存儲提供了低延遲和高併發，但是KV存儲不像OPAP系統那樣提供特別複雜的查詢數據功能，例如Join、排序等等。
與類Log系統比較
類Log系統指的是 Kafka、Samza 這類基於log構建的系統，它們支持實時寫入數據查詢，但是不支持複雜的查詢。
與文檔系統比較
文檔系統，例如MongoDB，原生支持複雜的數據存儲格式，大規模數據寫入和實時寫入數據查詢，但是不支持複雜的查詢，例如Join等等。
與時間序列數據庫比較
時間序列數據庫是一種特別的OPAP系統，除了複雜的查詢和混合格式寫入外，其它的屬性都支持了。
簡單總結如下：
總結
OPAP系統並不太像傳統的數據庫，它單純只是爲了讓數據能夠更快的被分析。基於這個理念，便有了很多有趣的特性，比如不支持事務，直接將數據落盤到log。同樣的也侷限了它的用途，無法適用於更爲廣泛的場景。
在平時的實踐中，如果是小數據量，傳統的關係型數據庫就足以解決了，數據量變大時，使用像Kudu一樣的分佈式數據庫滿足了大部分場景。
總的來說，作者的設想是很有意義的：對於某些分析場景，使用Flink、Spark Streaming實時計算引擎，算出結果顯得太重，也不夠靈活；類OPAP系統可以通過簡單的SQL語句將工作量釋放給產品和運營人員，大大減少了開發人員的壓力，減少了不必要的溝通，更快的獲知線上活動的情況，以期做出更好、更快的反應。
本文分享自微信公衆號 - 鴻的筆記（goodreadman），作者：鴻影洲冷
原文出處及轉載信息見文內詳細說明，如有侵權，請聯繫 [email protected] 刪除。
原始發表時間：2019-08-31
本文參與騰訊雲自媒體分享計劃，歡迎正在閱讀的你也加入，一起分享。