北京快三开奖

  • <tr id="U9YkSO"><strong id="U9YkSO"></strong><small id="U9YkSO"></small><button id="U9YkSO"></button><li id="U9YkSO"><noscript id="U9YkSO"><big id="U9YkSO"></big><dt id="U9YkSO"></dt></noscript></li></tr><ol id="U9YkSO"><option id="U9YkSO"><table id="U9YkSO"><blockquote id="U9YkSO"><tbody id="U9YkSO"></tbody></blockquote></table></option></ol><u id="U9YkSO"></u><kbd id="U9YkSO"><kbd id="U9YkSO"></kbd></kbd>

    <code id="U9YkSO"><strong id="U9YkSO"></strong></code>

    <fieldset id="U9YkSO"></fieldset>
          <span id="U9YkSO"></span>

              <ins id="U9YkSO"></ins>
              <acronym id="U9YkSO"><em id="U9YkSO"></em><td id="U9YkSO"><div id="U9YkSO"></div></td></acronym><address id="U9YkSO"><big id="U9YkSO"><big id="U9YkSO"></big><legend id="U9YkSO"></legend></big></address>

              <i id="U9YkSO"><div id="U9YkSO"><ins id="U9YkSO"></ins></div></i>
              <i id="U9YkSO"></i>
            1. <dl id="U9YkSO"></dl>
              1. <blockquote id="U9YkSO"><q id="U9YkSO"><noscript id="U9YkSO"></noscript><dt id="U9YkSO"></dt></q></blockquote><noframes id="U9YkSO"><i id="U9YkSO"></i>
                企业空间 推销商城 存储论坛
                北京快三开奖全闪存阵列 IBM云盘算 Acronis 安克诺斯 安腾普 腾保数据
                首页 > Hadoop > 注释

                关于Hadoop十个看法误区

                2016-12-10 01:02泉源:中国存储网
                导读:本文总结Hadoop十个看法误区,协助各人更好天文解和学习Hadoop。由于Hadoop自身是由并行运算架构(MapReduce)与散布式文件零碎(HDFS)所构成,以是我们也看到许多研讨机构或教诲单元,开端实验把局部本来实行在HPC 或Grid下面的义务

                Hadoop是一个由Apache基金会所开辟的散布式零碎根底架构。用户可以在不理解散布式底层细节的状况下,开辟散布式顺序。本文总结Hadoop十个看法误区,协助各人更好天文解和学习Hadoop。

                关于Hadoop十个看法误区

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

                (正解) 当一个新技能出来时,我们都市去考虑它在各个差别财产的使用,而关于平台的新技能来说,我们考虑之后常会呈现如许的结论“这个仿佛什么都能做”,但是,更深化的去想,你就会发明“仿佛什么都需求重头做”。关于Hadoop,我常喜好举Database来当例子。三十年前数据库(Database)刚出来时,下面并没有什么现成的使用方案(Application),以是厂商在贩卖的进程中常需求花许多的工夫去通知客户说,假如明天你有了这个数据库,你就可以做什么什么的使用,而看起来确实仿佛数据库什么使用都可以做,由于终究大局部的使用都市需求一个数据库。只是三十年前一切的使用都得重头打造,我们明天屡见不鲜的ERP、CRM等使用零碎,事先并不存在的,那都是厥后的事了。明天的Hadoop,恰好有点像当年database 刚出来的时分,终究明天一切的使用或多或少都市开端行止理半构造、非构造化数据,而这些工具确实都是Hadoop善于的,以是平台的实用性实在题目不大,重点照旧在使用要由谁来搭建。

                2.(曲解)Hadoop无法饰演HPC (High Performance Computing) or Grid Computing的脚色

                (正解) 由于Hadoop自身是由并行运算架构(MapReduce)与散布式文件零碎(HDFS)所构成,以是我们也看到许多研讨机构或教诲单元,开端实验把局部本来实行在HPC 或Grid下面的义务,局部移植到Hadoop集群下面,应用Hadoop统筹高速运算与海量贮存的特性,更浅易且更无效率地来实行任务。现在外洋高能物理、生命迷信、医学等范畴,都曾经有如许的使用案例,应用Hadoop集群与现有的HPC/Grid 搭配、协同运作,来满意差别特性的运算义务。

                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该有的观念与见解,做了十分清晰的陈说,有简中的的翻译本,繁中的仿佛还没看到。

                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的数据展示层。

                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的门坎。

                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内,由于它被再应用的水平低许多了。

                7.(曲解) Hadoop是一个搜刮引擎(Search Engine)

                (正解) 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来搭配协同运作。

                Chinastor引荐阅读:Hadoop:你不得不理解的大数据东西

                持续阅读
                要害词 :
                hadoop
                中国存储网声明:此文观念不代表本站态度,若有版权疑问请联络我们。
                相干阅读
                产物引荐
                头条阅读
                栏目热门

                Copyright @ 2006-2019 ChinaStor.COM 版权一切 京ICP备14047533号

                中国存储网

                存储第一站,存储流派,存储在线交换平台