hash是线程安全的吗?怎么解决?_怎么劳永逸地解决数据安全问题？

点击关注上方“知了小巷”，

设为“置顶或星标”，第一时间送达干货。

前文回顾：

(⼀)数据服务到底解决了什么问题？

(二)数据服务难道就是对外提供个API吗？

交付速度和质量问题解决了，⽼板说还得“省”

今天的数据怎么又不对？！

数据模型⽆法复⽤，归根结底还是设计问题

如何统⼀管理纷繁杂乱的数据指标？

元数据中⼼的关键⽬标和技术实现⽅案

数据中台到底怎么建设呢？

到底什么样的企业应该建设数据中台？

数据中台到底是不是大数据的下一站？ 

前文已经了解数据中台在数据建设效率、质量和成本⽅⾯的内容。⽽除了快、准和省以外，数据中台还必须是安全的。因为如果不安全，很可能出现和“微盟删库跑路”同样的事情。所以，要十分重视数据中台的数据安全。

2020年2⽉23⽇19点，国内最⼤的精准营销服务商微盟出现了⼤⾯积的系统故障，旗下300万商⼾的线上业务全部停⽌，商铺后台的所有数据被清零。始作俑者是⼀位运维⼈员，他在⽣产环境数据库进⾏了删库操作，⽽刚刚上市不久的微盟就因此遭受了巨⼤的损失，从2⽉23⽇宕机以来，市值已经蒸发了30亿港元。这件事⼉堪称史上最贵的安全事件。

那么从微盟的教训中，我们能得到什么警醒呢？在数据中台中怎么防⽌出现类似的事件呢？这或许是数据从业者需要认真思考的内容。安全问题可⼤可⼩，不出事情，可能根本不会重视，但是⼀旦出现事故，就是灾难性的。

数据中台的安全保障

 

三个问题：

1. 如何解决数据误删除问题；

2. 如何解决敏感数据泄露问题；

3. 如何解决开发和⽣产物理隔离问题。

在数据中台建设中⼀定会⾯临上面三个问题，此文可以找到解决这些问题的⽅法。

> 机制⼀：数据备份与恢复

---

对于绝⼤多数的企业，数据中台的数据都存储在HDFS中，即使是实时的数据(存储于Kafka)，也会归档⼀份到HDFS，因为要保存历史数据进⾏回算或者补数据。所以我们要解决的核⼼问题是HDFS 的数据备份。

HDFS数据的备份，基于HDFS快照 + DistCp + EC实现。

分为线上集群和冷备集群两个集群，数据加⼯任务访问的是线上集群，存储采⽤的是HDFS默认的3副本。⽽冷备集群，主要考虑到存储成本的因素，采⽤的是EC存储。

Hadoop在3.x就正式引⼊了EC存储，它是⼀种基于纠删码实现的数据容错机制，通过将数据进⾏分块，然后基于⼀定的算法计算⼀些冗余的校验块，当其中⼀部分数据块丢失的时候，可以通过这些冗余的校验块和剩余的数据块，恢复出丢失的数据块。

这么说可能不太形象，做个⽐喻。⽐如有三个数据块，分别存储的是1、2和3。我们⾮常担⼼其中⼀个数据块坏了，丢失内容。所以增加了⼀个块，这个块存储的内容是前⾯三个数据块之和。那么如果其中任意⼀个数据块坏了，我们可以根据现有的数据块计算出丢失的数据块内容。  

⽐如1丢失了，我们可以根据6-3-2 计算出1，当然这个只是最简单的EC算法，只能容忍⼀个数据块丢失，实际的EC算法要再复杂⼀些 。

关于EC具体的算法细节，不是重点。EC 存储，在不降低可靠性的前提下(与HDFS 3副本可靠性相同)，通过牺牲了⼀定的计算性能(因为计算校验块需要消耗额外的计算资源)，将数据存储成本降低了⼀半，⾮常适合低频访问的冷数据的存储，⽽备份数据就是这种类型的数据。

那线上集群的数据⼜是如何同步到冷备集群的呢？

在回答这个问题前，有必要先了解⼀下快照的基本原理，因为这样才能理解后续的数据同步流程。

Hadoop在2.x版本就已经⽀持了对某个⽂件或者⽬录创建快照，可以在⼏秒内完成⼀个快照操作。在做快照前，⾸先要对某个⽬录或者⽂件启⽤快照，此时对应⽬录下⾯会⽣成⼀个.snapshot的⽂件夹。

在上图中，我们对/helloword⽬录启⽤快照，然后创建⼀个s1的备份。此时，在.snapshot下存在s1⽂件。然后我们删除/helloword/animal/lion ⽂件时，HDFS 会在animal ⽬录创建differ⽂件，并把differ⽂件关联到s1备份，最后把lion⽂件移动到differ⽬录下。

通过这个案例，我们不难发现，HDFS快照实际只记录了产⽣快照时刻之后的，所有的⽂件和⽬录的变化，⾮常适合每天只有少数⽂件被更新的数据中台，代价和成本也很低。

有了快照之后，我们就需要把快照拷⻉到冷备集群中，这⾥选择的是Hadoop⾃带的DistCp。为什么考虑DistCp 呢？因为它⽀持增量数据的同步。它有⼀个differ参数，可以对⽐两个快照，仅拷⻉增量的数据。同时，DistCp是基于MapReduce框架实现的数据同步⼯具，可以充分利⽤Hadoop分布式计算的能⼒，保证数据的拷⻉性能。

这里有⼀张详细的图，透过这张图，可以看到具体的数据从线上集群拷⻉到冷备集群的流程。

⾸先，对于第⼀次开始数据备份的⽂件，会先创建⼀个快照，然后利⽤DistCp 拷⻉全量的备份数据到冷备集群。然后后续的每⼀天，都会定时⽣成⼀个快照，并和前⼀天的快照基于distcp --differ 参数进⾏对⽐，将有更新的部分再同步到冷备集群。同步完成以后，会删除前⼀天的快照，这样就完成了每⽇数据的增量同步。

这⾥需要特别注意的是，拷⻉数据会对线上I/O 产⽣⽐较⼤的压⼒，所以尽量在任务运⾏的低峰期进⾏同步(⽐如⽩天12点到晚上24点之间的时间)，同时DistCp的bandwidth参数可以限制同步的速率可以根据I/O负载和数据同步速率，动态调整。⽐如说，I/O利⽤率100%，应该限制数据拷⻉带宽，为10MB/s。

上面了解了数据中台中中⽂件⽬录的备份，但是光这些还不够，还需要备份数据的产出任务，表相关的信息：

1. 任务的备份，要保存任务代码、任务的依赖关系、任务的调度配置以及任务的告警、稽核监控等信息；

2. 表的备份主要是备份表的创建语句。

比如产品化的解决⽅案，数据开发可以在数据管理平台上，选择⼀张表，创建备份，然后系统就会⾃动地完成任务、⽂件和表的备份。平台也提供了⼀键恢复的功能，系统会⾃动地帮数据开发创建任务和表，拷⻉数据从冷备集群到线上集群。

什么样的数据应该备份呢？

数据的备份策略应该和数据资产等级打通， 对于核⼼数据资产，数据中台应该强制进⾏备份。

那假如说，数据没有备份，但我们误删除了，还有没有其他的补救⽅法呢？

> 机制⼆：垃圾回收箱设计

---

HDFS 本⾝提供了垃圾回收站的功能，对于意外删除的⽂件，可以在指定时间内进⾏恢复，通过在core-site.xml中添加如下配置就可以开启了，默认是关闭状态。

<property>  <name>fs.trash.intervalname>  <value>1440value>property>

当HDFS ⼀旦开启垃圾回收功能后，⽤⼾通过命令⾏执⾏rm⽂件操作的时候，HDFS会将⽂件移到/user/[⽤⼾名]/.trash/current/⽬录下。这个⽬录下的⽂件会在fs.trash.interval 配置的时间过期后被系统⾃动删除。当需要恢复⽂件的时候，只需要把/user/[⽤⼾名]/.trash/current/被删除⽂件移到要恢复的⽬录即可。

但是，HDFS垃圾回收机制在实际应⽤过程中，存在重⼤的缺陷。因为它只能⽀持通过命令⾏执⾏rm操作，对于在代码中通过HDFS  API调⽤Delete接⼝时，会直接删除⽂件，垃圾回收机制并不⽣效。尤其是我们在Hive中执⾏drop table删除⼀个Hive管理表，此时删除的数据⽂件并不会进⼊trash⽬录，会存在巨⼤的安全隐患。

可以对HDFS的Client进⾏修改，对Delete API通过配置项控制，改成跟rm相同的语义。也就是说，把⽂件移到trash⽬录。对于Hive上的HDFS Client进⾏替换，这样可以确保⽤⼾通过drop table 删除表和数据时，数据⽂件能够正常进⼊HDFS trash⽬录。

通过这种⽅式，可以解决数据误删除的问题。但HDFS回收站不宜保留时间过⻓，因为回收站中的数据还是三副本配置，会占⽤过多的存储空间。⼀个配合解决⽅案是，回收站保留24⼩时内的数据。 这样解决的是数据还没来得及被同步到冷备集群，误删除的情况。对于⼀天以上的数据恢复，建议采取基于冷备集群的数据备份来恢复。

下面是如何避免敏感数据的泄露，而这离不开精细化的权限管理。

> 机制三：精细化的权限管理

---

数据权限是数据中台实现数据复⽤的前提和必要条件。如果刚开始系统没有开启权限，后期接⼊权限，任务的改造成本会⾮常⾼的，⼏乎涉及到所有的任务。所以权限这个问题，在数据中台构建之初，必须提前规划好。

⽹易数据中台⽀撑技术体系是基于OpenLDAP + Kerberos + Ranger 实现的⼀体化⽤⼾、认证、权限管理体系。

试想⼀下，如果有⼏千台机器，却没有⼀个统⼀的⽤⼾管理服务，当我们想添加⼀个⽤⼾时，需要到⼏千台服务器上去创建初始化⽤⼾，这个管理和运维的效率有多低。⽽OpenLDAP就帮我们解决了这个问题。

OpenLDAP是⼀个轻量化的⽬录服务，数据以树型结构进⾏存储，能够提供⾼性能的查询服务，⾮常适合⽤⼾管理的场景。

在OpenLDAP中，我们可以创建⽤⼾(User)和组(Group)，对于每个⽤⼾，会有唯⼀的uid，对于每个组，通过memberuid，我们可以添加⼀个⽤⼾到⼀个组中。

在大数据平台上注册⼀个⽤⼾，平台会⾃动⽣成⼀个OpenLDAP的⽤⼾，当该⽤⼾加⼊某个项⽬时，会将该项⽬对应的Group下增加⼀个Memberuid。假设在上图中，甄漂亮加⼊了da_music项⽬，那么在da_music的Group下，会增加Memberuid:1002。同理，当甄美丽加⼊某个⻆⾊时，在对应⻆⾊的Group下，也会有甄美丽对应的Memberuid。

那Hadoop⼜是怎么跟OpenLDAP集成的呢？

Hadoop可以使⽤LdapGroupsMappings同步LDAP创建的⽤⼾和⽤⼾组，这样当我们在LDAP中添加⽤⼾和组时，会⾃动同步到Hadoop集群内的所有机器上。

通过这个⽅式，就可以解决⽤⼾管理的问题了，⽽接下来要解决的就是认证的问题。在⾮安全⽹络中，除了客⼾端要证明⾃⼰是谁，对于服务端⽽⾔，同样也需要证明我是我。为了实现双向的认证，我们在⽣产环境启⽤了安全等级最⾼的，基于共享密钥实现的Kerberos认证。

说起Kerberos认证的原理，举⼀个有趣的例⼦。

为了进游乐场，⾸先需要提供⾝份证，实名购买⼀张与⾝份绑定的⻔票。在进⼊游乐场之后，每个游乐设施前，都有⼀个票据授权机器，需要刷⼀下⻔票，授权机器会⽣成⼀个该游乐设施的票据，我们拿着这个票据就可以玩这个游乐设施了。

当然，当想玩另外⼀个游乐设施的时候，同样需要刷⼀下⻔票，⽣成对应游乐设施的票据。⽽且⻔票是有有效期的，在有效期内，可以尽情地玩游乐设施，⼀旦超过有效期，就需要重新购买⻔票。

Kerberos认证与上⾯这个故事类似，在上⾯的故事中，TGT(Ticket-granting ticket)可以看作是⻔票， Client⾸先使⽤⾃⼰的密钥⽂件Keytab和⽤⼾标识Principal去认证服务器(AS)购买TGT，认证服务器确认是合法的⽤⼾，Client会获得TGT，⽽这个TGT使⽤了TGS(Ticket-granting service)的Keytab加密，所以Client是没办法伪造的。

在访问每个Server前，Client需要去票据授权服务(TGS)刷⼀下TGT，获取每个服务的票据(ST)，ST使⽤了Client要访问的Server的Keytab加密，⾥⾯包含了TGS 认证的⽤⼾信息，Client是⽆法伪造ST的。

最后基于每个服务的票据，以及客⼾端⾃⼰⽣成的加密客⼾认证信息(Autenticator)访问每个服务。每个Server都有归属于⾃⼰的Keytab，Server只有使⽤Server⾃⼰的Keytab才能解密票据(ST)，这就避免了Client传给了错误的Server。

与此同时，解密后票据中包含TGS认证的客⼾信息，通过与Authenticator 中Client⽣成的客⼾信息进⾏对⽐，如果是⼀致的，就认为Client是认证通过的。

⼀般在Hadoop中，会使⽤Kinit⼯具完成TGT的获取，TGT⼀般保存24⼩时内。Kerberos对于Hadoop集群来说，是⼀个⾮常安全的认证实现机制，推荐使⽤Kerberos 实现Hadoop集群的安全认证。

Kerberos 使⽤的是Principal标识⽤⼾的，它⼜是怎么和OpenLDAP中的⽤⼾打通的呢？其实我们访问HDFS，使⽤的是Principal，Hadoop可以通过配置hadoop.security.auth_to_local，将Principal 映射为系统中的OpenLDAP的⽤⼾。⽤⼾注册时，平台会为每⼀个新注册的⽤⼾⽣成Principal以及相对应的Keytab⽂件。

认证完成之后呢，就要解决哪些客⼾可以访问哪些数据的问题了。推荐使⽤Ranger来解决权限管理的问题。

为什么要选择Ranger呢？因为Ranger提供了细粒度的权限控制(Hive列级别)，基于策略的访问控制机制，⽀持丰富的组件以及与Kerberos的良好集成。权限管理的本质，可以抽象成⼀个模型：“⽤⼾-资源-权限”。

数据就是资源，权限的本质是解决哪些⼈对哪些资源有权限。

在Ranger中，保存了很多策略，每⼀个资源都对应了⼀条策略，对于每个策略中，包含了很多组许可，每个⼀个许可标识哪个⽤⼾或者组拥有CRUD权限。

权限的申请流程是什么样⼦的呢?

在数据中台中，每⼀张表都有对应的负责⼈，当我们在数据地图中找到我们想要的数据的时候，可以直接申请表的访问权限，然后就会发起⼀个权限申请的⼯单。表的负责⼈可以选择授权或者拒绝申请。申请通过后，就可以基于我们⾃⼰的Keytab访问该表了。

另外，需要特别强调的是，由于数据中台中会有⼀些涉及商业机密的核⼼数据，所以数据权限要根据数据资产等级，制订不同的授权策略，会涉及到不同的权限审批流程，对于⼀级机密⽂件，可能需要数据中台负责⼈来审批，对于⼀般的表，只需要表的负责⼈审批就可以了。

> 机制四：操作审计机制

---

进⾏到第三步，权限控制的时候，其实已经⼤幅降低了数据泄露的⻛险了，但是⼀旦真的出现了数据泄露， 我们必须能够追查到到底谁泄露了数据，所以，数据中台必须具备审计的功能。

由于⽤⼾每次访问数据，都要对权限进⾏验证，所以在校验权限的同时，可以获取⽤⼾访问表的记录， Ranger⽀持审计的功能，⽤⼾的访问记录会由部署在各个服务(HDFS，HBase等等)上的插件推送到Audit Server上，然后存储在Solr中，Ranger提供了API接⼝查询表的访问记录。但是必须指出的是，Ranger开启Audit 后，会对服务内的插件性能产⽣影响。

除了敏感数据泄露的⻛险，我还看到⼀些企业想要对开发和⽣产环境进⾏物理隔离。为什么企业会有这个诉求呢？

⾸先，很多传统公司的数据开发都是外包⼈员，从企业的⻆度，不希望数据开发直接使⽤⽣产环境的数据进⾏测试，从安全⻆度，他们希望⽣产和测试从物理集群上完全隔离，数据脱敏以后，给开发环境进⾏数据测试。

其次，涉及⼀些基础设施层⾯的组件升级(⽐如HDFS、Yarn、Hive、Spark等)，贸然直接在⽣产环境升级，往往会造成兼容性的事故，所以从安全性的⻆度，企业需要有灰度环境，⽽⽤开发环境承担灰度环境的职能，是⼀个不错的选择。

最后，虽然可以为⽣产和开发环境设置不同的库和队列，从⽽实现隔离，避免开发任务影响线上任务和数据，但会导致任务上线需要改动代码，所以最理想的，还是实现开发和⽣产环境两套集群，同⼀套代码，在开发环境对应的就是开发集群，提交上线后，就发布到⽣产集群。

这些就是企业希望开发和⽣产集群物理隔离的原因，接下来看⼀看该如何满⾜。

> 机制五：开发和⽣产集群物理隔离

在⾯对这个需求时，我们遇到了两类完全不同的企业群体。

⼀部分来⾃传统企业，尤其是⾦融⾏业，他们对安全性的要求远⼤于对效率的诉求，严格禁⽌数据开发使⽤线上数据进⾏测试，他们希望有两套完全不同的环境，包括操作平台，任务在开发环境进⾏开发，配置任务依赖，设置稽核规则和报警，然后由运维⼈员进⾏审核后，⼀键发布到⽣产环境。当数据开发需要对数据进⾏测试时，可以同步⽣产环境的局部数据(部分分区)，数据会进⾏脱敏。

上图是该模式下的部署架构。

通过这张图我们可以看到，开发和测试环境本⾝是两套完全独⽴的平台，因为每次数据测试，都需要同步⽣产环境的数据，所以这种模式下，数据开发的效率会有⽐较⼤的影响，但是优势在于对数据安全实现了最⾼级别的保护。

与这部分客⼾不同的是，很多企业需要同时兼顾安全和效率，他们没有办法接受同步⽣产环境数据，⽽是需要在开发环境能够直接使⽤线上的数据进⾏测试。

上图展⽰了该模式下的部署架构。

⼤数据平台和任务调度系统(Azkaban)都是⼀套，然后Hive，Yarn和HDFS都是两套，两套集群通过Metastore共享元数据。

这样做的⼀个好处在于，⼀个集群的Hive可以直接访问另外⼀个集群的数据。在同⼀个Metastore中，开发环境的数据在_dev库中，⽣产环境的数据在_online库中，⽤⼾在代码中不需要指定库，在任务执⾏时，根据运⾏环境，⾃动匹配库。例如在开发环境执⾏，Hive默认会使⽤_dev库下的表，⽽在⽣产环境执⾏，Hive默认会使⽤_online库下的表，从⽽实现了不需要改代码可以实现⼀键发布。

上⾯两种部署模式，可以根据所在的企业实际情况进⾏选择，对安全性要求⾼，推荐第⼀种⽅案，对于效率要求⾼，同时兼顾⼀定的安全性，就推荐第⼆种⽅案。

> 总结

---

总的来说，介绍了解决数据中台安全问题的五⼤制胜法宝，相信通过这些保障机制，可以解决数据中台遇到的安全问题了。最后重点：

1. 数据备份要同时兼顾备份的性能和成本，推荐采⽤EC存储作为备份集群的存储策略；

2. 数据权限要实现精细化管理，基于OpenLDAP+Kerberos+Ranger可以实现⼀体化⽤⼾、认证、权限管理；

3. 开发和⽣产环境物理隔离，提到了两种部署模式，需要综合权衡效率和安全进⾏选择。

思考

---

引⼊权限管理，势必会对数据研发效率产⽣影响，同时已有的任务必须重构，进⾏认证改造。如何思考安全和效率之间的优先关系？

HDFS EC 存储介绍：

https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HDFSErasureCoding.html

在进⾏权限管理时，先构建权限体系，再按照资源本⾝的重要性和价值进⾏。特别是对于⼀些维度表，往 往包含⽐较敏感和丰富的信息。也可以从平台或者⼯具上⼊⼿尽可能透明化，降低权限对开发的影响。其 实，注意影响还是在前期投⼊如何解决好改造和开发新需求之间⽭盾。可以通过类似灰度发布的做法，逐步改造迁移。

引⼊权限管理，肯定会影响研发效率的。最好在项⽬开始前就引⼊。任务上线后再加⼊权限，要在开发环 境严格测试，否则可能会任务因权限不⾜报错。

往期推荐：

交付速度和质量问题解决了，⽼板说还得“省”

今天的数据怎么又不对？！

数据模型⽆法复⽤，归根结底还是设计问题

数据仓库、数据湖、流批一体，终于有大神讲清楚了！

如何统⼀管理纷繁杂乱的数据指标？

项目管理实战20讲笔记(网易-雷蓓蓓)

元数据中⼼的关键⽬标和技术实现⽅案

Hive程序相关规范-有助于调优

HBase内部探险-数据模型

HBase内部探险-HBase是怎么存储数据的

HBase内部探险-一个KeyValue的历险

数据中台到底怎么建设呢？

到底什么样的企业应该建设数据中台？

数据中台到底是不是大数据的下一站？