大数据资料常见的Hadoop应用误解

李荣

Hadoop是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下，开发分布式程序。并充分利用集群的威力进行高速运算和存储。以下是常见的Hadoop十大应用误解和正解。

1.（误解）Hadoop什么都可以做

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

2.（误解）Hadoop无法扮演HPC or Grid Computing的角色

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

3.（误解）Hadoop只能做资料分析或挖掘

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

Big Data强调的不是对因果关系的渴求，取而代之的是关注于data之間的相关关系。也就是说，重点在于要知道“是什么”，反而未必需要知道“为什么”。所以，它要求的是所有data的处理，而不只是随机样本的分析。

最后我们往往会发现，处理Big Data的简单算法所得到的来自于data呈现的事实，往往比分析small data的复杂算法所得到的来自data背后的原因，对企业带来的效益更大。

4.（误解）Hadoop就是商业智能（Business Intelligence，BI）

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

5.（误解）Hadoop就是ETL（Extract， Transform & Load）

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

6.（误解）Hadoop跟传统storage没什么差别，都特别适合用来做资料的备份

（正解）熟悉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，other time-series data等数据，因为这些数据都具有需要经常被拿出来分析处理的特性。在实际应用中，Hadoop与传统storage其实是相辅相成的，辟如说，我们可能会在Hadoop上放过去3～6个月的数据，因为这些数据的再被利用性较高，而6个月之后的数据就可能会把它放在传统的storage内，因为它被再利用的程度低很多了。

7.（误解）Hadoop是一个搜索引擎

（正解）Search的确是Hadoop的一个重要的应用，但Hadoop本身并没有内含search engine。实务上，我们常会把HBase的index设计运用到极致，来满足一些特定search或query的应用，但要满足全文检索的需求，就必须在Hadoop上建构一个基于Hadoop的搜索引擎。

8.（误解）基于Hadoop的推荐系统与传统的推荐系统并无不同

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

9.（误解）Hadoop不适合用来处理小档案的应用

（正解）对Hadoop稍微有点了解的人，都会知道HDFS的block size的default值为64 MB，且不建议往下调，因为HDFS当初在设计时，并不是针对碎片般的小档案处理。所以说Hadoop不适合用来处理小档案的应用时，就技术上来说是对的，但在实际运用上，却有不同的做法来满足海量小档案管理的需求。例如保险公司，它本身需要处理的小图档（20KB～1 MB）大概有2亿个那么多，且每天还持续在成长，包括客户的签名、看诊纪录等，都需要被扫描成图像文件，并加以储存，同时，还要被相对应的应用程序来进行查询、调用。在实作上，Hadoop把这些小图档的binary file存进去HBase，而不是HDFS来管理，所以HDFS block size的设定值大小就不是重点，同时，利用HBase column-base高效能与高延展性的特性，可以很容易满足多人同时快速在线查询的要求，而随着档案数量持续的增加。横向扩充也不再是问题。类似的应用其实还不少，譬如说银行票据文件的管理就是其中一种。

10.（误解）Hadoop不适合用来做日志管理的应用

（正解）当每天的日志量成长到一定的程度，现有的日志管理工具都会遇到瓶颈，所以一些国外的日志管理工具（如Splunk，ArcSight）都已经发布了其Hadoop Connector，强调其与Hadoop的联系性与兼容性。所以，如果客户对日志管理的需求只是保存日志、并可以随时对日志搜索的话，那Hadoop本身即可以满足，而对于比较复杂的日志管理且日志量非常大的需求，客户也可以从现有的日志管理工具中来挑选，并与Hadoop来搭配协同运作。