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

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

接上篇。

使用场景

先说流计算平台应用场景。在我们的业务中,实时平台核心包括几个部分:一是大促看板,比如刚过去的双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 级别的资源隔离以及失败自动重启会更加重要点。

资源

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

使用

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

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

其它

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

扫描下方二维码关注我。

你可能感兴趣的:(2018-11-13-Flink(1)——基于flink sql的流计算平台设计)