mapReduce部分

* MapReduce MAP :映射 reduce :归纳*
简单来说，一个映射函数就是对一些独立元素组成的概念上的列表（例如，一个测试成绩的列表）的每一个元素进行指定的操作（比如，有人发现所有学生的成绩都被高估了一分，他可以定义一个“减一”的映射函数，用来修正这个错误。）。 * 事实上，每个元素都是被独立操作的，而原始列表没有被更改，因为这里创建了一个新的列表来保存新的答案。 * 这就是说，Map操作是可以高度并行的，这对高性能要求的应用以及领域的需求非常有用。
而归纳操作指的是对一个列表的元素进行适当的合并（继续看前面的例子，如果有人想知道班级的平均分该怎么做？他可以定义一个归纳函数，通过让列表中的奇数（odd）或偶数（even）元素跟自己的相邻的元素相加的方式把列表减半，如此递归运算直到列表只剩下一个元素，然后用这个元素除以人数，就得到了平均分）。虽然他不如映射函数那么并行，但是因为归纳总是有一个简单的答案，大规模的运算相对独立，所以归纳函数在高度并行环境下也很有用。

avro部分


Avro（读音类似于[ævrə]）是Hadoop的一个子项目，由Hadoop的创始人Doug Cutting（也是Lucene，Nutch等项目的创始人，膜拜）牵头开发，当前最新版本1.3.3。Avro是一个数据序列化系统，设计用于支持大批量数据交换的应用。它的主要特点有：支持二进制序列化方式，可以便捷，快速地处理大量数据；动态语言友好，Avro提供的机制使动态语言可以方便地处理Avro数据。
当前市场上有很多类似的序列化系统，如Google的Protocol Buffers, Facebook的Thrift。这些系统反响良好，完全可以满足普通应用的需求。针对重复开发的疑惑，Doug Cutting撰文解释道：Hadoop现存的RPC系统遇到一些问题，如性能瓶颈(当前采用IPC系统，它使用Java自带的DataOutputStream和DataInputStream)；需要服务器端和客户端必须运行相同版本的Hadoop；只能使用Java开发等。但现存的这些序列化系统自身也有毛病，以Protocol Buffers为例，它需要用户先定义数据结构，然后根据这个数据结构生成代码，再组装数据。如果需要操作多个数据源的数据集，那么需要定义多套数据结构并重复执行多次上面的流程，这样就不能对任意数据集做统一处理。其次，对于Hadoop中Hive和Pig这样的脚本系统来说，使用代码生成是不合理的。并且Protocol Buffers在序列化时考虑到数据定义与数据可能不完全匹配，在数据中添加注解，这会让数据变得庞大并拖慢处理速度。其它序列化系统有如Protocol Buffers类似的问题。所以为了Hadoop的前途考虑，Doug Cutting主导开发一套全新的序列化系统，这就是Avro，于09年加入Hadoop项目族中。
上面通过与Protocol Buffers的对比，大致清楚了Avro的特长。下面着重关注Avro的细节部分。
Avro依赖模式(Schema)来实现数据结构定义。可以把模式理解为Java的类，它定义每个实例的结构，可以包含哪些属性。可以根据类来产生任意多个实例对象。对实例序列化操作时必须需要知道它的基本结构，也就需要参考类的信息。这里，根据模式产生的Avro对象类似于类的实例对象。每次序列化/反序列化时都需要知道模式的具体结构。所以，在Avro可用的一些场景下，如文件存储或是网络通信，都需要模式与数据同时存在。Avro数据以模式来读和写(文件或是网络)，并且写入的数据都不需要加入其它标识，这样序列化时速度快且结果内容少。由于程序可以直接根据模式来处理数据，所以Avro更适合于脚本语言的发挥。 Avro的模式主要由JSON对象来表示，它可能会有一些特定的属性，用来描述某种类型(Type)的不同形式。Avro支持八种基本类型(Primitive Type)和六种混合类型(Complex Type)。基本类型可以由JSON字符串来表示。每种不同的混合类型有不同的属性(Attribute)来定义，有些属性是必须的，有些是可选的，如果需要的话，可以用JSON数组来存放多个JSON对象定义。在这几种Avro定义的类型的支持下，可以由用户来创造出丰富的数据结构来，支持用户纷繁复杂的数据。
Avro支持两种序列化编码方式：二进制编码和JSON编码。使用二进制编码会高效序列化，并且序列化后得到的结果会比较小；而JSON一般用于调试系统或是基于WEB的应用。对Avro数据序列化/反序列化时都需要对模式以深度优先(Depth-First)，从左到右(Left-to-Right)的遍历顺序来执行。基本类型的序列化容易解决，混合类型的序列化会有很多不同规则。对于基本类型和混合类型的二进制编码在文档中规定，按照模式的解析顺序依次排列字节。对于JSON编码，联合类型(Union Type)就与其它混合类型表现不一致。 Avro为了便于MapReduce的处理定义了一种容器文件格式(Container File Format)。这样的文件中只能有一种模式，所有需要存入这个文件的对象都需要按照这种模式以二进制编码的形式写入。对象在文件中以块(Block)来组织，并且这些对象都是可以被压缩的。块和块之间会存在同步标记符(Synchronization Marker)，以便MapReduce方便地切割文件用于处理。下图是根据文档描述画出的文件结构图： [图片上传中。。。（1）]
上图已经对各块做肢解操作，但还是有必要再详细说明下。一个存储文件由两部分组成:头信息(Header)和数据块(Data Block)。而头信息又由三部分构成：四个字节的前缀(类似于Magic Number)，文件Meta-data信息和随机生成的16字节同步标记符。这里的Meta-data信息让人有些疑惑，它除了文件的模式外，还能包含什么。文档中指出当前Avro认定的就两个Meta-data：schema和codec。这里的codec表示对后面的文件数据块(File Data Block)采用何种压缩方式。Avro的实现都需要支持下面两种压缩方式：null(不压缩)和deflate(使用Deflate算法压缩数据块)。除了文档中认定的两种Meta-data，用户还可以自定义适用于自己的Meta-data。这里用long型来表示有多少个Meta-data数据对，也是让用户在实际应用中可以定义足够的Meta-data信息。对于每对Meta-data信息，都有一个string型的key(需要以“avro.”为前缀)和二进制编码后的value。对于文件中头信息之后的每个数据块，有这样的结构：一个long值记录当前块有多少个对象，一个long值用于记录当前块经过压缩后的字节数，真正的序列化对象和16字节长度的同步标记符。由于对象可以组织成不同的块，使用时就可以不经过反序列化而对某个数据块进行操作。还可以由数据块数，对象数和同步标记符来定位损坏的块以确保数据完整性。
上面是将Avro对象序列化到文件的操作。与之相应的，Avro也被作为一种RPC框架来使用。客户端希望同服务器端交互时，就需要交换双方通信的协议，它类似于模式，需要双方来定义，在Avro中被称为消息(Message)。通信双方都必须保持这种协议，以便于解析从对方发送过来的数据，这也就是传说中的握手阶段。
消息从客户端发送到服务器端需要经过传输层(Transport Layer)，它发送消息并接收服务器端的响应。到达传输层的数据就是二进制数据。通常以HTTP作为传输模型，数据以POST方式发送到对方去。在Avro中，它的消息被封装成为一组缓冲区(Buffer)，类似于下图的模型： [图片上传中。。。（2）] 如上图，每个缓冲区以四个字节开头，中间是多个字节的缓冲数据，最后以一个空缓冲区结尾。这种机制的好处在于，发送端在发送数据时可以很方便地组装不同数据源的数据，接收方也可以将数据存入不同的存储区。还有，当往缓冲区中写数据时，大对象可以独占一个缓冲区，而不是与其它小对象混合存放，便于接收方方便地读取大对象。
下面聊下Avro的其它方面信息。前文中引述Doug Cutting的话说，Protocol Buffer在传输数据时，往数据中加入注释(annotation)，以应对数据结构与数据不匹配的问题。但直接导致数据量变大，解析困难等缺点。那Avro是如何应对模式与数据的不同呢?为了保证Avro的高效，假定模式至少大部分是匹配的，然后定义一些验证规则，如果在规则满足的前提下，做数据验证。如果模式不匹配就会报错。相同模式，交互数据时，如果数据中缺少某个域(field)，用规范中的默认值设置；如果数据中多了些与模式不匹配的数据。则忽视这些值。
Avro列出的优点中还有一项是：可排序的。就是说，一种语言支持的Avro程序在序列化数据后，可由其它语言的Avro程序对未反序列化的数据排序。我不知道这种机制是在什么样的场景下使用，但看起来还是挺不错的。
当前关于Avro的资料挺少的，上面的文章也是我由官方文档和作者的文章来总结的。我相信其中肯定有很多错误，或许有些方面根本就理解错了。现在放出这篇总结，便于不断修订和补充，也是对这两天学习成果的分享，希望对想了解Avro的人有些许帮助，更希望大家指证我理解错误的地方，利于提高。
其它资料:
* Avro规范:http://avro.apache.org/docs/current/spec.html
http://avro.apache.org/docs/current/spec.html
* Doug Cutting文章:http://www.cloudera.com/blog/2009/11/avro-a-new-format-for-data-interchange/
http://www.cloudera.com/blog/2009/11/avro-a-new-format-for-data-interchange/
* 各序列化系统性能比较:http://wiki.github.com/eishay/jvm-serializers/
http://wiki.github.com/eishay/jvm-serializers/

kafka部分

Broker
Kafka集群包含一个或多个服务器，这种服务器被称为broker
Topic
每条发布到Kafka集群的消息都有一个类别，这个类别被称为topic。（物理上不同topic的消息分开存储，逻辑上一个topic的消息虽然保存于一个或多个broker上但用户只需指定消息的topic即可生产或消费数据而不必关心数据存于何处）
Partition
parition是物理上的概念，每个topic包含一个或多个partition，创建topic时可指定parition数量。每个partition对应于一个文件夹，该文件夹下存储该partition的数据和索引文件
Producer
负责发布消息到Kafka broker
Consumer
消费消息。每个consumer属于一个特定的consumer group（可为每个consumer指定group name，若不指定group name则属于默认的group）。使用consumer high level API时，同一topic的一条消息只能被同一个consumer group内的一个consumer消费，但多个consumer group可同时消费这一消息。

使用librdkafka开发一个producer的步骤：
librdkafka:
1. conf 设置
kafka conf:
rd_kafka_conf_new(): rd_kafka_conf_set()
topic conf:
rd_kafka_topic_conf_new(): rd_kafka_topic_conf_set()

  1. 设置conf回调，消息发送成功或者失败都会调用
    rd_kafka_conf_set_dr_cb()
    rd_kafka_conf_set_dr_msg_cb()
  2. 创建kafka
    rd_kafka_new()
    设置系统日志
    rd_kafka_set_logger()
    rd_kafka_set_log_level()
    添加下游brokers:
    rd_kafka_brokers_add()
  3. 创建新的topic
    rd_kafka_topic_new()
  4. producer:
    rd_kafka_produce()
    发送后，设置时间观察，第二个参数是阻塞等待时间，一般设置为0，rd_kafka_poll()
  5. 销毁操作
    rd_kafka_topic_destroy()
    rd_kafka_destroy()
    rd_kafka_wait_destroyed(2000)

一些数据结构的解释

  • Brokers
    librdkafka 只需要一份最初的brokers列表（至少包含一个broker）。它将连接所有”metadata.broker.list”或者是rd_kafka_brokers_add()函数添加的brokers，然后向每个brokers申请一些元数据信息：包含brokers的完整列表、topic、partitions以及它们在Kafka 集群中的leaders broker信息。

Brokers名字的形式为：host：port； 其中port是可选的，默认是9092，host是任何一个可以解析的hostname或者ipv4或者ipv6地址。如果host是多个地址，librdkafka将会在每一次连接尝试中循环连接这些地址。包含所有broker 地址的DNS记录可以用来提供可靠的bootstrap broker。

  • rd_kafka_t
    实际应用中，需要创建一个top-level的对象 rd_kafka_t， 这个对象是基本的容器，它提供了全局性配置属性以及共享状态信息，它由rd_kafka_new()函数创建。
  • rd_kafka_topic_t
    同时也需要创建一个或者多个topics对象rd_kafka_topic_t，给produer以及consumer使用。 topic对象具有topic特定的配置属性，同时还包含了所有可用partitions与leader brokers映射关系。它通过调用rd_kafka_topic_new()函数创建。
    注意：实际应用中，可能会创建多个rd_kafka_t对象，它们并没有共享状态信息
    注意：rd_kafka_topic_t对象只能由创建它的对象rd_kafka_t使用。
  • 线程和回调函数
    librdkafka 内部将会有多个线程，以充分利用硬件资源。API的实现是完全线程安全的，实际应用中可以在任何时候任何线程中调用任何API函数而不用担心线程安全。
    一个以轮询为基础的API用来给实际应用提供信号反馈，实际应用应当按照固定时间间隔调用rd_kafka_poll()函数。这个轮询的API将会调用以下可的回调（都是可选的）：
    消息发送报告回调：报告消息发送失败。这将允许实际应用采取措施应对发送失败，并释放消息发送过程中占有的资源。
    错误回调：报告错误；错误一般是信息化方面的，例如连接broker失败，实际应用通常不需要采取任何措施。错误的数据类型是通过rd_kafka_resp_err_t enum类型数据，可以描述本地错误和远程broker错误。
    不是poll函数引起的可选回调函数，可能是由任意线程引发的：
    logging 回调：实际应用中，用于发送librdkafka产生的log消息。
    partitioner 回调：实际应用提供消息的partitioner。partitioner可能被任何线程任何时候调用，它可能由于同一个key而被调用多次。Partitioner 函数有以下限制：
    一定不能调用rd_kafka_*()等函数
    一定不能阻塞或延长执行
    一定要返回一个0到partition_cnt-1之间的值，或者是在partitioning不能执行的时候返回特定RD_KAFKA_PARTITION_UA值。
    -rd_kafka_message_t对象成员：
    err：错误返回值。非0值表示出现错误，err是rd_kafka_resp_err_t类型数据。如果是0则表示进行了适当的消息抓取，并且payload中包含了message。
    rkt，partition：topic和partition信息
    payload，len：消息的payload数据或者错误的消息（err！=0）
    key，key_len：可选参数，主要是用来获取特定的消息。
    offset：消息的偏移地址

一些函数

* rd_kafka_consume_start()函数的参数：

rkt： 进行consume的topic， 由前面rd_kafka_topic_new()创建

partition：进行consume的partition

offset：开始consume的消息偏移。这个偏移可能是一个绝对消息偏移，或者是RD_KAKFA_OFFSET_STORED来使用存储的offset，也可能是两个特定偏移之一：RD_KAFKA_OFFSET_BEGINNING，从partition消息队列的开始进行consume；RD_KAFKA_OFFSET_END：从partition中的将要produce的下一条信息开始（忽略即当前所有的消息）。


在topic+partition的consumer启动之后，librdkafka将尝试使本地消息队列中的消息数目保持在queued.min.messages，一方反复的从broker获取消息。


本地消息队列将通过以下三种不同的consum  APIs进行consume：

rd_kafka_consume()：每次consume一条消息

rd_kafka_consume_batch()：批处理consume，一条或多条

rd_kafka_consume_callback()：consume本地消息队列中的所有消息，并调用回调函数处理每条消息


上述三种方式按照性能排列的，rd_kafka_consume()是最慢的，rd_kafka_consume_callback()最快。不同的需求可以选择不同的实现方式。


一条consumed消息，由每一个consume函数提供或返回，具体是由rd_kafka_messag_t类型对象保存。</big>

sparkstreaming 部分

librdkafka升级_序列化