Blogs

http://blog.csdn.net/kangroger：KangRoger的专栏（算法）
http://blog.csdn.net/column/details/12727.html：cs231n学习笔记
http://blog.csdn.net/column/details/13427.html：深度学习算法

http://gems.ruby-china.org：RubyGems 镜像

Hue

是一个开源的Apache Hadoop UI系统

Zeppelin

Spark交互式分析平台

Presto

是一个开源的分布式SQL查询引擎,适用于交互式分析查询,数据量支持GB到PB字节

Oozie

是一个工作流引擎服务器,用于运行Hadoop Map/Reduce和Pig 任务工作流

Hbase配置注意事项

  1. 硬件节点数请选择 4 个及以上，其包含了 Master 和 Slave 节点，E-MapReduce 会在这些节点上创建 namenode、datanode、journalnode、hmaster、regionserver 和 zookeeper 角色。
  2. 服务器配置推荐选择 4 核 16G / 8 核 32G 这两款机型，过低的配置可能导致 HBase 集群无法稳定运行。
  3. 数据盘类型建议选择 SSD 云盘，会有更好的成本性价比。对于访问少，存储量大的业务，可以选择普通云盘。

JStorm性能背后原因

  • Apache Storm, mini-batch 做的不够优秀， 导致效率并不高
  • Apache Flink, mini-batch 做的非常优秀， 但资源利用率没有做上来， 因为单机所有的task都跑在一个进程内， 内存共享很充分，进程内通信也非常优秀，但单机下只在一个进程内部， 无法充分利用cpu 资源。也就是会遇到cpu 使用上限问题
  • Twitter Heron, 存在致命设计缺陷
    Heron 最大的噱头 “10 倍storm性能”， 但heron 对比的对象是storm 0.8.2, 这是3年前的storm，是上一代的storm， 而最新版storm 1.0.2 早已经是storm 0.8.2 的十倍性能。
    heron在性能上存在几个致命缺陷
    失去了整个业界性能优化很大的一个方向， 流计算图优化。其核心思想就是让task尽量绑在一个进程中， 这样task之间的数据，可以直接走进程内通信，无需反序列化和序列化。
    为了提高稳定性， heron将每个task 独立成为一个进程， 则会产生一个新的问题，就是task之间的通信都不会有进程内通信， 所有task通信都是走网络， 都要经过序列化和反序列化， 引入了大量额外的计算.
    如果想要图优化， 则heron必须引入一层新的概念， 将多个task 链接到一个进程中， 但这个设计和heron的架构设计理念会冲突
    每个container 的stream manager 会成为瓶颈， 一个container 内部的所有task 的数据（无论数据对外还是对内）通信都必须经过stream manager， 一个进程他的网络tps是有上限的， 而stream-manager的上限就是50w qps， 则表示一个container的内部通道和外部通道总和就是50w qps. 大家都必须抢这个资源。
    原来的一次网络通信， 现在会变成3次网络通信， task －》 当前container的streammanager －》 目标container的stream manager －》 目标task