大数据运维工作（Linux，OGG，链路监控，Hadoop运维等）

Posted 2022-09-09 创作者mateo

大数据运维工程师工作内容

Linux运维手册

1. 启动/关闭集群组件

1.1 负载均衡

1）nginx 运维命令
Copy to clipboard
cd /usr/nginx/sbin #进入 sbin 目录
Copy to clipboard
./nginx #启动nginx
Copy to clipboard
./nginx -s stop #停止 Nginx
Copy to clipboard
./nginx -s reload #重启 Nginx

2）配置 Nginx 开机自启动：Nginx 配置开机自启动脚本

1.2 状态服务器

1）Redis 运维命令
Redis 的相关运维命令：Linux 系统 Redis 运维手册
2）设置开机自启动
配置 Redis 开机自启动：Redis 配置开机自启动脚本
配置 Redis 集群开机自启动：Redis 集群开机自启动脚本

1.3 文件服务器

1）vsftpd 运维命令
Copy to clipboard
service vsftpd status #查看 ftp 的状态
Copy to clipboard
service vsftpd start #启动服务
Copy to clipboard
service vsftpd stop #停止服务
Copy to clipboard
service vsftpd restart #重启 ftp
Copy to clipboard
chkconfig vsftpd on #设为开机启动
2）sftp 运维命令
Copy to clipboard
service sshd status #查看 sftp 的状态
Copy to clipboard
service sshd start #启动服务
Copy to clipboard
service sshd stop #停止服务
Copy to clipboard
service sshd restart #重启 sftp

注：sftp 默认是随系统启动而启动的 。

1.4 查看进程与强制关闭方式

对于 Tomcat 容器，shutdown 的关闭方式经常会无法有效杀死进程，建议在关闭 Tomcat 后再用 ps -ef |grep tomcat 检查一下，如果还有残留进程，再 kill 一下，命令如下：
注：2019-12-05及之后版本的 JAR 包可正常使用 shutdown 完全清理所有进程。
Copy to clipboard
ps -ef |grep java #查看所有的java进程
Copy to clipboard
ps -ef |grep tomcat #查看tomcat的进程
Copy to clipboard
kill -9 进程id # 杀死某个进程
其他应用（Nginx、Redis）等进程也可以用这种方式进行查看和杀死。
ps -ef |grep 和 ps aux |grep 基本类似，查看两者的区别：https://www.linuxidc.com/Linux/2016-07/133515.htm

2. 防火墙相关运维操作

2.1 开启/关闭防火墙

1）CentOS6.x &RedHat6.x
Copy to clipboard
service iptables status #查看 iptables 服务的当前状态
Copy to clipboard
service iptables start #开启防火墙
Copy to clipboard
service iptables stop #关闭防火墙
Copy to clipboard
chkconfig iptables on #设置防火墙开机启动
Copy to clipboard
chkconfig iptables off #关闭防火墙开机启动
2）CentOS7.x&RedHat7.x
Copy to clipboard
firewall-cmd --state  #查看防火墙状态（关闭后显示 notrunning，开启后显示 running）
Copy to clipboard
systemctl stop firewalld.service  #关闭 firewall
Copy to clipboard
systemctl start firewalld.service #开启 firewall
Copy to clipboard
systemctl enable firewalld.service #设置防火墙开机启动
Copy to clipboard
systemctl disable firewalld.service #关闭防火墙开机启动

2.2 防火墙开放部分端口

1）CentOS6.x &RedHat6.x
Copy to clipboard
/etc/init.d/iptables status #查看防火墙开放的端口
Copy to clipboard
/sbin/iptables -I INPUT -p tcp --dport 80 -j ACCEPT #开启 80 端口接收数据
Copy to clipboard
/sbin/iptables -I OUTPUT -p tcp --dport 80 -j ACCEPT #开启 80 端口发送数据
Copy to clipboard
/etc/rc.d/init.d/iptables save #保存防火墙配置
Copy to clipboard
/etc/init.d/iptables restart #重启防火墙
2）CentOS7.x&RedHat7.x
Copy to clipboard
firewall-cmd --list-ports #查看已经开放的端口
Copy to clipboard
firewall-cmd --zone=public --add-port=80/tcp --permanent #开放防火墙 80 端口，以实际配置的端口为准
Copy to clipboard
firewall-cmd --zone=public --remove-port=80/tcp --permanent #关闭防火墙 80 端口，以实际配置的端口为准
Copy to clipboard
firewall-cmd --reload #重启firewall

OGG运维

1. ogg提升相关参数解析：

前提：

需要先理解ogg的每个进程都有他自己的checkpoint file，当一个进程看到事务在
commit的时候，检查点文件中会产生一个检查点。ogg的恢复进程就会在检查点作为
起点，而ogg是通过监控的checkpoint和Lag at Chkpt 、Time Since Chkpt指
标来衡量数据同步延迟时效。

1. Chkpt(checkpoint) ： replicat将其读取的trail文件的位置记录为检查点。replicat将这些检查点同时记录在检查点表和检查点的文件中。在
每个事务完成时，replicat将会更新检查点，另外replicat会定期将其当前读取位置写入检查点文件，这些检查点是事务
应用过程的某个点，间隔长度由checkpointsecs参数控制。
2. Lag at Chkpt ： lag是复制进程处理最后一条记录的操作系统时间和此条记录在trail文件中记录的时间戳的差值，这里需要注意的是lag的延迟只有在检查点更新的时候才会更新，所以这个值不是不是实时更新的，具有一定的离散性，实际上应该理解成最后一个检查点的最后一条记录与当前系统的时间差。
3. Time Since Chkpt： :指ogg的extract或者extract进程产生最近的一个检查点，再从这个检查点到目前为止有多长时间没有进行更新，即最近的 一个检查点与当前系统的时间的时间差。这个值可以通过使用info看到是不断的变化的。特别是处理长会话时候，会持续增长直到处理完该长会话。

分析

OGG的lag指的是数据复制的延迟情况，对于不同的进程lag的较长时常分析：
1. extract的延迟：
答：首先要清楚extract是什么。extract是从源端（Oracle或者mysql等数据库）产生的日志情况做解析读取数据的变化，只要正常的运行都是在秒一级别左右，如果出现较大延迟，首先排查是否存在较大的交易，可能进程正在处理中；如果没有大交易但是延迟非常大就需要进一步的排查是什么情况。
（长交易的情况如下报错处理中的第八条）。

2. pump的延迟：
答：一样的，要清楚pump是做什么用。pump是使用network进行（TCP/IP）将源端读取的数据传输到目的端。如果延迟较大，首先查看网络带宽是否被占满，也有可能是短时间内产生了较多的数据变化。

3. replicat的延迟：
答：replicat负责的是数据入库，一般速度相对于前两者的速度较慢，容易产生较大的延迟。如果产生了较答的延迟，需要对进程进行调优或者拆分，（一般是几秒或者一分钟之内）；如果出现批处理的时候，可以允许有一定的延迟，只要是不影响第二天的正常业务即可。比如：定时调度在早上5点左右结束，可以控制在2小时以内即可。

2. 可能报错如下：

1.超过4000字节：
答： 在源端抽取进程添加tableexclude 表名
2.在启动进程的时候提示进程已starting
答： （1）：重新配置新的文件，将原文件下的信息拷贝到新文件下，然后启动
3.源端抽取进程报错提示no free space或CACHEMGR: Cannot allocate virtual memory len
答： 清理源端dirdat下的目录，不能全部删除，删除历史文件，释放空间
4.不兼容的trail文件.
答： 初始化pump进程和DHWT进程
5.ERROR OGG-02028 Failed to attach to logmining server OGG$EXT_AAA error 1,292 - ORA-01292: 上
游捕获的 LogMiner 找不到日志文件.
答： （1）：删除抽取进程
（2）：重新注册进程：dblogin userid ogg，passwordogg123.ps：这个需要一定的权限才能更改
unregister extract <进程名> database
register extract <进程名> database container(pdb)
（3）：重新添加抽取进程。（在上述初始化有）
（4）：重新初始化数据。（安装上述的流程）

6.表字段长度变更的问题如何解决。
答： （1）：新建一个文件<ogg_bc.def>.首先要使用defgen工具从源端获取表结构的信息。配置文件如下：
userid EMSS_OGG,password dwefrfdfsfa,encryptkey default
defsfile /<目录地址><自己新建的文件> purge（这里后面要加上purge，这个的意思就是如果文件生成有同名的话可以覆盖这个文件。不加有可能会报错，这里看ogg 的版本。）
table <表名>;
（2）：使用./defgen paramfile /<目录地址>生成文件
（3）：发送到目标端，这里如果不方便发送也可以选择复制粘贴过去。
（4）：配置目标端加上：SOURCEDEFS ogg_bc.def OVERRIDE
例如：
userid EMSS_OGG,password sdfghjksdfghj,encryptkey default
defsfile /ogg/ogghome/ogg_ba.def purge
table EMSS_BAC.PREAPP_FORM_APRV_HIS;

7.Failed to retrieve all chained row fragments on table,record(1),in transaction850,132.00a2 (0x0008.001c3b14.30,392). Position (2,390,234,300, 10). 8.1,
答： 这个属于内部错误。目前的处理方法是
（1）：在源端抽取进程添加tableexclude 表名。（90%有用，但是需要定时走di）
（2）：重启节点（不一定有用，可以试试）。
（3）：升级ogg（排除，稳定的状态下不建议使用）。

8.长交易处理方式WARNING OGG 01027 Long Running Transaction：XID 82.4.242063,Items 0, Extract YX_EXT1,Redo thread 1,SCN 2379.21327758…
答：（1）.查看是否存在长交易，里面的xid与告警日志对应，通过xid找到sql_text
send extract [进程名]，showtrans [thread n] [count n]
其中count n表示只显示n条记录，thread n查看其中一个节点的未提交交易。
例如：查看xxx进程中节点1上最长的10个交易，可以通过下面的命令
send extract xxx, showtrans thread 1 count 10
（2）.查找长事务对应的sql语句:
XID由三部分组成，XIDUSN.XIDSLOT.XIDSQN
XID 82.4.242063
通过XID查找对应的sql语句，后续具体问题具体分析。
例如：
select /+ rule/b.USERNAME,b.SCHEMANAME,b.OSUSER,b.MACHINE,c.SQL_TEXT
from v$transsactiona,v$session b,v$sql c
where a.XIDUSN = 82
and a.XIDSLOT = 4
and a.XIDSQL = 242063
and a.ADDR = b.TADDR
and b.SQL_ADDRESS = c.SQL_ADDRESS
and b.SQL_HASH_VALUE = c.HASH_VALUE;
（3）.长事务临时解决，源端可以执行
SEND EXTRACT xxx,SKIPTRANS <82.4.242063> THREAS <2> //跳过交易
SEND EXTRACT xxx,FORCETRANS <82.4.242063> THREAS <1>//强制认为该交易已经提交
使用这两个解决方式，只会让GoldenGate进程跳过交易或者强制认为交易提交。并不会改变数据库中的交易，它们依旧存在于数据库中。
因此强烈建议使用数据库中提交或者回滚交易而不是使用OGG处理。但是对于我们的实际任务中，使用数据库处理并不现实，所以如果使用
这个方式，需要重补数据。
（4）.可以通过配置extract进程参数warnlongtrans调整告警频率
edit params xxx
warnlongtrans 5h,checkintervals 1h
这个的意思是每隔1小时检查一下长交易，如果超过5小时的长交易会记录在ggserr.log中。
（5）.此外，在停止进程时候也会遇到长事务，若状态为不活跃可终止，也可以进行跳过此事务的交易。
【例子：】此例子是停止进程失败，报长事务的解决方案。
[解决方案：
问题： Long Running Transaction: XID 158.25.3353075, Items 1, Extract EXT_CSC, Redo
Thread 1, SCN 7.2777803912 (32842574984), Redo Seq #41101, Redo RBA 2748953616.
答：在OGG中跳过oracle DB长事务
send EXTRACT EXT_DDD , SKIPTRANS 93.10.3013282 THREAD 1 跳过长事务。
GGSCI (yxcxdb2) 23> send EXTRACT EXT_CSC , SKIPTRANS 158.25.3353075 THREAD 1
Sending SKIPTRANS request to EXTRACT EXT_CSC …
Are you sure you sure you want to skip transaction XID 158.25.3353075, Redo Thread 1, Start Time 2022-08-30:10:29:36, SCN 7.2777803912 (32842574984)? (y/n)y
Sending SKIPTRANS request to EXTRACT EXT_CSC …
Skiptrans operation successfully processed. Transaction XID 158.25.3353075, Redo Thread 1, Start Time 2022-08-30:10:29:36, SCN 7.2777803912 (32842574984) skipped]
9…修改oracle字段长度
答：sqlplus / as sysdba --进oracle库
alter table EMSS_CSC.SUPL_STOP modify(ISSU_CHAN_DESC VARCHAR(3000 CHAR)); --修改oracle字段长度

升华性问题：（文档参考阿里云）
10.遇到日志正常但是topic检测不到数据，在dirrpt目录下对应的进程这个日志（DHWT_XXX-access.log）
长时间没有更新，查看对应节点的日志文件如下：
[main] WARN DatahubHandler - dsOperation.getPosition(): 00000000390158034805
old sendPosition is: 00000020630126910510, Skip this operation, it maybe duplicated!!!
答：datahub-ogg-plugin.log：插件日志，Datahub插件进程打印的日志，一半以上的问题都可以跳过这个
插件日志来观测到并解决。在插件目录的log目录下面。
ggserr.log：监控日志，一般记录用户的操作记录和观测操作是否成功。一般extract进程配置错误，或
者缺少动态库文件报错记录就会记录在这个文件中。
dirrpt：report文件，可以观测到进程运行时的报错信息（view report 就是查看这个文件夹下的某个文件）。
如果数据正常传输到目标端，ggserr.log和插件日志都没有报错很有可能放在这个文件中。
dirchk：ogg的点位文件，记录该进程的点位信息。
datahub-ogg-plugin.chk：datahub插件自己本身的点位信息。
Q:出现数据无法写入datahub：
解决方案：
A：测试监测整条链路（ogg和datahub的点位文件的修改或者删除）。
*检查源端dirdat是否有数据进入，如果没有就是extract的问题。
*检查目标端的dirdat文件是否有数据，如果没有就是PUMP的问题。
*检查插件日志是否有记录，有可能是插件自己的点位文件导致直接忽略了数据或者就是插件本身的报错（最常见）（我归类为bug）
*如果插件日志没有数据显示，数据也是正常进来的情况，查看dirrpt下的access.log，和XXX.log，和XXX.log，和XXX.log
的信息，有可能是ogg自己的点位检查直接忽略掉数据了。
*检查oracleSchema配置是否正确，有可能是oracleSchema和源端不匹配导致的数据被忽略。
Q:无法配置rowid，其余数据正常。
解决方案：
A:多数是配置文件出错，仔细检查一下配置信息。
*检查版本，2.3.0才可以获取到rowid。
检查源端extract 是否正确配置token，table EMSS_ASC.,tokens (TKN-ROWID=@GETENV(‘RECORD’,‘rowid’));
是否写错。
*检查目标端configuration.xml是否配置了rowid，ext_ogg_seq
*检查抽取数据（logdump）是否成功获取rowid。这里需要使用logdump工具。
Q:[main] WARN DatahubHandler - dsOperation.getPosition(): 00000000390158054276 old sendPosition
is: 00000020630126910510, Skip this operation, it maybe duplicated!!!
A:多数是因为源端重启导致的。
*删除点位文件dayahub_ogg_plugin.chk，然后重启目标端进程
*如果删除点位文件仍然无法解决，可以尝试禁用插件的点位文件来解决，但是可能会导致重复。

Hadoop运维

1. 负责大数据平台/推荐系统/等产品的架构、研发和持续优化
2. 和业务团队深入合作，解决在业务发展中遇到的产品和平台架构问题；具备一定的前瞻性；
3. 负责搭建效果监控平台，数据质量监控平台，数据中心建设，算法模型平台化建设；
4. 基于Hadoop生态圈进行扩展研发，构建统一的DataInfrastructure，在开源的基础上研发统一支持Batch和Streaming的计算引擎，SQL、NoSQL、，以及自动化运维平台管理超大规模集群。
   作者：拼客网络安全学苑
   链接：https://www.zhihu.com/question/350277431/answer/868404806
   来源：知乎
   著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

一.HDFS运维工作

1. 容量管理

第一：HDFS空间我使用超过80%要警惕，如果是多租户环境，租户的配额空间也能用完；
第二：熟悉hdfs，fsck，distcp等常用命令，会使用DataNode均衡器；

2. 进程管理

第一：NameNode的进程是重点
第二：熟悉dfsadmin等Ingles。怎么做NameNode高可用。

3. 故障管理

Hadoop最常见的故障就是硬盘损坏。

4. 配置管理

1. hdfs-site.xml中的参数设置。这里的参数配置主要是修改hdfs的相关参数。

二.MapReduce运维工作

1. 进程管理

第一：jobtracker进程故障概率比较低，有问题可以通过重启解决；
第二：了解一下HA的做法；

2. 配置管理

mapred-site.xml中的参数设置。

三.Yarn运维工作

1. 故障管理

主要是当任务异常这中止时看日志排查，通茶故障原因会集中在资源问题，权限问题中的一种。

2. 进程管理

ResourceManager主要是学会配置HA NodeManager进程挂掉不重要，重启即可。

3. 配置管理

yarn-site.xml中的参数设置：
主要分三块配置：scheduler的，ResourceManager的，NodeManager的。

四.Hive/Impala运维工作

hive的运维放在这里是因为，这里的hive替代了mapredue计算引擎

1.SQL问题排查

第一：结果不对，主要原因可能是SQL错误，数据不存在，UDF错误等，需要靠经验排查
第二：慢SQL，这类问题开发经常会找运维排查，有可能是劣势SQL，数据量大，也有可能是集群资源紧张；（sql优化）

2. 元数据管理

Hive和Impala公用的元数据，存在关系型数据库中。

五.其它组件

根据组件用途，特性，关注点的不用，运维工作也各不相同，如：

1. HBase关注读写性能，服务的可用性
2. Kafka关注吞吐量，负载均衡，消息不丢机制
3. Flume关注屯度量，故障后的快速恢复

1.集群管理

大数据需要分布式系统，也就是集群：Hadoop，Hbase，Spark，Kafka，Redis等大数据生态圈组建。

2.故障处理

1 . 商用硬件使用故障是常态，硬件的维护包括服务器（刀片服务器）的维护与故障排除。
2. 区分故障等级，优先处理影响实时性业务的故障。保障整体性的功能正常运行。比如：ogg在实时读取数据的时候，超过4000字节的部分，先排除这个表，至于是走离线还是改成clob字段，另外再商议。

3. 变更管理

1 . 以可控的方式，高效的完成变更工作；
2. 包括配置管理和发布管理；

4.容量管理

1. 存储空间，允许链接数等都是容量概念；
2. 在多用户环境下，容量管理尤其重要；

5.性能调优

1. 不同组建的性能概念不一样，如kafka注重吞吐量，Hbase注重实用性可用性;
2. 需要对组建有深刻的理解

6.架构优化

1. 优化大数据平台架构，支持平台能力和产品的不断迭代;
2. 类似架构师的工作；大数据运维所需的能力
   • 一.DevOps： DevOps(英文Development和Operations的组合)是一组过程，方法和系统的统称，用于促进开发（应用程序/软件工程），技术运营和质量保障（QA）部门之间的沟通，写作与整合。
   • 二.硬件：OS，网络，安全的基础知识 大数据平台和组建设计范围广，各种都需要懂一点，这些知识出问题的时候不可能问人，因为别人也有自己的工作要做。
   • 三.脚本语言能力： Shell,SQL(DDL),Python.Java（加分）
   • 四.大数据各个组件知识 ： 设计思想。使用范围，底层架构，常用命令，常用配置或参数，常见问题处理方法。
   • 五.工具能力： Zabbix，Open Falcon，Ganglia，ELK等，企业自研工具。我推荐使用集群自带的工具。
   • 六.Trouble shooting能力： 搜索能力（搜索引擎，stackoverflow等），java能力（异常堆栈要看得懂，最好能看懂源码），英文阅读能力。
   • 七.意识，流程 良好的意识，什么能做什么不能做。同用的流程如ITIL，各企业也有自己的流程。大数据运维的主要工作一.运维三板斧 三板斧可以解决90%以上的故障处理工作。
     • 1. 重启 重启有问题的机器或经常，使其正常工作。
     • 2. 切换 主备切换或主主切换，链接正常工作的节点。
     • 3. 查杀 查杀有问题的进程，链接等。
     • 4. 三板斧的问题： 第一：只能处理故障处理问题，不能解决性能调优，架构优化等问题； 第二：只能治标，不能治本；
     • 5. 大数据运维和传统运维的不同：
       • 第一：传统运维面对的底层软硬件基本稳固，大数据运维面对的是商用硬件和复杂linux版本；
       • 第二：传统运维面对的是单机架构为主，大数据运维面对复杂的分布式架构；
       • 第三：传统运维大多维护闭源商业版系统，大数据运维通常面对开源系统，文档手册匮乏，对阅读源码要求高。
       • 第四：大数据运维对自动化工具的依赖大大增加；
   • 二.Iaas层（基础设置及服务）运维工作：
     • 一般中大型企业有自己的基础设施维护团队，这部分工作不会交给大数据运维来做。小公司可能需要大数据运维键值这部分工作。
     • 主要关注三个方面：
       • 1. 硬件 大数据系统大多使用廉价PC Server或虚拟机，硬件故障是常态，通过告警，日志，维护命令等识别故障，并支持硬件更换。
       • 2. 存储 大多使用PC Server挂本磁盘的存储方式，极少情况会使用SAN（存储区域网络）或NAS（网络附属存储），熟悉分区，格式化，巡检等基本操作。
       • 3. 网络 网络的配置变更更需要比较专业的知识，如有需要可学习CCNA，CCNP等认证课程，但网络硬件和配置出问题概率很低，主要关注丢包，延时。