大数据资料之常见的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 （编辑：湖南网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
