Hadoop发行版(2015第二季)

自从Hadoop的出现,引领大数据的浪潮越来越热。大数据存储的主要技术路线有几种:
1.Hadoop
2.Cassandra
3.MongoDB
Hadoop是Apache的开源项目,同时有很多商业公司对Hadoop进行版本发行和商业支持,参见:http://wiki.apache.org/hadoop/Distributions%20and%20Commercial%20Support
其中在最有名为人所知的三家:
1.Cloudera
这是一张图片
2.Hortonwork
这是一张图片
3.MapR
这是一张图片
这三个厂商之中,MapR最为封闭;Hortonworks最为开放,产品线全开源,在线文档比较丰富。国内使用Cloudera CDH和Hortonworks的应该是最多的。
国内市场当前有两家也非常有竞争力,一家是Huawei,一家是星环科技。
4.Huawei FusionInsight
这是一张图片
5.星环科技TDH,TDH对Spark的支持据说非常不错的,有良好的性能表现。
这是一张图片
准实时计算框架/即席查询
1.CDH的框架有:Impala + Spark;
2.HDP的框架有:Tez + Spark;
3.MapR的框架有:Drill + Tez + Spark。
关于Spark:
2014年大数据最热门的技术路线就是算是Spark了,而且得力于Spark不遗余力的推广和快速成长。Cloudera是最早支持Spark,也是最激进的。下图即是Spark在Cloudera产品线中的定位:
这是一张图片
实际上基于Hadoop的快速计算框架的发展才刚刚开始,社区中已经有如下几种:
1.Spark/Shark
2.Hortonworks Tez/Stinger
3.Cloudera Impala
4.Apache Drill
5.Apache Flink
6.Apache Nifi
7.Facebook Presto

SQL on Hadoop
SQL on Hadoop的发展主要是传统的SQL过于强大,人才库非常庞大,从Hadoop出现的第一天就在SQL发力。当前技术路线上更是百花齐放,这里从开源和商业产品来说。
Open Source

1. Apache Hive(Hive on MR)
2. Hortonworks Tez/Stinger(Hive on Tez)
3. Cloudera Impala
4. Shark
5. Spark SQL
6. Apache Drill - MapR
7. Facebook Presto
8. Apache Phoenix(on HBase) - Saleforce
9. Apache Kylin
10. Apache Tajo - (Database Lab, Korea University)
11. Cascading Lingual - (Cascading, Optiq)
12. Dato (GraphLab) - Dato

Commercial

1. EMC HAWQ
2. IBM BigSQL
3. TERADATA SQL-H
4. Hadapt/HadoopDB
5. Transwarp Inceptor

在开源领域里面,当前比受追捧的主要是:Hive、Impala、Spark、Phoenix。

参考:
SQL on Hadoop开源项目总结
http://segmentfault.com/a/1190000002799235
如何选择满足需求的SQL on Hadoop系统
http://www.searchbi.com.cn/showcontent_89816.htm
2015Hadoop技术峰会演讲速记3: 基于Transwarp Stream和Discover的实时大数据人流密度估计
http://www.transwarp.cn/news/detail?id=70

学习《七牛是如何搞定每天500亿条日志的》

七牛是如何搞定每天500亿条日志的 http://www.csdn.net/article/2015-07-30/2825342

日志处理的大致分为三步:

1. 日志采集,主要是通过Agent和Flume;
2. 日志流转,主要是通过Kafka;
3. 日志计算,主要是通过Spark Streaming作为计算引擎;

大致的处理流程:

1. Agent/Local Kafka -> Flume -> Kafka -> HDFS -> mongoDB
2. Agent/Local Kafka -> Flume -> Kafka -> Spark -> mongoDB
3. Agent/Local Kafka -> Flume -> Kafka -> Spark -> opentsdb 

流程3只是见于图上,文字上没有任何提到。
在日志采集中,通过Agent将业务应用和日志采集进行了分离,采取了Agent主动来拉的模式。专门强调了Agent 的设计需求:

1
2
每台机器上会有一个Agent去同步这些日志,这是个典型的队列模型,业务进程在不断的push,Agent在不停的pop。Agent需要有记忆功能,用来保存同步的位置(offset),这样才尽可能保证数据准确性,但不可能做到完全准确。由于发送数据和保存offset是两个动作,不具有事务性,不可避免的会出现数据不一致性情况,通常是发送成功后保存offset,那么在Agent异常退出或机器断电时可能会造成多余的数据。
在这里,Agent需要足够轻,这主要体现在运维和逻辑两个方面。Agent在每台机器上都会部署,运维成本、接入成本是需要考虑的。Agent不应该有解析日志、过滤、统计等动作,这些逻辑应该给数据消费者。倘若Agent有较多的逻辑,那它是不可完成的,不可避免的经常会有升级变更动作。

为什么Agent没有直接将日志发送给Kafka,而是通过Flume来做:

1
2
3
具体架构上,Agent并没把数据直接发送到Kafka,在Kafka前面有层由Flume构成的forward。这样做有两个原因:
1. Kafka的API对非JVM系的语言支持很不友好,forward对外提供更加通用的http接口。
2. forward层可以做路由、Kafka topic和Kafka partition key等逻辑,进一步减少Agent端的逻辑。

Kafka使用建议
1.Topic划分。尽量通过划分Topic分离不同类型的数据;
2.Kafka partition数目直接关系整体的吞吐量。3个Partition能够跑满一块磁盘的IO。
3.Partition key设计。partition key选择不当,可能会造成数据倾斜。在对数据有顺序性要求才需使用partition key。Kafka的producer sdk在没指定partition key时,在一定时间内只会往一个partition写数据,这种情况下当producer数少于partition数也会造成数据倾斜,可以提高producer数目来解决这个问题。
实时计算Spark Streaming
1.当前Spark只用作统计,没有进行迭代计算(DAG)。场景比较简单。
2.Spark Streaming从Kafka中读数据,统计完结果如mongoDB。可以理解是Spark Streaming + mongoDB的应用。
3.Spark Streaming对存储计算结果的数据库tps要求较高。比如有10万个域名需要统计流量,batch interval为10s,每个域名有4个相关统计项,算下来平均是4万 tps,考虑到峰值可能更高,固态硬盘上的mongo也只能抗1万tps,后续我们会考虑用redis来抗这么高的tps。难道Redis能够支持很高的TPS?
4.有状态的Task的挑战:有外部状态的task逻辑上不可重入的,当开启speculation参数时候,可能会造成计算的结果不准确。说个简单的例子。这个任务,如果被重做了,会造成落入mongo的结果比实际多。有状态的对象生命周期不好管理,这种对象不可能做到每个task都去new一个。我们的策略是一个JVM内一个对象,同时在代码层面做好并发控制。
七牛数据平台规模

1
线上的规模:Flume + Kafka + Spark8台高配机器,日均500亿条数据,峰值80万tps。

因此,
1.如果是Flume/Kafka/Spark共享同一个物理集群,硬件压力如何?
2.如果每条日志 0.1K,那么每天总数据量 50G 0.1K = 5T,每个节点每秒 5T/243600/8 = 7.23M。

参考:
【微信分享】王团结:七牛是如何搞定每天500亿条日志的
http://www.csdn.net/article/2015-07-30/2825342
对七牛云存储日志处理的思考
http://hadoop1989.com/2015/08/02/Think-QiNiu-Cloud/

学习《腾讯在Spark上的应用与实践优化》

《腾讯在Spark上的应用与实践优化》原文参见:http://download.csdn.net/detail/happytofly/8637461

TDW: Tencent Distributed Data Warehouse,腾讯分布式数据仓库;
GAIA:腾讯自研的基于YARN定制化和优化的资源管理系统;
Lhoste:腾讯自研的作业的工作流调度系统,类似于Oozie;

TDW集群规模:

1. Gaia集群节点数:8000+;
2. HDFS的存储空间:150PB+;
3. 每天新增数据:1PB+;
4. 每天任务数:1M+;
5. 每天计算量:10PB+;

Spark集群:

1. Spark部署在Gaia之上,即是Spark on YARN模式,每个节点是 24 cores 和 60G 内存;
2. 底层存储包括:HDFS、HBase、Hive、MySQL;
3. 作业类型,包括:ETL、SparkSQL、Machine Learning、Graph Compute、Streaming;
4. 每天任务数,10K+;
5. 腾讯从2013年开始引入Spark 0.6,已经使用2年了;

Spark的典型应用:

1. 预测用户的广告点击概率;
2. 计算两个好友间的共同好友数;
3. 用于ETL的SparkSQL和DAG任务;

Case 1: 预测用户的广告点击概率

1. 数据是通过DCT(Data Collect Tool)推送到HDFS上,然后Spark直接将HDFS数据导入到 RDD&Cache;
2. 60次迭代计算的时间为1015分钟,即每次迭代1015秒;

Case 2: 计算两个好友间的共同好友数

1. 根据shuffle数量来确定partition数量;
2. 尽量使用sort-based shuffle,减少reduce的内存使用;
3. 当连接超时后选择重试来减少executor丢失的概率;
4. 避免executor被YARN给kill掉,设置 spark.yarn.executor.memoryoverhead
5. 执行语句 INSERT TABLE test_result SELECT t3.d, COUNT(*) FROM( SELECT DISTINCT a, b FROM join_1 ) t1 JOINSELECT DISTINCT b, c FROM join_2 ) t2 ON (t1.a = t2.c) JOIN (SELECT DISTINCT c, d FROM c, d FROM join_3 ) t3 ON (t2.b = t3.d) GROUP BY t3.d 使用Hive需要30分钟,使用SparkSQL需要5分钟;
6. 当有小表时使用broadcase join代替Common join7. 尽量使用ReduceByKey代替GroupByKey;
8. 设置spark.serializer = org.apache.spark.serializer.KryoSerializer;
9. 使用YARN时,设置spark.shuffle.service.enabled = true10. 在早期版本中Spark通过启动参数固定executor的数量,当前支持动态资源扩缩容特性

    * spark.dynamicAllocation.enabled = true
    * spark.dynamicAllocation.executorIdleTimeout = 120
    * spark.dynamicAllocation.schedulerBacklogTimeout = 10
    * spark.dynamicAllocation.minExecutors/maxExecutors

11. 当申请固定的executors时且task数大于executor数时,存在着资源的空闲状态。


<完>

13~14年收集的大数据的一些技术架构图

1 Big Data Solution

1.1 HP


1.2 Oracle


1.3 IBM

1.4 Microsoft

1.5 Huawei



2 Big Data on Cloud

2.1 Amazon AWS

2.1.1 Netflix BigData on AWS

2.2 Microsoft Azure

2.3 Facebook

2.4 Linkedin

2.5 Twitter

2.6 Alibaba/Taobao

2.6.1 淘宝数据魔方

2.6.2 阿里大数据应用平台

2.6.3 阿里搜索实时流计算

2.7 Tencent

2.7.1 腾讯大规模Hadoop集群TDW

2.7.2 腾讯实时计算平台 广点通

2.8 JD(京东)

2.9 CMCC(中国移动)

2.9.1 大云PaaS 2.5

3 Hadoop Distribution

3.1 Apache Hadoop

3.2 Cloudera

3.3 Hortonworks

3.4 MapR

3.5 Intel

3.6 EMC Pivotal HD

3.7 IBM

3.8 Huawei

4 Landscape



5 参考

读《微软研发制胜策略》

软件开发的核心就是:达成项目目标,提高生产率,提高软件的质量。除此之外,都不要重要。
管理上、复用上,一切的核心就是人的问题,提高人的能力是第一生产力。

1.项目中一个现象就是紧紧的去控制进度,调整进度,进度的跟踪只是一种日常的事务工作。
2.观念的改变是第一位的,什么是观念改变的原则:规则不是法律,是可以触碰的。什么是我们要改变的规则,就是要有主动、计划、灵活。
3.紧密的进度计划,是一般的管理人员的通常做法,他的好处就是看到不断的工作,会有不断的压力;如果运用不当,就可能让人觉得厌烦和沮丧。
4.为了日程进度,牺牲质量往往是不值得的,除非你要一笑而过的做法。再不管这个项目的后续开发和维护了。对于产品或者项目的期限,要谨慎,要反思可能为了进度而牺牲质量。这叫着草率的期限。
5.一个好的日程表会兼顾公司和员工的利益的。
6.没有期限的目标不过是梦想而已。
7.把一个大项目,切分成n个小项目来做,每一个项目的周期大约是2个月。叫着阶段式的日程控制法。

大数据动态之201507

Hortonworks
HDP 2.3发布:
HDP 2.3新增加组件Apache Atlas、Apache Calcite
http://hortonworks.com/blog/available-now-hdp-2-3/
http://hortonworks.com/blog/introducing-availability-of-hdp-2-3-part-2/
http://hortonworks.com/blog/introducing-availability-of-hdp-2-3-part-3/
Spark 1.2开始支持ORC(Columnar Formats)
http://hortonworks.com/blog/bringing-orc-support-into-apache-spark/
Spark in HDInsight新特性一览
http://hortonworks.com/blog/spark-in-hdinsight/

Cloudera
HBase 1.0 开始支持Thrift客户端鉴权
http://blog.cloudera.com/blog/2015/07/thrift-client-authentication-support-in-apache-hbase-1-0/
Pig on MR优化
http://blog.cloudera.com/blog/2015/07/how-to-tune-mapreduce-parallelism-in-apache-pig-jobs/
Apache Zeppelin on CDH
http://blog.cloudera.com/blog/2015/07/how-to-install-apache-zeppelin-on-cdh/
大数据欺诈检测架构
http://blog.cloudera.com/blog/2015/07/designing-fraud-detection-architecture-that-works-like-your-brain-does/

MapR
YARN资源管理实践
https://www.mapr.com/blog/best-practices-yarn-resource-management
Hive 1.0对Transaction的支持
https://www.mapr.com/blog/hive-transaction-feature-hive-10

Databricks
Spark Streaming执行模型
https://databricks.com/blog/2015/07/30/diving-into-spark-streamings-execution-model.html
Spark 1.4 MLP新特性
https://databricks.com/blog/2015/07/29/new-features-in-machine-learning-pipelines-in-spark-1-4.html
从Spark 1.2开始支持ORC
https://databricks.com/blog/2015/07/16/joint-blog-post-bringing-orc-support-into-apache-spark.html
从Spark 1.4开始支持窗口函数
https://databricks.com/blog/2015/07/15/introducing-window-functions-in-spark-sql.html
从Spark 1.4开始新的Web UI
https://databricks.com/blog/2015/07/08/new-visualizations-for-understanding-spark-streaming-applications.html

Phoenix对join的支持,TPC in Apache Phoenix
https://blogs.apache.org/phoenix/entry/tpc_in_apache_phoenix

Cassandra
http://cassandra.apache.org/

mongoDB
https://www.mongodb.org/

Confluent
基于Kafka的实时流处理
http://www.confluent.io/
大数据生态系统之Kafka价值
http://www.confluent.io/blog/the-value-of-apache-kafka-in-big-data-ecosystem/

使用Hexo搭建Github静态博客

环境:

1. Windows XP
2. Git

步骤:

1. 安装Node.js
2. 安装Hexo
3. 创建博客(初始化Hexo)
4. 创建文章本地调试
5. 配置Github
6. 远程发布
7. 支持sitemap和feed
8. 支持百度统计
9. 支持图片
10. 支持Swiftype站内搜索
11. 参考资源

安装Node.js

下载并安装,https://nodejs.org/

安装Hexo

通过命令 npm install -g hexo 安装

D:\git\hexo>npm install -g hexo

npm WARN optional dep failed, continuing fsevents@0.3.6
npm WARN optional dep failed, continuing fsevents@0.3.6
-


> dtrace-provider@0.5.0 install C:\Users\stevenxu\AppData\Roaming\npm\node_modules\hexo\node_modules\bunyan\node_modules\dtrace-provider
> node scripts/install.js

C:\Users\stevenxu\AppData\Roaming\npm\hexo -> C:\Users\stevenxu\AppData\Roaming\npm\node_modules\hexo\bin\hexo
hexo@3.1.1 C:\Users\stevenxu\AppData\Roaming\npm\node_modules\hexo
├── pretty-hrtime@1.0.0
├── hexo-front-matter@0.2.2
├── abbrev@1.0.7
├── titlecase@1.0.2
├── archy@1.0.0
├── text-table@0.2.0
├── tildify@1.1.0 (os-homedir@1.0.1)
├── strip-indent@1.0.1 (get-stdin@4.0.1)
├── hexo-i18n@0.2.1 (sprintf-js@1.0.3)
├── chalk@1.1.0 (escape-string-regexp@1.0.3, supports-color@2.0.0, ansi-styles@2.1.0, strip-ansi@3.0.0, has-ansi@2.0.0)
├── bluebird@2.9.34
├── minimatch@2.0.10 (brace-expansion@1.1.0)
├── through2@1.1.1 (xtend@4.0.0, readable-stream@1.1.13)
├── swig-extras@0.0.1 (markdown@0.5.0)
├── hexo-fs@0.1.3 (escape-string-regexp@1.0.3, graceful-fs@3.0.8, chokidar@0.12.6)
├── js-yaml@3.3.1 (esprima@2.2.0, argparse@1.0.2)
├── nunjucks@1.3.4 (optimist@0.6.1, chokidar@0.12.6)
├── warehouse@1.0.2 (graceful-fs@3.0.8, cuid@1.2.5, JSONStream@0.10.0)
├── cheerio@0.19.0 (entities@1.1.1, dom-serializer@0.1.0, css-select@1.0.0, htmlparser2@3.8.3)
├── bunyan@1.4.0 (safe-json-stringify@1.0.3, dtrace-provider@0.5.0, mv@2.1.1)

├── hexo-cli@0.1.7 (minimist@1.1.2)
├── moment-timezone@0.3.1
├── moment@2.10.3
├── hexo-util@0.1.7 (ent@2.2.0, highlight.js@8.6.0)
├── swig@1.4.2 (optimist@0.6.1, uglify-js@2.4.24)
└── lodash@3.10.0

D:\git\hexo>

创建博客(初始化hexo)

创建博客站点的本地目录,然后在文件夹下执行命令:

$ hexo init

[info] Copying data
[info] You are almost done! Don’t forget to run npm install before you start b
logging with Hexo!

Hexo会自动在目标文件夹下建立网站所需要的文件。然后按照提示,安装node_modules,执行如下命令:

$ hexo install

创建文章本地调试

预览本地调试模式,执行如下命令:

$ hexo server

[info] Hexo is running at http://localhost:4000/. Press Ctrl+C to stop.

关键命令简介:

hexo n     #创建新的文章
hexo g     #重新生成站点
hexo s     #启动本地服务
hexo d     #发布到github

创建文章

$ hexo new "使用Hexo搭建Github静态博客" 

在Hexo工作文件夹下source_posts发现新创建的md文件 使用Hexo搭建Github静态博客.md 。

配置Github

部署到Github需要修改配置文件_config.yml文件,在Hexo工作目录之下:

# Deployment
## Docs: http://hexo.io/docs/deployment.html

deploy:
    type: git
    repository: git@github.com:<Your Github Username>/<Your github.io url>
    branch: master

注意,当前type为git,而不是github

测试Github是否好用

ssh -T git@github.com

远程发布

远程部署到Github,通过执行如下命令:

$ hexi deploy

Troubleshooting
出现错误:Error: spawn git ENOENT
解决方案:
http://blog.csdn.net/rainloving/article/details/46595559

使用github出现:fatal: unable to access: Failed connect to github.com:8080: No error
解决方案:
http://www.zhihu.com/question/26954892

使用github出现:ssh:connect to host github.com port 22: Bad file number
解决方案:
http://www.xnbing.org/?p=759
http://blog.csdn.net/temotemo/article/details/7641883

支持sitemap和feed

首先安装sitemap和feed插件

$ npm install hexo-generator-sitemap
$ npm install hexo-generator-feed

修改配置,在文件 _config.yml 增加以下内容

# Extensions
Plugins:
- hexo-generator-feed
- hexo-generator-sitemap

#Feed Atom
feed:
    type: atom
    path: atom.xml
    limit: 20

#sitemap
sitemap:
    path: sitemap.xml

在 themes\landscape_config.yml 中添加:

menu:
    Home: /
    Archives: /archives
    Sitemap: /sitemap.xml
rss: /atom.xml

支持百度统计

http://tongji.baidu.com 注册帐号,添加网站,生成统计功能的 JS 代码。

在 themes\landscape_config.yml 中新添加一行:

baidu_tongji: true

在 themes\landscape\layout_partial\head.ejs 中head的结束标签 之前新添加一行代码

<%- partial('baidu_tongji') %>

在 themes\landscape\layout_partial 中新创建一个文件 baidu_tongji.ejs 并添加如下内容:

<% if (theme.baidu_tongji){ %>
<script type="text/javascript">
    <百度统计的 JS 代码>
</script>
<% } %>

添加统计,参考:
http://ibruce.info/2013/11/22/hexo-your-blog/
http://www.cnblogs.com/zhcncn/p/4097881.html

支持图片

在source目录下创建images目录,然后将图片放在其中。
在文章中引用本地图片的语法例如:

![这是一张图片](/images/2005_TuoZhanXunLian.jpg)

支持swiftype站内搜索

http://siftype.com 注册一个帐号,按着网站引导流程就可以了。
安装 install code 代码到hexo,添加到 themes\landscape\layout_partial\after-footer.ejs,类似添加百度统计的代码。
然后回到swiftype网站对 install code 进行确认。通过会在下方弹出一条消息:

Installation successfully activated

添加robots.txt

http://blog.lmintlcx.com/post/blog-with-hexo.html

支持多说评论

首先,在多说官网 http://www.duoshuo.com 激活账户,并添加网站配置;
其次,参考多说官网的Hexo配置指南进行配置,http://dev.duoshuo.com/threads/541d3b2b40b5abcd2e4df0e9
针对landscap theme就是两步:
第一步在Hexo根目录下的配置文件 _config.yml 中添加多说配置项

duoshuo_shortname: 你站点的short_name

第二步修改themes\landscape\layout_partial\article.ejs模板,用多说推荐的代码替换之前的Disqus代码。

1
2
3
4
5
6
7
<% if (!index && post.comments && config.disqus_shortname){ %>
<section id="comments">
<div id="disqus_thread">
<noscript>Please enable JavaScript to view the <a href="//disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript>
</div>
</section>
<% } %>

改为

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<% if (!index && post.comments && config.duoshuo_shortname){ %>
<section id="comments">
<!-- 多说评论框 start -->
<div class="ds-thread" data-thread-key="<%= post.layout %>-<%= post.slug %>" data-title="<%= post.title %>" data-url="<%= page.permalink %>"></div>
<!-- 多说评论框 end -->
<!-- 多说公共JS代码 start (一个网页只需插入一次) -->
<script type="text/javascript">
var duoshuoQuery = {short_name:'<%= config.duoshuo_shortname %>'};
(function() {
var ds = document.createElement('script');
ds.type = 'text/javascript';ds.async = true;
ds.src = (document.location.protocol == 'https:' ? 'https:' : 'http:') + '//static.duoshuo.com/embed.js';
ds.charset = 'UTF-8';
(document.getElementsByTagName('head')[0]
|| document.getElementsByTagName('body')[0]).appendChild(ds);
})();
</script>

<!-- 多说公共JS代码 end -->
</section>
<% } %>

参考资源

http://blog.lmintlcx.com/post/blog-with-hexo.html
https://github.com/bruce-sha
http://zipperary.com/2013/05/28/hexo-guide-2/
http://zipperary.com/2013/05/29/hexo-guide-3/
http://zipperary.com/2013/05/30/hexo-guide-4/
http://cnfeat.com/2014/05/10/2014-05-11-how-to-build-a-blog/
http://www.cnblogs.com/zhcncn/p/4097881.html
http://blog.moyizhou.cn/web/search-engine-for-static-pages/
http://www.jerryfu.net/post/search-engine-for-hexo-with-swiftype.html

Hadoop 2.7.1 发布

2015年7月6日,Apache Hadoop的稳定版本 2.7.1 正式发布。
http://hadoop.apache.org/releases.html#Release+Notes

Hadoop 2.7的一个小版本发布了,本版本属于稳定版本。
修复了2.7.0中存在的131个bug。
这是2.7.x第一个稳定版本,增强的功能列表请通过2.7.0版本部分查看。
按着计划,下一个2.7.x的小版本是2.7.2.

原文:
06 July, 2015: Release 2.7.1 (stable) availableA point release for the 2.7 line. This release is now considered stable.
Please see the Hadoop 2.7.1 Release Notes for the list of 131 bug fixes and patches since the previous release 2.7.0. Please look at the 2.7.0 section below for the list of enhancements enabled by this first stable release of 2.7.x.

读《Deploying Apache Kafka: A Practical FAQ》

Cloudera发布了Kafka的好文,《Deploying Apache Kafka: A Practical FAQ》,参见:http://blog.cloudera.com/blog/2015/07/deploying-apache-kafka-a-practical-faq

是否应当为Kafka Broker使用 固态硬盘 (SSD)
实际上使用SSD盘并不能显著地改善 Kafka 的性能,主要有两个原因:

* Kafka写磁盘是异步的,不是同步的。就是说,除了启动、停止之外,Kafka的任何操作都不会去等待磁盘同步(sync)完成;而磁盘同步(disk syncs)总是在后台完成的。这就是为什么Kafka消息至少复制到三个副本是至关重要的,因为一旦单个副本崩溃,这个副本就会丢失数据无法同步写到磁盘。
* 每一个Kafka Partition被存储为一个串行的WAL(Write Ahead Log)日志文件。因此,除了极少数的数据查询,Kafka中的磁盘读写都是串行的。现代的操作系统已经对串行读写做了大量的优化工作。

如何对Kafka Broker上持久化的数据进行加密
目前,Kafka不提供任何机制对Broker上持久化的数据进行加密。用户可以自己对写入到Kafka的数据进行加密,即是,生产者(Producers)在写Kafka之前加密数据,消费者(Consumers)能解密收到的消息。这就要求生产者(Producers)把加密协议(protocols)和密钥(keys)分享给消费者(Consumers)。
另外一种选择,就是使用软件提供的文件系统级别的加密,例如Cloudera Navigator Encrypt。Cloudera Navigator Encrypt是Cloudera企业版(Cloudera Enterprise)的一部分,在应用程序和文件系统之间提供了一个透明的加密层。
Apache Zookeeper正成为Kafka集群的一个痛点(pain point),真的吗?
Kafka高级消费者(high-level consumer)的早期版本(0.8.1或更早)使用Zookeeper来维护读的偏移量(offsets,主要是Topic的每个Partition的读偏移量)。如果有大量生产者(consumers)同时从Kafka中读数据,对Kafka的读写负载可能就会超出它的容量,Zookeeper就变成一个瓶颈(bottleneck)。当然,这仅仅出现在一些很极端的案例中(extreme cases),即有成百上千个消费者(consumers)在使用同一个Zookeeper集群来管理偏移量(offset)。
不过,这个问题已经在Kafka当前的版本(0.8.2)中解决。从版本0.8.2开始,高级消费者(high-level consumer)能够使用Kafka自己来管理偏移量(offsets)。本质上讲,它使用一个单独的Kafka Topic来管理最近的读偏移量(read offsets),因此偏移量管理(offset management)不再要求Zookeeper必须存在。然后,用户将不得不面临选择是用Kafka还是Zookeeper来管理偏移量(offsets),由消费者(consumer)配置参数 offsets.storage 决定。
Cloudera强烈推荐使用Kafka来存储偏移量。当然,为了保证向后兼容性,你可以继续选择使用Zookeeper存储偏移量。(例如,你可能有一个监控平台需要从Zookeeper中读取偏移量信息。) 假如你不得不使用Zookeeper进行偏移量(offset)管理,我们推荐你为Kafka集群使用一个专用的Zookeeper集群。假如一个专用的Zookeeper集群仍然有性能瓶颈,你依然可以通过在Zookeeper节点上使用固态硬盘(SSD)来解决问题。
Kafka是否支持跨数据中心的可用性
Kafka跨数据中心可用性的推荐解决方案是使用MirrorMaker(https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=27846330 ) 。在你的每一个数据中心都搭建一个Kafka集群,在Kafka集群之间使用MirrorMaker来完成近实时的数据复制。
使用MirrorMaker的架构模式是为每一个”逻辑”的topic在每一个数据中心创建一个topic:例如,在逻辑上你有一个”clicks”的topic,那么你实际上有”DC1.clicks”和“DC2.clicks”两个topic(DC1和DC2指得是你的数据中心)。DC1向DC1.clicks中写数据,DC2向DC2.clicks中写数据。MirrorMaker将复制所有的DC1 topics到DC2,并且复制所有的DC2 topics到DC1。现在每个DC上的应用程序都能够访问写入到两个DC的事件。这个应用程序能够合并信息和处理相应的冲突。
另一种更复杂的模式是在每一个DC都搭建本地和聚合Kafka集群。这个模式已经被Linkedin使用,Linkedin Kafka运维团队已经在这篇Blog(https://engineering.linkedin.com/kafka/running-kafka-scale )中有详细的描述(参见“Tiers and Aggregation”)。
Kafka支持哪些类型的数据转换(data transformation)
数据流过的Kafka的时候,Kafka并不能进行数据转换。为了处理数据转换,我们推荐如下方法:

* 对于简单事件处理,使用Flume Kafka integration(http://blog.cloudera.com/blog/2014/11/flafka-apache-flume-meets-apache-kafka-for-event-processing ),并且写一个简单的Apache Flume Interceptor。
* 对于复杂(事件)处理,使用Apache Spark Streaming从Kafka中读数据和处理数据。

在这两种情况下,被转换或者处理的数据可被写会到新的Kafka Topic中,或者直接传送到数据的最终消费者(Consumer)那里。
对于实时事件处理模式更全面的描述,看看这篇文章(http://blog.cloudera.com/blog/2015/06/architectural-patterns-for-near-real-time-data-processing-with-apache-hadoop/ )。
如何通过Kafka发送大消息或者超大负荷量?
Cloudera的性能测试表明Kafka达到最大吞吐量的消息大小为10K左右。更大的消息将导致吞吐量下降。然后,在一些情况下,用户需要发送比10K大的多的消息。
如果消息负荷大小是每100s处理MB级别,我们推荐探索以下选择:

* 如果可以使用共享存储(HDFS、S3、NAS),那么将超负载放在共享存储上,仅用Kafka发送负载数据位置的消息。
* 对于大消息,在写入Kafka之前将消息拆分成更小的部分,使用消息Key确保所有的拆分部分都写入到同一个partition中,以便于它们能被同一个消息着(Consumer)消费的到,在消费的时候将拆分部分重新组装成一个大消息。

在通过Kafka发送大消息时,请记住以下几点:
压缩配置

* Kafka生产者(Producers)能够压缩消息。通过配置参数compression.codec确保压缩已经开启。有效的选项为"gzip""snappy"

Broker配置

* message.max.bytes (default: 1000000): Broker能够接受的最大消息。增加这个值以便于匹配你的最大消息。
* log.segment.bytes (default: 1GB): Kafka数据文件的大小。确保它至少大于一条消息。默认情况下已经够用,一般最大的消息不会超过1G大小。
* replica.fetch.max.bytes (default: 1MB): Broker间复制的最大的数据大小。这个值必须大于message.max.bytes,否则一个Broker接受到消息但是会复制失败,从而导致潜在的数据丢失。

Consumer配置

* fetch.message.max.bytes (default: 1MB): Consumer所读消息的最大大小。这个值应该大于或者等于Broker配置的message.max.bytes的值。

其他方面的考虑:

* Broker需要针对复制为每一个partition分配一个replica.fetch.max.bytes大小的缓存区。需要计算确认( partition的数量 * 最大消息的大小 )不会超过可用的内存,否则就会引发OOMs(内存溢出异常)。
* Consumers有同样的问题,因子参数为 fetch.message.max.bytes :确认每一个partition的消费者针对最大的消息有足够可用的内存。
* 大消息可能引发更长时间的垃圾回收停顿(garbage collection pauses)(brokers需要申请更大块的内存)。注意观察GC日志和服务器日志。假如发现长时间的GC停顿导致Kafka丢失了Zookeeper session,你可能需要为zookeeper.session.timeout.ms配置更长的timeout值。

Kafka是否支持MQTT或JMS协议
目前,Kafka针对上述协议不提供直接支持。但是,用户可以自己编写Adaptors从MQTT或者JMS中读取数据,然后写入到Kafka中。

更多关于在CDH中使用Kafka的信息,下载Deployment Guide(http://www.cloudera.com/content/cloudera/en/resources/library/datasheet/kafka-reference-architecture.html ) 或者 观看webinar “Bringing Real-Time Data to Hadoop”(http://www.cloudera.com/content/cloudera/en/resources/library/recordedwebinar/kafka-webinar-recording.html )。