大数据资料之常见的Hadoop十大应用误解学习
|
(正解) Search 的确是Hadoop的一个重要的应用，但Hadoop本身并没有内含search engine。实务上，我们常会把HBase 的index设计运用到极致，来满足一些特定search 或query的应用，但如果要满足全文检索 (full-text search)的需求的话，你就必须在Hadoop上建构一个基于Hadoop的搜索引擎。Lucene / Katta 及其他的open source都有相对应的计划，如何借助Hadoop的特性，来实现一个强大的分布式搜索引擎，这也是我们一直密切注意、且已放进未来产品的蓝图之中的重要话题。 8. (误解) 基于Hadoop的推荐系统与传统的推荐系统并无不同 (正解) 传统的推荐系统只处理客户的事务数据(transaction data)，大多用的是数据仓库或商业智能等解决方案，然而，除了客户的事务数据之外，是否也有可能针对客户交易前的行为进行分析、进而产生推荐? 特别是对电子商务网站来说，客户在完成购买前的点击浏览、搜寻、及放进购物车等行为，都包含了丰富的讯息，可以藉此很容易去导引出客户想要寻找什么样的商品，所以，如果在产生推荐过程中可以把这些讯息都纳进来，则所产生推荐的精准度与丰富度必然可以大为提高。这正是新一代的推荐系统会面临到的挑战 : 如何在事务数据 (Transaction Data) 之外，同时也可以把客户的互动数据 (Interaction Data) 含括进来? 由于客户互动数据的型态与事务数据间有极大的差异，其数量级更是远远大于事务数据量，运算频率更是有极高的要求，也因此都远超过现有数据库或数据仓储的能力，而这正是Hadoop所擅长，可以轻易拓展传统机器学习 (Machine Learning) 算法分析大量数据集 (Large Datasets) 的能力，并同时具备横向扩充 (Scale-out) 的能力，可随着数据集的成长轻易扩充，无论多大的数据都可轻易胜任。 9. (误解) Hadoop不适合用来处理小档案的应用 (正解) 对Hadoop稍微有点了解的人，都会知道HDFS的block size的default 值为64MB，且不建议往下调，因为HDFS当初在设计时，并不是针对碎片般的小档案的处理而来的。所以当我们说Hadoop不适合用来处理小档案的应用时，就技术上来说是对的，但在实际运用上，却可以有不同的做法来满足海量小档案管理的需求。我们在中国曾经辅导过一个保险公司，它本身需要处理的小图档 (20KB ~ 1MB)大概有两亿个那么多，且每天还持续在成长，举凡客户的签名、看诊纪录等，都需要被扫描成图像文件，并加以储存，同时，还要偶尔被相对应的应用程序来查询、调用。在实作上，我们把这些小图档的binary file存进去HBase——而不是HDFS——来管理，所以HDFS block size的设定值大小就不是重点，同时，利用HBase column-base 高效能与高延展性的特性，可以很轻易的就满足多人同时快速在线查询的要求，而随着档案数量持续的增加 , 横向扩充也不再是问题。类似的应用其实还不少，譬如说银行票据文件的管理就是其中一种，也因此，Etu团队在中国市场，特别针对此应用规划了 “海量小图文件管理系统”解决方案，以满足此类客户的需求。 10. (误解) Hadoop不适合用来做日志管理(Log Management)的应用 (正解) 当每天的日志量成长到一定的程度，现有的日志管理工具都会遇到瓶颈，所以一些国外的日志管理工具(如Splunk、ArcSight)都已经发布了其 Hadoop Connector，强调其与Hadoop的联系性与兼容性。所以，如果客户对日志管理的需求只是保存日志、并可以随时对日志搜索的话，那Hadoop本身即可以满足这样的应用，而对于比较复杂的日志管理且日志量非常大的需求，客户也可以从现有的日志管理工具中来挑选，并与Hadoop来搭配协同运作。 【编辑推荐】
点赞 0 （编辑：常州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
