大数据中台架构以及建设全流程一（Paas层设计）

设计背景当企业发展到一定规模时候有了不同的业务线以及数据规模，因为业务的快速发展。这个时候一些数据问题就会出现。问题点1:数据脏乱差，各部门生产线数据重复冗余，还不可:复用用存在数据孤岛2：数据开发部门的业务来自各部门各产品线，需求不明确，每天业务量繁复，日常工作可能成了sqlboy到处捞数据，而且在业务方面还没有业务部门了解的深入，有点缘木求鱼的意思。这个时候数据中台也就应运...

只会写demo的程序猿

7455人浏览 · 2021-12-02 14:06:31

只会写demo的程序猿 · 2021-12-02 14:06:31 发布

实时存储平台----------->KAFKA（未来pulsar也不错）

离线存储平台（Hadoop系列）

存储平台常见故障

Cloudera ManagerCloud

设计背景

当企业发展到一定规模时候有了不同的业务线以及数据规模，因为业务的快速发展。这个时候一些数据问题就会出现。

问题点

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样例如下


<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<!--
  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License. See accompanying LICENSE file.
-->

<!-- Put site-specific property overrides in this file. -->

<configuration>
	<!--指定hdfs的nameservice为zzhadoop，需要和core-site.xml中的保持一致 -->
	<property>
		<name>dfs.nameservices</name>
		<value>nxhadoop</value>
	</property>
	<!-- zzhadoop下面有两个NameNode，分别是nn1，nn2 -->
	<property>
		<name>dfs.ha.namenodes.zzhadoop</name>
		<value>nn1,nn2</value>
	</property>
	<!-- nn1的RPC通信地址 -->
	<property>
	    <name>dfs.namenode.rpc-address.zzhadoop.nn1</name>
            <value>hadoop01:8020</value>
	</property>
	<!-- nn1的http通信地址 -->
	<property>
	    <name>dfs.namenode.http-address.zzhadoop.nn1</name>
	    <value>hadoop01:50070</value>
	</property>
	<!-- dn 与 nn的rpc端口-->
        <property>
            <name>dfs.namenode.servicerpc-address.zzhadoop.nn1</name>
            <value>hadoop01:53310</value>
        </property>
	<!-- nn2的RPC通信地址 -->
	<property>
		<name>dfs.namenode.rpc-address.zzhadoop.nn2</name>
		<value>hadoop02:8020</value>
	</property>
	<!-- nn2的http通信地址 -->
	<property>
		<name>dfs.namenode.http-address.zzhadoop.nn2</name>
		<value>hadoop02:50070</value>
	</property>
        <property>
            <name>dfs.namenode.servicerpc-address.zzhadoop.nn2</name>
            <value>hadoop02:53310</value>
        </property>
	<property>
		<name>dfs.namenode.shared.edits.dir</name>
		<value>qjournal://hadoop03:8485;hadoop04:8485;hadoop05:8485/zzhadoop-joural</value>
	</property>
	<!-- 指定JournalNode在本地磁盘存放数据的位置 -->
	<property>
		<name>dfs.journalnode.edits.dir</name>
		<value>/opt/zdp/hadoop/journal</value>
	</property>
	<!-- 开启NameNode失败自动切换 -->
	<property>
		<name>dfs.ha.automatic-failover.enabled</name>
		<value>true</value>
	</property>
	<!-- 配置失败自动切换实现方式 -->
	<property>
		<name>dfs.client.failover.proxy.provider.zzhadoop</name>
		<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
	</property>
	<!-- 配置隔离机制 -->
	<property>
		<name>dfs.ha.fencing.methods</name>
		<value>sshfence(zdp:22)</value>
	</property>
    <property>
        <name>dfs.ha.fencing.ssh.connect-timeout</name>
        <value>1000</value>
    </property>
	<!-- 使用隔离机制时需要ssh免登陆 -->
	<property>
		<name>dfs.ha.fencing.ssh.private-key-files</name>
		<value>/home/zdp/.ssh/id_rsa</value>
	</property>
	<property>
		<name>dfs.replication</name>
		<value>2</value>
	</property>
	<property>
		<name>dfs.namenode.name.dir</name>
		<value>file:/opt/zdp/hadoop/hdfs/dfs.namenode.name.dir</value>
	</property>
<!-- 多块磁盘的话可以把fsimage与edits分开
	<property>
		<name>dfs.namenode.edits.dir</name>
		<value>${dfs.namenode.name.dir}</value>
    </property>
-->
	<property>
		<name>dfs.datanode.data.dir</name>
		<value>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</value>
	</property>
	<property>
		<name>dfs.webhdfs.enabled</name>
		<value>true</value>
	</property>
    <property>
        <name>dfs.namenode.handler.count</name>
        <value>100</value>
    </property>
    <property>
        <name>dfs.datanode.max.xcievers</name>
        <value>4096</value>
    </property>

    <property>
	<name>dfs.datanode.balance.bandwidthPerSec</name>
	<value>31457280</value>
    </property>
<!--  磁盘访问策略 -->
    <property>  
        <name>dfs.datanode.fsdataset.volume.choosing.policy</name>  
  	<value>org.apache.hadoop.hdfs.server.datanode.fsdataset.AvailableSpaceVolumeChoosingPolicy</value>  
    </property>  
	<property>
		<name>dfs.datanode.failed.volumes.tolerated</name>
		<value>2</value>
	</property>
	<property>
		<name>dfs.client.file-block-storage-locations.timeout.millis</name>
		<value>6000</value>
	</property>
	<property>
		<name>dfs.datanode.hdfs-blocks-metadata.enabled</name>
		<value>true</value>
	</property>
	<property>
		<name>dfs.blocksize</name>
		<value>268435456</value>
	</property>
	<property>
		<name>dfs.datanode.du.reserved</name>
		<value>107374182400</value>
	</property>
<!--
	<property>
		<name>ha.health-monitor.rpc-timeout.ms</name>
		<value>300000</value>
	</property>
-->
    <!-- 权限设置 -->
    <property>
        <name>dfs.permissions.enabled</name>
        <value>true</value>
    </property>
    <property>
        <name>dfs.permissions.superusergroup</name>
        <value>zdp</value>
    </property>
    <property>
        <name>fs.permissions.umask-mode</name>
        <value>022</value>
    </property>
    <property>
        <name>dfs.namenode.acls.enabled</name>
        <value>true</value>
    </property>
    
    <!--  1019 -->

    <property>
      <name>dfs.datanode.max.transfer.threads</name> 
      <value>8192</value>
    </property>
    <property>
      <name>dfs.namenode.fs-limits.max-component-length</name>
      <value>0</value>
    </property>

</configuration>

core-site.xml样例如下

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<!--
  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License. See accompanying LICENSE file.
-->

<!-- Put site-specific property overrides in this file. -->

<configuration>
	<property>
		<name>fs.defaultFS</name>
		<value>hdfs://hadoop</value>
	</property>
	<property>
		<name>ha.zookeeper.quorum</name>
		<value>hadoop03:2181,hadoop04:2181,hadoop05:2181/hadoop</value>
	</property>
	<property>
		<name>hadoop.tmp.dir</name>
		<value>/opt/zdp/hadoop/hadoop_tmp/tmp</value>
		<description>A base for other temporarydirectories.</description>
	</property>
	<property>
		<name>io.file.buffer.size</name>
		<value>131072</value>
	</property>
	<property>
            <name>fs.trash.interval</name>
            <value>1440</value>
        </property>
	<property>
		<name>io.compression.codecs</name>
		<value>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
		</value>
	</property>
    <property>
        <name>io.compression.codec.lzo.class</name>
        <value>com.hadoop.compression.lzo.LzoCodec</value>
    </property>

    <property>
        <name>ipc.server.read.threadpool.size</name>
        <value>3</value>
        <description>
        	Reader thread num, rpc中reader线程个数
        </description>
    </property>
<!-- Rack Awareness -->
    <property>
    	<name>net.topology.script.file.name</name>
    	<value>/opt/soft/zdp/hadoop-2.7.5/etc/hadoop/rack_awareness.py</value>
    </property>
    <property>
        <name>net.topology.script.number.args</name>
   	<value>100</value>
    </property>

   <!-- 改变dr.who为superuser(即启动用户), 在页面上可以访问任意目录 -->
 <!--
	<property>
		<name>hadoop.http.staticuser.user</name>
		<value>work</value>
	</property>
-->
    <property>
      <name>hadoop.proxyuser.zdp.hosts</name>
      <value>*</value>
    </property>
    <property>
      <name>hadoop.proxyuser.zdp.groups</name>
      <value>*</value>
    </property>
 
   <!-- 功能待验证 security.client.protocol.hosts -->
   <property>
       <name>hadoop.security.authorization</name>
       <value>true</value>
   </property>
</configuration>

操作系统调优：

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性能，因此建议

将其关闭

存储平台常见故障

1：下线DataNode

（1）、修改hdfs-site.xml文件

找到namenode节点配置文件/etc/hadoop/conf/hdfs-site.xml文件如下选项：

<name>dfs.hosts.exclude</name>

<value>/etc/hadoop/conf/hosts-exclude</value>

</property>

（2）、修改hosts-exclude文件

在hosts-exclude中添加需要下线的datanode主机名，执行如下操作：

vi /etc/hadoop/conf/hosts-exclude

192.16.213.77

（3）、刷新配置

在namenode上以hadoop用户执行下面命令，刷新hadoop配置：

[hadoop@namenodemaster ~]$hdfs dfsadmin -refreshNodes

（4）、检查是否完成下线

通过执行如下命令检查下线是否完成：

[hadoop@cdh5master ~]$hdfs dfsadmin -report

也可以通过查看NameNode的50070端口访问web界面，查看HDFS状态，需要重点关注退役的节点数以及复制的块数和进度

2：磁盘故障

如果某个datanode节点的磁盘出现故障，将会出现此节点不能写入操作而导致datanode进程退出，针对这个问题，首先在故障节点上查看/etc/hadoop/conf/hdfs-site.xml文件中对应的dfs.datanode.data.dir参数设置，去掉故障磁盘对应的目录挂载点。

然后，在故障节点查看/etc/hadoop/conf/yarn-site.xml文件中对应的yarn.nodemanager.local-dirs参数设置，去掉故障磁盘对应的目录挂载点。最后，重启此节点的datanode服务和nodemanager服务即可。磁盘修复好了以后，重新添加回去（可以通过脚本自动监控新增磁盘）。

3：NameNode故障

在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文件，找到如下内容：

<name>dfs.hosts</name>

<value>/etc/hadoop/conf/hosts</value>

</property>

（3）、修改hosts文件

在 namenode 上修改/etc/hadoop/conf/hosts文件，添加新增的节点主机名，操作如下：

vi /etc/hadoop/conf/hosts hadoop001 最后，将配置同步到所有datanode节点的机器上。

（4）、使配置生效

新增节点后，要让namenode识别新的节点，需要在namenode上刷新配置，执行如下操作：

[hadoop@namenodemaster ~]$hdfs dfsadmin -refreshNodes

（5）、在新节点启动dn服务

在namenode上完成配置后，最后还需要在新增节点上启动datanode服务，执行如下操作：

[hadoop@ hadoop001 ~]$ hdfs --daemon start datanode

这样，一个新的节点就增加到集群中了，hadoop的这种机制可以在不影响现有集群运行的状态下，任意新增或者删除某个节点。

7：missing blocks

这个问题也经常发生，并且会有数据丢失，因为一旦HDFS集群出现missing blocks错误，那意味着有元数据丢失或者损坏，要恢复的难度很大，或者基本无法恢复，针对这种情况，解决的办法就是先执行如下命令：

[hadoop@namenodemaster sbin]$ hdfs fsck /blocks-path/

此命令会检查HDFS下所有块状态，并给出那些文件出现了块丢失或损坏，最后执行如下命令删除这些文件即可：

[hadoop@namenodemaster sbin]$ hdfs fsck -fs hdfs://bigdata/logs/mv.log -delete

上面是删除HDFS上mv.log这个文件，因此此文件元数据丢失，无法恢复，所以只能删除。

8：KafkaBroker OOM

Kafka的默认启动内存较小，Kafka的生产端首先将数据发送到broker的内存存储，随机通过主机的OS层的数据刷盘机制将数据持久化，因此Kafka需要一定大小的内存空间，在生产环境一般建议将启动内存调整，官方建议内存在4-8G左右大小；

修改${KAFKA_HOME}/bin/kafka-server-start.sh脚本

9： broker运行日志大量topic不存在报错，导致节点不可用

若broker的运行日志大量刷topic不存在的WARN，并导致节点不可用；表明该集群存在topic被删除，但有发端仍使用该topic发送数据，此时需要检查broker上的2个配置项：

delete.topic.enable=true

auto.create.topics.enable=false（默认是true，发送时候没有topic默认创建）

10：kafka topic动态扩分区

流程见：https://blog.csdn.net/forrest_ou/article/details/79141391

目前Kafka只支持增加分区数而不支持减少分区数。比如我们再将主题topic-config的分区数修改为1，就会报出InvalidPartitionException的异常，详解如下

(27条消息) 为什么Kafka中的分区数只能增加不能减少_rede-CSDN博客

调度系统（Yarn）

ResourceManager

负责集群资源的统一管理和调度

NodeManager

每个节点只有一个，负责资源的管理和

使用

ApplicationMaster

每个应用程序只有一个，负责应用程序的

管理和任务调度

Container

对任务运行环境的抽象

优点

1：多类型资源调度，支持cpu，内存调度

2：多种调度器，FIFO（先到先得），Fair（公平调度），Capacity（权重调度）

yarn-site.xml参考配置如下

<?xml version="1.0"?>
<configuration>
	<!--ha related configuration-->
	<property>
		<name>yarn.resourcemanager.ha.enabled</name>
		<value>true</value>
	</property>
	<property>
		<name>yarn.resourcemanager.cluster-id</name>
		<value>rm</value>
	</property>
	<property>
		<name>yarn.resourcemanager.ha.rm-ids</name>
		<value>rm1,rm2</value>
	</property>
	<property>  
		<name>yarn.resourcemanager.hostname.rm1</name>  
		<value>hadoop1</value>  
	</property>  
	<property>  
		<name>yarn.resourcemanager.hostname.rm2</name>  
		<value>hadoop2</value>  
	</property>  
	<!--rm1 address-->
	<property>
		<name>yarn.resourcemanager.resource-tracker.address.rm1</name>
		<value>hadoop1:8031</value>
	</property>
	<property>
		<name>yarn.resourcemanager.scheduler.address.rm1</name>
		<value>hadoop1:8030</value>
	</property>
	<property>
		<name>yarn.resourcemanager.address.rm1</name>
		<value>hadoop1:8032</value>
	</property>
	<property>
		<name>yarn.resourcemanager.admin.address.rm1</name>
		<value>hadoop1:8033</value>
	</property>
	<property>
		<name>yarn.resourcemanager.webapp.address.rm1</name>
		<value>hadoop1:8088</value>
	</property>
	<!--rm2 address-->
	<property>
		<name>yarn.resourcemanager.resource-tracker.address.rm2</name>
		<value>hadoop2:8031</value>
	</property>
	<property>
		<name>yarn.resourcemanager.scheduler.address.rm2</name>
		<value>hadoop2:8030</value>
	</property>
	<property>
		<name>yarn.resourcemanager.address.rm2</name>
		<value>hadoop2:8032</value>
	</property>
	<property>
		<name>yarn.resourcemanager.admin.address.rm2</name>
		<value>hadoop2:8033</value>
	</property>
	<property>
		<name>yarn.resourcemanager.webapp.address.rm2</name>
		<value>hadoop2:8088</value>
	</property>
	<property>
		<name>yarn.resourcemanager.recovery.enabled</name>
		<value>true</value>
	</property>
	<property>
		<name>yarn.resourcemanager.store.class</name>
		<value>org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore</value>
	</property>
        <property>
    	    <name>yarn.resourcemanager.zk-state-store.parent-path</name>
    	    <value>/rmstore</value>
        </property>
	<property>
		<name>yarn.resourcemanager.zk-address</name>
		<value>hadoop011:2181,hadoop012:2181,hadoop013:2181/zzhadoop</value>
	</property>
	<property>
		<name>yarn.resourcemanager.ha.automatic-failover.enabled</name>
		<value>true</value>
	</property>
	<property>
		<name>yarn.resourcemanager.ha.automatic-failover.embedded</name>
		<value>true</value>
	</property>
	<property>
		<name>yarn.client.failover-proxy-provider</name>
		<value>org.apache.hadoop.yarn.client.ConfiguredRMFailoverProxyProvider</value>
	</property>
	<property>
		<name>yarn.log-aggregation-enable</name>
		<value>true</value>
	</property>
	<property>
		<description>Classpath for typical applications.</description>
		<name>yarn.application.classpath</name>
		<value>
			$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/*
		</value>
	</property>
	<property>
		<name>yarn.nodemanager.aux-services</name>
		<value>mapreduce_shuffle,spark_shuffle</value>
	</property>
	<property>
		<name>yarn.nodemanager.aux-services.mapreduce.shuffle.class</name>
		<value>org.apache.hadoop.mapred.ShuffleHandler</value>
	</property>

    <property>
        <name>yarn.nodemanager.aux-services.spark_shuffle.class</name>
        <value>org.apache.spark.network.yarn.YarnShuffleService</value>
    </property>

	<!-- 配置多块磁盘目录，用逗号隔开 -->
	<property>
		<name>yarn.nodemanager.local-dirs</name>
		<value>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</value>
		<description>
			An application's localized file directory will be found in: ${yarn.nodemanager.local-dirs}/usercache/${user}/appcache/application_${appid}.
		</description>
	</property>
	<!-- 配置多块磁盘目录，用逗号隔开 -->
	<property>
		<name>yarn.nodemanager.log-dirs</name>
		<value>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</value>
		<description>
			Where to store container logs. Each container directory will contain the files stderr, stdin, and syslog generated by that container.
		</description>
	</property>
    <property>
        <name>yarn.nodemanager.log.retain-seconds</name>
        <value>10800</value>
        <!-- 3days -->
    </property>
	<!-- hadoop hdfs目录 -->
	<property>
		<description>Where to aggregate logs</description>
		<name>yarn.nodemanager.remote-app-log-dir</name>
		<value>/yarn/apps/logs</value>
	</property>
	<!-- hadoop hdfs目录 -->
	<property>
		<name>yarn.app.mapreduce.am.staging-dir</name>
		<value>/yarn/staging</value>
	</property>
    <!-- for spark history server log-->
    <property>
        <name>yarn.log.server.url</name>
        <value>http://nxhadoop011:19888/jobhistory/logs</value>
    </property>

	<property>
		<name>yarn.resourcemanager.am.max-retries</name>
		<value>3</value>
	</property>
	<property>
		<name>yarn.resourcemanager.am.max-attempts</name>
		<value>3</value>
	</property>
	<property>
		<description>How long to wait until a node manager is considered dead.</description>
		<name>yarn.nm.liveness-monitor.expiry-interval-ms</name>
		<value>120000</value>
	</property>
	<property>
		<name>yarn.app.mapreduce.am.scheduler.connection.wait.interval-ms</name>
		<value>5000</value>
	</property>
	<property>
		<name>yarn.am.liveness-monitor.expiry-interval-ms</name>
		<value>120000</value>
	</property>
	<property>
		<name>yarn.resourcemanager.rm.container-allocation.expiry-interval-ms</name>
		<value>120000</value>
	</property>
	<property>
		<description>Amount of physical memory, in MB, that can be allocated for containers.</description>
		<name>yarn.nodemanager.resource.memory-mb</name>
		<value>102400</value>
	</property>
	<property>
		<description>Number of CPU cores that can be allocated for containers.</description>
		<name>yarn.nodemanager.resource.cpu-vcores</name>
		<value>32</value>
	</property>
<!-- fair scheduler-->
	<property>
		<name>yarn.resourcemanager.scheduler.class</name>
		<value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
	</property>
	<property>
		<name>yarn.scheduler.fair.allocation.file</name>
		<value>/opt/soft/zdp/hadoop/etc/hadoop/fair-scheduler.xml</value>
	</property>
	<property>
		<name>yarn.scheduler.fair.user-as-default-queue</name>
		<value>false</value>
	</property>
	<property>
		<name>yarn.scheduler.fair.preemption</name>
		<value>false</value>
	</property>
	<property>
		<name>yarn.scheduler.fair.sizebasedweight</name>
		<value>false</value>
	</property>
	<property>
		<name>yarn.scheduler.fair.assignmultiple</name>
		<value>true</value>
	</property>
	<property>
		<name>yarn.scheduler.fair.max.assign</name>
		<value>3</value>
	</property>
	<property>
		<name>yarn.scheduler.fair.allow-undeclared-pools</name>
		<value>false</value>
	</property>
	<property>
		<name>yarn.scheduler.fair.continuous-scheduling-enabled</name>
		<value>true</value>
	</property>


	<property>
		<name>yarn.scheduler.maximum-allocation-vcores</name>
		<value>10</value>
	</property>
	<property>
		<name>yarn.scheduler.minimum-allocation-mb</name>
		<value>512</value>
	</property>

        <property>
            <name>yarn.scheduler.maximum-allocation-mb</name>
            <value>32768</value>
            <description>
            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
            </description>
        </property>

	<property>
		<name>yarn.nodemanager.pmem-check-enabled</name>
		<value>true</value>
	</property>
	<property>
		<name>yarn.nodemanager.vmem-check-enabled</name>
		<value>true</value>
	</property>
	<property>
		<name>yarn.nodemanager.vmem-pmem-ratio</name>
		<value>100</value>
	</property>
<!--
	<property>
		<name>yarn.acl.enable</name>
		<value>true</value>
	</property>
-->
	<!--执行yarn的账号 -->
<!--
	<property>
		<name>yarn.admin.acl</name>
		<value>zdp</value>
	</property>
-->
	<property>
		<name>rpc.engine.org.apache.hadoop.mapred.JobSubmissionProtocol</name>
		<value>org.apache.hadoop.ipc.ProtobufRpcEngine</value>
	</property>
	<property>
		<name>yarn.ipc.rpc.class</name>
		<value>org.apache.hadoop.yarn.ipc.HadoopYarnProtoRPC</value>
	</property>
	<property>
		<name>yarn.client.nodemanager-connect.max-wait-ms</name>
		<value>20000</value>
	</property>
	<property>
		<name>yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage</name>
		<value>97.0</value>
	</property>

<!-- 指定nm address端口，containermanager 端口 -->
        <property>
            <name>yarn.nodemanager.address</name>
            <value>${yarn.nodemanager.hostname}:65033</value>
        </property>

           <property> 
    		<name>yarn.resourcemanager.connect.retry-interval.ms</name>  
    		<value>2000</value>  
           </property>  
</configuration>

管理平台

各个组件之间没有统一的 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. 没有报警机制，出现问题不能够及时报警。所以需要搭配其他报警组件使用

效果图如图所示

Nagios

Nagios是一个监视系统运行状态和网络信息的监视系统。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的用户了解他们的内部工作流，并帮助他们轻松优化他们的作业。