大数据之常见的 Hadoop 十大应用误解常见的 Hadoop 十大应用误解。

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

　　1.(误解)Hadoop 什么都可以做

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

　　2.(误解)Hadoop 无法扮演 HPC(HighPerformanceComputing)orGridComputing 的角色

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

　　3.(误解)Hadoop 只能做资料分析 / 挖掘 (DataMining/Analyst)

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

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

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

　　所以, 它要求的是所有 data 的处理，而不只是随机样本的分析。

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

　　我强烈推荐大家去看 BigData:ARevolutionThatWillTransformHowWeLive,Work,andThink 这本书，里面把我们面对 BigData 该有的观点与看法，做了非常清楚的陈述，有简中的的翻译本，繁中的好像还没看到。

　　4.(误解)Hadoop 就是 BI(BusinessIntelligence) 商业智能

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

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

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

　　6.(误解)Hadoop 跟传统 storage 没什么差别, 都特别适合来做资料的备份 (DataArchive)

　　(正解)熟悉 storage 的人，第一次看到 Hadoop 时，往往只会注意到它的分布式文件系统 HDFS，然后开始拿它来与现有的 storage 的功能特性做比较，而忽略掉 Hadoop 本身并行运算的那一块。这很合理，毕竟 MapReduce 的概念，在应用上是比较抽象且难以捉摸的，相反的，HDFS 就是一个很清楚且具象的概念。Hadoop 当然可以拿来做 dataarchive 的运用，但如果你本身的数据没有被经常或偶尔拿出来使用的需求 (也就是我们所说的 colddata) 的话，Hadoop 本身的 HDFS 作为 dataarchive 并不会有特别的优势，反而传统 storage 的一些延伸的功能特性，Hadoop 本身并不具备。虽然 HDFS 本身是一个不错的 objectstore，具备有作为 scale-outNAS 的底层的特性,，但也就仅限于此了，Hadoop 本身并没有特别为它外加 storage 本身该具有的功能，毕竟 Hadoop 当初设计时，对数据的储存与运用的思考，与 storage 的应用场景是完全不一样的。Hadoop 本身要解决的，反而是现有当数据被放进 storage 后，需要再被拿出来处理或运算时所遇到的困难性。也因此，它特别适合那些 webclick-stream、CDR(calldetailrecord)、GPSdata,systemlog、andothertime-seriesdata 等数据，因为这些数据都具有需要经常被拿出来分析处理的特性。在实际应用中，Hadoop 与传统 storage 其实是相辅相成的，辟如说，我们可能会在 Hadoop 上放过去 3 到 6 个月的数据，因为这些数据的再被利用性较高，而 6 个月之后的数据就可能会把它 archive 在传统的 storage 内，因为它被再利用的程度低很多了。

　　7.(误解)Hadoop 是一个搜索引擎 (SearchEngine)

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

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

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

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

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

　　10.(误解)Hadoop 不适合用来做日志管理 (LogManagement) 的应用

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