常见的Hadoop十大应用误解

常见的Hadoop十大应用误解

 

1. 1.        (误解) Hadoop什么均可以作

(正解) 当一个新技术出来时，咱们都会去思考它在各个不一样产业的应用，而对于平台的新技术来讲，咱们思考以后常会出现这样的结论 “这个好像什么都能作”， 然而，更深刻的去想，你就会发现“好像什么都须要重头作”。 对于Hadoop，我常喜欢举Database来当例子。 三十年前数据库(Database)刚出来时，上面并无什么现成的应用方案(Application)，因此厂商在销售的过程当中常须要花不少的时间去告诉客户说，若是今天你有了这个数据库，你就能够作什么什么的应用，而看起来的确好像数据库什么应用均可以作，由于毕竟大部分的应用都会须要一个数据库。只是三十年前全部的应用都得重头打造，咱们今天习觉得常的ERP、CRM等应用系统，当时并不存在的，那都是后来的事了。今天的Hadoop，正好有点像当年database 刚出来的时候，毕竟今天全部的应用或多或少都会开始去处理半结构、非结构化数据，而这些东西的确都是Hadoop擅长的，因此平台的适用性其实问题不大，重点仍是在应用要由谁来搭建。

 

1. 2.        (误解) Hadoop没法扮演HPC (High Performance Computing) or Grid Computing的角色

(正解) 因为Hadoop自己是由并行运算架构(MapReduce)与分布式文件系统(HDFS)所组成，因此咱们也看到不少研究机构或教育单位，开始尝试把部分本来执行在HPC 或Grid上面的任务，部分移植到Hadoop集群上面，利用Hadoop兼顾高速运算与海量储存的特性，更简易且更有效率地来执行工做。目前国外高能物理、生命科学、医学等领域，都已经有这样的应用案例，利用Hadoop集群与现有的HPC/Grid 搭配、协同运做，来知足不一样特性的运算任务。

 

1. 3.        (误解) Hadoop只能作资料分析/挖掘(Data Mining/Analyst)

(正解) Hadoop特别适合来数据分析与挖掘的应用是毫无疑问的，但数据分析与挖掘是难度与深度都较高的一个应用，所须要的时间的积累也比较长，也所以让通常企业对于导入Hadoop视为畏途，甚至心怀恐惧。然而，从Etu知意图团队这一两年来辅导客户的经验来看，咱们发现其实更多的应用，大多都在数据处理(Data Processing)这个部分，或者更精确地来讲，Hadoop这个平台，特别适合数据预处理(Data pre-Processing)这种应用场景。不管是数据仓库的负载分流(DW Offload)、数据的汇总(Data Aggregation)、甚或是咱们运用协同过滤算法(Collaborative Filtering)针对线下线上零售业所作的精准推荐应用(Recommendation)，广义上来看，均可以说是属于Data Processing的一环，毕竟，Big Data的来临，咱们看data、运用data的角度与方式都必需要有所改变。

l   Big Data强调的不是对因果关系的渴求，取而代之的是关注于data之间的相关关系。

l   也就是说，重点在于要知道“是什么”，反而未必须要知道“为何”。

l   因此, 它要求的是全部data的处理，而不仅是随机样本的分析。

l   最后咱们每每会发现，处理Big Data的简单算法所获得的来自于data呈现的事实，每每比分析small data的复杂算法所获得的来自data背后的缘由，对企业带来的效益更大。

我强烈推荐你们去看Big Data: A Revolution That Will Transform How We Live, Work, and Think这本书，里面把咱们面对Big Data该有的观点与见解，作了很是清楚的陈述，有简中的的翻译本，繁中的好像还没看到。

 

1. 4.        (误解) Hadoop就是BI (Business Intelligence)商业智能

(正解) 跟前面同样，这也是大多数人最容易误解的地方，由于Hadoop特别适合来作数据分析，因此就很直觉地把它想成 “那就是BI嘛”。 会有这种误解，主要来自于对数据运用的总体架构的不清楚。传统BI是属于数据展示层(Data Presentation)，其数据的载体(Data Store)是数据库或数据仓库。对比来看，Hadoop就是专一在半结构化、非结构化数据的数据载体，跟BI是不一样层次的概念。固然，Hadoop除了Data Store外，又特别具有运算的特性，也所以特别容易带来这种观念上的混淆。至于半结构、非结构化数据的数据展示层部分，目前自己并不在Hadoop的生态体系内，而是由其余现有或新创的公司来填补这块空缺，因此，逐渐地咱们会看到愈来愈多现有的BI tool，开始强调其自身与Hadoop的联系性与兼容性，同时，一些新创公司，也发展出彻底不一样于现有BI Tool的基于Big Data的数据展示层。

 

1. 5.        (误解) Hadoop就是ETL (Extract, Transform & Load)

(正解) ETL其实有两种意涵，它自己是一个概念，也同时是一个产品类别(Product Category)的总称。因此当咱们听到“某某公司是作ETL产品的”的这种对话时，其中的 ETL，与DB、Application Server等名词是相同的，都是指向某种类别的IT产品。然而，若是就概念性上来看，ETL指的实际上是数据运用的生命周期中的其中一个过程， 跟我前面提到的数据预处理(Data pre-Processing)是一样一个概念，举凡数据清洗(Data Cleansing)、数据关联、数据汇总等，都包含在这个范畴内。因此当咱们说Hadoop特别适合拿来作ETL时，在概念上，它是正确的，同时也能很清楚明白地定位出Hadoop在企业资料运用中所扮演的角色。但Hadoop终究不是一个ETL的产品，反却是现有的ETL产品，也开始跟BI同样，去发展它在Hadoop上的可用性、联系性与兼容性。Etu团队以前在帮客户导入Hadoop作数据处理时，经常会用script语言来实现一些应用场景，最近一段时间以来，咱们的技术顾问也开始运用3rd-party 的ETL tool来实做这一块，对企业客户来讲，这是他们较熟悉的工具，也下降了他们进入Hadoop的门坎。

 

1. 6.        (误解) Hadoop跟传统storage没什么差异, 都特别适合来作资料的备份(Data Archive)

(正解) 熟悉storage的人，第一次看到Hadoop时，每每只会注意到它的分布式文件系统HDFS，而后开始拿它来与现有的storage的功能特性作比较，而忽略掉Hadoop自己并行运算的那一块。这很合理，毕竟MapReduce的概念，在应用上是比较抽象且难以捉摸的，相反的，HDFS就是一个很清楚且具象的概念。Hadoop固然能够拿来作data archive的运用，但若是你自己的数据没有被常常或偶尔拿出来使用的需求(也就是咱们所说的cold data)的话，Hadoop自己的HDFS做为data archive并不会有特别的优点，反而传统storage的一些延伸的功能特性，Hadoop自己并不具有。虽然HDFS自己是一个不错的object store，具有有做为scale-out NAS的底层的特性,， 但也就仅限于此了， Hadoop自己并无特别为它外加storage自己该具备的功能，毕竟Hadoop当初设计时，对数据的储存与运用的思考，与storage的应用场景是彻底不同的。Hadoop自己要解决的，反而是现有当数据被放进storage后，须要再被拿出来处理或运算时所遇到的困难性。也所以，它特别适合那些web click-stream、CDR (call detail record)、GPS data, system log、 and other time-series data等数据，由于这些数据都具备须要常常被拿出来分析处理的特性。在实际应用中，Hadoop与传统storage实际上是相辅相成的，辟如说，咱们可能会在Hadoop上放过去3到6个月的数据，由于这些数据的再被利用性较高，而6个月以后的数据就可能会把它archive在传统的storage内，由于它被再利用的程度低不少了。

 

1. 7.        (误解) Hadoop是一个搜索引擎(Search Engine)

(正解) Search 的确是Hadoop的一个重要的应用，但Hadoop自己并无内含search engine。实务上，咱们常会把HBase 的index设计运用到极致，来知足一些特定search 或query的应用，但若是要知足全文检索 (full-text search)的需求的话，你就必须在Hadoop上建构一个基于Hadoop的搜索引擎。Lucene / Katta 及其余的open source都有相对应的计划，如何借助Hadoop的特性，来实现一个强大的分布式搜索引擎，这也是咱们一直密切注意、且已放进将来产品的蓝图之中的重要话题。

 

1. 8.        (误解) 基于Hadoop的推荐系统与传统的推荐系统并没有不一样

(正解) 传统的推荐系统只处理客户的事务数据(transaction data)，大多用的是数据仓库或商业智能等解决方案，然而，除了客户的事务数据以外，是否也有可能针对客户交易前的行为进行分析、进而产生推荐? 特别是对电子商务网站来讲，客户在完成购买前的点击浏览、搜寻、及放进购物车等行为，都包含了丰富的讯息，能够藉此很容易去导引出客户想要寻找什么样的商品，因此，若是在产生推荐过程当中能够把这些讯息都纳进来，则所产生推荐的精准度与丰富度必然能够大为提升。这正是新一代的推荐系统会面临到的挑战 : 如何在事务数据 (Transaction Data) 以外，同时也能够把客户的互动数据 (Interaction Data) 含括进来? 因为客户互动数据的型态与事务数据间有极大的差别，其数量级更是远远大于事务数据量，运算频率更是有极高的要求，也所以都远超过现有数据库或数据仓储的能力，而这正是Hadoop所擅长，能够轻易拓展传统机器学习 (Machine Learning) 算法分析大量数据集 (Large Datasets) 的能力，并同时具有横向扩充 (Scale-out) 的能力，可随着数据集的成长轻易扩充，不管多大的数据均可轻易胜任。

 

1. 9.        (误解) Hadoop不适合用来处理小档案的应用

(正解) 对Hadoop稍微有点了解的人，都会知道HDFS的block size的default 值为64MB，且不建议往下调，由于HDFS当初在设计时，并非针对碎片般的小档案的处理而来的。因此当咱们说Hadoop不适合用来处理小档案的应用时，就技术上来讲是对的，但在实际运用上，却能够有不一样的作法来知足海量小档案管理的需求。咱们在中国曾经辅导过一个保险公司，它自己须要处理的小图档 (20KB ~ 1MB)大概有两亿个那么多，且天天还持续在成长，举凡客户的签名、看诊纪录等，都须要被扫描成图像文件，并加以储存，同时，还要偶尔被相对应的应用程序来查询、调用。在实做上，咱们把这些小图档的binary file存进去HBase——而不是HDFS——来管理，因此HDFS block size的设定值大小就不是重点，同时，利用HBase column-base 高效能与高延展性的特性，能够很轻易的就知足多人同时快速在线查询的要求，而随着档案数量持续的增长 , 横向扩充也再也不是问题。相似的应用其实还很多，譬如说银行票据文件的管理就是其中一种，也所以，Etu团队在中国市场，特别针对此应用规划了 “海量小图文件管理系统”解决方案，以知足此类客户的需求。

 

1. 10.     (误解) Hadoop不适合用来作日志管理(Log Management)的应用

(正解) 当天天的日志量成长到必定的程度，现有的日志管理工具都会遇到瓶颈，因此一些国外的日志管理工具(如Splunk、ArcSight)都已经发布了其Hadoop Connector，强调其与Hadoop的联系性与兼容性。因此，若是客户对日志管理的需求只是保存日志、并能够随时对日志搜索的话，那Hadoop自己便可以知足这样的应用，而对于比较复杂的日志管理且日志量很是大的需求，客户也能够从现有的日志管理工具中来挑选，并与Hadoop来搭配协同运做。