【数据中台】大数据常用hadoop组件

1.Hadoop

1.1 定义

Hadoop是一个开发和运行处理大规模数据的软件平台，允许使用简单的编程模型在大量计算机集群上对大型数据集成进行分布式处理。

hadoop1.x的核心组件由：HDFS和MapReduce。

hadoop2.x的核心组件由：
HDFS（分布式文件系统）：解决资源任务调度

YARN（作业调度和集群资源管理的框架）解决资源任务调度

MapReduce（分布式运算编程框架）：解决海量数据计算

---

现在Hadoop通常是指一个更广泛的概念-Hadoop生态圈。比如：

• HDFS：分布式文件系统
• MapReduce：分布式运算程序开发框架
• Hive：基于Hadoop的分布式数据仓库，提供基于sql的查询数据操作
• HBase：基于Hadoop的分布式海量数据库
• Zookeeper：分布式协调服务基础组件
• Mahout：基于Mapreduce/Spark/flink等分布式运算框架的机器学习算法库
• Oozie：工作流调度框架
• Sqoop：数据导入导出工具（比如用于Oracle和HDFS）
• Flume：日志数据采集框架
• Impala：基于Hadoop的实时分析

1.2 特点优点

1. 扩容能力：Hadoop是在可用的计算机集群间分配数据并完成计算任务，这些集群可用方便的扩展到数以千计的节点中。
2. 低成本：Hadoop通过普通廉价打完机器组成服务器集群来分发以及处理数据，以至于成本很低。
3. 高效率：通过并发数据，Hadoop可以在节点之间动态并行的移动数据，使得速度非常快。
4. 可靠性：能自动维护数据的多份复制，并且在任务失败后能自动地重新部署计算任务，所以Hadoop的按位存储和处理数据的能力值得人们信赖。

1.3 Hadoop优化

1.3.1 Mapreduce跑的慢的原因

1. 计算性能，如CPU、内存、磁盘健康，网络
2. I/O操作优化

• 数据倾斜
• Map和Reduce数设置不合理
• Map运行时间长，导致Reduce等待过久
• 小文件过多
• 大量的不可分块的超大文件
• Split次数过多
• Merge次数过多

1.3.2 优化方法

1. 数据输入
2. Map阶段
3. Reduce阶段
4. IO传输

• 采用数据压缩的方式，减少网络IO的时间，安装Snappy和LZO压缩编码器。
• 使用SequenceFile二进制文件。

5. 数据倾斜问题原因与方法

• 数据频率倾斜，某一个区域的数据量要远远大于其他区域。
• 数据大小倾斜，部分记录的大小远远大于平均值。

方法一：抽样和范围分区

方法二：自定义分区

方法三：Combine

方法四：采用Map Join，尽量避免Reduce Join。

2.HDFS

HDFS是Hadoop分布式文件系统,是Hadoop核心组件之一，座位最底层的分布式存储服务而存在。分布式文件系统解决的问题就是大数据存储，它们是横跨多台计算机上的存储系统。

2.1 HDFS设计目标

1. 故障的检测和自动快速恢复是HDFS的核心构架目标。
2. HDFS上的应用与一般的应用不同，他们主要是以流式读取数据。HDFS被设计成适合批量处理，而不是用户交互式的，相较于数据访问的反应时间，更注重数据访问的高吞吐量。
3. 典型的HDFS文件大小是GB到TB的级别。
4. 大部分HDFS应用的文件要求是write-one-read-many访问模型，这一假设简化了数据的一致性问题，使高吞吐的数据访问成为可能。
5. 移动计算的代价比移动数据的代价低。
6. 在异构的硬件和软件平台上的可移植性。

2.2 HDFS的重要特性

首先，是一个文件系统，用于存储文件，通过统一命名空间目录树来定位定位文件。
其次，他是分布式的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色。

1. master/slave架构，一般一个HDFS集群是由一个NameNode和一定数量的DataNode组成，NameNode是HDFS集群主节点，DataNode是HDFS集群从节点，两种角色各司其职，共同协调完成分布式的文件存储服务。
2. 分块存储，在物理上是分块存储的，快的大小可以通过配置参数来规定，2.0版本的默认大小为128M。
3. 名字空间，支持传统的层次型文件组织结构，NameNode负责维护文件系统的名字空间，任何对文件系统名字空间或者属性的修改都将被NameNode记录下来，同时会给客户端提供一个统一的抽象目录树，客户端通过路径来访问文件。
4. NameNode元数据管理，目录结构及文件分块位置信息叫做元数据，NameNode负责维护整个HDFS文件系统的目录树结构，以及，每一个文件所对应的block块信息。
5. DataNode数据存储，文件的各个block的具体存储管理由DataNode节点承担，每一个block都可以在多个DataNode需要定时向Namenode汇报自己持有的block信息，同时，存储多个副本，副本数量也可以通过参数设置dfs.replication,默认是3。
6. 文件所有的block都会有副本，每个文件的block大小和副本系数都是可配置的。
7. 一次写入，多次读取。设计成一次写入，多次读取的场景，且不支持文件的修改。

2.3 优缺点

• 优点

1. 高容错性
2. 适合处理大数据
3. 可构建在廉价的机器上，通过多副本机制，提高可靠性。

• 缺点

1. 不适合低延时数据访问。
2. 无法高效的对大量小文件进行存储。
3. 不支持并发写入,文件随机修改

2.4 小文件解决方法

小文件的优化无非以下几种方式：

1. 在数据采集的时候，就将小文件或小批数据合成大文件再上传HDFS。

• Hadoop Archive，是一个高效地将小文件放入HDFS块中的文件存档工具，它能够将多个小文件打包成一个Har文件，这样就减少了NameNode的内存使用。

2. 在业务处理之前，在HDFS上使用MapReduce程序对小文件进行合并。

• SequenceFile是一系列二进制K/V组成，如果key为文件名，value为文件内容，则可以将大批小文件合并成一个大文件。

3. 在MapReduce处理时，可采用CombineYextInputFormat提高效率。

• CombineYextInputFormat是一种新的InputFormat，用于将多个文件合并成一个单独的Spilt，另外，它会考虑数据存储的位置。

3.HBase

HBase是一个高可靠性，高性能，面向列、可伸缩的分布式存储系统，利用HBase技术可以在廉价的PC Sever上搭建起大规模结构化存储集群。

3.1 特点

1. 海量存储，适合存储PB级别的海量数据，在PB级别的数据以及采用廉价pc存储的情况下，能在几十到百毫秒内返回数据。
2. 列式存储，HBase是根据列族拉开存储数据的，列族下面可以有非常多的列，列族在创建表的时候就必须制定。
3. 极易扩展，其扩展性主要表现在两个方面，一个是基础上层处理能力的扩展，一个是基于存储的扩展。
4. 高并发，由于采用廉价PC，因此单个IO的延迟其实并不小，一般在几十到上百个MS之间，这里说是在并发情况下，Hbase的单个IO延迟下降并不多。
5. 稀疏，主要是针对Hbase列的灵活性，在列族中，可以指定任意多的列，在列数据为空的情况下，是不会占用存储空间的。

3.2 架构

Hbase由Client、zookeeper、Master、HRegionSever、HDFS等几个组件组成。

1. Client包含了访问Hbase的接口，另外Client还维护了对应的cache来加速Hbase的访问，比如cache的.META.元数据的信息.

2. Zookpeeper,Hbase通过Zookeeper来做master的高可用、RegionSever的监控、元数据的入口以及集群配置的维护等工作，具体如下：

• 通过Zookeeper来保证集群中只有一个master在运行，如果master异常，会通过竞争机制产生新的master提供服务。
• 通过Zookeeper来监控RegionSever的状态，当RegionSever有异常的时候，通过回调的形式通知Master RegionSever上下线的信息。
• 通过Zoopkeeper存储元数据的统一入口地址。

3. Hmaster

• 为RegionSever分配Region
• 维护整个集群的负载均衡
• 维护集群的元数据信息
• 发现时效的Region，并将失效的Region分配到正常的RegionSever上
• 当RegionSever失效的时候，协调对应的Hlog的拆分

4. HregionSever，直接对接用户的读写请求，是真正的“干活”节点。功能如下：

• 管理master为其分配的Region
• 处理来自客户端的读写请求
• 负责和底层HDFS的交互，存储数据到HDFS
• 负责Region变大以后的拆分
• 负责Storefile的合并工作

5. HDFS

• HDFS为Hbase提供最终的底层数据存储服务，同时为HBase提供该可用的支持，提供元数据和表数据的底层分布式存储服务，数据多副本，保证的高可靠和高可用性。

4.Zookeeper

是一个开源分布式应用提供协调服务的Apache项目。

4.1 工作机制

是一个基于观察者模式设计的分布式服务管理框架，他负责存储和管理数据，然后接受观察者的注册，一旦这些数据的状态发生变化，它就就负责通知已经在Zookeeper上已注册的观察者做出相应的反应。

• Zookeeper = 文件系统 + 通知机制

4.2 特点

1. 由1个领导者（Leader），多个跟随者（Follower）组成的集群。
2. 集群中中要有半数以上的节点存活，Zookeeper集群就能正常服务。
3. 全局数据一致性，每个Sever保存一份相同的数据副本，Client无论连接哪个服务器，数据都是一致的。
4. 更新请求顺序进行，来自同一个Client的更新请求按其发送顺序依次执行。
5. 数据更新原子性，要么成功，要么失败。（事务性）
6. 实时性，在一定范围内，Client能读到最新数据。

4.2 选举机制

1. 选举机制：集群中半数以上机器存货，集群可用，所以Zookeeper适合安装技术台服务器。
2. 虽然在配置文件中并没有指定Master和Slave。但是在工作时，是有一个节点为leader，其他则为Follower，leader是通过内部的选举机制临时产生的。

4.3 监听器原理

1. 首先要有一个main（）线程。
2. 在main线程中创建Zookeeper客户端，这是会创建两个线程，一个负责网络连接通信（connet），一个负责监听（listener）。
3. 通过connect线程将注册的监听事件发送给Zookeeper。
4. 在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中。
5. Zookeeper监听到有数据变化或路径变化，就会将这个消息发送给listener线程。
6. listener线程内部调用了process（）方法。

4.4 部署方式有哪几种？集群中的角色有哪些？集群最少需要多少台机器？

1. 部署方式：单机模式，集群模式
2. 角色：leader和follower
3. 最少需要服务器数：3

5.YARN

Yarn是一个资源调度平台，负责为运算程序提供服务器运算资源，相当于一个分布式的操作系统平台，而MapReduce等运算程序则相当于运行于操作系统之上的应用程序。

5.1 基本构架

主要有ResourceManager，NodeManager， ApplicationMaster， Container等组件构成。

5.2 工作机制

（0）Mr 程序提交到客户端所在的节点。

（1）Yarnrunner 向 Resourcemanager 申请一个 Application。

（2）rm 将该应用程序的资源路径返回给 yarnrunner。

（3）该程序将运行所需资源提交到 HDFS 上。

（4）程序资源提交完毕后，申请运行 mrAppMaster。

（5）RM 将用户的请求初始化成一个 task。

（6）其中一个 NodeManager 领取到 task 任务。

（7）该 NodeManager 创建容器 Container，并产生 MRAppmaster。

（8）Container 从 HDFS 上拷贝资源到本地。

（9）MRAppmaster 向 RM 申请运行 maptask 资源。

（10）RM 将运行 maptask 任务分配给另外两个 NodeManager，另两个 NodeManager 分

别领取任务并创建容器。

（11）MR 向两个接收到任务的 NodeManager 发送程序启动脚本，这两个 NodeManager

分别启动 maptask，maptask 对数据分区排序。

（12）MrAppMaster 等待所有 maptask 运行完毕后，向 RM 申请容器，运行 reduce task。

（13）reduce task 向 maptask 获取相应分区的数据。

（14）程序运行完毕后，MR 会向 RM 申请注销自己。

5.3 资源调度器

1. FIFO（先进先出）
   按照到达时间排序，先到先服务。
2. 容器调度器
   支持多个队列，每个队列可配置一定的资源量，每个队列均采用FIFO调度策略，按照到达时间排序，先到先服务。
3. 公平调度器
   支持多队列多用户，每个队列中的资源可以配置，同一队列中的作业公平共享队列中所有的资源，按照缺额排序，缺额大者优先。

6.Kafka

在流式计算中，kafka一般用来缓存数据，Storm通过消费Kafka的数据进行计算。kafka是一个分布式消息队列，kafka对消息保存时根据Topic进行归类，发送消息者称为Producer，消息接受者称为Consumer，此外kafka集群有多个kafka实力组成，每个实例（sever）称为broker。

• 无论kafka集群，还是consumer都依赖与Zookeeper集群保存的一些元数据信息，来保证系统可用性。

6.1 消息队列

1. 点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）
   点对点模型通常是一个基于拉取或者轮询的消息传送模型这种消息从队列中请求信息，而不是将信息推送到客户端。这个模型的特点是发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。

2. 发布/订阅模式（一对多，数据生产后，推送给所有订阅者）
   发布订阅模型则是一个基于推送的消息传送模型，发布订阅模型可以有多种不同的订阅者，临时订阅者只在主动监听主题时才接收消息，而持久订阅者则监听主题的所有消息，即使当前订阅者不可用，处于离线状态。
   

6.2 Kafka架构

1. producer:消息生产者，就是向kafka broker发消息的客户端；
2. consumer：消息消费者，向kafka beoker取消息的客户端；
3. topic:可以理解为一个队列；
4. consumer group（CG）：kafka用来实现一个topic消息的广播，和单播的手段，一个topic可以有多个CG。topic的消息会复制到所有的CG。topic的消息会复制到所有的CG，但每个partion只会把信息发给该CG中的一个consumer。如果需要实现广播，只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。用CG还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic。
5. broker：一台kafka服务器就是一个broker，一个集群由多个broker组成。一个broker可以容纳多个topic。
6. partition：为了实现扩展性，一个非常大的topic可以分布到多个broker上，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset），kafka只保证按一个partition中的顺序将消息发给consumer，不保证一个topic的整体的顺序。
7. offset：kafka的存储文件都是按照offset。kafka来命名，用offset来做名字的好处是方便查找。

7.Flume

Flume是Clouder提供的一个高可用，高可靠，分布式的海量日志采集，聚合和传输的系统。flume基于流式架构，灵活简单。

• flume的主要作用就是实时读取本地磁盘的数据，将数据写入到HDFS。

7.1 Flume组成架构

7.1.1 Agent

Agent是一个JVM进程，它以事件的形式将数据从源头送至目的地，是flume数据传输的基本单元。Agent主要有三个部分组成，Source， Channel， Sink。

7.1.2 Source

Source是负责接收数据到Flume Agent的组件。Source组件可以处理各种类型，各种格式的日志数据，包括avro，thrift， exec， jms， spooling directory， netcat， swquence generator，syslog、http、legacy。

7.1.3 Channel

Channel是位于Source和Sink之间的缓冲区。因此，Channel允许Source和Sink运作
在不同的速率上。Channel是线程安全的，可以同时处理几个Source的写入操作和几个Sink
的读取操作。

Flume自带两种Channel：MemoryChannel和FileChannel。

• MemoryChannel是内存中的队列。MemoryChannel在不需要关心数据丢失的情景下适用。如果需要关心数据丢失，那么MemoryChannel就不应该使用，因为程序死亡、机器宕
  机或者重启都会导致数据丢失。
• FileChannel将所有事件写到磁盘。因此在程序关闭或机器宕机的情况下不会丢失数据。

7.1.4 Sink

Sink不断地轮询Channel中的事件且批量地移除它们，并将这些事件批量写入到存储或索引系统、或者被发送到另一个FlumeAgent。

Sink是完全事务性的。在从Channel批量删除数据之前，每个Sink用Channel启动一个事务。批量事件一旦成功写出到存储系统或下一个FlumeAgent，Sink就利用Channel提交事务。事务一旦被提交，该Channel从自己的内部缓冲区删除事件。

Sink组件目的地包括hdfs、logger、avro、thrift、ipc、file、null、HBase、solr、自定义。

7.2 如何实现Flume数据传输的监控

使用第三方框架Ganglia实时监控Flume。

7.3 Flume调优

7.3.1 Source

增加Source个（使用TairDirSource时可增加FileGroups个数）可以增大Source的读取数据的能力。例如：当某一个目录产生的文件过多时需要将这个文件目录拆分成多个文件目录，同时配置好多个Source以保证Source有足够的能力获取到新产生的数据。batchSize参数决定Source一次批量运输到Channel的event条数，适当调大这个参数可以提高Source搬运Event到Channel时的性能。

7.3.2 Channel

type选择memory时Channel的性能最好，但是如果Flume进程意外挂掉可能会丢失数据。type选择file时Channel的容错性更好，但是性能上会比memorychannel差。使用fileChannel时dataDirs配置多个不同盘下的目录可以提高性能。Capacity参数决定Channel可容纳最大的event条数。transactionCapacity参数决定每次Source往channel里面写的最大event条数和每次Sink从channel里面读的最大event条数。transactionCapacity需要大于Source和Sink的batchSize参数。

7.3.3 Sink

增加Sink的个数可以增加Sink消费event的能力。Sink也不是越多越好够用就行，过多的Sink会占用系统资源，造成系统资源不必要的浪费。batchSize参数决定Sink一次批量从Channel读取的event条数，适当调大这个参数可以提高Sink从Channel搬出event的性能。

7.4 Flume的事务机制

Flume的事务机制（类似数据库的事务机制）：Flume使用两个独立的事务分别负责从Soucrce到Channel，以及从Channel到Sink的事件传递。

7.5 Flume采集数据会丢失吗?

不会，Channel存储可以存储在File中，数据传输自身有事务。

7.6 项目中为什么通常flume和kafka要共同使用？

1. 生产环境中，往往是读取日志进行分析，而这往往是多数据源的，如果Kafka构建多个生产者使用文件流的方式向主题写入数据再供消费者消费的话，无疑非常的不方便。但如果系统比较简单，应用场景比较单一，从简化系统的角度考虑，在满足应用需求的情况下可能只使用一个比较好。
   • Kafka 是一个非常通用的系统。你可以有许多生产者和很多的消费者共享多个主题Topics。
   • Flume是一个专用工具被设计为旨在往HDFS,HBase发送数据。它对HDFS有特殊的优化，并且集成了Hadoop的安全特性。如果数据被多个系统消费的话，使用kafka；如果数据被设计给Hadoop使用，使用Flume。
2. 如果Flume直接对接实时计算框架，当数据采集速度大于数据处理速度，很容易发生数据堆积或者数据丢失，而kafka可以当做一个消息缓存队列，从广义上理解，把它当做一个数据库，可以存放一段时间的数据。而且考虑到现有系统业务发展，为了后面的灵活扩展，在先用系统设计时留有一定的扩展性感觉更重要。
3. Kafka属于中间件，一个明显的优势就是使各层解耦，使得出错时不会干扰其他组件。因此数据从数据源到flume再到Kafka时，数据一方面可以同步到HDFS做离线计算，另一方面可以做实时计算，可实现数据多分发。
4. Flume可以使用拦截器实时处理数据。这些对数据屏蔽或者过量是很有用的。Kafka需要外部的流处理系统才能做到。
5. Kafka和Flume都是可靠的系统,通过适当的配置能保证零数据丢失。然而，Flume不支持副本事件。于是，如果Flume代理的一个节点奔溃了，即使使用了可靠的文件管道方式，你也将丢失这些事件直到你恢复这些磁盘。如果你需要一个高可靠行的管道，那么使用Kafka是个更好的选择。

8.Elasticsearch

Elasticsearch是一个实时分布式搜索和分析引擎。它用于全文搜索、结构化搜索、分析 。

• 全文检索：将非结构化数据中的一部分信息提取出来,重新组织,使其变得有一定结构,然后对此有一定结构的数据进行搜索,从而达到搜索相对较快的目的。
• 结构化检索：我想搜索商品分类为日化用品的商品都有哪些，select * from products where category_id=‘日化用品’
• 数据分析：电商网站，最近7天牙膏这种商品销量排名前10的商家有哪些；新闻网站，最近1个月访问量排名前3的新闻版块是哪些

Elasticsearch，基于lucene，隐藏复杂性，提供简单易用的restful api接口、java api接口（还有其他语言的api接口）。

8.1 全文检索和Lucene

1. 全文检索，倒排索引。全文检索是指计算机索引程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，检索程序就根据事先建立的索引进行查找，并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。全文搜索搜索引擎数据库中的数据。
2. lucene，就是一个jar包，里面包含了封装好的各种建立倒排索引，以及进行搜索的代码，包括各种算法。我们就用java开发的时候，引入lucene jar，然后基于lucene的api进行去进行开发就可以了。

8.2 Elasticsearch的特点

1. 可以作为一个大型分布式集群（数百台服务器）技术，处理PB级数据，服务大公司；也可以运行在单机上，服务小公司。
2. Elasticsearch不是什么新技术，主要是将全文检索、数据分析以及分布式技术，合并在了一起，才形成了独一无二的ES；lucene（全文检索），商用的数据分析软件（也是有的），分布式数据库（mycat）。
3. 对用户而言，是开箱即用的，非常简单，作为中小型的应用，直接3分钟部署一下ES，就可以作为生产环境的系统来使用了，数据量不大，操作不是太复杂。
4. 数据库的功能面对很多领域是不够用的（事务，还有各种联机事务型的操作）；特殊的功能，比如全文检索，同义词处理，相关度排名，复杂数据分析，海量数据的近实时处理；Elasticsearch作为传统数据库的一个补充，提供了数据库所不能提供的很多功能。

关系型数据库（比如Orcle）	非关系型数据库（Elasticsearch）
数据库Database	索引Index
表Table	类型Type
数据行Row	文档Document
数据列Column	字段Field
约束 Schema	映射Mapping

Elasticsearch与Solr区别：https://blog.csdn.net/weixin_42526352/article/details/103606175

9.Oozie

一个基于工作流引擎的开源框架，由Cloudera公司贡献给Apache，提供对Hadoop Mapreduce、Pig Jobs的任务调度与协调。Oozie需要部署到Java Servlet容器中运行。

9.1 Oozie在集群中扮演的角色

定时调度任务，多任务可以按照执行的逻辑顺序调度。

9.2 Oozie的功能模块

1. Workflow，顺序执行流程节点，支持fork（分支多个节点），join（合并多个节点为一个）。
2. Coordinator，定时触发workflow。
3. Bundle Job，绑定多个Coordinator。

9.3 Oozie的节点

1. 控制流节点（Control Flow Nodes），控制流节点一般都是定义在工作流开始或者结束的位置，比如start,end,kill等。以及提供工作流的执行路径机制，如decision,fork,join等。
2. 动作节点（Action Nodes），就是执行具体任务动作的节点。

9.4 常见的调度框架

9.4.1 crontab定时器

linux自带定时器，没有web界面 ，不利于监控任务和调度任务,在工作量比较小的情况下,建议使用linux的crontab定时命令。
具体使用，见我的另外一篇博文在linux环境的python定时任务

9.4.2 Azkaban调度

开源项目，key/value配置对，操作简单，带web界面。

9.4.3 Oozie调度

apache项目，xml配置文件，操作稍微有难度，带web查看界面，常用于hadoop相关任务的调度。

9.5 为什么需要Oozie

1. 对于较为复杂的Hadoop作业系统来说,单纯的依靠shell脚本方式,手工方式调度是的流程更加难以控制。
2. 复杂系统的算法需要很多不同的作业(如mr,Java程序,shell脚本,hivesql,sqoop,spark等)按照特定的顺序,串行并行,不同时间,不同条件进行执行,就需要oozie这样的调度系统做支撑,将复杂问题简单化.

9.6 Oozie实际作用

1. 将hadoop生态系统中常见的mr任务启动,hdfs操作,shell调度,hive操作等通过统一的方式进行连贯调度。
2. 将复杂的依赖关系,时间触发,事件触发使用xml语言进行表达,提高开发效率。
3. 一组任务使用一个DAG(有向无环图)来表示,图形化的表达,流程逻辑更加清晰。
4. 支持很多种任务调度,能完成大部分的hadoop任务处理。
5. 程序定义支持EL常量和函数,写过shell脚本的小伙伴使用根本没难度。