说句实话，我刚开始真的不敢写这个东西，因为我压根什么都不知道，脑子里面一团浆糊，根本理不清什么对什么，甚至Kafka和Hbase是什么我都不敢正面的回答，因为我慌啊，我不懂啊，所以我就得学啊，找资料啊，恶补啊！所以我就开始从最基础的Kafka是什么，怎么部署搭建，再到后来的kafka与hbase之间的传输，基本上算是过了一遍。所以只是以我个人的角度来写这篇文章，可能是有点拙劣，但是我感觉这是我的一个成长历程，我得对它高度的重视起来。
一、Kafka是什么？怎么定义？
Kafka官方介绍：Kafka是一个分布式的流处理平台(0.10.x版本)，在kafka0.8.x版本的时候，kafka主要是作为一个分布式的、可分区的、具有副本数的日志服务系统(Kafka™ is a distributed, partitioned, replicated commit log service), 具有高水平扩展性、高容错性、访问速度快、分布式等特性；主要应用场景是：日志收集系统和消息系统。
Kafka是一个分布式的消息系统,作为用户来说,只需要把数据扔给kafka,在需要的时候直接读就可以了,非常方便,实现异步非io阻塞。
自己总结一下：我的理解就是它是用来一个解决消息队列的工具，用来解决阻塞问题，减缓数据库的压力。
kafka分为productor,consumer和broker
productor:消息生产者,就是向kafka里面扔数据的一方(可以是多个productor向同一个写入)
consumer:消息消费者 ,就是从kafka里面消费(取)数据的一方(也可以是多个consumer向同一个kafka取数据)
broker:一个服务器实例,这个就是productor写入的服务器(实例),consumer从这里取数据,
topic:一条消息流
partition:分区,每个topic可以按特定的分区逻辑分区,类似mysql的分表,
partition的数据决定了一个topic可以同时多少个进程(用户)去写入,消费它(如果一个topic的partition为3,那么productor只能同时起3个进程写入,consumer同时有3个进程进行消费,如果启动的数量超过3个则会一直等待)
（partition数量和并行采集卡关系，partition官方资料看看）
Spark (task任务的定义)
CPU的核数问题------1-2核个做一个excutor 执行器
内存（kafka自身怎么配比，分配资源）
consumer group:消费者组,相同groupid的consumer组成一个组
如果多个consumer都指定同一个groupid,则这些consumer会自动组成一个负载均衡的模式,消费一个topic
offset:一条消息在消息流中的偏移（不同组不同的,组不一样从头开始重新取，同一个groupid取相同的，有且仅有一次）（微信的机制）
举例来说:数据1,2可以往topicid为top1里面写入 ,数据3,4可以往topicid为top2里面写入,在消费时,指定同一个groupid,消费topicid为top1的topic,连续消费2次可以消费1,2,如果换一个groupid,则又从头开始消费,也就是同一条消费,可以被多个groupid重复消费。
二、Hbase是什么？作用？（官网）
HBase– Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群，海量数据的快速随机访问。
Hbase是一个面向列存储的分布式存储系统，它的优点在于可以实现高性能的并发读写操作，同时Hbase还会对数据进行透明的切分，这样就使得存储本身具有了水平伸缩性。
HTable一些基本概念
1.Row key
行主键， HBase不支持条件查询和Order by等查询，读取记录只能按Row key（及其range）或全表扫描，因此Row key需要根据业务来设计以利用其存储排序特性（Table按Row key字典序排序如1,10,100,11,2）提高性能。
2.Column Family（列族）
在表创建时声明，每个Column Family为一个存储单元。在上例中设计了一个HBase表blog，该表有两个列族：article和author。
3.Column（列）
HBase的每个列都属于一个列族，以列族名为前缀，如列article:title和article:content属于article列族，author:name和author:nickname属于author列族。
Column不用创建表时定义即可以动态新增，同一Column Family的Columns会群聚在一个存储单元上，并依Column key排序，因此设计时应将具有相同I/O特性的Column设计在一个Column Family上以提高性能。同时这里需要注意的是：这个列是可以增加和删除的，这和我们的传统数据库很大的区别。所以他适合非结构化数据。
4.Timestamp
HBase通过row和column确定一份数据，这份数据的值可能有多个版本，不同版本的值按照时间倒序排序，即最新的数据排在最前面，查询时默认返回最新版本。如上例中row key=1的author:nickname值有两个版本，分别为1317180070811对应的“一叶渡江”和1317180718830对应的“yedu”（对应到实际业务可以理解为在某时刻修改了nickname为yedu，但旧值仍然存在）。Timestamp默认为系统当前时间（精确到毫秒），也可以在写入数据时指定该值。
5.Value
每个值通过4个键唯一索引，tableName+RowKey+ColumnKey+Timestamp=>value，例如上例中{tableName=’blog’,RowKey=’1’,ColumnName=’author:nickname’,Timestamp=’ 1317180718830’}索引到的唯一值是“yedu”。
6.存储类型
TableName 是字符串
RowKey 和 ColumnName 是二进制值（Java 类型 byte[]）
Timestamp 是一个 64 位整数（Java 类型 long）
value 是一个字节数组（Java类型 byte[]）。
7.存储结构
可以简单的将HTable的存储结构理解为
即HTable按Row key自动排序，每个Row包含任意数量个Columns，Columns之间按Column key自动排序，每个Column包含任意数量个Values。理解该存储结构将有助于查询结果的迭代。
Hbase应用场景
---------------------------------
1.半结构化或非结构化数据
对于数据结构字段不够确定或杂乱无章很难按一个概念去进行抽取的数据适合用HBase。以上面的例子为例，当业务发展需要存储author的email，phone，address信息时RDBMS需要停机维护，而HBase支持动态增加.
2.记录非常稀疏
RDBMS的行有多少列是固定的，为null的列浪费了存储空间。而如上文提到的，HBase为null的Column不会被存储，这样既节省了空间又提高了读性能。
3.多版本数据
如上文提到的根据Row key和Column key定位到的Value可以有任意数量的版本值，因此对于需要存储变动历史记录的数据，用HBase就非常方便了。比如上例中的author的Address是会变动的，业务上一般只需要最新的值，但有时可能需要查询到历史值。
4.超大数据量
当数据量越来越大，RDBMS数据库撑不住了，就出现了读写分离策略，通过一个Master专门负责写操作，多个Slave负责读操作，服务器成本倍增。随着压力增加，Master撑不住了，这时就要分库了，把关联不大的数据分开部署，一些join查询不能用了，需要借助中间层。随着数据量的进一步增加，一个表的记录越来越大，查询就变得很慢，于是又得搞分表，比如按ID取模分成多个表以减少单个表的记录数。经历过这些事的人都知道过程是多么的折腾。采用HBase就简单了，只需要加机器即可，HBase会自动水平切分扩展，跟Hadoop的无缝集成保障了其数据可靠性（HDFS）和海量数据分析的高性能（MapReduce）。
Hbase的优缺点
----------------------------------------------------------
优点：
1 列的可以动态增加，并且列为空就不存储数据,节省存储空间.
2 Hbase自动切分数据，使得数据存储自动具有水平scalability.
3 Hbase可以提供高并发读写操作的支持
缺点：
1 不能支持条件查询，只支持按照Row key来查询.
2 暂时不能支持Master server的故障切换,当Master宕机后,整个存储系统就会挂掉.
- 运维角度的Hbase的备份和恢复（灾备）
1.简介
当HBase数据库中存在非常重要的业务数据的时候为了保护数据的可以对数据进行备份处理。对于HBase来说从备份操作来看可分为离线备份和在线备份。
2. 前准备
在测试环境上准备有哦两套HBase集群，资源有限原因他们共享一个hdfs集群和zookeeper，通过配置不同node路径和数据路径来区别开。
3.离线备份
离线备份顾名思义，在做备份的时候需要将集群停止，然后将集群在hdfs上的数据文件夹完整的拷贝到其他目录或者其他hdfs上，之后可以使用让其他集群或本集群重新加载这些数据从而达到备份的目的。之所以需要停止集群，因为如果集群处于服务状态的话，如果拷贝过程中，有数据正在插入或者表正在被创建等就会造成备份的数据的内部冲突。
离线备份总结
一个新集群接收备份数据的前提是，这个集群必须是新建的纯净的，无论在zookeeper上都不能有垃圾数据。另外更加可靠的做法就是你可以先去备份数据，然后在建立hbase集群，在配置文件中将其目录指定到备份文件的目录即可。此种备份方法可以定时执行，因为并不是是实时备份，所以存在丢失数据的风险。
4. 在线备份
在线备份的意思是指不停止集群，将数据备份到同一个集群或者不同集群。好处显而易见，业务不会停止。
在线备份的方法一般有三种：
1.copyTable使用方法
这种方式通过MR计算框架将数据从源表中读取出来，在将这些数据插入到目标集群的目标表中。读取和插入都是走API 客户端的。
copyTable备份总结：
此方法使得在两个集群同时online的时候进行备份，与离线备份一样，由于需要周期性的执行，也会存在数据丢失的风险。
通过copytable方法是针对单个表的备份操作，如果需要进行多个表的备份需要分别处理。
另外由于是通过api的方式读取备份源表的数据，所以势必会造成备份源数据的性能下降。
2.export and import
这种方法通过export工具执行MR任务读取HBase表数据（通过HBase 客户端）dump到相同集群的hdfs上，文件的格式是sequence格式的，在dump的时候可以指定MR的参数来进行压缩。
后续如果需要restore数据的时候通过import将dump下来的文件通过MR任务进行数据插入（通过HBase客户端）。
总结
export和import的组合使用可以进行数据的文件落地然后在restore，他们都是MR任务通过HBase API进行数据的读取和插入。对于dump出来的文件建议放在不同的hdfs集群上避免丢失。
HBase数据的导入和导出
1）导入
首先进入hbase根目录，然后输入下面的命令
bin/hbase org.apache.hadoop.hbase.mapreduce.Driver import 表名 数据文件位置
例如：bin/hbase org.apache.hadoop.hbase.mapreduce.Driver import a file:///opt/data/a
其中数据文件位置可为本地文件目录，也可以分布式文件系统hdfs的路径。
当其为前者时，直接指定即可，也可以加前缀file:///
而当其伟后者时，必须明确指明hdfs的路径，例如hdfs://mymaster:9000/path
2)导出
首先进入hbase根目录，然后输入下面的命令
bin/hbase org.apache.hadoop.hbase.mapreduce.Driver export 表名 数据文件位置
例如：bin/hbase org.apache.hadoop.hbase.mapreduce.Driver export a file:///opt/data/a
同上，其中数据文件位置可为本地文件目录，也可以分布式文件系统hdfs的路径。
3. replication
此种机制相对来说比较复杂，其实HBase本省的备份机制。前述的几种方法都是借用MR和HBAse客户端进行数据的转移。
对于replication的用户会在另外的博文中演示说明[How to]HBase集群备份方法--Replication机制
备份
HBase是一个基于LSM树（log-structured merge-tree）的分布式数据存储系统，它使用复杂的内部机制确保数据准确性、一致性、多版本号等。因此。你怎样获取数十个region server在HDFS和内存中的存储的众多HFile文件、WALs（Write-Ahead-Logs）的一致的数据备份？
让我们从最小的破坏性，最小的数据占用空间，最小的性能要求机制和工作方式到最具破坏性的逐一讲述：
- Snapshots
- Replication
- Export
- CopyTable
- HTable API
- Offline backup of HDFS data
以下的表格提供了一个关于这些方法的高速比較。具体的细节在以下再具体描写叙述。
Snapshots（快照）
HBase快照功能丰富。有非常多特征，而且创建时不须要关闭集群。
关于snapshot在文章《apache hbase snapshot介绍》中有更具体的介绍。
快照能通过在HDFS中创建一个和unix硬链接同样的存储文件，简单捕捉你的hbase表的某一时刻的信息（图1）。这些快照在几秒内就能够完毕，差点儿对整个集群没有不论什么性能影响。
而且。它仅仅占用一个微不足道的空间。除了在metadata文件里存储的极少文件夹数据，你的数据不会冗余，快照同意你的系统回滚到（创建快照）那个时刻。当然。你须要恢复快照。
正如你看到的。恢复快照须要对表进行离线操作。
一旦恢复快照。那不论什么在快照时刻之后做的添加/更新数据都会丢失。
假设你的业务需求是这种：你必须有数据的异地备份，你能够用exportSnapshot命令赋值一个表的数据到你的本地HDFS或者你选择的远程HDFS中。
快照是你的表在某一个时刻的完整图像。眼下没有增量快照功能可用。
HBase复制（HBase Relication）
HBase赋值是另外一个负载较轻的备份工具。
文章《HBase复制概述》有对它的具体描写叙述。
总的来说，赋值被定义为列簇级别，能够工作在后台而且保证全部的编辑操作在集群复制链之间的同步。
复制有三种模式：主->从(master->slave)。主<->主(master<->master)和循环（cyclic）。这样的方法给你灵活的从随意数据中心获取数据而且确保它能获得在其它数据中心的全部副本。
在一个数据中心发生灾难性故障的情况下，client应用程序能够利用DNS工具，重定向到另外一个备用位置。
复制是一个强大的。容错的过程。
它提供了“终于一致性”，意味着在不论什么时刻，近期对一个表的编辑可能无法应用到该表的全部副本。可是终于可以确保一致。
注：对于一个存在的表，你须要通过本文描写叙述的其它方法，手工的拷贝源表到目的表。
复制只在你启动它之后才对新的写/编辑操作有效。
导出（Export）
HBase的导出工具是一个内置的有用功能。它使数据非常easy从hbase表导入HDFS文件夹下的SequenceFiles文件。
它创造了一个map reduce任务。通过一系列HBase API来调用集群，获取指定表格的每一行数据。而且将数据写入指定的HDFS文件夹中。这个工具对集群来讲是性能密集的，由于它使用了mapreduce和HBase clientAPI。
可是它的功能丰富。支持制定版本号或日期范围。支持数据的筛选，从而使增量备份可用。
以下是一个导出命令的简单样例：
hbase org.apache.hadoop.hbase.mapreduce.Export <tablename> <outputdir>
一旦你的表导出了，你就能够复制生成的数据文件到你想存储的不论什么地方（比方异地/离线集群存储）。你能够运行一个远程的HDFS集群/文件夹作为命令的输出文件夹參数，这样数据将会直接被导出到远程集群。使用这种方法须要网络。所以你应该确保到远程集群的网络连接是否可靠以及高速。
拷贝表（CopyTable）
拷贝表功能在文章《使用CopyTable在线备份HBase》中有具体描写叙述，可是这里做了主要的总结。和导出功能类似，拷贝表也使用HBase API创建了一个mapreduce任务。以便从源表读取数据。
不同的地方是拷贝表的输出是hbase中的还有一个表，这个表能够在本地集群，也能够在远程集群。
一个简单的样例例如以下：
hbase org.apache.hadoop.hbase.mapreduce.CopyTable --new.name=testCopy test
这个命令将会拷贝名为test的表到集群中的另外一个表testCopy。
请注意，这里有一个明显的性能开销，它使用独立的“puts”操作来逐行的写入数据到目的表。假设你的表很大。拷贝表将会导致目标region server上的memstore被填满。会引起flush操作并终于导致合并操作的产生，会有垃圾收集操作等等。
此外，你必须考虑到在HBase上执行mapreduce任务所带来的性能影响。对于大型的数据集，这样的方法的效果可能不太理想。
HBase API（比方作为一个java应用）
因为总是这样使用hadoop。你能够使用公用的api写自己定制的client应用程序来直接查询表格。你也能够通过mapreduce任务的批量处理优势，或者自己设计的其它手段。然而，这种方法须要对hadoop开发以及因此对生产集群带来的影响有深入的理解。
离线备份原生的HDFS数据（Offline Backup of Raw HDFS Data）
最强力的备份机制。也是破坏性最大的一个。
涉及到最大的数据占用空间。
你能够干净的关闭你的HBase集群而且手工的在HDFS上拷贝数据。由于HBase已经关闭，所以能确保全部的数据已经被持久化到HDFS上的HFile文件里，你也将能获得一个最准确的数据副本。
可是，增量的数据差点儿不能再获得，你将无法确定哪些数据发生了变化。
同一时候也须要注意。恢复你的数据将须要一个离线的元数据由于.META.表将包括在修复时可能无效的信息。这样的方法须要一个高速的。可信赖的网络来传输异地的数据，假设须要在稍后恢复它的话。
因为这些原因。Cloudera很不鼓舞在HBase中这样的备份方法。
故障恢复（Disaster Recory）
HBase被设计为一个非常能容忍错误的分布式系统，如果硬件失败非常频繁。在HBase中的故障恢复通常有下面几种形式：
- 在数据中心级别的灾难性故障，须要切换到备份位置；
- 须要恢复因为用户错误或者意外删除的数据的之前一个拷贝；
- 出于审计目的，恢复实时点数据拷贝的能力
正如其它的故障恢复计划，业务须要驱动这你怎样架构而且投入多少金钱。一旦你确定了你将要选择的备份方案。恢复将有下面几种类型：
- 故障转移到备份集群
- 导入表/恢复快照
- 指向HBase在备份位置的根文件夹
假设你的备份策略是这种，你复制你的HBase数据在不同数据中心的备份集群，故障转移将变得简单。仅须要使用DNS技术。转移你的应用程序。
请记住。假设你打算同意数据在停运时写入你的备份集群，那你须要确保在停运结束后。数据能够回到主机群。主<->主或循环的复制架构能自己主动处理这个过程。但对于一个主从结构来讲。你就须要手动进行干预了。
你也能够在故障时通过简单的改动hbase-site.xml的 hbase.root.dir属性来更改hbase根文件夹，可是这是最不理想的还原选项。由于你复制完数据返回生产集群时，正如之前提到的。可能会发现.META是不同步的。
总结
综上所述。从某种损失或中断中恢复数据须要一个精心设计的BDR计划。
强烈建议你彻底明确你的业务需求，然后明确数据准确度/可用性以及故障恢复的最大时间。有了这些知识，你才干更好的选择满足这些需求的工具。
选择工具不过个開始。你应该对你的BDR策略进行大规模測试，以确保它的在你的基础设施下的功能。
而且，你应该是很熟悉全部的故障恢复步骤。
- 运维角度关于Hbase的监控问题
1.监控Hbase运行状况
1.1.群集网络IO，磁盘IO，HDFS IO
IO越大说明文件读写操作越多。当IO突然增加时，有可能：1.compact队列较大，集群正在进行大量压缩操作。
2.正在执行mapreduce作业
可以通过CDH前台查看整个集群综合的数据或进入指定机器的前台查看单台机器的数据：(218的数据)
3.Io wait
磁盘IO对集群的影响比较大，如果io wait时间过长需检查系统或磁盘是否有异常。通常IO增加时io wait也会增加，现在FMS的机器正常情况io wait在50ms以下
跟主机相关的指标可以在CDH前台左上角先点“主机”选项卡然后选要查看的主机：
4.CPU
如果CPU占用过高有可能是异常情况引起集群资源消耗，可以通过其他指标和日志来查看集群正在做什么。
5.内存 （监控谁的情况）（zabbix深入！）
6.JAVA
GC 情况
regionserver长时间GC会影响集群性能并且有可能会造成假死的情况
7.重要的hbase指标
region情况
需要检查
1.region的数量（总数和每台regionserver上的region数）
2.region的大小
如果发现异常可以通过手动merge region和手动分配region来调整
从CDH前台和master前台以及regionServer的前台都可以看到region数量，如master前台：
在region server前台可以看到storeFile大小：
在前台可以看到对应的Tables（看是否对应）
当然还可以看对应的logs
- 运维角度关于Kafka的监控问题
目前Kafka监控方案看似很多，然而并没有一个“大而全”的通用解决方案。各家框架也是各有千秋，以下是我了解到的一些内容：
Kafka manager
Github地址： https://github.com/yahoo/kafka-manager。 这款监控框架的好处在于监控内容相对丰富，既能够实现broker级常见的JMX监控(比如出入站流量监控)，也能对consumer消费进度进行监控(比如lag等)。另外用户还能在页面上直接对集群进行管理，比如分区重分配或创建topic——当然这是一把双刃剑，好在kafka manager自己提供了只读机制，允许用户禁掉这些管理功能。
Kafka Monitor
Github地址：https://github.com/linkedin/kafka-monitor。 这款监控框架更多的是关注对Kafka集群做端到端的整体系统测试，并产出各种系统级的监控指标，比如端到端的延时，整体消息丢失率等。对于新搭建的Kafka线上集群，使用Kafka Monitor做个整体测试有助于你了解该集群整体的一些性能，但若是用于日常监控该框架便有些不便了，需要自己修改webapp/index.html中的监控指标，流程上有些不太友好。不过这款框架的优势是其主要贡献者是LinkedIn的lindong(Kafka 1.0.0版本中正式支持JBOD就是lindong开发的)，质量上应该是有保证的。
Kafka Offset Monitor
Github地址：https://github.com/quantifind/KafkaOffsetMonitor。 KafkaOffsetMonitor应该算比较早的监控框架了，有着很酷的UI，使用者也是很多。但其比较大的劣势是对新版本consumer和security的支持，另外该项目已经近2年未维护了，其主力开发甚至是另起炉灶，重新写了一个新的KafkaOffsetMonitor来支持新版本consumer——https://github.com/Morningstar/kafka-offset-monitor。不过目前该项目star数很少，应该没有大规模应用，到底是否适用于生产环境需要用户自行判断
Burrow
Github地址： https://github.com/linkedin/Burrow。 Burrow是LinkedIn开源的一款专门监控consumer lag的框架。事实上，当初其开源时我对它还是期待挺高的，不过令人遗憾地是后劲不足，发展得非常缓慢，而且这款框架是用Go写的，安装时要求必须有Go运行环境，故Burrow在普及上不如其他框架。Burrow没有UI界面，只开放了很多HTTP endpoint，这对于想偷懒的运维来说更是一个减分项。总之它的功能目前十分有限，普及率和知名度都是比较低的。不过好处是该项目主要贡献者是LinkedIn团队维护Kafka集群的主要负责人，故质量上是很有保证的
JMXTrans + InfluxDB + Grafana
我在本地虚拟机中尝试了kafka offsetmonitor这种方案，被它的简单页面所吸引，但是我更想尝试JMXTrans + InfluxDB + Grafana，页面比较酷炫，还是有点含量，能够直观的看出Kafka的一些状态，以及处理的速率，还是比较心动的，值得深入研究。
我在尝试kafaka monitor的时候，下载了github上面的jar包，按照博客中的流程走了一遍.
(理想情况下是下面的情况)
KafkaOffsetMonitor运行比较简单，因为所有运行文件，资源文件，jar文件都打包到KafkaOffsetMonitor-assembly-0.2.0.jar了，直接运行就可以
a.新建一个目录monitor然后把jar拷贝到该目录下.
b.新建脚本，因为您可能不是一个kafka集群。用脚本可以启动多个
Vim kafka_monitor.sh
#!/bin/bash
java -Xms512M -Xmx512M -Xss1024K -XX:PermSize=256m -XX:MaxPermSize=512m
-cp
KafkaOffsetMonitor-assembly-0.2.0.jar \
com.quantifind.kafka.offsetapp.OffsetGetterWeb \
--zk 192.168.0.103:2181 \
--port 8086 \
--refresh 10.seconds \
--retain 7.days 1
chmod +x kafka_monitor.sh
/kafka_monitor.sh
消费者组列表
topic的所有partiton消费情况列表
以上图中参数含义解释如下：
topic：创建时topic名称
partition：分区编号
offset：表示该parition已经消费了多少条message
logSize：表示该partition已经写了多少条message
Lag：表示有多少条message没有被消费。
Owner：表示消费者
Created：该partition创建时间
Last Seen：消费状态刷新最新时间。
kafka正在运行的topic
kafka集群中topic列表
kafka集群中broker列表
但是我在运行执行了下面的命令当中却发现了这个问题
java -cp KafkaOffsetMonitor-assembly-0.2.0.jar com.quantifind.kafka.offsetapp.OffsetGetterWeb --zk localhost:12181 --port 18089 --refresh 5.seconds --retain 1.days
- CDH监控kafka （218）
一．平台
Hdfs（存数据，分布式文件系统，存储情况，磁盘空间）
Zookeeper(存资源，存字典，机制。leader,调度，运行状况，备份那些东西)
Yarn（资源调配组件）
spark(工具，checkpoint缓存在hdfs上，定期清除数据，监控,那些在run,磁盘空间情况)
Hbase（数据，热备，怎么备，备哪些？就是日常的备份，磁盘情况）
kafka(传输工具,占空间很大，报错情况，自带设置，监控kafka的磁盘空间情况)
redis() 热备备份什么，清理什么东西
1.日常演练（灾难恢复）
2.CDH，任何一个环节可以加node节点
细化，熟悉，扩展。 每一个组件怎么做，怎么弄
- 深入研究zabbix,把上面的提到的平台放入到zabbix
- 先把一个能够一个
- Kafka ，spark日常的一些错误，演练下（防危）那些指标
- Hdfs ,Hbase 日常的备份，就是一个文件，一个数据。
