Code speaks.

昨天和项目组的几个小伙伴去爬山。这次爬山坐标深圳梧桐山。从西北门进山，我们沿着蜿蜒的公路一路而上，历时三小时登顶。下山时不想原路返回，故意选了另一条路。从山上往下看，这条路陡峭得很。不过，对于几个血气方刚的男性，这条路正好。因为大家都觉得上山太简单不过瘾，想挑战一下高难度。于是我们一致同意换路而行。我们走的这条路就是凌云道。

说起凌云道这条路，真是名副其实。它不仅几乎呈垂直高度下降，而且台阶较窄仅有半脚宽。路两边树丛虽然茂盛，但是都不高大，山下的情形总是能进入眼帘。我一向有点恐高，在这垂直高度近1千米地方往下看，还真是心里有点慌。刚开始下山，小伙伴们见此山势，纷纷停下脚步拍照。得几张无P图片如下，大家可以感受一下：

系列文章：

• Hadoop安全认证机制 (一)
• Hadoop安全认证机制 (二)
• Hadoop安全认证机制 (三)

前面的文章中，我们搭建了一套安全的hadoop集群，并建立了一个对应的测试。结合相关的基础知识，我们应该对安全的hadoop集群有了一定的认识。本文主要关注如何将大数据其他组件安全地与hadoop进行集成。我们将关注这几个组件：hive hbase spark livy。

hive

首先来看hive，hive是最初由facebook发起的基于hadoop大数据架构的数据仓库。hive直接将hdfs变为了一个支持sql的数据存储。时至今日，hive已成为企业大数据最基础的组件之一，各种上层的组件均和hive有良好的集成。

采用跟之前同样的思路，我们先来建立一个测试，如下：

进门，双手帮你脱下外套，挂起。洗发师双手提起一件深色防水的丝质套衫，你伸手，换上。拿起腰带，穿过你的腰，两圈，拉扯一次，拉扯两次，系紧。抹平套衫肩部，拉住袖口，拉扯一次，拉扯两次，展平。拉住套衫底部，拉扯一次，拉扯两次，拉齐。

将你带到洗头处，你看到一个用于平躺的台面，台面上深色皮质的垫子分为两部分，前面部分可拆卸，上放一块叠起来的深蓝色毛巾，毛巾上面是一朵颜色鲜艳的大荷花。在台面前部放有一个与垫子同样深色皮质的单人凳。

洗发师伸开右手，将你迎向凳子坐下。介绍洗头服务：我是37号洗发师为您服务，本次洗发50分钟，请您稍坐，我去准备毛巾和其他用品。

系列文章：

• Hadoop安全认证机制 (一)
• Hadoop安全认证机制 (二)

前面的文章中我们分析了Hadoop安全机制中用到的协议及相关源代码实现，这一篇文章我们主要来看看如何搭建一套安全的Hadoop集群。

简单起见，我们这里的集群所有的组件将运行在同一台机器上。对于keytab的配置，我们也从简，只配置一个kerberos的service账号供所有服务使用。

建立测试用例

TDD是敏捷最重要的实践之一，可以有效的帮助我们确定目标，验证目标，它可以带领我们走得又快又稳。跟随TDD的思想，我们先从测试的角度来看这个问题。有了前面的基础知识，假设我们已经有了一套安全的Hadoop集群，那么我们应当可以从集群读写文件，运行MapReduce任务。我们可以编写读写文件的测试用例如下：

在上一篇文章中，我们分析了Kerberos协议的设计和通信过程。可以了解到，Kerberos主要实现了不在网络传输密码的同时又能在本地进行高性能鉴权。由于kerberos的协议设计相对复杂，看到评论有人还有疑问，这里再举一个例子来分析一下kerberos的安全性。

Kerberos协议回顾

假设有三个组件A B C，A想和C进行安全通信，而B作为一个认证中心保存了认证信息。那么以以下的方式进行通信就可以做到安全：

1. A向B请求说要访问C，将此消息用A的秘钥加密之后，发给B
2. B验证A的权限之后，用A自己的秘钥加密一个会话密码，然后传给A
3. 同时B还向A发送一个A自己不能解密，只能由C解密的消息
4. A在解密会话密码之后，将需要和C通信的消息（业务消息）用这个会话密码加密然后发给C，同时A需要将B发给A而A又不能解密的消息发给C
5. C在拿到消息之后，可以将第三步中的消息解密，得到会话秘钥，从而可以解密A发过来的业务消息了

安全无小事，我们常常要为了预防安全问题而付出大量的代价。虽然小区楼道里面的灭火器、消防栓常年没人用，但是我们还是要准备着。我们之所以愿意为了这些小概率事件而付出巨大的成本，是因为安全问题一旦发生，很多时候我们将无法承担它带来的后果。

在软件行业，安全问题尤其突出，因为无法预料的事情实在太多了。软件的复杂性让我们几乎无法完全扫清安全问题，模块A独立运行可能没问题，但是一旦和模块B一起工作也许就产生了安全问题。

不可否认为了让软件更安全，我们引入了很多复杂的机制。不少人开发者也抱怨为了进行安全处理而做了太多额外的事情。在一个复杂的分布式软件Hadoop中，我们为此付出的成本将更大。比如，我们可能可以比较轻松的搭建一个无安全机制的集群，但是一旦需要支持安全机制的时候，我们可能会付出额外几倍的时间来进行各种复杂的配置和调试。

Hadoop在开始的几个版本中其实并没有安全机制的支持，后来Yahoo在大规模应用Hadoop之后，安全问题也就日益明显起来。大家都在一个平台上面进行操作是很容易引起安全问题的，比如一个人把另一个人的数据删除了，一个人把另一个人正在运行的任务给停掉了，等等。在当今的企业应用里面，一旦我们的数据开始上规模之后，安全机制的引入几乎是必然的选择。所以作为大数据领域的开发者，理解Hadoop的安全机制就显得非常重要。

Hadoop的安全机制现在已经比较成熟，网上关于它的介绍也很多，但相对较零散，下面我将尝试更系统的，并结合实例代码，给大家分享一下最近一段时间关于Hadoop安全机制的学习所得，抛个砖。

预计将包括这样几个方面：

1. Kerberos协议介绍及实践
2. Kerberos协议发展及Hadoop相关源码分析
3. Hadoop安全集群搭建及测试
4. 周边工具的安全支持

《重构–第二版》在我的书单里面待了好长一段时间了，趁着放假有时间读了一遍。这本书作为我司首席科学家老马的大作，同时又有大熊和林丛羽的翻译加持，值得每个人认真的反复的学习。

重构作为敏捷实践的精髓之一，在我们这个以敏捷为立身之本的公司里应当属于大家信手拈来的基本技能了。虽然说重构的基本思想长期不过时，但是第一版《重构》毕竟已经是20年前的事情了，20年以来软件开发行业兴起了无数新的编程思想、语言、工具、框架等，现在回过头去看第一版，会发现不仅纸质书籍难以买到，而且知识上也总觉得有点脱节。新版本以JavaScript语言作为示例，重新思考并改进了第一版本中的众多重构手法，结合了多年来一些新的观点和思考，带给了我们一套更为丰富完善的重构体系。

通读一遍本书，很多让我产生共鸣的地方，同时本书让我对于我们日常的一些实践有了新的看法，对于我们经常讨论的一些问题也有了新的结论。下面想摘录一些重要的观点，并分享几点我的理解，与大家一起学习。

有一个技术人员都知道的很老的段子。如果我们想将一个技术论坛搞火起来，那么我们只需要发一篇帖子“php是世界上最好的语言”。虽然是很老的段子，但是就算现在我也常常能听到有人谈论它。很有意思的一个段子。

不仅仅是在论坛中，在我们日常的团队合作中，其实也常常有这样的事情。回忆一下我的 Code Review 活动，是不是常常有某一行代码引起了大家的广泛讨论，把整个会议给“搞火”了？大家可能就一个问题讨论很久，争执不下。

对于这样的讨论，如果大家能心平气和，互相理解，可能能较快的达成一致。但是事实上常常会出现这样的情况，双方争论很久争执不下，后来可能有人说，“这你都不知道啊”，或者“这我理解不了，你这里明显有问题”，或者“你说的都好，我用我的方式”，或者“你这里就明显是在#define true=false”等等。在这样的讨论中，我们比较容易情绪化（可能没有情绪化这么严重，但是这里姑且先用这个词），最后本来应该心平气和的讨论演变成了针对某个个人的互怼，或者直接拒绝交流。一旦情况变成这样，那么不仅讨论效率会大大下降，而且常常在相互心中产生芥蒂，影响后面的高效合作。

我时常在项目中听到一些经验稍欠缺的开发人员在Code Review时这么讲：

这里为了方便测试我抽取了一个纯函数，这个函数包含了主要的业务逻辑，测试覆盖率也比较高，我们可以认为这一部分质量不错。
使用这个函数的地方由于集成度高不好测试，我们就不做自动化测试了。

他的代码可能写成下面这样：

1
2
3
4
5
6
7
8
9
10

// some_file.ts
function someEasyToTestMethod() {
    ...
}

class A {
    someMethod() {
        someEasyToTestMethod();
    }
}

在文章开始之前，我们先回顾一下TDD带来的好处。当我们理解TDD之后我们至少会发现下面这三点：

1. TDD是一种更加自然的编程方式，因为我们总是要先弄清需求再编写代码，而这跟TDD先写测试（通过测试清晰的定义需求）再写实现的顺序是完全一致的。
2. 先写测试还要求我们站在使用者的角度来编写测试，这样我们可以自然的驱动出来更好的设计。
3. 由于TDD天然的特性，测试在编写代码之前就有了，自然我们也就无需担心测试覆盖率不够带来的质量问题了。

TDD给我们编写代码带来的好处多多，我前面有一篇文章主要分析了如何从改善设计的角度理解TDD，相信大家能感受到TDD给改善程序设计带来的好处。这里我想再次分享一个用TDD改善设计的例子，我们将从中看到不用TDD时我们的代码可能会变成什么样，而用了TDD又将变成什么样。