小议Storm输出到hdfs的各种方案
2013-05-16 00:50
225 查看
fromWeibo)
1)方案较多,从数据收集角度分为:NFS收集、Scribe/Flume等收集、不收集(多个Bolt并行写入),从数据写入角度分为:分段写入本地文件后Put、Fuse-HDFS写入、dfsCLient写入,收集和写入可以组合为多种方案;显然NFS在收集方面无优势,可以排除;另外Fuse-HDFS方案依赖于osfuse的支持,不适合于数据不收集的情况;剩余的5种组合适合不同的业务场景。
2)收集写入的最大优点是:多个topology多Bolt数据流合并分拆控制灵活,写入客户端部署维护方便;但同时,由于引入了storm控制之外的新的数据处理环节,增加了transactionaltopology控制的复杂度,需要收集系统特别的支持replay,使得该方案并不太适合正确性要求较高的应用,当然对于数据丢失可以容忍的场景该方案是OK的。
3)最后看一下Bolt直接写入的情况,这种方案结构最简单,但所有worker节点都要配置为写入客户端可执行的环境(特别是权限),各个topology的写入无法合并处理。另外dfsClient写入加上缓存优化会比Put方式更易于控制及部署。
4)写入环节需要考虑的包括数据序列化格式、数据分区控制、性能优化(cache)、事务控制(正确性保证)等具体问题,框架性的通用写入模块还需要解决较多系统结构方面的问题,如Kryo序列化框架支持等等。
通用的Bolt直接写入hdfs框架更符合分层规范,除了实现稍微麻烦一些外无明显问题,但在某些特殊的项目中其他方案可能会有更好的表现!
相关文章推荐
- HDU1466 计算直线交点(输出各种交点方案)
- 基于storm的实时数据处理方案
- 系统重启后,需要重新格式化HDFS问题解决方案
- 反垃圾邮件,需要全面了解各种方案
- C语言的各种格式化输出
- 大数据架构:flume-ng+Kafka+Storm+HDFS 实时系统组合
- RecyclerView,ListView,ViewPager 等各种控件复用问题解决方案
- JNI之——编译时各种问题解决方案
- Unity3D显示中文的各种方案的比较
- 各种热修复方案对比热修复
- sgu234 Black-White King Strikes Back(二分图 输出方案)
- flume-kafka-storm-hdfs-hadoop-hbase
- 大数据架构:flume-ng+Kafka+Storm+HDFS 实时系统组合
- POJ 3683 2-SAT +输出方案
- list集合的各种输出方法
- 各种数据类型的输出占位符
- 【Twitter Storm系列】flume-ng+Kafka+Storm+HDFS 实时系统搭建
- ERP系统各种单据流水号的产生方案
- Storm单机部署方案2
- Storm单机部署方案---原创