最佳實踐:騰訊HTAP資料庫TBase助力某省核心IT架構升級
資料儲存和處理是一個古老而重要的技術,從遠古時期的結繩記事到古人的文字記事,再到計算機誕生後的各種系統,直到E.F.Codd提出關係模型,人類終於有了一種相對高效而統一的資料處理系統——關聯式資料庫。
在傳統的關係資料處理系統中,習慣把系統按照業務特點分為線上事務處理系統(OLTP)和線上分析處理(OLAP),一般意義上OLTP關注實時線上業務,要求低延時,高吞吐量,總體資料量一般不會特別大;而OLAP系統用來處理大規模資料的報表分析,要求低響應時間。兩者因為資料量,查詢請求,業務要求的不用,加上之前技術條件的限制,就分解為兩個獨立的系統,即OLTP系統用來處理線上交易,OLAP系統用來進行報表處理,兩者之間透過ETL工具連線。
一般這個兩套資料庫系統是相互獨立的產品,常見的OLTP產品有IBM DB2,Informix, ORACLE,SQL SERVER,mysql,PostgreSQL等,在OLAP常見的如TeraData,SybaseIQ,GreenPlum,HP VERTICA, SAP HANA,Hadoop大資料平臺等等。在這個架構中,有兩套獨立的資料系統需要維護,增加系統採購的成本和系統運維的成本;同時ETL過程中OLTP到OLAP系統的資料一致性也是一個讓人頭疼的問題。
TBase向我們展示了一種革命性的資料處理架構,把OLTP和OLAP處理進行融合,在一套資料庫系統中同時完成兩種操作,同時降低業務複雜度和業務成本。TBase在某省部門上線執行超過快四年,在客戶的架構升級中扮演了重要的角色,當前在該客戶有快10套TBase系統在執行,叢集規模快接近百臺。本文希望藉助客戶的實際案例來對TBase的架構進行下解析,增加大家對TBase的瞭解。
TBase架構特點:
TBase分散式無共享(share nothing)分散式資料庫,叢集結構如下:
Coordinator: 協調節點(簡稱CN),對外提供介面,負責資料的分發和查詢規劃,多個節點位置對等,每個節點都提供相同的資料庫檢視;在功能上CN上只儲存系統的全域性後設資料,並不儲存實際的業務資料。
Datanode: 處理儲存本節點相關的後設資料,每個節點還儲存業務資料的分片,簡稱DN。在功能上,DN節點負責完成執行協調節點分發的執行請求。
GTM: 全域性事務管理器(Global transaction manager.),負責管理叢集事務資訊,同時管理叢集的全域性物件,比如序列等。
在這個架構下,TBase叢集具有下面幾個能力:
多活/多主: 每個coordinator提供相同的叢集檢視,可以從任何一個CN進行寫入,業務無需感知叢集拓撲;
讀/寫擴充套件:資料被分片儲存在了不同的DN,叢集的讀/寫能力,隨著叢集規模的擴大做而得到提升;
叢集寫一致: 業務在一個CN節點發生的寫事務會一致性的呈現在其他的CN節點,就像這些事務是本CN節點發生的一樣;
叢集結構透明: 資料位於不同的資料庫節點中,當查詢資料時,不必關心資料位於具體的節點;
TBase的share nothing叢集架構方便了業務接入,降低了業務接入的門檻。
TBase 的HTAP能力:
HTAP是混合事務和分析處理
Hybrid Transactional/Analytical Processing的簡寫,TBase透過下面這些技術構建了原生的HTAP能力。
事務ACID強保證:
在分散式資料庫中,分散式事務的ACID保證是一個很有挑戰性的工作,但是業務系統在使用資料庫的過程中,往往會依賴資料庫提供的ACID能力來開發他們的業務,因此事務ACID能力的保證也成了分散式資料庫必不可少的能力。先把資料庫理論中的ACID的定義拿出來,熟悉下這些概念:
ACID,指資料庫事務正確執行的四個基本要素的縮寫。包含:原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、永續性(Durability)。一個支援事務(Transaction)的資料庫,必須要具有這四種特性,否則在事務過程(Transaction processing)當中無法保證資料的正確性,交易過程極可能達不到交易方的要求。
詳細解釋下:
原子性(Atomicity): 整個事務中的所有操作,要麼全部完成,要麼全部不完成,不可能停滯在中間某個環節。事務在執行過程中發生錯誤,會被回滾(Rollback)到事務開始前的狀態,就像這個事務從來沒有執行過一樣。
一致性(Consistency): 事務必須始終保持系統處於一致的狀態,不管在任何給定的時間併發事務有多少。
也就是說:如果事務是併發多個,系統也必須如同序列事務一樣操作。其主要特徵是保護性和不變性(Preserving an Invariant),以轉賬案例為例,假設有五個賬戶,每個賬戶餘額是100元,那麼五個賬戶總額是500元,如果在這個5個賬戶之間同時發生多個轉賬,無論併發多少個,比如在A與B賬戶之間轉賬5元,在C與D賬戶之間轉賬10元,在B與E之間轉賬15元,五個賬戶總額也應該還是500元,這就是保護性和不變性。
一致性是分散式事務中的重大挑戰,網路時延和作業系統排程等不確定因素給分散式 事務一致性的保證帶來諸多困難,但是分散式資料必須有一套完整的分散式事務一致性邏輯,否則會帶來災難性的後果。
隔離性(Isolation): 隔離狀態執行事務,使它們好像是系統在給定時間內執行的唯一操作。如果有兩個事務,執行在相同的時間內,執行相同的功能,事務的隔離性將確保每一事務在系統中認為只有該事務在使用系統。這種屬性有時稱為序列化,為了防止事務操作間的混淆,必須序列化或序列化請求,使得在同一時間僅有一個請求用於同一資料。
永續性(Durability): 在事務完成以後,該事務對資料庫所作的更改便持久的儲存在資料庫之中,並不會被回滾。
TBase中的事務嚴格遵守事務的ACID,當前支援read committed和repeatable read兩個隔離級別,並提供可擴充套件的事務吞吐能力。
在事務測試模型TPC-C中有9張表,用來模擬從倉庫中下訂單發貨,庫存狀態查詢,並有一定的回滾比例,每個事務中有5-6條SQL,讀寫混合,測試過程中要求嚴格遵守ACID。在這個模型下TBase的處理能力隨著叢集規模的提升近似線性提升,在30臺(24core,64G,1000Mb)規模時可以達到300W tpm。
Share nothing架構決定了隨著叢集規模的增加系統的TPC-C處理能力會進一步的提升,TBase在事務處理中處理能力可以到千萬級QPS。
完整SQL相容性:
SQL是訪問資料庫的必備工具,在SQL誕生了幾十年後的今天,大量的軟體產品使用SQL進行開發,每個程式設計師都或多或少的使用到SQL,資料庫對SQL的處理能力直接關係軟體產品的穩定和程式開發的效率。
TBase認為:完整SQL相容性 = 完美的SQL語法相容+代價最佳化器+分散式執行器。因此TBase在設計之初就定下一條設計規則:SQL語法完全相容SQL2003標準,讓使用者像使用普通資料庫一樣來使用TBase。
因此在TBase中,資料庫開發工程師可以像在之前熟悉的資料庫產品中一樣編寫SQL,不用擔心資料庫產品的變化帶來額外的學習工作量。為業務節省大量的開發工作,降低業務升級的成本。
除了SQL語法相容性,為了達到高效的分散式執行,TBase有專門為分散式環境設計的基於代價的查詢最佳化器,與之配合的是專門為分散式環境設計的分散式執行器。
分散式執行器提供了目前已知的所有資料庫運算元(operator)支援,包括聚合,視窗函式,cube,儲存過程,自定義函式,觸發器,物化檢視,並行執行等等。
透過這些設計,TBase為業務提供良好了的資料庫使用體驗,大幅降低業務的遷移成本和開發人員的學習成本,提高業務遷移的效率。
SQL相容性和效能我們透過TPC-H來測試。TPC-H標準滿足了資料倉儲領域的測試需求。TPC-H中 用 3NF 實現了一個資料倉儲,共包含 8 個基本表, 22 個查詢(Q1~Q22),其主要評價指標是各個查詢的響應時間,即從提交查詢到結果返回所需時間(越短越好)。其中的查詢主要涉及:多表關聯(超過4張),多表聚合,子查詢等。
下圖是TBase在行儲存模式下TPC-H測試結果和國際知名資料庫倉庫的測試結果對比,從測試結果來看,TBase在所有22個測試用例中都大幅度的領先。
在資料庫語法中,除了SQL標準外,每個資料庫都產品有自己的本地化語義,在本地化語義方面, TBase完整的的相容PostgreSQL語法,部分相容Oracle語法。
完整列儲存能力
資料庫的物理檔案儲存格式常見的有兩種:按行儲存和按列儲存。下面對每種儲存結構給出一個例子,下表是我們的表結構和定義。
按行儲存格式
按行儲存格式,資料按照邏輯順序相同的方式來來進行檔案儲存,一行中的所有列資料按照順序儲存在物理磁碟上,這種格式的好處很明顯,如果同時訪問一行中的多列資料時,一般只需要一次磁碟IO,比較適合OLTP型別的負載。
按列儲存格式
表中的每列資料儲存為一個獨立的磁碟檔案,比如例子中,“姓名”,“部門”,“薪酬”,“家庭資訊”每列中的資料都為一個獨立的資料檔案,這中格式在一次需要訪問表中少數列時相比行存能夠節省大量的磁碟IO,在聚合類場景下尤其高效,因此多用在OLAP類系統中。
行儲存是TBase的基本儲存格式,為了支援高效的OLAP TBase也提供了完整的列儲存能力,業務可以根據自己的需要對寫入資料庫中的資料選擇需要的儲存格式。TBase的列儲存還支援強大的壓縮能力,支援透明壓縮和輕量級壓縮,透明壓縮支援gzip,zstd等壓縮演算法,輕量級壓縮演算法可以根據資料的特徵進行高效壓縮,壓縮比高達400+。
TPC-DS是一套決策支援系統測試基準,主要針對零售行業。提供了99個SQL查詢(SQL 2003),分析資料量大,測試資料與實際商業資料高度相似,同時具有各種業務模型(分析報告型,資料探勘型等等),主要用來對決策支援系統進行效能效能評測。TBase列儲存的 TPC-DS上執行了1T的工作集合,測試結果如下:
從測試結果來看,TBase在列儲存模式下的TPC-DS能力要遠遠優於業界標杆。
PS:TBase中行表和列表之間可以進行任意關聯查詢,可以進行相互的格式轉換(透過insert into select)。
資源隔離能力:
在HTAP系統中,OLTP和OLAP業務要同時執行,兩者都會消耗巨量的資源都,如果不對資源使用進行隔離必然會造成相互之間的干擾,影像系統的整體穩定性和服務質量。
TBase中的資源隔離方案--節點組的資源隔離方案, 如果業務的OLTP和OLAP訪問的是不同的資料,可以使用TBase中的節點組把OLTP業務和OLAP業務在叢集中分離為兩個節點組,對與OLTP節點組中的CN設定OLTP最佳化器,對於與OLAP節點組中的CN設定OLAP最佳化,從硬體上進行嚴格的分離。
在TBase中每個使用者session都有一個資源配額限制,使用這個配額可以限制使用者session的CPU,記憶體,網路等資源,在OLTP和OLAP不存在絕對競爭的場景也可以讓兩者執行在同一個group,使用使用者資源配置來資源進行管控和配置。
TBase資源隔離方式—多副本方式(專利技術),多平面技術 ,此時使用者資料還是同一份資料,透過副本複製的方式把資料從OLTP系統複製到OLAP系統,同時實現行儲存到列儲存的轉換,透過這種方式從硬體上分離了OLTP和OLAP業務,同時資料庫內部的資料複製可靠性由資料庫內部機制保證,可靠性遠遠高於ETL工具。 這種資源隔離技術TBase中的叫多平面技術。
透過上面這些資源隔離技術,TBase實現了HTAP中關鍵的資源隔離技術,可以很好的保證系統的服務質量和改善客戶體驗。
TBase安全解決方案:
得益於TBase常年服務公司內部客戶, TBase建設了一套很有特色的資料安全系統,可以說 TBase是目前市面上安全能力最出色的資料庫產品,這一特性得到內外部客戶的一致認可,並作為安全技術標準寫入到PICC的資料庫安全規範中。
TBase的資料安全系統我們稱之為MLS(multiple level security),這個體系的整體檢視如下:
以三權分立為基礎,消除系統的超級使用者許可權。在安全管理規則中增加強制安全規則,支援對錶進行矩陣式的許可權劃分,在資料訪問層和儲存層進行加密和脫敏控制,防止資料拖庫時發生的資料洩密:
在事後追溯和實時審計中,TBase提供了完整的審計規則和豐富的自定義審計規則來進行支援。 透過FGA(細粒度審計),TBase還可以做到資料越權訪問的實時告警,實時防止資料越權訪問。
客戶案例場景:
案例1:TBase協助解決某省彙集庫瓶頸,助力客戶架構升級:
原有系統使用某知名資料庫叢集。在支撐資料量到300億資料時,計算和查詢的時候能力已經到達極限,超時當機的場景頻發,入庫的速率最後只能達到數千/秒的極限值,遠遠無法滿足業務需要。
TBase彙集庫在系統中的位置:
彙集庫在系統中承擔著資料彙集處理的作用,既要對接其他關聯式資料庫,訊息中介軟體等,還要執行部分核心系統的OLTP業務,並在這兩者資料的基礎上執行模型構建,離線行為分析等OLAP類計算。是一個典型的HTAP系統。
之前的系統之所以遇到瓶頸,很大程度上也是因為業務模型本身計算量大,模型複雜超出了RAC的處理效率。
TBase團隊在分析了業務的特點後,結合TBase的本身能力為業務制訂詳細的解決方案。方案的核心要點是OLTP和OLAP的 多平面資源隔離技術 ,我們為系統的請求詳細的劃分了業務的執行平面,業務的寫入全都集中在主平面,把查詢類的請求根據計算複雜度和實時要求劃分到備用平面和主平面。很好的隔離了實時請求和離線請求。彙集庫TBase CN和DN的部署結構如下圖。
彙集叢集當前有節點數近百,儲存資料數百T。120億資料的OLTP類業務1秒內完成處理。處理效能 遠遠超越了之前系統,成本相比卻大幅降低 ,得到使用者的高度認可!
案例二:物聯網地理資訊系統:
業務背景:隨著物聯網的到來,很多的感測器資料需要進行接入,這些資料中都包含共同點,都包含一些點位資訊(經度和緯度)。結合這些位置資訊和我們已有的地理資訊進行關聯分析,可以分析出很有價值的資料,為國民生產生活所用。
這個系統的核心功能是要對地理位置資訊進行關聯計算和查詢,這個需要TBase提供的地理資訊能力進行支援。
PS:TBase支援最先進的開源地理資訊引擎PostGIS,可以提供豐富高效的地理資訊處理能力。
該業務系統的部署架構如下:
TBase上游對接接業務感測器後端的ETL,資料進入叢集后先對清洗變換,並把人和位置資訊進行關聯形成寬表;在寬表的基礎上進行GIS OLAP分析,輸出我們需要的高價值資訊。
目前GIS系統規模:目前5臺機器協調節點+6臺機器Datanode節點主備混合部署。
案例三,某核心OLTP線上核查系統:
某省核心服務微信公眾號後臺系統,核心系統結構如下:
業務的核心TBase伺服器部署內網,敏感資料部署在這個核心TBase例項中,網際網路部署的一臺應用伺服器,執行公眾號相關的業務資料,並透過網路邊界同步工具把資料同步到業務內網。
總結
TBase構建HTAP能力的過程中團隊小夥伴們突破了一個又一個技術難點,創造了一個又一個“不可能”,回顧這個過程,就想起一句古語“篳路藍縷,以啟山林”!對TBase來說,應該是“篳路藍縷,開拓創新”!
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69903766/viewspace-2637242/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 國產開源資料庫:騰訊雲TBase在分散式HTAP領域的探索與實踐資料庫分散式
- 守護客戶資料價值:企業級NewSQL HTAP分散式雲TBase架構詳解SQL分散式架構
- Android 中的升級資料庫最佳方法實踐Android資料庫
- 沈劍:58同城資料庫架構最佳實踐資料庫架構
- android資料庫如何進行版本升級?架構之資料庫框架升級Android資料庫架構框架
- 企業級雲資料庫最佳實踐資料庫
- 騰訊音樂內容庫資料平臺架構演進實踐架構
- MySQL 升級的最佳實踐MySql
- 汽車之家Unity前端通用架構升級實踐Unity前端架構
- 鬥魚資料庫混合雲架構實踐資料庫架構
- 亞信安慧AntDB資料庫高可用解決方案助力西南某省高速清分結算系統成功升級資料庫
- B站萬億級資料庫選型與架構設計實踐資料庫架構
- 最佳實踐 | 原始碼升級gcc原始碼GC
- 騰訊雲原生資料庫TDSQL-C架構探索和實踐資料庫SQL架構
- TiDB 異構資料庫複製最佳實踐TiDB資料庫
- 騰訊雲資料庫伍鑫:MPP資料庫HTAP技術探索資料庫
- 微服務架構最佳實踐微服務架構
- 如何理解騰訊雲資料庫戰略升級?資料庫
- rac 升級crs 升級資料庫軟體,升級資料庫資料庫
- PHP最佳實踐之資料庫PHP資料庫
- HTAP資料庫(OLTP+OLAP)-資料庫典型架構優缺點剖析(shardVSshared)資料庫架構
- 快狗叫車CTO沈劍:資料庫架構一致性最佳實踐資料庫架構
- Android升級資料庫的最佳寫法Android資料庫
- Redis 高可用架構最佳實踐Redis架構
- MSSQL·最佳實踐·例項級別資料庫上雲RDSSQLServerSQL資料庫Server
- 朱曜鑫:阿里巴巴第四代資料庫架構最佳實踐阿里資料庫架構
- 資料庫升級資料庫
- ♀♀資料庫升級♀♀資料庫
- 資料庫安全最佳實踐:基本指南資料庫
- 資料庫優化的最佳實踐資料庫優化
- 從 ClickHouse 到 Apache Doris,騰訊音樂內容庫資料平臺架構演進實踐Apache架構
- 阿里雲Polardb國產資料庫補丁升級 實踐阿里資料庫
- 微服務架構十條最佳實踐微服務架構
- 資訊架構升級在DataSimba的實踐 | StartDT Tech Lab 02架構
- PB級資料實時查詢,滴滴Elasticsearch多叢集架構實踐Elasticsearch架構
- 動手為王 | Oracle 資料庫跨版本升級遷移實踐Oracle資料庫
- CNCC技術論壇|分散式資料庫HTAP的探索與實踐分散式資料庫
- 金融業分散式資料庫選型及HTAP場景實踐分散式資料庫