数据从kafka到hive（2）
前面一篇讲到了将数据从kafka读到hdfs使用了开源工具camus，既然用到了开源的代码，免不了研究一下实现过程。所以这里分享一下阅读camus代码了解到的一些细节。
前置知识
在讲camus之前，需要提一下hadoop的一些知识。
关于inputFormat
inputFormat类的原型如下：
public interface InputFormat {
InputSplit[] getSplits(JobConf job, int numSplits) throws IOException;
RecordReader getRecordReader(InputSplit split,JobConf job,Reporter reporter) throws IOException;
} hadoop job调用setInputFormat来设置InputFormat类，通过getSplits函数，hadoop可以将输入分割为InputSplit，每个map分配到InputSplit后，再通过getRecordReader获取reader，逐条读取输入文件中Key-Value。hadoop本身提供了一些InputFormat类的实现，如TextInputFormat，KeyValueTextInputFormat，SequenceFileInputFormat等；
除了使用hadoop本身提供的这些类以外，hadoop允许自定义InputFormat类，只需要实现相应的getSplits函数和RecoderReader类即可。
关于OutputFormat 和 OutputCommitter
OutputFormat类用于写入记录，原型如下：
public abstract class OutputFormat {
//创建一个写入器
public abstract RecordWriter getRecordWriter(TaskAttemptContext context) throws IOException, InterruptedException;
// 检查结果输出的存储空间是否有效
public abstract void checkOutputSpecs(JobContext context) throws IOException, InterruptedException;
//创建一个任务提交器
public abstract OutputCommitter getOutputCommitter(TaskAttemptContext context) throws IOException, InterruptedException;
} getRecordWriter和checkOutputSpecs都很好理解，前置就是将Mapper或Reducer传来的key-value写入到文件里面，写入的姿势由它来决定。而checkOutputSpecs一般就是用来检查输出规范，判断输出文件是否存在，如果已经存在，则抛出异常。
OutputCommitter稍稍难理解一点，里面定义了这几个方法：
//Job开始被执行之前，框架会调用setupJob()为Job创建一个输出路径
void setupJob(JobContext jobContext);
//如果Job成功完成，框架会调用commitJob()提交Job的输出
void commitJob(JobContext jobContext);
//如果Job失败，框架会调用OutputCommitter.abortJob()撤销Job的输出
void abortJob(JobContext jobContext, JobStatus.State state);
//Task执行前的准备工作，类似setupJob
void setupTask(TaskAttemptContext taskContext);
//Task可能没有输出，也就不需要提交，通过needsTaskCommit()来判断
boolean needsTaskCommit(TaskAttemptContext taskContext);
//Task成功执行，提交输出
void commitTask(TaskAttemptContext taskContext);
//Task执行失败，清理
void abortTask(TaskAttemptContext taskContext);一般是这样一个过程：Job执行的时候，Task的输出放到Output路径下的_temporary目录的以TaskAttemptID命名的子目录中。只有当 Task成功了，相应的输出才会被提交到Output路径下。而只有当整个Job都成功了，才会在Output路径下放置_SUCCESS文件。 _SUCCESS文件的存在表明了Output路径下的输出信息是正确且完整的；而如果_SUCCESS文件不存在，Output下的信息也依然是正确的 （这已经由commitTask保证了），但是不一定是完整的（可能只包含部分Reduce的输出）。
camus的实现
camus重写了inputFormat和outputFormat类。
重写getSplits
camus是以map-reduce的方式执行的，实际上，它没有设置reduce任务，map完成后，直接将文件写入到了目标目录下。
camus的主要工作都是在InputFormat和OutputFormat中完成的。前面说到过自定义InputFormat，camus正是通过自定义的EtlInputFormat类完成了读取任务的分割。
EtlInputFormat的getSplits函数需要将抽数任务分割为几个独立的splits，而kafka的partition之间的消息没有顺序关系，正好符合这种条件。分割流程如下：
1.获取topic下各个partition的leader信息，得到一个映射关系为LeaderInfo -> List 的map，也就是各个partition的leader连接信息，再加上leader所在的partition列表。关键核心代码如下：
//获取kafka集群TopicMetadata信息，这些信息包括各个partition的leaderId,replicas以及Isr，存在于每一个broker上，所以即便brokerList不完整或者有broker挂了也不会影响。
List topicMetadataList = getKafkaMetadata(context, new ArrayList());
//对于每一个topic下的每一个partition，执行操作
for (TopicMetadata topicMetadata : topicMetadataList) {
for (PartitionMetadata partitionMetadata : topicMetadata.partitionsMetadata()) {
//为每个partition的leader创建LeaderInfo对象
LeaderInfo leader =new LeaderInfo(new URI("tcp://" + partitionMetadata.leader().getConnectionString()),partitionMetadata.leader().id());
//下面这一段，就是将leader相同的partition放在一起
//最终得到Map topicAndPartitions = offsetRequestInfo.get(leader);
topicAndPartitions.add(new TopicAndPartition(topicMetadata.topic(),partitionMetadata.partitionId()));
offsetRequestInfo.put(leader, topicAndPartitions);
} else {
//和上面一样，只是在offsetRequestInfo中没有leader时有个新建List的操作
.....
}
}
} 2.根据LeaderInfo -> List的映射关系，向每个partition的leader请求earliest offset和lastest offset。kafka的每个broker上的log会定期删除，earliest offset就是leader上保存的最早的log偏移量，而lastest offset则是最新log偏移量。在这之后，camus还会读取上次执行信息，其中包含上次任务每个partition读取完成的offset，作为本次任务读取的起始点。上次执行执行信息保存在配置项etl.execution.base.path对应的路径下。根据每个partition的earliest offset、lastest offset、offset组装成List，即请求列表。
CamusRequest是一个接口，主要信息如下：
//获取当前请求的topic
public abstract String getTopic();
//获取当前请求的URI
public abstract URI getURI();
//获取当前请求的partition
public abstract int getPartition();
//获取请求的起始offset
public abstract long getOffset();
public abstract long getEarliestOffset();
//获取partition的最大偏移量
public abstract long getLastOffset();
public abstract long estimateDataSize();有了这些信息，就可以开始分派request到各个mapper了。
3.默认使用BaseAllocator分派request，其中的关键函数如下：
@Override
public List allocateWork(List requests, JobContext context) throws IOException {
//获取配置项中mapred.map.tasks的map数目，一个mapper可以执行多个partition的抽数任务
int numTasks = context.getConfiguration().getInt("mapred.map.tasks", 30);
//按数据量由大到小给每个partition的request排序
reverseSortRequests(requests);
//初始化splists，这时候每个splits里面的request数目为0
List kafkaETLSplits = new ArrayList();
for (int i = 0; i < numTasks; i++) {
if (requests.size() > 0) {
kafkaETLSplits.add(new EtlSplit());
}
}
//分配request到各个splits，算法很简单，当前哪个splits的数据量最少，就给那个splits添加request，因为是按由大到小排序的，所以任务比较均匀
for (CamusRequest r : requests) {
getSmallestMultiSplit(kafkaETLSplits).addRequest(r);
}
return kafkaETLSplits;
} allocateWork函数返回的就是List类型，也就是EtlInputFormat.getSplits的返回值。
从InputSplit中读取message
每个InputSplit中可能包含多个CamusRequest，每个CamusRequest是不同partition的读数请求，其中包含Topic，Partition，leader URI，offset，lastest offset等信息。前面说到过，InputFormat需要重写createRecordReader函数，也就是定义如何从split中读取key-value。
EtlInputFormat.createRecordReader返回一个EtlRecordReader实例，由该实例读取kafka message发送给mapper。
RecordReader需要重写函数boolean nextKeyValue()，在数据读完之前，该函数一直返回true。
EtlRecordReader.nextKeyValue 核心代码(有删减)如下：
while (true) {
//reader为KafkaReader类型，该类专门负责逐条读取kafka消息
if (reader == null || !reader.hasNext()) {
//从InputSplit中弹出request
EtlRequest request = (EtlRequest) split.popRequest();
//传给mapper的key，这里是类成员变量，后面直接由getCurrentKey()返回
key.set(request.getTopic(), request.getLeaderId(), request.getPartition(), request.getOffset(),request.getOffset(), 0);
//在reader为null，或者一个partition中的数据已经读完的情况下，新建reader，reader负责从kafka中读取数据
reader =new KafkaReader(inputFormat, context, request, CamusJob.getKafkaTimeoutValue(mapperContext),CamusJob.getKafkaBufferSize(mapperContext));
//创建消息decoder，由配置camus.message.decoder.class指定，从kafka中读取出的为byte[]类型，decoder类负责将字节转换为最终在hdfs上存放的格式
decoder = createDecoder(request.getTopic());
}
while ((message = reader.getNext(key)) != null) {
//用decoder解码消息，封装在CamusWrapper中
CamusWrapper wrapper = getWrappedRecord(message);
value = wrapper;
return true;
}
EtlRecordReader.getCurrentKey和EtlRecordReader.getCurrentValue直接返回nextKeyValue中的key，value。Mapper正是直接将这两个函数的返回值作为入参。至此，InputFormat的工作就做完了。Mapper收到key-value后什么也没做，直接调用context.write(key, val)写入，因为没有reducer，所以结果会直接由OutputFormat输出。
OutputFormat输出message
EtlMultiOutputFormat重写了OutputFormat的getRecordWriter和getOutputCommitter函数。getRecordWriter返回一个EtlMultiOutputRecordWriter类的实例，它负责将Task的输出放到Output路径下，而由getOutputCommitter获取的EtlMultiOutputCommitter类实例在Task完成后将输出拷贝到最终目的地。
EtlMultiOutputRecordWriter.write(EtlKey key, Object val)负责执行写入key-value工作，核心代码如下：
//key中包含的是关于kafka的信息，如当前消息的offset，topic，parition等
//val中是具体的message，也就是前面从kafka 消息的bytes[]中获取的
public void write(EtlKey key, Object val) throws IOException, InterruptedException {
//当前message的key是否和前面message的一致，因为一个split可能包含不同paritition的数据，也就是一个mapper就可能处理不同partition
if (!key.getTopic().equals(currentTopic)) {
//如果topic不一致，则需要清除writer，重新创建新的topic的，之所有有很多writer，是因为topic下会有多个partition，不同partition写入到不同的文件中
for (RecordWriter writer : dataWriters.values()) {
writer.close(context);
}
dataWriters.clear();
//更新当前topic
currentTopic = key.getTopic();
}
//将当前的key的offset存入到 (topic+partition)-> offset 的map中，因为同一partition消息是顺序的，所以最后存入的肯定是offset最大的消息，committer会将这个map写入到执行记录目录中，下一次运行时以这个offset为起点
committer.addCounts(key);
CamusWrapper value = (CamusWrapper) val;
//获取写入文件名
String workingFileName =EtlMultiOutputFormat.getWorkingFileName(context, key);
//如果现有的writer中不包含对应文件的，则新建一个
if (!dataWriters.containsKey(workingFileName)) {
dataWriters.put(workingFileName, getDataRecordWriter(context,workingFileName, value));
log.info("Writing to data file: " + workingFileName);
}
//将key-value写入到Taks的输出目录下临时文件中
dataWriters.get(workingFileName).write(key, value); 大部分的信息都在注释中写了，这个理解起来也简单，就是将key-value写到临时文件里，同时把每个key的offset按partition存放起来，在任务成功时写到文件里。
EtlMultiOutputCommitter只实现了commitTask函数，该函数在任务（不是整个Job）完成后被调用。前面已经将输入写到输出目录下的临时文件里了，commitTask要做的就是将文件拷贝到配置etl.destination.path对应的路径下，拷贝完后再将 write函数中写入的(topic+partition)-> offset 键值对写入到etl.execution.base.path目录下，下次任务执行时，会从这个目录下读取offset，作为起始offset。如果某个Task失败，offset也不会写入，下次读取时还是会重新读一遍，而其他Task不受影响。
还是贴一部分核心代码：
//获取配置etl.destination.path对应的目录，作为最终输出目录
Path baseOutDir = EtlMultiOutputFormat.getDestinationPath(context);
//这里fs是前面write函数写入的目录，也就是Task的output路径
//列举其中的文件，数据文件的文件名都是以data开头的
for (FileStatus f : fs.listStatus(workPath)) {
String file = f.getPath().getName();
if (file.startsWith("data")) {
//数据文件名中包含topic，partition，offset，time等信息
//根据文件名，消息计数等信息获得最终的输出路径和输出文件名
//输出路径是以小时分割的，basePath/year/month/day/hour/filename
String partitionedFile =
getPartitionedPath(context, file, count.getEventCount(), count.getLastKey().getOffset());
//如果路径不存在，创建路径
Path dest = new Path(baseOutDir, partitionedFile);
if (!fs.exists(dest.getParent())) {
mkdirs(fs, dest.getParent());
}
//拷贝文件，从Task输出目录下拷贝到目标文件
commitFile(context, f.getPath(), dest)；
}
}
//后面还有一段写入offset的，只有写入数据成功后才会写入offset