共计 4483 个字符，预计需要花费 12 分钟才能阅读完成。
摘要：本文整顿自翼领取高级开发工程师曹劼、尹春光在 Flink Forward Asia 2021 平台建设专场的分享。本篇内容次要分为四个局部：
- 公司简介
- 实际中的问题
- 案例实际
- 将来布局
点击查看直播回放 & 演讲 PDF
一、公司简介
翼领取是中国电信的全资子公司，公司次要业务分为民生缴费、生产购物、金融理财，同时咱们依靠云计算、大数据、人工智能等技术手段，赋能线上及线下的商户。
公司次要的业务板块分为数字生存、数字金融及金融科技服务。其中数字生存次要是指惯例的领取业务，例如民生缴费，即居民的水电煤气费缴纳等等，同时咱们会联合电信联合推出 5G 的权利套餐；数字金融次要是蕴含保险、理财、信贷，其中橙分期和企业白条是重点产品；科技服务次要分为企业征信及数智业务，企业征信是指依靠现有的云计算、大数据、人工智能、区块链等外围科技能力，打造业余高效智能的风险管理及征信科技解决方案。数智业务是指以天翼云为根底平台，重点聚焦 SaaS/PaaS 服务及金融平安服务，打造端到端的金融解决方案。
目前，翼领取的月活用户数为 5000 万 +，存量用户数 5 个亿 +，线上的服务器大概 4000 台，每日的记录数为千亿条。
随着公司的业务规模一直扩大，咱们面临的业务挑战也在一直增多，次要体现在两个方面：
- 一方面，随着需求量的一直增多，采纳定制化开发的形式使得利用的数量急剧减少，导致利用难以对立治理，各个业务线的利用向着烟囱式的方向倒退，指标口径和计算不对立，反复的加工会造成能力的节约；
- 另一方面，某些场景下的单 topic 数据量高达 220 万 / 秒，同时针对风控等场景，业务响应提早要求 200 毫秒以内。
针对以上问题，咱们从 18 年开始，联合行业的实践经验，积极探索建设实时加工体系。在 19 年开始着手构建实时指标加工零碎，引入 SparkStreaming 作为计算引擎。在 20 年初出于对时效性的思考，咱们引入 StructuredStreaming 作为实时计算引擎。随着服务的利用一直增多，咱们接管到依赖原子指标的组合的实时决策需要逐步增多。因而在 20 年 9 月份，咱们开始构建实时决策零碎，将 FlinkCEP 引入零碎中。直到往年 4 月份，为了解决一些简单指标的加工需要，咱们将 Flink SQL 引入到了指标加工链路中。
通过产品的一直迭代，最终造成了一套企业化的智能决策零碎——先鉴平台。
上图展现了先鉴平台的次要性能。首先是实时指标加工。目前咱们反对多样化的数据源，次要蕴含罕用的中间件比方 Kafka 及 Pulsar。同时为了升高用户的应用难度，咱们提供了 23 种算法模板，也反对 SQL 的定制化加工形式；其次是实时决策。咱们反对丰盛的规定及规定组的嵌套组合，满足简单决策的需要。此外，咱们整合了实时、离线及第三方的标签，为用户提供对立的数据查问服务，同时为了生产的稳定性，咱们提供了全面的监控性能和细粒度资源隔离、熔断、限流的策略。同时针对实时计算作业的运行状态，咱们对 Source 及 Sink 的数据量和提早都进行了相干的 Metrics 监控。
上图展现了先鉴平台的逻辑架构，次要分为 4 层。
- 最上层是利用调用方，次要蕴含智能风控、智能决策、智能营销零碎；
- 往下是实时决策模块，提供实时决策的性能，其中蕴含 Web 进行决策的配置及治理，同时提供开发核心进行决策工作的验证，通过决策外围进行实时的决策；
- 第三层是实时指标加工模块，通过用户配置不同的加工形式，录入到不同的执行引擎，同时整合数据服务，为用户提供后果查问；
- 最上面是数据层，数据源次要蕴含业务数据、用户的埋点数据以及团体加工的离线数据。最终依据用户的配置，将计算结果存储到相应的 DB。
实时指标加工零碎的技术架构图次要蕴含三个模块。前端界面次要负责用户工作的配置及权限治理，后盾会将用户配置的信息生成相应的自定义 DSL 语言格局提交给内核，内核依据不同的配置形式，通过 Mode Selector 抉择相应的执行引擎。
如果通过模板的加工形式，则会通过 DSL Parser 进行语法解析，再进行数据的荡涤以及算法的计算；如果是 SQL 模式，则只进行 SQL 语法的解析，同时加载用户的 UDF 及相干配置信息生成相应的工作执行图交给 Program Deployer 并抉择相应的部署环境进行工作的公布。
执行环境通过 yarn 进行资源管控，同时 HDFS 负责元数据存储。
Stream SQL 的性能分为根底性能和性能监控性能。
根底性能次要包含以下几种：
- SQL 语法校验。目前反对 Flink SQL 语法，在用户提交之前先进行 SQL 语法的验证；
- 沙箱测试。用户能够预提交工作并进行工作准确性的验证；
- 反对用户 udf 函数的加载。
性能监控性能次要包含以下几种：
- 提供了细粒度的资源配置。社区版本的 Flink SQL 不反对 operator 层级的资源配置，只能应用对立的并行度配置，会导致生产上某个节点压力过大而造成工作提早的状况。所以咱们通过获取 Streamgraph 的 JsonPlan 的形式进行各个节点的并行度设置，从而实现细粒度的资源配置；
- 工作状态监控。咱们会监控工作的运行状态，同时思考工作提早以及加工链路过长的问题。咱们仅仅针对 source 及 sink 的数据流和流量的变化率进行监控，一旦发现变化率异样，会及时反馈给业务用户，可能尽早发现业务变动；
- 失败工作主动复原。可能通过获取最近一次 Checkpoint 进行复原。同时针对 Checkpoint 周期长的工作，在重启时思考复原工夫的问题，咱们会在重启时之前强制进行一次 Savepoint，从而缩短工作复原工夫。
上图展现了实时指标配置的过程：
- 第一步，配置相应的 Source、Schema 信息或提供数据的 demo 进行主动解析；
- 第二步，抉择数据荡涤的形式，这里提供了几种简略的数据荡涤逻辑，也反对 SQL 的形式；
- 第三步，抉择计算用的算法模板，也反对算法的嵌套。
上图展现了 SQL 加工配置的过程。先创立一个工作，蕴含用户的资源等参数，而后编写工作 SQL，最初上线工作并提交给执行环境。
实时决策模块里的前端页面次要负责决策工作的配置及用户权限治理，并将工作提交给后端。后端会通过 Zookeeper 将上线的策略公布到相应的决策节点。每一个执行节点都有一个 ZK Watcher，用于监听策略的状态，通过 RuleLoader 加载策略并通过 RuleCompiler 对策略进行编译，最初交给 Flink CEP 进行决策执行。最终将决策的后果存储到 DB 或中间件。
决策配置的过程首先须要创立一个工作，而后配置相应的规定以及规定的组合，最初通过开发核心进行工作的试运行，验证决策的准确性。
二、实际中的问题
在实际过程中，咱们也遇到了很多挑战，总结起来有如下几个方面：
业务 State 数据一致性、指标反复计算问题、动静规定配置以及全链路监控监控问题。
首先是指标作业降级过程中，通过指标引擎配置的 job State 数据一致性问题。晚期指标作业是通过手动开发，局部业务 State 存储在 HDFS 中，指标引擎配置的 job 没有独自治理业务 State 的数据，老的工作迁徙到平台过程中就会遇到数据一致性问题。
解决思路是扩大老的计算程序，读取全量 State 数据存储到内部，而后进行老工作。指标引擎配置的作业从指定的 offset 进行数据计算，而后从内部存储补齐原有的指标数据。
上图展现了作业降级的流程。Task 在 open function 的时候读取业务 State 数据存储到内部。如果是 Keyed State，则 State 接口无奈获取以后 task 的所有 State 数据，须要将 State 对象进行向下类型强转，而后获取所有 State 数据指标引擎。作业通过配置指定对应的 offset，通过从内部补齐数据的形式进行指标计算，从而实现数据恢复。
其次是指标作业在一直新增过程中存在的痛点，多个作业反复生产同一个 Kafka 导致上游生产压力大以及指标反复计算的问题。
针对以上痛点，咱们的解决办法是对所有作业进行对立优化，对所有音讯源进行对立预荡涤，依照业务过程散发到对应的数据域 Topic 中。对指标进行对立的口径治理，保障指标不反复计算。目前没有对实时指标进行分层解决，次要为了防止在计算链路过长从而影响业务的时效性。
第三，Flink CEP 存在的问题。实时决策的模块是通过 Flink CEP 进行规定匹配，最后是通过程序编码的形式实现规定的匹配，然而随着规定越来越多，不便于保护，开发成本也随之减少。Flink CEP 无奈进行动静的规定配置以及多个规定并行决策。
针对上述问题，咱们对 Flink CEP 进行了扩大开发来解决规定动静配置以及多个规定决策的问题。
上图展现了 Flink CEP 扩大开发的逻辑架构。用户通过 RuleManager 配置规定并将规定变更事件公布到 Zookeeper 中，RuleListener 监听到事件的变更后，若是新增规定，则会通过 groovy 动静语言编译生成 RulePattern 实例。随着规定的增多，CEP operator 线程解决效率会降落，须要通过把规定分组绑定到对应的 Worker 上来减速规定解决。CEP operator 线程接管到事件后会分发给所有 Worker，Worker 线程解决完后通过队列公布到 CEP operator 线程，最初公布到上游。
最初是数据全链路监控的问题。数据流从收集端通过 Flume 传输，再到音讯核心指标计算，而后公布到上游的实时决策，不容许大量的数据失落以及数据提早。
基于以上诉求，须要对整体数据链路进行监控，采纳 prometheus + grafana 进行 metrics 的收集以及告警。这里次要针对 Flume 消息中间件进行音讯沉积以及失落的监控。Flink 指标计算次要监控运行状态以及背压状况，上游监控 CEP 决策的工夫。对数据链路的监控可能帮忙运维疾速定位并解决线上的问题。
三、案例实际
上图展现了先鉴平台的工作形式。
首先，上游的用户行为和业务事件通过数据通道传输到先鉴平台，业务方负责配置实时指标和业务规定，当业务事件通过指标计算结果触发了业务规定，先鉴平台随即将后果推送到上游的音讯核心，通过各业务零碎触达到用户。比方用户拜访理财首页时，如果 30 分钟内未进行产品申购，就会依据用户的资质给他发送对应的推送短信。
四、将来布局
将来，咱们打算在以下几个方面进行继续摸索：
- 第一，数据库增量采集的计划对立。目前 MySQL 的采集是应用 Canal 实现的，将来咱们布局应用 Flink CDC 来针对 Oracle 和 MySQL 进行对立的增量采集；
- 第二，离线实时的批流交融。目前离线数仓通过 Spark SQL 计算，实时数仓应用 Flink SQL 计算，保护两套元数据以及不同的指标口径使得日常工作负荷很大，因而咱们心愿应用 Flink 来实现对立的批流计算；
- 第三，Flink 作业主动扩容缩容。目前 Flink 无奈进行主动扩容缩容，早晚流量变动较大，会导致较多的资源节约，计算能力有余的时候只能通过人工进行作业扩容。咱们心愿基于 Flink 来实现主动扩容，升高运维老本。
点击查看直播回放 & 演讲 PDF
更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～
