共计 6372 个字符，预计需要花费 16 分钟才能阅读完成。
摘要：
本文由以数据之名分享，正所谓“问君能有几多愁，恰似一江春水向东流 ”。
人不知; 鬼不觉中，“以数据之名”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)批改 <span style=”color:red;”>max_connect_errors</span> 的值：
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 知识库问答系列之六十而耳顺
- 3.1、表输出慢，思考是否存在查问 badsql，如索引未失效；
-
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（此处有省略门路信息）
- 或 <span style=”color:orangered”>$..extendList[*].itemCode</span>（此处有省略门路信息）
- 或 $.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 构造为示例，做具体步骤解析剖析，供参考。
<Session_header Code="xmltest">
<InfoSession>
<InfoSessionData User="Username1">
<Data>Data1</Data>
</InfoSessionData>
</InfoSession>
<InfoSession>
<InfoSessionData User="Username2">
<Data>Data2</Data>
</InfoSessionData>
</InfoSession>
<InfoSession>
<InfoSessionData User="Username3">
<Data>Data3</Data>
</InfoSessionData>
</InfoSession>
<Session>
<SessionData>
<Parameter>
<User>Username1</User>
<Password>password123</Password>
</Parameter>
<OutputData>
<Step>
<Error_Message>Please have transaction ID and related information ready. Timestamp : 20070731 01:50:06 Session : 0201</Error_Message>
</Step>
</OutputData>
</SessionData>
<SessionData>
<Parameter>
<User>Username2</User>
<Password>password345</Password>
</Parameter>
<OutputData>
<Step>
<Error_Message>error occurred Timestamp : 20070731 01:53:25</Error_Message>
</Step>
</OutputData>
</SessionData>
<SessionData>
<Parameter>
<User>Username3</User>
<Password>password567</Password>
</Parameter>
<OutputData>
<Step>
<Error_Message>Transaction Id :361163328</Error_Message>
<Status>Processed according to contract/plan provisions</Status>
</Step>
</OutputData>
</SessionData>
</Session>
</Session_header>- 1、指定 xml 数据流起源，是文件？还是数据流字段？还是接口返回报文？
- 2、查看 xml 数据标签构造，确定循环目录 Session_header/Session/SessionData;
-
3、明确待解析字段信息，是标签属性值？还是标签值？
- Code：为 Session_header 的标签属性值，而循环读取门路为 Session_header/Session/SessionData，所以须要往上找两层../../，加上此处获取的是标签属性值，故配置为 @Code。所以整体 Code 字段的 XML 门路为“../../@Code”
- User：此处 xml 构造第 5 层的 <User> 的标签值，而循环读取门路为 Session_header/Session/SessionData，所以须要往下找两层，此处采纳具体门路 Parameter/User。Password、Status、Error_Message 标签值的 XML 门路配置同上逻辑
- Data：此处 xml 构造第 4 层的 <Data> 的标签值，而循环读取门路为 Session_header/Session/SessionData，所以须要先往上找两层../../，再往下找两层 InfoSession/InfoSessionData。而这里的 Data 标签值要依据下层 InfoSessionData 的标签属性 User 对应值，与 Session_header/Session/SessionData/Parameter/User 的标签值一一匹配上。这里的 InfoSessionData 门路要调整为 InfoSessionData[@User=@_User-]，最初再取第 4 层的 <Data> 的标签值，最初 Data 对应的标签值的 XML 门路配置为../../InfoSession/InfoSessionData[@User=@_User-]/Data
- Code：为 Session_header 的标签属性值，而循环读取门路为 Session_header/Session/SessionData，所以须要往上找两层../../，加上此处获取的是标签属性值，故配置为 @Code。所以整体 Code 字段的 XML 门路为“../../@Code”
- 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 构建微服务
虽小编一己之力强劲，但读者众星之光璀璨。小编敞开心扉之门，还望倾囊赐教原创之文，期待之心满于襟怀，感谢之情溢于言表。一句话，欢送分割小编投稿您的原创文章！
