长久以来，说起Hadoop，大家只会想到它能承担offline系统的分析工作。的确，它在这个方面做的是很优秀了。如果有人说：Hadoop也可以担当online系统的一部分呀！我们可能就会替这个人悲哀了，是吧？为了更好地认识Hadoop的“所为”，我想暂时抛开技术的细枝末节，逐一梳理下Hadoop的各个组件，试着分析下Hadoop离担当online系统之大任还差哪些。
首先，在我来看，online系统需要有这些特质：稳定、高效、易于管理与监控、易于集成，它们在我认识中依次以重要性排序。能和Hadoop类比的（类似的，只为了举例）online系统有NFS，DB等，它们符合这样的要求。所以这些特质也会成为我们要求Hadoop平台的准绳。
Hadoop定位于大数据的存储与计算，且存储的是半结构化或非结构化数据。Online系统是否需要这样的一个组件是第一位要考虑的。单纯用它做文件存储?感觉大材小用了，类似的存储平台很多，不一定选Hadoop。Hadoop的优势就在于将存储与计算整合，所以如果要让它担当大任，对进来的数据不做分析就没有必要。那如果要分析， 可以分析哪些数据呢？之前Cloudera的创始人讲过Hadoop适用的十种场景，可能不是很完整，至少在很多领域里，我们都能看到Hadoop的应用场景。
有人会问：如果要online分析，我为什么不选择Storm/S4这些流式数据分析平台，那不更有效么？Storm/S4的特点就是一次分析结束，数据就没了！也就是说，数据没有“重放性”。很多时候分析不是一次就可以做完的。增量分析、定时分析、延迟分析、迭代分析等，都需要想要分析时数据还在。所以Hadoop的使用与Storm/S4的应用场景还是有差别的。那Hadoop要支持online系统，它能做什么呢？这个问题的答案就是：你想从大数据中获取什么信息？如果用在广告定位领域，就是想更快地根据实时搜索调整广告投放；如果用在贸易监控领域，就是想及时地获得异常情况反馈。。。 如果Hadoop能根据实时搜索结果动态改善搜索质量，那么你觉着有意义么？
Hadoop要想接入到online系统，它需要有效地部署与完善它的各个组件。下面会分析这些组件所面临的各种问题：
存储：
1. HA. 自从最近社区解决了HA问题后，终于可以扬眉吐气地增加主版本了。HDFS也不用再受别人BS的眼神。
2. 自身的软件问题。HDFS发展快八年了，还是有很多软件问题存在。客观上没办法，分布式集群的同步问题谁也避不开。但是它影响着集群的升级与维护，会降低系统的可用性。
3. 更简单及方便的接口。从语言上看，推出了libhdfs，但有内存泄露问题，不敢用呀。还没有其它语言的接口。Hoop正在完善中，之后就可以名正言顺地替代HTTPProxy了。Thrift接口也完善了，但Thrift server应该放在哪呢？
计算：
1. MapReduce的动静太大了。MapReduce利用并发化来解决没有索引的大数据分析问题。每个MapReduce Job都粗旷地扫描所有目标文件。我的感觉里，没有索引的粗狂风格纵是成为online系统，也应付不了online的更多问题。当前正在做的HOP只是解决框架设计，不能解决索引的问题。
2. 配额管理。MapReduce Job执行依赖于集群资源的支撑。CPU、内存和网络等资源需要有效管理起来，以适用于不同的online user。在MapReduce中，与之相关的部分就是Job调度策略。在Hive中，表结构的规划也会影响到HDFS文件大小及MapReduce资源。总之，如果不做资源管理的话，想对于提供相互貌似独立的平台其实很难的。
3. 调度。Job有大有小、有急有缓、有长期有瞬时。不管怎样的Job都套在MapReduce的Job调度策略中，肯定不是有效的选择。如何根据Job的属性来选择匹配合适的调度策略是需要考虑的。
4. MapReduce Job的调优。Job的优化不是统一的，肯定因Job而异。Online的服务需要根据业务与数据特性来定制合适的调优策略。这点暂时没有做到。
展现：
有效的输出展现工具。当前的MapReduce展现太丑陋了。做了这么牛的一套系统，输出很弱智，的确让人感到悲哀。不过，最新的消息是Apache正在酝酿Hive等系统的展现工具，或许是集成其它好玩的应用。不管怎样，有效的展现总会提高用户体验的。
全局：
1. 集群的管理与监控。这个方面现在不管Hadoop创业公司还是社区都有相当高的认识，很多产品开始涌现。如何简单地配置与高效地监控是大家比拼的重点。这个方面可以不用担忧。
2. 用户的全局管理。Hadoop生态圈的用户管理是分散、没有全局统一起来的。用户可以做什么、用户所在的组可以做什么都需要有明确的要求。在Hadoop之外再搭建一层用户管理的层是相当有必要的。