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，为消费者提供节约电费的服务，其中对⽤户电费单进⾏了预测分析。常见mpp数据库
基础架构管理：这是⼀个⾮常基础的应⽤场景，⽤户可以⽤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的协同
过滤的推荐效果。淘宝的商品推荐也是；在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集是⾮常有必要的。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。