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

翻译自：https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Authorization

提起索引大家通常想到的就是MySQL等关系型数据库管理系统的索引，但索引的定义远远不止这么窄：HBase TreeMap形式的聚集索引，ES等搜索引擎的倒排索引，甚至数组的下标都可以被称为index。

那么索引该怎么定义呢？我从各个权威网站并没有找到很好的描述：Wikipedia并没有为computer science的index做一个概述，而是细分成lookup table、database index、search engine index等进行说明；百度百科只针对数据库领域进行说明：在关系数据库中，索引是一种单独的、物理的对数据库表中一列或多列的值进行排序的一种存储结构，它是某个表中一列或若干列值的集合和相应的指向表中物理标识这些值的数据页的逻辑指针清单；较为满意的一个答案是THE FRRE DICTIONARY上：Something that serves to guide, point out, or otherwise facilitate reference（用于引导、指出或其他帮助引用的事物），不过不够详细具体。

以我的理解，索引的本质是基于对象的一个或多个属性按照某种数据结构（树、哈希、有序链表等）进行组织，以加速查找的一种技术。其中有两个关键点，一是基于一个或多个属性，二是数据结构。

目前大数据计算通常分为两大类：以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(尽管已经关闭)，还是很开心的啦。