查看: 91|回复: 0

扣丁学堂大数据培训分享Hadoop/Spark生态圈里的新气象

发表于 2018-6-13 11:43:12

Hadoop在短短的一年的时间里火爆了生态圈,如今越来越多的人想要了解学习Hadoop,本篇文章扣丁学堂大数据培训小编就给大家分享一下Hadoop/Spark生态圈里的新气象,让大家能更进一步的了解Hadoop。


1、Spark
Spark的运行速度正如其名;更重要的是,API用起来容易得多,所需的代码比之前的分布式计算模式来得少。IBM承诺会培训100万名新的 Spark开发人员,为这个项目备好了庞大资金,Cloudera宣布Spark是我们知道与其一个平台(One Platform)计划配套的所有项目的核心,加上Hortonworks全力支持Spark,鉴于这种形势,我们可以肯定地说,业界已将“技术环球小姐”(Tech Miss Universe)这顶桂冠授予了Spark(但愿这回没有弄错)。
成本因素也在推动Spark迅猛崛起。过去在内存中分析数据成本高昂,但由了云计算和更高的计算弹性,无法装入到内存(至少在分布式计算集群上)中的工作负载的数量在日益减少。同样,我们谈论的不是你的所有数据,而是为了计算结果而需要的一小部分数据。
Spark仍然不尽如人意――如果在生产环境中使用它,我们确实看到了这一幕,但是缺点值得忍受。Spark其实速度快得多,而且完全有了改进。
具有讽刺意味的是,Spark方面动静最大的恰恰与流数据有关,而这是Spark的最大软肋。Cloudera宣布旨在让Spark流数据技术适用于80%的使用场合,就考虑到了这一缺陷。不过,你可能仍需要探究替代方案,以实现亚秒级或大容量的数据获取(而不是数据分析)。
Spark不仅避免了需要MapReduce和Tez,还可能避免了Pig之类的工具。此外,Spark的RDD/DataFrames API并不是进行抽取、转换和加载(ETL)及其他数据转换的糟糕方法。与此同时,Tableau及其他数据可视化厂商已宣布打算直接支持Spark。
2、Hive
Hive让你可以对文本文件或结构化文件执行SQL查询。那些文件通常驻留在HDFS上,这时你可以使用Hive,Hive可以将文件编入目录,并暴露文件,好像它们就是表。你常用的SQL工具可以通过JDBC或ODBC连接到Hive。
简而言之,Hive是一个乏味、缓慢但又有用的工具。默认情况下,它将SQL任务转换成MapReduce任务。你可以切换它,使用基于DAG的Tez,而Tez的速度快得多。还可以切换它,使用Spark,不过“alpha”这个词无法体现真正体验。
你需要知道Hive,因为许多Hadoop项目一开始“就让我们将数据转储到某个地方”,然后“顺便提一下,我们想在常用的SQL图表工具中看看数据。”Hive是最直观简单的办法。如果你想高效地查看数据,可能需要其他工具(比如Phoenix或Impala)。
3、Kerberos
我讨厌Kerberos,它也不是那么喜欢我。遗憾的是,它又是唯一为Hadoop全面实施的验证技术。你可以使用Ranger或Sentry等工具来减少麻烦,不过仍可能要通过Kerberos与活动目录进行集成。
4Ranger/Sentry
如果你不使用Ranger或Sentry,那么大数据平台的每一个部分都将进行自己的验证和授权。不会有集中控制,每个部分都会以自己的独特方式看世界。
那么该选择哪一个:Ranger还是Sentry?这么说吧,眼下Ranger似乎有点领先,较为全面,不过它是Hortonworks的产物。 Sentry则是Cloudera的产物。各自支持Hadoop堆栈中相应厂商支持的那一部分。如果你没打算获得Cloudera或 Hortonworks的支持,那么我要说,Ranger是眼下更胜一筹的解决方案。然而,Cloudera走在Spark的前面,该公司还宣布了安全方面的重大计划,作为“一个平台”战略的一部分,这势必会让Sentry处于领先。(坦率地说,如果Apache运作正常,它会对这两家厂商施加压力,共同开发一款解决方案。)
5、HBase/Phoenix
HBase是一种完全可以接受的列式数据存储系统。它还内置到你常用的Hadoop发行版中,它得到Ambari的支持,与Hive可以顺畅地连接。如果你添加Phoenix,甚至可以使用常用的商业智能工具来查询HBase,好像它就是SQL数据库。如果你通过Kafka和Spark或 Storm获取流数据,那么HBase就是合理的着陆点,以便该数据持久化,至少保持到你对它进行别的操作。
使用Cassandra之类的替代方案有充分理由。但如果你使用Hadoop,那就已经有了HBase――如果你向Hadoop厂商购买支持服务,已经有了支持HBase的功能――所以这是个良好的起点。毕竟,它是一种低延迟、持久化的数据存储系统,为原子性、一致性、隔离性和持久性(ACID)提供了相当给力的支持。如果Hive和Impala的SQL性能没有引起你的兴趣,你会发现HBase和Phoenix处理一些数据集比较快。
6、Impala
Teradata和Netezza使用MPP来处理跨分布式存储的SQL查询。Impala实际上是基于HDFS的一种MPP解决方案。
Impala和Hive之间的最大区别在于,你连接常用的商业智能工具时,“平常事务”会在几秒钟内运行,而不是几分钟内运行。Impala在许多应用场合可以取代Teradata和Netezza。对不同类型的查询或分析而言,其他结构可能必不可少(针对这种情况,可着眼于Kylin和 Phoenix之类的技术)。但通常来说,Impala让你可以避开讨厌的专有MPP系统,使用单一平台来分析结构化数据和非结构化数据,甚至部署到云端。
这与使用正宗的Hive存在诸多重叠,但Impala和Hive的操作方式不一样,有着不同的最佳适用场合。Impala得到Cloudera的支持,但未得到Hortonworks的支持,Hortonworks改而支持Phoenix。虽然运行Impala不太复杂,但是你使用Phoenix可以实现同样的一些目标,Cloudera现正将注意力转向Phoenix。
7、HDFS(Hadoop分布式文件系统)
由于Spark大行其道,所谓的大数据项目不断迁移到云端,HDFS不如去年来得重要。但是它仍然是默认技术,也是概念上比较简单的实现分布式文件系统的技术之一。
8、Kafka
分布式消息系统(如Kafka提供的系统)会完全淘汰像ActiveMQ这样的客户机/服务器工具。即便Kafka没有用在大多数流数据项目上,至少也用在许多流数据项目。它也很简单。如果你使用其他消息传递工具,会觉得它有点原始简陋,但在大多数情况下,你无论如何也不需要MQ类解决方案提供的细粒度路由选项。
9、Storm/Apex
Spark处理流数据不是很擅长,但是Storm如何呢?它速度更快,延迟更低,而且耗用更少的内存――大规模获取流数据时,这点很重要。另一方面,Storm的管理工具较为逊色,API也不如Spark的API一样好。Apex更新更好,但还没有得到广泛部署。我仍会在默认情况下选择Spark 处理不需要亚秒级的任何事务。
10、Ambari / Cloudera Manager
我见过有人不用Ambari或Cloudera Manager,试着监视和管理Hadoop集群。效果不好。这两种解决方案在比较短的时间里,让Hadoop环境的管理和监控功能取得了长足发展。不妨与NoSQL领域作个比较:NoSQL领域在这方面远远不如Hadoop一样先进,尽管用的是更简单的软件,组件数量少得多,你肯定很想知道那些 NoSQL人员把大量资金究竟花在了哪里。

文章转载自:扣丁学堂http://www.codingke.com/



回复

使用道具 举报