网上找了很多别人的解决方案, 觉得最终剩下来的就2个选择.
kettle是Pentaho开发的开源产品, 但是内部实现封闭. "开源"意思是在github上找到源代码, "封闭"的意思是想利用源码来窥探内部原理/设计思想几乎没有可能, 代码没有写的没有像常用流行框架(Spring/Mybatis)那样通俗易懂, 互联网上有关kettle的深度资料较少。要是出个性能问题或者bug或者其他乱七八糟的问题 😃 对于我们把应用部署到客户那里的产品来说, 后果是会让人很难受。
对于Hadoop, 真是个庞大的技术栈(以Hadoop为基础, 其上可以架设hive/Spark进行PB规模的数据处理, 其中hive可以做ELT/ETL), 与老大简单商量, 这是咱以后的目标, 好滴咱先整个简单的.那么就决定了自己设计个。
一、设计目标
- 新增/修改一个任务不需要重启tomcat来重新解析SQL。
- 将复杂的报表展示SQL分解为: 抽取/extract, 转换/tranform, 加载/load. 抽取中的SQL进一步分解为简单的SQL分步查询。一般是T+1模式
- 用前端可视化组件如d3, echarts代替帆软这种定制化报表, 一是美化了界面, 二是解决了浏览器兼容性问题。
- 让报表的展现字段, 可让用户选择.
二、基本组件
Springboot
可维护干活不累的WEB应用必备. 同时"查数据/导出数据入口"均用http接口暴露
可编程介入的调度框架 很多抽取任务都是在夜间业务低峰期进行, 所以用调度框架定时触发.
可编程性是因为在任务被修改时, 需要取消/并重新注册/启动该任务。
对Mybatis的Mapper做些定制
SQL是任务的核心, 改动了想生效,要么重启要么重新对Mapper解析注册, 就像往IOC容器重新注册Bean一样.
差不多就这样了, 再回到上面kettle
一启动kettle的spoon工具内存就占了1G多. 生产环境就更恐怖了.
上面是操作系统核心进程, 下面是kettle进程.
