数据氧气第40篇原创文章，整个系统不可用对网络要求高，阅读5 min
最近2020东京奥运会如火如荼的开展，节点之间需要不断的传输数据免费版的Kettle缺乏必要的数据异常处理(简单抛出)和监控运维等管理功能服务。实际测试中经常出现一些莫名异常,调试比较困难。bulk load数据无法查找出错误明细。内存占用。并发模型中各组件以管道(hop)相连,后续某个组件处理速度较慢时,容易成为性能瓶颈.支持简单的数据分析工作,如sort/group by/aggregator，我国的奥运健儿在赛场上奋力拼搏，不适用数据量较的场景。对于数据分析工作来说,需注意Kettle目前不具备时间窗口、中间状态存储、延迟消息策略等实时计算引擎特性对于简单的ETL任务Kettle略显笨重,8.2版本安装包1.1G小.手动编译的9.2版本1.7GKettle资源库用于保存自定义的转换任务等元数据信息，给我们留下了深刻印象。突发奇想，支持本地、数据库方式。测试中使用数据库方式时操作卡顿频繁。对最近几年新出现存储引擎的支持不足(相对datax来说). 如: elasticsearch/druid/kudu...源码统计四、测试4.1 测试环境kettle版本: 8.2.0.0测试环境:master 10.128.2.64slave1 10.128.2.86slave2 10.128.2.54JVM: -Xms1024m -Xmx2048mkettle集群监控web页面:http://10.128.2.64:8090/kettle/status/4.2 Mysql连接查询场景: 集群模式,表现良好.2.139/2.54 mysql数据库: SVR_N_ACTION/SVR_U_APPLICATION关联查询查询2.54 SVR_U_ACTION表(500w记录)查询1.139 SVR_U_APPLICATION(1224记录)action.app_id=application.id关联字段选择: action_id, action_name, application_name过滤action_name字段输出到log日志查询结果同步到2.54 SVR_U_ACTION拓扑图:集群运行监控:4.3 kafka场景: 本地, kafka消费、生产数据结构:4.4 group_by-1000w场景: 集群模式, 1000w记录SQL:拓扑:运行监控:4.5 group-by-5000w4.6 group-by-all-5000w去除where过滤条件,全量group by4.7 group-by-all-2.8亿五、总结Kettle历经近二十年发展,架构设计(插件体系)、交互设计比较完善，从可视化角度搞点好玩的东西出来。用动态效果来可视化展现历届奥运会中各的金牌的名次情况。
那么你估计会认为这是用了什么复杂的编程搞定的，若从头设计有较好的参考性。作为ETL工具来说功能比较丰富, 甚至略显繁杂,有一定的学成本。支持分布式集群,目前开源的datax不支持.使用感受,作为研发人员来说不太惯. 比如一些简单的逻辑处理,通过图形界面操作比较麻烦,甚至说有点折磨!数据同步、失败处理、任务调度、管理和监控、拓扑设计与调试对于实时etl场景来说,无论kettle还是datax支持都不够, 实际场景中很可能需要类似flume这种第三方工具支持.基本满足BPI业务需求六、个人意见综合投入成本,项目周期等因素,建议前期以Kettle作为ETL基础.可能的话BPI先行.架构实现上, web端ETL拓扑数据模型单独设计,与底层ETL引擎进行隔离.参考:喜欢，其实不是，在看，用了可视化软件POWER BI中的一个组件搞定。Animated Bar Chart Race。
1-需要从应用商店中导入，默认的效果中是没有的。
2-将源数据导入到POWER BI中。
3-将相关字段拉入对应的区域，可以得到此图。
4-然后需要对应的格式进行调整，位置如下图。
5-对应参数值的可以简单设置下，然后就可以了。
topN：条形图中的条目数量
duration：动画延迟时间，值越动画播放越慢
autoPlay：设置是否自动播放
fontFamily：设置条目的字体
fontSize：设置条目的字号
hideGrid：设置是否因此图例
hideNumber：设置是否因此数据值
hidePeriod：设置是否显示日期
periodSize：设置日期的字号
——END ——
免责声明：文中图片均来源于网络，如有版权问题请联系我们进行删除！
