赞
踩
通过本文你能 get 到以下点:
先从痛点开始讲起,通常由 Maven 来构建 Flink 项目,如下图所示,一般会按照业务来划分 module。
本项目是 zhisheng 老师关于 flink 学习的项目(https://github.com/zhisheng17/flink-learning 欢迎大家关注),由于是学习项目所以按照 Flink 的知识点来划分 module,例如 sql、state、window 都是单独的 module。我们日常工作中一般会按照业务来划分 module,例如一般大数据组都会做一个数据管理平台也就是业界所说的 dmp 平台,提供各种维度 pv、uv 及其他指标的查询,互联网公司做 App的也都会有推送平台,市场推广平台,数据服务化平台,推荐平台,数据质量监控平台,做互联网广告的话还会有 dsp adx ssp 等平台,一些用户量比较大的 App 可能单独还会有一个业务数据统计的平台。以上这些平台都属于不同的业务线,且都需要用到 Flink 提供 ETL 或者实时统计的需求,如果上述所有业务统计都由一个团队来承担的话,一般会把上述所有的业务都放到一个 Flink 项目来管理,一般都会按照业务来划分 module,一个业务对应 Maven 项目的一个 module。
代码开发完发布时,也会按照 module 来打包发布。由于 Flink 安装包只提供了 flink core 相关的 jar 包,所以代码打包时,需要把其他第三方依赖全都打到 jar 包里,否则,Flink 任务发布时,就会出现 ClassNotFound。痛点来了,代码中引入的第三方依赖太多了,所以每个业务打 jar 包时,都会出现 jar 包很大的现象,准确的数字是我们六只以上业务打出来的 jar 包都在 200M 以上。Jar 包大,带来了两个问题:
基于上述两个问题,每解决一个 BUG,都需要好几分钟用来打包上传,效率太低了,这就是痛点。那怎么解决呢?
Flink 的安装目录下有个 lib 目录,当每次启动一个 Flink session 或 flink cluster 时,都会加载 lib 目录下的 jar 包,依赖这一点可以将所有业务的一些第三方公共依赖提前打包好,提前放到 lib 目录下,这样开发的业务代码打包时就可以不打这些公共依赖了,只把业务代码和相应业务代码单独的依赖打进去。这种思路就需要在 Flink 项目里单独提取出一个 common 模块,也就是上图中红色箭头标注的 module,把所有业务线公共的依赖都放到 common module 里,common 单独打包一份放置到集群中 Flink 安装目录的 lib 目录下。之后所有的业务代码打包时,就不需要再打 common 包含的内容了。
笔
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。