面向HBase的大数据脱敏技术实践

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

1 引言

1.1 背景

随着《中华人民共和国网络安全法》、等级保护2.0、《通用数据保护条例》（General Data Protection Regulation，简称GDPR）等法律法规的陆续推出，信息安全相关法律法规及制度日趋完善，保护公民个人信息安全，防止信息被窃取、泄露和非法使用是每个企业必须面对的问题。

针对数据安全的罚单令人咋舌，法国数据保护监管机构按照欧洲《通用数据保护条例》（GDPR）规定，对谷歌开出5700万美元罚单，英国数据安全监管部门宣布，将对英国航空公司2018年客户数据遭泄露事件开出1.83亿英镑巨额罚单。

数据机密性的保护成为各界关注的焦点。但任何事情都是相对的，由于大数据技术迅猛发展，数据交换需求越来越多。旅客数据的机密性问题恰恰限制了数据流动性。一边是对数据的保护需求，而另一边是在大数据时代，信息互联互通的需求。面对上述问题，大数据环境下的数据脱敏工作具有极大的研究价值。

中国民航信息网络股份有限公司（本文简称：中航信）所运营的民航商务信息系统被国务院列为八大系统之一，包含大量敏感数据。为确保合规性和问题排查的需要，建立了大数据平台。同时为客户提供更全面的服务。为了降低数据的敏感性，进行了数据脱敏系统的开发及实施。

1.2 国内研究现状

在银行业、电信运营商等数据敏感的行业，数据脱敏工作已经成为重要的核心安全保障方案。

从数据脱敏产品和服务来看，IBM、Oracle等已有成熟产品，HP公司提供定制解决方案，安华金和等国内企业也都有成功的实施案例。2019年北京网络安全大会上大数据治理方案中也有多家公司的产品或服务中也包含了数据脱敏部分。

2 数据脱敏面对的难点

2.1 数据量巨大

随着民航旅客运输量持续保持高增长，2018年民航旅客运输量6.1亿人次，比上年增长10.9%，根据国际航协最新数据到2037年全球航空客运量将达到82亿人次。中航信目前每天新增日志存储量已达到TB级，进行必要的清洗和处理后存入大数据平台HBase数据库。

2.2 数据格式复杂

中国航信运营的民航旅客信息服务系统中，存在的海量高维度数据，如：客票、预订、航班、配载、常旅客、收益、异常航班处理等数十个核心系统及配套的电商网站等等数百个IT系统，而敏感数据分散在各个系统中，需要通过详细的调研以确定数据脱敏的工作范围，并保障脱敏后的关联性。而且，各软件产品的日志内容和数据内容侧重点不同，都需要得到保护。

其次，在这数百软件系统中，数据之间的依赖关联关系错综复杂，需要对数据源及依赖关系进行梳理。同时，很多数据来源于航空公司等外部系统，也需要对外部关联系统进行调研和分析。

第三，各个数据的存储方式也存在较大的差异，包括字段类型的差异、多种数据混合存储、非标准的自由文本存储形式等，都需要进行梳理。

2.3 业务要求苛刻

用于开发、测试和数据分析的数据需求各不相同，同时要保证各个系统脱敏后数据关联性，敏感数据的识别靠人工梳理难以应对日益增长的数据增量或变化……一系列困难为数据脱敏工作的开展造成了巨大的困难。

2.4 对HBase数据库知识相对不足

图1

图2

图3

图4

HBase（Hadoop Database）是一个高可靠、高性能、面向列、可伸缩的分布式存储系统，与关系型数据有明显区别，是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。HBase用户存储数据行在一个表里。一个数据行拥有一个可选择的键和任意数量的列，一个或多个列组成一个Column Family，一个Column Family下的列位于一个HFile中，易于缓存数据。表是疏松的存储的，因此用户可以给行定义各种不同的列。在HBase中数据按主键排序，同时表按主键划分为多个Region。

表1

图5

在分布式的生产环境中，HBase需要运行在HDFS 之上，以HDFS作为其基础的存储设施。HBase上层提供了访问数据的Java API层，供应用访问存储在HBase的数据。在HBase的集群中主要由Master和Region Server组成，以及Zookeeper，具体模块如图1所示。

3 HBase脱敏实践过程

3.1 HBase的业界通用使用方法研究

3.1.1 HBase访问接口包括

（1）Native Java API，最常规和高效的访问方式，适合Hadoop MapReduce Job并行批处理HBase表数据；

（2）HBase Shell，HBase的命令行工具，最简单的接口，适合HBase管理使用；

（3）Thrift Gateway，利用Thrift序列化技术，支持C++，PHP，Python等多种语言，适合其他异构系统在线访问HBase表数据；

（4）REST Gateway，支持REST 风格的Http API访问HBase, 解除了语言限制；

（5）Pig，可以使用Pig Latin流式编程语言来操作HBase中的数据，和Hive类似，本质最终也是编译成MapReduce Job来处理HBase表数据，适合做数据统计；

（6）Hive，可以使用类似SQL语言来访问HBase。

3.1.2 常用的HBase读写流程

如图2所示，可以看出HBase只有增添数据，所有的更新和删除操作都是在后续的Compact历程中举行的，使得用户的写操作只要进入内存就可以立刻返回，实现了HBase I/O的高机能。读操作的寻址过程为：client-->Zookeeper-->-ROOT-表-->.META.表-->RegionServer-->Region-->client。

图6

图8

图9

3.1.3 搜索到的Hbase应用案例

（1）HBase在某公司A的用法。HBase在A公司主要存放了以下四种数据类型：

统计结果、报表类数据：主要是运营、运力情况、收入等结果，通常需要配合Phoenix进行SQL查询。数据量较小，对查询的灵活性要求高，延迟要求一般。

原始事实类数据：如订单、司机乘客的GPS轨迹、日志等，主要用作在线和离线的数据供给。数据量大，对一致性和可用性要求高，延迟敏感，实时写入，单点或批量查询。如图3所示。

中间结果数据：指模型训练所需要的数据等。数据量大，可用性和一致性要求一般，对批量查询时的吞吐量要求高。

图10

图11

图12

图13

线上系统的备份数据：用户把原始数据存在了其他关系数据库或文件服务，把HBase作为一个异地容灾的方案。

（2）HBase在某大型互联网公司B的应用。HBase是B公司搜索的核心存储系统，它和计算引擎紧密结合，主要服务搜索和推荐的业务。如图4所示。

3.2 脱敏过程中遇到的困难及解决方案

3.2.1 利用HBase集群的高性能之将应用打包

我们曾经对Oracle、EDB等传统关系型数据库进行过脱敏，效率约在15000条每秒。当我们怀着忐忑的心情将成熟的脱敏传统数据脱库的方法应用到大数据环境HBase时候，面对民航大数据，脱敏效率完全达不到要求。这种将源数据库的数据抽取到脱敏平台，对数据进行脱敏转换后，再将转换后的数据装载到目标数据库的方法效率太低。这种技术处理传统关系型数据库的数据量，一般都可以在数个小时执行完脱敏任务。但是，对于HBase这样的超大规模数据处理平台，用传统的脱敏方式处理将需要几个月的时间，这样的处理速度是不可忍受的。并行处理的优势完全没有发挥，系统的性能瓶颈锁定在了脱敏系统上。

经过技术研究（如本文前章所述），现有的对Hadoop平台HBase脱敏的处理方式一般是通过Hadoop API或者第三方工具如Phoenix，将HBase数据抽取到脱敏平台进行脱敏转换处理，再将转换后的数据通过API或工具装载回HBase数据库。这些方式都面临脱敏平台单点处理能力上限问题。

经过多次探索，为了打通脱敏平台和Hadoop集群，实现脱敏任务自动化提交运行，必须能够从脱敏平台提交MapReduce作业到Hadoop集群自动执行。Hadoop提供了提交MapReduce作业的API(Job.submit())，但脱敏作业需要依赖平台的其它类、脱敏平台的数据库配置信息及第三方JAR包，必须将这些类，配置文件及第三方JAR包一起打进需要提交的JAR包里，且必须将这个提交的JAR包打成FAT JAR(JAR包里不存在第三方JAR，而是第三方JAR里的文件)，否则会出现找不到第三方JAR包中的类的异常。打JAR包主要使用了JDK的java.util.jar包中的API。另外，提交任务的用户必须为Hadoop平台具有可提交作业权限的有效用户，可通过设置系统环境变量Hadoop_USER_NAME来设置提交MapReduce作业的用户。JAR文件格式以流行的ZIP文件格式为基础。与ZIP文件不同的是，JAR文件不仅用于压缩和发布，而且还用于部署和封装库、组件和插件程序，并可被编译器和JVM这样的工具直接使用。一个JAR文件可以用于：发布和使用类库、作为应用程序和扩展的构建单元、作为组件、Applet或者插件程序的部署单位、用于打包与组件相关联的辅助资源。FAT JAR打包插件，可以方便的完成各种打包任务，可以包含外部的包等。

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

在效率方面数据脱敏一直需要将资源压榨到可承受的极致，以更高的效率满足脱敏数据需求。在经过MapReduce和Spark的对比后，得益于Spark中一种名为RDD（Resilient Distributed DataSets）的数据处理模型，Spark实现了对MapReduce性能的直线超越。决定继续对脱敏系统进行改造，支持Spark。图5是业界将MapReduce和Spark进行对比的图。

从表1中可以看出排序100TB的数据（1万亿条数据），Spark只用了Hadoop所用1/10的计算资源，耗时只有Hadoop的1/3。面对如此令人兴奋的性能提升。我们进行了改造，以500M文件在单结点PC机为例进行测试，结果如下，对于6结点服务器1TB文件则用4.6小时完成，利用现有资源，完全可以满足TB级数据每天的脱敏需求。

3.2.3 如何根据Key值进行规则绑定之扫描表结构

现有的脱敏手段，需要识别敏感数据，绑定特定的脱敏规则。识别敏感数据的方法业界一般分为两种：

（1）数据建设过程中的文档记录结合人工梳理的方式；

（2）根据数据结构特性统计识别敏感数据的方式。

对于HBase数据库，我们结合常用方法进行了定制开发：由于HBase数据库的表结构能够动态变化、不固定，为了获取HBase的表结构，必须首先对HBase数据库的表做全表扫描，由于只扫表结构，不扫具体数据，速度还是比较快的。另外，由于HBase中并不是每张表都需要脱敏，有些表的表结构是固定的，不会变化的，也就是不会在新增加数据的过程中添加新的列，那么就可以通过在脱敏平台配置需要扫描的表和记录数，来提高扫描效率。扫描表结构也是由脱敏平台提交MapReduce/Spark作业的方式进行，获取到的表结构会存储到脱敏平台的数据库中，HBase表结构的主要形式为列族名：字段名。此时，就可以在脱敏平台针对HBase的表和字段进行脱敏算法的配置。

这种实施方案首先保障了字段的无遗漏，其次可以结合人工的方法筛选绑定规则，达到了效率和准确性的最佳平衡。

定义扫描字段集（图6）。

绑定扫描规则集（图7）。

对这个字段集中的各个表的各个需要脱敏的字段进行绑定脱敏规则。

3.2.4 其他一些“坑”-脱敏后表的权限

为了提升脱敏策略的灵活度，脱敏过程中会给执行者一些选择，比如是否覆盖原表，脱敏任务成熟后建议覆盖原表，比较方便和安全。我们提供两种方案，脱敏平台根据预设规则判断是否覆盖HBase数据库的原表：

（1）在覆盖HBase数据库的原表的情况下，删除原表并重命名脱敏后的表为原表的名称；

（2）在不覆盖HBase数据库的原表的情况下，创建表并保存脱敏后的表数据，表名通过前台配置。

新建表的权限需要和源表相同，避免因权限问题导致的业务不可用。

4 HBase脱敏过程及实施效果

图14

图15

4.1 HBase的脱敏过程

4.1.1 配置数据源

如图8所示，添加配置数据源配置，选择数据源平台为HBase，其他信息可以随意填写，不为空即可，填写完后保存。

4.1.2 定义扫描字段集

如图9所示。

4.1.3 绑定扫描规则集

对这个字段集中的各个表的各个需要脱敏的字段进行绑定脱敏规则。如图10所示。

4.1.4 创建扫描任务

创建脱敏任务，选择到要脱敏的数据源，选择脱敏字段集，选择脱敏目标数据源，其他按需配置后保存任务。如图11所示。

4.1.5 启动扫描任务

如图12。

4.1.6 扫描任务监控

脱敏任务启动后，可以在任务监控中查看到该脱敏任务的执行信息以及分解的子任务执行进度。如图13。

4.2 HBase的脱敏效果

（1）脱敏前后对比。如图14。

（2）脱敏前后数据表列表（为避免信息或算法泄露，使用测试数据并进行了变形）。如图15。

5 结束语

以上是对民航旅客大数据系统HBase的脱敏技术研究与实施总结。中航信经过长期的开发和研究，建立了数据脱敏工具平台，并探索出了一条针对大数据HBase的脱敏实践方案。通过脱敏，可以在信息安全机密性和可用性的天平上找到一个合适的支点，满足对私密信息的保护和对真实数据的分析需要两方面的要求。确保大数据安全快捷的流动起来，进一步推动大数据技术的开展，为客户带来价值，为民航事业的健康发展贡献力量！