尤其需要注意的是Files、Mapper和Reducer这三个属性中路径的写法,只有这样MR任务才能成功执行。不要问我怎么知道的,说多了都是泪。
运行任务提交程序,当看到控制台如下输出时表示任务已经成功提交并执行完毕。
否则,控制台会输出错误。
下面总结一下楼主遇到的错误以及MR任务查找错误原因的方法。
查找错误原因,可以访问ResourceManager管理界面(地址一般为headnode:8088),在界面中找到最近出错的任务,如下图:
点击进入任务详情界面:
点击“任务历史”链接进入HistoryServer的UI界面:
在任务历史中,点击图片中标出的Url,可以进入失败的Map或Reduce任务的列表界面:
点击Logs链接可以看到任务的详情,从中一定可以找到任务失败的原因。
下面两图就是楼主因为在SubmitMRJob方法中没有以正确的方式填充Files属性所报的错。
当时,楼主将.NET Core程序所输出的每个文件作为Files属性数组的一条进行提交,导致如图,程序文件被传到Blob后被放在不同的临时目录中,从而导致运行程序失败。
另外楼主遇到的问题还包括,目前Azure HDInsight预装的.NET Core版本较低(1.0.1),而使用VS2017来生成.NETCore App,即使所选的Target Framework为netcoreapp1.0,生成出来的程序也是1.0.4版,直接放到集群的主机上执行会报如下错误。
在使用Hadoop执行前,先直接执行下程序看看是否可以正确启动运行是一种很好的排除错误保证成功率的方法。
The specified framework 'Microsoft.NETCore.App', version '1.0.4' was not found.
/usr/share/dotnet/shared/Microsoft.NETCore.App
1.0.1
上面的报错可以清楚的了解到,HDInsight集群的主机安装了.NETCore但是版本只有1.0.1,而VS2017生成的.NETCore App至少需要1.0.4版本的运行时。
按照的说明,卸载旧版并安装新版。安装后继续测试程序是否可以在shell里直接运行知道成功。
特别注意,我们需要在实际干活的结点,即NodeManager运行的结点,安装适当的.NET Core,因为这些结点是实际运行.NET Core程序的结点。参考前文图片,这些结点以wn开头,我们可以在建立隧道后通过IP ssh到这些主机并安装.NET Core以及测试。
如果不方便使用Azure HDInsight,来进行测试,使用HDP沙盒也同样可以。
唯一不便的就是不能使用Microsoft.Azure.Management.HDInsight.Job来方便的提交任务,而需要自行使用hadoop CLI来完成,但这对于我们测试.NET Core编写的业务逻辑没有影响。
关于这个话题详见这篇博文。
微软4月份更新版的Azure在线文档中介绍了使用Mono在基于Linux的HDP集群上运行C#编写的MapReduce的方法,具体文章链接(这个连接可能在将来随时发生变化)。
最后本文及后续文章都是对于将微软技术用于大数据可能性的一种探讨,欢迎大家一起讨论。
本文示例相关示例在此
posted @