共计 7257 个字符，预计需要花费 19 分钟才能阅读完成。
摘要：本文由好将来资深数据平台工程师毛祥溢分享，次要介绍批流交融在教育行业的实际。内容包含两局部，第一局部是好将来在做实时平台中的几点思考，第二局部次要分享教育行业中特有数据分析场景。纲要如下：
- 背景介绍
- 好将来 T-Streaming 实时平台
- K12 教育典型剖析场景
- 瞻望与布局
Tips：点击文末【链接】即可下载作者分享 PPT 并回顾原版分享视频～
1. 背景介绍
好将来介绍
好将来是一家 2003 年成立教育科技公司，旗下有品牌学而思，当初大家据说的学而思培优、学而思网校都是该品牌的衍生，2010 年公司在美国纳斯达克上市，2013 年更名为好将来。2016 年，公司的业务范围曾经笼罩负一岁到 24 岁的用户。目前公司主营业务单元有智慧教育、教育领域的开放平台、K12 教育以及海内留学等业务。
好将来数据中台全景图
上图为好将来数据中台的全景图，次要分为三层：
- 第一层是数据赋能层
- 第二层是全域数据层
- 第三层是数据开发层
首先，数据赋能层。次要是商业智能、智慧决策的利用，包含一些数据工具、数据能力以及专题剖析体系，数据工具次要包含埋点数据分析工具、AB 测试工具、大屏工具；数据能力剖析次要包含将来画像服务、将来增长服务、将来用户服务以及新校区的选址服务；专题剖析体系次要包企业经营类专题剖析等等。
其次，数据全域层。咱们冀望将全团体所有的事业部的数据进行深刻的拉通和交融，买通不同业务线、产品线的用户池，从而盘活全团体的数据。具体的伎俩是 IDMapping，将设施 id、自然人、家庭三个层级的 id 映射关系开掘进去，将不同产品上的用户数据关联起来。这样就可能造成一个大的用户池，不便咱们更好的赋能用户。
最初，数据开发层。数据开发通过一些列的平台承载了全团体所有的数据开发工程，次要包含数据集成、数据开发、数据品质、数据服务、数据治理等服务。咱们明天要分享的实时平台就是在数据开发中。
2. 好将来 T-Streaming 实时平台
实时平台构建前的诉求
实时平台在构建之初，咱们梳理了四个重要的诉求。
- 第一个诉求是冀望有一套 对立的集群，通过提供多租户，资源隔离的形式进步资源利用率，解决多个事业部多套集群的问题。
- 第二个诉求是冀望通过平台的形式 升高实时数据开发的门槛，从而可能笼罩更多的开发者。
- 第三个诉求是冀望可能提供 通用场景的解决解计划，进步我的项目的复用性，防止每个事业部都开发雷同场景的剖析工具。
- 第四个诉求是对作业进行 全方位的生命周期治理，包含元数据和血统，一旦有一个作业出现异常，咱们能够疾速剖析和定位影响范畴。
实时平台性能概述
当初咱们平台曾经是一个一站式的实时数据分析平台，包含了数据集成、数据开发、作业保障、资源管理、数据安全等性能。
- 在 数据集成 方面，咱们反对数据库、埋点数据、服务端日志数据的集成，为了可能进步数据集成的效率，咱们提供了很多的通用模板作业，用户只须要配置即可疾速实现数据的集成。
- 在 数据开发 方面，咱们反对两种形式的作业开发，一种是 Flink SQL 作业开发、一种是 Flink Jar 包托管，在 Flink SQL 开发上咱们内置了很多 UDF 函数，比方能够通过 UDF 函数实现维表 join，也反对用户自定义 UDF，并且实现了 UDF 的热加载。除此之外，咱们也会记录用户在作业开发过程中的元数据信息，不便血统零碎的建设。
- 在 作业保障 方面，咱们反对作业状态监控、异样告警、作业失败之后的主动拉起，作业主动拉起咱们会主动抉择可用的 checkpoint 版本进行拉起，同时也反对作业在多集群之间的切换。
- 在 资源管理 方面，咱们反对平台多租户，每个租户应用 namespace 进行隔离、实现了不同事业部、不同用户、不同版本的 Flink 客户端隔离、实现了计算资源的隔离。
- 在 数据安全 方面，咱们反对角色权限治理、表级别权限治理、操作审计日志查问等性能。
以上就是咱们平台的性能，在赋能业务的同时，咱们也还在疾速迭代中，冀望平台简略好用，稳固可信赖。
实时平台的批流交融
接下来说一下平台建设中的一些实际，第一个是批流交融。
咱们先理分明批流交融是什么？
批流交融能够分为两个概念，一个是 Flink 提出的批流交融，具体的了解就是一个 Flink SQL 既能够作用于流数据、也能够作用于批数据，通过保障计算引擎统一从而缩小后果数据的差别，这是一个技术层面上的批流交融。另个一概念是咱们外部提出来的，那就是架构层面的批流交融。具体的操作手法就是通过 Flink 作业保障数据仓库 ODS 层的实时化，而后提供小时级别、分钟级别的调度，从而进步数据分析的实时化。
为什么咱们会提出架构上的批流交融，次要咱们看到行业倒退的两个趋势。
- 第一个趋势是数据集成的实时化和组件化，比方 Flink 集成 Hive、Flink CDC 的继续欠缺和加强，这样咱们做数据集成的时候就会变得非常简单。
- 第二个趋势是实时 OLAP 引擎越来越成熟，比方 Kudu+impala、阿里云的 Hologres、湖仓一体的计划。
这两个趋势让用户开发实时数据会变得越来越简略，用户只须要关注 SQL 自身就能够。
如上图所示，咱们有三个类型的实时数仓，一个是基于 Hive 的、一个是基于实时 OLAP 引擎的、一个是基于 Kafka 的。其中，蓝色线条就是咱们 ODS 层实时化的具体实现。咱们提供了一个对立的工具，能够将实时的将数据写入到 Hive、实时 OLAP 引擎、当然还有 Kafka。这个工具应用起来比较简单，如果是 MySQL 数据的同步，用户只须要输出数据库名称和表名就能够了。
通过 ODS 层实时化的工具，咱们就能够在 Hive、实时 OLAP 引擎、Kafka 中构建实时数仓。
- 如果是 Hive 实时数仓，咱们会应用 Flink 将实时的增量数据写入到 ODS 层，而后提供一个定时 merge 的脚本，用来 merge 增量数据和历史数据，从而保障 ODS 层的数据是最新最全的。配合 airflow 小时级别的调度能力，用户就能够失去一个小时级别的数仓了。
- 如果是相似于 Kudu / Hologres 这样的实时 OLAP 引擎，咱们会先把离线数据从 Hive 中导入到实时 OLAP 引擎中，而后应用 Flink 将实时的增量数据写入到 ODS 层，写入的形式举荐应用 upsert 这样的个性，这样用户就可能失去一个纯实时的数仓了。配合 airflow 分钟级别的调度能力，用户就能够失去一个分钟级别的数仓了。
- 基于 Kafka 构建实时数仓，就是十分经典的架构了，开发成本也比拟高一些，除了必须要秒级更新的剖析场景，咱们不太倡议用户应用。当然在 2021 年的时候，咱们也会去做 Flink 批流一体解决方案，让用户有更多抉择形式的同时，让整个实时数仓变得更加简略。
以上就是咱们对批流交融的思考和实际，通过这种架构层面的批流交融，原来须要开发一个月的实时需要，当初 2 天就差不多能实现。大大降低了开发实时数据的门槛，进步了数据分析的效率。
实时平台 ODS 层实时化
说一下 ODS 层实时化咱们具体是怎么做的。
要想把 ODS 层数据实时化，咱们须要解决两个问题，第一个是离线数据的初始化问题，第二个是增量数据如何写入的问题。离线数据导入比拟好做，如果数据源是 MySQL，咱们能够应用 DataX 或者 Spark 作业的形式将 MySQL 的全量数据导入到 Hive 中，而实时增量数据的写入咱们须要有两个步骤，第一个步骤是将 MySQL 的 binlog 采集到 Kafka，第二个步骤是将 Kafka 的数据应用 Flink 作业导入到 Hive。这样算下来，要解决 ODS 层实时化的问题，咱们就须要一个离线初始化的作业，一个增量数据采集的作业，一个增量数据写入的作业，也就是须要 3 个作业。
在咱们的平台上，咱们对 ODS 层的 3 个作业进行了封装和对立调度，用户只须要输出一个数据库名称和表的名称就能实现 ODS 层实时化的工作。
以上就是咱们批流交融中 ODS 层实时化的实现过程。
实时平台 Flink SQL 开发流程
咱们另外一个实际，就是对 Flink SQL 的作业封装。先看一下，在咱们平台上进行 Flink SQL 开发的整体流程。
从左往右看，数据源中的数据会通过 Maxwell、canal 这样的工具采集到 Kafka，采集到 Kafka 的原始数据格式并不是对立的，所以咱们须要将 Kafka 中的数据进行对立格式化解决，咱们默认反对埋点数据格式、canal 数据格式、maxwell 数据的解析，也反对用户本人上传 Jar 包进行数据解析，解析失去的标准化数据就会再次发送到 Kafka。
而后咱们会应用 Flink SQL 作业来生产 Kafka 的数据，进行 SQL 脚本的开发。这里的 SQL 脚本开发和原生的 Flink SQL 的脚本开发有一点不一样，原生的 SQL 脚本开发用户须要编写 Source 信息、Sink 信息，在咱们平台上用户只须要写具体的 SQL 逻辑就能够了。
那用户写完 SQL 之后，会将 SQL 作业信息提交到咱们封装好的 Flink SQL 执行作业上，最初通过咱们封装的 SQL 引擎将作业提交的 Flink 集群下来运行。前面将介绍咱们是怎么封装的。
以上就是在咱们平台上进行 Flink SQL 开发的流程，除了 Flink 作业自身的开发和提交，平台也会保留与作业无关的各种输出、输入的 schema 信息。比方业务数据库表的 schema 信息，通过批准加工之后的 schema 信息，数据输入的表的 schema 信息，通过这些记录，前期咱们排查问题的时候就可能疾速梳理出作业的前因后果和影响范畴。
实时平台 Flink SQL 开发过程
在咱们平台上开发 Flink SQL 作业，只须要三个步骤：
- 第一个步骤确认 Kafka 的 Topic 是否曾经注册过了，如果没有注册就须要用户手动注册下，实现注册后，咱们会把 Topic 的数据解析进去，将字段信息保存起来。
- 第二步使用户编写 SQL，方才说过，用户只须要写具体的 SQL 逻辑，不须要写 Source 和 Sink 信息。
- 第三步是用户指定将数据输入到哪里，当初平台能够反对同时指定多个 Sink 存储设备，比方将计算好的数据同时写入到 Hive、Holo 等存储。
通过以上三个步骤的配置，用户就能够提交作业了。
接下来说一下，咱们是怎么做的，我把整个执行过程分为 2 个阶段 10 个步骤。
第一个阶段就是作业筹备阶段，第二个阶段就是 SQL 执行阶段。
■ 作业筹备阶段
- 第一步，用户在页面数据 SQL 和指定 Sink 信息。
- 第二步，SQL 解析及校验过程，当用户提交 SQL 时，咱们会对 SQL 进行解析，看看 SQL 中用到的 Source 表和 UDF 是否在平台中注册过。
- 第三步，揣测建表，咱们会先使用下用户的 SQL，而后失去 SQL 的返回后果，依据后果数据生成一些建表语句，最初通过程序主动到指标 Sink 存储下来建表。
- 第四步，拼装 Flink SQL 的脚本文件，失去一个有 Source、SQL、Sink 三要素的脚本文件。
- 第五步，作业提交，这里会把 Flink SQL 文件提交到咱们本人执行引擎中。
■ SQL 执行阶段
- 第一步是会初始化 StreamTableAPI，而后应用 connect 办法注册 Kafka Source，Kafka 的 Source 信息须要指定数据解析的规定和字段的 schema 信息，咱们会依据元数据主动生成。
- 第二步是应用 StreamTableAPI 注册 SQL 中应用到的维表和 UDF 函数，UDF 函数包含用户本人上传的 UDF 函数。
- 第三步是应用 StreamTable API 执行 SQL 语句，如果有视图也能够执行视图。
- 第四步是一个比拟要害的步骤，咱们会把 StreamTabAPI 转成 DataStream API。
- 第五步就是在 DataStream 的根底上 addSink 信息了。
以上是两个阶段的执行过程，通过第二个阶段，用户的 SQL 作业就会真正的运行起来。
实时平台原生作业与模板工作
下面分享了咱们的 Flink SQL 作业如何开发和运行，接下来说一下咱们平台对 JAR 包类型作业的反对。
在咱们平台上，咱们反对用户本人上传 JAR 包作业，而后在咱们平台上进行治理。与此同时，为了进步代码通常场景的复用性，咱们开发了很多模板作业，比方反对 Maxwell 采集的 binlog 间接写入到 Hive、Kudu、Holo 等存储设备，反对阿里云 SLS 日志写入到各种 OLAP 引擎。
实时平台混合云部署计划
讲一下混合云部署计划和平台技术架构。
咱们平台当初反对将作业提交到阿里云机房、自建机房中，并且作业能够在两个机房中来回切换。为了要有这个性能呢?
今年年初，随着疫情的暴发，互联网在线教育涌入了大量的流量，为了应答暴增的流量，春节期间咱们洽购了上千台机器进行紧急的部署和上线，起初疫情稳固住了之后，这些机器的利用率就比拟低了，为了解决这个问题，咱们平台就反对了混合云部署计划，高峰期的时候作业能够迁徙到阿里云上运行，平时就在本人的集群上运行，既节约了资源又保障了弹性扩容。
实时平台技术架构
接下来说一下平台的技术架构。
咱们是一个前后端拆散的我的项目，前端应用 vue+elmentui、服务端应用 springboot，不同的机房外面咱们会部署一个后端服务的实例。工作提交到不同的机房次要通过转发层的 nginx+lua 来实现的。平台上工作的提交、暂停、下线操作，都是通过驱动层来实现的，驱动层次要是一些 shell 脚本。最初就是客户端了，在客户端上咱们做了 Namespace/ 用户 /Flink 版本的隔离。
3.K12 教育典型剖析场景
续报业务介绍
咱们聊一个具体的案例，案例是 K12 教育行业中典型的剖析场景，用户续报业务。
先说下什么是续报，续报就是反复购买，用户购买了一年的课程，咱们冀望用户购买二年的课程。为了用户购买课程，咱们会有一个集中的时间段用来做续报，每次继续一周左右，一年四次。
因为续报周期比拟集中，工夫比拟短暂，每次做续报业务老师对实时续报数据的需要就特地迫切。
为此咱们做了一个通用的续报解决方案，来反对各事业部的续报动作。要做实时续报，有几个挑战。
- 第一个挑战是计算一个用户的订单是否是续报，须要依赖这个用户历史上所有的订单，也就是须要历史数据参加计算。
- 第二个挑战就是一个订单的变动会影响其它订单的变动，是一个连锁效应。比方用户有 5 个订单，编号为 345 的订单都是续报状态，如果用户勾销了编号为 3 的订单，订单 4 和订单 5 的续报状态就须要从新计算。
- 第三个挑战是维度变动很频繁，比方用户上午的分校状态是北京，下午的分校状态可能就是上海，上午的辅导老师是张三，下午的辅导老师就是李四，频繁变动的维度给实时汇总数据带来了挑战。
依赖历史数据、订单扭转的连锁效应、频繁变动的维度，这些挑战如果单个看都不算什么，如果放在一起就会变得比拟有意思了。
实时续报解决方案
先说下整体架构，咱们采纳的批流交融形式来做的，分成两条线，一条线是分钟级实时续报数据计算，一条是秒级实时续报数据计算。计算好的数据放在 MYSQL 中，用来做大屏和 BI 看板。
先看下蓝色的这条线，咱们会把 Hive 中的离线数据导入到 Kudu 中，离线数据都是计算好的订单宽表。而后会应用 Flink 作业把新增的订单做成宽表写入到 Kudu 中，这样 Kudu 外面就会有最新最全的数据。配合 4 分钟的调度，咱们就提供了分钟级的实时续报数据。
在看第一条橙色的线条，这条线上有两个 Flink 作业，一个是 ETL Job，一个是 Update Job。
ETL job 会负责动态维度的拼接与续报状态的计算，动态维度拼接咱们是间接拜访 MySQL，而后缓存在 JVM 中。续报状态的计算须要依赖历史数据，ETL Job 会将所有的订单数据加载到 JVM 中，具体的实现办法是咱们自定义了一个 partitioncustom 办法，对所有的历史数据进行了分片，上游的每个 Task 缓存一个分片的数据。通过将数据加载到内存中，咱们大大的放慢了 Flink 实时计算的速度。
ETL Job 的计算的数据，会有两个输入，一个是输入到 Kudu，用来保障 Kudu 中的数据最新最全，两个一个数据是 Kafka，Kafka 中有一个 Topic 记录的是是以后订单的变动导致了哪些订单或者维度变动的信息。
接在 Kafka 前面的程序就是 Update Job，专门用来解决受影响的订单或者维度，间接去批改 MySQL 中相干的统计数据。
这样咱们就通过 2 个 Flink 作业实现的实时续报的计算。
最上面的一条线是实时维度的数据变更的解决，维度变更的数据会发送到 Kafka 中，而后应用 Flink 进行解决，看看维度的变动影响了哪些数据的统计，最初将受影响的订单发送到受影响的 Topic 中，由 Update Job 来从新计算。
以上就是咱们实时续报的整体解决方案，如果有教育行业的敌人听到这个分享，或者能够参考下。
实时续报稳定性保障
咱们看看这个通用的解决方案上线之后有哪些保障。
- 第一个保障是 异地双活，咱们在阿里云和自建机房都部署了一套续报程序，如果其中一套有异样，咱们切换前端接口就能够了。如果两个机房的程序都挂了，咱们从零开始启动程序，也只须要 10 分钟。
- 第二个保障是 作业容错，咱们有两个 Flink 作业，这两个作业随停随启，不影响数据的准确性。另外一点就是咱们缓存了所有订单数据在 JVM 中，如果数据量暴涨，咱们只须要扭转 ETL 程序的并行度就能够，不必放心 JVM 内存溢出。
- 第三个保障是 作业监控，咱们反对作业的异样告警和失败后的主动拉起，也反对生产数据提早告警。
通过以上保障措施，实时续报程序通过了几次续报周期，都比拟安稳，让人很省心。
4. 瞻望与布局
上述内容具体介绍了好将来以后业务及技术计划，总结而言咱们通过多租户实现各事业部资源隔离、通过批流交融的架构计划解决剖析实时化、通过 ODS 层实时化解决数据源到 OLAP 的数据集成问题、通过 Flink SQL 封装升高实时数据开发门槛、通过模板工作提供通用场景解决方案、通过混合云部署计划解决资源的弹性扩容、通过实时续报解决方案笼罩雷同场景的数据分析。
最初，来看一下咱们瞻望和布局。接下来咱们要持续深入批流交融，强化混合云部署，进步数据分析的时效性和稳定性。反对算法平台的实时化，数据利用的实时化，进步数据决策的时效性。
