ccql's Blog

Sink Processors类型包括这三种：Default Sink Processor、Load balancing Sink Processor和Failover Sink Processor。Default Sink Processor是默认的，不用配置Sink group，就是咱们现在使用的这种最普通的形式，一个Channel后面接一个Sink的形式；

注意：格式化操作只能执行一次，如果格式化的时候失败了，可以修改配置文件后再执行格式化，如果格式化成功了就不能再重复执行了，否则集群就会出现问题。hadoop集群就会使用到ssh，我们在启动集群的时候只需要在一台机器上启动就行，然后hadoop会通过ssh连到其它机器，把其它机器上面对应的程序也启动起来，为了不用每次输入密码，所以现在需要实现ssh免密码登录。集群只要涉及到多个节点的就需要对这些节点做时间同步，如果节点之间时间不同步相差太多，会应该集群的稳定性，甚至导致集群出问题。

通俗来讲，Channel Selectors组件控制Source采集到的数据分别流向哪些Channels。组件包括Replicating Channel Selector、Load Balancing Channel Selector和Multiplexing Channel Selector，其中Replicating Channel Selector是默认的Channel选择器，它会将Source采集过来的Event发往所有Channel；

Flume的核心组件包括：Source、Channel和Sink；Source Interceptors：Source可以指定一个或者多个拦截器按先后顺序依次对采集到的数据进行处理；Channel Selectors：Source发往多个Channel的策略设置，如果Source后面接了多个Channel，那么到底是给所有的Channel都发，还是根据规则发送到不同Channel，这些是由Channel Selectors来控制的；

将机器A（bigData02）和机器B（bigData03）两台机器实时产生的日志数据汇总到机器C（bigData04）中，再通过机器C（bigData04）将数据统一上传至HDFS的指定目录中。因为一台机器可以有多个ip，例如：内网ip、外网ip，如果通过bind参数指定某一个ip的话，表示就只监听通过这个ip发送过来的数据了，这样会有局限性，所以使用通用ip。一共涉及到三个机器，其中机器A和B收集网站信息，并发送给机器C汇总传输到HDFS，因此需要配置三台机器，机器A和B的配置基本相同。

要完成这个任务就需要使用在采集数据时使用Spooling Directory Source组件；传输数据时为了保证数据没有丢失风险，使用File Channel组件；在运行Flume之前应该先检查建立采集数据的文件夹和文件，且系统此时直接启动会报错提示找不到SequenceFile，虽然我们已经把fileType改为了DataStream，但是Flume默认还是会加载这个类。Flume各个组件的参数很多，因此通常复制官网的各组件样例程序并参照参数表进行修改。解决了这个问题后，在。

由于MapReduce默认采用Capacity Scheduler（详见），因此理论上可以存在多个队列，而默认只有一个队列（default），现有需求：额外创建两个队列分别为online和offline，将这三个队列的资源分别分配为70%、10%、20%，且允许在资源不足时借用其他队列的资源，但最多不能超过70%（online队列里面运行实时任务，offline队列里面运行离线任务，MapReduce属于离线任务），最后将WordCount任务提交到offline队列执行。

YARN是Hadoop资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

本文仅记录上传文件、下载文件和删除文件三个操作。这三个操作有着相似的逻辑，都是先创建配置对象，然后获取操作HDFS的对象，最后再进行各自的功能实现。

HDFS在core-site.xml中进行配置后，会为每一个用户在“/user/用户名/.Trash/”地址创建一个回收站目录，每个被用户使用Shell命令行删除的文件或者目录，都会被移动到回收站目录中。但如果一直保存而不清空回收站目录的话，注定会出现问题，因此回收站中的数据都有一个生存周期，也就是当回收站中的文件或者目录在一段时间之内没有被用户恢复的话，HDFS就会自动的把这个文件或者目录彻底删除。注意：默认情况下HDFS的回收站是没有开启的，需要通过修改core-site.xml配置文件来开启。

MapReduce是一种分布式计算模型，是Google提出来的，主要用于搜索领域，解决海量数据的计算问题。MapReduce的全套过程分为三个大阶段，分别是Map、Shuffle和Reduce。结合多篇资料，我最终确定划分11个小步骤来描述这个过程，在后续的内容中我也会结合一部分源码来进行剖析。

本文主要介绍了HDFS的常见shell操作，包含查询指定路径信息、上传和下载文件、浏览文件、创建文件夹、删除操作以及综合应用等。

通俗的讲，集群启动时DataNode会向NameNode上报所有的Block块信息，每个块（无论大小）对象约占150byte，而NameNode的内存是有限的，当HDFS文件愈来愈多的时候，NameNode就会成为集群的短板（这也是为什么HDFS不适合存储小文件的原因）。图中的Zookeeper是为了实现自动切换NameNode功能，当多个NameNode启动的时候会分别向Zookeeper中注册一个临时节点，当它挂掉的时候，这个临时节点也就消失了，这是Zookeeper的特性。

HDFS主要包含NameNode、Secondary NameNode和DataNode三部分，且这三部分在分布式文件系统中分属不同的机器，其中Secondary NameNode不是必须的，在HA架构中Standby NameNode可以替代它。

Hadoop的HDFS和MapReduce都是针对大数据文件来设计的，在小文件的处理上不但效率低下，而且十分消耗内存资源。在这篇博客中有提到HDFS的小文件问题，集群启动时DataNode会向NameNode上报所有的Block块信息，每个块（无论大小）对象约占150byte，而NameNode的内存是有限的，那么有可能集群内部其实并没有存储多少数据，但是NameNode已经存满了，针对这个问题采用Federation机制可以缓解。

在博客【Hadoop】MapReduce原理剖析（Map，Shuffle，Reduce三阶段）中已经分析了MapReduce的运行过程，以及部分原理。那么这篇博客则是进行一次实践，使用MapReduce统计文本中的单词数量。实际上我们只需要写Mapper和Reducer部分的代码即可，最后在Main中进行一些设置即可。

默认情况下Map任务的数量与InputSplit数量保持一致，Map阶段的执行效率也与InputSplit数量相关，当遇到大量的小文件时我们采用SequenceFile合并成一个大文件，以此来提高运行效率（默认情况下只有一个Reduce任务，那么解决了map阶段的小文件问题后，Reduce阶段的运行效率就是MapReduce运行效率的短板，我们当然可以通过增加Reduce任务的数量来提高数据处理的并行度，以此提高效率，但这种处理是“治标不治本”的。

这篇博客是一个结合HDFS的Shell练习，相对简单。现有需求：每天1:00需要从系统上传一份昨天的日志文件到HDFS，日志文件的格式为access_2023_01_01.log，HDFS目录格式为20230101。在shell脚本中向yesterday变量赋值时使用反引号（``），因为需要解析反引号中的字符命令并执行得出结果。这行命令是为了加载环境变量，因为直接使用了。文件即为上传的日志文件。命令，正常情况下应该是。