hunhun -- Any answers you can find in source code.

错误出现场景

使用kill -9 pid强制退出kafka进程之后，重启出现此错误，提示信息如下

1
2
3

ERROR There was an error in one of the threads during logs loading: java.lang.IllegalArgumentException: requirement failed: Corrupt index found, index file (${log.dirs}/${topicName}-0/00000000000001964914.index) has non-zero size but the last offset is 1964914 and the base offset is 1964914 (kafka.log.LogManager)
[2016-02-22 18:01:01,213] FATAL [Kafka Server 0], Fatal error during KafkaServer startup. Prepare to shutdown (kafka.server.KafkaServer)
java.lang.IllegalArgumentException: requirement failed: Corrupt index found, index file (${log.dirs}/${topicName}-0/00000000000001964914.index) has non-zero size but the last offset is 1964914 and the base offset is 1964914

利用flume进行日志采集已在业界广泛使用，如果需要采集的log比较多，并且分布在多个服务器上，那么对flume agent的管理就是一个头疼的事情。
本篇主要介绍下利用zookeeper对flume进程进行监控，当flume异常退出时进行报警，以至于我们能够及时的发现故障解决故障。

前几天看到别人的博客有个近期文章版块，感觉挺好，于是就想给自己的博客也加这么个功能。由于使用的是next主题，而next默认是没有这个版块的，那就自己搞一个吧。废话不多说，直接上代码，挺简单的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{% if theme.recent_posts %}
    <div class="links-of-blogroll motion-element {{ "links-of-blogroll-" + theme.recent_posts_layout  }}">
      <div class="links-of-blogroll-title">
        <!-- modify icon to fire by szw -->
        <i class="fa fa-history fa-{{ theme.recent_posts_icon | lower }}" aria-hidden="true"></i>
        {{ theme.recent_posts_title }}
      </div>
      <ul class="links-of-blogroll-list">
        {% set posts = site.posts.sort('-date') %}
        {% for post in posts.slice('0', '5') %}
          <li>
            <a href="{{ url_for(post.path) }}" title="{{ post.title }}" target="_blank">{{ post.title }}</a>
          </li>
        {% endfor %}
      </ul>
    </div>
{% endif %}

将此代码贴在next/layout/_macro/sidebar.swig中的if theme.links对应的endif后面，就ok了，是不是很简单。。。。
为了配置方便，在主题的_config.yml中添加了几个变量，如下：

1
2
3

recent_posts_title: 近期文章
recent_posts_layout: block
recent_posts: true

MapReduce天生就具有排序的特性，但是面对稍微复杂的排序时我们还是希望能够充分利用其自身的设计原理来达到我们的目的。其中二次排序就是一个很好的例子，下面主要介绍下二次排序。

二次排序的场景是不仅需要对key排序依然需要对value中的某个值进行排序，也就是先对key排序然后对相同key的record再对value进行排序。

对key排序我们可以使用MR自身的排序，但是怎么对value中的某个值进行排序呢？

MapReduce留出了很多可以自定义的接口，比如partition、comparator和group等等接口，这里只需用到这三个，其它以后用的接口再介绍。

之前有两篇文件分别分析了Map和Reduce阶段的流程，这篇文章把Map阶段的环形缓冲区单独拿出来进行分析，对环形缓冲区的数据结构和数据进入环形缓冲区然后溢写到磁盘的流程进行分析。

MapReduce–Map

MapReduce由Map和Reduce组成，而Map和Reduce又可以分为很多个小phase，下面就从源码的角度去扒下Map的流程。
通过intellij idea进行debug调试，在New API的流程发现Map中具体流程可以大致分为两种情况：有Reduce和没有Reduce

• 没有Reduce

split–>read–map(用户自定义的map函数)–>write(未排序)–>output

• 有Reduce

split–>read–>map(用户自定义的map函数)–>partition–>collect–>buffer–>quicksort–>(combiner)–>spill–>merge(heapsort、combiner)–>output

本篇主要介绍有Reduce的情况下Map中各个阶段的流程。

MR本身就具有排序功能，但是其分布式的特性使其无法较理想的进行全局排序。难道要想使用MR进行全局排序时只能将其结果都输入到一个reduce中？那这不就违背了其分布式的特性了嘛。于是大牛们想到了在map分区时保证分区的有序性，使其分配到第一个reduce中的key一定小于分配到第二个reduce中的key，此功能就是本篇要解析的分区类TotalOrderPartitioner。

上篇从应用的角度展示了TotalOrderPartitioner如何进行全局排序。本篇从代码的角度解析下TotalOrderPartitioner是怎么实现的，其中又用到了哪些黑科技。。。

TotalOrderPartitioner之所以能够实现全局排序，是因为其在分区时依赖一个分区文件，其文件中记录了将key进行分区的分界点，是这些分界点起到了关键作用。这些分界点保证了某一区间的key分到同一个reduce中，而TotalOrderPartitioner只是将key和分界点比较的过程进行了优化，使其在大数据规模下能够高效的进行。

MapReduce就是将一个大job切分为n个task，由map和reduce分别去执行，但是切分规则是什么呢？其实job的切分也就是job所需文件的切分。

下面就从源码的角度简单分析下。

文件切分

MR是通过JobSubmitter.submitJobInternal提交给RM的，在submitJobInternal中通过writeSplits(JobContext job, Path jobSubmitDir)将job的输入文件进行split，writeSplit只是对新旧api进行了下封装，根据你的代码选择新旧api，这里调用writeNewSplits使用新API对file进行split

用win时，有xshell之类的工具帮你记录服务器或者跳板机的密码，但到mac/linux上时虽然也有这样的软件，但mac本身就有终端，再用这样软件使用shell，感觉不太舒服(我有个怪癖，就是电脑能不装的软件决不安装)。于是就想自己写个脚本实现这样的功能。

那就开始干吧，这里自己给自己埋了个坑，那就是当初在win上生成rsa时，输入了密码，结果在mac上执行ssh-add添加密钥时需要输入密码，这就使脚本不太自动化，需要手动输入密码。
于是只能求助google了，发现了expect，于是就把脚本升级了下，内容如下：

没有expect则利用brew安装，命令brew install expect

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#!/usr/bin/expect
spawn ssh -A -p port username@ip
expect {
    "*?ermission denied" {
        set password "生成rsa时的密码"
        spawn ssh-add /Users/hadoop/.ssh/id_rsa_2048
        expect "passphrase"
        send "$password\n"
        interact
        spawn ssh -A -p port username@ip
    }
    "*?ast login*" {
    }
}
interact

join是sql中常用的关键字，同样在hive中，join语句也经常被用到，尤其是一些outer join语句，但在使用这样outer join语句时，不小心就会踩到坑里，使结果与预期的不一样，或者使sql执行不够高效。

这里就详细介绍下hive outer join。

下面先看几个概念：

• 保留表(Preserved Row table)

在outer join中需要返回所有数据的表叫做保留表，也就是说在left outer join中，左表需要返回所有数据，则左表是保留表；right outer join中右表则是保留表；在full outer join中左表和右表都要返回所有数据，则左右表都是保留表。

• Null Supplying table(这个怎么翻译？ 支持null的表？？？？)

在outer join中对于没有匹配到的行需要用null来填充的表称为Null Supplying table。在left outer join中，左表的数据全返回，对于左表在右表中无法匹配的数据的相应列用null表示，则此时右表是Null Supplying table，相应的如果是right outer join的话，左表是Null Supplying table。但是在full outer join中左表和右表都是Null Supplying table，因为左表和右表都会用null来填充无法匹配的数据。

此时你会发现full outer join就是个矛盾体，因为此时的左表和右表即使保留表又是Null Supplying table，这就导致在outer join中谓词下放时有一些问题。

• Join中的谓词

Join中的谓词是指 Join On语句中的谓词。如：’R1 join R2 on R1.x = 5’ the predicate ‘R1.x = 5’是Join中的谓词

• Join之后的谓词

where语句中的谓词称之为Join之后的谓词