目录
设计背景
问题点
中台目标
复用，赋能，降本增效
中台整体架构
Pass层技术选型
KAFKA（未来pulsar也不错）"> 实时存储平台----------->KAFKA（未来pulsar也不错）
离线存储平台（Hadoop系列）
Hadoop选型
机架感知
硬件选型(PB级)
内存配置
资源计算
关键参数
存储平台常见故障
调度系统（Yarn）
管理平台
Ambari
Cloudera ManagerCloud
自研+开源组件
日志采集
调度平台
实时数据Sql查询平台
设计背景
当企业发展到一定规模时候有了不同的业务线以及数据规模，因为业务的快速发展。这个时候一些数据问题就会出现。
问题点1:数据脏乱差，各部门生产线数据重复冗余，还不可:复用用存在数据孤岛
2：数据开发部门的业务来自各部门各产品线，需求不明确，每天业务量繁复，日常工作可能成了sqlboy到处捞数据，而且在业务方面还没有业务部门了解的深入，有点缘木求鱼的意思。
这个时候数据中台也就应运而生。
中台目标 复用，赋能，降本增效1：面向业务，数据进行建模。
2：数据整合避免烟囱式开发解决数据孤岛问题。
3：赋能给各个业务部门，将能力下放将数据的使用权限赋予各个部门，减少数据开发部门繁琐的数据sql业务。
中台整体架构 Pass层技术选型 实时存储平台----------->KAFKA（未来pulsar也不错）0.8版本标志着kafaka成熟
0.9版本提供了安全模块，偏移量也由zk转移到自己的topic进行管理了
0.10版本提供了流计算，生产者优化（提供了批次发送，默认16k发送一次），提供了机架感知
0.11版本生产者提供了幂等性和事物
1.x没啥特别优化
2.x优化stream，安全力度更细
所以0.11版本后都可以，版本太高也要考虑兼容性问题
tips：kafka因为内存是页存储，磁盘是顺序读写，因为顺序读写速度不亚于内存。所以kafka对于是内存还是磁盘需求不大
样例：假设平台每天接受一亿次实时请求，kafka如何hold住？
每天集群需要承载1亿数据请求，一天24小时，对于网站，晚上12点到凌晨8点这8个小时几乎没多少数据。使用 二八法 则估计，也就是80%的数据（8千万）会在其余16个小时涌入，而且8亿的80%的数据（6.4千万）会在这16个小时的20%时间 （3小时）涌入。 qps = 64000000/（3*60*60）= 6000，则高峰期每秒并发6000 每天1亿数据，每个请求10 kb ，也就是1T的数据。如果保存3副本，1 *3=3T， 假设kafka默认保留最近7天的数据。故需要 3 * 7 =21T tips （默认时间可以根据资源需求降低） 一个集群高峰期肯定还有很多其他业务要处理，所以高峰期的qps要控制在集群能承受的百分之30左右，所以集群能承受的总的qps在2w左右。一般来说一台物理机能承受的qps在4w左右。再加上消费者请求3三台左右就比较理想，而且kafka一般都是集群的3台起步。所以很合适。 磁盘：三台物理机需要存储21T数据，则每台7块磁盘，每个磁盘1T就可以了。tips(最好配置上kafka 的log.dir避免数据全部写到一个磁盘导致性能变差。且linux对磁盘目录数有个数限制，太多会导致有空间但是写不进去) kafka磁盘类型选择： SSD固态硬盘or普通SAS机械硬盘？ SSD就是固态硬盘，比机械硬盘要快，SSD的快主要是快在磁盘随机读写 Kafka是顺序写的，机械硬盘顺序写的性能机会跟内存读写的性能是差不多的。所以对于Kafka集群使用机械硬盘就可以了。 QPS计算公式= 64qps0000000÷(3*60*60)=6万，故高峰期集群需要要抗住每秒6万的并发内存：假如一个集群有3个topic，这3个topic的partition的数据在os cache里效果当然是最好的。3个topic，一个topic有假如30个partition。那么 总共会有90个partition。每个partition的Log文件大小是1G，我们有 3个副本，也就是说要把90个topic的partition数据都驻留在内存里需 要270G的内存。我们现在有3台服务器，所以平均下来每天服务器需 要90G的内存，但是其实partition的数据我们没必要所有的都要驻留 在内存里面，10-20%的数据在内存就非常好了，90G * 0.2 = 18G就 可以了。所以64g内存的服务 器也非常够用了。
cpu：主要是看Kafka进程里会有多少个线程，线程主要是依托多核CPU来执行的，如果线程特别多，但是 CPU核很少，就会导致CPU负载很高，会导致整体工作线程执行的效率不太高。 来Kafka内部有100多个线程，4个cpu core，一般来说几十个线程，在高峰期CPU几乎都快打满了。8个cpu ，能够比较宽裕的 支撑几十个线程繁忙的工作。所以Kafka的服务器一般是建议16核，基本上可以hold住一两百线程的工作。当然如果可以给到32 cpu 那就更加的宽裕。
网卡：
1亿写请求，6000/s的吞吐量，3T的数据，3台物理机 硬盘：7（SAS） * 1T，7200转 内存：64GB，JVM分配6G，剩余的给os cache CPU：16核/32核 网络：万兆网卡更佳 核心配置： 日志保留策略配置优化 建议减少日志保留时间，通过log.retention.hours来实现，例如设置 log.retention.hours=72， 根据实际需求调整，默认是七天 。 段文件大小优化 段文件配置1GB，有利于快速回收磁盘空间，重启kafka加载也会加快，相反，如果文件过小，则文件数量比较多，kafka启动 时是单线程扫描目录(log.dir)下所有数据文件)，文件较多时性能会稍微降低。可通过如下选项配置段文件大小： log.segment.bytes=1073741824 log数据文件刷盘策略优化 为了大幅度提高producer写入吞吐量，需要定期批量写文件 优化建议为：每当producer写入10000条消息时，刷数据到磁盘。可通过如下选项配置： log.flush.interval.messages=10000 每间隔1秒钟时间，刷数据到磁盘。可通过如下选项配置： log.flush.interval.ms=1000 提升并发处理能力 num.io.threads =8，num.network.threads =3（均为默认值，自己根据实际情况调整） 离线存储平台（Hadoop系列） Hadoop选型1：Apache社区版本
a:开源，免费
b:更新快，新特性多
c: Bug多，需考虑各组件兼容性
2：Cloudera
a:分开源，免费版本。目前都要收费了
b:稳定，不需要考虑兼容性问题
c：有clouderaManager管理工具可视化界面很友好
d: 版本因为稳定，更新慢。新特性尝鲜少。且收费（！这点估计很多都不会选择）
3：Hortonworks
a:万全开源免费
b:稳定，不需要考虑兼容性问题
c：有集群管理工具可视化界面很友好
d: 流行度不高
TIPS:
1.x 稳定版本
2.0支持高可用，支持联邦
2.7x流行度广比较稳定，建议2.7.5以后
3.x HA支持多个namenode，增加纠删码功能。可以减少副本，文件块里面存了一部分压缩元数据，另外一部分用于存储校验数据可以用于数据恢复。就可以减少副本存储数。当然也可以多副本和纠删码同时开启。但是缺乏数据本地性问题
机架感知 机架感知就是自动了解hadoop集群中每个机器节点所属的机架，某个datanode节点是属于哪个机柜并非是智能感知的，而是需要hadoop的管理者人为的告知hadoop哪台机器属于哪个机柜，这样在hadoop的Namenode启动初始化时，会将这些机器与机柜的对应信息保存在内存中，用来作为HDFS写数据块 *** 作分配Datanode列表时（比如3个 block对应三台datanode）选择DataNode的策略，比如，要写三个数据块到对应的三台datanode，那么通过机架感知策略，可以尽量将三个副本分布到不同的机柜上。这个需要运维配合设置。 硬件选型(PB级)cpu：推荐4路32核等，主频至少2-2.5GHz
内存：推荐64-256GB
磁盘：分为2组，系统盘和数据盘，系统盘2T*2，做raid1，数据盘2-10T左右（SSD，SAS）磁盘当然选择ssd性能更好，但是价格偏贵。每个数据盘在2-10T左右不宜太大，数据量太大读写慢，寻址慢。比如磁盘坏了或者导数据，磁盘数据量太大就很麻烦。
网卡：万兆网卡（光纤卡），很有钱十万兆网卡也可以。
电源：均配置冗余电源，有条件的可以具备发电能力。
内存配置NameNode
将Namenode运行在一台独立的服务器上，要设置Namenode堆内存大小，可通过在hadoop配置文件hadoop-env.sh中添加 如下内容实现： export HADOOP_HEAPSIZE_MAX= 大 export HADOOP_HEAPSIZE_MIN= 大 tips：建议Namenode堆内存大小设置为物理内存的80%，且堆内存上限和下限设置为一样大，以免jvm动态调整。因为nd需要加载很多元数据，所以内存设置的比较大。（比如128g的服务器，设置nd的的内存为100g可以hold住1000台且为20*1T硬盘的集群） DataNode 同样修改hadoop配置文件hadoop-env.sh，添加如下内容： export HDFS_DATANODE_HEAPSIZE=4096 export HDFS_DATANODE_OPTS="-Xms${HDFS_DATANODE_HEAPSIZE}m -Xmx${HDFS_DATANODE_HEAPSIZE}m" 建议Datanode堆内存大小设置为4GB以上。 4-8G即可 ，将更多内存留给YARN 资源计算 在搭建集群时候需考虑未来一到两年的资源消耗来搭建集群。举个例子如下 1. 每天1T， 副本数为3 ，一年需要的存储资源：1 * 3 * 365 = 1095T 2. 数据需要 进行加工 （建模）：1095T* 3 = 3285T 3. 数据增速是 每年50% ，3285T* （ 1.5）= 4928T 4. 磁盘只能存到 80% ，故需要3942T的存储空间 5. 压缩比，按50%估算，故需要存储1972T 机器配置：32cpu core, 128G内存，11 * 7T 故：1972/77 = 26 台 服务器 Tips：评估资源时候一定要预留充足，以及充分的扩展接口 关键参数 dfs.replication 此参数用来设置文件副本数，通常设为3，不推荐修改。这个参数可用来保障HDFS数据安全，副本数越多，越浪费 磁盘存储空间，但数据安全性越高。tips：高版本可搭配纠删码使用。 dfs.block.size 此参数用来设置HDFS中数据块的大小，默认为128M，所以，存储到HDFS的数据最好都大于128M或者是128的整 数倍，这是最理想的情况，对于数据量较大的集群，可设为256MB或者512MB。数据块设置太小，会增加NameNode的压力。数据块设置过大会增加定位数据的时间。 dfs.datanode.data.dir 这个参数是设置HDFS数据块的存储路径，配置的值应当是分布在各个独立磁盘上的目录，这样可以充分利用节点的IO读写能力，提高HDFS读写性能。 dfs.datanode.max.transfer.threads 这个值是配置datanode可同时处理的最大文件数量，推荐将这个值调大，最大值可以配置为65535 hdfs-site.xml样例如下dfs.nameservices nxhadoop dfs.ha.namenodes.zzhadoop nn1,nn2 dfs.namenode.rpc-address.zzhadoop.nn1 hadoop01:8020 dfs.namenode.http-address.zzhadoop.nn1 hadoop01:50070 dfs.namenode.servicerpc-address.zzhadoop.nn1 hadoop01:53310 dfs.namenode.rpc-address.zzhadoop.nn2 hadoop02:8020 dfs.namenode.http-address.zzhadoop.nn2 hadoop02:50070 dfs.namenode.servicerpc-address.zzhadoop.nn2 hadoop02:53310 dfs.namenode.shared.edits.dir qjournal://hadoop03:8485;hadoop04:8485;hadoop05:8485/zzhadoop-joural dfs.journalnode.edits.dir /opt/zdp/hadoop/journal dfs.ha.automatic-failover.enabled true dfs.client.failover.proxy.provider.zzhadoop org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider dfs.ha.fencing.methods sshfence(zdp:22) dfs.ha.fencing.ssh.connect-timeout 1000 dfs.ha.fencing.ssh.private-key-files /home/zdp/.ssh/id_rsa dfs.replication 2 dfs.namenode.name.dir file:/opt/zdp/hadoop/hdfs/dfs.namenode.name.dir dfs.datanode.data.dir file:///data0/hdfs/dfs.data,file:///data1/hdfs/dfs.data,file:///data2/hdfs/dfs.data,file:///data3/hdfs/dfs.data,file:///data4/hdfs/dfs.data,file:///data5/hdfs/dfs.data,file:///data6/hdfs/dfs.data,file:///data7/hdfs/dfs.data,file:///data8/hdfs/dfs.data,file:///data9/hdfs/dfs.data,file:///data10/hdfs/dfs.data,file:///data11/hdfs/dfs.data dfs.webhdfs.enabled true dfs.namenode.handler.count 100 dfs.datanode.max.xcievers 4096 dfs.datanode.balance.bandwidthPerSec 31457280 dfs.datanode.fsdataset.volume.choosing.policy org.apache.hadoop.hdfs.server.datanode.fsdataset.AvailableSpaceVolumeChoosingPolicy dfs.datanode.failed.volumes.tolerated 2 dfs.client.file-block-storage-locations.timeout.millis 6000 dfs.datanode.hdfs-blocks-metadata.enabled true dfs.blocksize 268435456 dfs.datanode.du.reserved 107374182400 dfs.permissions.enabled true dfs.permissions.superusergroup zdp fs.permissions.umask-mode 022 dfs.namenode.acls.enabled true dfs.datanode.max.transfer.threads 8192 dfs.namenode.fs-limits.max-component-length 0
core-site.xml样例如下
*** 作系统调优： 1、调整 *** 作系统打开文件描述符的上限 通过命令“ ulimit -a”可以看到所有系统资源参数，这里面需要重点设置的是“open files”和“max user processes”，其它可以酌情设置。 要永久设置资源参数，主要是通过下面几个文件来实现： /etc/security/limits.conf /etc/security/limits.d/90-nproc.conf(centos6.x) /etc/security/limits.d/20-nproc.conf(centos7.x) 2、修改net.core.somaxconn参数 此内核参数对应的具体文件路径为/proc/sys/net/core/somaxconn，它用来设置socket监听（ listen）的 backlog上限。 什么是backlog呢？backlog就是socket的监听队列，当一个请求（request）尚未被处理或建立时，他会 进入backlog。而socket server可以一次性处理backlog中的所有请求，处理后的请求不再位于监听队列 中。如何server处理请求较慢，以至于监听队列被填满时，新来的请求会被拒绝。所以必须增大这个值， 此 参数默认值为128。 作为网络参数的基础优化，建议修改为如下值： echo 4096 >/proc/sys/net/core/somaxconn 3、调整 *** 作系统使用swap的比例 swap本意是作为物理内存的扩展来使用的，但是在内存充足的今天，使用swap的场景越来越少，主要是使用swap会极大降低应用性能，在hadoop中，如果数据交换到swap，会导致 *** 作超时，非常影响hadoop的读写以及数据分析性能。 可以通过系统内核参数/proc/sys/vm/swappiness来调整使用swap的比例。swappiness=0的时候表 示最大限度使用物理内存，然后才是swap空间，swappiness＝100的时候表示积极的使用swap分 区，并且把内存上的数据及时的搬运到swap空间里面。 linux的基本默认设置为60，表示你的物理内存在使用到100-60=40%的时候，就开始出现有交换分 区的使用。此值在一些对内存需求高的服务器上，需要设置的足够小，比如hadoop、redis、hbase 机器上，应该设置0-10之间，表示最大限度使用物理内存.。 4、禁用THP(Transparent Huge Pages)功能 THP的本意是为提升内存的性能，但是在hadoop环境中发现，此功能会带来CPU占用率增大，影响hadoop性能，因此建议 将其关闭 存储平台常见故障fs.defaultFS hdfs://hadoop ha.zookeeper.quorum hadoop03:2181,hadoop04:2181,hadoop05:2181/hadoop hadoop.tmp.dir /opt/zdp/hadoop/hadoop_tmp/tmp A base for other temporarydirectories. io.file.buffer.size 131072 fs.trash.interval 1440 io.compression.codecs org.apache.hadoop.io.compress.GzipCodec, org.apache.hadoop.io.compress.DefaultCodec, com.hadoop.compression.lzo.LzoCodec, com.hadoop.compression.lzo.LzopCodec, org.apache.hadoop.io.compress.BZip2Codec io.compression.codec.lzo.class com.hadoop.compression.lzo.LzoCodec ipc.server.read.threadpool.size 3 Reader thread num, rpc中reader线程个数 net.topology.script.file.name /opt/soft/zdp/hadoop-2.7.5/etc/hadoop/rack_awareness.py net.topology.script.number.args 100 hadoop.proxyuser.zdp.hosts * hadoop.proxyuser.zdp.groups * hadoop.security.authorization true
1：下线DataNode
（1）、修改hdfs-site.xml文件 找到namenode节点配置文件/etc/hadoop/conf/hdfs-site.xml文件如下选项：在HDFS集群中，Namenode主机上存储了所有的元数据信息，如果此信息丢失，那么整个HDFS上面的数据将不可用，而如果Namenode服务器发生了故障无法启动，
解决的方法分为两种情况：
如果Namenode做了高可用服务，那么在主Namenode故障后，Namenode服务会自动切换到备用的 Namenode上，这个过程是自动的，无需手工介入。
如果你的Namenode没做高可用服务，那么还可以借助于SecondaryNameNode服务，在 SecondaryNameNode主机上找到元数据信息，然后直接在此节点启动Namenode服务即可，种方式可能会丢失部分数据，因为SecondaryNameNode实现的是Namenode的冷备份。 由此可知，对Namenode进行容灾备份至关重要，在生产环境下，建议通过standby Namenode实现Namenode的高可用热备份。
4：yarn被标记为不健康
当节点被标记为不健康后，此节点相会被剔出了yarn集群，不会再有任务提交到此节点. yarn配置中，参数yarn.nodemanager.local-dirs，它用来存储NodeManager应用程序运行的中间结果，另一个参数yarn.nodemanager.log-dirs，它指定了NodeManager的日志文件存放目录列表。这两个参数都可以配置多个目录，多个目录之间使用逗号分隔。 本地目录健康检测主要涉及到以下几个参数： yarn.nodemanager.disk-health-checker.min-healthy-disks 表示正常目录数目相对于总目录总数的比例，低于这个值则认为此节点处于不正常状态，默认值为0.25。 例如指定了十二个目录（磁盘），这意味着它们中至少有3（ 12的1/4）个目录必须处于正常状态才能使 NodeManager在该节点上启动新容器。 yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage 此参数默认值为90，表示yarn.nodemanager.local-dirs配置项下的路径或者yarn.nodemanager.log-dirs配置项下的路径的磁盘使用率达到了90%以上，则将此台机器上的nodemanager标志为unhealthy，这个值可以设置为0 到100之间 5：磁盘存储不均 在HDFS集群中，涉及到增删磁盘时候就回到指数局部均衡。以新增磁盘为例。 有新数据会写入这个硬盘，而之前的老数据不会自动将数据平衡过来，如此下去，更换的硬盘越多，节点之 间、每个节点的各个磁盘之间的数据将越来越不平衡。 可以使用hadoop提供的Balancer程序得HDFS集群达到一个平衡的状态，执行命令 如下： [hadoop@namenodemaster sbin]$ $HADOOP_HOME/bin/start-balancer.sh –t 5% 或者执行如下命令： [hadoop@namenodemaster sbin]$ hdfs balancer -threshold 5 这个命令中-t参数后面跟的是HDFS达到平衡状态的磁盘使用率偏差值。如果节点与节点之间磁盘使用率偏 差小于5%，那么我们就认为HDFS集群已经达到了平衡的状态。 6：集群新增DataNode （1）、新节点部署hadoop环境 新增节点在系统安装完成后，要进行一系列的 *** 作，比如系统基本优化设置，hadoop环境的部署和安装等等，这 些基础工作需要事先完成。 （2）、修改hdfs-site.xml文件 在namenode上查看/etc/hadoop/conf/hdfs-site.xml文件，找到如下内容：yarn-site.xml参考配置如下
管理平台yarn.resourcemanager.ha.enabled true yarn.resourcemanager.cluster-id rm yarn.resourcemanager.ha.rm-ids rm1,rm2 yarn.resourcemanager.hostname.rm1 hadoop1 yarn.resourcemanager.hostname.rm2 hadoop2 yarn.resourcemanager.resource-tracker.address.rm1 hadoop1:8031 yarn.resourcemanager.scheduler.address.rm1 hadoop1:8030 yarn.resourcemanager.address.rm1 hadoop1:8032 yarn.resourcemanager.admin.address.rm1 hadoop1:8033 yarn.resourcemanager.webapp.address.rm1 hadoop1:8088 yarn.resourcemanager.resource-tracker.address.rm2 hadoop2:8031 yarn.resourcemanager.scheduler.address.rm2 hadoop2:8030 yarn.resourcemanager.address.rm2 hadoop2:8032 yarn.resourcemanager.admin.address.rm2 hadoop2:8033 yarn.resourcemanager.webapp.address.rm2 hadoop2:8088 yarn.resourcemanager.recovery.enabled true yarn.resourcemanager.store.class org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore yarn.resourcemanager.zk-state-store.parent-path /rmstore yarn.resourcemanager.zk-address hadoop011:2181,hadoop012:2181,hadoop013:2181/zzhadoop yarn.resourcemanager.ha.automatic-failover.enabled true yarn.resourcemanager.ha.automatic-failover.embedded true yarn.client.failover-proxy-provider org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider yarn.log-aggregation-enable true Classpath for typical applications. yarn.application.classpath $HADOOP_HOME/etc/hadoop/, $HADOOP_HOME/share/hadoop/common/*,$HADOOP_HOME/share/hadoop/common/lib/*, $HADOOP_HOME/share/hadoop/hdfs/*,$HADOOP_HOME/share/hadoop/hdfs/lib/*, $HADOOP_HOME/share/hadoop/mapreduce/*,$HADOOP_HOME/share/hadoop/mapreduce/lib/*, $HADOOP_HOME/share/hadoop/yarn/*,$HADOOP_HOME/share/hadoop/yarn/lib/*, $HADOOP_HOME/share/hadoop/tools/lib/* yarn.nodemanager.aux-services mapreduce_shuffle,spark_shuffle yarn.nodemanager.aux-services.mapreduce.shuffle.class org.apache.hadoop.mapred.ShuffleHandler yarn.nodemanager.aux-services.spark_shuffle.class org.apache.spark.network.yarn.YarnShuffleService yarn.nodemanager.local-dirs file:///data0/yarn/nm-local-dir,file:///data1/yarn/nm-local-dir,file:///data2/yarn/nm-local-dir,file:///data3/yarn/nm-local-dir,file:///data4/yarn/nm-local-dir,file:///data5/yarn/nm-local-dir,file:///data6/yarn/nm-local-dir,file:///data7/yarn/nm-local-dir,file:///data8/yarn/nm-local-dir,file:///data9/yarn/nm-local-dir,file:///data10/yarn/nm-local-dir,file:///data11/yarn/nm-local-dir An application's localized file directory will be found in: ${yarn.nodemanager.local-dirs}/usercache/${user}/appcache/application_${appid}. yarn.nodemanager.log-dirs file:///data0/yarn/userlogs,file:///data1/yarn/userlogs,file:///data2/yarn/userlogs,file:///data3/yarn/userlogs,file:///data4/yarn/userlogs,file:///data5/yarn/userlogs,file:///data6/yarn/userlogs,file:///data7/yarn/userlogs,file:///data8/yarn/userlogs,file:///data9/yarn/userlogs,file:///data10/yarn/userlogs,file:///data11/yarn/userlogs Where to store container logs. Each container directory will contain the files stderr, stdin, and syslog generated by that container. yarn.nodemanager.log.retain-seconds 10800 Where to aggregate logs yarn.nodemanager.remote-app-log-dir /yarn/apps/logs yarn.app.mapreduce.am.staging-dir /yarn/staging yarn.log.server.url http://nxhadoop011:19888/jobhistory/logs yarn.resourcemanager.am.max-retries 3 yarn.resourcemanager.am.max-attempts 3 How long to wait until a node manager is considered dead. yarn.nm.liveness-monitor.expiry-interval-ms 120000 yarn.app.mapreduce.am.scheduler.connection.wait.interval-ms 5000 yarn.am.liveness-monitor.expiry-interval-ms 120000 yarn.resourcemanager.rm.container-allocation.expiry-interval-ms 120000 Amount of physical memory, in MB, that can be allocated for containers. yarn.nodemanager.resource.memory-mb 102400 Number of CPU cores that can be allocated for containers. yarn.nodemanager.resource.cpu-vcores 32 yarn.resourcemanager.scheduler.class org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler yarn.scheduler.fair.allocation.file /opt/soft/zdp/hadoop/etc/hadoop/fair-scheduler.xml yarn.scheduler.fair.user-as-default-queue false yarn.scheduler.fair.preemption false yarn.scheduler.fair.sizebasedweight false yarn.scheduler.fair.assignmultiple true yarn.scheduler.fair.max.assign 3 yarn.scheduler.fair.allow-undeclared-pools false yarn.scheduler.fair.continuous-scheduling-enabled true yarn.scheduler.maximum-allocation-vcores 10 yarn.scheduler.minimum-allocation-mb 512 yarn.scheduler.maximum-allocation-mb 32768 Maximum limit of memory to allocate to each container request at the Resource Manager. In MBs. According to my configuration,yarn.scheduler.maximum-allocation-mb > yarn.nodemanager.resource.memory-mb yarn.nodemanager.pmem-check-enabled true yarn.nodemanager.vmem-check-enabled true yarn.nodemanager.vmem-pmem-ratio 100 rpc.engine.org.apache.hadoop.mapred.JobSubmissionProtocol org.apache.hadoop.ipc.ProtobufRpcEngine yarn.ipc.rpc.class org.apache.hadoop.yarn.ipc.HadoopYarnProtoRPC yarn.client.nodemanager-connect.max-wait-ms 20000 yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage 97.0 yarn.nodemanager.address ${yarn.nodemanager.hostname}:65033 yarn.resourcemanager.connect.retry-interval.ms 2000
各个组件之间没有统一的 metric 可视化界面，比如说 hdfs 总共占用的磁盘空间、 IO 、运行状况等，. 平台健不健康也不知道。这个时候就需要一个可视化管理平台。
业内常见方案
Ambari安装部署文档自取
链接：https://pan.baidu.com/s/1CRbKv5H4VdnPgvgJgQcbCg
提取码：18us
特点：
1. Apache Ambari是一种基于Web的工具，支持Apache Hadoop集群的创建、管理和监控。 2. Apache Ambari 支持HDFS、MapReduce、Hive、Pig、Hbase、Zookeepr、Sqoop和Hcatalog等的集中管理 3. Ambari使用Ganglia收集度量指标，用Nagios支持系统报警，当需要引起管理员的关注时（比如，节点停机或磁盘剩余空间 不足等问题），系统将向其发送邮件。 4. 主要开发语言Python，开源 提供Hadoop集群 1） Ambari提供了跨任意数量的主机安装Hadoop服务的分步向导。 2）Ambari处理群集的Hadoop服务配置。 管理Hadoop集群 1） Ambari提供集中管理，用于在整个集群中启动，停止和重新配置Hadoop服务。 监控Hadoop集群 1）Ambari提供了一个仪表板，用于监控Hadoop集群的运行状况和状态。 2）Ambari利用Ambari指标系统进行指标收集。 3）Ambari利用Ambari alert framework进行系统警报，并在需要您注意时通知您(例如，节点出现故障，剩余磁盘空间不足 等)界面如图所示
Cloudera ManagerCloud Cloudera Manager(简称CM)是Cloudera公司开发的一款大数据集群安装部署利器，这款利器具有集群自动化安装、中心化管理、集群 监控、报警等功能。 特点： 1.管理：对集群进行管理，如添加、删除节点等 *** 作。 2.监控：监控集群的健康情况，对设置的各种指标和系统运行情况进行全面监控。 3.诊断：对集群出现的问题进行诊断，对出现的问题给出建议解决方案。 4.集成：对hadoop的多组件进行整合。 5.比Ambari管理粒度更细 缺点：收费 安装文档自取： 链接：https://pan.baidu.com/s/1olezueF2NZxvwHGVw9dFhA提取码：wjfd 界面展示如下
CM和Ambari对比如下
自研+开源组件集群的部署和管理可以基于Ambari二次开发(管理Apache，CDH，HDP都可以)。
监控告警解决方案（cm和Ambari自带的监控粒度不过详细，一般会选择其他监控方案）：
方案一：ganglia+nagios Ganglia是UC Berkeley发起的一个开源集群监视项目，设计用于测量数以千计的节点。Ganglia的核心包含gmond、gmetad 以及一个Web前端。主要是用来监控系统性能，如：cpu 、mem、硬盘利用率， I/O负载、网络流量情况等，通过曲线很容 易见到每个节点的工作状态。 用户群：适用于大型服务器集群用户。 ganglia （1）优点： 1. 适合监控系统性能，通过曲线很容易见到每个节点的工作状态 2. 可以自定义监控项，监控展示有表格和图像两种，支持手机版 3. 部署方便，通过不同的分层管理上万台机器，无需逐个添加配置，有利于后期的大规模扩张。 4. Ganglia的强大在于：ganglia服务端能够通过一台客户端收集到同一个网段的所有客户端的数据，ganglia集群服务端能够通过一台服务端 收集到它下属的所有客户端数据。这个体系设计表示一台服务器能够通过不同的分层能够管理上万台机器。这个功能是其他mrtg,nagios,cacti 所不能比拟。 5.Ganglia相比zabbix的优势在于客户端收集agent（gmond）所带来的系统开销非常低，不会影响相关服务的性能。 （2）缺点： 1. 没有报警机制，出现问题不能够及时报警。所以需要搭配其他报警组件使用 效果图如图所示 NagiosNagios是一个监视系统运行状态和网络信息的监视系统。Nagios能监视所指定的本地或远程主机以及服务，同时提供异常通知功能等
方案二：open falcon/Zabbix（两个都带监控告警，任选其一） OpenFalcon OpenFalcon是由小米的运维团队开源的一款企业级、高可用、可扩展的开源监控解决方案，，在众多开源爱好者的支持 下，功能越来越丰富，文档更加的完善，OpenFalcon 已经成为国内最流行的监控系统之一。小米、美团、金山云、快 网、宜信、七牛、又拍云、赶集、滴滴、金山办公、爱奇艺、一点资讯、快牙、开心网、借贷宝、百度、迅雷等公司使用. zabbix(没有openfacon好用) zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级的开源解决方案。zabbix能监视各种网络参 数，保证服务器系统的安全运营；并提供灵活的通知机制以让系统管理员快速定位/解决存在的各种问题。 方案三：Prometheus+grafana Prometheus 监控组件，但是展示比较丑一般搭配frafana使用。普罗米修斯对大数据组件支持很好 grafana Grafana是一款用Go语言开发的开源数据可视化工具，可以做数据监控和数据统计，带有告警功能。目前使用 grafana的公司有很多，如paypal、ebay、intel等 效果图如下所示 上诉集中监控组件对比如下推荐方案：Ambari（管理）+Opeca/Prometheus（自带的界面也没Grafana好看）+Granfana
实时Kafka监控告警
常用组件
kafka monitor
kafka manager
Eagle
管理比较完善，自带监控告警，还带kafka sql
如果想将告警信息统一可以采用如下设计方案。图中监控页面是上述三种组件中的任意一种。
使用开源组件或者自己读取kafka offset的topic进行监控
日志采集 完整的大数据平台，包括以下的几个过程：数据采集 –> 数据存储 –> 数据处理–> 数据展现 业务日志采集 Flume 是 Apache旗下的一款开源、 高可靠、高扩展、 容易管理、支持客 户扩展的数据采集系统 Logstash 是一个应 用程序日志、事件的 传输、处理、管理和 搜索的平台。你可以 用它来统一对应用程 序日志进行收集管 理，提供 Web 接口 用于查询和统计。 对比：logstash一般是elk使用，适合数据量中等，flume更适合hadoop生态海量数据 数据库日志采集 Canal是阿里巴巴旗下的一款开源 项目,纯Java开发。基于数据库增量 日志解析,提供增量数据订阅&消费, 目前主要支持MySQL(也支持 MariaDB) 数据库批量采集 Sqoop是一款开源的工 具，主要用于在 Hadoop(Hive)与传统的 数据库（MySQL、 postgresql...)间进行数据 的传递，反之成立。 DataX 是阿里巴巴集团内被广泛使用的离线数据同步工 具/平台，实现包括 MySQL、Oracle、 SqlServer、Postgre、 HDFS、Hive、Hbase等各 种异构数据源之间高效的数据同步功能。案例：用户行为日志
案例：业务数据采集 案例3：上述采集的数据入库基础数据平台
全流程整体架构如下
调度平台工作中很多任务需要定时调度最粗暴和简单直接的解决方案就是crontab。当然在机器少，任务不多，定时任务之间关联少的情况下，crontab效率还是比较高和便捷的。 随着集群的增多 ，任务的增多。crontab就开始出现管理混乱的情况，这个时候一个调度平台就非常重要。
业内常见组件
Oozie：
Oozie是一个用于管理Apache Hadoop作业的工作流调度程序系统。对于通用流程调度而言，不是一个非常 好的候选者，因为XML定义对于定义轻 量级作业非常冗长和繁琐。 它还需要相当多的外设设置。 Azkaban是由linkedin开源的一个批 量工作流任务调度器。用于在一个工 作流内以一个特定的顺序运行一组工 作和流程。 需要通过打zip进行任务调度，任务依赖支持不灵活。
Azkaban： Azkaban是由linkedin开源的一个批量工作流任务调度器。用于在一个工作流内以一个特定的顺序运行一组工作和流程。需要通过打zip进行任务调度，任务依赖支持不灵活。 DolphinScheduler： Apache DolphinScheduler是一个分 布式去中心化，易扩展的可视化DAG工作流任务调度系统。致力于解决数据处理流程中错综复杂的依赖关系，使调度系统在数据处理流程中开箱即用。 实时数据Sql查询平台离线数据可以使用hsql或者spaqlsql进行分析出具处理，这对于一些其他部门只需要学习一下sql就可以上手。但是实时需求就非常麻烦需要很多技术栈需要开发人员才能进行分析。
要是能对实时数据进行sql类型的分析那就很棒，工作效率也会变高，学习成本也变低了。目前有开源的工具可以进行二次开发进行使用。
https://github.com/DTStack/flinkStreamSQL 基于开源的flink，对其实时sql进行扩展；主要实现了流与维表的join，支持原生flink SQL所有的语法这个开源组件并没有形成产品化，只是提供了工具jar包。使用方式如下。plugins为该组件jar包目录。
要想将该组件产品化，需要搭配web使用，需要设计一个web任务提交保存页面，后端进行解析提交脚本。流程大致如下。
任务诊断
在任务管理平台里面，可以使用任务诊断的功能提出改善意见。
大多数Hadoop优化工具，不管是开源还是商业的，都被 设计用来采集系统资源指标和监控集群资源信息。他们大 多数专注于简化Hadoop集群的部署和管理。很少有工具 来帮助用户优化Hadoop作业流的。少数的几个可用工具 要么扩展性差，要么不支持快速发展的Hadoop框架。 Dr. Elephant能很好支持Hadoop生态框架以及后续的新 框架，同时对Spark的支持也很友好。你同时也可以通过 插件的方式配置各种你喜欢的启发式算法。旨在帮助Hadoop和Spark的用户了解他们的内部工作流， 并帮助 他们轻松优化他们的作业。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）