- 此系统已实现的功能
- 经验之谈
- 需要怎么样的服务器
- 推荐的hdfs部署方式
- hdfs_nameservice划分
- hdfs目录规范
- zookeeper集群划分
- yarn集群划分
- yarn_queue规范
- kafka集群划分
- kafka规范
- 收集服务Canal/Flume集群划分
- hbase集群划分
- data_warehouse规范
- 业务打log规范
- 集群划分建议原则
- master节点规划
- 系统分区和挂载
- 元数据在哪几个地方
- 不错的patch
- 小文件合并
- 监控告警
- 网络平面
- 集群组网
- 主机网卡配置
- 典型业务调优
- 组件安装部署的前提
- 组件安装顺序
- 安装步骤
- 自动部署和扩容大数据组件
- 组件日志管理与扩容步骤
- hdfs扩容
- namenode/ldap/kdc/keytab备份与恢复
- namenode都是standy/active怎么办
- 安全组件ranger原理/注意项/插件开启
- kerberos开启/jce验证keytab缺失怎么处理
- 组件升级
- 组件监控告警
- 下载服务器的目录
- ambari_service开发步骤
- 大数据参考资料
实现了常用的功能
主要有:
1 支持社区版的大数据组件(tar.gz包)自动安装部署升级
2 组件的配置都是经过生产实践考验的配置(100PB+数据 , 2k+ server, 20w+job/天)
3 68个组件的安装部署升级
4 组件的存活监控 和url监控
5 组件的日志集中管理
6 操作审计(hdfs,hive,hbase,kafka,storm等) 能知道谁在什么时候操作了什么资源
7 权限控制(支持hdfs,hive,hbase,kafka,storm等) 支持行列级的权限管理
8 监控告警(不止是系统的监控 还包括各种组件的jvm metrics的监控)
9 自动扩容
1, 业务刚起步,推荐使用google analytics(支持自定义事件和留存事件分析)/友盟/腾讯分析,不够用了再推荐使用阿里云的大数据套件或神策数据的私有化部署,最后万不得已再自己搭建，原因很简单，大数据是链路长投入大难产出的东西,第三方提供的不只是环境准备还有一整套做事方法和规范
2, 自己搭建的情况下要对未来3年左右的机架位有规划(如果业务发展快没规划而导致有钱买机器但买不到机架位置,那么就只能搬机房了,而搬机房的拷数据的耗时是按数月计)
3, 不管有多少集群 只有一套ldap(用户管理,可做主从同步) 一套kdc(安全票据) 一套ranger(授权和审计) 一套atlas(元数据管理 数据血缘)
4, 尽早建立包括hdfs目录规范,yarn队列规范,数仓表规范,kafka topic命名规范
5, 尽早建立多租户隔离机制,日志审计机制 (可用ranger解决)
6, 尽早建立quota机制,hdfs小文件周期性合并功能
7, 尽早建立埋点规范和埋点系统,业务打log规范
8, 尽早建立元数据系统和数据血缘关系系统（可用开源的atlas解决）
9，可通过kafka作为数据通道 用kafka的schema registy 把整个链路的schema管理起来
划分多个集群，通过federation共享共通数据
1 yarn logs,tmp
2 warehouse
3 hbase
4 streaming
按业务或者组来划分目录
以下是推荐的根目录 ，然后在此根目录的基础上按业务或组来划分
/logs yarn log /spark log / mr log
/warehouse 数仓
/tmp 临时目录
/hbase hbase目录
/user 用户目录
/revenue 营收
/ext 扩展 存放jar等
/checkpoints
划分多个集群 提高稳定性
1 hbase/streaming/kafka
2 warehouse/batch
3 other
划分多个集群 提高稳定性，后续可通过yarn federation统一资源调度
1, streaming
2, batch
3, other
按 部门.业务组 划分队列
比如 department.business
划分多个集群 提高稳定性
1, 用户行为上报/nginx logs
2, db binlog
3, other
Kafka中Topic命名规范: department_business_feature
partition数目为磁盘数目的4倍（也就是说每个盘上放4个partition）时候kafka的性能最优
worker数目最好与parition数目相等
离线
实时
大业务单独集群
公共/其他业务通过regionserver group隔离
数仓分层和数据质量管理很重要
数据分层不好的话 导致的直接结果是浪费计算资源和存储资源
质量不过关的数据还不如不搞
ODS和DWD层尽量做到和离线链路的复用
https://blog.csdn.net/zhaodedong/article/details/85293955
https://blog.csdn.net/zhaodedong/article/details/73385647
http://tech.weli.cn/2017/12/29/dataware-intro/
参考阿里的数仓命名规范:
ods层 命名规则：ods_{源系统类型}_{源系统表名}_[{刷新周期标识}{增量全量标识}] 统一设备纵表-实时（DataHub）：ods_dcs_prd_mc_point_r 统一设备纵表-离线（MaxCompute）：ods_dcs_prd_mc_point_di
dws层 命名规则：dws_{一级主题域}_{二级主题域}_{数据粒度}_{业务名称}_{统计周期} 例：转炉炼钢钢包粒度最近1天汇总表 dws_prd_sm_ladle_bof_1d 注：根据需要业务名称可细化为多个的组合 对于刷新周期标识和增量全量标识在dws层不做强制要求，默认不需添加
dwd层 命名规则：dwd_{一级主题域}_{二级主题域}_{业务名称}_{刷新周期标识}{增量全量标识} 例：转炉炼钢明细小时增量表 dwd_prd_sm_bof_hi 注：根据需要业务名称可细化为多个的组合
大数据组件部署的原则是混部 计算尽量靠近存储 大部分都是写入后不修改的append操作
主要需要3类机器
1类是master(10台左右就够)
典型比如namenode 需要超大内存推荐512G 4个ssd硬盘做raid1备份
1类是存储型机器，分2种 一种主力机型 一种归档机型
主力机型（例如浪潮NF5280M5,NF5466M5/华为2298V5,5288V5） 典型如datanode/kafka 2U的机器,前置12块+后置4块盘，每盘8T，内置2块ssd盘 sata盘 不做raid 内存也尽量256G以上
归档机型 (例如浪潮NF5486M5/华为5288V5) 4U的机器 支持106块8T盘
1类是client型机器
一般用来提交job的 类似gateway的角色 一般虚拟机即可
其它关键业务服务器(hot/warn/cold中hot机型)
(例如NF5180M5,NF8260M5/华为2288V5,2488V5)
网络
单万兆网卡即可 不做bond
kafka 是典型的网络瓶颈型 可配置双万兆网卡 做bond6
主要注意点是/var 需要单独分区 给个100G/200G 主要用来存组件日志 大数据的日志都非常多,虽会自动轮转 但也怕写爆/目录
master /var/log /data0 /data1
data /var/log /data0 /data1 /data2 /data3 /data4 /data5 /data6 /data7 /data8 /data9 /data10 /data11
client /var/log
大数据组件的 主要在 hive的metaserver db , zk , db , hdfs ,kafka , hbase
linux用户数据主要在ldap 安全票据在kdc
http://blog.jobbole.com/56574/
https://zhuanlan.zhihu.com/p/27363484
https://dbaplus.cn/news-134-1658-1.html
https://jira.apache.org/jira/browse/YARN-4948
https://issues.apache.org/jira/browse/HDFS-2139
https://issues.apache.org/jira/browse/HDFS-12943
https://issues.apache.org/jira/browse/HDFS-8966
https://issues.apache.org/jira/browse/SPARK-23128
parquet: hadoop jar ./parquet-tools-1.11.0.jar merge -b -l 512 /input_directory/ /output_idr/file_name
合并后删除/input_directory/ 中的小文件的源文件（上述命令的输出结构中有被合并的文件列表）
2种方式:
1,在grafana配置告警,grafana版本>5的都支持(推荐)
2,实现 alert_dispatcher.py里自定义告警函数 。然后执行 alert_dispatcher.sh 把这个告警功能加到server中
数据(datanode)统一（可通过hdfs federation 实现namenode隔离），计算分离（通过yarn nodelabel 或 yarn federation）
隔离实时和非实时工作负载：对实时性要求比较高的负载采用独立集群。
根据业务对硬件资源的根本性差异（含CPU/内存/磁盘/网络），建议按照SLA等级，将不同业务拆分部署。如Mapredue通常是磁盘密集型应用，
Spark通常是CPU/内存密集型应用，冷数据归档一般需要高密存储。混合负载的基础分析集群需要具备分级存储和标签调度能力。
整个系统网络划分为2个平面，即业务平面和管理平面，两个平面之间采用物理隔离的方式进行部署，保证业务、管理各自网络的安全性。
业务平面通过业务网络接入，主要为用户和上层用户提供业务通道，对外提供数据存取、任务提交及计算的能力。
管理平面通过运维网络接入，提供系统管理和维护功能，主要用于集群的管理，对外提供集群监控、配置、审计、用户管理等服务。
上层组件业务一般可以分为IO密集型业务，计算密集型业务，低延迟业务，高吞吐量业务。
【1】低延时业务
计算密集型业务，低延迟业务，这一类业务通常是对大量NameNode文件目录访问为主的。
因此需要针对NameNode的处理能力进行调整。主要可以采取以下措施：
1.利用federatian来增加新的NameNode的方案实现。把优先级高的业务部署在单独的NameNode，以解决资源使用问题。
2.在业务高峰期的时，可以暂时关闭HDFS的审计日志和把运行日志级别修改为WARN级别。当业务降低的时可以在调成INFO级别。
3.使用HDFS DataNode I/O隔离的特性，将低延迟业务的权重值增大。
4.硬件能力提升（提升NameNode节点的CPU主频、更换DataNode的磁盘为高性能磁盘或者SSD、减少网络带宽延迟。）。
【2】高吞吐量业务
高吞吐量业务，这一类业务主要是大文件操作，对DataNode的IO需求更高。主要可以采取以下措施：
1.扩容DataNode的节点数量，提高集群的吞吐量。
2.扩容DataNode节点的磁盘数量，以提高单DataNode的I/O能力。
3.更换DataNode挂载的磁盘类型，使用更高性能的磁盘或者SSD。
【3】实时数据
实时数据需要HDFS能尽快响应业务请求，对节点性能有较高的要求。为保证业务实时性,
一般采用配置高性能的节点，并将业务隔离的方案。主要可以采取以下措施:
1.采用标签存储，将存储节点按性能进行分组，让高性能的节点为其提供业务。
2.数据节点采用SSD存储介质。
3.采用Federation特性，隔离NameNode以及数据节点。
【4】频繁访问数据
频繁访问的数据一般指写入完成后，需要重复读取，偶尔有修改变化的数据。
对于这一类数据，主要可以采取以下措施：
1.使用Central Cache特性，将对应的文件缓存到内存。
2.使用分级存储的特性，将对应的文件存储到SSD介质。
【5】临时数据
临时数据一般是指在写入完成后，立即进行业务处理，处理完成后删除的数据。
对于这一类数据，主要可以采取以下措施：
1.使用分级存储，将数据存储到RAM盘。
2.将副本设置为2个，减少系统存储和网络压力。
【6】 归档数据
归档数据是指数据存储到集群后，一段时间不再访问的数据：
对于这一类数据，主要可以采取以下措施：
1.使用HDFS数据生命周期管理特性（冷热数据迁移），进行数据自己迁移，
可以将冷数据迁移到归档目录或者I/O性能较慢的存储介质上，也可以减少副本数等。
2.存储数据时，可以采用HRM格式存储或者采用SmallFS小文件合并功能。
3. 使用标签存储特性，将这些数据存储到高密节点上（Archive）。
-
三层ECMP组网
-
组网特点：
三层扁平汇聚
ECMP实现汇聚负荷分担
汇聚路由可线性扩展
一个逻辑机架一个子网，机架内二层交换
- 适用场景:
集群节点数大于500或后续有可能扩展到大于500
接入/汇聚交换机支持三层交换
每个节点的两个端口配成bond，分别接入两个接入交换机 不堆叠 无TRUNK Bond模式：mode= 6
采用自适应负载策略(balance-alb-rlb,Adaptive load balancing)。
网络流量bond的两个子端口上均衡分配，汇聚流量较大
主节点相关角色放到不同的机架上，Zookeeper，JournalNode节点放到不同机架
nodemanager 一般只跟datanode混部, datanode可跟nodemanager/regionserver/kafka brocker/storm supervisor/solr/es/presto worker等 混部
master0 (JournalNode/zk/HMaster/HiveServer/MetaStore/WebHCat/spark JobHistory/ThriftServer)
master1 (zk/HiveServer/MetaStore/WebHCat/spark JobHistory/ThriftServer)
master2 (zk/HMaster/HiveServer/MetaStore/WebHCat/ThriftServer/EsMaster)
master3 (zk/ResourceManager/EsMaster)
master4 (zk/ResourceManager/EsMaster/mr JobHistoryServer)
master5 (JournalNode/NameNode/airflow master)
master6 (JournalNode/NameNode/airflow master)
master7 (ldap/keberos server/Nimbus/UI)
master8 (ldap/keberos server/Nimbus/UI)
master9 (HiveServer/MetaStore/WebHCat/spark JobHistory/ThriftServer)
master10 (HiveServer/MetaStore/WebHCat/spark JobHistory/ThriftServer)
Stop the ZKFC
su - hdfs
hdfs zkfc -formatZK
restart ZKFC & HDFS
1 准备数据库和java环境
2 参考执行 https://raw.githubusercontent.com/xiaomatech/dataops/master/ambari_server_install.sh
3 注意修改配置中的 http://assets.example.com
4 准备assets的web服务 目录参考 assets.jpg
### 部署环境要求
1 hostname能通过dns解析
检验方法 dig `hostname`
2 /etc/yum.repos.d 下 yum源正常
确保能正常安装jdk,ambari-agent,openldap-client,kerberos client
yum install -y snappy snappy-devel lzo zlib bzip2 libzip openssl libtirpc-devel tar
curl jdk openldap-clients nss-pam-ldapd pam_ldap pam_krb5 authconfig krb5-libs libcgroup java-1.8.0-openjdk
3 ambari-server 有个rsa key能登录到被管理的机器
2个可选方案:
1,ambari-server生成的pub key分发到被管理机器
2,使用安装系统的时候初始化好的本地账户,类似yunwei这种神账号
4 被管理机器要能ping通ambari-server,因为要注册agent和发送回心跳
5 执行 build_private_repo.sh/download_bigdata_plugin.sh/download_intel_mkl.sh
下载各组件到本地 创建类似mirrors.aliyun.com的下载服务器
6 能ping通cmdb(需要获取hadoop机架感知数据 如果没有这接口则没有自动机架感知功能)
1 安装zk
2 安装openldap/kdc 或者 zookeeper-env填写对应的kdc_hosts,ldap_hosts
3 启动kerberos(可选)
blueprint介绍
ambari用来自动部署大数据组件的功能
参考
https://cwiki.apache.org/confluence/display/AMBARI/Blueprints
https://community.hortonworks.com/articles/78969/automate-hdp-installation-using-ambari-blueprints-4.html
日志管理介绍
大数据除了组件自身的job日志会汇总到hdfs外
还有 ranger的审计日志,atlas的搜索功能,组件运行日志(logsearch) 存储在infra solr(solrcloud)中
对应的collect的关系
ranger -> ranger_audits 默认保存14天
logsearch -> hadoop_logs(组件的运行日志), audit_logs(hdfs audit log) 默认保存7天
atlas -> edge_index,vertex_index,fulltext_index 默认保存7天
现阶段是用solrcloud分了32个shard
扩容步奏参考solr官方文档
在ambari添加机器并安装datanode
在ambari页面 刷新namenode下的配置(做了机架感知 没刷新的时候是默认/default-rack ,datanode加不进集群)
namenode 元数据(fsimage)备份与恢复
备份在/data/backup/namenode 。备份周期：每天凌晨一点备份 全备份,保留3天 。
备份命令/data/backup/namenode.sh
恢复步骤 :
https://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.6.2/bk_hdfs-administration/content/get_ready_to_backup.html
ldap/kdc 备份与恢复
备份:
在每台kdc的/data/backup/ldap 备份命令/data/backup/ldap.sh 备份周期: 每小时一全备 保留3天
恢复:
先删除所有条目： ldapdelete -x -D "cn=manager,dc=example,dc=com" -w "密码" -r "dc=example,dc=com"
恢复：ldapadd -x -D "cn=manager,dc=example,dc=com" -f /data/backup/ldap/ldap_时间.ldif -w 密码
keytab 备份与恢复
每次操作前都会备份/etc/security/keytabs下到/data/backup/keytab
支持恢复到之前任意一次的keytab
恢复的时候注意保留文件权限 使用 cp -rpf /data/backup/keytab/时间/keytabs/* /etc/security/keytabs/
解决的问题
hdfs,yarn,hive,spark,hbase,storm,kafka,atlas,solr等的统一权限管控
管理的数据流
ranger-admin 负责策略存储和提供 http restful api对外提供策略查询和修改服务
ranger-usersync 负责把用户,用户组数据从ldap中同步到ranger
ranger-tagsync 负责把atlas上打的标签同步到ranger
插件的数据流
1 插件启用后 会http定期(默认30秒)从ranger-admin下载策略到本地/etc/ranger
2 通过解析策略成类似一个大hashmap 当请求过来的时候有个filter(checkPermission)做权限控制
3 结果日志写回到solr,hdfs(新版的支持kafka没开启)
影响的组件
主要是对应的master节点:hdfs是namenode,yarn是resourcesmanager,hive是hiveserver2,
hbase是master,regionserver,kafka是broker,storm是nimbus
注意点
1 hadoop-env.sh,yarn-env.sh,hive-env.sh,hbase-env.sh等要把ranger的jar加入到对应的classpath 使能找到对应的类
2 hdfs-site.xml,yarn-site.xml,hbase-site.xml,hiveserver2.xml要加入对应的filter类
安装的时候在 ranger-env中可以修改对应的版本 ，修改后重启对应的插件就会自动升级到指定版本的插件
介绍
kerberos是一个安全交互协议
jce是jdk中用来加解密的jar包
oracle jdk中没有带jce 需要自己安装
openjdk 自带jce
查看kdc地址
cat /etc/krb5.conf |grep 'kdc ='
查看jce状态 kerberos模式下 应该开启
/usr/java/default/bin/java -jar /var/lib/ambari-agent/tools/jcepolicyinfo.jar -tu
keytab 备份与恢复
每次操作前都会备份/etc/security/keytabs下到/data/backup/keytab
支持恢复到之前任意一次的keytab
恢复的时候注意保留文件权限 使用 cp -rpf /data/backup/keytab/时间/keytabs/* /etc/security/keytabs/
keytab缺失处理
尽量不要用重新生成
除了hdfs外 都支持修改配置后重启来自动升级
1 修改对应组件的download_url
2 重启
3 升级完成
1 了解对应的service的构成,基本原则是一个component管一类守护进程,有多少类守护进程就有多少个component
2 复制示例 services\EXAMPLE 目录
3 修改 metainfo.xml 里的名字 ,component配置 必须全局唯一
4 修改kerberos的配置kerberos.json
5 修改监控配置alerts.json(可配置成自带的功能端口监控,url监控)
6 修改configuration目录中的配置(这个主要用来在web页面做配置管理)
7 实现package 目录 实现install,start,stop,status,restart方法(这个目录用来下发给agent执行)
8 把对应的目录打包拷贝到ambari-server的/var/lib/ambari-server/resources/stacks/XIAOMATECH/1.0/services
9 重启ambari-server /etc/init.d/ambari-server restart
10 进入http://ambari-server_ip:8080 安装部署对应的service
1 最权威的是官方文档
2 hdp官方文档 https://docs.hortonworks.com/HDPDocuments/HDP3/HDP-3.1.0/index.html
3 真实电商数据仓库全流程开发详解 https://chuanke.baidu.com/v1538386-116215-258987.html
4 青云七天学会大数据 Pro版 https://study.163.com/course/courseMain.htm?courseId=1003605105
5 阿里大数据平台核心技术 http://www.xuetangx.com/courses/course-v1:TsinghuaX+60240202X+sp/about
6 大数据科学与应用系列讲座 http://www.xuetangx.com/courses/course-v1:TsinghuaX+60250131X+sp/about
自带支持5种类型监控告警
1 port监控告警 用来监测机器上的一个端口是否可用
2 web状态码的监控告警 用于监测一个 WEB UI（URL）地址是否可用
3 SCRIPT Alert 的监测逻辑由一个自定义的 python 脚本执行
4 metric 用来监测 Metric 相关的配置属性
5 aggregate 用于收集其他某些 Alert 的状态
具体参考 hdfs service下的 alerts.json的配置