HBase方案 | 基於Lindorm的互聯網帳單解決方案

               

一.背景

無論是對於傳統行業仍是對於互聯網行業，交易訂單數據的存儲需求由來已久，好比筆者最初所處的民航業，其CRS系統（代理人機票售票系統）存儲了旅客的訂座記錄；又如各種銀行須要存儲廣大儲戶在其系統內的支取和存入的流水記錄；再如電子商務/第三方支付平臺，廣大網民的網購、繳費、理財、充值等交易行爲的記錄也須要保存。
交易性質的數據每每有較強的事務需求，好比電商系統中交易數據的存儲會有多張表，表與表之間的數據須要保證強一致性。基於這樣的要求，CRS系統最初選擇了專業性較強的Unisys大型機系統及其數據庫；銀行的選擇則是你們較爲熟悉的IBM DB2；而淘寶/支付寶這樣的電子商務的領頭羊，最初的選擇則是Oracle，在Oracle時代每每是一個業務一套數據庫，不一樣業務作垂直隔離，其架構以下圖所示：

如前所述，對於第三方支付場景，交易系統主要面向接單，操做以寫入爲主。可是，隨着其業務場景的不斷豐富，從最初只有網上購物，以後涌現出轉帳、公共事業繳費、話費充值等等愈來愈多的場景，而這些系統因其業務特徵的不一樣，每每是相互垂直，相對獨立的交易系統。這樣一來，對於一個普通網民而言產生了一個樸素而基本的需求，有一個統一的帳單查詢入口，畢竟普通老闆姓的錢不是大風颳來的。所以，帳單系統應運而生。

二.互聯網帳單系統的架構演進

互聯網帳單系統，從誕生的第一天起附帶了一些自然的屬性。

• 只讀性：帳單的數據來自於上游各個交易系統，經過可靠消息進行數據同步，提供統一的查詢入口給最終用戶。

• 高增加：互聯網的一個很是典型的特徵就是超乎想象的高速增加，特別是處於風口的豬，是真的會被吹起來的。

• 低成本：帳單系統不像交易系統，不直接產生經濟效益，總有一種庶出的感受。所以，指望重金投入那是絕對不可能的。

• 高可用：帳單系統是面向客戶，對交易系統的延伸，是客戶對交易數據的查詢入口，對C端客戶而言，其實並存在交易系統和帳單系統的區分。所以，這兩個系統的可用性要求是一致的。

• 多維度查詢：對於C端用戶而言，每每會從不一樣角度對帳單進行分類、標記以及查看和過濾本身的帳單。

2.1一代架構

2.1.1 基於MySQL的分庫分表

基於上述的特徵，在IOE還處於統治地位的時代，支付帳單系統最初擁抱的並非交易系統使用的、成本高昂的Oracle數據庫，而是開源世界裏最流行的、基於PC服務器的MySQL數據庫，而且由於規模的緣由，每每須要引入相對更加複雜的分表、分庫方案，其架構以下圖所示(圖中省略了MySQL Slave集羣及Master、Slave間的複製關係)：

然而，如前所述，業務的快速增加帶來數據的極速膨脹，須要不斷的增長分表、分庫的數量，不然就會達到MySQL單實例的瓶頸，而拆分爲更大規模的分表、分庫的運維代價是極其巨大的。基於此緣由，帳單系統的存儲演變到了下一代架構。

2.2 二代架構

上文描述到，隨着業務的不斷增加，因爲MySQL自身容量的天花板，第一代架構面臨的問題沒法解決，單純依賴MySQL的架構已經再也不是帳單業務的合適選擇。
所以，不一樣的用戶作出了不一樣的選擇。

2.2.1 MySQL熱數據+HBase全量的混布架構

作爲架構演進的一種選擇，有一部分用戶的選擇是仍然依賴MySQL，但會將經過消息系統過來的數據同時寫入到MySQL的分表和HBase集羣中的單表。MySQL作爲主存儲，承擔「熱」數據的讀請求，而HBase作爲備存儲，僅承擔歷史數據的讀請求。這種架構下MySQL僅須要保存業務定義的指定週期內的熱數據，所以，在演變到該架構的初期，極大的緩解了數據增加帶來的壓力。
可是，隨着時間的推移，業務的飛速發展，熱數據的量不斷變大，所以仍然面臨繼續作拆分的需求；並且須要天天起定時任務進行歷史數據的刪除，大規模的數據刪除引發了集羣負載的升高，對集羣穩定性產生了嚴重的隱患；
另外一方面，業務形態也在發生變化，好比：出現了最典型的「雙十一」，這樣超級的業務大熱點，這就迫使須要對MySQL作更細粒度的拆分，而且每一年大促前要大量擴容節點，大促後還原到原有規模，這對於存儲系統提出了極致的彈性擴縮容需求，而這樣的要求對於存儲計算一體化的架構而言是很是大的挑戰。
同時，雙十一帶來的不只僅是業務量上的一個巨大尖刺，也帶來了一些其餘的不穩定因素，好比：會隨時奔出來一個大賣家，這樣的大熱點每每致使單個MySQL實例容量不足，在計算存儲一體化的架構下，應對這樣的問題老是顯得有點力不從心。

2.2.2 基於Share Nothing架構的分佈式關係型數據庫

作爲架構演進的另外一種選擇，其餘一部分用戶則拋棄了MySQL，選擇新的市面上比較流行的分佈式關係型數據庫。分佈式關係型數據庫經過其內置的數據分片的能力，很好的避免了業務增加、新業務場景(雙十一)帶來的分庫、分表的需求；經過其自動化的擴容/縮容能力，相比MySQL架構下的運維成本也有大幅度的下降。
可是，這種架構下也面臨着一些問題：

• 存儲成本高

• 
  

  • 沒法按需擴縮容：單臺服務內的CPU、內存、磁盤資源的配比是固定的，在Share Nothing架構下，無論是計算仍是存儲資源不足，都只能進行總體擴容，這樣就致使了沒必要要的資源投入，從而提升了運行成本。

• 
  

  • 冷熱分離：在Share Nothing架構下，即使不考慮是否已經實現了冷熱分離，在實踐層面也會有一些問題。好比：帳單數據有永久保存的需求，意味着冷數據佔比會愈來愈高，而機型是固定的，所以集羣會由於冷存儲不能知足需求，而進行擴容，從而致使沒必要要的資源投入；或者採用非固定/非標準化機型，則意味着運維複雜度的提高。

• 
  

  • 性能問題：關係型數據庫主要面向的業務場景是有強事務需求的交易、支付、帳務類業務，須要強事務保證，每每會致使部分操做的串行化，從而下降了性能。另外一方相關係型數據庫不像NoSQL，須要通過SQL層的解析並生成執行計劃後才能執行，這個過程也不可避免的產生了必定的資源開銷，從而下降了性能。性能的降低意味着單機吞吐量的降低，進而須要更多的服務器資源的投入，即意味着成本的增長

• 彈性能力差
  存儲計算一體的Share Nothing架構，致使擴容節點的過程須要伴隨着數據的搬遷，從而致使節點擴容的代價和耗時都是比較大的，致使面對雙十一這樣的須要極致彈性擴縮容能力的場景，顯得力不從心。更長的擴縮容時間意味着更長的資源保有周期，從而提高了大促運行成本

• 熱點問題：

• 
  

  • 應急效率低：Share Nothing架構下，應對隨時可能出現的熱點問題也是很是低效的,致使有較高的穩定性風險。好比：雙十一忽然涌現出來的一個大賣家，熱點賣家和該節點的其餘賣家共享服務器資源，因爲歷史數據的存在，並不能當即隔離識別出來的熱點，而是須要等待歷史數據同步完成後，才能切流到獨立的空閒節點。這樣的應急速度在雙十一這樣的大促下顯然是很是低效，難以知足穩定性需求的。

• 
  

  • 存儲不均衡：Share Nothing架構下，有熱點帳號的狀況下，數據量每每也會比較大，致使節點間數據量的不均衡，從而須要人工去幹預對大帳號所在節點作拆分，致使運維成本上升。

2.3 三代架構

所以，勢必須要有一種新的更完善的數據庫產品來知足帳單場景的需求。
首先，咱們簡單回顧一下1、二代架構下面臨的最核心的業務痛點，也是三代架構下必需要着重面對而且解決的問題。

• 存儲成本高

• 彈性能力差

• 熱點問題

那麼，市面上是否存在這樣的一款數據庫產品「剛好」 能解決帳單場景在1、二代架構下遇到的問題，同時又能很好的知足帳單系統對可用性，對多維度查詢的要求？答案是確定的。Lindorm正是這樣一個合適的數據庫選型。

三.基於Lindorm的架構

Lindorm是誕生於大數據時代的一款NoSQL數據庫，低成本解決海量大數據的高效存、取是根植於其體內的基因。Lindorm在阿里內部歷經十年的技術積澱，目前是阿里內部使用最爲普遍的、數據體量最大的核心數據庫產品。這一切歸功於Lindorm擁有衆多的核心技術和功能特性。
那麼，面向帳單場景的業務痛點，Lindorm有哪些重要的抓手呢？

3.1 低成本

對於帳單這樣的海量數據場景，數據有着很是典型的訪問特徵，近期數據訪問頻率較高，請求的響應延遲要求也較高，隨着時間的推移訪問頻率會逐步下降，甚至僅做爲歷史數據存在，而只有極少許的訪問，但另外一方面業務要求數據永久保留的特性，致使其在線數據體量很是大。Lindorm的冷熱分離和壓縮優化則能夠很是有效的解決這個問題。

3.1.1 冷熱分離

Lindorm具有在單一個存儲架構下的「一張表」內實現數據的冷熱分離，系統會自動根據用戶設置的冷熱分界線，自動將表中的冷數據歸檔到冷存儲中。在用戶的訪問方式上和普通表幾乎沒有任何差別，在查詢的過程當中，用戶只需配置查詢Hint或者Time Range，系統根據條件自動地判斷查詢應該落在熱數據區仍是冷數據區。對用戶而言始終是一張表，對用戶幾乎作到徹底的透明。

3.1.2 壓縮優化

存儲成本最低的系統是沒有數據須要存儲的系統，但這點顯然是不現實的，現實可行的方案是將須要存儲的數據降到合理的最低點。
爲了下降存儲開銷，Lindorm引入了一種新的無損壓縮算法，旨在提供快速壓縮，並實現高壓縮比。它既不像LZMA和ZPAQ那樣追求儘量高的壓縮比，也不像LZ4那樣追求極致的壓縮速度。這種算法的壓縮速度超過200MB/s, 解壓速度超過400MB/s（實驗室數據），很好的知足Lindorm對吞吐量的需求。經實際場景驗證，新的壓縮優化下，壓縮比相對於LZO有很是顯著的提升，存儲節省能夠達到50%～100%，對於存儲型業務，這就意味着最高能夠達到50%的成本減小。

3.2 極致彈性

互聯網世界老是以超乎想象的速度在飛速增加。帳單的峯值讀&寫請求量、須要存儲數據量會伴隨着業務飛速的增加，每一年都會是上一年的翻倍甚至數倍，所以須要存儲系統具有良好的擴展能力。
雙十一這樣的業務場景，則會瞬間帶來數十倍甚至百倍的峯值讀寫量，爲了知足這樣的場景，就須要存儲系統具有更加極致的彈性擴、縮容的能力。
如前所述，低成本解決海量大數據的高效存、取是根植於Lindorm體內的基因。所以，Lindorm自然就具有了良好的線性擴展能力，能夠很好的支撐每秒億級別請求，PB級數據量，並且在大數據量、高併發下仍然能提供穩定的毫秒級的平均響應。
Lindorm原生支持存儲計算分離架構( 其架構以下圖)，這樣的架構設計使得集羣擴容、縮容都變得很是的輕量，說簡單一點就是「起個進程+數據分片balance」這點事，新節點接收業務請求並不須要等待歷史數據的搬遷，而縮容剛恰好是逆向的過程。所以，對於Lindorm而言彈性擴縮容固然是分分鐘搞定咯！

3.3 熱點問題

3.3.1 高效熱點響應

交易分爲買家和賣家兩個對手方，帳單數據也每每會按照這兩個用戶維度進行組織。從單個買家角度看每每交易量較低，不至於造成熱點。可是賣家卻多是一個大的焦點，特別是在雙十一這樣的大壓力下，單個UID的交易量尖刺每每會更高。
熱點對於任何一個存儲系統而言都是災難性的，但Lindorm自然的讀寫分離架構在應對熱點方面會有更大的優點。
Lindorm分爲存儲和計算兩層，LDserver負責數據分片的組織和讀寫訪問，Lindorm Store負責文件的存儲和訪問。數據分片在不一樣LDserver之間的移動並不須要考慮Lindorm Store層存儲位置。所以，當讀寫出現熱點時，Lindorm能夠經過快速移動數據分片到空閒節點，便可秒級完成熱點數據分片的隔離，達到提高抗熱點的能力。

3.3.2 存儲水位不均問題

如前所述，Lindorm採用存儲計算分離的架構，數據按region進行分片，其大小在GB級別，一般指定爲8G，16G，超過閾值會自動進行split，數據分片會自動在不一樣節點間進行balance。所以，這樣的架構設計使得Lindorm能夠很好的保持不一樣節點間數據量的均衡。從而很好的避免了Share Nothing架構下熱點帳號帶來的「沒必要要」的運維工做。

3.4 其餘必要特性

Lindorm的上述幾個特性很好的解決了帳單系統在1、二代架構中難於解決的問題，可是帳單場景對存儲系統基本要求：可用性、多維度查詢，在三代架構下也是必需要知足的，不然就是顧此失彼，甚至得不償失了。

3.4.1 高可用

Lindorm的表數據經過自動balance策略分散到集羣中的多臺服務器上，每個數據分片能夠擁有1至N個副本，這N個副本擁有主、從兩種角色，主從副本能夠加載在不一樣的Zone，從而保障集羣的高可用和強一致。針對不一樣的一致性模式，主從副本之間的數據同步和讀寫模式以下：

• 強一致模式：只有主副本提供讀寫，數據會異步回放到從副本,主副本所在節點故障，從副本晉升爲主(晉升以前會保障數據同步完成，從副本擁有全部最新數據，總體過程由Master協調負責)

• 最終一致模式：主從副本都提供讀寫，數據會相互同步，保證副本之間的數據最終一致。
  

經過這樣的高可用機制，Lindorm能夠很好的保障帳單這樣的對數據強一致性和可用性需求都很是高的業務。

3.4.2 多維度查詢

爲了解決業務基於非主鍵列的查詢問題，Lindorm內置原生的全局二級索引功能，對於列較少且有固定查詢模式的場景來講，高性能二級索引方案可以完美解決此類問題，同時仍保持強大的吞吐與性能。

當面對更加複雜的查詢，好比模糊查找、隨機條件組合查詢等等，二級索引方案會顯得力不從心，這時候Lindorm搜索引擎LSearch就有其用武之地。LSearch是面向海量數據設計的分佈式搜索引擎，兼容開源Solr標準接口，同時可無縫做爲寬表、時序引擎的索引存儲，加速檢索查詢。其總體架構與寬表引擎一致，基於數據自動分區+分區多副本+Lucene的結構設計，具有全文檢索、聚合計算、複雜多維查詢等能力，支持水平擴展、一寫多讀、跨機房容災、TTL等，知足海量數據下的高效檢索需求。

四.Lindorm核心能力概述

Lindorm經過全方位多角度的能力提高，充分知足了帳單場景的高可用、高吞吐、低延遲、低成本、多維度及可能的突發熱點請求等等一系列的需求。
固然，Lindorm的能力還遠不止於此，Lindorm具有了大數據背景下，面向海量數據的存儲系統應該具有的一系列的能力：

• 是一款支持寬表、時序、搜索、文件的多模數據庫

• 是一款基於存儲計算分離架構的數據庫，提供極致的計算、存儲彈性伸縮能力，並將全新提供Serverless服務，實現按需即時彈性、按使用量付費的能力

• 是一款支持冷熱分離、、追求更優壓縮優化方案的極具性價比的數據庫

• 是一款具有全局二級索引、多維檢索、時序索引等功能的數據庫

• 提供具有智能化服務能力的LDInsight工具，白屏化完成系統管理、數據訪問及故障診斷

• 提供LTS(Lindorm Tunnel Service，原BDS)，支持簡單易用的數據交換、處理、訂閱等能力，知足用戶的數據遷移、實時訂閱、數湖轉存、數倉迴流、單元化多活、備份恢復等需求

五、帳單場景客戶案例

第三方支付帳單

某國內領先的第三方支付平臺，致力於提供「簡單、安全、快速」的支付解決方案。自2014年第二季度開始成爲當前全球最大的移動支付廠商。
自從2013年起，該第三方支付平臺已經將其全量的在線交易、線下交易、繳費、轉帳等等各種交易數據全量存儲在Lindorm內，提供實時、在線查詢，能夠獲取帳單詳情以及經過各種篩選條件知足C端用戶的帳單篩選需求。

收錢吧

隸屬於上海喔噻互聯網科技有限公司，是中國移動支付服務商領軍者，致力於用網絡和數據的力量服務線下實體商家。收錢吧不只爲商家提供專業移動支付收款工具，同時也是爲商家提供金融、廣告、營銷管理、供應鏈等多種服務的生意幫手。2014年12月，收錢吧正式上線，開創了中國移動支付市場「一站式收款」時代，併成功研發了「收錢吧掃碼王」等全場景智能收款設備，產品得到多項國家專利。目前收錢吧服務超過330萬商家，日服務3000萬人次。
收錢吧使用Lindorm做爲其訂單解決方案，成功實現了：

• 全文索引方案，使得業務高性能實現高維度&隨機組合場景下的訂單搜索

• 數據壓縮優化及集羣內冷熱分離，使得業務低成本實現數據永久保留

• 相比優化前的架構，成本降低77.42%

• 全託管、免運維及SLA保障，並有專家團隊的免費技術支持，使客戶能盡心盡力聚焦業務側發展