Bigdata

问题描述： 使用hive load hdfs文件时报错： FAILED: Execution Error, return code 3 from org.apache.hadoop.hive.ql.exec.spark.SparkTask. Spark job failed due to task failures: Cannot obtain block length for LocatedBlock{BP-1984322900-192.168.102.3-1594185446267:blk1180034904106295094; getBlockSize()=4179; corrupt=false; offset=0; locs=[DatanodeInfoWithStorage[192.168.102.11:9866,DS-cb5a2e07-20e9-45fd-869b-5d8b4ad170a4,DISK], DatanodeInfoWithStorage[192.168.102.9:9866,DS-74706bce-bb23-4aaf-a6eb-ceaa9bdbf38c,DISK], DatanodeInfoWithStorage[192.168.102.5:9866,DS-57f122fb-b6ca-437c-a52e-5f81efdd239c,DISK]]} 22/02/23 16:31:17 ERROR ql.Driver: FAILED: Execution Error, return code 3 from org.apache.hadoop.hive.ql.exec.spark.SparkTask. Spark job failed due to task failures: Cannot obtain block length for LocatedBlock{BP-1984322900-192.168.102.3-1594185446267:blk1180034904106295094; getBlockSize()=4179; corrupt=false; offset=0; locs=[DatanodeInfoWithStorage[192.168.102.11:9866,DS-cb5a2e07-20e9-45fd-869b-5d8b4ad170a4,DISK], DatanodeInfoWithStorage[192.168.102.9:9866,DS-74706bce-bb23-4aaf-a6eb-ceaa9bdbf38c,DISK], DatanodeInfoWithStorage[192.168.102.5:9866,DS-57f122fb-b6ca-437c-a52e-5f81efdd239c,DISK]]} 分析问题： 可得知hdfs文件块出现异常，Cannot obtain block length for LocatedBlock，无法获取块文件长度信息 因为昨日CDH重启导致hdfs文件未关闭写状态 解决问题： 对hive load hdfs文件的地址执行检查命令 ...

问题：agent启动后跑到一半报错卡死 解决：修改flume_ng启动脚本中jvm参数： vi /opt/cloudera/parcels/CDH/lib/flume-ng/bin/flume-ng 把 JAVA_OPTS="-Xmx20m" 改为 JAVA_OPTS="-Xmx2048m" 重启agent，顺畅running

问题描述：flume采集到hdfs上的文件一直不关闭，有tmp后缀，hive读不到 原配置： # 当前文件写入达到该值时间后触发滚动创建新文件，单位：秒，设置为24小时防止产生小文件 ex_trade_agent.sinks.k1.hdfs.rollInterval = 86400 # 当前文件写入达到该大小后触发滚动创建新文件，单位：字节，设置为128M ex_trade_agent.sinks.k1.hdfs.rollSize = 134217700 # 向 HDFS 写入内容时每次批量操作的 Event 数量 ex_trade_agent.sinks.k1.hdfs.batchSize = 2000 # 不根据 Event 数量来分割文件 ex_trade_agent.sinks.k1.hdfs.rollCount = 0 可以看到只按照128m和24小时来判断是否写新文件，如果两者都不满足那就不关闭临时文件 解决方案： # 当前文件写入达到该值时间后触发滚动创建新文件，单位：秒，设置为4小时防止产生小文件 ex_trade_agent.sinks.k1.hdfs.rollInterval = 14400 # 当非活动文件超过4小时，关闭该文件 ex_trade_agent.sinks.k1.hdfs.idleTimeout = 14400

1.现象 flink任务提交任务虚拟内存不足导致的失败 Container [pid=3007,containerID=container_1599018748796_0004_01_000004] is running 342252032B beyond the 'VIRTUAL' memory limit. Current usage: 416.0 MB of 1 GB physical memory used; 2.4 GB of 2.1 GB virtual memory used. Killing container. 2.原因 因为yarn强制检查虚拟内存是否符合配置导致的，当我们的服务器或者虚拟机的内存达不到配置要求，可能就会报这个错误 。 3.解决 修改检查虚拟内存的属性为false <property> <name>yarn.nodemanager.vmem-check-enabled</name> <value>false</value> </property>

问题: flink的web管理界面在日志过大时无法加载且无法下载 解决: 复制该任务task manager的container编号 container_e01_1675618892497_0264_01_000003 远程登录该task manager所在服务器 使用命令查询进程 ps -ef | grep taskmanager | grep -v "bash -c" |grep container_e01_1675618892497_0264_01_000003 进入该目录 各文件用途 taskmanager.out：业务侧的输出文件，该文件中的内容一般是业务代码中，使用算子的print()方法或者使用java的System.out.print()产生的内容，与前台的taskmanager输出打印内容一致 taskmanager.log就是运行中的taskmanager的日志 taskmanager.err ：taskmanager中出错时候的异常信息 gc.log.x.current：taskmanager的gc日志

在es中数据类型为date： "addTime": { "format": "yyyy-MM-dd HH:mm:ss", "type": "date" } 在hive建映射表 CREATE EXTERNAL TABLE hive_es.cty_test1( addTime date ) STORED BY 'org.elasticsearch.hadoop.hive.EsStorageHandler' TBLPROPERTIES('es.resource' = 'cty_test/cty_test', 'es.nodes'='172.16.98.113,172.16.98.149,172.16.98.150,172.16.98.151,172.16.98.152', 'es.port'='9200', 'es.mapping.names'= 'addTime:addTime', 'es.date.format'='yyyy-MM-dd HH:mm:ss', 'es.index.auto.create'='false', ) 查询报错： 更改hive表数据类型为string CREATE EXTERNAL TABLE hive_es.cty_test5( addTime string ) STORED BY 'org.elasticsearch.hadoop.hive.EsStorageHandler' TBLPROPERTIES('es.resource' = 'cty_test/cty_test', 'es.nodes'='172.16.98.113,172.16.98.149,172.16.98.150,172.16.98.151,172.16.98.152', 'es.port'='9200', 'es.mapping.names'= 'addTime:addTime', 'es.date.format'='yyyy-MM-dd HH:mm:ss', 'es.index.auto.create'='false', ) 查询继续报错： 查阅资料： elasticsearch-hadoop中用于将ES中的日期转换为Hive中的日期格式的类为org.elasticsearch.hadoop.hive.HiveValueReader，通过查看该类的源码，其实现的用户日期转换的方法为： @Override protected Object parseDate(String value, boolean richDate) { return (richDate ? new TimestampWritable(new Timestamp(DatatypeConverter.parseDateTime(value).getTimeInMillis())) : parseString(value)); } 可以看到它是通过javax.xml.bind.DatatypeConverter.parseDateTime(String)方法将对应的日期字符串转换为日期的，该方法不支持的日期字符串格式为“yyyy-MM-dd HH:mm:ss”的字符串，它支持的日期字符串的格式为“yyyy-MM-ddTHH:mm:ss”这样的。 解决方案： 在建表时设置参数’es.mapping.date.rich’=‘false’，然后hive字段类型设为string。 官方解释： Whether to create a rich Date like object for Date fields in Elasticsearch or returned them as primitives (String or long). By default this is true. The actual object type is based on the library used; noteable exception being Map/Reduce which provides no built-in Date object and as such LongWritable and Text are returned regardless of this setting. ...

一个sql节点只能写一条sql且结尾不能写分号 使用sql节点时由于dolohin写了hive的预编译，某些时候变量不能正确传入，比如 location ‘xxxxx${变量名}’,在预编译过程中会直接变成 location ‘xxxxx?’ **解决方案：**把sql节点替换成shell节点用hive -e ‘………….. location ‘xxxxx${变量名}’来实现变量传参 节点开启非严格模式，从节点偶尔会失效 **解决方案：**每个需要动态分区的sql都加上设置非严格模式的前置sql sql节点无法使用hive永久注册的udf **解决方案：**在dolphin资源中心上传udf并创建（会注册成临时udf） sql节点使用 REPLACE函数会有bug，导致任务流无法保存 **解决方案：**使用REGEXP_REPLACE函数 sql节点添加扩展jar包，无法使用本地路径 **解决方案：**需要先上传jar到hdfs，然后加上hdfs://nameservice1/前缀

1.zookeeper刚启动时会报错，晾它两分钟会就好了 2.更改或迁移服务时一定要切换到维护模式并停止当前服务！！！ 3.cdh01的hadoop组件起不来，原因是一些文件夹的权限问题，更改权限并且更改拥有者及组（参照其他服务器） 4.内存不足主要因为NodeManager内存调的太高，调小即可（个人经验，5台机器可用内存和为30*4+20=160G，可同时对20G的数据做处理，感觉够用了） 5.oozie报错：Failed to install Oozie ShareLib，这个问题是cdh6.2的通病，只要安装oozie就会 出现(无论是升级，还是新装。 解决： cd /opt/cloudera/parcels/CDH/lib/oozie/libtools ln -s ../../../jars/logredactor-2.0.7.jar logredactor-2.0.7.jar 执行完后重启oozie。 6.oozie端口号11000冲突，改为11002 7.从节点不要提前安装agent服务！！！直接在web界面安装！ 8.把CM和CDH装好后面就轻松多了 9.==主机名不要出现下划线!==

1.指标字典 指标字典，是业务数据标准化的基础，目的是对指标进行统一管理，方便共享达成对业务指标的共识，并且统一修改和维护。指标字典可以更新在 Excel或者Wiki中。如果有足够多的资源，那么开发指标管理模块可以放在数据管理系统中再配合血缘关系，就可以很方便追踪数据流转了。 1.1设计指标字典的主要目的： (1)规范维度和量度命名，命名规则要尽量做到明确、通用、易懂。 (2)对维度或量度统一计算口径，避免岐义。 (3)涵盖尽可能多的关注的核心维度和量度，以此为基础推动数据建设，确保指标字典里覆盖的维度都可区分、指标都可统计 (4)基于指标字典，将核心维度和量度注入元数据中心，接入指标提取工具，后续实现不需要写QL语句即可完成自査询及分析需求 指标字典的建立，是搭建数据平台的基础。 1.2指标、量度和维度的相关概念 1.2.1 指标: 定义：衡量目标的方法 构成要素：维度+汇总方式+量度 （1）维度=哪些角度去看问题 （2）汇总方式=哪些方法衡量问题 （3）量度=目标是什么问题 1.2.2 维度： 定义：看问题的角度和方向，例如我要从年份看毛衣的销量，那么年份就是我看问题的角度 1.2.3 量度： 定义：对一个物理量的测定，通常数字+计算单位表示。例如，金额，次数，率 1.3 指标定义规范 1.3.1怎么定义一个合格的指标字典？需要遵守什么规范？ 一个指标一经录入，它的命名和所有下钻维度的口径都已确定(默认口径)，这称为指标的一义性。 例如，“交易额”这个指标默认的时间口径是：支付时间，默认的城市口径是：下单所在城市等。 如果需要按下单时间口径看订单金额，我们定义了一个新的指标“下单交易额”。一个在某些维度上口径不确定的“指标”是不能被使用的，在业务场景中是毫无意义的。 1.3.2指标一般分为基础指标、普通指标和计算指标三类。 1.3.2.1基础指标 例如，“交易额”作为一个基于单纯实体的属性的简单计算，它没有更上游的指标，即它的父指标是它自身。我们称这样的指标为基础指标。 1.3.2.2.普通指标 所谓普通指标，即在单一父指标的基础上通过一些维度上的取值限定可以定义的指标。 例如，对于购买中PC端首次购买用户数，限制条件为首次购买用户中下单平台＝PC。 1.3.2.3.计算指标 可以在若干个注册指标之上通过四则运算、排序、累计或汇总定义出的指标称为计算指标。 1.4量度和维度都考虑好了，在构建一个指标字典时我们应该考虑哪些要素呢? 1.4.1指标字典要素如下： 1.4.2通常指标字典包含指标维度和指标量度两个部分，如下： 总结： 通过上面的步骤和方法，根据自身业务情况，建立一个指标字典。 指标字典在建立知乎，要经过各个业务产品经理的评审，纠正错误不明或者有歧义的指标，在达成一致后，由数据产品推广，共大家参考使用。 好的指标字典就像二叉树一样，从单维度，粗糙维度分析，再细拆维度。看问题需要：由大到小，由内到外。

在大数据平台运维中，会经常遇到集群资源争抢的问题。因为在公司内部，Hadoop Yarn 集群一般会被多个业务、多个用户同时使用，共享 Yarn 资源。此时，如果不对集群资源做规划和管理的话，那么就会出现 Yarn 的资源被某一个用户提交的 Application（App）占满，而其他用户只能等待；或者也可能会出现集群还有很多剩余资源，但 App 就是无法使用的情况。 如何解决这个问题呢？此时就需要用到 Hadoop 中提供的资源调度器。 Yarn 多用户资源管理策略 Yarn 提供了可插拔的资源调度算法，用于解决 App 之间资源竞争的问题。在 Yarn 中有三种资源调度器可供选择，即 FIFO Scheduler、Capacity Scheduler、Fair Scheduler，目前使用比较多的是 Fair Scheduler 和 Capacity Scheduler。下面对这三种资源调度器分别进行介绍。 1. FIFO Scheduler 在 Hadoop 1.x 系列版本中，默认使用的调度器是 FIFO，它采用队列方式将每个任务按照时间先后顺序进行服务。比如排在最前面的任务需要若干 Map Task 和 Reduce Task，当发现有空闲的服务器节点时就分配给这个任务，直到任务执行完毕。 2. Capacity Scheduler 在 Hadoop 2.x/3.x 系列版本中，默认使用的调度器是 Capacity Scheduler（容量调度器），这是一种多用户、多队列的资源调度器。每个队列可以配置资源量，可限制每个用户、每个队列的并发运行作业量，也可限制每个作业使用的内存量；每个用户的作业有优先级，在单个队列中，作业按照先来先服务（实际上是先按照优先级，优先级相同的再按照作业提交时间）的原则进行调度。 容量资源调度器，支持多队列，但默认情况下只有 root.default 这一个队列。 当不同用户提交任务时，任务都会在这个队列里按照先进先出策略执行调度，很明显，单个队列会大大降低多用户的资源使用率。 因此，要使用容量资源调度，一定要配置多个队列，每个队列可配置一定比率的资源量（CPU、内存）；同时为了防止同一个用户的任务独占队列的所有资源，调度器会对同一个用户提交的任务所占资源量进行限定。 举个简单的例子，下图是容量调度器中配置好的一个队列树： 上图通过队列树方式对 Yarn 集群资源做了一个划分，可以看到，在 root 队列下面定义了两个子队列 dev 和 test，分别占 30% 和 70% 的 Yarn 集群资源；而 dev 队列又被分成了 dev1 和 dev2 两个子队列，分别占用 dev 队列 30% 中的 40% 和 60% 的 Yarn 集群资源。 ...