扣丁学堂浅谈Hadoop/Spark生态圈里的新气象

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与活动目录进行集成。 4、Ranger/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人员把大量资金究竟花在了哪里。 11、Pig 我想这恐怕是Pig最后一年上我的名单。Spark的速度快得多，可以用于许多同样的ETL场合，而Pig Latin(没错，他们就是这么称呼这门语言的)有点怪异，而且常常令人沮丧。正如你想象，在Spark上运行Pig需要费老大的劲。 从理论上来说，在Hive上执行SQL的人可以改用Pig，就像他们过去由SQL改用PL/SQL那样，但事实上，Pig不如PL/SQL来得简单。介于普通SQL和正宗Spark之间的技术可能还有生存余地，但我认为Pig不是这种技术。来自另一个方向的是Apache Nifi，这让你可以做一些同样的ETL，但是少用或不用代码。我们已经使用Kettle减少了编写的ETL代码数量，这相当棒。 12、YARN/ Mesos YARN和Mesos让你能够跨集群执行任务队列和调度操作。每个人都在尝试各种方法：Spark到YARN、Spark到Mesos、Spark 到YARN到Mesos，等等。但要知道，Spark的独立模式对于忙碌的多任务多用户集群来说不是很切实际。如果你不专门使用Spark，仍运行 Hadoop批处理任务，那么眼下就选择YARN。 13、Nifi /Kettle Nifi将不得不竭力避免仅仅是Oozie的改进版。诸多厂商声称Nifi是物联网的解决之道，不过那是营销声势而已。实际上，Nifi好比为 Hadoop与Spring整合。你需要通过转换和队列来管道传输数据，然后按时间表将数据放在某个地方――或者基于触发器，处理来自诸多来源的数据。添加一个漂亮的图形用户界面(GUI)，Nifi就成了。其魅力在于，有人为它编写了一大批的连接件。 如果今天你需要这个，但想要更成熟一点的技术，不妨使用Pentaho公司的Kettle(以及其他相关工具，比如Spoon)。这些工具在生产环境中颇有成效已有一段时间。我们用过它们。坦率地说，它们很不赖。 14、Knox 虽然Knox是很强大的边缘保护机制，但它的作用就是，为用Java编写的反向代理系统提供验证。它不是写得很好;举例说，它掩盖了错误。另外，尽管它使用了URL重写，但仅仅在后面添加一个新服务就需要完整的Java实现。 你需要知道Knox，因为如果有人想要边缘保护，这是提供这种保护的“钦定”方式。坦率地说，要是有小小的修改，或者面向HTTPD的mod_proxy的附件，它会更实用，并提供一系列更广泛的验证选项。 15、Scala/ Python 从技术上来说，你可以用Java 8处理Spark或Hadoop任务。但实际上，支持Java 8是事后添加的功能，那样销售人员可以告诉大公司它们仍可以利用原来的Java开发人员。事实上，Java 8是一门新语言，如果你使用得当的话――在在种情况下，我认为Java 8拙劣地模仿Scala。 尤其是对Spark而言，Java落后于Scala，可能甚至落后于Python。本人其实并不喜欢Python，但它得到了Spark及其他工具相当有力的支持。它还有成熟的代码库;就许多数据科学、机器学习和统计应用而言，它将是首选语言。Scala是Spark的第一选择，也越来越多是其他工具集的第一选择。对于“偏运算”的数据，你可能需要Python或R，因为它们的代码库很强大。 在以上就是小编给大家分享的Hadoop/Spark生态圈里的新气象，希望对小伙伴们有所帮助，想要学习大数据的小伙伴可以登录扣丁学堂官网查询更多内容。扣丁学堂不仅有专业的老师和与时俱进的课程体系，还有大量的大数据在线教程供学员观看学习，扣丁学堂是专业的大数据培训机构。