BlogJava-Change Dir-随笔分类-数据

Leetcode-Database-181~183-3个easy题目连发

changedi — Fri, 06 Feb 2015 05:39:00 GMT

181题目地址：https://oj.leetcode.com/problems/employees-earning-more-than-their-managers/

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如下：

select
Name as Employee
from(
select
o1.Name
,o1.Salary as s
,o2.Salary as m
from(
select * from Employee
)o1
join(
select * from Employee
)o2
on(o1.ManagerId=o2.Id)
)t
where s>m

其中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如下：

select
    Email
from(
select
    Email
    ,count(Id) as cnt
from Person
group by Email
)t
where cnt>1

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

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

select
o1.Name as Customers
from(
select * from Customers
)o1
left outer join(
select * from Orders
)o2
on(o1.Id=o2.CustomerId )
where o2.CustomerId is null

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

changedi 2015-02-06 13:39 发表评论

Leetcode-Database-180-Consecutive Numbers-Medium

changedi — Thu, 29 Jan 2015 11:01:00 GMT

题目地址：https://oj.leetcode.com/problems/consecutive-numbers/

这个题目是要求写一个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，这样就可以把连续记录关联出来了

我的代码如下：

select
distinct o1.Num
from(
select * from Logs
)o1
join(
select * from Logs
)o2
on(o1.Num=o2.Num and o1.Id=o2.Id+1)
join(
select * from Logs
)o3
on(o2.Num=o3.Num and o2.Id=o3.Id+1)

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

代码如下：

select DISTINCT num
FROM (
  select
    num,
    case when @record = num then @count:=@count+1
         when @record <> @record:=num then @count:=1
    end as n
  from Logs ,(
    select
       @count:=0,
       @record:=(SELECT num from Logs limit 0,1)
  ) r
) a
where a.n>=3

简单分析一下，作者通过定义两个变量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字段~~非常棒

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

changedi 2015-01-29 19:01 发表评论

Leetcode-Database-178-Rank Scores-Medium

changedi — Wed, 28 Jan 2015 08:50:00 GMT

题目地址：https://oj.leetcode.com/problems/rank-scores/

这个问题很有趣，写一个类似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吧~~

实现代码如下：

select
o1.Score
,count(o2.Score) as Rank
from(
select * from Scores
)o1
left outer join(
select distinct Score from Scores
)o2
on(o1.Score<=o2.Score)
group by
o1.Id
order by o1.Score desc

changedi 2015-01-28 16:50 发表评论

Leetcode-Database-177-Nth Highest Salary-Medium

changedi — Tue, 27 Jan 2015 08:59:00 GMT

题目地址：https://oj.leetcode.com/problems/nth-highest-salary/

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

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

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

CREATE FUNCTION getNthHighestSalary(N INT) RETURNS INT
BEGIN
    declare n1 int;
    set n1 = N-1;
  RETURN (
      # Write your MySQL query statement below.
      select
        Salary
      from(
        select distinct Salary from Employee
      )t
      order by Salary desc
      limit n1,1

  );
END

大写的部分是题目已经给的框架，我们只需要在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~

changedi 2015-01-27 16:59 发表评论

Leetcode-Database-176-Second Highest Salary-Easy

changedi — Tue, 27 Jan 2015 08:38:00 GMT

leetcode地址：https://oj.leetcode.com/problems/second-highest-salary/

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

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

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

select Salary from Employee order by Salary desc limit 1,1

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

select
max(Salary) as SecondHighestSalary
from(
select
o1.*
,case when o2.s is null then 1 else 0 end as nt
from
(select * from Employee)o1
left outer join
(select max(Salary) as s from Employee)o2
on(o1.Salary=o2.s)
)t
where nt=1

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

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

changedi 2015-01-27 16:38 发表评论

Leetcode-Database-175-Combine Two Tables-Easy

changedi — Tue, 27 Jan 2015 08:23:00 GMT

大概上周看到leetcode开始做数据相关的挑战题目，目前是基于MySQL的Sql测试题目。作为一个现在hive sql占掉大部分工作时间的码农，还是可以选择来练练手，今天立帖把这些题目一一解决。

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

一张表叫做Person，主键是PersonId

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

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

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

1 select
2     o1.FirstName
3     ,o1.LastName
4     ,o2.City
5     ,o2.State
6 from(
7     select * from Person
8 )o1
9 left outer join(
10     select * from Address
11 )o2
12 on(o1.PersonId = o2.PersonId)

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

changedi 2015-01-27 16:23 发表评论

初探IMEI【译】

changedi — Thu, 27 Nov 2014 09:30:00 GMT

一直想清楚的理解IMEI是什么,但是怎么也找不到合适的下笔思路,最终还是把imei.org上的这篇介绍翻译过来，做个记录。

原文地址：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

从后向前，记录下每隔两位的数字，记为列表A
从后向前，记录下除A以外的数字，记为列表B
将A中的数字都乘以2，如果一个数字乘以2后大于10，那么把这个结果拆为两个数字（个位数一个，十位数一个），记为列表A'
把A'和B中的所有数字求和，记为S
计算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

changedi 2014-11-27 17:30 发表评论

Hbase配置项粗解（3）

changedi — Mon, 31 Mar 2014 09:18:00 GMT

HBase的配置完结篇：

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；

changedi 2014-03-31 17:18 发表评论

Hbase配置项粗解（2）

changedi — Fri, 03 Jan 2014 10:34:00 GMT

hbase的配置接上篇

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；

changedi 2014-01-03 18:34 发表评论

Hbase配置项粗解（1）

changedi — Mon, 09 Dec 2013 12:07:00 GMT

继之前写的设计和使用tip，这里补充一下hbase所有的配置项。之前涉及的一个项目在hbase设计上存在缺陷，当进入时已经存在着很多rowkey设计和读写问题，现在重读hbase文档，把所有的配置项整理一遍。

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；

changedi 2013-12-09 20:07 发表评论

Hive配置项的含义详解（7）

changedi — Wed, 13 Nov 2013 06:41:00 GMT

hive配置的最终章

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：在测试模式运行时不进行抽样的表列表，默认是空；

changedi 2013-11-13 14:41 发表评论

基数估计

changedi — Tue, 12 Nov 2013 02:10:00 GMT

问题的背景是在大数据冲击下，很多数据指标（尤其是涉及到去重的）的计算无法在合理的空间和时间内完成，比如uv的计算，数学原型问题等价于持续的向一个集合中写数，重复的不记，要求最终给出集合中不重复的元素的个数（集合的势）。而比较暴力的做法是随着数字增多不断的扩展集合的大小，让它放下所有的数，最终数出这个个数就OK。显然这样的空间复杂度在单机下是做不到的，所以多数做法是利用分布式原理将uv数据隔离到不同的计算节点，每个计算节点自行维护一个类似这样的集合（wdm实时里的布隆过滤器），然后分而治之，最后merge为一份结果数据。

基数估计的初衷就是为了解决在大数据的前提下，如何以低成本的空间复杂度去计算超大集合的势的问题，换句话说，通过基数估计，单机做到计算亿级别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

changedi 2013-11-12 10:10 发表评论

Hive配置项的含义详解（6）

changedi — Sat, 26 Oct 2013 11:35:00 GMT

hive的index索引相关、统计相关和认证授权相关的配置。

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做数据库任何操作前执行的事件监听类列表；

changedi 2013-10-26 19:35 发表评论

Hive配置项的含义详解（5）

changedi — Mon, 14 Oct 2013 09:39:00 GMT

关于MetaStore：metastore是个独立的关系数据库，用来持久化schema和系统元数据。

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不开启；

changedi 2013-10-14 17:39 发表评论

Hive配置项的含义详解（4）

changedi — Mon, 23 Sep 2013 10:12:00 GMT

hive.exec.drop.ignorenoneexistent：在drop表或者视图时如果发现表或视图不存在，是否报错，默认是true；

hive.exec.show.job.failure.debug.info：在作业失败时是否提供一个任务debug信息，默认true；

hive.auto.progress.timeout：运行自动progressor的时间间隔，默认是0等价于forever；

hive.table.parameters.default：新建表的属性字段默认值，默认是empty空；

hive.variable.substitute：是否支持变量替换，如果开启的话，支持语法如${var} ${system:var}和${env.var}，默认是true；

hive.error.on.empty.partition：在遇到结果为空的动态分区时是否报错，默认是false；

hive.exim.uri.scheme.whitelist：在导入导出数据时提供的一个白名单列表，列表项之间由逗号分隔，默认hdfs,pfile；

hive.limit.row.max.size：字面意思理解就是在使用limit做数据的子集查询时保证的最小行数据量，默认是100000；

hive.limit.optimize.limit.file：使用简单limit查询数据子集时，可抽样的最大文件数，默认是10；

hive.limit.optimize.enable：使用简单limit抽样数据时是否开启优化选项，默认是false，关于limit的优化问题，在hive programming书中解释的是这个feature有drawback，对于抽样的不确定性给出了风险提示；

hive.limit.optimize.fetch.max：使用简单limit抽样数据允许的最大行数，默认50000，查询query受限，insert不受影响；

hive.rework.mapredwork：是否重做mapreduce，默认是false；

hive.sample.seednumber：用来区分抽样的数字，默认是0；

hive.io.exception.handlers：io异常处理handler类列表，默认是空，当record reader发生io异常时，由这些handler来处理异常；

hive.autogen.columnalias.prefix.label：当在执行中自动产生列别名的前缀，当类似count这样的聚合函数起作用时，如果不明确指出count(a) as xxx的话，那么默认会从列的位置的数字开始算起添加，比如第一个count的结果会冠以列名_c0，接下来依次类推，默认值是_c，数据开发过程中应该很多人都看到过这个别名；

hive.autogen.columnalias.prefix.includefuncname：在自动生成列别名时是否带函数的名字，默认是false；

hive.exec.perf.logger：负责记录客户端性能指标的日志类名，必须是org.apache.hadoop.hive.ql.log.PerfLogger的子类，默认是org.apache.hadoop.hive.ql.log.PerfLogger；

hive.start.cleanup.scratchdir：当启动hive服务时是否清空hive的scratch目录，默认是false；

hive.output.file.extension：输出文件扩展名，默认是空；

hive.insert.into.multilevel.dirs：是否插入到多级目录，默认是false；

hive.files.umask.value：hive创建文件夹时的dfs.umask值，默认是0002；

changedi 2013-09-23 18:12 发表评论

Hive配置项的含义详解（3）

changedi — Tue, 10 Sep 2013 05:45:00 GMT

hive.exec.script.maxerrsize：一个map/reduce任务允许打印到标准错误里的最大字节数，为了防止脚本把分区日志填满，默认是100000；

hive.exec.script.allow.partial.consumption：hive是否允许脚本不从标准输入中读取任何内容就成功退出，默认关闭false；

hive.script.operator.id.env.var：在用户使用transform函数做自定义map/reduce时，存储唯一的脚本标识的环境变量的名字，默认HIVE_SCRIPT_OPERATOR_ID；

hive.exec.compress.output：控制hive的查询结果输出是否进行压缩，压缩方式在hadoop的mapred.output.compress中配置，默认不压缩false；

hive.exec.compress.intermediate：控制hive的查询中间结果是否进行压缩，同上条配置，默认不压缩false；

hive.exec.parallel：hive的执行job是否并行执行，默认不开启false，在很多操作如join时，子查询之间并无关联可独立运行，这种情况下开启并行运算可以大大加速；

hvie.exec.parallel.thread.number：并行运算开启时，允许多少作业同时计算，默认是8；

hive.exec.rowoffset：是否提供行偏移量的虚拟列，默认是false不提供，Hive有两个虚拟列:一个是INPUT__FILE__NAME,表示输入文件的路径，另外一个是BLOCK__OFFSET__INSIDE__FILE，表示记录在文件中的块偏移量，这对排查出现不符合预期或者null结果的查询是很有帮助的（来自这篇文章）；

hive.task.progress：控制hive是否在执行过程中周期性的更新任务进度计数器，开启这个配置可以帮助job tracker更好的监控任务的执行情况，但是会带来一定的性能损耗，当动态分区标志hive.exec.dynamic.partition开启时，本配置自动开启；

hive.exec.pre.hooks：执行前置条件，一个用逗号分隔开的实现了org.apache.hadoop.hive.ql.hooks.ExecuteWithHookContext接口的java class列表，配置了该配置后，每个hive任务执行前都要执行这个执行前钩子，默认是空；

hive.exec.post.hooks：同上，执行后钩子，默认是空；

hive.exec.failure.hooks：同上，异常时钩子，在程序发生异常时执行，默认是空；

hive.mergejob.maponly：试图生成一个只有map的任务去做merge，前提是支持CombineHiveInputFormat，默认开启true；

hive.mapjoin.smalltable.filesize：输入表文件的mapjoin阈值，如果输入文件的大小小于该值，则试图将普通join转化为mapjoin，默认25MB；

hive.mapjoin.localtask.max.memory.usage：mapjoin本地任务执行时hash表容纳key/value的最大量，超过这个值的话本地任务会自动退出，默认是0.9；

hive.mapjoin.followby.gby.localtask.max.memory.usage：类似上面，只不过是如果mapjoin后有一个group by的话，该配置控制类似这样的query的本地内存容量上限，默认是0.55；

hive.mapjoin.check.memory.rows：在运算了多少行后执行内存使用量检查，默认100000；

hive.heartbeat.interval：发送心跳的时间间隔，在mapjoin和filter操作中使用，默认1000；

hive.auto.convert.join：根据输入文件的大小决定是否将普通join转换为mapjoin的一种优化，默认不开启false；

hive.script.auto.progress：hive的transform/map/reduce脚本执行时是否自动的将进度信息发送给TaskTracker来避免任务没有响应被误杀，本来是当脚本输出到标准错误时，发送进度信息，但是开启该项后，输出到标准错误也不会导致信息发送，因此有可能会造成脚本有死循环产生，但是TaskTracker却没有检查到从而一直循环下去；

hive.script.serde：用户脚本转换输入到输出时的SerDe约束，默认是org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe；

hive.script.recordreader：从脚本读数据的时候的默认reader，默认是org.apache.hadoop.hive.ql.exec.TextRecordReader；

hive.script.recordwriter：写数据到脚本时的默认writer，默认org.apache.hadoop.hive.ql.exec.TextRecordWriter；

hive.input.format：输入格式，默认是org.apache.hadoop.hive.ql.io.CombineHiveInputFormat，如果出现问题，可以改用org.apache.hadoop.hive.ql.io.HiveInputFormat；

hive.udtf.auto.progress：UDTF执行时hive是否发送进度信息到TaskTracker，默认是false；

hive.mapred.reduce.tasks.speculative.execution：reduce任务推测执行是否开启，默认是true；

hive.exec.counters.pull.interval：运行中job轮询JobTracker的时间间隔，设置小会影响JobTracker的load，设置大可能看不出运行任务的信息，要去平衡，默认是1000；

hive.enforce.bucketing：数据分桶是否被强制执行，默认false，如果开启，则写入table数据时会启动分桶，个人对分桶的理解可以参考这篇文章，写的较清楚，有示例，分桶在做全表查询和带有分区字段查询时感觉影响不大，主要作用在sampling；

hive.enforce.sorting：开启强制排序时，插数据到表中会进行强制排序，默认false；

hive.optimize.reducededuplication：如果数据已经根据相同的key做好聚合，那么去除掉多余的map/reduce作业，此配置是文档的推荐配置，建议打开，默认是true；

hive.exec.dynamic.partition：在DML/DDL中是否支持动态分区，默认false；

hive.exec.dynamic.partition.mode：默认strict，在strict模式下，动态分区的使用必须在一个静态分区确认的情况下，其他分区可以是动态；

hive.exec.max.dynamic.partitions：动态分区的上限，默认1000；

hive.exec.max.dynamic.partitions.pernode：每个mapper/reducer节点可以创建的最大动态分区数，默认100；

hive.exec.max.created.files：一个mapreduce作业能创建的HDFS文件最大数，默认是100000；

hive.exec.default.partition.name：当动态分区启用时，如果数据列里包含null或者空字符串的话，数据会被插入到这个分区，默认名字是__HIVE_DEFAULT_PARTITION__；

hive.fetch.output.serde：FetchTask序列化fetch输出时需要的SerDe，默认是org.apache.hadoop.hive.serde2.DelimitedJSONSerDe;

hive.exec.mode.local.auto：是否由hive决定自动在local模式下运行，默认是false，关于满足什么条件开启localmode，可以参考这篇文章；

changedi 2013-09-10 13:45 发表评论

Hive配置项的含义详解（2）

changedi — Thu, 15 Aug 2013 06:47:00 GMT

标记粗体的我个人认为在运行hive sql时可以根据数据情况进行设置，当然还有一些join的优化的配置需要单独研究。

mapred.reduce.tasks：每个作业的reduce任务数，默认是hadoop client的配置1个；

hive.exec.reducers.bytes.per.reducer：每个reducer的大小，默认是1G，输入文件如果是10G，那么就会起10个reducer；

hive.exec.reducers.max：reducer的最大个数，如果在mapred.reduce.tasks设置为负值，那么hive将取该值作为reducers的最大可能值。当然还要依赖（输入文件大小/hive.exec.reducers.bytes.per.reducer）所得出的大小，取其小值作为reducer的个数，hive默认是999；

hive.fileformat.check：加载数据文件时是否校验文件格式，默认是true；

hive.groupby.skewindata：group by操作是否允许数据倾斜，默认是false，当设置为true时，执行计划会生成两个map/reduce作业，第一个MR中会将map的结果随机分布到reduce中，达到负载均衡的目的来解决数据倾斜，可以参看阿里巴巴数据平台的这篇文章了解hive对于数据倾斜时group by的处理；

hive.groupby.mapaggr.checkinterval：map端做聚合时，group by 的key所允许的数据行数，超过该值则进行分拆，默认是100000；

hive.mapred.local.mem：本地模式时，map/reduce的内存使用量，默认是0，就是无限制；

hive.mapjoin.followby.map.aggr.hash.percentmemory：map端聚合时hash表的内存占比，该设置约束group by在map join后进行，否则使用hive.map.aggr.hash.percentmemory来确认内存占比，默认值0.3；

hive.map.aggr.hash.force.flush.memeory.threshold：map端聚合时hash表的最大可用内存，如果超过该值则进行flush数据，默认是0.9；

hive.map.aggr.hash.min.reduction：如果hash表的容量与输入行数之比超过这个数，那么map端的hash聚合将被关闭，默认是0.5，设置为1可以保证hash聚合永不被关闭；

hive.optimize.groupby：在做分区和表查询时是否做分桶group by，默认开启true；

hive.multigroupby.singlemr：将多个group by产出为一个单一map/reduce任务计划，当然约束前提是group by有相同的key，默认是false；

hive.optimize.cp：列裁剪，默认开启true，在做查询时只读取用到的列，这个是个有用的优化；

hive.optimize.index.filter：自动使用索引，默认不开启false；

hive.optimize.index.groupby：是否使用聚集索引优化group-by查询，默认关闭false；

hive.optimize.ppd：是否支持谓词下推，默认开启；所谓谓词下推，将外层查询块的 WHERE 子句中的谓词移入所包含的较低层查询块（例如视图），从而能够提早进行数据过滤以及有可能更好地利用索引。这篇中文文章简单的说明了在关系数据库里的应用；

hive.optimize.ppd.storage：谓词下推开启时，谓词是否下推到存储handler，默认开启，在谓词下推关闭时不起作用；

hive.ppd.recognizetransivity：在等值join条件下是否产地重复的谓词过滤器，默认开启；

hive.join.cache.size：在做表join时缓存在内存中的行数，默认25000；

hive.mapjoin.bucket.cache.size：mapjoin时内存cache的每个key要存储多少个value，默认100；

hive.optimize.skewjoin：是否开启数据倾斜的join优化，默认不开启false；

hive.skewjoin.key：判断数据倾斜的阈值，如果在join中发现同样的key超过该值则认为是该key是倾斜的join key，默认是100000；

hive.skewjoin.mapjoin.map.tasks：在数据倾斜join时map join的map数控制，默认是10000；

hive.skewjoin.mapjoin.min.split：数据倾斜join时map join的map任务的最小split大小，默认是33554432，该参数要结合上面的参数共同使用来进行细粒度的控制；

hive.mapred.mode：hive操作执行时的模式，默认是nonstrict非严格模式，如果是strict模式，很多有风险的查询会被禁止运行，比如笛卡尔积的join和动态分区；

changedi 2013-08-15 14:47 发表评论

Hive配置项的含义详解（1）

changedi — Tue, 13 Aug 2013 07:24:00 GMT

一个hive任务，如何才算是优化的任务，hadoop job config里哪些配置能影响hive的效率。看看hive的详细配置我们可以略知一二。

hive的配置：

hive.ddl.output.format：hive的ddl语句的输出格式，默认是text，纯文本，还有json格式，这个是0.90以后才出的新配置；

hive.exec.script.wrapper：hive调用脚本时的包装器，默认是null，如果设置为python的话，那么在做脚本调用操作时语句会变为python