好吧，停止广告，daocloud再好，也不给我发钱，真是的。

这里就介绍一下我最简单的一个docker-tomcat容器。

首先在我的linux机器上安装docker：

安装教程特别多，随便可以找到，我的本地环境是64位的centos7.0，所以安装就被简化为：

Sudo yum install docker

这么一句话了。

docker的核心思想是everything is container，docker运行的就是一个个的容器，而容器是用户完全自定义的镜像，我个人认为最灵活的就是写一个dockerfile（我理解就算一个镜像了），然后把它build为镜像并run，一个可用的容器环境就完全起来了。

步骤：

1，创建一个项目，最好在git上

2，写Dockerfile文件，描述你的镜像

3，docker build

4，docker run

这样就好了。

于是，以我个人的项目为例：

1，创建项目：https://github.com/changedi/mydocker

2，编辑Dockerfile：https://github.com/changedi/mydocker/blob/master/Dockerfile

3，在本地项目中运行docker build <image_name> .，build一个自定义名字的镜像

4，启动这个镜像容器：docker run -d -p 80:80 <image_name>

这样，这个镜像就好了，服务也起来了，后续可以通过docker ps来查看启动的镜像，通过docker stop来停止容器。

我这里解释一下我的Dockerfile：

  1 # Using a compact OS

主要做几件事：

1，拉个操作系统：这里是Ubuntu

2，装工具：curl、jdk、tomcat、nginx，配置环境变量，配置tomcat，配置nginx（tomcat和nginx的配置都是本地搞好，直接add）

3，部署应用（自己的war包），这里我直接利用docker的ADD操作，把git项目中的文件直接add到容器中

参考资料：

1，docker安装 http://www.linuxidc.com/Linux/2014-12/110034.htm

2，dockerfile编写 http://blog.csdn.net/we_shell/article/details/38445979

dump文件包含的内容：

1，全部的对象：类，域，原生值和引用；

2，全部的类：classloader，类名，超类，静态域；

3，GC root：被JVM定义的可触达的对象；

4，线程栈和本地变量：线程的call stack，本地对象每帧的信息。

dump文件不包含内存的分配信息，因此无法查询谁创建了哪个对象这样的信息。

Shallow heap是一个对象占用的内存空间，一个对象需要32或者64bits。

Retained set of X是X在被jvm gc回收后被remove的一组object。

Retained heap of X是在retained set of X中的所有对象的shallow heap size的和。换句话说就是保持X活着需要的内存空间。

通俗的讲，shallow heap是一个对象在内存中的实际空间，而retained heap是一个对象被gc回收后内存释放出来的空间。

这张图可以看懂什么是leading set什么是retained set。

Dominator tree：定义一个对象x dominate 对象y，当每一条从root开始到y的路径都经过x。说白了就是只要有y对象的存活，那么一定会有一个x对象。Dominator tree就是将对象引用图转换成的树形结构。帮助发现在对象间保持alive的依赖，同时也能识别出retained内存的最大的chunk。Immediate dominator x of y是离y最近的dominator。

Dominator tree有几个属性：

1，对象x的子树包含的对象（x dominate的对象集），代表了x的retained set；

2，如果x是y的immediate dominator，那么x的immediate dominator同样dominate y，以此类推；

3，dominate tree中的边不代表对象引用图里对应的边，并非严格的直接的对象引用。

这张图反应了一个对象引用图转换成dominator tree的示例。

Gc root：一个gc根就是一个对象，这个对象从堆外可以访问读取。以下一些方法可以使一个对象成为gc根。

1，System class：被bootstrap或者system类加载器加载的类，比如rt.jar里的java.util.*；

2，JNI local：native代码里的local变量，比如用户定义的JNI代码和JVM的内部代码；

3，JNI global：native代码里的global变量；

4，Thread block：当前活跃的线程block中引用的对象；

5，Thread：已经启动并且没有stop的线程；

6，busy monitor：被调用了wait()或者notify()或者被synchronized同步的对象，如果是synchronized方法，那么静态方法指的类，非静态方法指的是对象；

7，java local：local变量，比如方法的入参和方法内创建的变量；

8，native stack：native代码里的出入参数，比如file/net/IO方法以及反射的参数；

9，finalizable：在一个队列里等待它的finalizer 运行的对象；

10，unfinalized：一个有finalize方法的对象，还没有被finalize，同时也没有进入finalizer队列等待finalize；

11，unreachable：不会被触碰到的对象，在MAT里被标记为root用来retain object，否则是不会在分析中出现的；

12，java stack frame：java栈帧包含了本地变量，当dump被解析时且在preferences里设置过把栈帧当做对象，这时才会产生；

13，unknown：位置的root类型。

接下来是一些获取dump的方法：

1，在oom时dump：JVM参数：-XX:+HeapDumpOnOutOfMemoryError

2，交互式环境下dump：

1）JVM参数：-XX:+HeapDumpOnCtrlBreak

2）用外部tools：jmap -dump:format=b,file=<filename.hprof> <pid>

3）用外部tools：jconsole

4）用外部工具：MAT

5）kill -3 <pid>

6）jstack -l <pid> > <dumpfile>

一些排查方法：

1，通过top consumers查找大对象，可以按照class、classloader和package进行group by；

2，通过immediate dominator找到责任对象，对于快速定位一组对象的持有者非常有用，这个操作直接解决了“谁让这些对象alive”的问题，而不是“谁有这些对象的引用”的问题，更直接高效；

3，运行classloader分析，这个重要性体现在亮点：第一，应用使用不同的classloader加载类，第二，不同classloader加载的类存储在不同的永久代，这理论上也是可以被回收的。当有一个类被不同的classloader加载时，这时要根据各自loader下的instance数量判断哪个loader更重要，从而要把另一个回收掉；

4，分析线程，本身heap dump里包含了thread信息，可以通过MAT来查看threads 的overview和detail，detail中有线程的堆内存信息，也有线程栈，同时还包含了操作系统本地栈。假设不做heap dump，我们检查到系统有问题，如何通过线程的角度来排查呢？首先top -H -p <pid>以线程的模式查看java应用的运行情况，找到占用cpu或者内存大的线程，记录线程id，然后printf %x <tid>转为16进制，再jstack -l <pid> > thread.log把java进程的thread dump出来，从里面找到tid，分析是哪个线程占用了系统资源。

5，分析java容器类，因为java的容器类是最常用来存储对象的，所以理论上发生内存泄露的风险也最高。可以从几个角度来看：1）array填充率查询（填充率fill ratio是数组中非空元素的比例），打印非原生类型数组的填充率频率分布，从而排查系统中array的利用率；2）数组按照size分组查询，打印一个按size分组的直方图；3）collection的填充率查询，ArrayList/HashMap/Hashtable/Properties/Vector/WeakHashMap/ConcurrentHashMap$Segment；4）collection按照size分组直方图；5）查看一个list里的所有对象；6）查看hashmap里的所有对象；7）查看hashset里的对象；8）检查map的碰撞率；9）检查所有只有一个常量的array。

6，分析Finalizer，1）查询finalizer正在处理的对象；2）查询finalizer准备处理的对象；3）直接查看finalizer线程；4）查看finalizer线程的thread local对象。

        几乎每个Java程序员都清楚知道Java的异常和错误机制，无论是在面试过程中，还是在学习中，你看到Exception，无非就是了解一下继承关系、子类、和Error的关系等等。当然这些知识点是基础，那么在实践中，用到了吗？你确定你使用Exception时没有偷懒？我的经验告诉我，良好的使用Exception能让你的程序bug更少，或者至少能保证你的程序更容易被理解和跟踪。

        先回到老的知识点吧——Java的异常机制，我们知道Java里的异常是完全继承Throwable的，正如java doc里注释的，无论你throw的还是JVM throw的，抑或是你想catch的，都必须继承Throwable。我这里帮助大家纠正的第一个点就是：java.lang.Throwable是一个class，不是一个interface，千万别被名字欺骗。优秀的程序员有好的命名习惯，当Java程序员默认认为带有-able后缀的都该是接口时， Josh Bloch给大家上了一课——Throwable就是类。回到正题，Throwable有两大子类，一个是java.lang.Error，一个是java.lang.Excpetion，Error是错误，一般多用于系统异常和底层错误，Error抛出就会导致程序终止；而Exception是异常，有程序引起，又分为受检的checked和非受检的unchecked（不知道哪本书这么翻译的来着），受检的异常是普通异常，就是你需要catch的来打日志或者补救的（这种做法叫吞掉异常），非受检的多数是RuntimeException，就是运行时异常，这类异常不建议catch，因为这个是程序bug，需要被人发现，所以建议抛出引起程序终止。Blah~blah~ 这些都是老生常谈的话题，需要深入的点是有几个：

        第一，Error是建议到系统级别的错误的，包括虚拟机的，我们常见的就是java.lang.VirtualMachineError，这是一个JVM级别的抽象Error，如果你觉得没见过？那么不用奇怪，它的两个儿子你肯定见过：OutOfMemoryError和StackOverflowError。Error其实真没好说的，一般情况不建议捕获，程序员也用的较少，但是你看很多基础框架或者系统软件，都是有自定义Error的，所以当你的工作层次或者范围你能确定比较底层时，其实是可以自定义一些Error来控制程序的错误的。我这样说可能也不是很好理解，换个简单的话：你的架构设计中需要考虑到异常的处理，那么首先要对异常定级别，如果有可能有偏底层的异常时，或者是本不该出现且不建议用户（多数是依赖你的库进行开发的其他程序员）捕获时，定义为Error是个不错的选择。当然也不是说做上层开发的程序员就不能使用Error，只要你设计合理，你可以在必要时抛出Error来终止程序——比如提醒你的老板再不加薪就Error到死：）

        第二，Exception分两类这事几乎人人皆知，受检的异常往往是web后端开发或者服务开发自定义的业务异常比如BizServiceException或者常见的DAOException，这些异常在开发定义时总是直接extends Exception，而忽视了究竟这些异常我们对它们的期望是什么，这里我想强调一点，我们在业务系统架构中考虑到异常机制，自定义的异常不是为了有异常而定义异常，一定对它本身是有期望的。我们对异常的一个基本期望是异常究竟该被谁捕获，如果被你的服务下游捕获，那么这必须是一个受检的异常，如果是系统自身需要，那么这个我个人认为是分阶段设计的，在初期，也就是未发布状态，这些Exception应该总是被抛出的，因为这样可以快速的让测试和质量控制人员发现系统崩溃的点。在发布阶段，异常可能需要被内部消化，这时受检异常就要提供给业务系统，让业务开发自行捕获异常。当然，好的系统架构可能会把Exception作为一个内部可见外部不可见的内容，而基于此完全封装一套error code对外，这应该算是比较友好的做法了，也是很多API设计时的标准规范。毕竟对外部透明，不要让用户看到你的Exception，这是非常友好的做法。

        第三，关于catch，就针对上面的第二点讲，吞异常这事不是没人干过，我们往往担心系统错误而一个try catch 捕获所有Exception，有的甚至不够，还升一级，捕获Throwable，这应该是最糟糕的代码设计（但不幸的是在我现在开发的系统和曾经开发过的业务系统中，这类代码非常普遍）。开发人员不应该因为时间紧、赶进度等接口而忽视Exception，就拿最上层的业务开发举例，开发可能会调用各类服务、访问数据库、访问缓存和文件系统等等，而这些服务必然包含了各种异常，而catch一个Exception，试图通过吞噬异常保护系统或者页面正常访问，而打日志到后台，通过分析日志来偷偷的解决bug……说起来真是汗毛倒竖。我的观点：如果有错误，那么让它尽早暴露出来，我们应该通过尽量多的测试和优化来避免错误，而不是偷偷的隐藏。事实也证明，日志里大量的NPE或者其他RuntimeException存在，但是无人问津，“系统不是好好的吗？”，“页面不是没问题吗”这样的说辞可以让开发看起来毫无责任，但是这为系统长期的维护和后续的扩展都带来了无尽的烦恼和坑。

         综上，我个人的经验告诉我几点对待Exception的方法：

        1，花时间了解涉及到的每个服务和方法所可能抛出的异常。事实往往是理解异常的关系和机制其实不花时间，了解后再开发，你会比别人知道更多的异常点，这能保证你程序的健壮性；

        2，无论你在服务开发还是服务使用层级，都要尝试或者想到封装异常，提供友好错误设计的方案，最简单的是自定义一个业务Exception来封装。

        3，不要在你的方法开始try，结束时catch，这防御性太强了，很美品位。

        4，前三点可能都是错的，因为我自己也没有完全实践：）

        苦逼用来形容自己，是稍显偏颇了，2014虽然经历了两拨996的洗礼（年初和年末），但是技术成长确实没有想象的多，工作四年来，两年时间用来做web的后端开发，从spring、webx的源码，到慢慢深入到一些数据库中间件的使用ibatis和tddl（淘宝内部）、消息中间件metaq（淘宝内部）、服务框架HSF和其他的整个后端相关的内容，大概理解了一遍所有backend后，团队缺前端的状况逼的自己开始做frontend，使用jquery和kissy（brix），使用bootstrap，开发自己的基于raphaeljs的vnix数据绘图框架等等，对前端的正常业务开发也基本熟练。回顾2013年的总结，发现自己去年就开始有些负面情绪了，虽然接触了storm开发，正常时间写hive和odps的sql，开发数据报表，但是这些工作对于技术的直接提升并不明显。在无线反作弊领域做两年了，整个反作弊的设计架构也从最开始的统计分析发展到机器学习后来又逐渐变为混合模式，也算经历了三代的演变。乐观的审视自己这4年的蜕变，技术上的提升最大还是在2-3年的时候，现在的很多认知提升，都慢慢的转到了架构设计和团队管理，慢慢的自己开始不断挑刺了，我一直不理解我这种变化的原因究竟是什么，开始不满团队的管理模式，经常设想如果自己来干，哪些地方该优化该改进；开始不满产品的技术架构；开始不满团队成员的“不够优秀”。

         回家过了个年，胡吃海喝后，自己开始熟悉原来身边的环境，也开始能看到自己内心去了。你要做成功一个事情，这是之前在阿里巴巴的一个承诺。其实这是很难的，不仅是阿里，你在哪家大公司都很难。那么发泄不满是最低效最没有品位的做法，你只能让身边的人知道你不满，但这重要吗？The thing is to acitvate them。一个卓越的人，首先要能包容自己对身边的不满，我们不乱发泄，我们沟通，我们建设。要做成一件成功的事，不是要和一个完美的团队配合，而是要能配合出一个完美的团队。能容别人所不能容，能帮助别人成就别人。

        2014整个一年我自己总结就是懒惰的一年，这一年，我没怎么读过书，没怎么关注过新技术，没怎么写过有趣的代码，反而还经常玩手游，跟人诉苦水，传播负能量。人生苦短，在即将30岁的时候，我却开始纠结一些芝麻绿豆的事情，工资高低啦，晋升啦？These all shit。新的一年，自己要有远大的目标，我一定要做成一个事情，而为了这个目标，要持续学习、读书。记得小时候，每到寒暑假，都会把整个假期及未来学期的计划写清楚，虽然那时很幼稚，计划总是什么几点睡觉，几点起床，读哪几本书之类，但是这种习惯，在我们长大后却逐渐褪去了，我们成了没有目标的混日子的混子。想起Fenng之前的一篇文章，讲大公司的混子，还真别说，大公司最多的就是混子。

        不要拘泥于要成为什么样的人，只要知道你要做成什么事就够了，因为只要你努力为这个目标奋斗，你就会成为一个能做成这个目标的人。That's enough。

181题又是一个简单题目，给定一个Employee表，里面存储了雇员的工资信息，包括名字、工资、经理ID，题目要求写一个sql查找出所有那些自身工资比经理还高的雇员的名字。

+----+-------+--------+-----------+
| Id | Name  | Salary | ManagerId |
+----+-------+--------+-----------+
| 1  | Joe   | 70000  | 3         |
| 2  | Henry | 80000  | 4         |
| 3  | Sam   | 60000  | NULL      |
| 4  | Max   | 90000  | NULL      |
+----+-------+--------+-----------+

这个题目很简单，现有表不能做就是因为现有的一行记录里没有包含经理的工资信息，但是有经理的ID，那么我们做一下关联，把工资信息拿到，再过滤就好了，于是思路sql如下：

其中s是自己的工资，m是经理的工资~~一目了然

182题目地址：https://oj.leetcode.com/problems/duplicate-emails/

182也是Easy级别题目，题目描述就是写一个sql，把Person表中有重复Email的记录拉出来。

+----+---------+
| Id | Email   |
+----+---------+
| 1  | a@b.com |
| 2  | c@d.com |
| 3  | a@b.com |
+----+---------+

很容易想到的思路：按照email做聚合，把count>1的取出来，对应sql如下：

183题目地址：https://oj.leetcode.com/problems/customers-who-never-order/

183题，一个网站包含两张表，一张Customers表存放客户数据，一张Orders表存放产生订单的客户ID，题目要求写sql查出没有在网站产生过订单的客户。说白了就是查询在Customers里而不在Orders里的数据，sql如下：

3个简单题目，夯实sql基础~~

这个题目是要求写一个sql，查询出表中连续出现三次的记录。表结构非常简单如下：

+----+-----+
| Id | Num |
+----+-----+
| 1  |  1  |
| 2  |  1  |
| 3  |  1  |
| 4  |  2  |
| 5  |  1  |
| 6  |  2  |
| 7  |  2  |
+----+-----+

这个Logs表里，只有Id和Num字段，而题目就是要找出连续出现3次的Num，对于这个表，答案就是1了。

思路很直观暴力的一个想法就是Logs表自己关联3次，关联条件依次是Id+1，这样就可以把连续记录关联出来了

我的代码如下：

这个题目虽然可以这样解掉，但是很自然的会联想，如果3变成n呢，题目变为求连续出现n次的记录，那该如何解？显然暴力解法是不可行的。鉴于能力有限，我从discuss区找到了一个很赞的解法，通过定义变量，很巧妙的解了这个扩展的问题，原作者kent-huang

代码如下：

简单分析一下，作者通过定义两个变量record和count来控制记录和对应的rank值，首先通过一个select @count:=0,@record:=(SELECT num from Logs limit 0,1)语句来初始化这两个变量count=0，record=表里第一条记录的num。接下来通过普通查询，将Logs表里每一条记录查出来，和record对比，如果相同，则count自增1，如果不同，那么新的record被赋值，同时count置1，很漂亮的自定义变量用sql实现了我们直觉上需要用逻辑代码来完成的功能。而且这个代码的一大优势是不需要用到Id字段~~非常棒

还有好的思路，请一定分享给我~~:)

这个问题很有趣，写一个类似oracle里的窗口函数rank()，具体描述一下，有一张数据表Scores，里面有两个字段Id和Score，具体结构如下：

+----+-------+
| Id | Score |
+----+-------+
| 1  | 3.50  |
| 2  | 3.65  |
| 3  | 4.00  |
| 4  | 3.85  |
| 5  | 4.00  |
| 6  | 3.65  |
+----+-------+

任务是要写一个sql来给Score字段打一个rank标识，条件是按照Score从大到小排序，相等情况时rank相同，且rank之间没有“洞”，即rank字段是连续值。显然这个任务比rank窗口函数容易一些，但是也是一个棘手的问题。

题目具体给出了输出示例：

+-------+------+
| Score | Rank |
+-------+------+
| 4.00  | 1    |
| 4.00  | 1    |
| 3.85  | 2    |
| 3.65  | 3    |
| 3.65  | 3    |
| 3.50  | 4    |
+-------+------+

平常说实话rank函数或者row_number函数用多了，很少考虑实现，面对这个问题，硬着头皮用笛卡尔积的join解决了，若是在hive中，strict模式可能拒绝笛卡尔积的join，这时还是求助于窗口函数rank吧~~

实现代码如下：

这个题目其实是176的扩展，刚才不是要找第二大的salary吗，那好，现在直接扩展到任意，第N大，而且这次是要写一个Function，N作为参数。表还是之前的Employee表。

+----+--------+
| Id | Salary |
+----+--------+
| 1  | 100    |
| 2  | 200    |
| 3  | 300    |
+----+--------+

我不知道为什么这个题目的通过率那么低，但是事实是使用176题那篇文章的“错误”做法即可解掉这个题目。注意limit是从0开始，所以变量要默认自减1。

大写的部分是题目已经给的框架，我们只需要在Return语句里填写内容即可，我declare了一个变量，不知道是否是一个hack手段，但是it works.

当然本着在大数据平台下sql的经验，如果换做是在hive下写这个，思路是什么呢？

1，我建议直接写一个UDAF解决。

2，不具备UDAF能力的话，可以在一个key下做sort by后，把他们group_concat或者wm_concat起来，然后get第n个item即可，当然这会利用到hive的默认的几个UDAF和UDF。

思路肯定有很多，欢迎大家一起来share~

这个问题很有趣，是要求我们写个sql来查询Employee表里第二高的工资，如果没有第二高的，那么返回null。

+----+--------+
| Id | Salary |
+----+--------+
| 1  | 100    |
| 2  | 200    |
| 3  | 300    |
+----+--------+

看到这个问题，可能很多人会想，这很简单啊，写个order by desc，然后找到第二个即可。

试试提交呗？Wrong answer，为什么？看条件约束啊，没有第二要返回null，我看到null的第一直觉是通过join搞到null值，于是有了下面的ac sql：

思路简单说就是通过全表左外联最大salary，从关联不到的salary里再找最大不就是第二大吗？

最后的结果是894ms，当然我坚信有很多更快更高效的结果。

第一题的描述：题目地址：https://oj.leetcode.com/problems/combine-two-tables/

一张表叫做Person，主键是PersonId

+-------------+---------+
| Column Name | Type    |
+-------------+---------+
| PersonId    | int     |
| FirstName   | varchar |
| LastName    | varchar |
+-------------+---------+

另一张表叫做Address，主键是AddressId

+-------------+---------+
| Column Name | Type    |
+-------------+---------+
| AddressId   | int     |
| PersonId    | int     |
| City        | varchar |
| State       | varchar |
+-------------+---------+

题目要求写一个sql完成查询任务：把Person表中每个人的FirstName，LastName，City和State都查询出来。

这明显是个非常简单的sql，只要拿Person表做左表进行left outer join即可（当然做右表进行right join也行）

最后，啰嗦几句，在我们现在的软件开发过程中，数据处理应该是一个工程师必备的技能，身在大公司，可能sql的编写有很多的限制，有的甚至不需要工程师来编写，直接交给DBA就行了。在这样的环境下，开发工程师往往丢掉了数据库的基本功。而在大数据的浪潮下，在hive\pig\ODPS下编写 sql 也成了数据开发工程师的基本技能，数据开发不能仅仅停留在写sql实现功能，最重要的是理解Hadoop生态下，各种sql语句的原理。就像开发一样，要写出最高效的sql来处理数据。我相信leetcode对于sql的挑战会是一个不错的平台，大家加油~~

原文地址：http://imei.org/2013/05/imei-number-decode/ 原文标题：What Is IMEI Number and How To Decode It

译文：

“

你可能听说过IMEI，也知道它是移动设备的标识ID，但是你知道它的具体功用吗？IMEI自手机出产后就伴随其一生，究竟什么是IMEI，如何理解它的数字含义？

智能手机是全世界范围内偷窃事件的“主角”，不要低估IMEI的重要性，把IMEI备份一下是一个明智的决定。本文会解释为什么我们的手机需要IMEI，同时会列出如何找到并记录IMEI的技术方法。

IMEI是什么？

IMEI的全称是International Mobile Equipment Identity，每台设备都必备的一个唯一标识，用来区分设备与设备。当你购买一台新的手机设备时，你会在收据上看到IMEI；当你需要修理手机时，手机服务商可能会要求你提供IMEI。标准的IMEI是一个14位数字，同时也有IMEI/SV这样的16位数字形式（仅新设备有），SV是由软件设计的。当然苹果的iPhone GSM有 15位数字，而CDMA是14位数字。不管如何，IMEI的设计动机不仅仅是一个ID标识，它也可以用来阻止网络访问，还可以用IMEI来进行运营商解锁。

如果你的手机失窃，你可以将情况上报到你的手机服务商，他们会阻止这台手机进行一切的网络访问，同时警察也可以通过IMEI来识别丢失的设备。

IMEI怎么查看？

多数手机在你输入拨号*#06#后就能看到IMEI了，当然也有其他的一些方法：

• iOS：Settings->General->About（设置->通用->关于手机），这样也可以看到有IMEI（需要自己下滑寻找）。iPhone手机同样可以在sim卡托盘上找到IMEI，当然如果你不是使用原生的托盘就看不到了。

• Android：Settings->About（设置->关于），这里可以看到IMEI，序列号和其他的信息。
• 老的Sony或者索爱：输入 * Right * Left Left * Left *
• 新的索爱或者Blackberry：Options->Status（选项->状态）

你可以使用http://imei.org/check-iphone-carrier/ 服务通过输入IMEI来获得手机的运营商信息

如何解释IMEI：

2004年以来，统一的IMEI格式为：AA-BBBBBB-CCCCCC-D，这是一个15位数字号，其中：

• AA：两位数字号，表示Reporting Body Identifier，用来表示由TAC（Type Allocation Code）分配的GSMA。
• BBBBBB：TAC(FAC)的剩余部分。
• CCCCCC：机器序列号（SNR）
• D：Luhn 检测位

举例来说，现在iPhone 5的TAC为01-332700，而三星的Galaxy S2为35-853704，而C部分的SNR是由手机制造商自定义的生产序列号，最后一位校验位是通过算法来生成的。

IMEI是手机相关的，与sim卡无关，当你的手机被偷后，无论手机重置还是更换sim卡，IMEI都是不变的，这时你是可以通过联系你的手机服务商来锁住手机的服务的。如果这行不通，可以联系你所在地区的运营商来锁定IMEI对于运营商网络的访问。

有时候IMEI是变化的，尽管这不合法。有些窃贼有能力将合法的新的IMEI安装到你的手机里从而重新启用这个手机。另外鉴于犯罪动机，还有人会利用IMEI来监听设备。

综上，IMEI是手机的重要的唯一性ID，你需要去备份并记住它。

”

翻译结束。

最后附加一些说明。

关于TAC：http://en.wikipedia.org/wiki/Type_Allocation_Code

关于最后一位校验位的算法和python code：

以14位IMEI为例，校验位假设是C

1. 从后向前，记录下每隔两位的数字，记为列表A
2. 从后向前，记录下除A以外的数字，记为列表B
3. 将A中的数字都乘以2，如果一个数字乘以2后大于10，那么把这个结果拆为两个数字（个位数一个，十位数一个），记为列表A'
4. 把A'和B中的所有数字求和，记为S
5. 计算S*9%10，记为F，如果F等于C，校验通过，否则IMEI有问题。

   1: if len(arg0)==15:

   2:             check_bit = int(arg0[-1])

   3:             i = len(arg0)-2

   4:             l,r = [],[]

   5:             while i>=0:

   6:                 m = int(arg0[i])*2

   7:                 if m<10:

   8:                     l.append(m)

   9:                 else:

  10:                     l.append(m%10)

  11:                     l.append(m/10)

  12:  

  13:                 r.append(int(arg0[i-1]))

  14:                 i-=2

  15:             l.reverse()

  16:             r.reverse()

  17:             if sum((sum(l),sum(r)))*9%10==check_bit:

  18:                 return True

  19:         return False

为什么会这样，我想这个和我最近痴迷橄榄球NFL有关（怎么这个句式特别像广告呢）。年初的超级碗全场录像把橄榄球运动拉入了我的视野，随着2014-2015NFL新赛季的开始，我也开始关注NFL，美式橄榄球是项非常棒的运动，为什么这么说？运动本身有几个特点非常吸引人：1）高强度身体对抗——无疑这是一项男人的运动，比赛中最常见的就是身体接触。2）规则和体系非常合理，橄榄球的进攻防守规则是非常合理的，进攻组司职攻城略地，而防守组负责守卫家园，这个对于原始的战争游戏模拟的非常到位。3）策略和战术要求极高，橄榄球进攻和防守战术非常多样化，进攻端可以采用地面冲球和传球，传球的话又可以分远距离、中距离和近距离传球，传球的对象，也可以是外接或者跑卫，外接的跑动路线……说不完啊。4）数据拟合准确，当然这是让我最痴迷NFL的原因，美式橄榄球把数据运用到了极致，对于球员的指标衡量非常的准确形象。

比起拳击那样的攻击与防御，它显得安全了很多；比起网球、乒乓球这样的球类运动，就相当的刺激荷尔蒙；比起足球和篮球这样的流行运动，橄榄球的规则和完整的体系以及无可出其右的策略性，是最吸引人的。当然足球的魅力在于团队配合可以打得非常精彩，同时个人英雄的出现也可以拯救世界，但是足球里衡量运动员综合素质的指标体系实在是不够好。我个人认为像橄榄球和棒球（NFL和MLB）是最好的数据决策运动体系，好笑的是这都是美国人为之疯狂的运动，而在世界上其他国家却知之甚少。

结合橄榄球运动和数据体系构建，确实给了数据从业人员很大灵感，玩NFL Fantasy的玩家都知道每周的Pick’Em可以来预测比赛，要知道一周15场比赛完全猜对的人非常非常多，为什么？因为数据刻画形象且透明，也就是说，我们做预测，不在于算法有多牛逼，而在于指标是否足够好，模型是否足够清晰的能刻画业务本身。这是我一直在做数据挖掘强调的，但是仍然有太多太多的人纠结在算法中不能自拔……NFL有一套自己的rating算法来评估球员的素质，当然这在FM游戏里也有，但是我个人认为NFL的计算更合理，因为橄榄球运动目标性非常强，没有像足球那样过多的回传和组织，橄榄球单箭头的向前就是最好的约束条件，这为数据可操作性提供了基本保障，我个人是这么认为的。另外NFL联盟的运作也类似一个数据体系，联盟约定工资帽，不会出现过分的强弱队之分，一个队伍都是明星大牌，工资帽不允许啊，所以NFL的32支球队，大体水平相当（当然有弱队和强队，这里说的大体相当是指在一场NFL比赛预测中，没有那么明显的胜负趋势，优势微弱=属性连续、分布完美）。另外不同的战术相生相克，在场上随时可以通过暂停来及时调整，这是小步快跑实时运算的等价比喻，足球比赛一开场就至少踢45分钟，这是典型的批处理，教练有个意图都是大声喊，也不见得球员遵循，但是橄榄球就完全不同，每次攻守基本都是战术的完整体现。说起时间，因为足球篮球是连续比赛，而棒球和橄榄球则是分档进攻，这其中的区别体现在数据的可分析性以及一次操作的影响性分析上，其实是很明显的。足球的连续比赛，导致我们在分析一次进攻的成功因素时，需要考虑的变量非常的多，因为时间窗口太大——45分钟，而橄榄球是阶段性的，一次成功的推进，一定是经历一个开球-传球或跑球这样的流程，这明显是规格化的产物，谁告诉你足球进球一定要是本方守门员大脚开球到前锋射门呢？所以对于橄榄球这种阶段性运动，一次分析可以根据本身的进攻和防守阶段被拆成很多的细片，在细片上完成分析，这也符合分析的规律——样本干净且完整。这有点像分布式计算，橄榄球天生分布式，而足球只能一把搞到内存里做完全分析……

胡乱扯了一通NFL的东西，美式橄榄球运动是项极度体现智慧的运动，结合数据去玩Fantasy，更觉得其乐无穷。

回头有空，再详细举例NFL的数据故事。没准也还聊聊手游和数据的事。

说起决策树，就好像是一个ML算法的标配一样，在每本ML的教程里，每个ML的代码库里，每个ML的软件包里，都有决策树的存在。个人认为决策树是一种人类本能的规则判别的算法表达，当我们遇到一个分类问题时，本能的会以一些IF-THEN规则去划分，这是本质的关联和分类的思维在起作用。比如我们在做决策时总会找一些阈值x，大于x该怎么做，小于x又该怎么做。或者我们换句话说，决策树是一种归纳推理的典型，而我们数学推理的模式无非是归纳和演绎。

决策树分类是希望通过数据集中各个属性的特点，归纳得到一组规则作为分类条件，而这些规则是通过一棵树来展现的，每个节点都是一个规则，得到规则后在遇到新的数据实例时，只要从树根按照顺序遍历树，评估每个节点的规则条件，最后到达叶子时就得到了决策。我们就拿Quinlan论文中的例子来讲什么是决策树。下面的表是一个训练数据集，其中表示了每天的一个天气状况（有4个特征维度：forecast, temperature, humidity, windy），而需要给出的决策结论(class)是当天是否要play tennis。而下面的图就是决策树。

其实稍加推断，不难发现，根据训练集去构建决策树，树的数目是不唯一的，甚至是无限多的（当然前提是数据集足够充分），比如上面就有两棵决策树，它们都是正确的，但是从复杂程度上来看有了区分。但是我们构建分类器的目的是要尽可能的具备优秀的泛化能力，即除了对训练数据集有好的效果，对于未知数据的分类要准确这才是我们想要的结果。基于此，我们构建决策树不是随便的，我们倾向于更简单的树，更简单的规则来分类数据，因为这样明显具有更好的泛化能力（显而易见）。具体如何构建呢？决策树算法有成千上万种，paper也遍地都是，但是ID3算法是构建决策树的最经典的算法之一，也是Quinlan的经典作。

ID3是一个迭代的算法，自顶向下构建决策树，步骤可以分作3步：

1. 在所有没有选定的属性中，计算每个属性的信息增益

1. 选择信息增益最大的特征作为节点

1. 对于选定的节点特征，选择其所有的可能取值作为子节点，重复步骤a，直到叶子节点的熵为0或者属性节点全部被计算过

直白的解释是，构建树嘛，就要不断的选好节点和子节点咯，选的规则嘛，很简单——信息增益，为啥是信息增益？信息增益怎么算？这要引出一段故事了：

熵是信息论中广泛使用的度量标准，表述的是数据集的纯度，在信息论中的解释是对信息编码的最少二进制位数。

以上面的数据集为例，14个数据实例的样本集S，有9个P，5个N，所以它p(class:P)=9/14，p(class:N)=5/14，在class上的熵为-(9/14)log2(9/14)-(5/14)log2(5/14)=0.94。熵值在0~1之间分布，熵越小说明数据集越纯。因为分类树的目的是找到规则属性来尽量的划分不同类别，那么也就是说如果能找到一个属性来划分数据集从而使期望的熵最小，则这个节点的属性就是好的，表示这个属性的这种程度被定义为信息增益（information gain）

Values(Windy)=True, False

S = [9 P, 5 N]

=[3 P, 3 N]

=[6 P, 2 N]

同样的道理我们计算所有的属性的信息增益得到

Gain(S,Outlook)=0.246, Gain(S,Humidity)=0.151, Gain(S,Temprature)=0.029

属性Outlook具有最大信息增益，所以第一个节点就选Outlook，而剩下的过程照此迭代，于是得到了最后的决策树就如上面图片中较简单的树形。当然作为衡量属性优劣的度量标准除了信息增益外还有增益比率（gain ratio）和基尼指数（gini index）等。

决策树的分支条件除了上述的方法，还有通过做转移函数来进行斜分的和基于最近邻的图的方式，具体几种划分的几何表示见下图。我们一般的划分数据方法也是采用第一种。

决策树学习算法包含了3个部分：特征选择、树构建和剪枝，特征选择可以帮助我们构建更简单有效的树，这个过程其实在很多的机器学习算法中都必不可少，正如Quinlan在论文中提到的噪音问题和丢失值问题，这些都会影响树的构建。而树构建由上面介绍的ID3算法可知是一个启发式搜索过程，如果采用暴力的做法，那么构建决策树是一个需要搜索出所有可能的树然后选择最优的问题，这是NP的，所以全局最优的结论是无法做到的，只能通过像ID3这样找到合适的启发准则（信息增益）来做局部最优搜索（贪心搜索）。顺序搜索带来的问题就是过拟合和局部最优性，我们对于一个训练集进行ID3算法，很难找到一个泛化能力强的树形model，所以这也顺其自然的引出了剪枝的过程。剪枝就是把一些不重要的分支砍掉从而达到简化model的目的，同时这也满足决策树在归纳偏置上的倾向——简单胜于复杂。剪枝可以看做是构建的一个逆过程，自底向上的剔除不“合格”的分支，而“合格”的定义取决于代价函数，代价函数定义为

如果把代价函数的第一项表示为

那么最后的代价函数形式为

这里C(T)表示预测误差，|T|表示模型的复杂度。剪枝的算法描述如下：

1. 计算节点的经验熵
2. 
3. 重复步骤b直到得到最小子树。

经过剪枝的决策树将原有的可能过拟合和有点复杂的树缩减到一棵简单树，完成了模型的泛化。

在应用ID3决策树时需要考虑的问题还有很多，比如缺失值、噪声数据、数据属性要求是nominal或者是enum等等，而Quinlan后面的C4.5算法作为ID3的升级版优化解决了部分问题，比如对于特征属性已经可以兼容连续数值型属性，使用信息增益比率来代替信息增益作为度量标准等等。因为决策树是随机森林的基础，所以特地结合教科书和Quinlan的paper做一个简单介绍，由于发展历史较为悠久，所以变种的决策树多如牛毛，决策树算法的各个阶段都有非常多的paper改进，包括各种剪枝方法理论、树的大数据挑战和可视化等等，感兴趣的话自行查阅搜索，后面可能会单独介绍CART和C4.5这两种树的算法并对比ID3,C4.5和CART。

What is Random Forests:

随机森林是一个组合分类的方法，和bagging和boosting一样都非常常用，组合分类的思想就是将k个学习模型组合在一起，从而创建一个复合分类模型，最后通过投票来决定分类决策。随机森林的一个通俗解释就是：由一组决策树构建的复合分类器，它的特点是每个决策树在样本域里使用随机的特征属性进行分类划分。最后分类时投票每棵分类树的结论取最高票为最终分类结论。

如上所述，如果我们理解随机森林是一组决策树构成的，那么我们需要首先找到构建决策树的方法，同时我们也需要一个判别函数去将各个决策树的分类结果汇总起来并且能保证他们的准确度。首先，如何构建这些决策树呢，显然不能用同样的数据集和同样的特征向量，否则构建n个决策树和构建一个是等价的。那么随机化如何呢？随机化是ML的一个很重要的方法，也是一个很有用的工具，例如交叉验证、随机抽样等等。一种方法来构建决策树就是随机的选择n个特征子集来训练n个决策树，那如上所说，树构建好后需要判别函数来把结果整合，定义判别函数之前我们先看一个后验概率

随机森林是集体智慧的象征，通过随机分配一些特征向量来各自学习最后选举结果，准确率据说可以媲美AdaBoost，且对错误和利群点更鲁棒，通过调整森林中树的个数可以使泛化误差收敛，解决过拟合问题。同时调整个体树的属性选择可以提高准确率，通常的选择方法是log2d+1个属性。

而X和Y是否有线性关系？ 普通线性回归(Ordinary Linear Regression)是否就能满足需求？我们需要先论证这个问题，我们看一下普通线性回归，模型是这样的：

在线性回归中，随机误差项服从正态分布。这也意味着回归的Y值是个连续变量，不能是0\1这样的binary变量。另外一个解释就是线性回归对响应变量Y的要求是有常数方差，这也限定了Y的分布，就比如二项分布的Y就没有常数方差。这也正符合我们常规的阅读理解，回归用于定量分析，更多的在拟合和预测量上，而分类是个定性分析。正因为OLR的做法限制太多，因此有了通用线性回归的方法（General Linear Regression），通用方法的思路就是寻求一个转换函数g来作用于输入变量X，从而摆脱对Y的分布限制。具体表现为

下面两张图对比了线性回归和逻辑回归数据的特点，也说明了如果用线性回归来分类binary数据是一个什么样的效果。

其实比较朴素的理解就是，我们把要分类的数据划分为0和1两类，那么数据其实是会以中间这幅图的形式分布的，必然存在一个平面（直线）把数据划分。而我们希望找到一个判别函数能完成区分，显而易见的是直线无法完成这个事情。

面对线性回归的劣势，我们理解回归的问题在于无法对公式（1）的结果做0\1划分，线性回归的方法做分类，就是要求

而逻辑回归作为GLR的一个特殊情况，定义了一函数f()，这个函数可以将Y做0\1处理，从而使线性回归变得有意义。而逻辑回归的做法就是找到了这样一个函数，这个函数也叫logit函数

其中我们把p等价于原来的 ，解释一下就是p代表Y=1的概率，标准说法p是Y=1时Y的期望。然后把这个p替换掉就得到了

目标是求解，于是

这里就不是一个线性函数了，上面提到的公式（2）对应的曲线上面最右边的图——可以看到p的函数曲线，这样的划分对于0\1数据的分类是非常合适的。

那么一个问题就随之而来，logit函数是怎么来的？要想知道答案，我们需要先分析一下这个形式，我们定义这个形式为“优势”（odds），odds有时候也叫做“几率”，odds的函数形式其实是下面左图的样子，而logit函数的形式是右图的样子

odds的理解其实要结合概率的思想，我们认为一个事件发生的概率是p，那么不发生的概率就是1-p，而odds表达的就是事件发生与不发生（或者一个标注yes 或者no）的几率，比如一个事情发生的概率是0.9，而不发生是0.1，那么odds（发生）=0.9/0.1=9，而odds(不发生)=0.1/0.9=0.1111...。这说明一种事物相比较时的优势，但是这个优势在形式上非对称，这样是不完美的，也是难于理解的，毕竟对于一个0-1之间的概率比较，结果却在0-∞之间。而可以看出logit函数是把odds对数化后得到的一个对称的美妙的曲线，拥有我们想要的所有性质，并且解决了OLR所限制的问题，而且由公式（3）我们也能看到，logit函数使结果限定在0-1之间，且是输入变量X的线性表示。

最后当我们计算出p，我们就能确定分类，比如p>0.5时 y=1，而p<0.5时y=0。于是这样的分类任务就结束了。不过我们再看看模型，似乎忘记了什么，我们可以从数据集里得到X和Y，但是对于α和β以及ε的值（参数值），我们需要获取到。而这才是LR作为机器学习方法最关键的一个部分。

我们假设数据集有n个数据样本，且n大于估计的参数的个数，于是我们令

我们用β表示整个参数向量，那么原来的表达式可以写为Y=X*β。类似最小二乘法的思路，我们有下面的推断

其实如果把目标约定为计算β,那么问题也就被归约为一个参数估计问题，而我们最常用的方法就是极大似然估计法。这里不具体介绍MLE，换种角度我们从头开始设计这个分类器。

之前考虑的点我们简化了分析，我们理所当然的认为X特征向量彼此是同等重要的，而事实往往不是这样，因此模型需要加入一个权重影响因子，也就是LR模型被扩展为Weighted Logistic Regression，因为目标是计算公式（5），加入权重后，我们把评估公式（5）的做法替换为去评估

这里就涉及一个问题：权重具体是个什么定义？权重W是个对角矩阵，其对角元素即每个特征项的权重值，而这个权重定义为预测变量的标准差。此时我们回到一个基本问题，LR用来预测二类问题，而我们一般假设我们的预测变量Y是服从二项分布的即，那么方差，更特殊的，对于单次试验是伯努利分布，所以有，而这个即我们对于预测变量Y的估计值，形如公式（4），换用现在对β的定义就是，回到公式（6）中，我们新引入的变量U即表示为，其中后面这个加项我们这么理解：分子是一个预测误差项，而分母是我们定义的权重，这样一个比值缩放了正确分类的大方差样本点和小方差样本点对结果的影响。另外需要引入的一个概念是岭回归（Ridge Regression），源于一些预测变量y可能是线性相关的，那么这会导致是奇异矩阵，会导致无穷解，因此在带求解的公式（6）的基础上，为可逆矩阵引入一个常量对角矩阵，公式变为

其中是小常量，而I是单位矩阵。这样做避免了对奇异矩阵求逆，但是带来了问题就是对预测变量结果的偏置，导致目标问题发生了小小的变化。多种方法可以帮助我们寻找一个好的，这里就不具体展开了，具体参考资料即可。

最后就是算法实现了，为了避免复杂的矩阵求逆，我们把形式变一下，将公式（7）转换为求解这样一个线性系统

其中，。可以看出，算法的输入是特征矩阵X和U（间接得到），输出是β。求解线性系统的算法有很多，其中共轭梯度算法是非常有效的算法，下面左图描述了共轭梯度算法的实现伪代码。

共轭梯度：

IRLS：

其中值得一提的是共轭梯度算法中的“is large enough”或者维基上说的“sufficiently small”有多种判断方式，具体这里就不列出了，可以看参考资料[2]。右图是迭代重加权最小二乘法，用于最终求解β。

我在github上放了一个《machine learning in action》中的LR算法的python实现，对于β的求解使用的是梯度下降法，可以参考https://github.com/changedi/mlmlml/blob/master/LogisticRegression/logRegres.py，而关于梯度下降等最优化算法，我想还是单独开一篇去介绍比较合适。至此，LR的基本介绍基本就结束了。

文中除流程图外，其他截图取自ref[2]，特此声明。

References:

[1] http://logisticregressionanalysis.com/86-what-is-logistic-regression/

[2] http://www.omidrouhani.com/research/logisticregression/html/logisticregression.htm

[3] 《统计学习方法》，李航

[4] Logit Models for Binary Data, G. Rodriguez, 2007

[5] http://zh.wikipedia.org/wiki/%E5%85%B1%E8%BD%AD%E6%A2%AF%E5%BA%A6%E6%B3%95

[6] http://cnx.org/content/m45285/latest/

源码如下：

   1: /*

   2:  * Copyright (C) 2013 changedi

   3:  *

   4:  * Licensed under the Apache License, Version 2.0 (the "License");

   5:  * you may not use this file except in compliance with the License.

   6:  * You may obtain a copy of the License at

   7:  *

   8:  * http://www.apache.org/licenses/LICENSE-2.0

   9:  *

  10:  * Unless required by applicable law or agreed to in writing, software

  11:  * distributed under the License is distributed on an "AS IS" BASIS,

  12:  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

  13:  * See the License for the specific language governing permissions and

  14:  * limitations under the License.

  15:  */

  16: package com.jybat.dp;

  17:  

  18: import java.util.HashSet;

  19: import java.util.Set;

  20:  

  21: /**

  22:  * Knapsack01Problem.

  23:  * 

  24:  * @author zunyuan.jy

  25:  * 

  26:  * @since 2014年6月13日

  27:  */

  28: public class KS01 {

  29:  

  30:     private static int knapsackCapacity = 22;

  31:     private static int[] value = { 25, 24, 15 };

  32:     private static int[] weight = { 18, 15, 10 };

  33:     private static int n = value.length; // number of objects n=3

  34:     private static int highestIndex = n - 1; // items are indexed

  35:  

  36:     // from 0 through n-1

  37:  

  38:     private static Set<Integer> calculateDecisionSet(int objInd, int w) {

  39:         Set<Integer> decSet = new HashSet<Integer>();

  40:         decSet.add(new Integer(0)); // decision to not take object

  41:         // is always feasible

  42:         if (w >= weight[objInd]) { // check if there is enough space

  43:             // to take object

  44:             decSet.add(new Integer(1));

  45:         }

  46:         return decSet;

  47:     }

  48:  

  49:     public static double f(int currentObejctIndex, int weightToGive) {

  50:         if (currentObejctIndex == -1)

  51:             return 0.0;

  52:         Set<Integer> decisionSet = calculateDecisionSet(currentObejctIndex,

  53:                 weightToGive);

  54:         double max = 0.0;

  55:         for (int d : decisionSet) {

  56:             double tmp = d

  57:                     * value[currentObejctIndex]

  58:                     + f(currentObejctIndex - 1, weightToGive - d

  59:                             * weight[currentObejctIndex]);

  60:             if (tmp > max)

  61:                 max = tmp;

  62:         }

  63:         return max;

  64:     }

  65:  

  66:     /**

  67:      * @param args

  68:      */

  69:     public static void main(String[] args) {

  70:         System.out.println(KS01.f(2, 22));

  71:     }

  72:  

  73: }

具体拿例子说是，假设c=(3,5)，b=(4,12,18)，并且A是约束矩阵A=[(1,0),(0,2),(3,2)]这里矩阵是行表示法即3行两列矩阵。那么经过上面的迭代求解，可以知道最优的决策组(x1,x2)=(2,6)，最大化后的函数值为c1x1+c2x2=3*2+5*6=36。

最后我们附上解题源码：

   1: /*

   2:  * Copyright (C) 2013 changedi

   3:  *

   4:  * Licensed under the Apache License, Version 2.0 (the "License");

   5:  * you may not use this file except in compliance with the License.

   6:  * You may obtain a copy of the License at

   7:  *

   8:  * http://www.apache.org/licenses/LICENSE-2.0

   9:  *

  10:  * Unless required by applicable law or agreed to in writing, software

  11:  * distributed under the License is distributed on an "AS IS" BASIS,

  12:  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

  13:  * See the License for the specific language governing permissions and

  14:  * limitations under the License.

  15:  */

  16: package com.jybat.dp;

  17:  

  18: import java.util.HashSet;

  19: import java.util.Set;

  20:  

  21: //IntegerLinearProgramming;

  22: public class ILP {

  23:     // objective function coefficients

  24:     private static int[] c = { 3, 5 };

  25:     // right hand side of constraints vector

  26:     private static int[] b = { 4, 12, 18 };

  27:     // constraint matrix

  28:     private static int[][] a = { { 1, 0 }, { 0, 2 }, { 3, 2 } };

  29:     private static int n = c.length;

  30:     private static int m = b.length;

  31:     private static final int infty = Integer.MAX_VALUE;

  32:  

  33:     private static Set<Integer> calculateDecisionSet(int stage, int y1, int y2,

  34:             int y3) {

  35:         Set<Integer> result = new HashSet<Integer>();

  36:         // maxPossibleChoiceBecauseOfResourceiRestriction, i=1,2,3

  37:         int mpc1 = infty;

  38:         int mpc2 = infty;

  39:         int mpc3 = infty;

  40:         if (a[0][stage] != 0) {

  41:             mpc1 = y1 / a[0][stage];

  42:         }

  43:         if (a[1][stage] != 0) {

  44:             mpc2 = y2 / a[1][stage];

  45:         }

  46:         if (a[2][stage] != 0) {

  47:             mpc3 = y3 / a[2][stage];

  48:         }

  49:         for (int i = 0; i <= Math.min(mpc1, Math.min(mpc2, mpc3)); i++) {

  50:             result.add(new Integer(i));

  51:         }

  52:         return result;

  53:     }

  54:  

  55:     // here: yi denotes how much of resource i is still available,

  56:     // (in other words how much slack is still available)

  57:     public static double f(int stage, int y1, int y2, int y3) {

  58:         if (stage == n) {

  59:             return 0.0;

  60:         }

  61:         double max = Double.MIN_VALUE;

  62:         for (int d : calculateDecisionSet(stage, y1, y2, y3)) {

  63:             double t = c[stage]

  64:                     * d

  65:                     + f(stage + 1, y1 - a[0][stage] * d, y2 - a[1][stage] * d,

  66:                             y3 - a[2][stage] * d);

  67:             if (t > max)

  68:                 max = t;

  69:         }

  70:         return max;

  71:     }

  72:  

  73:     /**

  74:      * @param args

  75:      */

  76:     public static void main(String[] args) {

  77:         System.out.println(ILP.f(0, b[0], b[1], b[2]));

  78:     }

  79:  

  80: }

可以看出这个方案的调度时长需要40。

如果用DP去求解这个问题，首先定义状态，我们定义过程d的A任务完成时间为pd，B任务完成时间为qd，那么引入一个虚拟阶段号k，k表示上一次被确认调度的A和B任务各自完成中间那段流失的时间（可能不是很好理解，这里解释一下，为什么取这个值作为状态，首先对于pd和qd这都是固定计算成本，那么导致任务不能连续运转的原因就是有A在B前完成这个约束，对于上面的例子，我们看到B3任务并不能在B2任务结束后马上开始，而一定要等到A3任务结束才可以，B2结束后到A3结束前这段时间即15-11这4个时间单位的时间就是这里的k了，定义了这个k后，我们就可以知道目标状态是要使k=0且未被调度的任务集合），定义S为剩余的过程集合，所以状态为(k,S)，这个状态对于一个过程的A和B任务如果没有延迟(k<pd)，那么k=qd，反之有延迟则延迟时间为max(k-pd,0)，所以一个调度过程d开始后的时间成本会记为A任务时间pd+延迟时间max(k-pd,0)+B任务时间qd。所以DPFE即f(k,S)=min d∈S{pd+f(max(k-pd)+qd,S-{d})}。初始状态对于S是空集，那么f(k,S)=k。于是对于上面的具体问题，方程求解最优时间是38，决策序列为d1=0，d2=2，d3=3，d4=1。

过程源码如下：

   1: /*

   2:  * Copyright (C) 2013 changedi

   3:  *

   4:  * Licensed under the Apache License, Version 2.0 (the "License");

   5:  * you may not use this file except in compliance with the License.

   6:  * You may obtain a copy of the License at

   7:  *

   8:  * http://www.apache.org/licenses/LICENSE-2.0

   9:  *

  10:  * Unless required by applicable law or agreed to in writing, software

  11:  * distributed under the License is distributed on an "AS IS" BASIS,

  12:  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

  13:  * See the License for the specific language governing permissions and

  14:  * limitations under the License.

  15:  */

  16: package com.jybat.dp;

  17:  

  18: import java.util.HashSet;

  19: import java.util.Set;

  20:  

  21: //Flowshop Problem

  22: public class FLOWSHOP {

  23:  

  24:     private static int[] first = { 3, 4, 8, 10 }; // sum=25

  25:     private static int[] second = { 6, 2, 9, 15 }; // sum=32

  26:     // upper bound on final completion time is 25+32:

  27:     private static int sum = 57;

  28:     private static int m = first.length;

  29:  

  30:     private static Set<Integer> setOfAllItems = new HashSet<Integer>();

  31:     

  32:     static{

  33:         setOfAllItems.add(0);

  34:         setOfAllItems.add(1);

  35:         setOfAllItems.add(2);

  36:         setOfAllItems.add(3);

  37:     }

  38:     

  39:     private static int fct(int t, int d) {

  40:         return Math.max(t - first[d], 0) + second[d];

  41:     }

  42:     

  43:     public static double f(Set<Integer> set, int t){

  44:         if(set.isEmpty())

  45:             return t;

  46:         double min = Double.MAX_VALUE;

  47:         for(int d : set){

  48:             Set<Integer> tmpSet = copySet(set);

  49:             tmpSet.remove(d);

  50:             double tmp = first[d]+f(tmpSet,fct(t,d));

  51:             if(tmp<min){

  52:                 min=tmp;

  53:             }

  54:         }

  55:         return min;

  56:     }

  57:  

  58:     private static Set<Integer> copySet(Set<Integer> set) {

  59:         Set<Integer> s = new HashSet<Integer>();

  60:         for(int x : set){

  61:             s.add(x);

  62:         }

  63:         return s;

  64:     }

  65:  

  66:     /**

  67:      * @param args

  68:      */

  69:     public static void main(String[] args) {

  70:         System.out.println(f(setOfAllItems,0));

  71:     }

  72:  

  73: }

问题是这样的：假设有一个湖，湖里有一些鱼，在第一年有b1条鱼，之后在第t年开始有bt条鱼。渔民靠捕鱼卖鱼为生，在第t年卖掉xt条鱼的话，可以有r(xt)的收益。当然捕获这些鱼也会造成c(xt,bt)的成本。鱼群每年会自然繁殖，假定繁殖规律是固定的，每年以s的比例自然增长。同样渔民手里的钱存在银行每年也会有固定利息y。请问从第一年开始到第T年，每年应该怎么捕鱼才能使利益最大化，不能竭泽而渔，当然也不能等着饿死。

乍一看这个描述，目标很明确——最大化利益，但是条件N多，在DP求解时，要仔细考虑清楚状态转移方程中核心的优化条件。首先我们定义状态，年份t是个天然的stage维度，那么要知道利益，已知条件有收益函数、成本函数、增长比例和固定利息，共同的需求就是鱼的数量b，于是状态就是(t,b)，因为t在1~T之间（这本身也是递归收敛条件），所以DPFE方程为分段方程：f(t,b)=0当且仅当t>T，当t≤T时，f(t,b)=max xt∈{0,…,b} {r(xt)-c(xt,b)+1/(1+y) * f(t+1,s(b-xt)} 。具体解释一下，就是我们算t年b条鱼时的利益时，假设捕xt条鱼，那么利益等价于卖鱼收益r(xt)减去捕鱼成本c(xt,b)，再加上明年收益及利息。

看起来蛮复杂的问题，其实核心的状态定义清楚后，逻辑理清，条件虽然多，但是复杂度只增加在了目标计算上，这样的问题对于DP里来说个人认为算是不太复杂的。

实际例子，我们假设T=2，y=0.05，s=2，初始b1=10（单位是千条），收益函数也线性化表示为3xt，成本函数简化为2xt，这样收益我们实际是在求f(1,10)，答案输出是19.05，其最优化决策是x1=0,x2=20，即第一年不捕鱼，第二年捕完所有鱼~~（这个变态的决策，有点。。。。。。）

源码：

   1: /*

   2:  * Copyright (C) 2013 changedi

   3:  *

   4:  * Licensed under the Apache License, Version 2.0 (the "License");

   5:  * you may not use this file except in compliance with the License.

   6:  * You may obtain a copy of the License at

   7:  *

   8:  * http://www.apache.org/licenses/LICENSE-2.0

   9:  *

  10:  * Unless required by applicable law or agreed to in writing, software

  11:  * distributed under the License is distributed on an "AS IS" BASIS,

  12:  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

  13:  * See the License for the specific language governing permissions and

  14:  * limitations under the License.

  15:  */

  16: package com.jybat.dp;

  17:  

  18: //Discounted Profits Problem

  19: //A discounted DP problem from Winston/Venkataramanan

  20: //pp.779--780

  21: //Used a reproductionFactor of 2 instead of 1.2 so number of

  22: //fish takes on integral values, without the need to use a

  23: //round or a floor function.

  24: public class DPP {

  25:     private static int T = 2; // planning horizon T=2 years

  26:     private static double interestRate = 0.05; // assume 5% interest rate

  27:     private static int initialFishAmount = 10; // initially 10,000 fish in lake

  28:     private static int reproductionFactor = 2; // in 1 year 100% more fish

  29:  

  30:     private static double revenue(int xt) {

  31:         // simply assume that the sale price is $3 per fish, no matter what

  32:         return 3.0 * xt;

  33:     }

  34:  

  35:     private static double cost(int xt, int b) {

  36:         // simply assume that it costs $2 to catch (and process) a fish, no

  37:         // matter what

  38:         return 2.0 * xt;

  39:     }

  40:  

  41:     // t is stage number, each stage represents one year

  42:     // b is current number of fish in lake (scaled to thousands)

  43:     public static double f(int t, int b) {

  44:         if (t == T + 1)// T+1 is outside planning horizon

  45:             return 0.0;

  46:         // xt is the number of fish to catch and sell

  47:         // during year t

  48:         int xt;

  49:         double max = Double.MIN_VALUE;

  50:         for (xt = 0; xt <= b; xt++) {

  51:             double earn = revenue(xt) - cost(xt, b) + 1 / (1 + interestRate)

  52:                     * f(t + 1, reproductionFactor * (b - xt));

  53:             if (earn > max)

  54:                 max = earn;

  55:         }

  56:         return max;

  57:     }

  58:  

  59:     /**

  60:      * @param args

  61:      */

  62:     public static void main(String[] args) {

  63:         System.out.println(f(1, initialFishAmount));

  64:     }

  65:  

  66: }

deadline问题的描述是：一台处理器可以处理n个作业，表示为a1,a2,…,an。每个作业aj有相等的运行时长（如果不等也作为变量呢？），有效益pj以及截止时间dj。机器是串行的，也就是说一个时刻只能处理一个作业。而且作业是原子的，不可拆分。获得效益pj的前提是aj一定要在dj之前完成。请给出一个算法来达到最优调度，即效益最大化。之前讲到，在看到最优化问题时就直接想DP求解，这个当然是个好习惯，但是这里再介绍一个思路就是优先可以先考虑贪心是否可解，相对列动态规划方程定义状态这些事情，贪心往往更直观更简单（人心不足啊）。

这个问题是可以使用贪心法求解的，贪心算法不是我们这个系列问题的关键，但是也可以简单谈一下贪心：贪心的核心是要确定正确的贪心目标，就是在一系列决策做出时，每个步骤选择的理由是什么，比如这个问题，是按照处理时间排序后贪心？还是按照效益排序后贪心？根据目标是效益最大化，那么就可以做出正确选择了。

当然动态规划比贪心优势的一点就是贪心是个局部策略，不是所有问题都能得到全局最优解，而DP是全局最优的，使用DP总能得到最优决策。针对本题，我们思考如何定义一个状态来列出状态转移方程。就像考虑其他类似组合优化问题时，看到有决策性步骤问题时，我们定义状态是带有步骤标号的，也就是第一章提到的stage decision，每个stage用k表示，到了第i个stage后，剩余的可决策集S作为另一个状态元素，于是我们定义状态(k,S)，其中k是stage，S是表示当前状态下剩余可选决策。为了保证S集是可选择的决策集，我们需要对deadline排序，即按照截止时间排序。这样，我们列DPFE如下：f(k,S)=max d∈S{c(d|s)+f(k+1,S-{d})}，其中c(d|s)=pd，基本条件是f(k,S)=0，当k=1+N或者S为空时。

以具体数据为例：5个作业标号为{0,1,2,3,4}，其中每个作业的效益为{10,15,20,1,5}，完成deadline为{1,2,2,3,3}，求最优策略的效益。可以看到按照之前贪心解法，按照效益排序后，为20,15,10,5,1，而对应的截止时间也变为2,2,1,3,3，这样最优解就是20+15+5=40。DP的解法如下源码：

   1: package com.jybat.dp;

   2:  

   3: import java.util.Set;

   4: import java.util.SortedSet;

   5: import java.util.TreeSet;

   6:  

   7: //deadline scheduling of unit-time jobs

   8: public class DEADLINE {

   9:  

  10:     private static int[] profit = { 10, 15, 20, 1, 5 };

  11:     private static int[] deadline = { 1, 2, 2, 3, 3 }; // sorted

  12:     private static int N = profit.length; // no.of jobs

  13:  

  14:     private static SortedSet<Integer> setOfAllJobs = new TreeSet<Integer>();

  15:  

  16:     public DEADLINE() {

  17:         for (int i = 0; i < N; i++) {

  18:             setOfAllJobs.add(i);

  19:         }

  20:     }

  21:  

  22:     private static boolean feasible(SortedSet<Integer> jobs, int k, int d) {

  23:         int j = 0;

  24:         for (int i = 0; i < N; i++) {

  25:             if (!(jobs.contains(new Integer(i))) || i == d) {

  26:                 // if i already chosen or next (and is j-th),

  27:                 // does it meet its deadline?

  28:                 if (deadline[i] < ++j) {

  29:                     return false;

  30:                 }

  31:             }

  32:         }

  33:         return true;

  34:     }

  35:  

  36:     private static int cost(SortedSet<Integer> jobs, int k, int d) {

  37:         if (feasible(jobs, k, d)) {

  38:             return profit[d];

  39:         } else {

  40:             return 0;

  41:         }

  42:     }

  43:  

  44:     // jobs not yet chosen at stage k

  45:     public int f(SortedSet<Integer> jobs, int k) {

  46:         if (k > N)

  47:             return 0;

  48:         int max = Integer.MIN_VALUE;

  49:         for (int d : jobs) {

  50:             SortedSet<Integer> nJobs = copySet(jobs);

  51:             nJobs.remove(d);

  52:             int t = cost(jobs, k, d) + f(nJobs, k + 1);

  53:             if (t > max)

  54:                 max = t;

  55:         }

  56:         return max;

  57:     }

  58:  

  59:     private SortedSet<Integer> copySet(SortedSet<Integer> jobs) {

  60:         SortedSet<Integer> nJobs = new TreeSet<Integer>();

  61:         for (int i : jobs) {

  62:             nJobs.add(i);

  63:         }

  64:         return nJobs;

  65:     }

  66:  

  67:     /**

  68:      * @param args

  69:      */

  70:     public static void main(String[] args) {

  71:         DEADLINE d = new DEADLINE();

  72:         System.out.println(d.f(setOfAllJobs, 1));

  73:     }

  74:  

  75: }

      因为限制了n=3，也就是需要我们在c这个成本序列里添加两个分界把这个序列分为3个子序列，然后每部分按照最大的那个尺寸去加和，然后最后加和3个子序列和来确定成本。如果我们把分界定为3和6（第3个和第6个，指定下标），那么需要生产的其实是c[3]=7和c[6]=13以及c[9]=21的遮罩，而总和C=7*size(0~3)+13*size(4~6)+21*size(7~9)=7*4+13*3+21*3=130。而要想求得最优方案和最低成本，我们明显需要划分出所有可能的组合而求最小值，这典型的DP求解。

      DP求解的第一步就是定义状态，这个在之前也说过无数次了，状态定义是状态转移方程的基础。那么这个问题因为涉及到遮罩和花朵两种对象，所以我们自然的想到用(j,l)来定义状态，其中j是有多少种遮罩需要确定，l是尚未被确定遮罩的花朵中的最大尺寸的花朵（位置下标）。通过这个定义，可以知道目标函数是求f(n,k-1)，而基础条件是f(1,l)=(l+1)*c[l]，当j=1时。DPFE为f(j,l)=min {(l-k)*c[l]+f(j-1,l-k)}当j>1时，且k∈(j-2,…,l-1)。

      综上，最优分隔应该是4，6和9，显然9是必须在这个分隔组里的。那么最低成本C=8*size(0~4)+13*size(5~6)+21*size(7~9)=8*5+13*2+21*3=129。

source code：

   1: /*

   2:  * Copyright (C) 2013 changedi

   3:  *

   4:  * Licensed under the Apache License, Version 2.0 (the "License");

   5:  * you may not use this file except in compliance with the License.

   6:  * You may obtain a copy of the License at

   7:  *

   8:  * http://www.apache.org/licenses/LICENSE-2.0

   9:  *

  10:  * Unless required by applicable law or agreed to in writing, software

  11:  * distributed under the License is distributed on an "AS IS" BASIS,

  12:  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

  13:  * See the License for the specific language governing permissions and

  14:  * limitations under the License.

  15:  */

  16: package com.jybat.dp;

  17:  

  18: //optimal COVering problem

  19: public class COV {

  20:     // cost of cover sizes 0,1,..,9 in dollar

  21:     private static int[] cost = { 1, 4, 5, 7, 8, 12, 13, 18, 19, 21 };

  22:  

  23:     public static double f(int numberOfCoverSizes, int largestSize) {

  24:         //numberOfCoverSizes denotes the stage number in this problem        

  25:         if (numberOfCoverSizes == 1)

  26:             return (largestSize + 1) * cost[largestSize];

  27:         double min = Double.MAX_VALUE;

  28:         for (int nextCoverSize = numberOfCoverSizes - 2; nextCoverSize <= largestSize - 1; nextCoverSize++) {

  29:             double t = (largestSize - nextCoverSize) * cost[largestSize]

  30:                     + f(numberOfCoverSizes - 1, nextCoverSize);

  31:             if (t < min)

  32:                 min = t;

  33:         }

  34:         return min;

  35:     }

  36:  

  37:     /**

  38:      * @param args

  39:      */

  40:     public static void main(String[] args) {

  41:         System.out.println(f(3, 9));

  42:     }

  43:  

  44: }

      以具体例子来解读，一个数据集为{A,B,C,D,E}，对应的搜索概率为{0.25,0.05,0.2,0.4,0.1}。那么最优解f(X)=f({A,B,C,D,E})=1.9，树形为：

程序源码：

   1: /*

   2:  * Copyright (C) 2013 changedi

   3:  *

   4:  * Licensed under the Apache License, Version 2.0 (the "License");

   5:  * you may not use this file except in compliance with the License.

   6:  * You may obtain a copy of the License at

   7:  *

   8:  * http://www.apache.org/licenses/LICENSE-2.0

   9:  *

  10:  * Unless required by applicable law or agreed to in writing, software

  11:  * distributed under the License is distributed on an "AS IS" BASIS,

  12:  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

  13:  * See the License for the specific language governing permissions and

  14:  * limitations under the License.

  15:  */

  16: package com.jybat.dp;

  17:  

  18: import java.util.SortedSet;

  19: import java.util.TreeSet;

  20:  

  21: public class BST {

  22:  

  23:     private int[] data = { 0, 1, 2, 3, 4 };// assume the n data items are

  24:                                             // the ints {0,1,..,n-1}

  25:                                             // corresponding to strings

  26:                                             // { "A", "B", "C", "D",

  27:                                             // "E"}

  28:     private double[] probability = { 0.25, 0.05, 0.2, 0.4, 0.1 };

  29:  

  30:     private static SortedSet<Integer> setOfAllItems = new TreeSet<Integer>();

  31:  

  32:     public BST() {

  33:         for (int i = 0; i < data.length; i++)

  34:             setOfAllItems.add(data[i]);

  35:     }

  36:  

  37:     private double sumOfProbabilitiesOfItems(SortedSet items) {

  38:         double result = 0.0;

  39:         for (int i = ((Integer) items.first()).intValue(); i <= ((Integer) items

  40:                 .last()).intValue(); i++) {

  41:             result += probability[i];

  42:         }

  43:         return result;

  44:     }

  45:  

  46:     private SortedSet setOfItemsLessThanPivot(SortedSet items, int alpha) {

  47:         // conveniently use method headSet() from SortedSet

  48:         // headSet() DOES NOT include alpha

  49:         return new TreeSet(items.headSet(new Integer(alpha)));

  50:     }

  51:  

  52:     private SortedSet setOfItemsGreaterThanPivot(SortedSet items, int alpha) {

  53:         // conveniently use method tailSet() from SortedSet

  54:         // headSet() DOES include alpha

  55:         SortedSet ss = new TreeSet(items.tailSet(new Integer(alpha)));

  56:         ss.remove(alpha);

  57:         return ss;

  58:     }

  59:  

  60:     public double f(SortedSet<Integer> items) {

  61:         if (items.size() == 0)

  62:             return 0.0;

  63:         double min = Double.MAX_VALUE;

  64:         for (int a : items) {

  65:             double t = sumOfProbabilitiesOfItems(items)

  66:                     + f(setOfItemsLessThanPivot(items, a))

  67:                     + f(setOfItemsGreaterThanPivot(items, a));

  68:             if (t < min)

  69:                 min = t;

  70:         }

  71:         return min;

  72:     }

  73:  

  74:     /**

  75:      * @param args

  76:      */

  77:     public static void main(String[] args) {

  78:         BST bst = new BST();

  79:         System.out.println(bst.f(setOfAllItems));

  80:     }

  81:  

  82: }

算导的原题：

      某汽车工厂有2个装配线，每个装配线有n 个装配站（按顺序编号1～n ）标记为Si,j，表示第i个装配线的第j个装配站，两个装配线的对应的装配站执行相同的功能，但所用的时间可能不同。经过第i条流水线（i=1，2）的第j 个装配站所花的时间为a[i][j]。从第i条流水线的第j 个装配站移到第j+1个装配站的时间可以忽略，而移到另外一个流水线的下一个装配站则需要一定的时间t[i][j]。汽车进入流水线需要花时间，进入装配线1需要时间e[1]，进入装配线2需要时间e[2];  汽车出流水线时需要花时间，出装配线1需要时间x[1]，出装配线2需要时间x[2] 。汽车的装配需要按顺序经过所有装配站。
　　现在已知装配时间a[i][j] 、转移时间t[i][j]、进入装配线的时间e[i]、出装配线的时间x[i]，要求输出装配一辆汽车所需要的最短时间，以及经过的装配站。 

      对于这个问题，可以将其与之前所解的有向无环图对比，非常类似，不同的是这个在计算转移成本的时候，不仅需要算路径（也就是转移的成本），还要叠加节点本身的生产成本。以具体为例，装配线有14个装配站，其中0号和13号分别是起点和终点，而剩余12个站平均分配在两条流水线上，具体各计算成本如下图：

其中节点权重为v=[0,7,8,9,5,3,6,4,4,8,5,4,7,0]，即代表装配时间，而转移时间表示为矩阵形式：

因为已经将过程打上了stage的标签，我们定义一个状态为(k,i)，表示在第k个阶段的第i条装配线上，那么转移时间就表示为(k,i)->(k+1,j)的一个成本c(k,i,j)。当然由题图可见在同线转移时是没有成本的即c(i,k,k)=0。具体的，定义总成本R(k,i,j)=v(k,i)+c(k,i,j)，其中v(k,i)即i装配线的编号为k的节点权重。定义f(k,i)为状态值，即在k阶段时的i装配线到出产时的总成本，那么DPFE为：f(k,i)=min j{R(k,i,j)+f(k+1,j)}。f(N+1,0)=0是初始条件，表示在最后一个节点时的成本，那么往前递推，f(0,0)作为在起点处的成本就是目标函数，于是f(0,0)=(0+2)+(7+2)+(5+1)+(3+1)+(4+0)+(5+1)+(4+3)=38.

解题程序：

   1: /*

   2:  * Copyright (C) 2013 changedi

   3:  *

   4:  * Licensed under the Apache License, Version 2.0 (the "License");

   5:  * you may not use this file except in compliance with the License.

   6:  * You may obtain a copy of the License at

   7:  *

   8:  * http://www.apache.org/licenses/LICENSE-2.0

   9:  *

  10:  * Unless required by applicable law or agreed to in writing, software

  11:  * distributed under the License is distributed on an "AS IS" BASIS,

  12:  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

  13:  * See the License for the specific language governing permissions and

  14:  * limitations under the License.

  15:  */

  16: package com.jybat.dp;

  17:  

  18: public class ASMBAL {

  19:  

  20:     private static int[][] cost = // (stage,line)

  21:     { 

  22:             { 2, 4 }, // to next line

  23:             { 2, 2 }, { 1, 3 }, { 2, 1 }, { 2, 3 }, { 1, 4 }, // to next line

  24:             { 3, 2 } // from line

  25:     };

  26:     private static int[][] vertexcost = // (stage,line)

  27:     { 

  28:         { 0, 0 }, { 7, 8 }, { 9, 5 }, { 3, 6 }, { 4, 4 }, { 8, 5 }, { 4, 7 } 

  29:     };

  30:     private static int N = vertexcost.length - 1;

  31:  

  32:     private static int arccost(int g, int x, int d) {

  33:         if (g == 0)

  34:             return cost[g][d]; // to next line d

  35:         else if (g == N)

  36:             return cost[g][x]; // from line x

  37:         else if (x == d)

  38:             return 0; // stay same line

  39:         else

  40:             return cost[g][d]; // to next line d

  41:     }

  42:     

  43:     public static double f(int g, int x) {

  44:         if (g > N)

  45:             return 0.0;

  46:         double min = Double.MAX_VALUE;

  47:         for (int d = 0; d <= 1; d++) {

  48:             double c = vertexcost[g][x] + arccost(g, x, d) + f(g + 1, d);

  49:             if (c < min)

  50:                 min = c;

  51:         }

  52:         return min;

  53:     }

  54:     /**

  55:      * @param args

  56:      */

  57:     public static void main(String[] args) {

  58:         System.out.println(f(0,0));

  59:     }

  60:  

  61: }

这个问题的描述很容易让我们想起huffman tree，霍夫曼树是最优二叉树，满足的条件就是节点权值*路径长度，求和后最小。ARC树与霍夫曼树类似，也是二叉树，条件是对所有节点的权值求和后最小，只不过霍夫曼树因为不递归不重叠，所以直接贪心解即可。而ARC树一个明显的特点就是递归包含。所以我们使用动态规划来求解。而前提同huffman一样，需要先对节点权值进行排序。

问题具体化：有4个节点，分别具有权重(2,3,1,4)，现求这四个节点构成的ARC树。解决这个问题的思路就在于，如果是动态规划解，那么构建这个树的方法是如何开始呢？我们知道huffman树是一个经典的自底向上方法，而ARC动态规划要转换为自顶向下。一但思路确定，定义DPFE就很明显了，我们抽象表示定义S=(w0,w1,…wn)，这里的w已经有序，接下来定义状态(i,j)为{wi,…,wj}的子树求和，那么动态规划方程为：f(i,j)=min i≤d<j {c(i,j,d)+f(i,d)+f(d+1,j)} 当i<j。基本条件是f(i,j)=0当i=j时，成本计算函数c(i,j,d)=Σwk k=i,…,j。目标函数是求f(0,n)。我们以中缀括号表示一棵ARC树，那么对于具体化问题的节点集(2,3,1,4)，最后的结果就是(((2,1),3),4)。这棵树的权值为f(S)=(2+1)+((2+1)+3)+(2+1+3+4)=19。

代码如下：

   1: /*

   2:  * Copyright (C) 2013 changedi

   3:  *

   4:  * Licensed under the Apache License, Version 2.0 (the "License");

   5:  * you may not use this file except in compliance with the License.

   6:  * You may obtain a copy of the License at

   7:  *

   8:  * http://www.apache.org/licenses/LICENSE-2.0

   9:  *

  10:  * Unless required by applicable law or agreed to in writing, software

  11:  * distributed under the License is distributed on an "AS IS" BASIS,

  12:  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

  13:  * See the License for the specific language governing permissions and

  14:  * limitations under the License.

  15:  */

  16: package com.jybat.dp;

  17:  

  18: import java.util.Arrays;

  19:  

  20: public class ARC {

  21:  

  22:     private static double[] weight = { 2, 3, 1, 4 };

  23:  

  24:     private static int N = weight.length - 1;

  25:  

  26:     private static double sum(int p, int q) {

  27:         double result = 0.0;

  28:         for (int k = p; k <= q; k++) {

  29:             result += weight[k];

  30:         }

  31:         return result;

  32:     }

  33:     

  34:     public static double f(int firstIndex, int lastIndex){

  35:         if(firstIndex == lastIndex)

  36:             return 0.0;

  37:         double min = Double.MAX_VALUE;

  38:         for(int d=firstIndex;d<lastIndex;d++){

  39:             double t = f(firstIndex,d) + f(d+1,lastIndex) + sum(firstIndex,lastIndex);

  40:             if(t<min)

  41:                 min = t;

  42:         }

  43:         return min;

  44:     }

  45:  

  46:     /**

  47:      * @param args

  48:      */

  49:     public static void main(String[] args) {

  50:         Arrays.sort(weight);

  51:         System.out.println(f(0,N));

  52:     }

  53:  

  54: }

F(k,p,q) = min r∈S{b(p, r)+F(k−1,r,q)},k>0。其中当p=q时，F(0,p,q)=0，当p≠q时，F(0,p,q)=∞，b(p,p)=0，b是路径长度函数。

这样，列出方程，我们可以轻松写递归代码求解问题了。

当然这里还是补充一下Floyd-Warshall算法的状态转移方程：F(k,p,q) = min{F(k−1,p,q),F(k−1,p,k)+F(k−1,k,q)}，其中当p=q时，F(0,p,q)=0，当p≠q时，F(0,p,q)=b(p,q)。可以看出两者的差异，FW算法缩减了SPC问题求解方法的中间变量r，也就是说每次求解min值不需要在一个状态集合里寻求最短，而把min缩小到(k-1,p,q)和(k-1,p,k)+(k-1,k,q)中，这样直接把计算复杂度降了一个量级。

递归Java source code：

   1: /*

   2:  * Copyright (C) 2013 changedi

   3:  *

   4:  * Licensed under the Apache License, Version 2.0 (the "License");

   5:  * you may not use this file except in compliance with the License.

   6:  * You may obtain a copy of the License at

   7:  *

   8:  * http://www.apache.org/licenses/LICENSE-2.0

   9:  *

  10:  * Unless required by applicable law or agreed to in writing, software

  11:  * distributed under the License is distributed on an "AS IS" BASIS,

  12:  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

  13:  * See the License for the specific language governing permissions and

  14:  * limitations under the License.

  15:  */

  16: package com.jybat.dp;

  17:  

  18: public class APSP {

  19:  

  20:     private static final int INF = Integer.MAX_VALUE;

  21:  

  22:     // nodes (s,x,y,t) = {0,1,2,3}, so (s,x) = 3 means d[0][1] = 3

  23:     private static int[][] distance = { 

  24:         { INF, 5,      3,     INF }, 

  25:         { INF, INF, 2,     5 },

  26:         { INF, 1,       INF, 8 }, 

  27:         { INF, INF, INF, INF } 

  28:     };

  29:     

  30:     private static int maxNodeIndex = distance.length-1;

  31:     

  32:     private static int[] possibleSuccessors = { 0, 1 };

  33:     

  34:     public static double f(int k, int p, int q) {

  35:         if (k == 0 && p == q)

  36:             return 0;

  37:         if (k == 0 && p != q)

  38:             return distance[p][q];

  39:         double min = Double.MAX_VALUE;

  40:         for (int d : possibleSuccessors) {

  41:             double t = (1 - d) * f(k - 1, p, q) + d * f(k - 1, p, k) + d

  42:                     * f(k - 1, k, q);

  43:             if (t < min)

  44:                 min = t;

  45:         }

  46:         return min;

  47:     }

  48:     /**

  49:      * @param args

  50:      */

  51:     public static void main(String[] args) {

  52:         System.out.println(f(maxNodeIndex,0,3));

  53:     }

  54:  

  55: }

我们把问题具体化，有4个苹果，要分给3个小朋友，小朋友按照1-3编号，每个小朋友拿到一定个数苹果后会哭闹一段时间（因为他们是小朋友，所以会哭闹），具体时间表如下：

C(k,d)=[

            ∞,1.0,0.8,0.4,0.0

            ∞,1.0,0.5,0.0,0.0

            ∞,1.0,0.6,0.3,0.0

           ], 1≤k≤3, 0≤d≤4

k是小朋友编号，d是分给小朋友的苹果数，可以看到，当分给小朋友0个苹果时（不分苹果），那么小朋友会无休止的哭闹，而把全部（4个）苹果全部分给一个小朋友时，小朋友不会哭闹（0时间）。那么根据这个时间，提供一个最优的分苹果方案，使得小朋友们拿到苹果后的哭闹时间最短。

那么，根据这个具体问题，我们抽象的结果就是f(1,4)=1.0+0.5+1.0=2.5，最优分布是d1=1.0，d2=0.5，d3=1.0，这样的分配方案。具体解法见source code：

   1: /*

   2:  * Copyright (C) 2013 changedi

   3:  *

   4:  * Licensed under the Apache License, Version 2.0 (the "License");

   5:  * you may not use this file except in compliance with the License.

   6:  * You may obtain a copy of the License at

   7:  *

   8:  * http://www.apache.org/licenses/LICENSE-2.0

   9:  *

  10:  * Unless required by applicable law or agreed to in writing, software

  11:  * distributed under the License is distributed on an "AS IS" BASIS,

  12:  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

  13:  * See the License for the specific language governing permissions and

  14:  * limitations under the License.

  15:  */

  16: package com.jybat.dp;

  17:  

  18: import java.util.HashMap;

  19: import java.util.Map;

  20:  

  21: public class ALLOT {

  22:  

  23:     private static int N = 3;

  24:     private static int M = 4;

  25:     

  26:     private static final double INF=Double.MAX_VALUE;

  27:     

  28:     private static Map<Integer,Integer> choices = new HashMap<Integer,Integer>();

  29:     

  30:     private static final double [][] c = {

  31:         {INF,1.0,0.8,0.4,0.0},

  32:         {INF,1.0,0.5,0.0,0.0},

  33:         {INF,1.0,0.6,0.3,0.0}

  34:     };

  35:     

  36:     private static double cost(int k, int d) {

  37:         return c[k-1][d];

  38:     }

  39:     

  40:     public static double f(int k, int m){

  41:         if(k>N&&m>=0) return 0.0;

  42:         else{

  43:             double mm = Double.MAX_VALUE;

  44:             int dispatch = -1;

  45:             for(int d=0;d<=m;d++){

  46:                 double t = cost(k,d)+f(k+1,m-d);

  47:                 if(t<mm) {

  48:                     mm = t;

  49:                     dispatch = d;

  50:                 }

  51:             }

  52:             if(!choices.containsKey(k))

  53:                 choices.put(k, Integer.MAX_VALUE);

  54:             if(mm<choices.get(k))

  55:                 choices.put(k,dispatch);                

  56:             return mm;

  57:         }

  58:     }

  59:     /**

  60:      * @param args

  61:      */

  62:     public static void main(String[] args) {

  63:         double minCost = f(1,M);

  64:         System.out.println("min cost is : "+minCost);

  65:         System.out.print("solution is : ");

  66:         for(int i=1;i<=N;i++){            

  67:             System.out.print(choices.get(i));

  68:             if(i<N)

  69:                 System.out.print(",");

  70:         }

  71:     }

  72:  

  73: }

PS:因为考虑到这里的选择不是很长的代码，可能不影响理解DP，所以把记录选择方案的代码也加进来了。

hbase.rpc.server.engine：hbase 做rpc server的调度管理类，实现自org.apache.hadoop.ipc.RpcServerEngine，默认是org.apache.hadoop.hbase.ipc.ProtobufRpcServerEngine；

hbase.rpc.timeout：Hbase client发起远程调用时的超时时限，使用ping来确认连接，但是最终会抛出一个TimeoutException，默认值是60000；

hbase.rpc.shortoperation.timeout：另一个版本的hbase.rpc.timeout，控制短操作的超时时限，比如region server 汇报master的操作的超时时限可以设置小，这样有利于master的failover，默认是10000；

hbase.ipc.client.tcpnodelay：默认是true，具体就是在tcp socket连接时设置 no delay；

hbase.master.keytab.file：kerberos keytab 文件的全路径名，用来为HMaster做log，无默认值；

hbase.master.kerberos.principal：运行HMaster进程时需要kerberos的principal name，这个配置就是这个name的值，形如：hbase/_HOST@EXAMPLE.COM；

hbase.regionserver.keytab.file：kerberos keytab 文件的全路径名，用来为HRegionServer做log，无默认值；

hbase.regionserver.kerberos.principal：运行HRegionServer进程时需要kerberos的principal name，这个配置就是这个name的值，形如：hbase/_HOST@EXAMPLE.COM；

hadoop.policy.file：RPC服务器做权限认证时需要的安全策略配置文件，在Hbase security开启后使用，默认是habse-policy.xml；

hbase.superuser：Hbase security 开启后的超级用户配置，一系列由逗号隔开的user或者group；

hbase.auth.key.update.interval：Hbase security开启后服务端更新认证key的间隔时间：默认是86400000毫秒；

hbase.auth.token.max.lifetime：Hbase security开启后，认证token下发后的生存周期，默认是604800000毫秒；

hbase.ipc.client.fallback-to-simple-auth-allowed：client使用安全连接去链接一台非安全服务器时，服务器提示client切换到SASL SIMPLE认证模式（非安全），如果设置为true，则client同意切换到非安全连接，如果false，则退出连接；

hbase.coprocessor.region.classes：逗号分隔的Coprocessores列表，会被加载到默认所有表上。在自己实现了一个Coprocessor后，将其添加到Hbase的classpath并加入全限定名。也可以延迟加载，由HTableDescriptor指定；

hbase.rest.port：Hbase REST服务器的端口，默认是8080；

hbase.rest.readonly：定义REST服务器启动的模式，有两种方式，false：所有http方法都将被通过-GET/PUT/POST/DELETE，true：只有get方法ok。默认值是false；

hbase.rest.threads.max：REST服务器线程池的最大线程数，池满的话新请求会自动排队，限制这个配置可以控制服务器的内存量，预防OOM，默认是100；

hbase.rest.threads.min：同上类似，最小线程数，为了确保服务器的服务状态，默认是2；

hbase.rest.support.proxyuser：使REST服务器支持proxy-user 模式，默认是false；

hbase.defaults.for.version.skip：是否跳过hbase.defaults.for.version的检查，默认是false；

hbase.coprocessor.master.classes：由HMaster进程加载的coprocessors，逗号分隔，全部实现org.apache.hadoop.hbase.coprocessor.MasterObserver，同coprocessor类似，加入classpath及全限定名；

hbase.coprocessor.abortonerror：如果coprocessor加载失败或者初始化失败或者抛出Throwable对象，则主机退出。设置为false会让系统继续运行，但是coprocessor的状态会不一致，所以一般debug时才会设置为false，默认是true；

hbase.online.schema.update.enable：设置true来允许在线schema变更，默认是true；

hbase.table.lock.enable：设置为true来允许在schema变更时zk锁表，锁表可以组织并发的schema变更导致的表状态不一致，默认是true；

hbase.thrift.minWorkerThreads：线程池的core size，在达到这里配置的量级后，新线程才会再新的连接创立时创建，默认是16；

hbase.thrift.maxWorkerThreads：顾名思义，最大线程数，达到这个数字后，服务器开始drop连接，默认是1000；

hbase.thrift.maxQueuedRequests：Thrift连接队列的最大数，如果线程池满，会先在这个队列中缓存请求，缓存上限就是该配置，默认是1000；

hbase.thrift.htablepool.size.max：Thrift服务器上table pool的最大上限，默认是1000；

hbase.offheapcache.percentage：JVM参数-XX:MaxDirectMemorySize的百分比值，默认是0，即不开启堆外分配；

hbase.data.umask.enable：开启后，文件在regionserver写入时会 有权限相关设定，默认是false不开启；

hbase.data.umask：开启上面一项配置后，文件的权限umask，默认是000；

hbase.metrics.showTableName：是否为每个指标显示表名前缀，默认是true；

hbase.metrics.exposeOperationTimes：是否进行关于操作在使用时间维度的指标报告，比如GET PUT DELETE INCREMENT等，默认是true；

hbase.snapshot.enabled：是否允许snapshot被使用、存储和克隆，默认是true；

hbase.snapshot.restore.take.failsafe.snapshot：在restore过程中，如果失败则启用snapshot替换，成功则删除掉snapshot，默认开启true；

hbase.snapshot.restore.failsafe.name：刚才所说过程中snapshot的名字，默认是hbase-failsafe-{snapshot.name}-{restore.timestamp}；

hbase.server.compactchecker.interval.multiplier：检查是否需要compact的时间间隔，一般情况是在比如memstore flush后或者其他事件触发compact的，但是有时也需要不同的compact策略，所以需要周期性的检查具体间隔=hbase.server.compactchecker.interval.multiplier * hbase.server.thread.wakefrequency，默认1000；

hbase.lease.recovery.timeout：在dfs 租约超时时限，超时则放弃，默认是900000；

hbase.lease.recovery.dfs.timeout：dfs恢复租约调用的超时时限，默认是64000；

对于一个无环图来讲（有环图后面讲到），一个起始节点为s，一个目标节点为t，DPFE为：f(p) = min q{ b(p,q) + f(q)}，其中b(p,q)是从p到q的距离，f(p)是从p到t的最短路径，另外这里的p是q的前驱节点，如果p不是q的直接前驱，那么b(p,q)=∞。而目标函数就是求 f(s)，base condition就是f(t)=0。

那么举例如下：一个有向无环图，其有四个节点，集合为{s,x,y,t}，五条边，边集合为{(s,x), (s,y), (x,y), (x,t), (y,t)}，长度为{3,5,1,8,5}。那么求从s到t的最短路径。

首先使每个节点都有到t的边，如果没有的，加一条虚拟边，长度为∞，即(s,t)=∞。DPFE为：f(s) = min{b(s,x)+f(x), b(s,y)+f(y), b(s,t)+f(t)}，f(x) = min{b(x,y)+f(y), b(x,t)+f(t)}，f(y) = min{b(y,t)+f(t)}，f(t)=0。依次代入，得到f(y)=min{5+0}=5，f(x)=min{1+5,8+0}=6，f(s)=min{3+6,5+5,∞+0}=9。

因此最短路径长度为9，路径为s->x->y->t。

代码是经典的最短路代码，使用邻接矩阵来表示一个有向无环图，这里仍然用一个递归函数来简化：

   1: /*

   2:  * Copyright (C) 2013 changedi

   3:  *

   4:  * Licensed under the Apache License, Version 2.0 (the "License");

   5:  * you may not use this file except in compliance with the License.

   6:  * You may obtain a copy of the License at

   7:  *

   8:  * http://www.apache.org/licenses/LICENSE-2.0

   9:  *

  10:  * Unless required by applicable law or agreed to in writing, software

  11:  * distributed under the License is distributed on an "AS IS" BASIS,

  12:  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

  13:  * See the License for the specific language governing permissions and

  14:  * limitations under the License.

  15:  */

  16: package com.jybat.dp;

  17:  

  18: import java.util.HashSet;

  19: import java.util.Set;

  20:  

  21: public class ShortestPathAcyclic {

  22:  

  23:     private static final int INF = Integer.MAX_VALUE;

  24:  

  25:     // nodes (s,x,y,t) = {0,1,2,3}, so (s,x) = 3 means d[0][1] = 3

  26:     private static int[][] distance = { 

  27:         { INF, 3,      5,     INF }, 

  28:         { INF, INF, 1,     8 },

  29:         { INF, INF, INF, 5 }, 

  30:         { INF, INF, INF, INF } 

  31:     };

  32:  

  33:     private static Set<Integer> possibleNextNodes(int node) {

  34:         Set<Integer> result = new HashSet<Integer>();

  35:         for (int i = 0; i < distance[node].length; i++) {

  36:             if (distance[node][i] != INF) {

  37:                 result.add(new Integer(i));

  38:             }

  39:         }

  40:         return result;

  41:     }

  42:     

  43:     public static double f(int currentNode){

  44:         if(currentNode==3) return 0.0;

  45:         else{

  46:             Set<Integer> possibleSuccessors = possibleNextNodes(currentNode);

  47:             double min = Double.MAX_VALUE;

  48:             for(Integer d : possibleSuccessors){

  49:                 double dis = distance[currentNode][d]+f(d);

  50:                 if(dis<min) {

  51:                     min = dis;

  52:                 }

  53:             }

  54:             return min;

  55:         }

  56:     }

  57:  

  58:     /**

  59:      * @param args

  60:      */

  61:     public static void main(String[] args) {

  62:         double shortest = f(0);

  63:         System.out.println(shortest);

  64:     }

  65:  

  66: }

在进入第一个问题之前，先简单介绍一下动态规划（以下简称DP）。第一次知道动态规划不是在大学的算法课上，就是在读经典的《算法导论》里，动态规划解决的问题主要是最优决策问题，就是说在一个目标问题下，需要一系列的操作决策来达到目标，那么最优化的决策是哪个，就是动态规划解决的问题。而我们一般提到最优化，无非最低成本、最高收益等可以通过定义一个函数来量化的东西。更深入的理解我们可能需要先把动态规划的过程抽象化符号化，但是我个人认为理解到这个层次就进了象牙塔，对于实际解决问题太过深奥晦涩，于是一个总结性的抽象化是：H*=(opt (h [d1,d2,…,dn]∈ Δ))  ，opt是最优函数、h是目标函数、d1-dn是一系列决策、Δ是全局决策空间，那么这个表示的含义就是在所有决策中找到一组最优决策满足目标函数h。动态规划问题的一个通用特点是具备最优子结构和重叠子问题，最优子结构可以这么理解，目标问题是可以拆分的，比如最短路问题中，你要从a到b的最短路径，这个最短路径包含了子路径从a到c的最短……。重叠子问题同样拿最短路问题举例，那就是你要求从a到b的最短路径，那么其中有多重选择，你可以选a到c再从c到b，也可以选a直接到b或者更多，而这些路径选择中，重叠情况不断出现……

具体在动态规划解决问题时的一些表示和说明，我们在描述问题的过程中边描述边解说。

下面举例来剖析求解动态规划问题。

问题1：线性搜索（Linear Search）

描述：一个数组A包含N个元素，每个元素x有权重px，有一个成本函数来计算一种排列的排列成本，线性搜索的目标是做到最小化成本来找出一个数组A的排列。

举例：A={a,b,c}，pa=0.2，pb=0.5，pc=0.3；数组A共有6种排列，abc,acb,bac,bca,cab,cba。成本的计算方式是1*c1 + 2*c2 + 3*c3。即对应位置的元素优先级乘位置数，比如对于排列bca来说，成本就是1*pb+2*pc+3*pa=1.7 。

问题规范化和求解：我们首先定义状态S作为备选的元素集合，那么接下来的目标就是要做一系列决策决定哪个元素该摆在哪个位置。DPFE（动态规划方程）可以帮助我们更好的理解这个优化问题，DPFE的基本形式是f(S)=opt d∈D(S){R(S,d) o f(T(S,d))}. 其中S是状态空间的状态，d是一个从决策空间D(S)中选出的决策，R(S,d)是价值函数（reward function或者称为决策成本，也表示为C(d|S)），T(S,d)是下一个状态的状态转移函数，o是一个二元操作符。具体解释一下DPFE中的每个元素的含义，S作为状态，因为动态规划解决的问题是需要一系列决策的，S就是表示到当前决策时的问题状态；D(S)是决策空间，代表从一个状态到另一个状态转移时，可以选择的决策d的集合；f是目标函数，是关于状态S的函数，代表到达状态S所做的所有决策产生的最优利益或者最低成本；价值函数R(S,d)是个从状态S做下一个决策d所带来的收益或成本的计算函数，区别于f，它是一个单步的计算函数；T(S,d)是个转移函数，表示从S做下一个决策d所带来的结果；o作为二元操作符，多数是加法或者乘法及最大最小值等，为了将决策合并起来。因为DPFE是一个递归的形式，所以需要一个base condition作为递归的结束条件。另外DPFE可能会有高阶形式，对于某些复杂问题，形式可能是f(S)=opt d∈D(S){R(S,d) o f(T1(S,d)) o f(T2(S,d))} 这样的二阶形式或者是带有权重的f(S)=opt d∈D(S){R(S,d) o p1*f(T1(S,d)) o p2*f(T2(S,d))} 形式。

回到这个问题，本问题的DPFE 形式为 f(S) = min { C(x|S) + f(S-{x})}，其中C(x|S)成本函数已经定义，C(x|S)= (N+1-|S|) * px。于是我们可以递归来描述这个过程了，这里用到一个反向搜索的方法，先从排列的最后开始向前查找。

首先base condition f(φ)=0，就是说空集的成本就是0 。

然后对于单项集合，a作为最后一个元素，f({a}) = min {C(a|{a})+f(φ)} = min {3*0.2+0} = 0.6；

b作为最后一个元素，f({b}) = min {C(b|{b})+f(φ)} = min {3*0.5+0} = 1.5；

c作为最后一个元素，f({c}) = min {C(b|{b})+f(φ)} = min {3*0.3+0} = 0.9；

依次类推，f({a,b}) = min {C(a|{a,b})+f({b}), C(b|{a,b})+f({a})} = min {2*0.2+1.5, 2*0.5+0.6} = 1.6；

f({a,c}) = min {C(a|{a,c})+f({c}), C(c|{a,c})+f({a})} = min {2*0.2+0.9, 2*0.3+0.6} = 1.2；

f({b,c}) = min {C(b|{b,c})+f({c}), C(c|{b,c})+f({b})} = min {2*0.5+0.9, 2*0.3+1.5} = 1.9；

f({a,b,c}) = min {C(a|{a,b,c})+f({b,c}), C(b|{a,b,c})+f({a,c}), C(c|{a,b,c})+f({a,b})} = min {1*0.2+1.9, 1*0.5+1.2, 1*0.3+1.6} = 1.7

所以，最优答案是1.7，并且组合方式是bac。好吧，问题得解了。

换一个解法思路：状态转移图模型（State Transition Graph Model），同DPFE方法一致，只不过状态转移图更直观，状态转移图对每一个状态S当做一个节点，f(S)就是S到达φ的最短路径，之前的标准解法是从后向前的计算思路，而STGM是从前向后的计算思路，形式等价于标准，只不过方程变化一下：f’(S)=min {f’(S’) + C(x|S’)}。其中S’是一个由x决策导致状态S的前置节点，也就是说S’->S （条件是x决策）。并且f’(S)是源节点S*到S的最短路径，最终目标函数是f’(φ)，起始状态是 S*={a,b,c}。

所以整个搜索过程如下：

f’({a,b,c})=0；

f’({b,c}) = min {f’({a,b,c})+C(a|{a,b,c}) } = min{0+0.2} = 0.2；

f’({a,c}) = min {f’({a,b,c})+C(b|{a,b,c}) } = min{0+0.5} = 0.5；

f’({a,b}) = min {f’({a,b,c})+C(c|{a,b,c}) } = min{0+0.3} = 0.3；

f’({c}) = min {f’({b,c})+C(b|{b,c}), f’({a,c})+C(a|{a,c}) } = min{0.2+2*0.5,0.5+2*0.2} = 0.9；

f’({b}) = min {f’({a,b})+C(a|{a,b}), f’({b,c})+C(c|{b,c}) } = min{0.3+2*0.2,0.2+2*0.3} = 0.7；

f’({a}) = min {f’({a,b})+C(b|{a,b}), f’({a,c})+C(c|{a,c}) } = min{0.3+2*0.5,0.5+2*0.3} = 1.1；

f’(φ) = min {f’({a})+C(a|{a}), f’({b})+C(b|{b}), f’({c})+C(c|{c}) } = min{1.1+3*0.2, 0.7+3*0.5, 0.9+3*0.3} = 1.7；

过程已经比较清晰了，更直白的理解就是，倒着数，对于这个集合，排列好后的路径长度是0，有两个已经排列好，剩下放到第一个位置的选择的最小路径，有一个已经排列好，剩下放到前两个的选择的最小路径……有0个已经排列好，剩下放到前3个的选择的最小路径，迭代计算即可。

再换一个思路：阶段决策（Stage Decision），这是个顺序决策过程，分阶段，第一阶段决定放在第一个位置的元素是什么，依次类推。方程转变为：f(k,S)=min{C(x|k,S)+f(k+1,S-{x})}。其中k是阶段标识，base condition为f(N+1 , φ)=0，目标函数是f(1,A)，因为k=N+1-|S|，所以成本函数C(x|k,S)=(N+1-|S|)*px=k * px。

整个过程如下：

f(1,{a,b,c}) = min {C(a|1,{a,b,c})+f(2,{b,c}), C(b|1,{a,b,c})+f(2,{a,c}), C(c|1,{a,b,c})+f(2,{a,b})}

                  = min {3*0.2+1.1, 3*0.5+0.7, 3*0.3+0.9} = 1.7；

f(2,{b,c}) = min {C(b|2,{b,c})+f(3,{c}), C(c|2,{b,c})+f(3,{b})} = min{2*0.5+0.3,2*0.3+0.5}=1.1；

f(2,{a,c}) = min {C(a|2,{a,c})+f(3,{c}), C(c|2,{a,c})+f(3,{a})} = min{2*0.2+0.3,2*0.3+0.2}=0.7；

f(2,{a,b}) = min {C(a|2,{a,b})+f(3,{b}), C(b|2,{a,b})+f(3,{a})} = min{2*0.2+0.5,2*0.5+0.2}=0.9；

f(3,{a}) = min {C(a|3,{a})+f(4,φ)} = min{0.2+0} = 0.2；

f(3,{b}) = min {C(b|3,{b})+f(4,φ)} = min{0.5+0} = 0.5；

f(3,{c}) = min {C(c|3,{c})+f(4,φ)} = min{0.3+0} = 0.3；

f(4,φ) = 0；

反向代入后，得解 f(1,{a,b,c}) = 1.7 。

最后再介绍一种图论的思想：如果把S定义为从源头一直到决策d的一系列决策集(d1,d2,…,di-1)，S作为一个图的节点的话，图的每个节点都表示了从初始状态φ到S的一个路径（Path-States）。那么方程变为：f(S) = min x∉S {C(x|S) + f(S ∪ {x})}。这个其实是等同于状态转移图的另一种表示。

至此，已经通过第一个简单的问题，得到了4种（其实是2种，一种直观的，一种图论的）描述动态规划问题求解策略的方法了，分别是Stage Decision 和 State Transition Graph Model。未来会有更多的动态规划问题通过这些方法来求解。

最后再附上这个问题的一个函数代码：不出意外，所有的过程都以Java代码来实现描述。

source code:

   1: /*

   2:  * Copyright (C) 2013 changedi

   3:  *

   4:  * Licensed under the Apache License, Version 2.0 (the "License");

   5:  * you may not use this file except in compliance with the License.

   6:  * You may obtain a copy of the License at

   7:  *

   8:  * http://www.apache.org/licenses/LICENSE-2.0

   9:  *

  10:  * Unless required by applicable law or agreed to in writing, software

  11:  * distributed under the License is distributed on an "AS IS" BASIS,

  12:  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

  13:  * See the License for the specific language governing permissions and

  14:  * limitations under the License.

  15:  */

  16: package com.jybat.dp;

  17:  

  18: import java.util.HashMap;

  19: import java.util.HashSet;

  20: import java.util.Map;

  21: import java.util.Set;

  22:  

  23: public class LinearSearch {

  24:  

  25:     int N = 3;

  26:     Map<String,Double> map = new HashMap<String,Double>();

  27:  

  28:     public LinearSearch(){

  29:         map.put("a", 0.2);

  30:         map.put("b", 0.5);

  31:         map.put("c", 0.3);

  32:     }

  33:     public void dp() {

  34:         Set<String> A = new HashSet<String>();

  35:         for (String k : map.keySet()) {

  36:             A.add(k);

  37:         }

  38:         System.out.println(f(A));

  39:     }

  40:  

  41:     private double cost(String x, Set<String> A) {

  42:         return map.get(x) * (N + 1 - A.size());

  43:     }

  44:  

  45:     private double f(Set<String> A) {

  46:         double fx = Double.MAX_VALUE;

  47:         if(A.isEmpty()){

  48:             fx = 0;

  49:         }

  50:         else{

  51:             for(String key : A){

  52:                 Set<String> A1 = new HashSet<String>();

  53:                 for(String ik : A){

  54:                     A1.add(ik);

  55:                 }

  56:                 A1.remove(key);                

  57:                 double tmp = cost(key,A) + f(A1);

  58:                 if(tmp<fx)

  59:                     fx = tmp;

  60:             }

  61:         }

  62:         return fx;

  63:     }

  64:  

  65:     public static void main(String[] args) {

  66:         LinearSearch ls = new LinearSearch();

  67:         ls.dp();

  68:     }

  69:  

  70: }

    2013已经成了历史的一个数字，在各种数据总结、趋势图表、红包鞭炮、酒席宴请弥漫的后春节状态下，终于回到公司，坐在清冷的办公室，冲一杯咖啡，键盘和聊天声中，开始静静的回忆过去的一年。

    3年一个坎儿，也许不假，2013是我最频繁想起跳槽、转行、辞职的一年，为什么？我把它归罪于3年这个坎儿。工作3年整了，在一家公司，一个部门，做着很多类似的事情，有这些想法……正常。先插一段故事，从年前到家到年后的各类聚会，总结起来比上班还累，天天吃肉喝酒，处处谈论着本不感兴趣却不得不谈的现实，开始总跟人抱怨在外地工作辛苦，天天加班拼命，上班路堵不方便，生活成本高，周六日没休息等等。后来所见所想，看着各有各的辛苦，各有各的烦恼，明白抱怨解决不了问题，抱怨只会让大家知道你在外面混的很苦而已……徒劳的。回到正题，总结2013，先谈积极的，生活上，孩子健康成长，父母健康平安，房子按期装修，一切都正常运转按部就班，只是花钱如流水，年底混个0的开始，不过还是很欣慰，一切蛮顺利的。总结总是谈工作更多，那我也就更多的说说工作。

    工作好像不那么顺利了，进入了一个很奇怪的循环，也许别人不觉得，但是我自己把现在的状态称作一种尴尬的境地。这一年，在互联网技术这个圈子里，我尝试了4种岗位，2013之前，我是一个专职的Java开发工程师，我关注的是服务端应用的架构设计、代码质量、并发和可扩展，但是到2013年底，我感觉自己成了一个时下流行的ASE——全栈工程师（All Stack Engineer），这种转变是因为团队缺乏“资源”而被逼出来的，年初产品改版，全站大换血，没前端资源，没办法，在借了个前端做了2周demo和组件的前提下，我带着一个开发兄弟“成为”了前端，写js，写css，后来css变成了less，js也需要自己做前端组件，1个月后，我们真的成为了前端，这时候的我，开始关注数据可视化组件（了解d3和raphael），前端模块化（seajs），前端开发模式(前端OOP)和架构等，看两遍犀牛书已经满足不了我的需求，更多的js书籍进入了我的reading list。项目在快速的迭代后进入稳定，新的需求也可以快速的被完成（因为我们俩已经算是前端熟手了），而后开发人员补充一倍，机器扩容，一切看上去都开始正常。这时一个新的数据项目起步，再次面临“资源”紧张，不过这次缺的不是software engineer，而是data algorithm engineer。于是我也重复了这次紧张，进入到数据开发的角色中。数据开发其实是个有意思的角色，关注点主要是写sql，但是在大数据背景下，hadoop要非常熟悉，要理解整个生态，数据开发不是单纯的ETL，写写hive或者pig的ql，而是在结合业务的前提下设计出出色的数据架构，数据架构看上去很虚，但是其作用不亚于软件开发中的架构设计。从某种角度讲，在大数据背景下，好的数据架构起到的作用更大，直观上讲能节省大量的成本。本来数据这块角色可以分很细的，但是同样由于“资源”的问题，我承担了全部的工作，当然学习起步阶段得到了不少同事的帮助，同时也得感谢公司的大数据平台的简单易用让大数据这种比较有技术含量的东西可以轻易的被工程师使用。总的来说，2013后半年进入到数据领域，开始各种数据开发尝试。这一切看上去还挺不错的，但其实麻烦在于业务，业务发展过于变动和快速，导致工程师做东西都是填补型甚至是一次性产品，比如前后端开发成了copy&paste，数据开发沦为了copy&paste型的ETL，结构层次不清晰，毫无架构可言。在短时间内开发高质量产品本来是个悖论，又经历长期的加班和强制性的公司政策，这是在束缚创造力和打压创新精神……

     于是，作为一个ASE，我们可能热衷于一切可能改变世界的技术，但是产品落地一定依托于某些业务，而业务往往是关键点，所以，真正的循环悖论是我们在不断的重复失败的业务，而技术的轮子由成功的业务驱动，于是周而复始，眼见别人的成功，而无能为力改变自己，这应该算是某类工程师的悲哀吧，我们可以轻易的实现各种算法，可以写大量的Java来实现控制业务逻辑，迅速的组织页面html+css+js来可视化，可以熟练的写成MR或者hive sql在大数据平台下查找数据，甚至可以轻松的把这一切全部一肩扛起，但是~~~我们改变不了产品失败的命运……

    In my opinion，我们不应该仅仅是为了公司的股票和工资在做事，不能只是因为一次涨薪、一次红包、一次配股而努力，既然选择了，那么这是一份事业——a career not only a job。3年前我放弃导师的博士学位邀约，进入大公司成为了一名普通工程师，3年后，是否要放弃大公司的庸碌而重拾自我？忙碌过后、重新思考，如果这仅仅是工作，那么趁着还不老，追寻自己的梦想吧。

    就写这么多吧，总结这东西写起来总没个关注点，洋洋洒洒的，哦对了，最近流行的文体是北上广深究竟给了你什么？好吧，我不在以上四地，但是就杭州来说，我这3年，没想清楚杭州究竟给了我什么。但是我心中有个答案，你不在这些地方存在过，你永远不知道答案。

hbase.client.write.buffer：htable客户端写缓冲区大小，默认是2097152BYTE，这个缓冲区就是为了写数据的临时存放，设置大了，浪费客户端和服务端的存储，设置小了，如果写的数据多，太多的RPC又带来网络开销，官方给的一个服务端存储耗费评估计算是：hbase.client.write.buffer*hbase.regionserver.handler.count，服务端的rs的处理handler个数也很关键；

hbase.client.pause：pause时长，在hbase发生get或其他操作fail掉的时候进行pause的时间长度，默认是100；

hbase.client.retries.number：发生操作fail时的重试次数，结合上一个指标一起来控制总的重试时间，默认是35；

hbase.client.max.total.tasks：一个HTable实例可以提交给集群的最大并发任务数，默认是100；

hbase.client.max.perserver.tasks：一个HTable实例给一台regionserver提交的最大并发任务数，默认是5；

hbase.client.max.perregion.tasks：客户端连接一台region的最大连接数，换句话说，当你有这么多个连接在region时，新的操作不被发送直到有操作完成，默认是1；

hbase.client.scanner.caching：做scanner的next操作时（如果再本地client没找到）缓存的数据行数，这个值的设置也需要权衡，缓存的多则快，但吃内存，缓存的少则需要多的拉数据， 需要注意的事项是如果两次调用的时间差大于scanner的timeout，则不要设置该值，默认是100；

hbase.client.keyvalue.maxsize：一个KeyValue实例的最大大小，这是存储文件中一个entry的容量上限，合理的设置这个值可以控制regionserver的split，split不会拆keyvalue，所以把keyvalue的大小设置为regionserver大小的一个比例分数（可除）是个不错的选择，默认是10485760；

hbase.client.scanner.timeout.period：结合刚才的caching做的一个，scanner的超时时间，默认是60000毫秒；

hbase.client.localityCheck.threadPoolSize：做localityCheck的线程池大小，默认是2；

hbase.bulkload.retries.number：做bulk load的最大重试次数，默认是0，即代表不断重试；

hbase.balancer.period：Master运行balancer的周期，默认是300000毫秒；

hbase.regions.slop：如果有regionserver的region数目超过average+(average*slop)，则rebalance，默认是0.2；

hbase.server.thread.wakefrequency：服务线程的sleep时间，默认10000毫秒，比如log roller；

hbase.server.versionfile.writeattempts：退出前写 version file的重试次数，默认3，每次尝试的间隔由上一个参数控制；

hbase.hregion.memstore.flush.size：Memstore写磁盘的flush阈值，超过这个大小就flush，默认是134217728；

hbase.hregion.preclose.flush.size：如果一个region的memstore的大小等于或超过这个参数的量，在关闭region时（放置关闭flag），要提前flush，然后region关闭下线，默认大小是5242880；

hbase.hregion.memstore.block.multiplier：如果memstore的大小满足hbase.hregion.block.memstore * hbase.hregion.flush.size个byte，那么阻塞update，这个配置可以避免不必要的长时间split或者compact，甚至是OOME，默认是2；

hbase.hregion.memstore.mslab.enabled：开启MemStore-Local Allocation Buffer，这个配置可以避免在高写入的情况下的堆内存碎片，可以降低在大堆情况下的stop-the-world GC频率，默认是true；

hbase.hregion.max.filesize：HStoreFile的最大尺寸，换句话说，当一个region里的列族的任意一个HStoreFile超过这个大小，那么region进行split，默认是10737418240；

hbase.hregion.majorcompaction：一个region的所有HStoreFile进行major compact的时间周期，默认是604800000 毫秒（7天）；

hbase.hregion.majorcompaction.jitter：major compaction的发生抖动范围，这么理解比较容易，就是说上一个参数不是一个严格周期，会有个抖动，这个参数就是这个抖动的比例，默认是0.5；

hbase.hstore.compactionThreshold：一个HStore存储HStoreFile的个数阈值，超过这个阈值则所有的HStoreFile会被写到一个新的HStore，需要平衡取舍，默认是3；

hbase.hstore.blockingStoreFiles：一个HStore存储HStoreFile阻塞update的阈值，超过这个阈值，HStore就进行compaction，直到做完才允许update，默认是10；

hbase.hstore.blockingWaitTime：一个更强力的配置，配合上一个参数，当HStore阻塞update时，超过这个时间限制，阻塞取消，就算compaction没有完成，update也不会再被阻塞，默认是90000毫秒；

hbase.hstore.compaction.max：每个minor compaction的HStoreFile个数上限，默认是10；

hbase.hstore.compaction.kv.max：在flushing或者compacting时允许的最大keyvalue个数，如果有大的KeyValue或者OOME的话则配置一个小的值，如果行数多且小则配置大值，默认是10；

hbase.storescanner.parallel.seek.threads：如果并行查找开启的线程池大小，默认是10；

hfile.block.cache.size：一个配置比例，允许最大堆的对应比例的内存作为HFile和HStoreFile的block cache，默认是0.4，即40%，设置为0则disable这个比例，不推荐这么做；

hfile.block.index.cacheonwrite：在index写入的时候允许put无根（non-root）的多级索引块到block cache里，默认是false；

hfile.index.block.max.size：在多级索引的树形结构里，如果任何一层的block index达到这个配置大小，则block写出，同时替换上新的block，默认是131072；

hfile.format.version：新文件的HFile 格式版本，设置为1来测试向后兼容，默认是2；

hfile.block.bloom.cacheonwrite：对于组合布隆过滤器的内联block开启cache-on-write，默认是false；

io.storefile.bloom.block.size：一个联合布隆过滤器的单一块（chunk）的大小，这个值是一个逼近值，默认是131072；

hbase.rs.cacheblocksonwrite：当一个HFile block完成时是否写入block cache，默认是false；

hbase.tmp.dir：本地文件系统的临时目录，默认是${java.io.tmpdir}/hbase-${user.name}；

hbase.rootdir：hbase持久化的目录，被所有regionserver共享，默认${hbase.tmp.dir}/hbase，一般设置为hdfs://namenode.example.org:9000/hbase类似，带全限定名；

hbase.cluster.distributed：hbase集群模式运作与否的标志，默认是false，开启需要设置为true，false时启动hbase会在一个jvm中运行hbase和zk；

hbase.zookeeper.quorum：重要的也是必须设置的，启动zk的服务器列表，逗号分隔，cluster模式下必须设置，默认是localhost，hbase客户端也需要设置这个值去访问zk；

hbase.local.dir：本地文件系统被用在本地存储的目录，默认${hbase.tmp.dir}/local/；

hbase.master.port：hbase master绑定的端口，默认是60000；

hbase.master.info.port：hbase master web 界面的端口，默认是60010，设置为-1可以禁用ui；

hbase.master.info.bindAddress：master web界面的绑定地址，默认是0.0.0.0；

hbase.master.logcleaner.plugins：清理日志的插件列表，逗号分隔，被LogService调用的LogCleanerDelegate，可以自定义，顺序执行，清理WAL和HLog；默认org.apache.hadoop.hbase.master.cleaner.TimeToLiveLogCleaner

hbase.master.logcleaner.ttl：HLog在.oldlogdir目录中生存的最长时间，过期则被Master起线程回收，默认是600000；

hbase.master.hfilecleaner.plugins：HFile的清理插件列表，逗号分隔，被HFileService调用，可以自定义，默认org.apache.hadoop.hbase.master.cleaner.TimeToLiveHFileCleaner

hbase.master.catalog.timeout：Catalog Janitor从master到META的超时时间，我们知道这个Janitor是定时的去META扫描表目录，来决定回收无用的regions，默认是600000；

fail.fast.expired.active.master：如果master过期，那么不需要从zk恢复，直接终止，默认是false；

hbase.master.dns.interface：master的dns接口，向该接口提供ip，默认是default；

hbase.master.dns.nameserver：master使用的dns主机名或者ip，默认是default；

hbase.regionserver.port：regionserver绑定的端口，默认是60020；

hbase.regionserver.info.port：regionserver的web界面端口，-1取消界面，默认是60030；

hbase.regionserver.info.bindAddress：regionserver的web绑定，默认是0.0.0.0；

hbase.regionserver.info.port.auto：master或者regionserver是否自动搜索绑定的端口，默认是false；

hbase.regionserver.handler.count：regionserver上rpc listener的个数，http://kenwublog.com/hbase-performance-tuning把这个配置称为io线程数，其实雷同，就是说在regionserver上一个处理rpc的handler，默认是30；

hbase.regionserver.msginterval：regionserver向master发消息的间隔，默认3000毫秒；

hbase.regionserver.optionallogflushinterval：如果没有足够的entry触发同步，那么过了这个间隔后HLog将被同步到HDFS，默认是1000毫秒；

hbase.regionserver.regionSplitLimit：regionsplit的最大限额，默认是MAX_INT=2147483647，设置这个限制后，在到达限制时region split就不会再进行；

hbase.regionserver.logroll.period：不管有多少版本，直接roll掉commit log的周期，也就是说一个固定的时间周期，到期就roll，默认是3600000毫秒；

hbase.regionserver.logroll.errors.tolerated：可接受的WAL关闭错误个数，到达后将触发服务器终止；设置为0那么在WAL writer做log rolling失败时就停止region server，默认是2；

hbase.regionserver.hlog.reader.impl：HLog 文件reader的实现类，默认是org.apache.hadoop.hbase.regionserver.wal.ProtobufLogReader；

hbase.regionserver.hlog.writer.impl：HLog 文件writer的实现类，默认是org.apache.hadoop.hbase.regionserver.wal.ProtobufLogWriter；

hbase.regionserver.global.memstore.upperLimit：memstore在regionserver内存中的上限，届时新的update被阻塞并且flush被强制写，默认是0.4就是堆内存的40%；阻塞状态持续到regionserver的所有memstore的容量到达hbase.regionserver.global.memstore.lowerLimit；

hbase.regionserver.global.memstore.lowerLimit：memstore在regionserver内存中的最大上限，到达时flush就被强制写，默认是0.38等价于38%的内存容量；

hbase.regionserver.optionalcacheflushinterval：一个edit版本在内存中的cache时长，默认3600000毫秒，设置为0的话则禁止自动flush；

hbase.regionserver.catalog.timeout：regionserver的Catalog Janitor访问META的超时时间，默认是600000；

hbase.regionserver.dns.interface：同master类似~~不讲

hbase.regionserver.dns.nameserver：同master类似

zookeeper.session.timeout：这是个值得说道一下的配置，首先ZK客户端要用，Hbase使用zk的客户端联系总体，同时也被用来启动一个zk server，作为zk的maxSessionTimeout，总的来说就是regionserver与zk的关键参数，如果连接超时，master会重新的balance，regionserver也会被从集群名单中清除，默认是90000；一个问题是如果zk 由hbase自己维护，那么该参数作为regionserver连接是一个值，如果zk在另外的集群，那么zk自己的maxSessionTimeout参数将优先于Hbase的该参数，届时可能会发生超时时间不同的问题；

zookeeper.znode.parent：znode存放root region的地址，默认是root-region-server；

zookeeper.znode.acl.parent：root znode的acl，默认acl；

hbase.zookeeper.dns.interface：zk的dns接口，默认default；

hbase.zookeeper.dns.nameserver：zk的dns服务地址，默认default；

hbase.zookeeper.peerport：zk的peer之间的通讯端口，默认是2888；

hbase.zookeeper.leaderport：zk选leader的通讯端口，默认是3888；

hbase.zookeeper.useMulti：zk支持多重update，要求zk在3.4版本以上，默认是false；

hbase.config.read.zookeeper.config：让hbaseconfig去读zk的config，默认false，也不支持开启，这个功能很搞笑~~个人观点；

hbase.zookeeper.property.initLimit：zk的配置，同步的属性个数限制，默认10个~~没用；

hbase.zookeeper.property.syncLimit：zk的配置，同步时的每次请求的条数，默认5个；

hbase.zookeeper.property.dataDir：zk的配置，snapshot存放的目录，默认是${hbase.tmp.dir}/zookeeper；

hbase.zookeeper.property.clientPort：zk的配置，client连zk的端口，默认2181；

hbase.zookeeper.property.maxClientCnxns：zk的配置，允许接入zk的最大并发连接数的限制，按ip分配，默认300；

fs.har.impl：访问Hadoop Archives的实现类，低于hadoop 0.20版本的都不兼容，默认是org.apache.hadoop.hive.shims.HiveHarFileSystem；

hive.archive.enabled：是否允许归档操作，默认是false；

hive.archive.har.parentdir.settable：在创建HAR文件时必须要有父目录，需要手动设置，在新的hadoop版本会支持，默认是false；

hive.support.concurrency：hive是否支持并发，默认是false，支持读写锁的话，必须要起zookeeper；

hive.lock.mapred.only.operation：控制是否在查询时加锁，默认是false；

hive.lock.numretries：获取锁时尝试的重试次数，默认是100；

hive.lock.sleep.between.retries：在重试间隔的睡眠时间，默认60秒；

hive.zookeeper.quorum：zk地址列表，默认是空；

hive.zookeeper.client.port：zk服务器的连接端口，默认是2181；

hive.zookeeper.session.timeout：zk客户端的session超时时间，默认是600000；

hive.zookeeper.namespace：在所有zk节点创建后的父节点，默认是hive_zookeeper_namespace；

hive.zookeeper.clean.extra.nodes：在session结束时清除所有额外node；

hive.cluster.delegation.token.store.class：代理token的存储实现类，默认是org.apache.hadoop.hive.thrift.MemoryTokenStore，可以设置为org.apache.hadoop.hive.thrift.ZooKeeperTokenStore来做负载均衡集群；

hive.cluster.delegation.token.store.zookeeper.connectString：zk的token存储连接串，默认是localhost:2181；

hive.cluster.delegation.token.store.zookeeper.znode：token存储的节点跟路径，默认是/hive/cluster/delegation；

hive.cluster.delegation.token.store.zookeeper.acl：token存储的ACL，默认是sasl:hive/host1@example.com:cdrwa,sasl:hive/host2@example.com:cdrwa；

hive.use.input.primary.region：从一张input表创建表时，创建这个表到input表的主region，默认是true；

hive.default.region.name：默认region的名字，默认是default；

hive.region.properties：region的默认的文件系统和jobtracker，默认是空；

hive.cli.print.header：查询输出时是否打印名字和列，默认是false；

hive.cli.print.current.db：hive的提示里是否包含当前的db，默认是false；

hive.hbase.wal.enabled：写入hbase时是否强制写wal日志，默认是true；

hive.hwi.war.file：hive在web接口是的war文件的路径，默认是lib/hive-hwi-xxxx(version).war；

hive.hwi.listen.host：hwi监听的host地址，默认是0.0.0.0；

hive.hwi.listen.port：hwi监听的端口，默认是9999；

hive.test.mode：hive是否运行在测试模式，默认是false；

hive.test.mode.prefix：在测试模式运行时，表的前缀字符串，默认是test_；

hive.test.mode.samplefreq：如果hive在测试模式运行，并且表未分桶，抽样频率是多少，默认是32；

hive.test.mode.nosamplelist：在测试模式运行时不进行抽样的表列表，默认是空；

      基数估计的初衷就是为了解决在大数据的前提下，如何以低成本的空间复杂度去计算超大集合的势的问题，换句话说，通过基数估计，单机做到计算亿级别uv，误差在4%以内。解决思路主要是概率估计，具体原理和做法参看 blog和论文原文。

     出于实验的目的，我简单实现了暴力做法bruteforce-bf，布隆过滤器-bbf，loglog-llc和hyperloglog-hllc四个算法，比较一下基数估计这个计算去重指标的逻辑是否可行（llc非常离谱，可能是我分桶数没有调整好，就不贴出结果了）。

预处理方法：1-N生成随机uid，模拟N次（均匀分布），jvm启动-Xmx1024m。

实验结果：

附加说明一下，期望值如何计算：其实这个实验的数学原型就是一个长度为k的均匀分布的（1-N)的随机数列，求不重复的元素个数的期望。我实验里k=n，这是一种极端情况（实验设计纯为方便计算，如果k较大会导致计算超慢，uv5000w时根本无法计算出来，增大k理论上会提高精度，我实验过的一组数据是100w uv 500wpv时 hllc的值是991234，误差<1%），理论上k相当于pv，在递推公式中k趋于无穷时期望等于n。

这个递推的计算可以通过组合分析推导，推导方法不详说了（当然我有可能推导错了~~数学功底 实在 不行了），通项公式见matlab代码。

syms e n;
e = n-(1/n)*((1-2*n+n*n)*((n-1)/n)^(n-2)+(1-n)*n+n*(n-1));

vpa(subs(e,'n',1000000),10)

另外，我个人认为分布式布隆过滤器的方案是非常好的，因为空间和时间都比较均衡，且精确度高，基数估计的方法本质上空间复杂度O(1)，时间复杂度代码高效一点也可以非常快，但是缺点是精确度稍微欠缺，且不易分布式计算（因为它天生适合单进程，llc分桶均衡也是单进程做比较好，分布式完全是牛刀杀鸡）。

ref blog: http://blog.codinglabs.org/articles/cardinality-estimate-exper.html#ref4

算法实现的java代码可见github： https://github.com/changedi/card-estimate

hive.index.compact.file.ignore.hdfs：在索引文件中存储的hdfs地址将在运行时被忽略，如果开启的话；如果数据被迁移，那么索引文件依然可用，默认是false；

hive.optimize.index.filter.compact.minsize：压缩索引自动应用的最小输入大小，默认是5368709120；

hive.optimize.index.filter.compact.maxsize：同上，相反含义，如果是负值代表正无穷，默认是-1；

hive.index.compact.query.max.size：一个使用压缩索引做的查询能取到的最大数据量，默认是10737418240 个byte；负值代表无穷大；

hive.index.compact.query.max.entries：使用压缩索引查询时能读到的最大索引项数，默认是10000000；负值代表无穷大；

hive.index.compact.binary.search：在索引表中是否开启二分搜索进行索引项查询，默认是true；

hive.exec.concatenate.check.index：如果设置为true，那么在做ALTER TABLE tbl_name CONCATENATE on a table/partition（有索引） 操作时，抛出错误；可以帮助用户避免index的删除和重建；

hive.stats.dbclass：存储hive临时统计信息的数据库，默认是jdbc:derby；

hive.stats.autogather：在insert overwrite命令时自动收集统计信息，默认开启true；

hive.stats.jdbcdriver：数据库临时存储hive统计信息的jdbc驱动；

hive.stats.dbconnectionstring：临时统计信息数据库连接串，默认jdbc:derby:databaseName=TempStatsStore;create=true；

hive.stats.defaults.publisher：如果dbclass不是jdbc或者hbase，那么使用这个作为默认发布，必须实现StatsPublisher接口，默认是空；

hive.stats.defaults.aggregator：如果dbclass不是jdbc或者hbase，那么使用该类做聚集，要求实现StatsAggregator接口，默认是空；

hive.stats.jdbc.timeout：jdbc连接超时配置，默认30秒；

hive.stats.retries.max：当统计发布合聚集在更新数据库时出现异常时最大的重试次数，默认是0，不重试；

hive.stats.retries.wait：重试次数之间的等待窗口，默认是3000毫秒；

hive.client.stats.publishers：做count的job的统计发布类列表，由逗号隔开，默认是空；必须实现org.apache.hadoop.hive.ql.stats.ClientStatsPublisher接口；

hive.client.stats.counters：没什么用~~~

hive.security.authorization.enabled：hive客户端是否认证，默认是false；

hive.security.authorization.manager：hive客户端认证的管理类，默认是org.apache.hadoop.hive.ql.security.authorization.DefaultHiveAuthorizationProvider；用户定义的要实现org.apache.hadoop.hive.ql.security.authorization.HiveAuthorizationProvider；

hive.security.authenticator.manager：hive客户端授权的管理类，默认是org.apache.hadoop.hive.ql.security.HadoopDefaultAuthenticator；用户定义的需要实现org.apache.hadoop.hive.ql.security.HiveAuthenticatorProvider；

hive.security.authorization.createtable.user.grants：当表创建时自动授权给用户，默认是空；

hive.security.authorization.createtable.group.grants：同上，自动授权给组，默认是空；

hive.security.authorization.createtable.role.grants：同上，自动授权给角色，默认是空；

hive.security.authorization.createtable.owner.grants：同上，自动授权给owner，默认是空；

hive.security.metastore.authorization.manager：metastore的认证管理类，默认是org.apache.hadoop.hive.ql.security.authorization.DefaultHiveMetastoreAuthorizationProvider；用户定义的必须实现org.apache.hadoop.hive.ql.security.authorization.HiveMetastoreAuthorizationProvider接口；接口参数要包含org.apache.hadoop.hive.ql.security.authorization.StorageBasedAuthorizationProvider接口；使用HDFS的权限控制认证而不是hive的基于grant的方式；

hive.security.metastore.authenticator.manager：metastore端的授权管理类，默认是org.apache.hadoop.hive.ql.security.HadoopDefaultMetastoreAuthenticator，自定义的必须实现org.apache.hadoop.hive.ql.security.HiveAuthenticatorProvider接口；

hive.metastore.pre.event.listeners：在metastore做数据库任何操作前执行的事件监听类列表；

hive.metastore.local：控制hive是否连接一个远程metastore服务器还是开启一个本地客户端jvm，默认是true，Hive0.10已经取消了该配置项；

javax.jdo.option.ConnectionURL：JDBC连接字符串，默认jdbc:derby:;databaseName=metastore_db;create=true；

javax.jdo.option.ConnectionDriverName：JDBC的driver，默认org.apache.derby.jdbc.EmbeddedDriver；

javax.jdo.PersisteneManagerFactoryClass：实现JDO PersistenceManagerFactory的类名，默认org.datanucleus.jdo.JDOPersistenceManagerFactory；

javax.jdo.option.DetachAllOnCommit：事务提交后detach所有提交的对象，默认是true；

javax.jdo.option.NonTransactionalRead：是否允许非事务的读，默认是true；

javax.jdo.option.ConnectionUserName：username，默认APP；

javax.jdo.option.ConnectionPassword：password，默认mine；

javax.jdo.option.Multithreaded：是否支持并发访问metastore，默认是true；

datanucleus.connectionPoolingType：使用连接池来访问JDBC metastore，默认是DBCP；

datanucleus.validateTables：检查是否存在表的schema，默认是false；

datanucleus.validateColumns：检查是否存在列的schema，默认false；

datanucleus.validateConstraints：检查是否存在constraint的schema，默认false；

datanucleus.stroeManagerType：元数据存储类型，默认rdbms；

datanucleus.autoCreateSchema：在不存在时是否自动创建必要的schema，默认是true；

datanucleus.aotuStartMechanismMode：如果元数据表不正确，抛出异常，默认是checked；

datanucleus.transactionIsolation：默认的事务隔离级别，默认是read-committed；

datanucleus.cache.level2：使用二级缓存，默认是false；

datanucleus.cache.level2.type：二级缓存的类型，有两种，SOFT:软引用，WEAK:弱引用，默认是SOFT；

datanucleus.identifierFactory：id工厂生产表和列名的名字，默认是datanucleus；

datanucleus.plugin.pluginRegistryBundleCheck：当plugin被发现并且重复时的行为，默认是LOG；

hive.metastroe.warehouse.dir：数据仓库的位置，默认是/user/hive/warehouse；

hive.metastore.execute.setugi：非安全模式，设置为true会令metastore以客户端的用户和组权限执行DFS操作，默认是false，这个属性需要服务端和客户端同时设置；

hive.metastore.event.listeners：metastore的事件监听器列表，逗号隔开，默认是空；

hive.metastore.partition.inherit.table.properties：当新建分区时自动继承的key列表，默认是空；

hive.metastore.end.function.listeners：metastore函数执行结束时的监听器列表，默认是空；

hive.metastore.event.expiry.duration：事件表中事件的过期时间，默认是0；

hive.metastore.event.clean.freq：metastore中清理过期事件的定时器的运行周期，默认是0；

hive.metastore.connect.retries：创建metastore连接时的重试次数，默认是5；

hive.metastore.client.connect.retry.delay：客户端在连续的重试连接等待的时间，默认1；

hive.metastore.client.socket.timeout：客户端socket超时时间，默认20秒；

hive.metastore.rawstore.impl：原始metastore的存储实现类，默认是org.apache.hadoop.hive.metastore.ObjectStore；

hive.metastore.batch.retrieve.max：在一个batch获取中，能从metastore里取出的最大记录数，默认是300；

hive.metastore.ds.connection.url.hook：查找JDO连接url时hook的名字，默认是javax.jdo.option.ConnectionURL；

hive.metastore.ds.retry.attempts：当出现连接错误时重试连接的次数，默认是1次；

hive.metastore.ds.retry.interval：metastore重试连接的间隔时间，默认1000毫秒；

hive.metastore.server.min.threads：在thrift服务池中最小的工作线程数，默认是200；

hive.metastore.server.max.threads：最大线程数，默认是100000；

hive.metastore.server.tcp.keepalive：metastore的server是否开启长连接，长连可以预防半连接的积累，默认是true；

hive.metastore.sasl.enabled：metastore thrift接口的安全策略，开启则用SASL加密接口，客户端必须要用Kerberos机制鉴权，默认是不开启false；

hive.metastore.kerberos.keytab.file：在开启sasl后kerberos的keytab文件存放路径，默认是空；

hive.metastore.kerberos.principal：kerberos的principal，_HOST部分会动态替换，默认是hive-metastore/_HOST@EXAMPLE.COM；

hive.metastore.cache.pinobjtypes：在cache中支持的metastore的对象类型，由逗号分隔，默认是Table,StorageDescriptor,SerDeInfo,Partition,Database,Type,FieldSchema,Order；

hive.metastore.authorization.storage.checks：在做类似drop partition操作时，metastore是否要认证权限，默认是false；

hive.metastore.schema.verification：强制metastore的schema一致性，开启的话会校验在metastore中存储的信息的版本和hive的jar包中的版本一致性，并且关闭自动schema迁移，用户必须手动的升级hive并且迁移schema，关闭的话只会在版本不一致时给出警告，默认是false不开启；