面向HBase的大數(shù)據(jù)脫敏技術(shù)實(shí)踐

文/王明 張海洋 王步放 付征

1 引言

1.1 背景

隨著《中華人民共和國網(wǎng)絡(luò)安全法》、等級(jí)保護(hù)2.0、《通用數(shù)據(jù)保護(hù)條例》（General Data Protection Regulation，簡稱GDPR）等法律法規(guī)的陸續(xù)推出，信息安全相關(guān)法律法規(guī)及制度日趨完善，保護(hù)公民個(gè)人信息安全，防止信息被竊取、泄露和非法使用是每個(gè)企業(yè)必須面對的問題。

針對數(shù)據(jù)安全的罰單令人咋舌，法國數(shù)據(jù)保護(hù)監(jiān)管機(jī)構(gòu)按照歐洲《通用數(shù)據(jù)保護(hù)條例》（GDPR）規(guī)定，對谷歌開出5700萬美元罰單，英國數(shù)據(jù)安全監(jiān)管部門宣布，將對英國航空公司2018年客戶數(shù)據(jù)遭泄露事件開出1.83億英鎊巨額罰單。

數(shù)據(jù)機(jī)密性的保護(hù)成為各界關(guān)注的焦點(diǎn)。但任何事情都是相對的，由于大數(shù)據(jù)技術(shù)迅猛發(fā)展，數(shù)據(jù)交換需求越來越多。旅客數(shù)據(jù)的機(jī)密性問題恰恰限制了數(shù)據(jù)流動(dòng)性。一邊是對數(shù)據(jù)的保護(hù)需求，而另一邊是在大數(shù)據(jù)時(shí)代，信息互聯(lián)互通的需求。面對上述問題，大數(shù)據(jù)環(huán)境下的數(shù)據(jù)脫敏工作具有極大的研究價(jià)值。

中國民航信息網(wǎng)絡(luò)股份有限公司（本文簡稱：中航信）所運(yùn)營的民航商務(wù)信息系統(tǒng)被國務(wù)院列為八大系統(tǒng)之一，包含大量敏感數(shù)據(jù)。為確保合規(guī)性和問題排查的需要，建立了大數(shù)據(jù)平臺(tái)。同時(shí)為客戶提供更全面的服務(wù)。為了降低數(shù)據(jù)的敏感性，進(jìn)行了數(shù)據(jù)脫敏系統(tǒng)的開發(fā)及實(shí)施。

1.2 國內(nèi)研究現(xiàn)狀

在銀行業(yè)、電信運(yùn)營商等數(shù)據(jù)敏感的行業(yè)，數(shù)據(jù)脫敏工作已經(jīng)成為重要的核心安全保障方案。

從數(shù)據(jù)脫敏產(chǎn)品和服務(wù)來看，IBM、Oracle等已有成熟產(chǎn)品，HP公司提供定制解決方案，安華金和等國內(nèi)企業(yè)也都有成功的實(shí)施案例。2019年北京網(wǎng)絡(luò)安全大會(huì)上大數(shù)據(jù)治理方案中也有多家公司的產(chǎn)品或服務(wù)中也包含了數(shù)據(jù)脫敏部分。

2 數(shù)據(jù)脫敏面對的難點(diǎn)

2.1 數(shù)據(jù)量巨大

隨著民航旅客運(yùn)輸量持續(xù)保持高增長，2018年民航旅客運(yùn)輸量6.1億人次，比上年增長10.9%，根據(jù)國際航協(xié)最新數(shù)據(jù)到2037年全球航空客運(yùn)量將達(dá)到82億人次。中航信目前每天新增日志存儲(chǔ)量已達(dá)到TB級(jí)，進(jìn)行必要的清洗和處理后存入大數(shù)據(jù)平臺(tái)HBase數(shù)據(jù)庫。

2.2 數(shù)據(jù)格式復(fù)雜

中國航信運(yùn)營的民航旅客信息服務(wù)系統(tǒng)中，存在的海量高維度數(shù)據(jù)，如：客票、預(yù)訂、航班、配載、常旅客、收益、異常航班處理等數(shù)十個(gè)核心系統(tǒng)及配套的電商網(wǎng)站等等數(shù)百個(gè)IT系統(tǒng)，而敏感數(shù)據(jù)分散在各個(gè)系統(tǒng)中，需要通過詳細(xì)的調(diào)研以確定數(shù)據(jù)脫敏的工作范圍，并保障脫敏后的關(guān)聯(lián)性。而且，各軟件產(chǎn)品的日志內(nèi)容和數(shù)據(jù)內(nèi)容側(cè)重點(diǎn)不同，都需要得到保護(hù)。

其次，在這數(shù)百軟件系統(tǒng)中，數(shù)據(jù)之間的依賴關(guān)聯(lián)關(guān)系錯(cuò)綜復(fù)雜，需要對數(shù)據(jù)源及依賴關(guān)系進(jìn)行梳理。同時(shí)，很多數(shù)據(jù)來源于航空公司等外部系統(tǒng)，也需要對外部關(guān)聯(lián)系統(tǒng)進(jìn)行調(diào)研和分析。

第三，各個(gè)數(shù)據(jù)的存儲(chǔ)方式也存在較大的差異，包括字段類型的差異、多種數(shù)據(jù)混合存儲(chǔ)、非標(biāo)準(zhǔn)的自由文本存儲(chǔ)形式等，都需要進(jìn)行梳理。

2.3 業(yè)務(wù)要求苛刻

用于開發(fā)、測試和數(shù)據(jù)分析的數(shù)據(jù)需求各不相同，同時(shí)要保證各個(gè)系統(tǒng)脫敏后數(shù)據(jù)關(guān)聯(lián)性，敏感數(shù)據(jù)的識(shí)別靠人工梳理難以應(yīng)對日益增長的數(shù)據(jù)增量或變化……一系列困難為數(shù)據(jù)脫敏工作的開展造成了巨大的困難。

2.4 對HBase數(shù)據(jù)庫知識(shí)相對不足

圖1

圖2

圖3

圖4

HBase（Hadoop Database）是一個(gè)高可靠、高性能、面向列、可伸縮的分布式存儲(chǔ)系統(tǒng)，與關(guān)系型數(shù)據(jù)有明顯區(qū)別，是一個(gè)適合于非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)的數(shù)據(jù)庫。另一個(gè)不同的是HBase基于列的而不是基于行的模式。HBase用戶存儲(chǔ)數(shù)據(jù)行在一個(gè)表里。一個(gè)數(shù)據(jù)行擁有一個(gè)可選擇的鍵和任意數(shù)量的列，一個(gè)或多個(gè)列組成一個(gè)Column Family，一個(gè)Column Family下的列位于一個(gè)HFile中，易于緩存數(shù)據(jù)。表是疏松的存儲(chǔ)的，因此用戶可以給行定義各種不同的列。在HBase中數(shù)據(jù)按主鍵排序，同時(shí)表按主鍵劃分為多個(gè)Region。

表1

圖5

在分布式的生產(chǎn)環(huán)境中，HBase需要運(yùn)行在HDFS 之上，以HDFS作為其基礎(chǔ)的存儲(chǔ)設(shè)施。HBase上層提供了訪問數(shù)據(jù)的Java API層，供應(yīng)用訪問存儲(chǔ)在HBase的數(shù)據(jù)。在HBase的集群中主要由Master和Region Server組成，以及Zookeeper，具體模塊如圖1所示。

3 HBase脫敏實(shí)踐過程

3.1 HBase的業(yè)界通用使用方法研究

3.1.1 HBase訪問接口包括

（1）Native Java API，最常規(guī)和高效的訪問方式，適合Hadoop MapReduce Job并行批處理HBase表數(shù)據(jù)；

（2）HBase Shell，HBase的命令行工具，最簡單的接口，適合HBase管理使用；

（3）Thrift Gateway，利用Thrift序列化技術(shù)，支持C++，PHP，Python等多種語言，適合其他異構(gòu)系統(tǒng)在線訪問HBase表數(shù)據(jù)；

（4）REST Gateway，支持REST 風(fēng)格的Http API訪問HBase, 解除了語言限制；

（5）Pig，可以使用Pig Latin流式編程語言來操作HBase中的數(shù)據(jù)，和Hive類似，本質(zhì)最終也是編譯成MapReduce Job來處理HBase表數(shù)據(jù)，適合做數(shù)據(jù)統(tǒng)計(jì)；

（6）Hive，可以使用類似SQL語言來訪問HBase。

3.1.2 常用的HBase讀寫流程

如圖2所示，可以看出HBase只有增添數(shù)據(jù)，所有的更新和刪除操作都是在后續(xù)的Compact歷程中舉行的，使得用戶的寫操作只要進(jìn)入內(nèi)存就可以立刻返回，實(shí)現(xiàn)了HBase I/O的高機(jī)能。讀操作的尋址過程為：client-->Zookeeper-->-ROOT-表-->.META.表-->RegionServer-->Region-->client。

圖6

圖8

圖9

3.1.3 搜索到的Hbase應(yīng)用案例

（1）HBase在某公司A的用法。HBase在A公司主要存放了以下四種數(shù)據(jù)類型：

統(tǒng)計(jì)結(jié)果、報(bào)表類數(shù)據(jù)：主要是運(yùn)營、運(yùn)力情況、收入等結(jié)果，通常需要配合Phoenix進(jìn)行SQL查詢。數(shù)據(jù)量較小，對查詢的靈活性要求高，延遲要求一般。

原始事實(shí)類數(shù)據(jù)：如訂單、司機(jī)乘客的GPS軌跡、日志等，主要用作在線和離線的數(shù)據(jù)供給。數(shù)據(jù)量大，對一致性和可用性要求高，延遲敏感，實(shí)時(shí)寫入，單點(diǎn)或批量查詢。如圖3所示。

中間結(jié)果數(shù)據(jù)：指模型訓(xùn)練所需要的數(shù)據(jù)等。數(shù)據(jù)量大，可用性和一致性要求一般，對批量查詢時(shí)的吞吐量要求高。

圖10

圖11

圖12

圖13

線上系統(tǒng)的備份數(shù)據(jù)：用戶把原始數(shù)據(jù)存在了其他關(guān)系數(shù)據(jù)庫或文件服務(wù)，把HBase作為一個(gè)異地容災(zāi)的方案。

（2）HBase在某大型互聯(lián)網(wǎng)公司B的應(yīng)用。HBase是B公司搜索的核心存儲(chǔ)系統(tǒng)，它和計(jì)算引擎緊密結(jié)合，主要服務(wù)搜索和推薦的業(yè)務(wù)。如圖4所示。

3.2 脫敏過程中遇到的困難及解決方案

3.2.1 利用HBase集群的高性能之將應(yīng)用打包

我們曾經(jīng)對Oracle、EDB等傳統(tǒng)關(guān)系型數(shù)據(jù)庫進(jìn)行過脫敏，效率約在15000條每秒。當(dāng)我們懷著忐忑的心情將成熟的脫敏傳統(tǒng)數(shù)據(jù)脫庫的方法應(yīng)用到大數(shù)據(jù)環(huán)境HBase時(shí)候，面對民航大數(shù)據(jù)，脫敏效率完全達(dá)不到要求。這種將源數(shù)據(jù)庫的數(shù)據(jù)抽取到脫敏平臺(tái)，對數(shù)據(jù)進(jìn)行脫敏轉(zhuǎn)換后，再將轉(zhuǎn)換后的數(shù)據(jù)裝載到目標(biāo)數(shù)據(jù)庫的方法效率太低。這種技術(shù)處理傳統(tǒng)關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)量，一般都可以在數(shù)個(gè)小時(shí)執(zhí)行完脫敏任務(wù)。但是，對于HBase這樣的超大規(guī)模數(shù)據(jù)處理平臺(tái)，用傳統(tǒng)的脫敏方式處理將需要幾個(gè)月的時(shí)間，這樣的處理速度是不可忍受的。并行處理的優(yōu)勢完全沒有發(fā)揮，系統(tǒng)的性能瓶頸鎖定在了脫敏系統(tǒng)上。

經(jīng)過技術(shù)研究（如本文前章所述），現(xiàn)有的對Hadoop平臺(tái)HBase脫敏的處理方式一般是通過Hadoop API或者第三方工具如Phoenix，將HBase數(shù)據(jù)抽取到脫敏平臺(tái)進(jìn)行脫敏轉(zhuǎn)換處理，再將轉(zhuǎn)換后的數(shù)據(jù)通過API或工具裝載回HBase數(shù)據(jù)庫。這些方式都面臨脫敏平臺(tái)單點(diǎn)處理能力上限問題。

經(jīng)過多次探索，為了打通脫敏平臺(tái)和Hadoop集群，實(shí)現(xiàn)脫敏任務(wù)自動(dòng)化提交運(yùn)行，必須能夠從脫敏平臺(tái)提交MapReduce作業(yè)到Hadoop集群自動(dòng)執(zhí)行。Hadoop提供了提交MapReduce作業(yè)的API(Job.submit())，但脫敏作業(yè)需要依賴平臺(tái)的其它類、脫敏平臺(tái)的數(shù)據(jù)庫配置信息及第三方JAR包，必須將這些類，配置文件及第三方JAR包一起打進(jìn)需要提交的JAR包里，且必須將這個(gè)提交的JAR包打成FAT JAR(JAR包里不存在第三方JAR，而是第三方JAR里的文件)，否則會(huì)出現(xiàn)找不到第三方JAR包中的類的異常。打JAR包主要使用了JDK的java.util.jar包中的API。另外，提交任務(wù)的用戶必須為Hadoop平臺(tái)具有可提交作業(yè)權(quán)限的有效用戶，可通過設(shè)置系統(tǒng)環(huán)境變量Hadoop_USER_NAME來設(shè)置提交MapReduce作業(yè)的用戶。JAR文件格式以流行的ZIP文件格式為基礎(chǔ)。與ZIP文件不同的是，JAR文件不僅用于壓縮和發(fā)布，而且還用于部署和封裝庫、組件和插件程序，并可被編譯器和JVM這樣的工具直接使用。一個(gè)JAR文件可以用于：發(fā)布和使用類庫、作為應(yīng)用程序和擴(kuò)展的構(gòu)建單元、作為組件、Applet或者插件程序的部署單位、用于打包與組件相關(guān)聯(lián)的輔助資源。FAT JAR打包插件，可以方便的完成各種打包任務(wù)，可以包含外部的包等。

3.2.2 效率的更高要求之從MapReduce到Spark

在效率方面數(shù)據(jù)脫敏一直需要將資源壓榨到可承受的極致，以更高的效率滿足脫敏數(shù)據(jù)需求。在經(jīng)過MapReduce和Spark的對比后，得益于Spark中一種名為RDD（Resilient Distributed DataSets）的數(shù)據(jù)處理模型，Spark實(shí)現(xiàn)了對MapReduce性能的直線超越。決定繼續(xù)對脫敏系統(tǒng)進(jìn)行改造，支持Spark。圖5是業(yè)界將MapReduce和Spark進(jìn)行對比的圖。

從表1中可以看出排序100TB的數(shù)據(jù)（1萬億條數(shù)據(jù)），Spark只用了Hadoop所用1/10的計(jì)算資源，耗時(shí)只有Hadoop的1/3。面對如此令人興奮的性能提升。我們進(jìn)行了改造，以500M文件在單結(jié)點(diǎn)PC機(jī)為例進(jìn)行測試，結(jié)果如下，對于6結(jié)點(diǎn)服務(wù)器1TB文件則用4.6小時(shí)完成，利用現(xiàn)有資源，完全可以滿足TB級(jí)數(shù)據(jù)每天的脫敏需求。

3.2.3 如何根據(jù)Key值進(jìn)行規(guī)則綁定之掃描表結(jié)構(gòu)

現(xiàn)有的脫敏手段，需要識(shí)別敏感數(shù)據(jù)，綁定特定的脫敏規(guī)則。識(shí)別敏感數(shù)據(jù)的方法業(yè)界一般分為兩種：

（1）數(shù)據(jù)建設(shè)過程中的文檔記錄結(jié)合人工梳理的方式；

（2）根據(jù)數(shù)據(jù)結(jié)構(gòu)特性統(tǒng)計(jì)識(shí)別敏感數(shù)據(jù)的方式。

對于HBase數(shù)據(jù)庫，我們結(jié)合常用方法進(jìn)行了定制開發(fā)：由于HBase數(shù)據(jù)庫的表結(jié)構(gòu)能夠動(dòng)態(tài)變化、不固定，為了獲取HBase的表結(jié)構(gòu)，必須首先對HBase數(shù)據(jù)庫的表做全表掃描，由于只掃表結(jié)構(gòu)，不掃具體數(shù)據(jù)，速度還是比較快的。另外，由于HBase中并不是每張表都需要脫敏，有些表的表結(jié)構(gòu)是固定的，不會(huì)變化的，也就是不會(huì)在新增加數(shù)據(jù)的過程中添加新的列，那么就可以通過在脫敏平臺(tái)配置需要掃描的表和記錄數(shù)，來提高掃描效率。掃描表結(jié)構(gòu)也是由脫敏平臺(tái)提交MapReduce/Spark作業(yè)的方式進(jìn)行，獲取到的表結(jié)構(gòu)會(huì)存儲(chǔ)到脫敏平臺(tái)的數(shù)據(jù)庫中，HBase表結(jié)構(gòu)的主要形式為列族名：字段名。此時(shí)，就可以在脫敏平臺(tái)針對HBase的表和字段進(jìn)行脫敏算法的配置。

這種實(shí)施方案首先保障了字段的無遺漏，其次可以結(jié)合人工的方法篩選綁定規(guī)則，達(dá)到了效率和準(zhǔn)確性的最佳平衡。

定義掃描字段集（圖6）。

綁定掃描規(guī)則集（圖7）。

對這個(gè)字段集中的各個(gè)表的各個(gè)需要脫敏的字段進(jìn)行綁定脫敏規(guī)則。

3.2.4 其他一些“坑”-脫敏后表的權(quán)限

為了提升脫敏策略的靈活度，脫敏過程中會(huì)給執(zhí)行者一些選擇，比如是否覆蓋原表，脫敏任務(wù)成熟后建議覆蓋原表，比較方便和安全。我們提供兩種方案，脫敏平臺(tái)根據(jù)預(yù)設(shè)規(guī)則判斷是否覆蓋HBase數(shù)據(jù)庫的原表：

（1）在覆蓋HBase數(shù)據(jù)庫的原表的情況下，刪除原表并重命名脫敏后的表為原表的名稱；

（2）在不覆蓋HBase數(shù)據(jù)庫的原表的情況下，創(chuàng)建表并保存脫敏后的表數(shù)據(jù)，表名通過前臺(tái)配置。

新建表的權(quán)限需要和源表相同，避免因權(quán)限問題導(dǎo)致的業(yè)務(wù)不可用。

4 HBase脫敏過程及實(shí)施效果

圖14

圖15

4.1 HBase的脫敏過程

4.1.1 配置數(shù)據(jù)源

如圖8所示，添加配置數(shù)據(jù)源配置，選擇數(shù)據(jù)源平臺(tái)為HBase，其他信息可以隨意填寫，不為空即可，填寫完后保存。

4.1.2 定義掃描字段集

如圖9所示。

4.1.3 綁定掃描規(guī)則集

對這個(gè)字段集中的各個(gè)表的各個(gè)需要脫敏的字段進(jìn)行綁定脫敏規(guī)則。如圖10所示。

4.1.4 創(chuàng)建掃描任務(wù)

創(chuàng)建脫敏任務(wù)，選擇到要脫敏的數(shù)據(jù)源，選擇脫敏字段集，選擇脫敏目標(biāo)數(shù)據(jù)源，其他按需配置后保存任務(wù)。如圖11所示。

4.1.5 啟動(dòng)掃描任務(wù)

如圖12。

4.1.6 掃描任務(wù)監(jiān)控

脫敏任務(wù)啟動(dòng)后，可以在任務(wù)監(jiān)控中查看到該脫敏任務(wù)的執(zhí)行信息以及分解的子任務(wù)執(zhí)行進(jìn)度。如圖13。

4.2 HBase的脫敏效果

（1）脫敏前后對比。如圖14。

（2）脫敏前后數(shù)據(jù)表列表（為避免信息或算法泄露，使用測試數(shù)據(jù)并進(jìn)行了變形）。如圖15。

5 結(jié)束語

以上是對民航旅客大數(shù)據(jù)系統(tǒng)HBase的脫敏技術(shù)研究與實(shí)施總結(jié)。中航信經(jīng)過長期的開發(fā)和研究，建立了數(shù)據(jù)脫敏工具平臺(tái)，并探索出了一條針對大數(shù)據(jù)HBase的脫敏實(shí)踐方案。通過脫敏，可以在信息安全機(jī)密性和可用性的天平上找到一個(gè)合適的支點(diǎn)，滿足對私密信息的保護(hù)和對真實(shí)數(shù)據(jù)的分析需要兩方面的要求。確保大數(shù)據(jù)安全快捷的流動(dòng)起來，進(jìn)一步推動(dòng)大數(shù)據(jù)技術(shù)的開展，為客戶帶來價(jià)值，為民航事業(yè)的健康發(fā)展貢獻(xiàn)力量！