hadoop应用场景总结

我个人接触hadoop仅仅不到一年，因为是业余时间学习，故进度较慢，看过好多视频，买过好多书，学过基本知识，搭建过伪分布式集群，有过简单的教程式开发，恰逢毕业季，面试过相关岗位，自认为路还很远，还需一步一步积累。

今天总结一篇关于hadoop应用场景的文章，自认为这是学习hadoop的第一步，本文主要解答这几个问题：

hadoop的十大应用场景?

hadoop到底能做什么?

2012年美国著名科技博客GigaOM的专栏作家Derrick Harris跟踪云计算和Hadoop技术已有多年时间，在一篇文章中总结了10个Hadoop的应用场景，下面分享给大家：

在线旅游：目前全球范围内80%的在线旅游网站都是在使用Cloudera公司提供的Hadoop发行版，其中SearchBI网站曾经报道过的Expedia也在其中。

移动数据：Cloudera运营总监称，美国有70%的智能手机数据服务背后都是由Hadoop来支撑的，也就是说，包括数据的存储以及无线运营商的数据处理等，都是在利用Hadoop技术。

电子商务：这一场景应该是非常确定的，eBay就是最大的实践者之一。国内的电商在Hadoop技术上也是储备颇为雄厚的。

能源开采：美国Chevron公司是全美第二大石油公司，他们的IT部门主管介绍了Chevron使用Hadoop的经验，他们利用Hadoop进行数据的收集和处理，其中这些数据是海洋的地震数据，以便于他们找到油矿的位置。

节能：另外一家能源服务商Opower也在使用Hadoop，为消费者提供节约电费的服务，其中对用户电费单进行了预测分析。

基础架构管理：这是一个非常基础的应用场景，用户可以用Hadoop从服务器、交换机以及其他的设备中收集并分析数据。

图像处理：创业公司Skybox Imaging使用Hadoop来存储并处理图片数据，从卫星中拍摄的高清图像中探测地理变化。

诈骗检测：这个场景用户接触的比较少，一般金融服务或者政府机构会用到。利用Hadoop来存储所有的客户交易数据，包括一些非结构化的数据，能够帮助机构发现客户的异常活动，预防欺诈行为。

IT安全：除企业IT基础机构的管理之外，Hadoop还可以用来处理机器生成数据以便甄别来自恶意软件或者网络中的攻击。

医疗保健：医疗行业也会用到Hadoop，像IBM的Watson就会使用Hadoop集群作为其服务的基础，包括语义分析等高级分析技术等。医疗机构可以利用语义分析为患者提供医护人员，并协助医生更好地为患者进行诊断。

上述转载自：10个hadoop应用场景 总体来说，hadoop能够做很多事，不过说得很虚，只是做个简单了解，让我们接着往下看：

hadoop是什么?

(1)Hadoop是一个开源的框架，可编写和运行分布式应用处理大规模数据，是专为离线和大规模数据分析而设计的，并不适合那种对几个记录随机读写的在线事务处理模式。Hadoop=HDFS(文件系统，数据存储技术相关)+ Mapreduce(数据处理)，Hadoop的数据来源可以是任何形式，在处理半结构化和非结构化数据上与关系型数据库相比有更好的性能，具有更灵活的处理能力，不管任何数据形式最终会转化为key/value，key/value是基本数据单元。用函数式变成Mapreduce代替SQL，SQL是查询语句，而Mapreduce则是使用脚本和代码，而对于适用于关系型数据库，习惯SQL的Hadoop有开源工具hive代替。

(2)Hadoop就是一个分布式计算的解决方案.

hadoop能做什么?

hadoop擅长日志分析，facebook就用Hive来进行日志分析，2009年时facebook就有非编程人员的30%的人使用HiveQL进行数据分析;淘宝搜索中 的自定义筛选也使用的Hive;利用Pig还可以做高级的数据处理，包括Twitter、LinkedIn 上用于发现您可能认识的人，可以实现类似Amazon.com的协同过滤的推荐效果。淘宝的商品推荐也是;在Yahoo的40%的Hadoop作业是用pig运行的，包括垃圾邮件的识别和过滤，还有用户特征建模。(2012年8月25新更新，天猫的推荐系统是hive，少量尝试mahout!)

下面举例说明：

设想一下这样的应用场景. 我有一个100M 的数据库备份的sql 文件.我现在想在不导入到数据库的情况下直接用grep操作通过正则过滤出我想要的内容。例如：某个表中含有相同关键字的记录，有几种方式,一种是直接用linux的命令 grep 还有一种就是通过编程来读取文件,然后对每行数据进行正则匹配得到结果好了 现在是100M 的数据库备份.上述两种方法都可以轻松应对.

那么如果是1G , 1T 甚至 1PB 的数据呢 ,上面2种方法还能行得通吗? 答案是不能.毕竟单台服务器的性能总有其上限.那么对于这种 超大数据文件怎么得到我们想要的结果呢?

有种方法 就是分布式计算, 分布式计算的核心就在于 利用分布式算法 把运行在单台机器上的程序扩展到多台机器上并行运行.从而使数据处理能力成倍增加.但是这种分布式计算一般对编程人员要求很高,而且对服务器也有要求.导致了成本变得非常高.

Hadoop 就是为了解决这个问题诞生的.Hadoop 可以很轻易的把很多linux的廉价pc 组成分布式结点,然后编程人员也不需要知道分布式算法之类,只需要根据mapreduce的规则定义好接口方法,剩下的就交给Haddop. 它会自动把相关的计算分布到各个结点上去,然后得出结果.

例如上述的例子 ： Hadoop 要做的事 首先把 1PB的数据文件导入到 HDFS中, 然后编程人员定义好 map和reduce, 也就是把文件的行定义为key,每行的内容定义为value , 然后进行正则匹配,匹配成功则把结果 通过reduce聚合起来返回.Hadoop 就会把这个程序分布到N 个结点去并行的操作.

那么原本可能需要计算好几天,在有了足够多的结点之后就可以把时间缩小到几小时之内.

hadoop使用场景

• 大数据量存储：分布式存储（各种云盘，百度，360~还有云平台均有hadoop应用）
• 日志处理: Hadoop擅长这个
• 海量计算: 并行计算
• ETL:数据抽取到oracle、mysql、DB2、mongdb及主流数据库
• 使用HBase做数据分析: 用扩展性应对大量读写操作—Facebook构建了基于HBase的实时数据分析系统
• 机器学习: 比如Apache Mahout项目（Apache Mahout简介 常见领域：协作筛选、集群、归类）
• 搜索引擎:hadoop + lucene实现
• 数据挖掘：目前比较流行的广告推荐
• 大量地从文件中顺序读。HDFS对顺序读进行了优化，代价是对于随机的访问负载较高。
• 用户行为特征建模
• 个性化广告推荐
• 智能仪器推荐

下面从hadoop的各项技术和各层架构角度分析应用场景

hadoop各技术下的应用场景：

 

 

hadoop 1.x 技术分布

数据采集和DataFlow

对于数据采集主要分为三类，即结构化数据库采集，日志和文件采集，网页采集。对于结构化数据库，采用Sqoop是合适的，可以实现结构化数据库中数据并行批量入库到hdfs存储。对于网页采集，前端可以采用Nutch，全文检索采用lucense，而实际数据存储最好是入库到Hbase数据库。对于日志文件的采集，现在最常用的仍然是flume或chukwa，但是我们要看到如果对于日志文件数据需要进行各种计算处理再入库的时候，往往flume并不容易处理，这也是为何可以采用Pig来做进一步复杂的data flow和process的原因。

数据采集类似于传统的ETL等工作，因此传统ETL工具中的数据清洗，转换，任务和调度等都是相当重要的内容。这一方面是要基于已有的工具，进行各种接口的扩展以实现对数据的处理和清洗，一方面是加强数据采集过程的调度和任务监控。

数据存储库

数据存储在这里先谈三种场景下的三种存储和应用方式，即Hbase，Hive，impala。其中三者都是基于底层的hdfs分布式文件系统。hive重点是sql-batch查询，海量数据的统计类查询分析，而impala的重点是ad-hoc和交互式查询。hive和impala都可以看作是基于OLAP模式的。而Hbase库是支撑业务的CRUD操作(增加(Create)、读取(Retrieve)、更新(Update)和删除(Delete))，各种业务操作下的处理和查询。

如何对上面三种模式提供共享一致的数据存储和管理服务，HCatalog是基于Apache Hadoop之上的数据表和存储管理服务。提供统一的元数据管理，而不需要知道具体的存储细节当然是最好的，但是Hcatalog本身也还处于完善阶段，包括和Hive ,Pig的集成。

基于Mysql的MPP数据库Infobright是另外一个MPP(share nothing)数据分析库的选择，如果本身已有的业务系统就是基于Mysql数据库的，那么采用Infobright来做作为一个OLAP分析库也是一个选择。但是本身Infobright的性能，Infobright社区版的稳定性，管控功能的缺失等仍然是需要考量的因素。

对于mapreduce和zookeeper本身就已经在hbase和hive中使用到了。如hive的hsql语言需要通过mapreduce解析和合并等。而对于impala要注意到本身是基于内存的MPP机制，没有用到mapreduce框架去处理，Dremel之所以能在大数据上实现交互性的响应速度，是因为使用了两方面的技术：一是对有嵌套结构的嵌套关系型数据采用了全新的列式存储格式，一是分布式可扩展统计算法，能够在几千台机器上并行计算查询结果。

实时流处理

这个hadoop框架本身没有包含，twitter推出storm可以解决实时热点查询和排序的问题，基于一个巨大的海量数据数据库，如果不是这种基于增量strom模式的分布式实时任务计算和推送，很难真正满足业务对性能的要求。

storm只是提供了一个开源的实时流处理框架，而真正的任务处理逻辑和代码仍然需要自己去实现，而开源框架只是提供了一个框架，提供了基本的集群控制，任务采集，任务分发，监控和failover的能力。真正在企业内部应用来看，很少有这种实时流场景，而与之对应的CEP复杂事件处理和EDA事件驱动架构，这个基于消息中间件实现的事件发布订阅和推送，事件链的形成相对来说更加成熟。

另外，hadoop 和 strom还是有本质区别的?

hadoop的处理方式，不能称之为流，因为当数据来了，不能处理，因为mapreduce还没有跑完。hadoop为什么被称之为批处理。因为它一个mapreduce只能处理当前输入的文件数据。比如日志处理，我想处理去年的数据，那么这个mapreduce只能处理去年的，今年的今天新产生的能不能处理-------不能处理。 想处理该怎么办?另外起一个mapreduce。如果再产生该怎么办，再启动一个mapreduce~

再来看storm，处理去年的数据，那么今年今天的能不能处理，能处理，如果吞吐量不够，怎么办?排队，那么我们是否需要在此开启storm的topology，答案是不需要，因为一个topology就能处理。

从Hadoop生态4层架构谈hadoop(2.X)应用背景：

底层：存储层，文件系统HDFS，NoSQL Hbase
中间层：资源及数据管理层，YARN以及Sentry等
上层：MapReduce、Impala、Spark等计算引擎
顶层：基于MapReduce、Spark等计算引擎的高级封装及工具，如Hive、Pig、Mahout

hadoop可以作为分布式存储框架存储大规模数据，数据的价值越来越被企业重视，被称为是21世纪的石油;

存储了大规模的数据，我们要干什么呢，当然是分析数据中的价值，Hadoop+MR(MapReduce)用于离线大数据的分析挖掘，比如：电商数据的分析挖掘、社交数据的分析挖掘，企业客户关系的分析挖掘，最终的目标就是BI了，提高企业运作效率，实现精准营销，各个垂直领域的推荐系统，发现潜在客户等等。在这个数据化时代，每件事都会留下电子档案，分析挖掘日积月累的数据档案，我们就能理解这个世界和我们自己更多。

MR编写代码复杂度高，由于磁盘IO，分析结果周期长，现实世界中我们对数据分析的实时性要求越来越高，基于内存计算的spark来了。Hadoop+spark正在替代Hadoop+MR成为大数据领域的明星，Cloudera正在积极推动Spark成为Hadoop的默认数据处理引擎。

更上层应用，如：机器学习,发现、预测分析等都必须基于大规模的数据，没有足够的数据一切扯淡，数据量足够大，就必须分布式存储，依赖大规模的廉价PC构建hadoop集群是非常有必要的。