摘要:本文整顿自中泰证券大数据中心实时计算平台架构师连序全,在 Flink Forward Asia 2022 行业案例专场的分享。本篇内容次要分为四个局部:
- 平台倒退历程
- 架构 & 选型
- 典型利用场景
- 将来瞻望
点击查看直播回放和演讲 PPT
中泰证券股份有限公司成立于 2001 年 5 月,是全国大型综合类上市券商,在全国 28 个省市自治区设有 45 家分公司、300 多家证券营业部,员工 9000 多人,造成了集证券、期货、基金等为一体的综合性证券控股集团。
目前中泰证券服务客户超 770 万,为企业融资近 1.5 万亿元,公司治理总资产额超过万亿,在全国各地领有 300 多家营业部为客户提供各种服务。能够说中泰证券在证券行业领有着很强的综合实力。
一、平台倒退历程
随着业务的一直倒退,对数据的时效性要求也越来越高,传统的离线计算越发步履艰难,业务驱动着咱们建设一套实时计算平台和体系。在实时计算平台的摸索过程中,性能、场景的反对度、稳定性始终是推动咱们平台一直降级的原动力。
首先在性能方面,须要一款高性能计算引擎撑持公司的实时类业务;其次在利用场景方面,须要平台疾速响应业务需要,上线各类服务;最初在稳定性方面,证券行业的特点决定了实时计算平台须要领有很好的容错性和高可用性。
基于上述建设背景,咱们平台一共经验了四次技术变迁。
- 第一阶段,在 2018 年初,基于 Storm 计算引擎构建第一版实时计算平台,采纳的是一种组合式的编程模式。
- 第二阶段,在 2021 年 2 月,咱们基于 Flink 构建了第二版实时计算平台,采纳了申明式的编程模式,并上线了第一个 Flink 业务利用。
- 第三阶段,在 2022 年 7 月,借助云原生的倒退,推动了 Flink 与 K8s 的集成。基于 Pod 进行 Task 资源调度,并进行大规模的业务推广。
- 第四个阶段,从 2022 年至今,平台始终在摸索流批一体的整体解决方案,寻求新的数据处理架构。
第一版实时计算平台基于 Storm 计算引擎构建,采纳 Storm 原生的 API,Spout、Bolt 构建工作拓扑,窗口计算、状态存储等性能个性通过引入第三方组件实现。在资源调度上,采纳 Storm Standalone 模式部署,所有的工作共享集群的资源。此时的实时计算平台在客户关键时刻揭示 MOT、合规风控等场景开始利用起来。
然而平台运行不久,Storm 计算引擎开始暴露出一些问题。
- Storm 计算框架本身反对的能力有余,像 Exactly Once、窗口计算、状态存储等个性均不反对,难以应答简单的计算场景。
- 开发成本太高,上线周期太长。Storm 基于组合式的开发方式,工作的拓扑关系、数据的散发形式都须要开发者自行指定,自身就存在肯定的开发门槛,简略的作业也须要开发者编写大量的冗余代码。
- 资源隔离粒度较差,作业运行相互影响。另外,Storm 部署架构中 Nimbus 节点负责工作的调度,资源数据的收集、散发、Jar 包等性能。当集群作业增长到肯定数量级时,Nimbus 节点将变成整个集群的性能瓶颈。
针对 Storm 计算引擎的种种问题,咱们来看一下 Flink 计算引擎是如何一一解决的。
首先在性能个性的反对上,Flink 借鉴了一篇对于分布式快照的论文,实现了只解决一次语义,同时提供了多种状态存储形式等等。正是这些个性的引入,为实时计算的简单场景提供了很好的技术撑持。
其次在开发方式上,Flink 提供了 Flink SQL、Table API、Data Stream、Stream Processing 四个级别的形象,为程序开发带来了很大的灵活性,开发者能够针对不同的业务场景灵便抉择。
最初是资源调度上,Flink 反对 Yarn、K8s 等多种调度形式,能够对资源进行更细粒度的管制,使资源的利用率更高,作业的隔离性更好。
因而以 Flink 计算引擎为外围的实时计算平台上线伊始,就为各业务提供了重要的撑持。截止到目前为止,实时计算平台曾经囊括的数据源包含集中交易柜台、融资融券柜台、产品核心、资讯中心、公募基金、账户零碎、综合金融、资金治理等泛滥外围的业务零碎,同时为齐富通 APP、掌 E 通等多种终端提供服务。
二、架构 & 选型
上图是咱们实时计算平台的整体架构图,从下之上次要包含数据源、数据的接入层、资源的调度层、实时计算平台、数据存储层以及数据应用层。
在数据源,次要采集业务数据库的变更日志、APP 埋点数据、日志数据、监控数据等等。数据接入层分为两种类型:
- 对于结构化数据,平台应用商业产品 HVR 和 Flink CDC 进行采集。
- 对于非结构化数据,平台应用 Elastic Beats 进行数据收集。
在资源调度层面,平台反对基于 Yarn、K8s 的资源调度,开发者能够灵便抉择须要的资源调度形式。
实时计算平台反对多种开发方式,反对丰盛的自定义组件,同时领有全面的运维管理体系。通过实时计算平台加工后的数据,按场景进行分类存储,反对输入到 Kafka 消息中间件、HDFS 离线数仓、TiDB、MySQL 等关系型数据库,和 ES 全文检索引擎。
最初,数据应用层反对多种数据服务形式,能够通过服务订阅将数据推送到上游业务零碎;通过接口平台将数据提供给其余零碎应用。
基于实时计算平台的整体架构图,咱们对实时计算平台的能力域进行了汇总,次要包含以下四个局部。
- 开发方式。反对 Flink SQL、Table API、Data Stream API,以及正在调研应用的可视化构建等多种开发方式,反对不同类型的开发需要。
- 资源调度上。开发者能够灵便抉择 K8s、Yarn、Standalone 多种调度形式。
- 自定义插件。为了晋升开发效率,升高开发成本,平台针对具体的业务场景,形象出相似数据荡涤、数据去重、维表关联等开发模型。
- 运维治理。稳定性、安全性始终是平台重点关注的内容,权限管制、监控、告警、日志收集、平安认证等性能撑持平台稳固平安的运行。
实时计算平台通过长期的技术积攒、业务积淀,能够总结出以下四大个性。
- 麻利的平台。反对与 DevOps 协同,一键部署线上作业。
- 云化的平台。反对 K8s 资源调度,借助其弱小的能力,实现资源的弹性扩缩容。
- 平安的平台。采纳多租户隔离机制,在数据存储、计算、调度等层面保障用户数据安全。
- 凋谢的平台。拥抱凋谢的生态,凋谢的架构。
三、典型利用场景
实时计算平台的利用场景十分多,本次的分享次要从晋升服务效力、实时数据管道、实时危险监测三个利用场景进行开展。
在实时平台上线之前,客户服务的时效性有余,这里列举了三个案例。
应用实时计算平台前:
- 新股中签音讯 T+1 天后,才告知客户中签。
- 客户交易后短少相应的信息反馈。
- 客户不能及时获知本人持仓证券的危险警示信息,导致客户的体验感较差。
通过实时计算平台的业务场景革新后:
- 客户能够第一工夫获知中签信息。
- 客户在交易后能够立刻收到信息反馈。
- 客户能够实时接管到证券的危险警示信息。
上图是晋升服务效力利用场景的数据流图。
数据源次要来自上游的业务数据库,包含集中交易柜台、融资融券柜台、产品核心、资讯数据等等。通过 HVR 将数据库变更日志抽取到 Kafka 中,而后 Flink 进行数据生产、逻辑加工、维表关联,将最终的加工后果输入到 Kafka、TiDB、MySQL 等。
上游通过 MOT、KPM、综合金融等平台将数据发送到客户终端,以齐富通 APP、短信、微信为载体,将信息实时展现给客户。
上图向大家展现了晋升服务效力场景革新后的建设成绩。
第一张图展现了客户基金定投扣款失败的揭示,在扣款失败时及时告知客户失败的起因。前面两张图别离展现了客户新股中签的音讯揭示和客户股票的成交揭示。
实时数据管道场景次要以技术角度为出发点,有以下四种数据流向。
- Kafka 数据通过 Flink SQL 同步到 Kafka,实现不同 Kafka 集群间的音讯复制,实现集群读写拆散的场景。
- 通过 Flink SQL 将日志数据落地到 HDFS,提供给后续审计、数据挖掘等场景应用。
- 将监控数据实时写入 TiDB,实现监控运维大屏。
- 将客户的流水数据、交易数据写入 Hbase,满足客户实时流水数据的查问。
上图是实时数据管道利用场景的数据流图。数据源依然来自上游业务数据库,次要包含集中交易柜台、融资融券柜台、产品核心、平台的日志数据、用户行为数据等等。通过 HVR、Agent 将数据库的变更日志、行为数据等抽取到 Kafka 中,应用 Flink SQL 进行数据生产、逻辑加工、数据落地。最终提供给经营剖析、运维治理、大屏展现等场景进行应用。
上图向大家展现了实时数据管道场景革新后的建设成绩。
通过 Flink SQL 实现了运维监控大屏,能够通过运维监控大屏排查平台的 CPU、内存、网络 IO 等异样情况。
金融业是应用数据的重点行业,对数据具备高度的依赖性,呈现数据安全问题的风险性也更大。公司始终提倡“合规风控至上”的经营理念,把风险管理文化建设作为公司倒退策略的重要组成部分。实时计算平台为高效的危险监测带来了一种新的可能,次要波及的危险监测场景包含实时维保比例监控、大额申报监控、频繁高买高卖监控、涨停价、跌停价申报监控等等。
目前危险监测次要存在以下几个痛点:
- 在数据的时效性上,监测频率为分钟级别,数据的时效性严重不足,难以满足业务需要和监管部门的要求。
- 在数据处理架构上,危险监测大多采纳批量计算的模式,通过周期性调度作业的形式实现,存在失落重要事件的可能性。
- 在数据存储上,危险监测两头后果数据并不落地,导致无奈查问历史的时点值,无奈进行重要事件回溯。
上图是实时危险监测利用场景的数据流图。数据源次要来自上游的业务数据库,包含客户的股份数据、负债数据、委托数据、交易数据、行情数据等等。通过 HVR、Agent 将数据库变更日志、行情数据等抽取到 Kafka 中,实时计算平台进行事件生产,将客户交易数据与行情数据进行多流合并,并关联证券客户、信息等维表。
在数据架构上,采纳原始层、明细层、汇总层三层架构,对数据进行组织。加工后的数据存储到 HTAP 类型的数据库,这里咱们抉择了 TiDB。同时在非凡场景下输入到 Redis 队列中,供上游零碎进行生产。数据落地后通过数据推送、API 服务、报表零碎等形式提供应用。
上图是以客户实时维保比例监测为例,展现的实时危险监测场景的建设成绩。
维保比例 140% 是警戒线,130% 是平仓线。报表平台对维保比例跌破 130% 平仓线的客户进行了筛查,并进行后续的业务解决。同时,无论是行情变动还是客户产生了交易行为,平台都将相应的记录落地,实现对历史任意时点值的维持担保比例查问,并提供可视化的形式展示其变化趋势。
接下来为大家分享实时危险监测在施行过程中的难点。
- 在性能的方面,因为实时危险监测波及到客户的股票、债券、基金等多种标的的综合计算,导致计算量比拟大,计算逻辑简单。尽管 Flink 反对通过横向扩大的形式解决性能问题,但对于以后的利用场景,从客户维度无奈对工作持续进行拆解,横向扩大曾经无奈解决此类场景的问题。
- 在数据准确性方面,对于工作运行过程中呈现的一些异常情况,比方机器宕机、服务中断等等,如何保证数据的精准无误呢?
- 在数据存储上,须要寻找一款兼具 OLTP、OLAP 场景的数据库,一方面 Flink 写入后果数据的 TPS 较高,另一方面须要对落地的数据进行统计、聚合剖析。
针对以上三个难点咱们的解决方案如下:
针对性能瓶颈方面的难点。首先须要找到作业性能的瓶颈点,咱们通过 Task Manager 节点的 CPU 负载、Flink 的背压状态来定位具体的 Stream Operator。通过 Arthas 评估该 Stream Operator 要害门路的耗时,最终定位到产生性能瓶颈的具体业务逻辑。
在定位到性能瓶颈点之后,利用 Flink State 存储一些中间状态,防止业务逻辑反复计算。通过革新后,要害门路的耗时降落了一个数量级,优化的成果比拟显著。最初在数据输入方面,正当设置 TiDB 的写入参数,最大水平的晋升写入效率。
针对数据准确性保障方面的难点,咱们做了以下尝试。
- Checkpoint 指定长久化的存储形式,咱们抉择了星环 HDFS 作为存储底座,保障了工作在产生异样后能够复原运行。
- 作业上线后会依据业务的需要随时更新代码,咱们须要设置 RETAIN_ON_CANCELLATION 参数,在工作版本的降级后,依然能够复原以后的状态持续运行。
- 当上游零碎出现异常时,操作 HVR 进行数据回放,保障数据源的可回溯性。同时 Flink 作业依照事件的类型进行幂等解决,保障整体数据的准确性。最初通过 Queryable State 查问作业运行过程中的状态数据,在线排查客户数据的异样问题。
针对数据落地方面的难点,TiDB 输出表开启 TiFlash 性能,TiDB 通过 raft 协定异步复制数据到 TiFlash。对于不同的查问场景抉择不同的存储引擎,对于单客户的点查场景,通过 SQL Hint 批示应用 TiKV 存储引擎。对于聚合统计类的场景,比方咱们要查问 Top 100 的客户,通过 SQL Hint 批示应用 TiFlash 列式存储引擎。通过理论观测,在此利用场景下,通过 TiFlash 引擎能够将查问的耗时由分钟级升高至秒级。
四、将来瞻望
将来咱们将从以下三个方向进行摸索:
首先,实时数仓的摸索。Flink 弱小的流批一体能力让咱们能够很不便的去构建实时数仓体系架构。业务驱动着技术的倒退,本着将业务做深、做厚的理念,咱们将摸索更多的利用场景,同时 Flink 与数据湖联合也是将来的钻研方向之一。
其次,Flink CEP 的摸索。利用 Flink CEP 弱小的简单事件处理能力,降级现有的 Data Stream 技术框架,并在风控、合规等场景推广应用。
最初,随着云服务向算力服务的一直引进,Flink 与 K8s 的深度联合也是咱们后续的摸索方向之一。通过 K8s 的资源调度能力实现资源稳步,晋升资源的利用率。
点击查看直播回放和演讲 PPT
更多内容
流动举荐
阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动:
99 元试用 实时计算 Flink 版(包年包月、10CU)即有机会取得 Flink 独家定制卫衣;另包 3 个月及以上还有 85 折优惠!
理解流动详情:https://www.aliyun.com/product/bigdata/sc