SQL、NewSQL和NoSQL融合研究與實踐
講師介紹
朱祥磊
山東移動BOSS系統架構師
- 負責業務支撐系統架構規劃和建設
- 獲國家級創新獎1項,通訊行業級科技進步獎2項,移動集團級業務服務創新獎3項
- 申請發明專利13項
近幾年,各類大資料技術迅猛發展,企業中資料處理量呈現幾十到幾百倍增長,資料型別也從傳統結構化資料,延伸到實時流資料,以及各類非結構化資料。傳統資料庫單一技術包打天下的局面無法適應複雜多變的海量資料處理,從而出現了各類NewSQL技術和NoSQL技術,出現不同技術解決不同場景應用的局面。
以某運營商大資料平臺為例,建立了基於“MPP平臺+Hadoop平臺+Kafak+Spark+Oracle”混搭架構的企業大資料中心。但隨著資料量和業務量的倍增,平臺間資料互動運算頻繁,常規跨平臺資料遷移和跨平臺資料交叉運算的工作複雜度越來越高,急需高效方案實現對各大資料平臺的統一管理。
本文通過研究SQL和NoSQL融合技術,並進行了測試,通過融合MPP之GBase資料庫,以及傳統Oracle資料庫和Hadoop、Kafaka等平臺能力,可以便捷地以統一的SQL介面打通跨平臺的資料遷移和運算功能,解決了實際應用難點和痛點,並可以進一步推廣到資料集市、歷史資料統計分析等場景,實現在不改變當前應用架構的前提下,充分利用大資料能力的目的。
首先簡單介紹各類SQL技術,具體如下:
一、傳統資料庫技術(OldSQL)
基於強事務一致性的資料庫,如Oracle、TimesTen、Sybase等,支援SQL標準,擅長於線上交易型別應用。特點是資料儲存在列與表裡、關係通過資料表來表示、DML\DDL\DCL語言、事務、物理層的抽象。
適合處理熱資料,適用於小資料量、業務邏輯複雜、併發度高的事務型業務場景,如BOSS系統各個資料庫。
二、分散式資料庫(NewSQL)
本質上仍然屬於關係型資料庫,但是引入了分散式並行處理架構,支援SQL標準,如MPP(大規模並行處理)資料庫,常見的如GBase、Greenplum等。
適合處理溫資料,新型MPP資料庫適合處理大規模的複雜分析,例如我們的經分核心資料倉庫系統。
三、分散式key-value資料庫(NoSQL)
基於鍵值對的,而不是基於關係,適合查詢需要快速返回答案場景,適合場景的特點是大量查詢、極少修改、非同步插入資料與更新資料、無模式、不需要強一致性事務,一般為開源,不支援SQL。
NoSQL細分為4類:列儲存資料庫(如Cassandra)、文件儲存資料庫(如MongoDB)、鍵值儲存資料庫(如Redis)、圖形資料庫(如GraphSQL)。
Hadoop適合任意結構化資料處理以及大規模批量複雜作業,鍵值儲存資料庫則適合快取場景。
OldSQL和NewSQL都是基於SQL標準的,傳統的SQL語法已經很強大,很多人已經習慣通過SQL獲取自己需要的資料。但是NoSQL產品一般不支援SQL,這就造成了一定的知識碎片,傳統技術人員需要再去掌握另一種NoSQL技術,帶來很多的不便,同時NoSQL解決的問題是傳統OldSQL和NewSQL無法解決的,如下:
- 非結構化資料處理(傳統資料庫僅支援結構化和半結構化資料)
- 海量歷史資料的處理和查詢(傳統資料庫難以進行海量資料儲存)
- 流資料處理
- 深度迭代,機器學習
- 圖演算法引擎
- R語言非結構資料演算法分析
這就帶來一個問題,是否可以實現採用傳統的SQL和NoSQL結合,進行融合,即利用SQL的強大語法,同時利用NoSQL上述優點呢?
一個場景例子,在現有的Oracle資料庫上儲存最近期的資料,需要深度挖掘和歷史查詢,則自動轉到Hadoop進行處理,這樣充分利用了SQL和NoSQL的優點,避免了資料同步,大幅降低學習掌握NoSQL的難度。
SQL和NoSQL融合主要由如下幾種演進路徑:
- 一類是開源產品,如Apache Impala、Phoenix、Spark-SQL等。
- 一類是商業產品,如IBM的Big SQL、Pivotal的HAWQ等。
上述屬於SQL on Hadoop,即在Hadoop上研發實現支援SQL機制,實現融合。
為了實現傳統資料庫和NoSQL的深度融合,一些資料庫公司正在開發或已退出SQL and Hadoop產品,如Oracle公司的Big Data SQL等,可在Oracle中實現對Hadoop資料的直接查詢。國產南大通用資料庫GBase則推出了GBase UP產品,使後端SQL 和NoSQL上層封裝為一個整體呈獻給使用者使用。
不同的產品以成熟的資料庫為基礎,擴展出針對Hive&Spark、HBase等元件的計算和儲存引擎,建立引擎之間高效資料交換通道,構建了對外統一,對內可擴充套件的叢集資料庫產品。
對比上述SQL on Hadoop和SQL and Hadoop產品,後者在利舊現網資料庫,以及在處理複雜多變的業務場景下優勢明顯,實現幾乎不改變現有技術架構的前提下實現對大資料技術的充分利用。
為充分驗證SQL and Hadoop技術,我們近期進行了測試,一是現有交易資料庫Oracle和Hadoop的融合,一是資料倉庫型別GBase和Hadoop的融合,取得較好的效果:
1.Oracle和Hadoop的融合
Oracle公司推出Oracle Big Data SQL來實現本功能,主要思路是Oracle標準SQL通過實現跨Oracle資料庫、Hadoop和NoSQL資料儲存提供統一查詢。
該產品需要Oracle資料庫12c作為支援,資料庫版本要求12.1.0.2以上;支援的Hadoop版本包括CDH 5.5以上或HDP 2.3以上。
Big Data SQL的主要理念是“SQL應該直接在資料所儲存的地方”進行操作,即最大限度利用各類資料存放的位置平臺的優勢,同時利用統一的元資料用來實現如何執行統一跨平臺查詢,充分利用原有儲存資料的技術平臺的特性來優化查詢執行效率,對於關係型資料庫的技術平臺,其優點包括:能立即查詢處理,變化資料日誌記錄,細粒度的安全訪問控制等等。對於Hadoop的技術平臺,其優勢在於可擴充套件性和schema-on-read。
Big Data SQL資料流
1)從HDFS DataNone上讀取資料
- 直接路徑讀
- 基於C開發的讀取引擎(目前支援分割文字和JSON)
- 其它使用Hadoop原生類來訪問
2)轉換成Oracle資料格式
3)基於Oracle格式資料做Smart Scan
- WHERE子句條件過濾
- 列投影
- 應用布隆篩選器以提高聯接效能
- JSON/XML解析,資料探勘模型評分
統一元資料
Oracle Big Data SQL通過Oracle資料庫的資料字典技術,通過Oracle外部表技術的擴充套件,將在Hadoop或者NoSQL資料庫中的表定義成Oracle的外部表。在通過外部表技術進行設計的同時,還充分儲存和利用了Hadoop的特性。
CREATE TABLE movieapp_log_json
(click VARCHAR2(4000))
ORGANIZATION EXTERNAL
(TYPE ORACLE_HIVE
DEFAULT DIRECTORY DEFAULT_DIR )
ACCESS PARAMETERS
(
com.oracle.bigdata.tablename logs
com.oracle.bigdata.cluster mycluster))
PARALLEL 20
REJECT LIMIT UNLIMITED;
Oracle資料庫12.1.0.2支援兩個新型別的外部表,也就是兩種新的訪問驅動:ORACLE_HIVE和ORACLE_HDFS。ORACLE_HIVE是在Apache Hive資料來源上建立Oracle外部表。ORACLE_HIVE也可以訪問儲存在其他位置如HBase的資料。ORACLE_HDFS是在HDFS檔案上直接建立Oracle外部表。ORACLE_HIVE訪問驅動從Hive中繼承元資料, ORACLE_HDFS訪問驅動需要手工指定資料訪問方式。
效能優化
Oracle Big Data SQL效能優化的核心是充分利用並行,讓儘可能多的資料處理工作在Hadoop端完成,從而減少資料的流動。
上面是Big Data SQL針對Hadoop智慧掃描的技術,通過這個技術讓資料能在其存放的Hadoop層就完成儘可能多的資料處理。Oracle Big Data SQL給Hadoop生態系統引入了一個新的服務,這個服務和HDFS的DataNodes,YARN NodeManagers協同工作。外部表的查詢的請求能直接傳送到這些服務,進行直接路徑的資料本地讀取。通過智慧掃描加速I/O最大限度地減少資料移動。
儲存索引
Big Data SQl還通過減少HDFS IO的掃描提升查詢效能。通過外部表Mapping HDFS上的資料,儲存索引記錄每個HDFS block的最大、最小值。
資料安全
Big Data SQL支援跨Oracle,Hadoop和NoSQL資料來源的一個統一的資料字典,將Hive和NoSQL資料呈現為Oracle的常規表,允許DBA來建立關係型資料的安全性,制定行級過濾策略等。
下面是測試的幾個場景例子:
場景1:聯合查詢:A表(10億行,在Hive中)和B表(7.6千萬,在Hive中),指定某一個手機號。
場景2:聯合查詢:A表(10億行,在Hive中)和B表 (7.6千萬,在Hive中)指定b_avg_arpu欄位排序,並取Top10。
場景3:聯合查詢:A表(10億行,在Hive中)和B表(17行,在Oracle中)根據應用型別和城市分組,取記錄數Top20。
場景4:聯合查詢:A表(7.6千萬行,在Hive中)和B表(18行,在Oracle中),C表(315行,在Oracle中),根據城市分組,取4G流量最高的Top20。
場景5:聯合查詢:A表(10億行,在Hive中)和B表(7.6千萬,在Oracle中),指定vie_game_flow欄位排序,並取Top10。
測試結果如下:
2.MPP之GBase和Hadoop的融合
GBase UP,它是融合了GBase 8a MPP、GBase 8t、開源Hadoop生態系統等大資料平臺產品,兼顧了大規模分散式並行資料庫集群系統、穩定高效的事務資料庫,以及Hadoop生態系統的多種大規模結構化與非結構化資料處理技術,能夠適應OLAP、OLTP和NoSQL三種計算模型的業務場景。
通過構建完整的Schema定義和資料庫訪問控制,能夠對使用者資料庫訪問進行解析、優化、資料緩衝等操作,完成透明高效的中間資料儲存、關聯、聚合等操作,對內構建GBase 8a MPP、Hadoop或者其它資料庫之間的內部資料傳輸協議,實現高效的資料交換,構建統一的監視和控制系統,進行資源排程。提供了經典的資料庫接入方式和結構化查詢語言,從而大大降低維護和開發成本。
其核心技術架構如下圖:
其實質是在各個資料引擎(Oracle、GBase、Hadoop等)之上建立Mega SQL Engine (資料聯邦),實現統一介面、統一查詢語言、統一元資料以及統一的使用者管理和許可權控制,並構建了跨引擎的優化器和關聯查詢。整個架構中,GBase UP負責連線接入、元資料管理、跨叢集查詢排程、安全認證、日誌記錄等一系列分散式資料庫的功能;GBase 8a叢集(集合)負責高質量高密度高效能的資料儲存和計算;GBase 8t(Oracle)負責支撐高階事務處理;Hive叢集負責驅動Hadoop或Spark叢集實現對低密度、低質量、結構化/非結構化的大資料進行分析;Hadoop叢集的HDFS負責高效高可用的儲存海量資料,HBase負責儲存海量中小檔案,以及作為分散式可擴充套件的KV型資料倉庫。目前已經支援SQL92標準、HiveQL、GBase 8t 、HBase等,目前已融合Oracle部分功能。
測試環境:
測試功能點包括:統一介面資料載入,跨引擎資料交換(簡單),跨引擎關聯查詢,跨引擎資料交換(複雜),水平分割槽表,資料備份恢復,Kafka對接UP測試,Hive on Spark模式用例測試。
測試軟體版本:
場景1:統一資料介面資料載入
場景一是從ftp方式遠端載入到UP資料庫,二是從Hadoop HDFS載入到UP。
資料量:1157542760行
檔案大小:593G
表名稱:
cdr_gbase_t01_fromftp
cdr_gbase_t01_fromhdfs
語句:
執行結果:
SQL執行 | 耗時 |
FTP載入到8a(UP) | Elapsed: 00:10:54.20 |
HDFS載入到8a(UP) | Elapsed: 00:06:55.24 |
場景2:跨引擎關聯(MPP和Hive)
測試MPP與Hive 在不同計算機制(MR/Spark)下join關聯查詢並分別插入MPP和Hive的功能。
表名:cdr_hive_t01 資料量:1157542760行
表名:dw_brand_status 資料量:98291109行
語句:
執行結果:
場景3:Kafka對接UP測試
驗證Kafka訊息載入到UP功能支援情況。
表名:cdr_gprs_dm_kafka 資料量:10000000行
訊息大小:5.3GB 單行訊息長度:560B
語句:
執行結果:
SQL執行 | 耗時 |
FTP載入到8a(UP) | Elapsed: 00:10:54.20 |
HDFS載入到8a(UP) | Elapsed: 00:06:55.24 |
場景4:水平分割槽表
驗證UP產品對資料生命週期管理機制。
測試過程:
- 建立水平分割槽表,8a為熱分割槽,Hive為冷分割槽;
- 建立自動資料遷移任務,每天將前一天的資料自動遷移至Hive分割槽;
- 將資料匯入至熱分割槽,驗證熱分割槽和整個水平分割槽表的資料正確性;
- 等待一天,觀察資料是否已經自動遷移至冷分割槽,並驗證冷分割槽和整個水平分割槽表的資料正確性;
- 嘗試向冷分割槽插入資料,應報錯(只有熱分割槽可以更新資料,冷分割槽只供讀取)。
語句:
執行結果:GBase UP按照設定的資料遷移策略後臺自動透明的完成高效遷移。
以上為本階段針對UP產品的測試說明,後續將逐步測試融合HBase、Oracle產品的能力,本文就不做過多贅述。
經過上述測試,初步驗證了SQL和NoSQL融合技術的可行性,後續將推廣使用,尤其歷史資料存放和查詢等場景,可實現Hadoop的歷史資料直接查詢,大大方便了資料生命週期管理。
文章來自微信公眾號:DBAplus社群