概述
Hadoop Archive是Hadoop官方提供的解决HDFS上小文件过多的一种方案。可以通过如下命令来执行生成har文件:
|
1 |
hadoop archive -archiveName foo.har -p /user/hadoop -r 3 dir1 dir2 /user/zoo |
执行archive命令会提交一个MapReduce任务来生成har文件。在了解har文件…
Hadoop Archive是Hadoop官方提供的解决HDFS上小文件过多的一种方案。可以通过如下命令来执行生成har文件:
|
1 |
hadoop archive -archiveName foo.har -p /user/hadoop -r 3 dir1 dir2 /user/zoo |
执行archive命令会提交一个MapReduce任务来生成har文件。在了解har文件…
前两天又接了一个Spark任务,倒不复杂,依然是检索HDFS上的日志数据这样的事情。不过瞅着组内跑着十几二十个任务内存一共只有160来G的yarn集群,有些欲哭无泪。
事情还是要做的,反正执行时间要求不太严格,只能想办法尽量压缩内存的占用了。
先说下背景:现在使用的yarn集群由8个容器组成,每个容器的内存大概20G;工作内容是检索数据,源数据大概1T左右,取出…
工作中需要通过Spark以csv格式导出日志文件。实现功能不太复杂,但是在中文识别上遇到了些问题。
解决csv文件中的乱码最直接的思路就是添加BOM,这样Excel在打开Excel的时候就知道使用什么样的编码来解析这篇文档了。
先写了段测试代码验证了下:
|
1 2 3 4 5 6 7 |
val bom = Array(0xEF, 0xBB, 0xBF).ma |
最近的工作有很大一部分是在做用户画像。
画像读取的维度bitmap动辄几百MB,甚至存在部分GB级别的。而我们的Yarn集群规模比较小,内存总计只有100多GB。开发调试时遇到最多的问题除了Task not serializable就是heap out of memeory了。
我们使用的Spark版本是1.6.3。yarn集群使用的jdk版本是1.7。
如何解决堆内存溢出…
这一节将主要介绍资源调优,或者说是如何充分利用集群资源。然后再说一下如何对并发度进行优化,这是job性能参数中最难也是最重要的部分。最后我们将了解一些数据自身的表现形式:Spark读取时数据在磁盘上的保存形式(如Apache Avro和 Apache Parquet),以及缓存时或系统内移动时数据在内存中的形式。
在Spark的用户反馈中经常提到一类问题…
在开始写spark代码或者翻阅spark文档的时候,会遇到一些诸如“transformation”,“action”和“RDD”这样的术语。了解这些术语对于编写spark代码是至关重要的。
类似的,当写的spark程序执行失败的时候或者尝试通过Spark WebUI来研究提交的应用为什么执行时间过长的时候,可能会遇到另外一些术语,如“job”、“stage”和“…
在工作中使用spark的一个主要内容就是从多个路径下搜集数据并进行处理。常用的代码大致如下:
|
1 2 3 |
val paths = obtainPaths() val rdd = paths.map(readData).reduce(_ ++ _) & |
前段时间终于无法忍受sbt慢如龟速的编译打包速度了。稍稍调研了一下,就果断切换到了gradle。由于调研得比较匆忙,在使用过程中遇到了各种问题。好在最后都能解决了。
我这里使用scala主要是用来编写spark job。由于我自己的一些需要,这些job中有几个是多模块的。在这里简单解释一下如何使用gradle构建scala多模块项目。
这里用我最近开发的项目来做说…
运行spark任务消费kafka时,报了如下的异常:
|
1 2 3 4 5 6 7 8 |
java.lang.NoSuchMethodError: scala.Predef$.ArrowAssoc(Ljava/lang/Object;)Ljava/lang/Object; at kafka.consumer.FetchRequestAndResponseMetrics.< |
这里介绍一个在Spark上使用自定义RDD获取HBase数据的方案。
这个方案的基础是我们的HBase表的行键设计。行键设计大概是这样子的:标签ID+时间戳+随机码。平时的需求主要是导出指定标签在某个时间范围内的全部记录。根据需求和行键设计确定下实现的大方向:使用行键中的时间戳进行partition并界定startRow和stopRow来缩小查询范围,使用HB…