Kettle知识库问答系列之八零年代

摘要：

本文由以数据之名分享，正所谓“问君能有几多愁，恰似一江春水向东流”。
不知不觉中，“以数据之名”Kettle解忧消愁系列专题已更新了五篇知识库文章“三十而立、四十不惑、五十而耳知天命、六十而耳顺、七十古稀”，叙述了使用Kettle作为ETL开发的常见组件使用说明、业务场景实现逻辑、异常分析及组件性能优化相关内容。
今天，我们跟着小编的节奏，继续探讨第六篇Kettle知识库问答系列之八零年代，做到理念和实践的生动统一。

一.异常分析篇

第073问：

Host '127.0.0.1' is blocked 
because of many connection errors; 
unblock with 'mysqladmin flush-hosts'Connection
closed by foreign host？

第073答：

由异常提示可以看出原因：同一个ip在短时间内产生太多（超过mysql数据库max_connect_errors的最大值）中断的数据库连接而导致的阻塞。

首先，我们先查询数据库服务端的参数max_connect_errors配置
```
show variables like 'max_connect_errors';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| max_connect_errors | 10     |
+--------------------+-------+
```
max_connect_errors是一个MySQL中与安全有关的计数器值，它负责阻止过多尝试失败的客户端以防止暴力破解密码的情况。
max_connect_errors的值与性能并无太大关系，默认是10。意味着如果某一客户端尝试连接此MySQL服务器，但是失败（如密码错误等等）10次，则MySQL会无条件强制阻止此客户端连接。
如果希望重置此计数器的值，则必须重启MySQL服务器或者执行mysql> flush hosts; 命令。当这一客户端成功连接一次MySQL服务器后，针对此客户端的max_connect_errors会清零。如果max_connect_errors设置过小，则网页可能提示无法连接数据库服务器。
解决方法1：修改max_connect_errors的值

(1)进入Mysql数据库查看max_connect_errors：
```
show variables like '%max_connect_errors%';
```
(2)修改max_connect_errors的值：
```
set global max_connect_errors = 80; 
```
(3)查看是否修改成功
```
show variables like '%max_connect_errors%';
```
- 解决方法2：使用mysqladmin flush-hosts 命令清理一下hosts文件
  。
  (1)在查找到的目录下使用命令修改：
```
> mysqladmin -u xxx -p flush-hosts
```
  或者
```
> flush hosts;
```
- 解决方法3：重启mysqld。
  也可以在重启之前，在配置文件中将该参数调大。
```
> vi /etc/my.cnf
max_connect_errors = 80
```

第074问：

Kettle发送邮件附件中文乱码，如何解决呢？

第074答：

修改spoon启动脚本配置，在set OPT=%OPT% %PENTAHO_DI_JAVA_OPTIONS% 这一行末尾，添加如下配置：

"-Dmail.mime.encodefilename=true" 
"-Dmail.mime.charset=utf-8" 
"-Dfile.encoding=utf-8"

第075问：

Kettle ES Bulk Insert批量数据写入，Kibana查询有延迟？

第075答：

首先，很可能短时间写入数据量和并发量过大，es的master处理不过来了，segment合并是一个很是耗时的操作。
其次也可能有以下几点原因：
- 1、分片数过多，建议单节点的分片数不要超过1000个；shard越少，写入开销越小；
- 2、经过写入数据自动建立索引最容易出现这种状况；
- 3、大批量写入数据refresh时间间隔过短；
- 4、索引的字段数量太多（几十上百个）

二.性能分析篇

第076问：

你理解count(*)、count(1)、count(column)的区别嘛？

第076答：

我们可以从以下两个角度来分别看待：

执行效果上：
- 1、count(*)包括了所有的列，相当于行数，在统计结果的时候，不会忽略列值为NULL
- 2、count(1)包括了忽略所有列，用1代表代码行，在统计结果的时候，不会忽略列值为NULL
- 3、count(column)只包括列名那一列，在统计结果的时候，会忽略列值为空（这里的空不是只空字符串或者0，而是表示null）的计数，即某个字段值为NULL时，不统计。
执行效率上：
- 1、列名为主键，count(column)会比count(1)快
- 2、列名不为主键，count(1)会比count(column)快
- 3、如果表多个列并且没有主键，则 count（1）的执行效率优于 count（*）
- 4、如果有主键，则 select count（主键）的执行效率是最优的
- 5、如果表只有一个字段，则 select count（*）最优。

第077问：

怎么我的Kettle转换或者作业运行耗时那么长？

第077答：

无论使用什么组件，首先要看任务运行表象：

1、任务执行慢？（思考为什么慢，怎么找出那个环节慢）
2、找出哪个环节接慢？
- 2.1、看各环节执行耗时，做初步观察；
- 2.2、启动探测，观察metrics步骤度量信息。
3、找出了那个环节耗时最长，思考什么原因可能导致慢逻辑？
- 3.1、表输入慢，思考是否存在查询badsql，如索引未生效；
  Kettle知识库问答系列之六十而耳顺
- 3.2、数据库查询或数据库连接，反查操作慢，是否存在索引未生效的情况，如上一步骤数据流，数据类型和查询条件数据类型不匹配，导致badsql
- 3.3、表输出慢或插入更新慢,参考我的文章：
  
  Kettle知识库问答系列之三十而立
  
   Kettle知识库问答系列之四十不惑
  
   Kettle知识库问答系列之六十而耳顺
4、也可能跟源数据库服务器、etl服务器、目标数据库服务器等系统资源或数据库存在性能瓶颈。
- 4.1、需要做服务器底层参数优化（如文件句柄数等）
- 4.2、数据库层面（如server实例启动分配内存等）
- 4.3、找DBA配合做性能分析
5、抑或是组件使用问题，再或者是组件本身存在性能瓶颈

三.实战开发篇

第078问：

如何一次性掌握json解析真谛？

第078答：

对于Json字段的解析有两种标准的处理方式：

1.使用自带的JsonInput输入组件解析
- 1.1 解析单层数据
  
  解析思路：JsonInput的使用规范是，解析单层数据，可以一次性搞定；
  这里我们直接解析第4层，itemCode的路径配置，JsonArray用key[*]获取，JsonObject用key直接获取：
  - $..extendList[*]..itemCode（此处有省略路径信息）
  - 或 $..extendList[*].itemCode（此处有省略路径信息）
  - 或 $.result.paySuiteDataList[*].extendList[*].itemCode
    
    解析结果,具体如下：
- 1.2 解析多层数据，需要分层次解析。还有一点，需要保证每层解析的元数据字段必须一致，否则JsonInput组件就会跑异常啦。
  - 这里我们需要解析第3层和第4层数据，实现数据流字段组合，先解析第3层，extendList的路径为$.result.paySuiteDataList[*].extendList，其他同层key获取路径前缀一致
  解析结果,具体如下：
  - 再在第三层extendList的路径基础上，解析第4层JsonArray数据。itemCode的路径配置为$..itemCode
  解析结果,具体如下：
2.使用Java脚本组件解析（引入FastJson或Jackson等Json序列化和反序列化包），此处以FastJson为例
- 1、import 导入FastJson包；
- 2、Json反序列化成JsonArray或JsonObject，依据Json体层次结构的对象属性来具体调用JSONObject.parseObject或JSONArray.parseArray等API方法
- 3、获取当层次key字段数据getString或getObject等API方法

第079问：

怎么玩转xml解析？

第079答：

针对于XML文件或字段串解析，有以下几个关键步骤：
以如下xml结构为示例，做具体步骤解析分析，供参考。

  
   
      
         Data1
      
   

   
      
         Data2
      
   

   
      
         Data3
      
   

   
      
         
            Username1
            password123
         

         
            
               Please have transaction ID and related information ready. Timestamp : 20070731 01:50:06 Session : 0201
            
         
      

      
         
            Username2
            password345
         

         
            
               error occurred Timestamp : 20070731 01:53:25
            
         
      

      
         
            Username3
            password567
         

         
            
               Transaction Id :361163328
               Processed according to contract/plan provisions

1、指定xml数据流来源，是文件？还是数据流字段？还是接口返回报文？
2、查看xml数据标签结构，确定循环目录Session_header/Session/SessionData;
3、明确待解析字段信息，是标签属性值？还是标签值？
- Code：为Session_header的标签属性值，而循环读取路径为Session_header/Session/SessionData，所以需要往上找两层../../，加上此处获取的是标签属性值，故配置为@Code。所以整体Code字段的XML路径为“../../@Code”
- User：此处xml结构第5层的的标签值，而循环读取路径为Session_header/Session/SessionData，所以需要往下找两层，此处采用具体路径Parameter/User。Password、Status、Error_Message标签值的XML路径配置同上逻辑
- Data：此处xml结构第4层的的标签值，而循环读取路径为Session_header/Session/SessionData，所以需要先往上找两层../../，再往下找两层InfoSession/InfoSessionData。而这里的Data标签值要根据上层InfoSessionData的标签属性User对应值，与Session_header/Session/SessionData/Parameter/User的标签值一一匹配上。这里的InfoSessionData路径要调整为InfoSessionData[@User=@_User-]，最后再取第4层的的标签值，最后Data对应的标签值的XML路径配置为../../InfoSession/InfoSessionData[@User=@_User-]/Data
4、最后我们来具体看下，示例运行输出结果，来检查配置逻辑是否正确。

第080问：

我有200+表，需要做全量数据同步，Kettle 有没有通用的解决方案？

第080答：

如果你的ETL逻辑没有特别个性化，理论上是可以搞一套通用配置，要什么字段取什么字段，目标不配置映射关系。就可以让数据流和目标数据库按照顺序自动匹配。

1个入口程序Job A，负责调用查询通用配置表查询转换 Trans A，和循环调用执行Job B；
1个执行Job B ，负责调用初始化通用参数转换Trans B，和调用核心执行转换Trans C；
1个转换Trans A负责读取配置表信息，复制到结果集；
1个转换Trans B负责从结果集读取配置行信息，赋值给设置变量；
1个转换Trans C负责执行核心ETL操作，表输入（根据配置源数据库表参数信息，获取动态SQL
```
${S_SQL}
```
或动态拼接SQL
```
select ${s_column} from ${s_tb} where ${s_where}）
```
+个性化处理（非必须）+表输出（动态目标表【${t_tb}】）。

四.KETTLE专题回顾篇

Kettle插件开发之Splunk篇

 Kettle插件开发之Elasticsearch篇

 Kettle插件开发之KafkaConsumerAssignPartition篇

 Kettle插件开发之KafkaProducer篇

 Kettle插件开发之KafkaConsumer篇

 Kettle插件开发之KafkaConsumerAssignPartition篇

 Kettle插件开发之MQToSQL篇

 Kettle插件开发之Redis篇

 Kettle快速构建基础数据仓库平台

 Kettle知识库问答系列之三十而立

 Kettle知识库问答系列之四十不惑

 Kettle知识库问答系列之五十而知天命

 Kettle知识库问答系列之六十而耳顺

 Kettle知识库问答系列之七十古稀

 Kettle实战系列之Carte集群应用

 Kettle实战系列之动态邮件

 Kettle实战系列之基于Carte构建微服务

虽小编一己之力微弱，但读者众星之光璀璨。小编敞开心扉之门，还望倾囊赐教原创之文，期待之心满于胸怀，感激之情溢于言表。一句话，欢迎联系小编投稿您的原创文章！