Flink(1)——基于flink sql的流计算平台设计

November 13, 2018
作者:星爷
出处:http://www.readingnotes.site/posts/Flink(1)-%E5%9F%BA%E4%BA%8EFlink-SQL%E7%9A%84%E6%B5%81%E8%AE%A1%E7%AE%97%E5%B9%B3%E5%8F%B0%E8%AE%BE%E8%AE%A1.html
声明:转载请注明作者及出处。

本文转自个人微信公众号,原文链接

上篇

使用场景

先说流计算平台应用场景。在我们的业务中,实时平台核心包括几个部分:一是大促看板,比如刚过去的双11,供领导层和运营查看决策使用;二是实时风控的技术支持;三是实时数据接入、清洗、入库功能,为下游提供实时、准确的数据。

为了支持这些业务需求,并最小化技术人员的介入,设计并实现了实时计算平台。

设计

首先,是数据源部分。数据接入包括埋点日志、数据库数据、API上报数据等,埋点数据、API上报的数据等都接入Kafka,平台支持的数据源包括Kafka、MySQL、Redis、Elasticsearch,根据使用经验,Kafka和MySQL 已经基本覆盖我们的业务需求。我们将数据源统一在平台进行管理,使用者不需要关注数据源的具体来源信息。

其次,是Job。Job由数据源和具体的task组成。数据接入后,需要进行运算,要定义算子和工作流。算子就是我们要对数据流进行的操作,同时,对数据可能需要经过中间很多层处理,所以,还需要定义工作流。算子我们采用Flink SQL,且目前仅支持Flink SQL。Flink 使用 Apache calcite 解析SQL,它支持 ANSI SQL,这对于BI和分析师,都是比较容易使用的。在当前情况下,Flink SQL 对有些语法还不支持,对我们来说,这不算大问题,一是先有语法已经覆盖我们的绝大多数需求,如果我们要等它完美支持后再来使用,反而是得不偿失,正所谓Done is better than perfect.;其次是对于刚需语法,我们可以根据Flink 提供的UDF 自行开发,比如函数 LAST_VALUE()。

部署

Flink 集群支持Standalone、Yarn、Mesos、K8S等多种模式,我们目前的版本采用Standalone cluster模式,现在流行的在生产环境使用较多的是Yarn模式,下表是Standalone 模式和 Yarn 模式的优缺点对比。我们之前采用Standalone 模式的两个原因,一是为了快速实现;二是尽量减少外部依赖特别是对 Yarn 集群的依赖(Yarn 集群主要是离线计算和BI、分析师日常取数使用,尽量减少对他们的影响。如果要采用Yarn 集群模式,我也推荐单独搭建Yarn 集群)。但我还是更推荐Yarn 模式,Job 级别的资源隔离以及失败自动重启会更加重要点。

  Standalone cluster Yarn cluster
优点 1. 外部依赖少
2. 添加、减少task manager方便,可以快速实现
3. 方便调试和查看日志
1. Job 级别的资源隔离
2. Node 失败自动恢复
缺点 1. 需要额外部署ZK
2. 不支持Job 级别的资源隔离
需要依赖外部系统 Yarn

资源

不同的任务数据量不同,计算量不同,需要的资源也不同,我们支持对不同的Job 配置不同的 parallelism,从而满足不同的资源需求,该值还只是一个经验值,暂时无法做到自适应配置。

使用

Flink 将 savepoint 保存到HDFS,在使用过程中,我们发现HDFS上的savepoint 数量巨大,但一段时间前的savepoint是没有用处的,所以,我们对savepoint 进行了生命周期管理,自动删除过期的savepoint。

另外,在业务方使用过程中,也要做Job的生命周期管理,比如大促看板,否则,实时计算平台的资源就是一个黑洞。

其它

系统还涉及用户管理、权限管理、监控告警等部分,暂不做详细介绍。

扫描下方二维码关注我。

wx