专注思考的时候，时间仿佛也静下来了

目前大数据计算通常分为两大类：以Storm为代表的实时计算和以MapReduce为代表的离线计算。实时计算对数据处理时间有着较高的要求，对于延迟阈值大数据界一直没有统一标准，默认是秒级（严格来说实时系统必须保证在某个时间边界内响应，通常是毫秒级或亚秒级，但无论是Spark Streaming还是Storm都只能保证计算时间较低，因此应该属于近实时系统）。离线计算对数据处理时间不太敏感，通常只要求在N+1的时间内看到结果。

Join操作是数据处理中必不可少的一部分，传统关系型数据库经历多年对高效率join的研究和技术沉淀，已经非常成熟。然而在分布式环境下，数据存在不同程度的异构并缺乏索引等机制，使得传统的join优化技术难以应用。更重要的join是一个全局操作，一台物理机器需要大量网络IO获取join计算需要的记录，而网络却正是分布式计算最为珍贵的资源。以上种种原因导致分布式join与传统关系型join有着较大的差别（当然这仅仅是目前的状况，分布式计算也在不断借鉴关系型数据库的经验）。

分布式计算中的join大部分基于MapReduce计算模型，根据join操作实现的阶段可以分为reduce join和map join两大类，其余都是在该基础上进行优化。

在默认的情况下，MapReduce在HDFS上新建一个目录作为输出目录。目录结构如下:

- _SUCCESS
- part-r-00000
- part-r-00001

其中_SUCCESS是一个空文件，表示任务成功，其他是输出文件。输出文件的文件名有三个部分:part是固定的，r表示是reduce的输出，最后的5位数表示是第几个reduce。每个reduce的输出都是独立的，利用这点可以实现将记录分类输出到不同文件。具体方式是将用于分类的字段放到map output的key中，并实现partitioner按照自己设定的规则分类。

前段时间Spenser有篇文章，大意是平台就是本事，因为环境在绝大多数人的成长中起到决定性作用，好的平台可以给你带来机会、圈子和背书。

我基本上赞同。从统计学角度说，在好的环境成长能力更强也是理所当然。如果你本来就在好平台，那么你只需要不犯错误就能利用马太效应逐渐积累优势。然而，好平台也是相对的，比如一线互联网公司可以算得上好平台，但公司内不同部门也千差万别，在鹅厂做电商和做游戏是几乎不能比的。所以更加有价值的是，如何在坏环境下减少负面影响？

一般情况下，使用add partition语句为Hive表新增partition:

1

ALTER TABLE table_name ADD [IF NOT EXISTS] PARTITION (partition_column1='value1', partition_column2='value2',) [LOCATION 'location1'];

其中Location默认为最低层目录，如果该目录仍包含子目录，Hive就会报错。

本文翻译自：Flume Memory Consumption

在Spark三种常见的资源调度器，YARN、Mesos和Standalone中，最受欢迎的莫过于YARN。YARN与Hadoop原生集成，可以支持不同计算框架在Hadoop集群上的调度，这使得Spark on YARN无需改变配置就可以与MapReduce共享同一个资源池，避免了资源浪费，节省了开发成本。

最近接入一个新的日志，需要导入历史数据。数据分析师跟我说的时候我爽快地答应了，不就是ETL么，没想到在调用flume接口上卡了一个星期，今天查flume源码终于才搞定。虽然周末都花费在debug上，不过第一次算是解决了一个jira上的issuse(尽管已经关闭)，还是很开心的啦。

最近用到Spark比较多，于是打算深入学习下Spark的调优。我谷歌下发现网上调优的经验还是比较散乱，所以决定将官方文档翻译下，为国内开源社区贡献一点力量。另外不得不吐槽翻译真是个体力活，90%的时间都花费在IO上了。

平时spark thrift server多用来做探索性的查询，比如验证下数据格式或count一下某天数据数量，都是轻量级的查询，查询效率也比较满意。没想到最近要真正用起来的时候，却遭遇各种瓶颈。