Hadoop,开发者纠结的十件事

简介:

开源数据处理平台Hadoop在大数据时代的今天有着非常广泛的应用。著名的大象图标遍布各行各业,从医疗记录到银行交易,从车票预定到房屋租赁,乃至很多科学数据处理,都可以见到Hadoop的身影。

在Hadoop生态繁荣的背后,是开发者们夜以继日的开发与支持。而在用户得益甚至赞赏这些应用的时候,开发者们却不得不面对Hadoop平台中一些可用性较差的地方。本文列举了网络上一些关于Hadoop的缺点,供大家探讨,部分观点来自InfoWorld及开发者博客。

1、 平台尚未成熟

虽然用途广泛,但不得不承认的是,Hadoop目前仍在开发阶段。很多数据结构都不全,比如Hadoop一直不支持原生datatime数据类型,最近才在时间序列数据开发者的强烈建议下下引入此数据类型。其次,技术支持并不到位,无论是Google还是Stack Overflow上寻找的答案,都不足以解决开发者遇到的问题。

2、 数据模式模糊不清

Hadoop目前对模式(Schema)的描述并不清晰,很多开发者在撰写Pig脚本的过程中,会花费超过50%的时间在调试对Schema的支持上。

3、 Pig和Hive无法互通

Hive和Pig用起来完全是两个东西。熟悉SQL的开发者可以在Hive中使用类似的脚本,但是在Pig中却不得不重新学习其语法。在Pig中无法使用Hive的UDFS,也无法使用HCatalog访问Pig的Hive表。反过来,无法在Hive中使用Pig的UDFS。这让开发者在两者切换使用的过程中颇为纠结,需要耗费精力重新撰写脚本来完成已有的工作。

4、 HDFS存储共享函数库

鉴于Hadoop的复用机制,一旦开发者将Pig脚本保存于HDFS,那么Hadoop将自动认为所有的JAR包的存储方式都应如此。通常情况下,这样的做法并无问题,但是有时候,当一个项目需要维护大量共享库的时候,这就变得非常复杂。而且,大部分时间JAR包通常都在安装客户端的时候一并安装过,Hadoop这种存储方式使得JAR包多次存储。据悉,脚本存储的问题Pig新版本已修正,但是共享函数库存储的问题却仍然存在。

5、 报错信息不完整

这几乎是Hadoop系列工具的通病,经常在出了问题的时候,返回一个“运行失败,无更多错误信息”这样的报错提示,使得开发者无法进行更进一步的错误调试。还有,Hadoop经常会抛出一些无法找到指针的异常(NPE),而这些问题则是由文件解析之类的操作造成,并不能属于NPE范畴。另外,由于采用UDFS,导致很多报错最终以udf执行错误的样子呈现给开发者,而它们可能仅仅是语法错误或者类型错误。

6、 不兼容的安全机制

开发者经常会听到这样的说法:“已经有足够多的案例证明,想要保证Hadoop的安全性,建议使用Kerberos,LDAP直白易用。”但是现状就是,Hadoop平台并未对此有友好的集成:没有SAML、没有OAuth,也没有很好的安全验证机制(开发者只能时不时的无奈面对再一次出现的登录窗口)。更有意思的是,Hadoop平台中很多组件都自己支持LDAP,且彼此不考虑兼容性。

7、 难以开发的LDAP连接器

对开发者来讲,用Java成功完成一个能用的LDAP连接器,至少需要修改上百次代码。而反过来看看完成的代码,连接器的功能还不完善。实际上,开发者们能感觉出Knox有点像一时冲动的产物。毕竟用Apache配置mod_rewrite模块就能完成的事情,非要用Java再写一遍,的确是让开发者头痛的事情。

8、 难以扩展的Hive表管理

如果开发者使用Hive进行表管理的话,在Hive执行了drop表命令后,会自动将表删除。但是如果这个表是外部的话,则不会自动删除。为什么Hive不能将这两个表同样对待呢?此外,既然Hive现在有向RDBMS发展的趋势,为什么不增加Update和Delete?

9、 不兼容的Namenode

Hadoop的很多组件,如Oozie、Knox等,都不遵循新的Namenode HA。开发者可以做一个HA Hadoop,前提是他完全不想使用其他组件。

10、 出错的文档

Hadoop的文档存在很多问题,开发者经常会发现文档的示例代码中有问题,有一些文档本身都没有遵循Hadoop的模式设计。鉴于这些文档在互联网上流传广泛,应该有相当一批人学习并尝试,因此都会遇到并纠结于这些错误。实际上,有些错误是完全可以避免的,只要文档的撰写人在完成文档的同时,自己动手运行一下示例代码。比如Oozie文档中充斥着大量过去版本的样例代码,开发者遇到错误的时候,很可能不是自己程序写错了,而是由于Oozie版本更替而导致之前教程中的函数不兼容造成,比如协议问题、模式有效性问题等等。有人形容Oozie,称其类似Ant和Maven,只是没有任何调试手段,而且代码非常善变。

此外,在Hadoop平台的适用范围方面,它对实时数据访问支持并不好,也无法高效存储大量小文件,而且目前尚不支持多用户。

目录
相关文章
|
存储 分布式计算 Hadoop
|
分布式计算 Hadoop 数据库
|
分布式计算 大数据 Hadoop
|
分布式计算 Hadoop Linux
Hadoop开发者入门专刊
全文下载:http://ishare.iask.sina.com.cn/f/6740538.html 目录 1 Hadoop介绍 2 Hadoop在国内应用情况 3 Hadoop源代码eclipse编译教程 7 在Windows上安装Hadoop教程 13 在Linux上安装H...
844 0
|
分布式计算 Java Hadoop
hadoop开发者第二期
全文下载:http://ishare.iask.sina.com.cn/f/7401946.html 目录 1、Hadoop 业界资讯.......................
779 0
|
分布式计算 Java Hadoop
Hadoop开发者第四期
全文下载:http://ishare.iask.sina.com.cn/f/14487230.html 目录 mooon 1 海量数据处理平台架构演变 4 计算不均衡问题在Hive中的解决办法 15 Join算子在Hadoop中的实现 20 配置Hive元数据DB为Postg...
803 0
|
分布式计算 Hadoop 数据库
hadoop开发者第三期
全文下载: hadoop开发者第三期.pdf    目录 Hadoop中的数据库访问 MapReduce中多文件输出的使用 ZooKeeper使用与分析 浅析一种分类数据模型 Sector框架分析 RunonHadoop ...
659 0
|
1月前
|
分布式计算 Kubernetes Hadoop
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
大数据-82 Spark 集群模式启动、集群架构、集群管理器 Spark的HelloWorld + Hadoop + HDFS
162 6
|
1月前
|
分布式计算 资源调度 Hadoop
大数据-80 Spark 简要概述 系统架构 部署模式 与Hadoop MapReduce对比
大数据-80 Spark 简要概述 系统架构 部署模式 与Hadoop MapReduce对比
66 2
|
24天前
|
存储 分布式计算 Hadoop
数据湖技术:Hadoop与Spark在大数据处理中的协同作用
【10月更文挑战第27天】在大数据时代,数据湖技术凭借其灵活性和成本效益成为企业存储和分析大规模异构数据的首选。Hadoop和Spark作为数据湖技术的核心组件,通过HDFS存储数据和Spark进行高效计算,实现了数据处理的优化。本文探讨了Hadoop与Spark的最佳实践,包括数据存储、处理、安全和可视化等方面,展示了它们在实际应用中的协同效应。
83 2
下一篇
无影云桌面