Flink-流平台调研

Flink-流平台调研

Flink系列文章

• 更多Flink系列文章请点击Flink系列文章

• 更多大数据文章请点击大数据好文推荐

1 flinkStreamSQL

1 简介

flinkStreamSQL是袋鼠云大数据团队基于开源的flink，对其实时sql进行了扩展；主要实现了流与维表的join，支持原生flink SQL所有的语法。

优点是可以纯SQL的方式提交应用运行。

缺点是目前版本只支持到Flink 1.8，不支持1.9以后的Blink特性，很多函数都无法使用需要自己写UDF。

提了个issue，回复说4月底才能支持Flink1.10，我们等不起。。。

更多详情可参考：

• Git-flinkStreamSQL

1.2 flinkStreamSQL解决的问题

原生FlinkSQL没有实现对数据来源、数据目的地的SQL化，必须要写代码。

这个就很坑了，一般来说，SQL面向数据分析人员，如果要写代码无疑提高了门槛。flinkStreamSQL里面将这一切都用SQL解决。袋鼠云声称的数据计算采用SQL的优势：

• 声明式
  用户只需要表达我想要什么，至于怎么计算那是系统的事情，用户不用关心。
• 自动调优
  查询优化器可以为用户的 SQL 生成最有的执行计划。用户不需要了解它，就能自动享受优化器带来的性能提升。
• 易于理解和使用
  很多不同行业不同领域的人都懂 SQL，SQL 的学习门槛很低，用 SQL 作为跨团队的开发语言可以很大地提高效率。
• 稳定
  SQL 是一个拥有几十年历史的语言，是一个非常稳定的语言，很少有变动。所以当我们升级引擎的版本时，甚至替换成另一个引擎，都可以做到兼容地、平滑地升级。

此外，FlinkSQl还支持了流与流、流与维表Join:

1.3 flinkStreamSQL基本原理

这里摘自Flink-SQL的扩展实现

• 将创建源表的sql语句转换为flink的operator
  目前flinkStreamSQL只支持Kafka数据源，已经满足我们要求。其实我们在flinkStreamSQL中写的建表语句就是映射到Flink Table类，各个属性就是Kafka数据源的属性，注册表时调用以下Flink代码：

  StreamTableEnvironment.registerTable(tableName, table);
  

• 将创建的输出表sql语句转换为flink的operator

  • 解析出create table语句中的连接信息和表信息，放入自定义类
  • 继承RichOutputFormat类，根据数据源来分别实现writeRecord方法将数据写入外部数据源

• 将UDF语句转换为flink的operator
  Flink原生对UDF提供两种类型的实现方式：

  • 继承ScalarFunction
  • 继承TableFunction

  flinkStreamSQL将用户提供的实现了上述接口class所在的jar添加到URLClassLoader，并加载指定的class ，然后调用TableEnvironment.registerFunction(funcName, udfFunc)即完成了UDF注册。

• 维表功能的实现
  Flink原生SQL不支持注册表和外部数据源Join，但我们常常需要用Flink做数据预处理时就join维表补足表的维度信息字段。

  flinkStreamSQL使用定时更新缓存外部被Join数据源、阿里贡献的异步获取外部数据源数据的RichAsyncFunction、解决了维表不断变化、IO吞吐问题。

  另一方面，使用Flink项目依赖的calcite做SQL解析出的AST，迭代搜索出维度表，区分出维表和非维表即可（如果有维表就把这个join的维表的语句单独拆来，用Flink的TableAPI和StreamAPi 生成新DataStream，在把这个DataStream与其他的表再做join即可）。
  
  
  

2 Oppo流平台

参考：

• OPPO数据中台之基石：基于Flink SQL构建实时数仓
• OPPO 基于 Flink 构建实时计算平台的思路、演进与优化
  一些流平台构建心路历程、Flink源码阅读和优化经验

2.1 背景

2.1.1 数据规模不断增加

Oppo在手机上做了基于Android的ColorOS，日活2亿，构建了不少应用，每天产生海量数据。

2.1.2 Oppo数据中台

这里还可以看看Oppo的数据中台：

这里的全域数据是指公司业务数据全都打通后形成的统一数据自产。

2.1.3 离线数仓

以前Oppo是离线数仓：

Presto那条线是可直接通过Presto即席查询和提数。

2.1.4 实时数仓

需求背景：

主要是有很多实时也无需求提出。比如实时推送商圈广告，就需要实时对用户打商圈标，此时t+1肯定就不行。所以需要实时打标

在数据平台这边，因为离线数仓大多是t+1的，所以调度平台、标签计算和导入大多集中在凌晨，资源竞争严重，集群压力大，耗时长。而数据质量监控也是t+1，必须在数据产出后进行事后校验，无法及时发现问题，增加起夜率。

离线迁移到实时，必须注意平滑，即对用户来说使用习惯和抽象不能有根本改变。

• 流场景也支持SQL和UDF
• 流场景执行引擎需要替换为Flink，中转数据存储演变为Kafka，可方便同步到其他数据源进行特定场景查询使用。

实时数仓架构如下：

• 基本流程不变，但是关键技术演进为了Flink，串起了整个数据流转过程。

使用FlinkSql原因如下：

• 其中ANSI SQL含义是支持ANSI SQL标准。
• 数据类型丰富，内置函数在Flink1.9合并了阿里Blink后更是齐全
• 支持很多常见数据源来做Source Sink，还可自定义，便于扩展
• 流批统一，同一个SQL即可
• 支持事件时间，且可支持各种窗口计算，便于实时统计
• 容错性强，基于Checkpoint、状态等机制可实现端到端Exactly Once

2.1.5 FlinkSql存在的问题

虽然FlinkSQL可以用SQL定义输入输出表，但仍然需要编码，这对于ETL同事来说并不友好，所以最好是有个界面，能直接用SQL定义、提交流作业。但FlinkSQL并未提供该功能，只能自己实现。

OPPO的流式SQL凭条界面构想如下：

可以看到，该界面就如同Navicat、HUE等。

Uber开源了一个AthenaX的SQL管理器：

• Job
  是SQL作业的抽象，封装SQL及作业资源信息。

• Job Store
  托管所有Job。

  定义

3 小米流平台

• 【实践案例分享】小米流式平台架构演进与实践
  介绍小米流平台从Storm->Spark Streaming->Flink的技术演进，以及基于 Flink 的实时数仓的介绍，还有对SQL解析
  作恶管理、Flink JobGraph生成等细节。但问题是这一套都是自己实现，并未开源，所以开发成本很高。

4 网易实时计算平台

• 覆盖电商、推荐、ETL、风控等多场景，网易的实时计算平台做了啥？
  介绍了网易流平台Sloth，都是自己实现的，功能做的很完备。然后介绍了内部应用状况，如实时数仓、推荐、数据分析、搜索推荐等。

5 58同城实时计算平台

• 58同城实时计算平台架构实践
  介绍了其实时计算平台Wstream，其实时平台演进路线如下
  
  可以看到也是跟小米一样走了Storm（吞吐能力不够）->SparkStreaming（计算延迟）->Flink（支持状态管理、时间窗口、Exactly Once语义等，且拥有高吞吐低延迟的架构设计以及高可用的稳定性，同时拥有实时计算场景一系列特性以及支持实时流式Sql）这样的路线。

主要业务分为 实时ETL、实时数仓（实时数据数据计算、模型加工、存储、业务指标实时计算服务于运营人员）、实时监控（包括系统行为如业务指标和用户行为如金融风控）、实时分析（如实时标签、特征平台、实时推荐等）

流平台Wstream架构如下

FlinkSQL这块儿扩展如下：

• 支持自定义DDL语法（包括源表,输出表,维表）
• 支持自定义UDF/UDTF/UDAF语法
• 实现了流与维表的join,双流join

用户提交任务可使用Sql client的cli方式以及Wstream界面的sql任务编辑器，同时对用户提供了向导化配置方式，解决用户定义table需要了解复杂的参数设置（比如），用户只需关心业务逻辑处理，像开发离线Hive一样使用sql开发实时任务，比如以下Flink SQL DDL配置：

58流平台支持如下：

6 腾讯基于 Flink 的实时流计算平台

• 腾讯基于 Flink 的实时流计算平台演进之路

腾讯选择用 Flink 作为新一代的实时流计算引擎，并对社区版的 Flink 进行了深度的优化，在此之上构建了一个集开发、测试、部署和运维于一体的一站式可视化实时计算平台—— Oceanus

腾讯云的流平台技术演进路线，也是Storm（没有内置状态的支持，没有提供完备的容错能力，没有内置的窗口 API，core API 无法提供 Exactly-once 的语义保证等）->Flink，但没有SparkStreaming。可以看到，他们把流计算平台不仅应用与公司内部，还上云给客户使用。

Oceanus技术架构如下

• Flink是从Flink社区拉出来的分支
• Oceanus 支持画布（它提供了很多功能细分的可插拔的便捷函数来简化常见的事件解析与提取的复杂度）、SQL 以及 Jar 三种形式构建应用。为了方便业务方降低整体成本，还提供了配置、测试、部署等完整配套的功能，在平台之上提供了一些领域特定的场景化服务比如 ETL、监控、推荐广告等。
• 还有大量对Flink原生功能优化，可以做参考。
• 该文档中罗列的很多细节是Standalone模式。

5 网易严选-基于 Flink 的实时数仓实践

• 基于 Flink 的严选实时数仓实践

5.1 背景

• 长链路且快速变化的业务
  严选作为一个 ODM 电商，整个业务链度从商品采购、生产、仓库、到销售这个阶段可以在主站 APP 上购买或者分厂购买，然后通过商户配送到达消费者。链度是非常长的，这也决定数据的数据域非常广；

  严选作为一个成长的电商，会有很多新的业务出现。

• 越来越多的实时数据需求
  目前需要更多的实时数据来做业务决策，需要依据销售情况做一个资源位的调整；

  同时有些活动也需要实时数据来增强与用户的互动。

  如果数据有实时和离线两种方案，优先考虑实时的，如果实时实现不了再考虑离线的方式。

• 越来越高的数据质量要求
  因为数据会直接影响业务决策，影响线上运营活动效果，因此对数据质量的要求越来越高。

针对这样的项目背景提出了实时数仓的三个设计目标：

• 是灵活可扩展
• 开发效率高
• 数据质量要求高

5.2 架构

5.3 实时数仓

详细讲了实时数仓分层、主题域

• ODS 层和 DWD 层
  都是用Kafka存储的一些实时数据，选择的是 Kafka 进行存储，
• DWD层
  会关联一些历史明细数据，会将其放到 Redis 里面。
• DIM 层
  主要做一些高并发维度的查询关联，一般将其存放在 HBase 里面。
• DM数据集市层
  需要综合考虑对于数据落地的要求以及具体的查询引擎来选择不同的存储方式：
  • 对于常见的指标汇总模型直接放在 MySQL 里面
  • 维度比较多的、写入更新比较大的模型会放在 HBase 里面
  • 还有明细数据需要做一些多维分析或者关联会将其存储在 Greenplum 里面
  • 还有一种是维度比较多、需要做排序、查询要求比较高的，如活动期间用户的销售列表等大列表直接存储在 Redis 里面。

5.4 对比流计算主流技术栈

5.5 对使用技术的优化

还介绍了对 Hyperloglog HBase MySQL Greenplum的一些使用优化。

5.6 数据质量

数据质量分为两个方面来介绍，离线/实时数据一致性和数据监控。

5.6.1 离线/实时数据一致性

数据一致性主要针对实时与离线的数据一致性，同一个指标实时与离线都会产出：

• 建模方法与分层基本统一，建模基于维度建模，分层也是业内通用方法；
• 业务上主题域和模型设计同步；
• 数据接入与源数据统一；
• 数据产出方面，指标定义和接口都是统一输出。

5.6.2 数据监控

5.6.3 实时数据血缘

梳理实时数仓中数据依赖关系，以及实时任务的依赖关系，从底层 ODS 到 DIM 再到 DM，以及 DM 层被哪些模型用到，将整个链度串联起来。

5.7 应用

还有业务后台仓配产能监控、物流时效监控、库存预警、商品变更通知。

5.8 未来计划

现在网易严选也是用的SQL和API，后面要搞纯SQL

参考文档

• Github-flinkStreamSQL
• 袋鼠云研发手记 | 开源·数栈-扩展FlinkSQL实现流与维表的join
• Flink-SQL的扩展实现
  本文介绍了flinkStreamSQL的基本概念和实现基本原理。
• 阿里-实时计算 Flink SQL 核心功能解密
• OPPO数据中台之基石：基于Flink SQL构建实时数仓