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

1 引言

1.1 背景

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3 業(yè)務要求苛刻

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

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

圖1

圖2

圖3

圖4

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

表1

圖5

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

3 HBase脫敏實踐過程

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 風格的Http API訪問HBase, 解除了語言限制；

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

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

3.1.2 常用的HBase讀寫流程

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

圖6

圖8

圖9

3.1.3 搜索到的Hbase應用案例

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

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

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

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

圖10

圖11

圖12

圖13

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

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

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

3.2.1 利用HBase集群的高性能之將應用打包

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 HBase脫敏過程及實施效果

圖14

圖15

4.1 HBase的脫敏過程

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

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

4.1.2 定義掃描字段集

如圖9所示。

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

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

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

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

4.1.5 啟動掃描任務

如圖12。

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

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

4.2 HBase的脫敏效果

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

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

5 結(jié)束語

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