每秒8.8億次請求!讓數據存得起,看得見 - 雲原生多模數據庫Lindorm 2020雙十一總結

一、引言

2020雙十一順利落下帷幕,這也是雲原生多模數據庫Lindorm參與的第九個雙十一,其作爲阿里經濟體的核心數據庫產品之一,全面支撐了淘寶、天貓、螞蟻、菜鳥、阿里媽媽、高德、優酷、釘釘、大文娛等經濟體業務的結構化、半結構化數據存儲需求,今年更是爲申通這樣的公有云用戶保駕護航。

在今年的雙十一中,Lindorm整體峯值請求達到了8.8億次每秒,全天吞吐25萬億次,平均響應時間低於3ms,數據存儲量達400+PB,平均壓縮率達5:1,應用在阿里集團、螞蟻集團、菜鳥、大文娛等各個業務板塊,是目前爲止公司內部數據體量最大、覆蓋業務最廣的數據庫產品。

二、雲原生多模數據庫Lindorm

面對多模數據管理的應用需求和雲原生的技術趨勢,着眼於集團雲原生戰略、5G/IoT時代的未來發展,Lindorm在2020年全新升級爲適用於任何規模、多種模型的雲原生數據庫服務,支持海量數據的低成本存儲處理和彈性按需伸縮,提供寬表、時序、搜索、文件等多種數據模型,兼容HBase、Cassandra、Phoenix、OpenTSDB、Solr、SQL等多種開源標準接口,是互聯網、IoT、車聯網、廣告、社交、監控、遊戲、風控等場景首選數據庫。

Lindorm融合了阿里巴巴過去十年在大規模寬表、時序存儲等領域的技術能力和經驗,同時今年重點在雲原生、多模融合、低成本等方向創新突破,進一步構建海量數據存儲處理場景的競爭力,並通過集團雲原生上雲戰役,實現了一套產品同時服務內外客戶,提供穩定、高效、經濟的基礎數據庫服務。



三、Lindorm面臨的雙十一挑戰

3.1 擁抱雲原生

雲原生上雲帶來的基礎設施的雲化共池,不僅很好的解決成本與庫存孤島問題,也極大的提升了我們的運維效率,免去了過去複雜的IaaS運維開銷。同時雲原生三機房強一致容災能力首次上線,並在過去一年進行了10+次的斷網演習,確保了機房級別的容災快恢能力,夯實了底盤能力的同時,內外一致的產品技術棧也增強了我們服務公用雲客戶的信心。

物理機轉變到ECS的形態:ECS具備極強的故障自檢測恢復能力,藉助於ECS的主動運維事件透傳,結合數據庫雲管控平臺以及Lindorm內核的聯動,提前感知潛在的ECS節點故障並自動處理下線,減小ECS宕機對我們服務的影響。同時針對NC故障多臺同集羣ECS受影響宕機,我們提前感知拓撲以及巡檢進行ECS的反親和性打散,避免NC故障導致的故障半徑放大。

大規模上雲也面臨着海量數據搬遷的效率和穩定性挑戰,Lindorm在經濟內是衆多離線、在線業務數據互通很好的一個載體。業務搬遷透明無感知、服務不中斷是我們的原則,在這過程中我們通過磨鍊LTS(Lindorm Tunnel Service)產品能力解決多種異構產品之間無縫遷移的問題,使lindorm中存儲的海量數據真正的靈動起來。

3.2 存儲成本的挑戰

在Lindorm全面擁抱雲原生過程中,我們看到了基於雲存儲技術的多樣化的塊存儲、對象存儲等原子存儲能力,我們期望基於雲存儲資源構建新的數據庫存儲技術的形態,通過雲原生技術的虛擬化、彈性、按需使用等特質,實現存儲計算分離解耦,提高資源使用率,降低Lindorm的總體TCO。

同時,我們看到數據往往呈現出一定的活躍週期規律。將訪問頻率低,生命週期長的的數據沉澱到低成本存儲中,並輔以更高壓縮比的壓縮策略來降低總體存儲成本。我們基於不同種類的雲存儲能力,將冷熱溫冰不同性價比的存儲資源集成到一套系統中,構建一體化的存儲體驗。並提供基於用戶規則、基於智能判斷的策略,使得數據在Lindorm中可以自動進行冷熱分離。

3.3 核心鏈路高可用、穩定性的挑戰

目前Lindorm在集團生態體系下服務了大量核心場景,包括支付寶交易風控、花唄決策、消費記錄,GMV媒體大屏,Sunfire監控,手淘消息,阿里小蜜,物流詳情等核心系統。與此同時,Lindorm也服務了大量的中小用戶,這些用戶成本更加敏感,業務的不可控性更多,很容易出現大查詢打爆物理資源,多業務相互影響等情況,造成用戶體驗變差。

過去HBase提供的容災恢復能力,單機宕機時產生的影響會在3~5分鐘左右,在目前內部的可用性要求下,核心業務很容易出現故障。過去一年,我們從技術演進,部署形態和業務改造三方面全面推進Lindorm的高可用建設:

技術上:Lindorm持續進行可用性改造和演練,利用數據多內存副本能力,在故障發生時進行自動容災切換。雙機房最終一致場景實現10秒內自動容災,三機房強一致場景實現30s自動恢復。針對用戶經常出現的大請求,分區傾斜,單行熱點等場景,Lindorm內核側也開發了大請求調度,單region併發flush,熱點識別等能力,大大降低了因爲用戶請求不合理造成的業務影響。

部署上:推進雲原生三機房強一致容災,在用戶成本無增加的情況下保證了機房級斷網0 RPO,60s RTO。同時推出Serverless服務模式,多業務在資源上共享降低成本,通過限流,調度,彈性擴縮容等方式進行邏輯隔離,減少用戶之間的相互影響。

業務側:推動Hbase核心業務全面向Lindorm升級,目前全網的Lindorm規模10000+節點,全域的SLA服務能力大幅提升。

3.4 海量離線數據的批量導入性能的挑戰

如何在有限資源情況下支撐數倍流量增長是Lindorm數據迴流場景在雙十一面臨的最大挑戰。一方面很多重要業務的批量導入任務在大促峯值期間會執行降級預案並持續數小時,業務峯值過後,導入任務在雙十一當天的產出時間仍然需要保障,因此很多任務需要以數倍的速度去追。另一方面導入集羣的日常水位已經接近飽和,CPU使用率超過80%,但整體上資源預算已經非常緊張,擴容所需資源缺口太大。爲了應對這一挑戰Lindorm團隊打響性能攻堅戰役,對導入全鏈路進行優化迭代,最終實現4倍性能提升。特別的在大促當天,風控導入集羣資源不變,總量上漲百分之50的情況下,任務運行時間縮短爲三分之一。

Lindorm支撐Velocity 2.0架構平穩度過雙十一,批量回流鏈路的極致性能優化,爲下一代風控業務發展保駕護航。在整個性能優化過程中團隊也沉澱了RowAwareHfileWriter,MultiClusterFSDataOutputStream等專利,陸續還會在CPU cache、異步化等方面發佈新的優化版本。

四、Lindorm全新關鍵技術

4.1 融合多模

過去原生的HBase只支持KV結構的查詢,對於一些複雜的業務場景,如二級索引、搜索、時序等需求,需要借用第三方組件組合實現,大幅增加業務的複雜度。

Lindorm支持寬表、時序、搜索、文件四種模型,提供統一聯合查詢和獨立開源接口兩種方式,模型之間數據互融互通,幫助應用開發更加敏捷、靈活、高效。提供一處寫入,處處可用的能力。同時,Lindorm爲開發者提供CQL Driver、Phoenix Driver、HBase API、HDFS API、OpenTSDB API、Solr API、Lindorm API、Lindorm SQL等多種訪問方式,方便存量業務無縫切換至Lindorm,其核心能力由四大引擎提供,包括:

  • 寬表引擎,面向海量KV、表格數據,具備全局二級索引、多維檢索、動態列、TTL等能力,適用於元數據、訂單、賬單、畫像、社交、feed流、日誌等場景,兼容HBase、Phoenix(SQL)、Cassandra(CQL)等開源標準接口。
  • 時序引擎,面向IoT、監控等場景存儲和處理量測數據、設備運行數據等時序數據。提供HTTP API接口(兼容OpenTSDB API)、支持SQL查詢。針對時序數據設計的壓縮算法,壓縮率最高爲15:1。支持海量數據的多維查詢和聚合計算,支持降採樣和預聚合。
  • 搜索引擎,面向海量文本、文檔數據,具備全文檢索、聚合計算、複雜多維查詢等能力,同時可無縫作爲寬表、時序引擎的索引存儲,加速檢索查詢,適用於日誌、賬單、畫像等場景,兼容開源Solr標準接口。
  • 文件引擎,面向海量非結構化數據,具備彈性低成本、100%HDFS協議的文件存儲能力,與多模引擎共享存儲,同時支持外部系統直接訪問多模引擎的底層文件,適用於大數據分析、數據湖等場景,可使用開源HDFS客戶端直接訪問。

Lindorm支持多個模型之間的融合打通,包括數據同步、模型轉換、統一訪問、統一管理、資源共享等能力,從而將多個系統組合使用的解決方案下沉爲數據庫內置能力。對於目前使用類HBase+ElasticSearch或HBase+OpenTSDB+ES的應用場景,比如監控、社交、廣告等,利用Lindorm的原生多模能力,將很好地解決架構複雜、查詢痛苦、一致性弱、成本高、功能不對齊等痛點,讓業務創新更高效。

4.2 讓數據存得起-極致性價比

4.2.1 智能壓縮

基於LSM-Tree的數據存儲,如HBase,在組織文件內容時經常使用數據分塊編碼壓縮的方式,降低數據文件的空間佔用以減少存儲成本。Lindorm在這項技術上更進一步,Compaction前提取數據樣本進行採樣分析,根據數據特質,智能選擇合適的編碼、壓縮參數,並提取公共字典,降低壓縮算法中的字典結構帶來的額外開銷,進一步提升了數據的壓縮比率與壓縮速度。

4.2.2 冷熱數據一體化存儲

對於類似賬單這種永久保存的場景,每年數倍的存儲增長,無論是分庫分表後擴容或者歷史庫冷數據的搬遷,都存在較大的運維成本、一致性風險、並且對業務的侵入性較大。

雲原生的場景下Lindorm在同一張表裏實現了數據的冷熱分離,系統會自動根據用戶設置的冷熱分界線自動將表中的冷數據歸檔到冷存儲(SSD、高效、OSS等多層存儲)中。在用戶的訪問方式上和普通表幾乎沒有任何差異,在查詢的過程中,用戶只需配置查詢Hint或者TimeRange,系統根據條件自動地判斷查詢應該落在熱數據區還是冷數據區。對用戶而言始終是一張表,對用戶幾乎做到完全的透明。成本最低化。

4.2.3 容量型存儲

容量型存儲是Lindorm今年新推出的一種虛擬化存儲形態。基於對象存儲的低成本特質,我們將對象存儲作爲一塊共享磁盤看待,將對象存儲能力融合到LindormStore的內部數據庫塊管理機制中,在上層依然保持文件系統的全部功能以及API語義,在保持HDFS通信協議兼容的同時,使得對象存儲的低成本能力被無縫集成到Lindorm。相比雲盤雙副本存儲方案,容量型存儲降低了80%的存儲成本。更加適合歷史日誌、歷史訂單等冷數據歸檔場景。

4.2.4 共享塊存儲降副本

雲盤技術是雲原生存儲的代表之一,雲盤以塊設備爲交互界面,提供了強大的按需使用的彈性擴展能力。但是原生HDFS沒有很好的和雲盤結合,HDFS本身的多副本與雲盤底層的多副本技術重疊,造成了實際存儲資源的浪費。LindormStore基於共享塊存儲(DBFS)開發了一寫多讀共享技術,使得LindormStore在塊存儲上只需寫入一份數據,就可以保證數據可靠性與可用性。共享塊存儲的彈性擴展,動態掛載/卸載等能力,助力Lindorm實現存儲計算分離解耦,使得Lindorm在不搬運數據的基礎上實現計算與存儲資源配比動態調整成爲可能。

4.2.5 存儲計算解耦

基於4.2.3與4.2.4的雲原生存儲技術,我們使得計算資源與存儲資源徹底解耦,存儲資源與計算資源的獨立擴容成爲可能。我們不再困惑於傳統HDFS生態中的買多少計算節點,每個節點配多少存儲的資源規劃問題。LindormStore相當於一個雲原生存儲網關,數據實際存放在虛擬化的雲存儲資源池中,LindormStore提供HDFS兼容的功能語義與訪問接口。業務可以根據自身需要調節Lindorm的存儲與計算比例。存儲計算解耦帶來了更高的資源利用比例,減少了傳統IDC時代的機器資源存算比浪費。存儲與計算按需配置,爲業務帶來更高性價比的資源規劃能力。

4.2.6 ServerLess

單純的獨享部署和資源售賣的形態無法滿足所有用戶的需求。特別對於請求量特別低或者波峯波谷非常明顯的用戶,他們希望有比ECS物理資源更細粒度的彈性能力。因此,我們推出了全新的Serverless模式,Serverless是體現雲計算按需計費,極致彈性的最好形式。利用Serverless,用戶可以使用申明式的API定義對數據庫資源的要求,不需要爲未知的業務流量去預估存儲和計算資源。同時,Serverless可以真正實現全託管,用戶無需再關心容量水位,軟件版本等集羣管理問題,讓用戶的精力完全收斂於業務開發。

在Serverless模式下,用戶可以做到0請求0費用,而當業務流量突然增加時,Lindorm自身的彈性能力和Serverless大資源池共享的模式可以爲用戶提供極致的彈性體驗。而在多租戶隔離上,Lindorm原生的多租戶,Quota限流能力能夠保證各個Serverless各個租戶能夠不會相互影響。使用戶的成本,穩定性,彈性達到一個完美的平衡。

4.3 讓數據看得見-豐富索引

4.3.1 二級索引

Lindorm表天然具備主鍵索引,可以很好的滿足主鍵匹配,主鍵前綴模式的查詢需求。爲了解決了絕大多數NoSQL系統查詢非主鍵條件效率低下的問題,在誕生之初Lindorm就引入了全局二級索引,並對TTL,多版本等鬆散Schema結構提供了很好的支持。Lindorm二級索引目前除了可以通過SQL-like API訪問,也可以通過Cassandra Query Language,Lindorm SQL等多種方式讀寫,大大降低了用戶的使用成本。

4.3.2 全文索引

全局二級索引很好的解決了用戶固定訪問模式的查詢需求,但對於多維組合查詢存在成本高,不夠靈活的缺點。過去很多用戶自行搭建HBase+ES/Solr的解決方案,通過搜索引擎查詢rowkey,再通過rowkey返查獲取完整數據。這套方案儘管較好的解決了查詢的問題,但依然存在數據同步複製延遲不可控(極端情況下丟數據),查詢方式複雜,DDL變更導致數據錯亂等問題。

Lindorm推出原生全文檢索能力,利用Lindorm Tunnel Service可以全自動完成DDL,數據的同步異步構建。與此同時Lindorm CQL還提供了統一查詢能力,基於用戶查詢條件在編譯時決定是否需要通過搜索進行加速,無需用戶自行判斷,大幅優化了用戶的使用體驗。

4.4 智能化服務

目前lindorm服務了經濟體以及公有云上萬的開發者,過去的一年我們也圍繞着服務自助化、運維智能化、運營數據化的目標,全新打造LDInsight工具產品服務,降低使用lindorm的門檻以及提升運維效率。LDInsight具備了信息透視、系統管理、智能診斷等功能,幫助應用開發者/DBA輕鬆掌握系統運行狀態,白屏化完成常見系統管理和數據訪問操作,以及自動診斷使用過程中的常見問題,讓用戶和維護者更加簡單、高效地使用Lindorm,減少服務對人的依賴。

4.4.1 智能診斷

爲了讓應用開發者/DBA更放心的使用lindorm,LDInsight 提供了7*24小時的數據庫異常診斷功能,自動診斷生產運維過程中的常見問題、排除潛在風險,比如慢請求、熱點、性能診斷、Schema設計、索引推薦等,讓用戶和DBA更加簡單、透明、高效地使用Lindorm。

LDInsight 會秒級收集各項關鍵指標信息作爲某個時間點的性能數據快照,我們會先結合DBA 的專家經驗將關鍵指標進行分類,接着分析出每個指標的規律性(週期性、平穩性、還是趨勢性等),最後根據指標的不同規律,應用混合模式的時序數據異常檢測模型對指標進行智能化的分析與歸納,從而增強異常發現的成功率。

目前LDInsight已在全網部署對所有開發者開放使用。

4.4.2 熱點識別與自愈

在支持海量數據在線高併發查詢的場景中,業務中天然存在着突發的熱點商品促銷、大V直播帶貨等場景,在熱點的識別設計上,我們運用Sketch-Counting算法統計高頻訪問的Key,其核心思想是拋棄低概率的key的詳細信息,僅保留高概率訪問的信息並進行Sketch樹狀擴展,層層逼近真正熱點,無需對每個輸入key採樣收集,可以極小內存與計算開銷統計出熱點,通常運行時單機單表僅佔用500B內存,運行時常態開啓實時監測熱點。同時再結合Insight控制系統,自動快速隔離熱點,避免影響全局服務。

4.5 數據鏈路生態-LTS

LTS(Lindorm Tunnel Service)是面向Lindorm業務場景特點深度定製的數據生態服務。支持簡單易用的數據交換、處理、訂閱等能力,滿足用戶的數據遷移、實時訂閱、數湖轉存、數倉迴流、單元化多活、備份恢復等需求,實現面向Lindorm的一站式數據生態服務。

在集團內部,Lindorm擁有全網前列的離在線數據同步流量。依賴LTS(Lindorm Tunnel Service)服務,每天有接近670+TB,約3.2萬億條記錄來源於其他數據源的導入Lindorm。同時每天有接近549TB數據實時導出到TT、MetaQ、ODPS等其他系統,用於實時、離線計算、數據訂閱、算法訓練、數據備份等場景。

4.5.1 數據生態總覽

下圖展示了LTS功能總覽,其生態覆蓋了關係型數據庫、消息隊列、NoSQL數據庫、數倉/數據湖、搜索引擎等等。典型場景包含了互聯網賬單、低成本歷史庫、離線系統加速、大數據畫像、數據訂閱(CDC)、數據入湖等等。

4.5.2 企業級特性

本節介紹LTS三大企業級特性:Bulkload、Streams、全球多活,打造大數據場景下基於Lindorm的數據閉環最佳實踐。

4.5.2.1 Bulkload

Lindorm Bulkload是由LTS(Lindorm Tunnel Service)提供的低成本、高可靠、高性能的企業級批量導入服務,支持將MaxCompute、Hive等數據源中的數據導入Lindorm/HBase。

Lindorm Bulkload的優勢

  • 低成本:Bulklaod模式天然比API模式節省資源,無需日誌、事務、RPC等方面的開銷。同時利用外部生成SSTable的特殊性,我們對SSTable Writer進行了優化,使其性能提升2倍以上
  • 一致性提升:我們把表切換的邏輯做到系統內部,對客戶透明,支持強一致覆蓋寫(即將上線)。對於同城多活的實例,我們支持多個Zone同時Load數據。
  • 防導入抖動:我們提供了多級限速、本地化率、緩存更新優化等多種手段減少導入時的性能波動
  • 反數據傾斜:可以自動檢測數據分佈,實時調節目標表的分區,並做到分佈式導入下的負載均衡
  • 易用性:白屏化接入
  • 可靠性:系統高可用,有完善的監控報警體系

4.5.2.2 實時數據變更通道(Streams)

Lindorm Streams提供對Lindorm數據變更的實時、保序、高併發的處理能力,同時具備水平擴展、高可用、低成本等特點。可以基於Streams實現數據訂閱、實時流處理、數據備份、異地複製等功能

Lindorm Streams的優勢

  • 實時捕獲數據變更:非保序模式下百毫秒延遲,保序模式下秒級延遲
  • 保序:支持主鍵級別的保序,同一行的變更有序處理,基於時間戳進行排序
  • 易用性:白屏化接入
  • 可靠性:系統高可用,有完善的監控報警體系

4.5.2.3 全球多活

Lindorm 全球多活的優勢

  • 多雲支持:支持IDC與公有云混布
  • 多點寫入:單元化讀寫,異步複製,支持最終一致性
  • 智能路由:客戶端根據延遲自動選擇接入點
  • 按需多活:可選擇部分表全球同步,部分表不同步
  • 易用性:白屏化接入,拓撲關係展示
  • 可靠性:系統高可用,有完善的監控報警體系



五、總結

2020年,是全面雲化的一年,核心鏈路完全雲化,業務形態從Cloud Hosting走向Cloud Native,Lindorm的多模形態也在快速發展,雙十一核心支撐的業務也從阿里經濟體內部,走向了公共雲企業級客戶。面向未來,我們將繼續往雲原生、多模型、低成本方向奔赴,重點在多模融合查詢、Serverless隔離調度、低成本海量存儲、實時Stream、智能化等技術突破,向着“讓數據存得起,看得見”的使命,全力以赴。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章