LinkedIn Camus踩坑记录
首先，介绍下Camus吧。
由LinkedIn公司开发的消息队列同步框架，提供将Kafka（一种消息队列框架）的数据装载到Hadoop分布式文件系统(HDFS)的功能。
英文版原文出处：http://docs.confluent.io/2.0.1/camus/docs/intro.html#key-features
简单来说camus其实底层还是执行的mapreduce，一个将kafka数据拉取hdfs的工具。这个工具相对来说比较小众，但是好处就是使用简单，学习成本低，相对来说跑的是mapreduce还是比较稳定安全的，美团等大厂也有在使用该工具，并对其进行二次开发使用。
同时介绍几个与Camus类似的组价，可参考https://blog.csdn.net/clerk0324/article/details/60580706这篇文章。
基础使用篇的话我后面补上，先说下我的踩坑记录吧，毕竟排查加解决花费了整整一天的时间，还是值得记录下来的.
背景介绍：当时由于某些原因，需要处理历史数据并入到hive表，历史数据时间跨度三年，数据量3T左右，我这边处理的流程是filebeat->kafka->sparkstreaming->kafka这样一个流程，最后通过camus去拉取kafka对应topic的数据到hdfs(hdfs文件以天为单位进行分区以方便load到hive表中)。从kafka拉取下来的文件到hdfs大致是这样的：
遇到的异常报错是：找不到block位置的异常。
我开始了焦虑的排错过程。首先有怀疑是不是hadoop namenode出了问题，但是这个怀疑很快就排除了，其他camus任务都是正常执行的，并没有报错。
其次，怀疑是否有两个相同camus任务在执行，你在执行这个任务，别人也在执行这个任务，而且都写到相同的目录下，导致block文件被前一个camus任务取走，后面一个camus任务找不到block块的情况。后面通过反复确定Azkaban上定时任务已经停止，在集群上手动执行任务只有一个camus任务在跑的还是会出现找不到block块异常后，也排除了这个可能性。中间也切换过不使用root用户，使用普通的hadoop用户及work用户去执行camus任务，也是不行，报相同的错误。
最后，我怀疑可能是日期跨度比较大引起的，因为camus平时我们用的很多，也用了一年多了，从来没有出现过这种情况的异常。这次的数据与以往数据的不同在于时间跨度大，而我们拉取到hdfs的时候恰恰还按天为单位进行分区。于是我试着不按日期进行分区，即拉取到hdfs的数据都放到一个目录下。奇迹发生了，它竟然跑完了任务没有报错，一口气把kafka 累积的数据都拉取了下来。
总结：此处应该是camus的一个bug 它拉取数据下来到hdfs可以再加一步，按照指定的字段进行分区，之前跑的每天的离线任务没点问题，这次跑的历史数据大概两年多的数据，按这个时间分区可能它代码分布式协调这块处理的不是很好，所以会出现其他节点处理了一个block的数据，又有一个节点去这个位置找block块，就出现找不到block块的报错了。