Hadoop/Spark生态圈里的新气象
Hadoop/Spark生态圈里的新气象
2016-02-18 15:05:15 来源：云头条
抢沙发
2016-02-18 15:05:15 来源：云头条
摘要：Hadoop绝对没有消亡，不过我确信，知名研究机构Gartner的下一篇文章会这么认为。但Hadoop绝不再是原来的Hadoop。现在你需要知道这个新的Hadoop Spark生态圈里面有什么。
关键词：
大数据
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 /KettleNifi
将不得不竭力避免仅仅是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，因为它们的代码库很强大。
记住：如果你用Java 7编写任务，那太傻了。如果使用Java 8，那是由于有人对你老板撒了谎。
16. Zeppelin/ Databricks
大多数人在iPython Notebook中首次碰到的Notebook概念很流行。编写一些SQL或Spark代码以及描述代码的一些标记，添加一个图形，动态执行，然后保存起来，那样别人就能从你的结果获得一些东西。
最终，你的数据被记录并执行，图表很漂亮!
Databricks有良好的开端，自我上一次表示对它腻味以来，其解决方案已经成熟起来。另一方面，Zeppelin是开源的，没必要非得从Databricks购买云服务。你应该知道其中一款这样的工具。学会一款，学另一款不会太费劲。
值得关注的新技术
我还不会将这些技术应用到生产环境，但是一定要了解它们。
Kylin：一些查询需要更低的延迟，于是你一头有HBase;另一头，更庞大的分析查询可能不适合HBase――因此另一头使用 Hive。此外，一再合并几个表来计算结果速度缓慢，所以“预合并”(prejoining)和“预计算”( precalculating)这些数据处理成数据立方(Cube)对这类数据集来说是一大优势。这时候，Kylin有了用武之地。
Kylin是今年的后起之秀。我们已经看到有人将Kylin用于生产环境，不过我建议还是谨慎一点为好。因为Kylin并不适用于一切，其采用也不如Spark来得广泛，但是Kylin也受到同样热烈的追捧。眼下，你对它应该至少了解一点。
Atlas/Navigator：Atlas是Hortonworks新的数据治理工具。它甚至还谈不上完全成熟，不过正取得进展。我预计它可能会超过Cloudera的Navigator，但如果历史重演的话，它会有一个不太花哨的GUI。如果你需要知道某个表的世系，或者没必要逐列(tagging)地映射安全，那么Atlas或Navigator可能正是你需要的工具。如今治理是个热门话题。你应该知道这其中一项新技术的功能。
第三十五届CIO班招生
国际CIO认证培训
首席数据官（CDO）认证培训
责编：pingxiaoli
免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。
