Bigdata on LeoChu Space

HDFS更改数据目录导致NameNode无法启动

Thu, 26 Mar 2026 00:00:00 +0000

20260326 HDFS更改数据目录导致NameNode无法启动

问题描述：

由于一开始硬盘还未挂载目录，安装cdh时，配置hdfs相关数据目录就用了默认的系统盘下的目录，如下

/data/dfs/nn /data/dfs/jn /data/dfs/dn

后面数据盘挂载在/hadoop/data1/下，固将hdfs的数据目录改为

/hadoop/data1/dfs/nn /hadoop/data1/dfs/jn /hadoop/data1/dfs/dn

重新启动hdfs，报错，分为三类：

nameNode 无法格式化
丢失块信息100%
Cloudera Manager 无法检测 HDFS 健康状态

解决：

停掉hdfs所有服务
清空/hadoop/data1/dfs/nn /hadoop/data1/dfs/jn /hadoop/data1/dfs/dn
启动dataNode，failoverController 等服务（除NameNode，journalNode外）
对activity NameNode执行format操作
启动所有journalNode
启动activity NameNode
对Standby NameNode执行Bootstrap Standby操作
启动Standby NameNode
ssh客户端以hdfs用户执行hdfs dfs -chmod -R 777 /data/tmp 等命令,完成以下目录创建及赋权,后续通过ranger做权限收口

[hdfs@cdhmaster02 ~]$ hdfs dfs -ls Found 3 items
drwxrwxrwt   - hdfs supergroup          0 2026-03-26 12:31 /data
drwxrwxrwt   - hdfs supergroup          0 2026-03-26 17:25 /tmp
drwxr-xr-x   - hdfs supergroup          0 2026-03-26 17:24 /user

注意事项：

操作顺序不可颠倒，否则可能导致 NameNode 或 JournalNode 数据不一致
不能对 Standby NameNode 执行 format，否则会破坏 HA 集群
**(重要)**清空目录操作仅限于尚未存储业务数据的集群或测试环境
如果要迁移已有数据的数据目录，则需要rsync -avh /data/dfs/nn/ /hadoop/data1/dfs/nn/类似命令

原因解释：

NameNode 无法格式化
- HDFS 的 HA 模式下，Active NameNode 的元数据（fsimage + edits）必须与 Quorum Journal Nodes 保持一致。
- 修改 HDFS 存储目录后，如果 JournalNode 目录仍保留旧数据或未初始化，NameNode 在检查 quorum 时会发现元数据不匹配，因此无法格式化。
- 关键点：只允许对 Active NameNode 格式化，Standby NameNode 或 JournalNode 不能直接 format，否则会破坏 HA 的一致性机制。
丢失块信息 100%
- DataNode 存储目录修改后，旧数据无法被 NameNode 正确识别，因为 NameNode 的 fsimage 中没有对应块信息。
- NameNode 启动时会扫描 DataNode 上报的块，如果目录未初始化或数据不匹配，则所有块都被标记为丢失，从而导致 CM 显示 100% missing blocks。
- 关键点：HDFS 的块映射严格依赖 NameNode 的元数据，DataNode 目录未同步会造成“逻辑丢失”，即使物理数据存在。
Cloudera Manager 无法检测 HDFS
- CM Canary 测试依赖基本的 HDFS I/O 操作（创建、写入、读取、删除文件）。
- 当 NameNode 在安全模式或丢失块状态下，读写请求无法完成，Canary 测试失败，导致 CM 显示健康异常。
- 关键点：CM 健康检测反映的是 NameNode 和 DataNode 的可用性与一致性，而非磁盘本身状态。
操作顺序要求严格
- Active NameNode 必须先格式化并启动，使元数据初始化完成。
- JournalNode 启动后才能形成 Quorum，保证 HA 的 edit log 复制。
- Standby NameNode 只能通过 Bootstrap Standby 从 Active NameNode 同步元数据，否则会破坏 HA 的一致性，导致集群无法启动。
- 关键点：HDFS HA 的核心机制是 edit log 的 quorum 写入与 NameNode 状态同步，顺序错误会导致集群不可用。

PostgreSQL同步HDFS

Thu, 12 Feb 2026 00:00:00 +0000

1.使用datax同步数据

2.模板json(已配置hdfs ha)：

{
    "job": {
        "content": [
            {
                "reader": {
                    "name": "postgresqlreader",
                    "parameter": {
                        "username": "hs_sync",
                        "password": "Pass2025",
                        "column": [
                            "order_date",
                            "day",
                            "iso_day_of_week",
                            "weekday_cn",
                            "weekday_en",
                            "weekday_short",
                            "is_weekend",
                            "iso_week",
                            "month",
                            "month_cn",
                            "month_en_full",
                            "month_en_short",
                            "quarter",
                            "year"
                        ],
                        "connection": [
                            {
                                "table": [
                                    "dim_calendar"
                                ],
                                "jdbcUrl": [
                                    "jdbc:postgresql://100.64.0.10:25432/hs_sync_data"
                                ]
                            }
                        ],
                        "fetchSize": 1000
                    }
                },
                "writer": {
                    "name": "hdfswriter",
                    "parameter": {
                        "defaultFS": "hdfs://nameservice1",
                        "hadoopConfig": {
                            "dfs.nameservices": "nameservice1",
                            "dfs.ha.namenodes.nameservice1": "nn1,nn2",
                            "dfs.namenode.rpc-address.nameservice1.nn1": "192.168.33.61:8020",
                            "dfs.namenode.rpc-address.nameservice1.nn2": "192.168.33.62:8020",
                            "dfs.client.failover.proxy.provider.nameservice1": "org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider"
                        },
                        "fileType": "orc",
                        "path": "/tmp/data/test/",
                        "fileName": "dim_calendar",
                        "writeMode": "truncate",
                        "column": [
                            {
                                "name": "order_date",
                                "type": "date"
                            },
                            {
                                "name": "day",
                                "type": "smallint"
                            },
                            {
                                "name": "iso_day_of_week",
                                "type": "smallint"
                            },
                            {
                                "name": "weekday_cn",
                                "type": "string"
                            },
                            {
                                "name": "weekday_en",
                                "type": "string"
                            },
                            {
                                "name": "weekday_short",
                                "type": "string"
                            },
                            {
                                "name": "is_weekend",
                                "type": "boolean"
                            },
                            {
                                "name": "iso_week",
                                "type": "smallint"
                            },
                            {
                                "name": "month",
                                "type": "smallint"
                            },
                            {
                                "name": "month_cn",
                                "type": "string"
                            },
                            {
                                "name": "month_en_full",
                                "type": "string"
                            },
                            {
                                "name": "month_en_short",
                                "type": "string"
                            },
                            {
                                "name": "quarter",
                                "type": "string"
                            },
                            {
                                "name": "year",
                                "type": "smallint"
                            }
                        ],
                        "fieldDelimiter": "\t",
                        "maxFileSize": 134217728,
                        "encoding": "UTF-8"
                    }
                }
            }
        ],
        "setting": {
            "speed": {
                "channel": 5
            },
            "errorLimit": {
                "record": 0,
                "percentage": 0.02
            },
            "retry": {
                "limit": 3,
                "interval": 5000
            }
        }
    }
}

CDH基础配置及优化

Sun, 01 Feb 2026 00:00:00 +0000

一、hive中文注释乱码

1、设置 hive 元数据库字符集

show create database hive;

查看为 utf8，需变更为 latin1

alter database hive character set latin1;

2、更改如下表字段为字符集编码为 utf8

①修改表字段注解和表注解
alter table COLUMNS_V2 modify column COMMENT varchar(256) character set utf8;
alter table TABLE_PARAMS modify column PARAM_VALUE varchar(4000) character set utf8;
② 修改分区字段注解：
alter table PARTITION_PARAMS modify column PARAM_VALUE varchar(4000) character set utf8 ;
alter table PARTITION_KEYS modify column PKEY_COMMENT varchar(4000) character set utf8;
③修改索引注解：
alter table INDEX_PARAMS modify column PARAM_VALUE varchar(4000) character set utf8;

linux系统级优化

Sat, 31 Jan 2026 00:00:00 +0000

一、在cdh+cm部署时，已经做了部分系统优化

ssh双向免密
配置时间同步服务（本次没用ntpd，用的是chrony）
禁用透明大页、碎片整理：THP (Transparent Huge Pages)
禁用内存交换swap（常用0或1）

二、hadoop集群推荐内核参数：

参数名称	默认值	说明
文件系统参数
`fs.file-max`	6815744	系统最大文件描述符数量（所有进程可打开文件总数上限）
`fs.aio-max-nr`	1048576	异步I/O请求的最大并发数（影响高并发场景性能）
网络核心参数
`net.core.rmem_default`	262144	TCP接收缓冲区默认大小（256KB）
`net.core.wmem_default`	262144	TCP发送缓冲区默认大小（256KB）
`net.core.rmem_max`	16777216	TCP接收缓冲区最大允许值（16MB）
`net.core.wmem_max`	16777216	TCP发送缓冲区最大允许值（16MB）
TCP协议栈参数
`net.ipv4.tcp_rmem`	4096 262144 16777216	接收窗口尺寸：• 最小值4KB• 默认值256KB• 最大值16MB
`net.ipv4.tcp_wmem`	4096 262144 16777216	发送窗口尺寸：• 最小值4KB• 默认值256KB• 最大值16MB

查看当前内核配置：

sysctl -e fs.file-max fs.aio-max-nr \
 net.core.rmem_default net.core.wmem_default \
 net.core.rmem_max net.core.wmem_max \
 net.ipv4.tcp_rmem net.ipv4.tcp_wmem 2>/dev/nulll

CDH6.3.2集群部署

Fri, 30 Jan 2026 00:00:00 +0000

使用ansible做自动化部署

CDH 集群安装指南

环境准备

项目	值
NFS 服务器	xxx.xxx.xxx.xxx:/nfs/share
Inventory	inventory/cdh-init.ini

安装步骤

步骤 1：配置 /etc/hosts 和挂载 NFS

ansible-playbook cdh-hosts-nfs.yml -i inventory/cdh-init.ini

步骤 2：系统初始化

ansible-playbook cdh-init-raw.yaml -i inventory/cdh-init.ini

验证

# 验证 NFS 挂载
ansible cdh_all -i inventory/cdh-init.ini -m shell -a "ls /mnt" -b

# 验证 Java
ansible cdh_all -i inventory/cdh-init.ini -m shell -a "java -version"

# 验证 SELinux
ansible cdh_all -i inventory/cdh-init.ini -m shell -a "sestatus"

# 验证 haveged
ansible cdh_all -i inventory/cdh-init.ini -m shell -a "systemctl status haveged"

安装介质目录

/mnt/
├── cdh/                    # CDH Parcel
├── ClouderaManager/        # CM 6.3.1
└── mysql/                  # MySQL 5.7 RPM

spark参数num-executors未生效

Sat, 23 Nov 2024 00:00:00 +0000

问题：

spark-submit --master yarn --conf spark.default.parallelism=100 \
--deploy-mode cluster --driver-memory 4G --executor-memory 4G \
--num-executors 40 --executor-cores 2 \
--conf spark.yarn.executor.memoryOverhead=5g \
--class com.lz.hbase.CompanyInfo /tmp/test_langzi/original-spark_hbase01-1.0-SNAPSHOT.jar

以上提交参数中的–num-executors 40没有生效，executors 大于40并且占满yarn资源，导致后来的yarn任务阻塞

原因：

官方参数解释

–num-executors NUM Number of executors to launch (Default: 2). If dynamic allocation is enabled, the initial number of executors will be at least NUM.

当开启动态分配时，num-executors成为了最小executors 数，而cdh中spark默认开启dynamic allocation，所以当yarn队列资源空闲时，真正的excutor数会大于设置的num-executors

解决方案：

提交参数添加--conf spark.dynamicAllocation.maxExecutors=40 限制最大excutor数

附：spark提交任务模板

spark-submit --master yarn --conf spark.default.parallelism=100 \

--conf spark.dynamicAllocation.maxExecutors=40\
--deploy-mode cluster --driver-memory 4G --executor-memory 4G \
--num-executors 40 --executor-cores 3 \
--conf spark.yarn.executor.memoryOverhead=4G \
--class com.lz.hbase.CompanyInfo /tmp/test_langzi/original-spark_hbase01-1.0-SNAPSHOT.jar

maven打包去除dependency-reduced-pom.xml文件

Sat, 09 Nov 2024 00:00:00 +0000

标签	#maven
场景	工作
时间	2023年2月14日17:58:09

一、问题描述

每次打包的时候，项目目录会多出一个莫名的文件dependency-reduced-pom.xml

二、导致原因

maven打包插件maven-shade-plugin打包时自动生成，createDependencyReducedPom默认为true。

dependency-reduced-pom.xml 删除了已经在你的着色 jar 中的传递依赖项。这可以防止消费者两次拉他们，从而避免无用的重复。

三、解决方案

添加以下配置

<configuration>
      <createDependencyReducedPom>false</createDependencyReducedPom>
</configuration>

如：

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <version>3.1.1</version>
    <configuration>
        <createDependencyReducedPom>false</createDependencyReducedPom>
    </configuration>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <artifactSet>
                    <excludes>
                        <exclude>org.slf4j:*</exclude>
                        <exclude>log4j:*</exclude>
                        <exclude>ch.qos.logback:*</exclude>
                        <exclude>com.google.code.findbugs:jsr305</exclude>
                    </excludes>
                </artifactSet>
                <filters>
                    <filter>
                        <!-- Do not copy the signatures in the META-INF folder.
                        Otherwise, this might cause SecurityExceptions when using the JAR. -->
                        <artifact>*:*</artifact>
                        <excludes>
                            <exclude>META-INF/*.SF</exclude>
                            <exclude>META-INF/*.DSA</exclude>
                            <exclude>META-INF/*.RSA</exclude>
                        </excludes>
                    </filter>
                </filters>
                <transformers>
                    <transformer
                            implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                        <!-- Replace this with the main class of your job -->
                        <mainClass>my.programs.main.clazz</mainClass>
                    </transformer>
                    <transformer
                            implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
                </transformers>
            </configuration>
        </execution>
    </executions>
</plugin>

kafka集群运行节点运行不成功

Sat, 26 Oct 2024 00:00:00 +0000

1.现象

由于zookeeper挂掉，造成kafka出现：There are 60 offline partitions。

2.造成的原因

经过排查发现，由于kafka之前Topic在zookeeper中的数据还在，再重新建立会产生冲突导致失败。

3.解决方案

进入Zookeeper中将之前的脏数据删掉再重启kafka。

#1.进入zookeeper

sh /opt/cloudera/parcels/CDH-6.3.2-1.cdh6.3.2.p0.1605554/lib/zookeeper/bin/zkCli.sh

#2.删除掉脏数据

deleteall /brokers/topics

hiveOnSpak客户端RemoteSparkDriver超时

Sat, 12 Oct 2024 00:00:00 +0000

1.现象

2.原因

集群资源使用率过高时可能会导致Hive On Spark查询失败-查询超时。

从hive on spark的架构看出超时的位置：

3.解决

修改以下参数，重启集群

### 其他可设置的参考参数
# 在Hive client和远程Spark driver通信过程中，随机生成密码的比特数。最好设置成8的倍数。　
hive.spark.client.secret.bits
# 远程Spark drive用于处理RPC事件所用的最大线程数，默认是8。　
hive.spark.client.rpc.threads
# Hive client和远程Spark driver通信最大的消息大小（单位：byte）,默认是50MB。　
hive.spark.client.rpc.max.size
# 远程Spark driver的通道日志级别，必须是DEBUG, ERROR, INFO, TRACE, WARN中的一个。　
hive.spark.client.channel.log.level
# 用于身份验证的SASL机制的名称。
hive.spark.client.rpc.sasl.mechanisms


#生产集群设置的相应参数：
hive.spark.client.future.timeout=360s # Hive client请求Spark driver的超时时间，如果没有指定时间单位，默认就是秒。
hive.metastore.client.socket.timeout=360s # 客户端socket超时时间，默认20秒。
hive.spark.client.connect.timeout=360000ms # Spark driver连接Hive client的超时时间，如果没有指定时间单位，默认就是毫秒。
hive.spark.client.server.connect.timeout=360000ms # Hive client和远程Spark driver握手时的超时时间，这个会在两边都检查的，如果没有指定时间单位，默认就是毫秒。
hive.spark.job.monitor.timeout=180s # Job监控获取Spark作业状态的超时时间，如果没有指定时间单位，默认就是秒。

hdfs文件未关闭

Sat, 28 Sep 2024 00:00:00 +0000

问题描述：

使用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:blk_1180034904_106295094; 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:blk_1180034904_106295094; 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，无法获取块文件长度信息

猜测是因为昨日yarn重启导致hdfs文件未关闭写状态

解决问题：

对hive load hdfs文件的地址执行检查命令

hdfs文件块异常

Sat, 14 Sep 2024 00:00:00 +0000

问题描述：

使用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文件的地址执行检查命令

Flume内存溢出卡死

Sat, 31 Aug 2024 00:00:00 +0000

问题：agent启动后跑到一半报错卡死

解决：修改flume_ng启动脚本中jvm参数：

vi /opt/cloudera/parcels/CDH/lib/flume-ng/bin/flume-ng

把 JAVA_OPTS="-Xmx20m" 改为 JAVA_OPTS="-Xmx2048m"

重启agent，顺畅running

flume不关闭临时文件

Sat, 17 Aug 2024 00:00:00 +0000

问题描述：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

flink虚拟内存不足

Sat, 03 Aug 2024 00:00:00 +0000

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查看stdout日志

Sat, 20 Jul 2024 00:00:00 +0000

问题:

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映射hive数据类型date无法解析

Sat, 06 Jul 2024 00:00:00 +0000

在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.

dolphin踩坑

Sat, 22 Jun 2024 00:00:00 +0000

一个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/前缀

部署CDH踩坑总结

Sat, 08 Jun 2024 00:00:00 +0000

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.==主机名不要出现下划线!==

指标字典

Sat, 11 May 2024 00:00:00 +0000

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通常指标字典包含指标维度和指标量度两个部分，如下：

总结：

通过上面的步骤和方法，根据自身业务情况，建立一个指标字典。

指标字典在建立知乎，要经过各个业务产品经理的评审，纠正错误不明或者有歧义的指标，在达成一致后，由数据产品推广，共大家参考使用。

好的指标字典就像二叉树一样，从单维度，粗糙维度分析，再细拆维度。看问题需要：由大到小，由内到外。

yarn队列设置

Sun, 28 May 2023 00:00:00 +0000

在大数据平台运维中，会经常遇到集群资源争抢的问题。因为在公司内部，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 集群资源。

sqoop提交参数解析

Sun, 14 May 2023 00:00:00 +0000

/opt/cloudera/parcels/CDH/lib/sqoop/bin/sqoop import \  
--connect jdbc:[mysql://ip:port/T_Cloud_Promote](mysql://ipport) \  
--username rt_center \  
--password pwd\  
--query "select KeywordID,KeyType,Root,KeywordName,UID,Status,AddDate,UpdateDate,MigrateOID,PromotionStatus,WordType,IsEmphasis,KeywordLength,IsViolate,ViolateWord from T_Cloud_Promote.T_Cloud_User_KeywordLibrary where KeywordID < $[a+10000000] AND KeywordID >= ${a} AND AddDate != '0000-00-00 00:00:00' AND \$CONDITIONS" \  
--fields-terminated-by '\001' \  
--target-dir /tmp/t_cloud_order \  
--delete-target-dir \  
--hive-import \  
--hive-database T_Cloud_Promote \  
--hive-table ods_t_cloud_user_keywordlibraryb_tmp_01 \  
--null-string '\\N' \  
--null-non-string '\\N' \  
--hive-drop-import-delims \  
--num-mappers 5 \  
--split-by KeywordID \  
--hive-overwrite

–connect
mysql连接
–username
用户名
–password
密码
–query
条件查询语句
–fields-terminated-by
分隔符
–target-dir
临时存放位置
–delete-target-dir \
程序结束删除文件夹
–hive-import \
导入到hive
–hive-database T_Cloud_Promote \
hive的数据库
–hive-table
hive表
–null-string ‘\N’ \
–null-non-string ‘\N’ \
转换为hive空

spark提交参数

Sun, 30 Apr 2023 00:00:00 +0000

spark-submit --master yarn --conf spark.default.parallelism=100 \
--deploy-mode cluster --driver-memory 4G --executor-memory 4G \
--num-executors 40 --executor-cores 3 \
--conf spark.yarn.executor.memoryOverhead=5g \
--class com.lz.hbase.CompanyInfo /tmp/test_langzi/original-spark_hbase01-1.0-SNAPSHOT.jar \
--conf spark.dynamicAllocation.maxExecutors=40

Spark Thrift Server

Sun, 16 Apr 2023 00:00:00 +0000

文章目录

一、Spark Thrift Server 介绍

Spark Thrift Server 是 Spark 社区基于 HiveServer2 实现的一个 Thrift 服务。旨在无缝兼容 HiveServer2。

因为 Spark Thrift Server 的接口和协议都和 HiveServer2 完全一致，因此我们部署好 Spark Thrift Server 后，可以直接使用 hive 的 beeline 访问 Spark Thrift Server 执行相关语句。

Spark Thrift Server 的目的也只是取代 HiveServer2，因此它依旧可以和 Hive Metastore 进行交互，获取到 hive 的元数据。

Ranger配置大数据组件

Sun, 02 Apr 2023 00:00:00 +0000

1.开启ranger-hive ranger-hdfs插件 2.修改hdfs配置 1.开启hdfs认证 hadoop.security.authorization = true

presto

Sun, 19 Mar 2023 00:00:00 +0000

presto操作hive

presto-cli --server 172.16.98.183:8050 --catalog hive

OneData数据仓库架构

Sun, 05 Mar 2023 00:00:00 +0000

**1.**什么是 onedata

面对爆炸式增长的数据，如何建设高效的数据模型和体系，对这些数据进行有序和有结构地分类组织和存储，避免重复建设和数据不一致性，保证数据的规范性，一直是大数据系统建设不断追求的方向。OneData 即是阿里巴巴内部进行数据整合及管理的方法体系和工具。阿里巴巴的大数据工程师在这一体系下，构建统一、规范、可共享的全域数据体系，避免数据的冗余和重复建设，规避数据烟囱和不一致性，充分发挥阿里巴巴在大数据海量、多样性方面的独特优势。借助这一统一化数据整合及管理的方法体系，我们构建了阿里巴巴的数据公共层，并可以帮助相似的大数据项目快速落地实现。

**2.**指导思想

阿里巴巴集团数据公共层设计理念遵循维度建模思想，可参考 StarSchema-The Complete Reference 和 The Data Warehouse Toolkit-The Definitive Guide to Dimensional Modeling。数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实。其核心的实施指导方针如下：

首先，要进行充分的业务调研和需求分析。

其次，进行数据总体架构设计，主要是根据数据域对数据进行划分；按照维度建模理论，构建总线矩阵，抽象出业务过程和维度。

再次，对报表需求进行抽象整理出相关指标体系，使用 One Data 工具完成指标规范定义和模型设计。

最后，是代码研发和运维。其实施流程主要分为：数据调研、架构设计、规范定义和模型设计。

**3.**业务调研

业务调研：需要确认要规划进数仓的业务领域，以及各业务领域包含的功能模块，以阿里的业务为例，可规划如下矩阵

需求调研：了解需求方关系哪些指标？需要哪些维度、度量？数据是否沉淀到汇总层等。

可以想象一下，在没有考虑分析师、业务运营人员的数据需求的情况下，根据业务调研建设的数据仓库无疑等于闭门造车。了解了业务系统的业务后并不代表就可以进行实施了，此刻要做的就是收集数据使用者的需求，可以去找分析师、业务运营人员了解他们有什么数据诉求，此时更多的就是报表需求。

需求调研的途径有两种:一是根据与分析师、业务运营人员的沟通(邮件、IM)获知需求；二是对报表系统中现有的报表进行研究分析。通过需求调研分析后，就清楚数据要做成什么样的。很多时候，都是由具体的数据需求驱动数据仓库团队去了解业务系统的业务数据，这两者并没有严格的先后顺序。

举例：分析师需要了解大淘宝(淘宝、天猫、天猫国际)一级类目的成交金额。当获知这个需求后，我们要分析根据什么(维度)汇总，以及汇总什么(度量)，这里类目是维度，金额是度量；明细数据和汇总数据应该怎样设计?这是一个公用的报表吗?是需要沉淀到汇总表里面，还是在报表工具中进行汇总?

**4.**架构设计

4.1 数据域的划分

数据域是指面向业务分析，将业务过程或者维度进行抽象的集合，一般数据域和应用系统(功能模块)有联系，可以考虑将同一个功能模块系统的业务过程划分到一个数据域。业务过程可以概括为一个个不可拆分的行为事件，如下单、支付、退款。为保障整个体系的生命力，数据域需要抽象提炼，并且长期维护和更新，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中或者扩展新的数据域。如表所示是功能模块/业务线的业务动作(部分示例)：

根据业务过程进行归纳，可以抽象出如下数据域：

4.2 构建总线矩阵

在进行充分的业务调研和需求调研后，就要构建总线矩阵了，需要做两件事情：

1.明确每个数据域下有哪些业务过程。

2.业务过程与哪些维度相关，并通过总线矩阵定义每个数据域下的业务过程和维度。

如下表是供应链管理业务过程示例：

4.3 规范定义

规范定义主要定义指标体系，包括原子指标、修饰词、时间周期和派生指标。

4.4 模型设计

模型设计主要包括维度及属性的规范定义，维表、明细事实表和汇总事实表的模型设计。

4.5 架构总结

One Data 的实施过程是一个高度迭代和动态的过程，一般采用螺旋式实施方法。在总体架构设计完成之后，开始根据数据域进行迭代式模型设计和评审。在架构设计、规范定义和模型设计等模型实施过程中，都会引入评审机制，以确保模型实施过程的正确性。

**5.**指标体系搭建

5.1 指标体系核心结构

left join 谓词下推

Sun, 19 Feb 2023 00:00:00 +0000

zzz1

uid	is_delete
1	1
2	0
3	0
zzz2

uid	is_delete
1	0
2	1
3	0

select * from zzz1 left join zzz2 on zzz1.uid = zzz2.uid
where zzz1.is_delete = 0 and zzz2.is_delete = 0

结果: 3 0 3 0

select * from (select * from zzz1 where zzz1.is_delete = 0) z1
left join (select * from zzz2 where zzz2.is_delete = 0) z2
on z1.uid = z2.uid

结果: 2 0 NULL NULL 3 0 3 0

select * from (select * from zzz1 where zzz1.is_delete = 0) z1
left join (select * from zzz2 where zzz2.is_delete = 0) z2
on z1.uid = z2.uid where z2.uid is not null

结果: 3 0 3 0

Kerberos入门

Sun, 05 Feb 2023 00:00:00 +0000

1. Kerberos是什么

Kerberos在古希腊神话中是指：一只有三个头的狗。这条狗守护在地狱之门外，防止活人闯入。

Kerberos是一个用于鉴定身份的协议，它采用对称密钥加密。

在我们的CDH平台中，常用来作为一种安全验证，只有经过kerberos认证后的用户才可以访问大数据集群的服务。

2.Kerberos中的一些概念

KDC(key distribution center): kerberos的认证中心，用来鉴别用户的身份的。想访问带kerberos的服务，得先过这个。

Principal: kerberos中账户的概念，用户会以这个账户来被KDC认证。

一个Principal由三个部分组成：primary, instance以及realm，其组成形式为primary/instance@realm。

primary : 可以是OS中的username，也可以是service name；
instance : 用于区分属于同一个user或者service的多个principals，该项为optional；
realm : 类似于DNS中的domain，定义了一组principals

举个栗子：hive/hive@ZHENDAO.COM    kafka/kafka@ZHENDAO.COM

KeyTab: 以文件的形式呈现，存储了一个或多个Principal的长期的key，用途和密码类似，用于kerberos认证登录；

其存在的意义在于让用户不需要明文的存储密码，和程序交互时不需要人为交互来输入密码。

TGT: 用户使用principal在KDC中进行认证后，KDC会返回给客户一个TGT，TGT会有过期时间。

Ticket：用户访问具体Server时，KDC会进行一次加密操作，返回给用户一张对应server的门票。

3.Kerberos基本使用

kerberos管理员创建一个principal, 并生成对应的keytab文件 → 注册一个kerberos的账号，并配置了免密登录
拿着keytab去KDC中进行账户的认证 → kinit -kt /var/lib/hive/hive.keytab hive/hive@ZHENDAO.COM
KDC返回一个这个principal对应的TGT文件 → 默认存放在linux的 /tmp 目录下
客户拿着TGT去过带有kerberos的服务端APP

4.Kerberos认证原理

客户拿着principal去KDC中进行认证的时候，kerberos会检查其库中是否有对应的principal，如果有的话，返回一个TGT。
客户拿着TGT向带有kerberos的服务端app发起请求时，请求会先发到KDC。
KDC会拿着客户的master key（客户密码的hash）和服务端的master key（比如说hive server的master key）进行加密操作，并返回给客户一个对应hive server的ticket。
客户拿着加密后的ticket,去请求hive服务的时候，hive会对ticket进行一个验证。验证通过即可访问hive

5.举个栗子：KAFKA认证过程

kafka producer拿着principal向KDC认证身份，通过则拿到KDC返回的TGT <这是第一次认证，就好比在游乐园的门口，做一次验票操作>
producer拿着TGT向KDC请求kafka的服务，KDC验证TGT，看该账号能不能使用kafka，如果可以使用，那么进行加密，并返回一个ticket给producer <这是第二次认证，就好比你想玩游乐园中的具体项目，得看看你买的门票有没有这个资格玩VIP项目>
producer拿着ticket和kafka server尝试建立连接，kafka server会使用server的master key对ticket进行一次解密操作，来验证producer的身份，通过则建立连接 <玩上具体的项目了>

kafka在zk中的目录结构

Sun, 22 Jan 2023 00:00:00 +0000

Kafka数据导入ClickHouse

Sun, 08 Jan 2023 00:00:00 +0000

1.Kafka中数据导入ClickHouse的标准流程

在ClickHouse中建立Kafka Engine 外表，作为Kafka数据源的一个接口
在ClickHouse中创建普通表(通常是MergeTree系列）存储Kafka中的数据
在ClickHouse中创建Materialized View, 监听Kafka中的数据，并将数据写入ClickHouse存储表中

上述三个步骤，就可以将Kafka中的数据导入到ClickHouse集群中。

2. Kafka数据导入ClickHouse详细步骤

ClickHouse 提供了Kafka Engine 作为访问Kafka集群的一个接口（数据流）。有了这个接口后，导入数据就很方便了，具体步骤如下：

步骤1：创建Kafka Engine

CREATE TABLE source
(
    `ts` DateTime, 
    `tag` String, 
    `message` String
)
ENGINE = Kafka()
SETTINGS kafka_broker_list = '172.19.0.47:9092', 
         kafka_topic_list = 'tag',
         kafka_group_name = 'clickhouse', 
         kafka_format = 'JSONEachRow',
         kafka_skip_broken_messages = 1,
         kafka_num_consumers = 2

必选参数：

kafkabrokerlist: 这里填写Kafka服务的broker列表，用逗号分隔
kafkatopiclist: 这里填写Kafka topic,多个topic用逗号分隔
kafkagroupname：这里填写消费者group名称
kafkaformat__:Kafka数据格式, ClickHouse支持的Format, 详见这里可选参数：
kafkaskipbrokenmessages：填写大于等于0的整数，表示忽略解析异常的Kafka数据的条数。如果出现了N条异常后，后台线程结束，Materialized View会被重新安排后台线程去监听数据
kafkanumconsumers_: 单个Kafka Engine 的消费者数量，通过增加该参数，可以提高消费数据吞吐，但总数不应超过对应topic的partitions总数
kafkarowdelimiter: 消息分隔符
kafkaschema__:对于kafkaformat需要schema定义的时候，其schema由该参数确定
kafkamaxblocksize: 该参数控制Kafka数据写入目标表的Block大小，超过该数值后，就将数据刷盘。

步骤2：创建存储Kafka数据的目标表，该表就是最终存储Kafka数据本文中，采用MergeTree来存储Kafka数据：

CREATE TABLE target
(
    `ts` DateTime, 
    `tag` String
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(ts)
ORDER BY tag

步骤3：创建Metrialized View 抓取数据

本文中，采用如下语句创建MV:

Kafka 中的控制器组件

Sun, 25 Dec 2022 00:00:00 +0000

控制器组件（Controller），是 Apache Kafka 的核心组件。它的主要作用是在 Apache ZooKeeper 的帮助下管理和协调整个 Kafka 集群。集群中任意一台 Broker 都能充当控制器的角色，但是，在运行过程中，只能有一个 Broker 成为控制器，行使其管理和协调的职责。换句话说，每个正常运转的 Kafka 集群，在任意时刻都有且只有一个控制器。官网上有个名为 activeController 的 JMX 指标，可以帮助我们实时监控控制器的存活状态。这个 JMX 指标非常关键，你在实际运维操作过程中，一定要实时查看这个指标的值。下面，我们就来详细说说控制器的原理和内部运行机制。

在开始之前，我先简单介绍一下 Apache ZooKeeper 框架。要知道，控制器是重度依赖 ZooKeeper 的，因此，我们有必要花一些时间学习下 ZooKeeper 是做什么的。

Apache ZooKeeper 是一个提供高可靠性的分布式协调服务框架。它使用的数据模型类似于文件系统的树形结构，根目录也是以 “/” 开始。该结构上的每个节点被称为 znode，用来保存一些元数据协调信息。

如果以 znode 持久性来划分，znode 可分为持久性 znode 和临时 znode。持久性 znode 不会因为 ZooKeeper 集群重启而消失，==而临时 znode 则与创建该 znode 的 ZooKeeper 会话绑定，一旦会话结束，该节点会被自动删除==。

==ZooKeeper 赋予客户端监控 znode 变更的能力，即所谓的 Watch 通知功能。一旦 znode 节点被创建、删除，子节点数量发生变化，抑或是 znode 所存的数据本身变更，ZooKeeper 会通过节点变更监听器 (ChangeHandler) 的方式显式通知客户端。==

依托于这些功能，ZooKeeper 常被用来实现集群成员管理、分布式锁、领导者选举等功能。==Kafka 控制器大量使用 Watch 功能实现对集群的协调管理==。我们一起来看一张图片，它展示的是 Kafka 在 ZooKeeper 中创建的 znode 分布。你不用了解每个 znode 的作用，但你可以大致体会下 Kafka 对 ZooKeeper 的依赖。

Kafka 常见的脚本汇总

Sun, 11 Dec 2022 00:00:00 +0000

命令行脚本概览

Kafka 默认提供了很多个命令行脚本，用于实现各种各样的功能和运维管理。今天我以 2.2 版本为例，详细地盘点下这些命令行工具。下图展示了 2.2 版本提供的所有命令行脚本。

从图中我们可以知道，2.2 版本总共提供了 30 个 SHELL 脚本。图中的 windows 实际上是个子目录，里面保存了 Windows 平台下的 BAT 批处理文件。其他的. sh 文件则是 Linux 平台下的标准 SHELL 脚本。

默认情况下，不加任何参数或携带 –help 运行 SHELL 文件，会得到该脚本的使用方法说明。下面这张图片展示了 kafka-log-dirs 脚本的调用方法。

有了这些基础的了解，我来逐一地说明这些脚本的用途，然后再给你详细地介绍一些常见的脚本。

我们先来说说 connect-standalone 和 connect-distributed 两个脚本。这两个脚本是 Kafka Connect 组件的启动脚本。在专栏第 4 讲谈到 Kafka 生态时，我曾说过社区提供了 Kafka Connect 组件，用于实现 Kafka 与外部世界系统之间的数据传输。Kafka Connect 支持单节点的 Standalone 模式，也支持多节点的 Distributed 模式。这两个脚本分别是这两种模式下的启动脚本。鉴于 Kafka Connect 不在我们的讨论范围之内，我就不展开讲了。

接下来是 kafka-acls 脚本。它是用于设置 Kafka 权限的，比如设置哪些用户可以访问 Kafka 的哪些主题之类的权限。在专栏后面，我会专门来讲 Kafka 安全设置的内容，到时候我们再细聊这个脚本。

impala配置调优

Sun, 27 Nov 2022 00:00:00 +0000

Impala Daemon 命令行参数高级配置代码段（安全阀）

-use_local_tz_for_unix_timestamp_conversions=true
-convert_legacy_hive_parquet_utc_timestamps=true

在hive中，一个中文字符长度为1

在impala中，一个中文字符长度为3

Hive注册udf

Sun, 13 Nov 2022 00:00:00 +0000

1.创建临时函数

hive> add jar /home/hadoop/bigdata_udf.jar;
hive> create temporary function isContains100 as 'com.xx.hive.udf.hm2.IsContains100';
--验证
hive> select isContains100(t.col1) from t limit 10;
hive> drop temporary function isContains100;

2.创建永久函数

hadoop fs -put /opt/bigdata_udf.jar /udf
hive> create function default.url_decode as 'com.xx.udf.DecodeURL' using jar 'hdfs:///udf/bigdata_udf.jar';
--验证
hive> select default.url_decode(t.col1) from t limit 10;

注意:注册永久函数必须使用hdfs路径,不可使用本地路径

Hive映射HBase数据源

Sun, 30 Oct 2022 00:00:00 +0000

CREATE EXTERNAL TABLE `mongodb_dingtalk.hbasetohive_patent`(  
key String,  
abstracts String,  
address String)  
STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler'  
WITH SERDEPROPERTIES ("hbase.columns.mapping" = ":key,info:abstracts,info:address")  
TBLPROPERTIES("[hbase.table.name](http://hbase.table.name/)" = "dingtalk:patent");

仅从HBase拉取数据使用，禁止利用此种方式往HBase写数据

数据拉出时拉出hbase中数据对应当前版本的时间戳

create external table ods.ods_zxk_hbase_wechat_public_account_mapping(  
id string comment '需要拆分的key',  
ts timestamp comment '数据标识符，用来跟新数据做去重')  
comment '高级搜索有无微信公众号'  
STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler'  
WITH SERDEPROPERTIES ('hbase.columns.mapping' = ':key,:timestamp')  
TBLPROPERTIES('[hbase.table.name](http://hbase.table.name/)' = 'dingtalk:wechat_public_account')

hive映射es

Sun, 16 Oct 2022 00:00:00 +0000

一 hive导入es

1 创建hive-es映射表

CREATE EXTERNAL TABLE hive_es.re_run_test2(
id STRING
,test STRING)
STORED BY 'org.elasticsearch.hadoop.hive.EsStorageHandler'
TBLPROPERTIES('es.resource' = 're_run_test2/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.id' ='id')

注：

1.

es.resource对应es中的index/type

2.

1.es.mapping.names为hive和es字段名映射关系。
2.如果hive表和es表字段名完全一致，可以省略此参数。
3.hive中字段名不区分大小写，元数据寸的全是小写；es中字段大小写敏感，如果es中字段名出现大写，需认真填写。
4.es中_id为自动生成，如若需要覆盖，需加参数'es.mapping.id'='id'

2 先导入es映射表相关jar包

add jar /opt/cloudera/parcels/CDH-6.3.2-1.cdh6.3.2.p0.1605554/lib/hive/auxlib/elasticsearch-hadoop-6.3.0.jar;
add jar /data/jar/httpclient-4.5.5.jar;
add jar /data/jar/org.apache.commons.httpclient.jar;

3 向映射表insert数据

二 es导入hive

1 建hive映射表

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.mapping.date.rich'='false',
  'es.index.auto.create'='false',
)

注意，hive表数据类型要和es一致，除了es的date要转成hive的string，同时要加参数’es.mapping.date.rich’=‘false’,否则查询会报错.

2 通过映射表向其他表insert

参考：

https://www.cnblogs.com/koushr/p/9505435.html

hive设置spark参数

Sun, 02 Oct 2022 00:00:00 +0000

set spark.master=yarn-cluster;          #设置spark提交模式

set hive.execution.engine=spark;         #设置计算引擎

set spark.yarn.queue=queue_name;      #设置作业提交队列

set spark.app.name=job_name;         #设置作业名称

set spark.executor.instances=20;         #设置执行器个数

set spark.executor.cores=4;            #设置执行器计算核个数

set spark.executor.memory=8g;         #设置执行器内存

set mapred.reduce.tasks=600;           #设置任务并行度

set spark.yarn.executor.memoryOverhead=2048;   #设置每个executor的jvm堆外内存

set spark.memory.fraction=0.8;          #设置内存比例(spark2.0+)

set spark.serializer=org.apache.serializer.KyroSerializer;  #设置对象序列化方式

Hive调优大全

Sun, 18 Sep 2022 00:00:00 +0000

调优具体细节

Hive建表设计层面

Hive 的建表设计层面调优，主要讲的怎么样合理的组织数据，方便后续的高效计算。比如建表的类型，文件存储格式，是否压缩等等。

利用分区表优化

关于 Hive 的表的类型有哪些？
1、分区表  
2、分桶表

分区表是在某一个或者几个维度上对数据进行分类存储，一个分区对应一个目录。如果筛选条件里有分区字段，那么 Hive 只需要遍历对应分区目录下的文件即可，不需要遍历全局数据，使得处理的数据量大大减少，从而提高查询效率。

也就是说：当一个 Hive 表的查询大多数情况下，会根据某一个字段进行筛选时，那么非常适合创建为分区表，该字段即为分区字段。

select1:  select ....  where country = "china"
select2:  select ....  where country = "china"
select3:  select ....  where country = "china"
select4:  select ....  where country = "china"
.....

分门别类：这个city字段的每个值，就单独形成为一个分区。其实每个分区就对应带HDFS的一个目录

在创建表时通过启用 partitioned by 实现，用来 partition 的维度并不是实际数据的某一列，具体分区的标志是由插入内容时给定的。当要查询某一分区的内容时可以采用 where 语句，形似 where tablename.partition_column = a 来实现。

1、创建含分区的表：

CREATE TABLE page_view(viewTime INT, userid BIGINT,
                       page_url STRING, referrer_url STRING,
                       ip STRING COMMENT 'IP Address of the User')
PARTITIONED BY(date STRING, country STRING)
ROW FORMAT DELIMITED FIELDS TERMINATED BY '1'
STORED AS TEXTFILE;

2、载入内容，并指定分区标志：

Hive常用参数语句

Sun, 04 Sep 2022 00:00:00 +0000

1.动态分区

SET hive.exec.dynamic.partition=true;

SET hive.exec.dynamic.partition.mode=nonstrict;

SET hive.exec.max.dynamic.partitions=100000;

SET hive.exec.max.dynamic.partitions.pernode=100000;

SET hive.exec.max.created.files=100000;

2.union all并发执行

--在使用union all的时候，系统资源足够的情况下，为了加快hive处理速度，可以设置如下参数实现并发执行

set mapred.job.priority=VERY_HIGH;

set hive.exec.parallel=true;

3.设置map reduce个数

-- 设置map capacity

set mapred.job.map.capacity=2000;

set mapred.job.reduce.capacity=2000;

-- 设置每个reduce的大小

set hive.exec.reducers.bytes.per.reducer=500000000;

-- 直接设置个数

set mapred.reduce.tasks = 15;

4.文件合并

-- 设置文件合并

set abaci.is.dag.job=false;

set hive.merge.mapredfiles=true;

set mapred.combine.input.format.local.only=false;

set hive.merge.smallfiles.avgsize=100000000;

-- 在map only的情况下，如上的参数如果没有生效，可以设置如下

-- 在HQL的最外层增加distribute by rand()

select * from XXX distribute by rand()

5.设置任务名称


-- 设置名称

set mapred.job.name=${my_job};

6.设置引擎和指定队列

set hive.execution.engine=mr;

set mapreduce.job.queuename=bigdata;

Hive-mongo导入导出

Sun, 21 Aug 2022 00:00:00 +0000

1.MongoDB拉出到hive

# 导入mongodb的包到hadoop
add jar /var/lib/hadoop-hdfs/bin/hive_mongoDB/mongo-hadoop-core-2.0.2.jar;
add jar /var/lib/hadoop-hdfs/bin/hive_mongoDB/mongo-hadoop-hive-2.0.2.jar;
add jar /var/lib/hadoop-hdfs/bin/hive_mongoDB/mongo-java-driver-3.12.8.jar;
set mongo.input.split.create_input_splits=false;


DROP TABLE IF EXISTS ods.ods_ex_trade_mdb_wmb_rocket_waimao_company_info_mapping;
drop table ods.ods_zxk_annualBusiness_mapping;
create external table ods.ods_zxk_annualBusiness_mapping(
`_id` string,
companyName string,
Tel string
)STORED BY 'com.mongodb.hadoop.hive.MongoStorageHandler'
WITH SERDEPROPERTIES('mongo.columns.mapping'='{"_id":"_id","companyName":"companyName","Tel":"Tel"}')
TBLPROPERTIES('mongo.uri'='mongodb://username:password@172.16.98.159:21000/annualReport.annualBusiness?authSource=admin');

Hive 字段中文注释乱码

Sun, 07 Aug 2022 00:00:00 +0000

Hive 字段中文乱码，如执行 show create table xxx 时，表级别注释、字段级别注释发现有乱码现象（都是？？？？），一般都是由 hive 元数据库的配置不当造成的。

此时可按如下步骤进行配置调整：

1、设置 hive 元数据库字符集

show create database hive;

查看为 utf8，需变更为 latin1

_alter database hive character set latin1;

2、更改如下表字段为字符集编码为 utf8

①修改表字段注解和表注解
alter table COLUMNS_V2 modify column COMMENT varchar(256) character set utf8
alter table TABLE_PARAMS modify column PARAM_VALUE varchar(4000) character set utf8
② 修改分区字段注解：
alter table PARTITION_PARAMS modify column PARAM_VALUE varchar(4000) character set utf8 ;
alter table PARTITION_KEYS modify column PKEY_COMMENT varchar(4000) character set utf8;
③修改索引注解：
alter table INDEX_PARAMS modify column PARAM_VALUE varchar(4000) character set utf8;

Hive 数仓建表该选用 ORC 还是 Parquet，压缩选 LZO 还是 Snappy

Sun, 24 Jul 2022 00:00:00 +0000

在数仓中，建议大家除了接口表（从其他数据库导入或者是最后要导出到其他数据库的表），其余表的存储格式与压缩格式保持一致。

在数仓中，建议大家除了接口表（从其他数据库导入或者是最后要导出到其他数据库的表），其余表的存储格式与压缩格式保持一致。

我们先来说一下目前 Hive 表主流的存储格式与压缩方式

从 Hive 官网得知，Apache Hive 支持 Apache Hadoop 中使用的几种熟悉的文件格式，如 TextFile（文本格式），RCFile（行列式文件），SequenceFile（二进制序列化文件），AVRO，ORC（优化的行列式文件）和Parquet 格式，而这其中我们目前使用最多的是TextFile，SequenceFile，ORC和Parquet。

下面来详细了解下这 2 种行列式存储。

1、ORC

1.1 ORC 的存储结构

我们先从官网上拿到 ORC 的存储模型图

看起来略微有点复杂，那我们稍微简化一下，我画了一个简单的图来说明一下

但是由于索引的高成本，在**「目前的 Hive3.X 中，已经废除了索引」**，当然也早就引入了列式存储。

列式存储的存储方式，是按照一列一列存储的，如上图中的右图，这样的话如果查询一个字段的数据，就等于是索引查询，效率高。但是如果需要查全表，它因为需要分别取所有的列最后汇总，反而更占用资源。于是 ORC 行列式存储出现了。

在需要全表扫描时，可以按照行组读取
如果需要取列数据，在行组的基础上，读取指定的列，而不需要所有行组内所有行的数据和一行内所有字段的数据。

了解了 ORC 存储的基本逻辑后，我们再来看看它的存储模型图。

同时我也把详细的文字也附在下面，大家可以对照着看看：

条带 (stripe)：ORC 文件存储数据的地方，每个 stripe 一般为 HDFS 的块大小。（包含以下 3 部分）

index data:保存了所在条带的一些统计信息,以及数据在 stripe中的位置索引信息。
rows data:数据存储的地方,由多个行组构成，每10000行构成一个行组，数据以流( stream)的形式进行存储。
stripe footer:保存数据所在的文件目录

文件脚注 (file footer)：包含了文件中 sipe 的列表, 每个 stripe 的行数, 以及每个列的数据类型。它还包含每个列的最小值、最大值、行计数、求和等聚合信息。
postscript：含有压缩参数和压缩大小相关的信息

所以其实发现，ORC 提供了 3 级索引，文件级、条带级、行组级，所以在查询的时候，利用这些索引可以规避大部分不满足查询条件的文件和数据块。

hadoop默认端口

Sun, 10 Jul 2022 00:00:00 +0000

端口	用途
9000	fs.defaultFS，如：hdfs://172.25.40.171:9000
9001	dfs.namenode.rpc-address，DataNode会连接这个端口
50070	dfs.namenode.http-address
50470	dfs.namenode.https-address
50100	dfs.namenode.backup.address
50105	dfs.namenode.backup.http-address
50090	dfs.namenode.secondary.http-address，如：172.25.39.166:50090
50091	dfs.namenode.secondary.https-address，如：172.25.39.166:50091
50020	dfs.datanode.ipc.address
50075	dfs.datanode.http.address
50475	dfs.datanode.https.address
50010	dfs.datanode.address，DataNode的数据传输端口
8480	dfs.journalnode.rpc-address
8481	dfs.journalnode.https-address
8032	yarn.resourcemanager.address
8088	yarn.resourcemanager.webapp.address，YARN的http端口
8090	yarn.resourcemanager.webapp.https.address
8030	yarn.resourcemanager.scheduler.address
8031	yarn.resourcemanager.resource-tracker.address
8033	yarn.resourcemanager.admin.address
8042	yarn.nodemanager.webapp.address
8040	yarn.nodemanager.localizer.address
8188	yarn.timeline-service.webapp.address
10020	mapreduce.jobhistory.address
19888	mapreduce.jobhistory.webapp.address
2888	ZooKeeper，如果是Leader，用来监听Follower的连接
3888	ZooKeeper，用于Leader选举
2181	ZooKeeper，用来监听客户端的连接
60010	hbase.master.info.port，HMaster的http端口
60000	hbase.master.port，HMaster的RPC端口
60030	hbase.regionserver.info.port，HRegionServer的http端口
60020	hbase.regionserver.port，HRegionServer的RPC端口
8080	hbase.rest.port，HBase REST server的端口
10000	hive.server2.thrift.port
9083	hive.metastore.uris

flume示例

Sun, 26 Jun 2022 00:00:00 +0000

conf：

# ex_trade.conf:外贸数据自kafka接入hdfs
# 配置负责人：褚天宇
# 配置时间： 2022-01-17

# 配置Agent ex_trade_agent各个组件的名称
ex_trade_agent.sources = r1
ex_trade_agent.sinks = k1
ex_trade_agent.channels = c1

# 配置Agent ex_trade_agent的source r1的属性
# 设置kafka源
ex_trade_agent.sources.r1.type = org.apache.flume.source.kafka.KafkaSource
# 设置kafka消费者组id （不能改动！改动会丢失已记录的offset）
ex_trade_agent.sources.r1.kafka.consumer.group.id = ex_trade_flume
ex_trade_agent.sources.r1.kafka.bootstrap.servers = 192.168.102.2:9092,192.168.102.3:9092,192.168.102.7:9092
ex_trade_agent.sources.r1.kafka.topics = ex_trade
# 一批写入 channel 的最大消息数
ex_trade_agent.sources.r1.batchSize = 2000
# 一个批次写入 channel 之前的最大等待时间（毫秒）。达到等待时间或者数量达到 batchSize 都会触发写操作
ex_trade_agent.sources.r1.batchDurationMillis = 2000
# 设置kafka-offset策略为从头消费
ex_trade_agent.sources.r1.kafka.consumer.auto.offset.reset = earliest




# 配置Agent ex_trade_agent的sink k1的属性
# 配置hdfs目标
ex_trade_agent.sinks.k1.type = hdfs
# 配置hdfs写入目录，每天一个文件夹，为之后hive表按日分区做准备
ex_trade_agent.sinks.k1.hdfs.path = /flume/ex_trade/date=%Y%m%d/
# 配置文件前缀
ex_trade_agent.sinks.k1.hdfs.filePrefix = ex_trade_
# 配置数据类型为原样输出
ex_trade_agent.sinks.k1.hdfs.fileType = DataStream
# 当前文件写入达到该值时间后触发滚动创建新文件，单位：秒，设置为1天防止产生小文件
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
# 文件写入格式设置为 Text，否则 Impala或 Apache Hive 无法读取这些文件。
ex_trade_agent.sinks.k1.hdfs.writeFormat = Text



# 配置Agent ex_trade_agent的channel c1的属性，用来缓冲数据
ex_trade_agent.channels.c1.type = file
# 配置通道的检查点目录
ex_trade_agent.channels.c1.checkpointDir = /data/deploy/flume/checkpoint
# 配置通道的数据目录
ex_trade_agent.channels.c1.dataDirs = /data/deploy/flume/data

# 把source和sink绑定到channel上
ex_trade_agent.sources.r1.channels = c1
ex_trade_agent.sinks.k1.channel = c1

启动脚本：

flume动态加载配置原理

Sun, 12 Jun 2022 00:00:00 +0000

Flume NG支持运行时动态修改配置的配置模块

细说一下PollingPropertiesFileConfigurationProvider提供的运行时动态修改配置并生效的能力。

要实现动态修改配置文件并生效，主要有两个待实现的功能

观察配置文件是否修改
如果修改，将修改的内容通知给观察者

对于第一点，监控配置文件是否修改，Flume NG定义了一个FileWatcherRunnable对象来监控配置文件，启动了一个单独的线程采用定时轮询的方式来监控，轮询频率是30毫秒一次，比较file.lastModified属性与lastChange时间戳，当file.lastModified > lastChange时表示文件被修改

public class FileWatcherRunnable implements Runnable {
    private final File file;
    private final CounterGroup counterGroup;

    private long lastChange;

    public FileWatcherRunnable(File file, CounterGroup counterGroup) {
      super();
      this.file = file;
      this.counterGroup = counterGroup;
      this.lastChange = 0L;
    }

    @Override
    public void run() {
      LOGGER.debug("Checking file:{} for changes", file);

      counterGroup.incrementAndGet("file.checks");

      long lastModified = file.lastModified();

      if (lastModified > lastChange) {
        LOGGER.info("Reloading configuration file:{}", file);

        counterGroup.incrementAndGet("file.loads");

        lastChange = lastModified;

        try {
          eventBus.post(getConfiguration());
        } catch (Exception e) {
          LOGGER.error("Failed to load configuration data. Exception follows.",
              e);
        } catch (NoClassDefFoundError e) {
          LOGGER.error("Failed to start agent because dependencies were not " +
              "found in classpath. Error follows.", e);
        } catch (Throwable t) {
          // caught because the caller does not handle or log Throwables
          LOGGER.error("Unhandled error", t);
        }
      }
}
      }

// PollingPropertiesFileConfigurationProvider.start()启动一个单独的线程来监控properties配置文件
 public void start() {
    LOGGER.info("Configuration provider starting");
    Preconditions.checkState(file != null,
        "The parameter file must not be null");

    executorService = Executors.newSingleThreadScheduledExecutor(
            new ThreadFactoryBuilder().setNameFormat("conf-file-poller-%d")
                .build());

    FileWatcherRunnable fileWatcherRunnable =
        new FileWatcherRunnable(file, counterGroup);

    executorService.scheduleWithFixedDelay(fileWatcherRunnable, 0, interval,
        TimeUnit.SECONDS);

    lifecycleState = LifecycleState.START;

    LOGGER.debug("Configuration provider started");
           }

对于第二点，利用Guava EventBus提供的发布订阅模式机制，将配置修改封装成事件传递给Application，来重新加载配置

CDH组件参数调优

Sun, 29 May 2022 00:00:00 +0000

1.YARN参数调优

检查项	当前值	修改值
JobHistory Server 的 Java 堆栈大小	1GB	2GB
NodeManager 的 Java 堆栈大小	1GB	2GB
ResourceManager 的 Java 堆栈大小	1GB	2GB
容器内存 yarn.nodemanager.resource.memory-mb	24GB	32GB
最小容器内存 yarn.scheduler.minimum-allocation-mb	10GB	8GB
最大容器内存 yarn.scheduler.maximum-allocation-mb	40GB	56GB
Map 任务内存 mapreduce.map.memory.mb	0M	12GB
Reduce 任务内存 mapreduce.reduce.memory.mb	0M	24GB
Application Master容器内存 yarn.app.mapreduce.am.resource.mb	24GB	32GB
Map 任务 Java 选项库 mapreduce.map.java.opts	-Djava.net.preferIPv4Stack=true	-Dmapreduce.map.java.opts=-Xmx2048m
Reduce 任务 Java 选项库 mapreduce.reduce.java.opts	-Djava.net.preferIPv4Stack=true	-Dmapreduce.reduce.java.opts=-Xmx2048m
yarn.resourcemanager.scheduler.class	org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler	org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler

yarn.scheduler.capacity.root.queues:

当前值：

<configuration>
    <property>
        <name>yarn.scheduler.capacity.root.queues</name>
        <value>default</value>
    </property>
    <property>
        <name>yarn.scheduler.capacity.root.capacity</name>
        <value>100</value>
    </property>
    <property>
        <name>yarn.scheduler.capacity.root.default.capacity</name>
        <value>100</value>
    </property>
</configuration>

修改值：

CDH角色划分

Sun, 15 May 2022 00:00:00 +0000

1. 服务器配置

主节点：

hostname: m1,m2,m3

vcore：48

内存：128G

SSD：1T（不算系统盘）

工作节点：

hostname: n1,n2,n3,n4

vcore : 48

内存：256G

SSD:1T（不算系统盘）

2. 节点职责描述

m1: 控制核心；cdh核心，hadoop主节点

m2: 网关入口；主节点高可用，一些组件的web ui，用户入口，（前期做计算任务的driver端，后期优化driver打散到各节点）

m3: 后台服务；组件元数据库，任务的history服务，（后期做元数据HA）

n1~n4: 算存一体；提供存储，计算等服务

3.角色分配策略

一、hdfs

NameNode一般在主节点上，初始化安装的时候没有高可用，所以有SecondaryNameNode的作为一个备份,NameNode它会将它拆分后进行分布式存储，其中的数据是分散在各个DataNode节点，且默认都会有3个副本，防止其中一台机器宕机使得数据缺失。balancer一般与namenode搭建在一起。

二、hive

hive metastore server与hiveServer2一般搭载一起上，但也可以分开，因为hive服务需要启动hiveServer2，访问sparksql需要启动metastore而hive gateway,事实上并不是真正的角色，也没有状态，但它们充当了告诉客户端配置应该放置在哪里。添加Hive服务时，默认情况下会创建Hive网关。

三、cloudera manager server

这个可以根据实际搭建，这个相当于是集群的监听器，在网页上出现的的图表也就是这个监听器类似的，这个可以搭建在主节点上，但若是主节点上分配的角色过多会影响其服务器的性能。

四、spark

这个角色可以分配这任意的机器上，按实际情况调整。spark-gateway全部部署在各个机器上，这个对于个人理解来说相当于spark、spark2机器之间的通信功能。

五、yarn

jobhistory与resourcemanager进行通信，所以部署上一般在同一台机器上放在主节点上，而nodemanager分配在各个节点上

六、zookeeper

这个若是机器足够一般是奇数的，所以部署在m节点上比较合适。奇数台、高可用、与管理角色共置

七、hue

会对外提供一个web ui，以便于数据分析和数据开发做即席查询。这个服务随意部署，根据自己的机器部署情况来看。

4.角色划分详情表


		控制核心	网关+入口	元数据+历史服务	存算一体
m1	m2	m3	n1	n2	n3	n4
cloudera management	Alert Publisher	✅
Event Server	✅
Host Monitor	✅
Service Monitor	✅
hdfs	NameNode	✅	✅
JournalNode	✅	✅	✅
Failover Controller	✅	✅
HttpFs		✅
DataNode				✅	✅	✅	✅
yarn	ResourceManager	✅	✅
NodeManager				✅	✅	✅	✅
JobHistory Server			✅
hive	Hive MetaStore Server			✅
HiveServer2			✅
HiveGateway	✅	✅	✅	✅	✅	✅	✅
spark	Spark History Server			✅
Spark Gateway	✅	✅	✅	✅	✅	✅	✅
impala	Impala StateStore	✅
Impala catalog Server			✅
Impala Daemon				✅	✅	✅	✅
zookeeper	zk-node	✅	✅	✅
hue	Hue Server		✅
Hue Load Balancer			✅

5. 未来升级项

work节点扩展硬盘，只需将新盘挂载到新目录/hadoop/data2或/hadoop/data3，更新hdfs配置就能完成存储扩展（支持热加入）

beeline导出数据

Sun, 01 May 2022 00:00:00 +0000

beeline -n chutianyu -p chutianyu –showHeader=false –outputformat=csv2 -e “select * from smp.india_imp_json_test2mongo ;” > india_imp_test1.json

如何重设消费者组位移

Sun, 17 Apr 2022 00:00:00 +0000

为什么要重设消费者组位移？

我们知道，Kafka 和传统的消息引擎在设计上是有很大区别的，其中一个比较显著的区别就是，Kafka 的消费者读取消息是可以重演的（replayable）。

像 RabbitMQ 或 ActiveMQ 这样的传统消息中间件，它们处理和响应消息的方式是破坏性的（destructive），即一旦消息被成功处理，就会被从 Broker 上删除。

反观 Kafka，由于它是基于日志结构（log-based）的消息引擎，消费者在消费消息时，仅仅是从磁盘文件上读取数据而已，是只读的操作，因此消费者不会删除消息数据。同时，由于位移数据是由消费者控制的，因此它能够很容易地修改位移的值，实现重复消费历史数据的功能。

对了，之前有很多同学在专栏的留言区提问：在实际使用场景中，我该如何确定是使用传统的消息中间件，还是使用 Kafka 呢？我在这里统一回答一下。如果在你的场景中，消息处理逻辑非常复杂，处理代价很高，同时你又不关心消息之间的顺序，那么传统的消息中间件是比较合适的；反之，如果你的场景需要较高的吞吐量，但每条消息的处理时间很短，同时你又很在意消息的顺序，此时，Kafka 就是你的首选。

重设位移策略

不论是哪种设置方式，重设位移大致可以从两个维度来进行。

位移维度。这是指根据位移值来重设。也就是说，直接把消费者的位移值重设成我们给定的位移值。
时间维度。我们可以给定一个时间，让消费者把位移调整成大于该时间的最小位移；也可以给出一段时间间隔，比如 30 分钟前，然后让消费者直接将位移调回 30 分钟之前的位移值。

下面的这张表格罗列了 7 种重设策略。接下来，我来详细解释下这些策略。

Earliest 策略表示将位移调整到主题当前最早位移处。这个最早位移不一定就是 0，因为在生产环境中，很久远的消息会被 Kafka 自动删除，所以当前最早位移很可能是一个大于 0 的值。如果你想要重新消费主题的所有消息，那么可以使用 Earliest 策略。

Latest 策略表示把位移重设成最新末端位移。如果你总共向某个主题发送了 15 条消息，那么最新末端位移就是 15。如果你想跳过所有历史消息，打算从最新的消息处开始消费的话，可以使用 Latest 策略。

Current 策略表示将位移调整成消费者当前提交的最新位移。有时候你可能会碰到这样的场景：你修改了消费者程序代码，并重启了消费者，结果发现代码有问题，你需要回滚之前的代码变更，同时也要把位移重设到消费者重启时的位置，那么，Current 策略就可以帮你实现这个功能。

表中第 4 行的 Specified-Offset 策略则是比较通用的策略，表示消费者把位移值调整到你指定的位移处。这个策略的典型使用场景是，消费者程序在处理某条错误消息时，你可以手动地 “跳过” 此消息的处理。在实际使用过程中，可能会出现 corrupted 消息无法被消费的情形，此时消费者程序会抛出异常，无法继续工作。一旦碰到这个问题，你就可以尝试使用 Specified-Offset 策略来规避。

如果说 Specified-Offset 策略要求你指定位移的绝对数值的话，那么 Shift-By-N 策略指定的就是位移的相对数值，即你给出要跳过的一段消息的距离即可。这里的 “跳” 是双向的，你既可以向前“跳”，也可以向后“跳”。比如，你想把位移重设成当前位移的前 100 条位移处，此时你需要指定 N 为 -100。

如何调优 Kafka

Sun, 03 Apr 2022 00:00:00 +0000

调优目标

在做调优之前，我们必须明确优化 Kafka 的目标是什么。通常来说，调优是为了满足系统常见的非功能性需求。在众多的非功能性需求中，性能绝对是我们最关心的那一个。不同的系统对性能有不同的诉求，比如对于数据库用户而言，性能意味着请求的响应时间，用户总是希望查询或更新请求能够被更快地处理完并返回。

对 Kafka 而言，性能一般是指吞吐量和延时。

吞吐量，也就是 TPS，是指 Broker 端进程或 Client 端应用程序每秒能处理的字节数或消息数，这个值自然是越大越好。

延时和我们刚才说的响应时间类似，它表示从 Producer 端发送消息到 Broker 端持久化完成之间的时间间隔。这个指标也可以代表端到端的延时（End-to-End，E2E），也就是从 Producer 发送消息到 Consumer 成功消费该消息的总时长。和 TPS 相反，我们通常希望延时越短越好。

总之，高吞吐量、低延时是我们调优 Kafka 集群的主要目标，一会儿我们会详细讨论如何达成这些目标。在此之前，我想先谈一谈优化漏斗的问题。

优化漏斗

优化漏斗是一个调优过程中的分层漏斗，我们可以在每一层上执行相应的优化调整。总体来说，层级越靠上，其调优的效果越明显，整体优化效果是自上而下衰减的，如下图所示：

第 1 层：应用程序层。它是指优化 Kafka 客户端应用程序代码。比如，使用合理的数据结构、缓存计算开销大的运算结果，抑或是复用构造成本高的对象实例等。这一层的优化效果最为明显，通常也是比较简单的。
第 2 层：框架层。它指的是合理设置 Kafka 集群的各种参数。毕竟，直接修改 Kafka 源码进行调优并不容易，但根据实际场景恰当地配置关键参数的值，还是很容易实现的。
第 3 层：JVM 层。Kafka Broker 进程是普通的 JVM 进程，各种对 JVM 的优化在这里也是适用的。优化这一层的效果虽然比不上前两层，但有时也能带来巨大的改善效果。
第 4 层：操作系统层。对操作系统层的优化很重要，但效果往往不如想象得那么好。与应用程序层的优化效果相比，它是有很大差距的。

基础性调优

接下来，我就来分别介绍一下优化漏斗的 4 个分层的调优。

操作系统调优

我先来说说操作系统层的调优。在操作系统层面，你最好在挂载（Mount）文件系统时禁掉 atime 更新。atime 的全称是 access time，记录的是文件最后被访问的时间。记录 atime 需要操作系统访问 inode 资源，而禁掉 atime 可以避免 inode 访问时间的写入操作，减少文件系统的写操作数。你可以执行 mount -o noatime 命令进行设置。

取消HDP hive默认开启ACID配置

Sun, 20 Mar 2022 00:00:00 +0000

问题描述

原因排查

HDP 的 hive 使用的版本较高为3.1.0 ，默认建表都是使用 ACID 的事务表。而 HDP的spark版本较低为2.3 目前还不支持 hive 的 ACID 功能，因此无法读取 ACID 表的数据，准确来说是内表的数据。

官方资料

spark issues 地址： SPARK-15348 Hive ACID

解决方案

修改hive以下配置，重启hive

hive.strict.managed.tables =false
hive.create.as.insert.only =false
metastore.create.as.acid =false

其他资料

Hive 中支持的表类型和 ACID 特性


表类型	ACID	文件格式	插入	更新 / 删除
托管表：CRUD 事务	是	ORC	是	是
托管表：仅插入式事务	是	任意格式	是	没有
托管表：临时	没有	任意格式	是	没有
外部表	没有	任意格式	是	没有

查看表的属性，指令：desc formatted tb_name

大数据常用命令

Sun, 06 Mar 2022 00:00:00 +0000

Linux（vi/vim）

一般模式

语法	功能描述
yy	复制光标当前一行
y数字y	复制一段（从第几行到第几行）
p	箭头移动到目的行粘贴
u	撤销上一步
dd	删除光标当前行
d数字d	删除光标（含）后多少行
x	删除一个字母，相当于del
X	删除一个字母，相当于Backspace
yw	复制一个词
dw	删除一个词
shift+^	移动到行头
shift+$	移动到行尾
1+shift+g	移动到页头，数字
shift+g	移动到页尾
数字N+shift+g	移动到目标行

编辑模式

按键	功能
i	当前光标前
a	当前光标后
o	当前光标行的下一行
I	光标所在行最前
A	光标所在行最后
O	当前光标行的上一行

指令模式

命令	功能
:w	保存
:q	退出
:!	强制执行
/要查找的词	n 查找下一个，N 往上查找
? 要查找的词	n是查找上一个，shift+n是往下查找
:set nu	显示行号
:set nonu	关闭行号

压缩和解压

gzip/gunzip 压缩

（1）只能压缩文件不能压缩目录