分类 工具 下的文章

mapreduce程序shell脚本运行跑多天数据

vprun.sh

sh vprun.sh 20130101 20130102

说明:参数为开始日期和结束日期,如果开始日期和结束日期是一样的话,那就是跑一天的数据

#!/bin/bash
#Filename: vprun.sh
ct=0
date=`date -d "${1} ${ct} days" +%Y%m%d`
while [[ ${2} > ${date} ]] || [[ ${2} == ${date} ]]
	do
		hadoop jar /home/yda/tianhailong/vp-0.0.1-SNAPSHOT.jar com.youku.vp.userindex.day.calculators.TDVUserVideoJoin -libjars /home/yda/tianhailong/json-lib-2.3-jdk15.jar,/home/yda/tianhailong/ezmorph-1.0.6.jar,/home/yda/tianhailong/kfs-0.3.jar,/home/yda/tianhailong/redis-0.0.1.jar,/home/yda/tianhailong/jedis-2.0.0.jar,/work/yda/video_profile/dataUtil.jar /commons/common_data/user/hive/tudou:/commons/common_data/t_dlord_info/hive:/commons/common_data/t_vuser/hive:/commons/common_data/video/hive/tudou /commons/web/vuser-video/$date/tudou $date
	let "ct += 1"
	date=`date -d "${1} ${ct} days" +%Y%m%d`
	done

Flume日志系统

           Flume是Cloudera提供的一个高可用的,高可靠的,分布式的海量日志采集、聚合和传输的系统,Flume支持在日志系统中定制各类数据发送方,用于收集数据;同时,Flume提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力。
          Flume最早是Cloudera提供的日志收集系统,目前是Apache下的一个孵化项目,Flume支持在日志系统中定制各类数据发送方,用于收集数据;同时,Flume提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力 Flume提供了从console(控制台)、RPC(Thrift-RPC)、text(文件)、tail(UNIX tail)、syslog(syslog日志系统,支持TCP和UDP等2种模式),exec(命令执行)等数据源上收集数据的能力。
Flume采用了多Master的方式。为了保证配置数据的一致性,Flume[1]引入了ZooKeeper,用于保存配置数据,ZooKeeper本身可保证配置数据的一致性和高可用,另外,在配置数据发生变化时,ZooKeeper可以通知Flume Master节点。Flume Master间使用gossip协议同步数据。
这个和hadoop配合起来应该不错,后续研究下……

hadoop Task process exit with nonzero status of 126

通过分析hadoop 1.0.1代码,发现map/reduce task在执行的时候,hadoop系统会先把要执行的java 命令已经一些环境变量写到一个本地的sh文件taskjvm.sh中,然后使用bash -c file的方式执行这个sh脚本,如果出错当然后抛出异常,进而导致看到
Caused by: java.io.IOException: Task process exit with nonzero status of 126.
at org.apache.hadoop.mapred.TaskRunner.run(TaskRunner.java:258)
这样的错误
所以,这个exitcode实际就是bash执行时的推出代码,bash的exitcode是有特殊含义的,通过google可以知道126表明是permission的问题,具体为啥是这样的,不是很清楚了~~
上面的那个文件在创建的是权限是700(rwx——), 而这个文件在执行的过程中又被以setsid的方式exec,会不会这中间有些permission上的问题那~~~ 源码里说了,这样做是为了防止special character attacks
好吧水平有限,看不出来这里有什么竞争条件导致出现那样的错误
bash的退出码含义可以在下面的地方查到 http://tldp.org/LDP/abs/html/exitcodes.html
这个问题可以修改hadoop源码DefaultTaskControl加入重试机制,或者对task启用reuse=-1得到缓解(reuse和非reuse执行逻辑不一样),因为涉及到文件系统,不太容易根治。

hive日常积累优化技巧

一、join优化
Join查找操作的基本原则:应该将条目少的表/子查询放在 Join 操作符的左边。原因是在 Join 操作的 Reduce 阶段,位于 Join 操作符左边的表的内容会被加载进内存,将条目少的表放在左边,可以有效减少发生内存溢出错误的几率。
Join查找操作中如果存在多个join,且所有参与join的表中其参与join的key都相同,则会将所有的join合并到一个mapred程序中。
案例:
SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1) 在一个mapre程序中执行join
SELECT a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key2) 在两个mapred程序中执行join
Map join的关键在于join操作中的某个表的数据量很小,案例:
SELECT /*+ MAPJOIN(b) */ a.key, a.value
FROM a join b on a.key = b.key
Mapjoin 的限制是无法执行a FULL/RIGHT OUTER JOIN b,和map join相关的hive参数:hive.join.emit.interval hive.mapjoin.size.key hive.mapjoin.cache.numrows
由于join操作是在where操作之前执行,所以当你在执行join时,where条件并不能起到减少join数据的作用;案例:
SELECT a.val, b.val FROM a LEFT OUTER JOIN b ON (a.key=b.key)
WHERE a.ds=’2009-07-07′ AND b.ds=’2009-07-07′
最好修改为:
SELECT a.val, b.val FROM a LEFT OUTER JOIN b
ON (a.key=b.key AND b.ds=’2009-07-07′ AND a.ds=’2009-07-07′)
在join操作的每一个mapred程序中,hive都会把出现在join语句中相对靠后的表的数据stream化,相对靠前的变的数据缓存在内存中。当然,也可以手动指定stream化的表:SELECT /*+ STREAMTABLE(a) */ a.val, b.val, c.val FROM a JOIN b ON (a.key = b.key1) JOIN c ON (c.key = b.key1)
二、group by 优化
Map端聚合,首先在map端进行初步聚合,最后在reduce端得出最终结果,相关参数:
· hive.map.aggr = true是否在 Map 端进行聚合,默认为 True
· hive.groupby.mapaggr.checkinterval = 100000在 Map 端进行聚合操作的条目数目
数据倾斜聚合优化,设置参数hive.groupby.skewindata = true,当选项设定为 true,生成的查询计划会有两个 MR Job。第一个 MR Job 中,Map 的输出结果集合会随机分布到 Reduce 中,每个 Reduce 做部分聚合操作,并输出结果,这样处理的结果是相同的 Group By Key 有可能被分发到不同的 Reduce 中,从而达到负载均衡的目的;第二个 MR Job 再根据预处理的数据结果按照 Group By Key 分布到 Reduce 中(这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce 中),最后完成最终的聚合操作。
三、合并小文件
文件数目过多,会给 HDFS 带来压力,并且会影响处理效率,可以通过合并 Map 和 Reduce 的结果文件来消除这样的影响:
· hive.merge.mapfiles = true是否和并 Map 输出文件,默认为 True
· hive.merge.mapredfiles = false是否合并 Reduce 输出文件,默认为 False
· hive.merge.size.per.task = 256*1000*1000合并文件的大小
四、Hive实现(not) in
通过left outer join进行查询,(假设B表中包含另外的一个字段 key1
select a.key from a left outer join b on a.key=b.key where b.key1 is null
通过left semi join 实现 in
SELECT a.key, a.val FROM a LEFT SEMI JOIN b on (a.key = b.key)
Left semi join 的限制:join条件中右边的表只能出现在join条件中。
五、排序优化
Order by 实现全局排序,一个reduce实现,效率低
Sort by 实现部分有序,单个reduce输出的结果是有序的,效率高,通常和DISTRIBUTE BY关键字一起使用(DISTRIBUTE BY关键字 可以指定map 到 reduce端的分发key)
CLUSTER BY col1 等价于DISTRIBUTE BY col1 SORT BY col1
六、使用分区
Hive中的每个分区都对应hdfs上的一个目录,分区列也不是表中的一个实际的字段,而是一个或者多个伪列,在表的数据文件中实际上并不保存分区列的信息与数据。Partition关键字中排在前面的为主分区(只有一个),后面的为副分区
静态分区:静态分区在加载数据和使用时都需要在sql语句中指定
案例:(stat_date=’20120625′,province=’hunan’)
动态分区:使用动态分区需要设置hive.exec.dynamic.partition参数值为true,默认值为false,在默认情况下,hive会假设主分区时静态分区,副分区使用动态分区;如果想都使用动态分区,需要设置set hive.exec.dynamic.partition.mode=nostrick,默认为strick
案例:(stat_date=’20120625′,province)
七、Distinct 使用
Hive支持在group by时对同一列进行多次distinct操作,却不支持在同一个语句中对多个列进行distinct操作。
八、Hql使用自定义的mapred脚本
注意事项:在使用自定义的mapred脚本时,关键字MAP REDUCE 是语句SELECT TRANSFORM ( … )的语法转换,并不意味着使用MAP关键字时会强制产生一个新的map过程,使用REDUCE关键字时会产生一个red过程。
自定义的mapred脚本可以是hql语句完成更为复杂的功能,但是性能比hql语句差了一些,应该尽量避免使用,如有可能,使用UDTF函数来替换自定义的mapred脚本
九、UDTF
UDTF将单一输入行转化为多个输出行,并且在使用UDTF时,select语句中不能包含其他的列,UDTF不支持嵌套,也不支持group by 、sort by等语句。如果想避免上述限制,需要使用lateral view语法,案例:
select a.timestamp, get_json_object(a.appevents, ‘$.eventid’), get_json_object(a.appenvets, ‘$.eventname’) from log a;
select a.timestamp, b.*
from log a lateral view json_tuple(a.appevent, ‘eventid’, ‘eventname’) b as f1, f2;
其中,get_json_object为UDF函数,json_tuple为UDTF函数。
UDTF函数在某些应用场景下可以大大提高hql语句的性能,如需要多次解析json或者xml数据的应用场景。
十、聚合函数count和sum
Count和sum函数可能是在hql语句中使用的最为频繁的两个聚合函数了,但是在hive中count函数在计算distinct value时支持加入条件过滤。
转自:http://in.sdo.com/?p=809

数据库索引

索引是对数据库表中一列或多列的值进行排序的一种结构,使用索引可快速访问数据库表中的特定信息。
数据库索引好比是一本书前面的目录,能加快数据库的查询速度。
索引是对数据库表中一个或多个列(例如,employee 表的姓氏 (lname) 列)的值进行排序的结构。如果想按特定职员的姓来查找他或她,则与在表中搜索所有的行相比,索引有助于更快地获取信息。
例如这样一个查询:select * from table1 where id=10000。如果没有索引,必须遍历整个表,直到ID等于10000的这一行被找到为止;有了索引之后(必须是在ID这一列上建立的索引),在索引中查找,但索引是经过某种算法优化过的,查找次数要少的多的多。可见,索引是用来定位的。
索引分为聚簇索引和非聚簇索引两种,聚簇索引 是按照数据存放的物理位置为顺序的,而非聚簇索引就不一样了;聚簇索引能提高多行检索的速度,而非聚簇索引对于单行的检索很快。
建立索引的目的是加快对表中记录的查找或排序。
为表设置索引要付出代价的:一是增加了数据库的存储空间,二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。
创建索引可以大大提高系统的性能。第一,通过创建唯一性索引,可以保证数据库表中每一行数据的唯一性。第二,可以大大加快数据的检索速度,这也是创建索引的最主要的原因。第三,可以加速表和表之间的连接,特别是在实现数据的参考完整性方面特别有意义。第四,在使用分组和排序子句进行数据检索时,同样可以显著减少查询中分组和排序的时间。第五,通过使用索引,可以在查询的过程中,使用优化隐藏器,提高系统的性能。
也许会有人要问:增加索引有如此多的优点,为什么不对表中的每一个列创建一个索引呢?因为,增加索引也有许多不利的方面。第一,创建索引和维护索引要耗费时间,这种时间随着数据量的增加而增加。第二,索引需要占物理空间,除了数据表占数据空间之外,每一个索引还要占一定的物理空间,如果要建立聚簇索引,那么需要的空间就会更大。第三,当对表中的数据进行增加、删除和修改的时候,索引也要动态的维护,这样就降低了数据的维护速度。
索引是建立在数据库表中的某些列的上面。在创建索引的时候,应该考虑在哪些列上可以创建索引,在哪些列上不能创建索引。一般来说,应该在这些列上创建索引:
在经常需要搜索的列上,可以加快搜索的速度;
在作为主键的列上,强制该列的唯一性和组织表中数据的排列结构;
在经常用在连接的列上,这些列主要是一些外键,可以加快连接的速度;在经常需要根据范围进行搜索的列上创建索引,因为索引已经排序,其指定的范围是连续的;
在经常需要排序的列上创建索引,因为索引已经排序,这样查询可以利用索引的排序,加快排序查询时间;
在经常使用在WHERE子句中的列上面创建索引,加快条件的判断速度。
同样,对于有些列不应该创建索引。一般来说,不应该创建索引的的这些列具有下列特点:
第一,对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为,既然这些列很少使用到,因此有索引或者无索引,并不能提高查询速度。相反,由于增加了索引,反而降低了系统的维护速度和增大了空间需求。
第二,对于那些只有很少数据值的列也不应该增加索引。这是因为,由于这些列的取值很少,例如人事表的性别列,在查询的结果中,结果集的数据行占了表中数据行的很大比例,即需要在表中搜索的数据行的比例很大。增加索引,并不能明显加快检索速度。
第三,对于那些定义为text, image和bit数据类型的列不应该增加索引。这是因为,这些列的数据量要么相当大,要么取值很少,不利于使用索引。
第四,当修改性能远远大于检索性能时,不应该创建索引。这是因为,修改性能和检索性能是互相矛盾的。当增加索引时,会提高检索性能,但是会降低修改性能。当减少索引时,会提高修改性能,降低检索性能。因此,当修改操作远远多于检索操作时,不应该创建索引。

谷歌票房预测模型 准确度高达94%

谷歌公布了一项重要研究成果–电影票房预测模型。该模型能够提前一个月预测电影上映首周的票房收入,准确度高达94%。这在业内引起了强烈讨论,不少内人士认为该模型非常适合好莱坞电影公司通过预测票房来及时调整电影营销战略,但同时也有吐槽者暗示谷歌的票房预测模型别有用心,旨在鼓动电影公司购买其搜索引擎广告。那么,孰是孰非,谷歌票房预测模型以及大数据在电影行业的应用是嘘头,还是大有来头,让我们来一探究竟。
谷歌票房预测模型的基础:电影相关的搜索量与票房收入的关联
谷歌的票房预测模型是大数据分析技术在电影行业的一个重要应用。随着互联网的发展,人们越来越习惯于在网上搜索电影信息。据谷歌统计,从2011到2012年,电影相关的搜索量增长了56%。谷歌发现,电影相关的搜索量与票房收入之间存在很强的关联。
图1显示了2012年电影票房收入(红色)和电影的搜索量(灰色)的曲线(注:本文的所有图片均引用自谷歌的白皮书:QuantifyingMovieMagicwithGoogleSearch)。可以看到,两条曲线的起伏变化有着很强的相似性。

p1

p1


 

图1.2012年票房收入与搜索量的曲线
(红色是票房收入,灰色是搜索量,横轴是月份,纵轴是数量)

更进一步地,谷歌把电影的搜索分成了两类:
  I.涉及电影名的搜索(MovieTitleSearch);
  II.不涉及电影名的搜索(Non-TitleFilm-RelatedSearch)。这类搜索不包含具体的名字,而是一些更宽泛的关键词搜索,如“热门电影”、“爱情片”、“好莱坞电影”等。
  图2显示了票房收入与这两类搜索量之间的关系。从图上可以看到,大部分情况下,第I类搜索量超过第II类搜索量。但在电影淡季的时候(图中灰色椭圆区域,这时候票房收入较低),第I类搜索量会低于第II类搜索量。这符合常理,因为在淡季的时候知名度高的电影很少,人们往往用更宽泛的搜索来寻找想看的电影。

p2
p2

图2.2012年票房收入和两类搜索量的曲线

  (红色代表票房收入,蓝色代表第I搜索,灰色代表第II类搜索,横轴是月份,纵轴是数量)

  这一发现对电影的网络营销来说有一定的指导意义:在淡季的时候,电影公司可多购买相对宽泛的关键词的广告,而在旺季的时候,多购买涉及电影名的、更具体的关键词的广告。
  提前一周预测票房,可达到92%的准确度
  上面的讨论表明用电影的搜索量来预测票房是有可能的。那么,如果单纯使用搜索量来预测首周票房收入,效果怎么样?通过对2012年上映的99部电影的研究,谷歌发现仅依靠搜索量来预测是不够的。谷歌尝试构建了一个线性的模型,但只达到了70%的准确度(如图3)。

p3
p3

图3.搜索量与首周票房收入之间的关系

  (横轴是搜索量,纵轴是首周票房收入,灰色点对应某部电影的搜索量与首周票房收入)

  为了构建更加精确的预测模型,谷歌最终采用了四类指标:
  (1)(电影放映前一周的)电影的搜索量
  (2)(电影放映前一周的)电影广告的点击量
  (3)上映影院数量
  (4)同系列电影前几部的票房表现
  其中每类指标又包含了多项类内指标。
  在获取到每部电影的这些指标后,谷歌构建了一个线性回归模型(linearregressionmodel)模型,来建立这些指标和票房收入的关系。线性回归模型,在大数据分析领域里算是最基本的模型之一,它认为票房收入与这些指标之间是简单的线性关系。
  图4展示了模型的效果,其中灰色点代表了实际的票房收入,红色点代表了预测的票房收入。可以看到,预测的结果与实际的结果差异很小。

p4
p4

图4.提前一周预测票房的效果

  (横轴是搜索量,纵轴是首周票房收入,灰色点对应某部电影的首周票房收入,红色点对应预测的首周票房收入)

   提前一个月预测票房,可达到94%的准确度
   尽管提前一周预测可以达到92%的准确度,对于电影的营销来说,价值并不大,因为一周的时间往往很难调整营销策略,改善营销效果。因此,谷歌又进一步研究,使得模型可以提前一个月预测首周票房。
  实现提前一个月预测的关键在于:谷歌采用了一项新的指标–电影预告片的搜索量。谷歌发现,预告片的搜索量比起电影的直接搜索量而言,可以更好的预测首周票房表现。这一点不难理解,因为在电影放映前一个月的时候,人们往往更多地搜索预告片。
  仅使用预告片的搜索量仍然不够,因此谷歌的模型最终采用了三类指标:
  (1)电影预告片的搜索量
  (2)同系列电影前几部的票房表现
  (3)档期的季节性特征
  其中每类指标又包含了多项类内指标。
  在获取到每部电影的这些指标后,谷歌再次构建了一个线性回归模型(linearregressionmodel)模型,来建立这些指标和票房收入的关系。
  图5展示了模型的效果,其中灰色点代表了实际的票房收入,红色点代表了预测的票房收入。可以看到,预测结果与实际结果非常接近。

p5
p5

图5提前一个月预测票房的效果

  (横轴是预告片搜索量,纵轴是首周票房收入,灰色点对应实际某部电影的首周票房收入,红色点对应预测的首周票房收入)

   为什么谷歌采用了这么简单的模型
  前面的分析中已经提到,谷歌采用的是数据分析中最简单的模型之一-线性回归模型。这对很多读者来说多少有点意外。为什么谷歌用的模型如此简单?
  首先,线性模型虽然简单,但已经达到了很高的准确度(94%)。简单且效果好,是我们在实际应用中一直追求的。
  其次,简单的模型易于被人们理解和分析。大数据分析技术的优势正是能够从大量数据中挖掘出人们可以理解的规律,从而加深对行业的理解。正是因为谷歌使用了线性预测模型,所以它很容易对各项指标的影响做出分析。例如谷歌的报告中给出了这样的分析结论:“距离电影上映一周的时候,如果一部影片比同类影片多获得25万搜索量,那么该片的首周票房就很可能比同类影片高出430万美元。若一部电影有搜索引擎广告,我们也可以通过其广告的点击量来推测票房表现——如果点击量超出同类电影2万,那该片首周票房将领先750万美元”。
  对于电影的营销来说,掌握各项指标对票房收入的影响,可以优化营销策略,降低营销成本。谷歌的报告中指出,用户一般会通过多达13个渠道来了解电影的信息。票房预测模型的出现无疑使得营销策略的制定更加有效。
   大数据分析在电影行业的应用前景:把模糊的行业经验变得更科学,更精准
  票房预测模型的公布,让业内人士再次见证了大数据的成功应用。近年来,大数据在电影行业的应用越来越引起关注,比如此前谷歌利用搜索数据预测了奥斯卡获奖者,Neflix通过大数据分析深度挖掘了用户的喜好,捧红了《纸牌屋》等。但大数据对电影行业的价值到底如何,仍然众说纷纭。梦工厂CEO卡森伯格最近接受腾讯财经专访时发表了一个似乎悲观的态度:电影创作靠创造力,不靠数据分析。
  要理解大数据对电影行业的影响,首先需要对大数据分析有正确的认识。大数据分析的本质,在于通过数据,更精准地挖掘用户的需求。而谁能掌握用户的需求,谁就可以引领行业的发展。谷歌的票房预测模型,本质上也是通过搜索量,挖掘出用户对电影的需求有多大,进而预测出票房收入。值得注意的是,谷歌的模型基于的只是宏观的搜索量的统计,对用户需求的挖掘相对表面。如何从搜索数据中更深地挖掘用户的需求将是未来的趋势之一。
  既然大数据分析的核心是挖掘用户需求,所以一大核心问题是:哪些用户的需求是可以从数据中挖掘到的?要知道,并不是任何需求都可以被挖掘到,或者说可以被精准地挖掘到。能够通过大数据分析挖掘到的需求,一般是符合行业经验的,应当是业内人士觉得可以被挖掘的(有时候,挖掘出的需求可能会超出行业经验,甚至产生颠覆性的影响)。谷歌的预测模型的基本假设,是符合行业直觉的,即电影的搜索量越大,往往票房收入越大。模型能够提前一个月预测票房,也符合行业经验,正如谷歌的一项行业调研揭示的:大多数观众会在电影首映4周前去了解电影。数据分析技术,是把这种模糊的行业经验,变得更科学,变得更精准。而这一过程,很可能会深层次地改变电影行业。
  要将大数据分析更广泛地应用于电影行业,可以从以下几个方面去探索:
   一.我们可以获得哪些数据。大数据时代的特点是数据来源广泛,可以是业内发布的数据,也可以是来自搜索引擎、社交媒体等的数据。有些数据看似关联不强(比如社交媒体数据),但往往能从中挖掘到用户的潜在需求。
   二.从数据中,我们想挖掘什么信息。谷歌的模型,挖掘了搜索量等数据与票房收入的关联;Netflix的模型,则挖掘了观众对不同电影的偏好,以及其他的行为特点。挖掘什么信息,一方面取决于我们有哪些数据,另一方面也取决于什么样的信息可能有助于商业决策。
  三.有什么行业经验是可以结合的。单纯地数据分析,可能会找到很多规律,但这些规律未必是有实际价值的。只有当数据结合行业经验,才更容易形成精准的行业模型,从而产生巨大的价值。
  而卡森伯格说的“不靠数据”,更多的是强调电影创作本身。电影的创作充满了艺术,是很难形成科学的规律的。即便如此,大数据对电影创作也可以起到一定的辅助作用。毕竟,了解观众的需求,也是电影创作的重要参考。

Hadoop的分块与分片

HDFS存储系统中,引入了文件系统的分块概念(block),块是存储的最小单位,HDFS定义其大小为64MB。与单磁盘文件系统相似,存储在HDFS上的文件均存储为多个块,不同的是,如果某文件大小没有到达64MB,该文件也不会占据整个块空间。在分布式的HDFS集群上,Hadoop系统保证一个块存储在一个datanode上。
当我们执行hadoop fs -put aa.txt /bb.txt,则aa.txt会被复制为集群的/bb.txt。查看系统的log日志hadoop-$username-namenode-*.log,可以看到类似于
2011-09-07 08:39:12,506 INFO org.apache.hadoop.hdfs.StateChange: BLOCK* NameSystem.addStoredBlock: blockMap updated: 127.     0.0.1:50010 is added to blk_5715489406767973176_1455 size 32
这样的信息,里面记录有分配block的元数据信息和block号(blk_5715489406767973176)。
在另一个日志中hadoop-$username-datanode-*.log可以看到对应的datanode打印出相应的log:
2011-09-07 08:39:12,495 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: Receiving block blk_5715489406767973176_145     5 src: /127.0.0.1:48492 dest: /127.0.0.1:50010
HDFS的namenode只存储整个文件系统的元数据镜像,这个镜像由配置dfs.name.dir指定,datanode则存有文件的metainfo和具体的分块,存储路径由dfs.data.dir指定。
分析完毕分块,下面讨论一下分片:
hadoop的作业在提交过程中,需要把具体的输入进行分片。具体的分片细节由InputSplitFormat指定。分片的规则为  FileInputFormat.class中的getSplits()方法指定:
long splitSize = computeSplitSize(goalSize, minSize, blockSize);
computeSplitSize:
Math.max(minSize, Math.min(goalSize, blockSize));
其中goalSize为“InputFile大小”/“我们在配置文件中定义的mapred.map.tasks”值,minsize为mapred.min.split.size,blockSize为64,所以,这个算式为取分片大小不大于block,并且不小于在mapred.min.split.size配置中定义的最小Size。
当某个分块分成均等的若干分片时,会有最后一个分片大小小于定义的分片大小,则该分片独立成为一个分片。
http://hi.baidu.com/chemical_liang/item/bd2d0163eb54d3177ddecceb

linux swap命令

一般来说可以按照如下规则设置swap大小:
4G以内的物理内存,SWAP 设置为内存的2倍。
4-8G的物理内存,SWAP 等于内存大小。
8-64G 的物理内存,SWAP 设置为8G。
64-256G物理内存,SWAP 设置为16G。
系统中交换分区的大小并不取决于物理内存的量,而是取决于系统中内存的负荷,所以在安装系统时要根据具体的业务来设置SWAP的值。
查看swap使用的情况:

swapon -s
free -m
cat /proc/sys/vm/swappiness

该值默认值是60.
swappiness=0的时候表示最大限度使用物理内存,然后才是 swap空间,
swappiness=100的时候表示积极的使用swap分区,并且把内存上的数据及时的搬运到swap空间里面。

实现ssh无密码登录的实现方法

实现ssh无密码登录的实现方法:
步骤1: 用 ssh-key-gen 在本地主机上创建公钥和密钥
先在本机上创建一个文件夹执行命令:mkdir .ssh
接着生成公钥和密钥,执行命令:ssh-keygen -t rsa
Enter file in which to save the key (/home/jsmith/.ssh/id_rsa):[Enter key]
Enter passphrase (empty for no passphrase): [Press enter key]
Enter same passphrase again: [Pess enter key]
Your identification has been saved in /home/jsmith/.ssh/id_rsa.
Your public key has been saved in /home/jsmith/.ssh/id_rsa.pub.
The key fingerprint is: 33:b3:fe:af:95:95:18:11:31:d5:de:96:2f:f2:35:f9
ligh@local-host
步骤2: 用 ssh-copy-id 把公钥复制到远程主机上
ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.0.3
ligh@remote-host‘s password:
Now try logging into the machine, with ―ssh ?remote-host‘‖, and check in:
.ssh/authorized_keys to make sure we haven‘t added extra keys that you weren‘t expecting.
[注: ssh-copy-id 把密钥追加到远程主机的 .ssh/authorized_keys 上.]
步骤3: 直接登录远程主机
ssh remote-host
Last login: Sun Nov 16 17:22:33 2008 from 192.168.1.2

数据分析相关概念的理解

所有的数据产品最后都可以抽象成:指标 +维度
维度,能够向上聚合(实际上就是SUM)
对于部分复合型指标,实际上就是由多个基础指标经过一些简单的数学运算得到
指标和维度是业务来定的,与技术无关
将这些指标和维度,按照分析的主题域梳理成指标维度矩阵