??多源數據技術體系下數據即席查詢的探索與實踐 - 網安 - 專業的網絡安全產業、社區、知識平臺

近年來，隨著大數據技術產品的不斷發展和多樣化，各個應用系統也會依據不同的業務場景選擇多個不同的技術組件，數據也隨之散落在各個存儲平臺之中。這種狀況給后續數據分析師在不同數據源之上進行數據的即席關聯查詢和分析帶來了新的難題，本文介紹了在數據不移動的前提下進行多源數據即席訪問的具體探索與實踐。

數據即席查詢的現狀及問題

中國光大銀行傳統數據倉庫體系經過十幾年的發展建設，在技術平臺上也經歷了多次迭代升級，現階段形成了以GuassDB為主的分布式關系型數據庫系統。近年來隨著Hadoop生態體系大數據技術的成熟穩定，光大銀行針對不同的業務場景使用多種新興技術搭建了多套不同功能用途的技術平臺。

從以前單一的傳統數據倉庫發展到多種數據倉庫技術并行后，各類數據勢必散落在各個不同的技術平臺系統當中。數據分析師想要分析不同數據源的數據時，傳統思路是先要將數據搬挪到某一個數據倉庫平臺中，然后再進行相關業務數據的查詢與分析。數據搬挪時的ETL過程任務繁重、費時、費用昂貴，且不能夠滿足數據分析師對日常業務需求的即時查詢服務。

為解決多數據源即席查詢的問題，光大銀行進行了相關技術產品的探索和實踐，基于openLooKeng開源技術實現了行內跨源數據的即時查詢和分析。

通過連接器的架構來適配

不同的數據源

光大銀行針對即席查詢的使用場景對市場中的開源產品進行了對比選擇，最終選擇了基于Presto計算引擎開源的技術產品openLooKeng。它是一個開源的分布式SQL查詢引擎，類似于MPP數據庫，用于支持數據探索、即席查詢和批處理，而無需移動數據。引擎可以運行簡單查詢、復雜查詢、聚合、連接和窗口函數，并支持跨源查詢。在整體技術架構層面，它是由一個協調節點和多個工作節點組成的物理集群，對外提供的是SQL查詢服務。

該查詢引擎通過基于連接器的架構實現了存儲與計算分離，每個連接器將數據源中的數據抽象成一個個的數據表。數據源只要能夠表示為表、列和行，就可以創建連接器讓查詢引擎使用這些數據進行查詢處理，目前支持的連接器不僅包括Hive、GaussDB、MySQL關系型數據庫，還支持連接非關系型的存儲數據源，例如分布式消息隊列Kafka、列式存儲數據庫HBase、全文檢索引擎Elasticsearch。對于同一個數據源中的不同數據庫的訪問，還可以通過配置不同的連接器實例來滿足用戶對于多實例的支持。

圖1 openLooKeng集群整體架構

在服務器端程序啟動時，以插件方式加載在Catalog目錄下配置好的各個連接器實例。在生產環境中針對大數據平臺各個物理集群下的Hive數據庫分別配置連接器實例，對GaussDB數據庫中的數據倉庫和各種不同集市數據庫創建不同的連接器實例。終端用戶通過SQL客戶端工具在進行數據查詢時通過完全限定名（catalog-name.schema-name.table-name）來屏蔽數據源的差異性，對不同數據源的表關聯、過濾、聚合等操作。例如，針對Hive數據庫和GaussDB數據庫的跨源關聯查詢可以使用如下語句進行：

select a.cust_id,a.cust_name,b.account_num

from gaussdb.test_db.customer a, hive.test_db.account b

where a.cust_id = b.cust_id

and a.cust_id = 12345;

針對不同Hive數據庫租戶

的實現機制

光大銀行Hadoop物理集群是以平臺的方式進行搭建，用于數據即席查詢的有批量主集群和數據科學實驗室集群，在每個集群之上啟用了基于Kerberos管理的用戶認證方式，針對使用平臺的不同應用系統會創建獨立的應用租戶，每個租戶有自己獨立管理和使用的Hive數據庫，在管理和查詢的權限上和其他系統租戶相互隔離。

在Hive連接器的catalog配置中，如果分別對Hive技術組件下不同租戶的數據庫進行配置，需要創建不同的catalog文件，并且每個租戶需要提供底層Hadoop平臺上的Kerberos的keytab秘鑰文件，使用這種配置方式在管理上較為繁雜，并且容易出錯。另外一種較為方便也是光大銀行所使用的配置方式是針對每個Hive數據庫集群只配置一個Hive連接器實例，對底層Hadoop平臺配置的用戶使用的是超級用戶和對應的keytab文件，然后超級用戶使用代理模擬的方式來對Hive數據庫的元數據和HDFS的數據文件進行相關讀取和查詢操作。

圖2 Hive連接器的訪問機制

在具體的Hive連接器配置方面，需要配置以下相關參數：

connector.name=hive-hadoop2

hive.metastore.uri=thrift://hive-metastore:9083

hive.metastore.authentication.type=KERBEROS

hive.metastore.thrift.impersonation.enabled=true

hive.metastore.service.principal=hive/_HOST@CEBBANK.COM

hive.metastore.client.principal=hive@CEBBANK.COM

hive.metastore.client.keytab=hive.keytab

hive.metastore.krb5.conf.path=krb5.conf

hive.hdfs.authentication.type=KERBEROS

hive.hdfs.impersonation.enabled=true

hive.hdfs.presto.principal=hive@CEBBANK.COM

hive.hdfs.presto.keytab=hive.keytab

hive.config.resources=core-site.xml,hdfs-site.xml

當底層Hadoop集群使用Kerberos進行身份認證時，在openLooKeng中Hive連接器的Thrift服務和HDFS身份驗證服務，都需要配置為使用Kerberos方式進行驗證，此外還需要提供對應的Principal用戶名和Keytab秘鑰文件。對于這兩個配置，光大銀行使用了Hadoop平臺中的超級用戶和其對應的Keytab文件。在通過啟用元數據和HDFS的Impersonation后，即開始了代理模擬的功能，用戶對Hive數據庫發起查詢執行SQL語句時的用戶名會作為該超級用戶所要代理模擬的用戶，具體對于數據庫中表的訪問是否具有權限也完全依賴于這個用戶名對應的用戶在底層Hadoop集群中是否有讀寫權限，在系統安全上并不會因為Catalog中配置了超級用戶而導致用戶查詢時的越權訪問。

對GaussDB數據庫的

JDBC訪問機制

在傳統數據倉庫方面，光大銀行使用的是GaussDB數據庫，它是基于MPP架構，為超大規模的數據管理提供通用的計算平臺。在整個物理集群方面，是由管理節點、控制節點和數據節點組成。終端用戶在發起SQL查詢時，請求會統一發送到Coordinator節點，接收到用戶的請求后會分配服務進程，請求全局事務，根據數據的分布信息及系統元數據將具體任務發送到Datanode進行處理，處理完成后的結果也會統一返回到Coordinator節點，再將結果返回給終端查詢用戶。

圖3 GaussDB連接器訪問機制

在openLooKeng連接GaussDB時，使用的是傳統關系型數據庫的JDBC方式進行連接，具體的Catalog實例參數配置信息如下：

connector.name=opengauss

connection-url=jdbc:postgresql://192.168.1.101:38910/hetu

connection-user=hetu

connection-password=test

在進行底層數據讀取操作時，終端查詢用戶所擁有的權限是依賴于該Catalog配置中的連接用戶在GaussDB數據庫中的實際權限決定的。受限于JDBC方式訪問GaussDB數據庫的查詢處理機制，查詢所要獲取的數據必須全部經過Coordinator節點進行傳輸，在獲取數據量比較大的情況下，Coordinator節點可能會成為整個并發查詢時的性能瓶頸。

未來的技術優化與展望

通過使用openLooKeng對底層不同數據存儲源的集成，基本上解決了數據分析師進行跨源數據關聯查詢分析的功能性問題。但是對于GaussDB這樣的分布式關系型數據庫還是存在單點的性能瓶頸，后續將深入探索JDBC多分片管理以及GaussDB的GDS多分片導出技術來進行并行查詢上的優化。

同時在終端的查詢用戶和使用JDBC方式連接器的底層用戶之間的權限映射管理上，權限的配置方式還比較簡單，后續將和開源社區一起探索更加細粒度的權限控制，能夠在終端用戶、Catalog連接器、SQL命令、表的各個粒度上都分別能進行各種級別（all，read-only，none）的權限管理和控制。