摘要：本篇内容整顿自中信建投证券金融实时数仓我的项目负责人刘成龙、金融资讯数据研发工程师蔡跃在 Flink Forward Asia 2021 行业实际专场的演讲。次要内容包含：
- 中信建投证券 Flink 框架
- Flink 流解决场景
- 金融资讯实时化革新
- 将来瞻望
点击查看直播回放 & 演讲 PDF
中信建投证券公司成立于 2005 年，2016 年港交所上市，2018 年上交所主板上市。投行业务间断 8 年放弃行业前 3，托管证券规模行业第 2，次要经营指标目前均列于行业前 10。随同着公司的业务一路高歌猛进，技术方面也不容落后，数字化转型正在成为咱们近些年来的倒退重点。
因为金融行业波及的业务畛域泛滥，公司多年来积攒了大量简单的与业务高度相干的根底数据，在发现问题、剖析问题，解决问题的过程中，如何协调业务前、中、后盾以及科技部门等多方面配合来开展业务口径的梳理与加工逻辑的开发，成为目前亟待解决的关键问题。
一、中信建投证券 Flink 框架
数据中台架构如图所示。次要分为以下几大板块：由 Greenplum 数据仓库和 Hadoop 大数据平台形成的数据中心板块；以离线开发、实时开发、数据交换为主的数据开发板块；以及数据门户、数据网关、数据治理、经营治理等板块形成。
其中数据开发板块目前的工作次要以离线开发与数据交换的离线数据处理为主。但随着业务对数据时效性的进步，基于离线批处理的 t+1 业务模式曾经无奈齐全满足以后市场环境下对信息及时性的需要，这也是大力发展实时开发，力求为客户提供更高时效性数据服务的目标。
咱们以实时开发整个链路为例，对数据中台各个板块间的互相联动进行阐明。
从数据门户对立入口进入实时开发模块，首先将集中交易、融资融券等业务信息的实时增量数据拉取到 Kafka 音讯队列，Flink 生产 Kafka 实时流数据并与维表数据进行数据加工。加工逻辑中波及的维表数据量比拟大时，须要离线开发与数据交换，通过离线跑批的形式实现对维表的数据筹备。最初将后果数据写入关系型数据库或 NoSQL 数据库。数据网关再通过读取后果数据生成 API 接口，对上游的零碎提供数据服务。
数据治理板块中的数据管控模块次要治理数据中台的数据库表以及业务相干的数据库表的元数据，用户能够在数据门户订阅他们所关注数据库表的变更信息。当订阅的数据表产生了变动的时候，经营核心能够通过对立告警模块，多渠道告诉订阅用户数据库表的变更状况，以便于开发人员及时调整数据加工的工作。
Flink 实时流解决架构首先通过 Attunity 工具采集业务数据库的 CDC 日志，将同一零碎下的数据库表变动写入 Kafka 的一个 topic 队列中，这也就意味着 Kafka 的每一个 topic 中都会有多个表的数据，所以在 Flink 的 Kafka source 要先对 schema 和 tablename 这两个字段进行一次过滤，获取想要拿到的数据表的 CDC 数据流，再进行后续与维表的加工逻辑。将解决后的数据写入后果表，依据需要不同写入不同的数据库进行存储。
数据库的选型个别遵循以下准则：
- 数据量比拟小且不要求高并发的状况下，通常抉择关系型数据库进行存储；
- 数据量较大，而且对高并发有需要的时候，通常抉择 HBase 作为存储介质；
- 大量数据但要求高并发的状况下，抉择 Redis 进行缓存；
- 波及大量数据检索的状况下，个别抉择 ES 作为存储组件。
证券行业数据有两个显著特色：
- 其中一个是收盘的工夫固定，大量业务在开盘后数据量会大幅缩小，甚至有一些业务在开盘后不再产生新的数据，所以为了节约资源，咱们会依据理论状况对那些与收盘工夫严密相干的工作设置启停工夫；
- 第二个特点是金融数据的重要性，大量场景下不容许数据偏差存在，针对数据可靠性要求极高的特色，咱们对大量实时工作设置了夜间数据修改的离线工作，保证数据的正确性。
二、Flink 流解决场景
上面以几个理论场景阐明 Flink 流解决的利用状况。次要分为三个场景，批发业务实时指标统计、基金投顾实时指标统计和资金流水明细查问。
2.1 批发业务场景
批发业务线实时指标是治理驾驶舱的重要组成部分，决策者通过剖析公司经营指标，对公司的经营和倒退作出正当决策。
面向批发业务设计实时数仓，须要取得开户统计、客户服务、APP 经营几个主题的统计指标，依据实时数据处理架构和数据仓库分层的设计，面向批发业务的实时数仓能够分为以下几个流程：
- 首先是构建 ODS 层数据，实时采集客户信息表、业务流水表、渠道表等相干根底表的 CDC 日志。每个业务库的数据表对应接入到一个 Kafka 的 topic 中建设实时数仓的 ODS 层；
- 其次是 DWD 层的数据建模，创立 Flink 工作生产 ODS 层的 Kafka 音讯，进行数据荡涤，过滤、脱敏、关联转换等解决。同时以客户账户粒度进行数据合流，借助离线维表进行扩围操作，以取得账户粒度的明细表，实现 DWD 层的建设；
- 之后是 DWS 层的数据建模，基于 DWD 层的数据进行汇总，通过剖析业务需要，将 DWD 层的数据依照主题进行划分，汇总出渠道服务主题宽表、业务部经营主题宽表、交易产品主题宽表等公共指标宽表，建设 DWS 层；
- 最初依据理论业务需要，计算业务指标建设 ADS 层。对于一部分用户账户粒度的业务指标，可通过 DWD 层的明细间接计算失去，局部粗粒度的业务指标比方 APP 渠道服务客户人数、投顾产品浏览人数等，能够通过 DWS 层计算取得。最终计算结果接入到数据网关将数据对立提供给上游零碎或通过 BI 零碎展现。
通过对实时数仓进行分层治理，可能带来两方面的益处：
- 首先是防止烟囱式的数据开发模式，无需所有工作都从生产 Kafka 的 ODS 层数据开始，缩小了工夫上的开销，更有利于数据的复原，并可能撑持不同业务主题的灵便剖析；
- 其次在数据加工出错的状况下，更容易判断是哪个分层的数据加工逻辑出了问题，缩短排错时长。
2.2 基金投顾实时指标统计场景
基金业务在证券行业的重要性日益凸显，它能实时提供基金投顾产品的销售信息，为基金投顾及时调整策略提供数据反对。基金投顾场景的数据有三个特点：
- 第一，波及的数据规模比拟小；
- 第二，数据在收盘工夫提供给公司内部人员查看；
- 第三，数据对准确性的要求特地高。
针对数据量小的特点，咱们将数据指标后果输入到 Oracle 关系数据库；针对收盘工夫将数据供应内部人员查看的特点，咱们开启实时工作的启停策略，将更多的资源留给夜间跑批的工作来应用；针对数据准确性要求很高的特点，咱们通过夜间离线跑批的形式对数据进行修改，以保证数据的准确性。
原来的计划是通过页面触发存储过程来读取数据，而且读取的数据不是源零碎数据，存在分钟级别的提早。而实时数据加工计划通过实时推送客户新增、追加、签约、保有、签约率、规模等维度的指标，让业务部门能够更高效地把握外围数据。
2.3 实时 ETL- 资金流水场景
此场景次要满足业务人员在收盘期间疾速查问客户某个时间段内的交易流水明细数据。它须要解决三个问题：
- 第一，资金流水明细，总共几十亿的数据，数据量很大的状况下，如何做到疾速查问？
- 第二，收盘工夫内满足业务人员查问，且非收盘工夫内数据量较小，是否采纳定时调度？
- 第三，资金流水肯定不能出错，如何保证数据的准确性？
针对数据量大的特点，咱们最终抉择通过 Hbase 组件来存储数据，通过正当设计 rowkey 与建设 region 分区，达到疾速查问指定时间段内的资金流水明细状况；针对非收盘工夫内交易数据量很小的特点，开启工作的定时启停策略，将更多的资源留给夜间跑批工作；针对数据准确性要求高的特点，通过离线数据修改的办法来达到准确性的要求。
三、金融资讯实时化革新
在金融畛域每天有着各种新闻布告等这些每个市场参与方最常浏览和关注的资讯。咱们公司对资讯的定义不仅蕴含上述这些传统意义下的资讯，思考到数据自身的庞杂多样及收集、治理、利用等理论流转过程，咱们对资讯做了从新定义，即所有的非用户非交易相干的数据均为金融资讯领域。
咱们核心汇聚了如下 4 大类金融资讯数据，最常见的就是新闻、布告、研报，此外还有交易市场相干的货币、股票、债券、基金、衍生品等证券市场数据和各个维度的宏观行业数据，最初一类是无所不包作为兜底的其余及衍生，涵盖了各种基于市场原始数据进行剖析的其余第三方机构剖析的数据，比方公司舆情、基本面剖析预测等。
如果把交易和用户比作金融市场的骨骼和经络的话，资讯数据就是咱们金融市场的血液，产自前者贯通全身且源源不断。
那么品类庞杂的资讯数据具体如何流动？很简略，如图所示的三层构造：最底层是咱们引入的数据源，目前大多数资讯数据曾经被 Wind、同花顺等资讯数据商收集整理，咱们不须要破费太多的工夫老本即可取得种种根底数据。
但随着引入数据商的增多，问题也随之而来。假如某个数据商出了问题导致单干不能持续，数据服务也必定会受到影响。为了解决这个问题，咱们推出了核心库的概念，自建了一套金融数据模型，上游零碎都和核心库的数据结构对接，咱们负责把资讯数据商屏蔽掉，这就是图中的第二层。
上图最右侧还有一个小模块叫数据直发，因为理论利用中并不是所有的上游零碎都适宜对接，有些仍然依赖原始的数据商构造，所以这个小接口仍然存在，和核心库并行独特输入数据服务。
最上层是服务对象，笼罩了公司外部的各个业务线，继续为各个业务零碎输血。
在三层的整体架构下，日益增多的数据源还有数据品种晋升了咱们数据服务的整体品质，有能力服务更多的客户。同时核心库为外围的架构，进步了整体服务的抗危险能力，防备危险是金融公司重中之重的事。
咱们后期的工作次要集中在这两点上，当这两个性能缓缓欠缺且稳固后，关注点逐步转移到资讯数据传输和资讯内容优化上。市场瞬息万变，数据在链路上流传耗时越短，资讯在工夫上的价值越高，传输速度没有下限、越快越好，这就是数据传输效率。然而，数据快了而上游数据商的品质参差不齐，服务只快不准，提供给用户的数据存在问题，那么如何在不损失 1、2、3 点的状况下，把控数据内容品质也成了辣手问题。
为了优化 3、4 两个点，咱们以 Flink 引擎为外围进行了架构革新，选取了两个场景进行分享。
3.1 蜻蜓点金 APP F10 新闻场景
蜻蜓点金 APP 次要提供金融资讯，数据服务给宽广的投资者浏览。上图是第一版计划，次要流程为从上游的标签零碎为新闻打标，流入到 Kafka 中，进而进入刚刚所设计的核心库，上游应用时将数据进行抽取转化，传输到接口库，最终通过 API 对外提供服务。
为了及时获取数据库的变动状况，咱们在泛滥的 CDC 工 具中选取了部署轻量、集成不便的 Canal 来施行。通过捕捉数据库的变更，开发人员编写程序实时读取订阅 Canal 数据，将数据解析组合为业务所需的数据格式，而后被动更新写入到最上方的 Redis 中。上游用户在应用相干接口时，就能够取得最新的资讯数据，无需再期待数据被动过期。
计划一运行一段时间之后咱们发现两个问题，一是链路偏长，会损失时效性；二是被动写缓存过程逐步成为整个资讯服务的重要一环。但 Canal 作为开源工具，性能还在不断完善中，如程序监控、告警等须要独自开发实现，此外稳定性和高可用方面也略显有余。
为此咱们引入 Flink 对数据链路和数据处理环节做了调整。数据处理方面，利用 Flink 高效的 ETL 能力，引入了高时效性要求的资讯数据处理场景，同时 Flink 作为流式计算引擎，人造和 Kafka 集成，能够无缝对接，具备间接输入音讯到 Kafka 能力的零碎，如新闻标签零碎。社区始终在欠缺各种 connector，像 CDC 形式就为 Flink ETL 能力提供更大的空间。同时 Redis sink 的反对也使得原有的缓存程序、业务逻辑能够整合到 Flink 中对立实现。最终使整个资讯数据处理过程失去了集中管理，缩短链路，节约了传输工夫。
弱小的 ETL 能力升高了架构的复杂度，节约了原有的一系列组件。从整体来看，分布式高可用的架构贯通了上中下游，使得资讯服务能力能够稳固高效地输入。从久远来看，资讯数据利用宽泛，起源和输入多样，Flink 不断丰富的连接器也能够反对数据源和目标端的进一步扩大，为资讯数据能够应酬更多的场景带来可能。
3.2 多源数据穿插测验场景
如果能用一套架构解决所有问题那是再好不过的，为此咱们在多源数据穿插测验的场景上做了尝试。这个场景次要为了解决把控数据内容品质的问题。数据更快，能够通过技术手段得带解决，然而数据更准就不是咱们处在中间环节所能左右的了。
上游依赖诸多的数据商，数据商可能是爬虫采集、人工录入、数据接管等形式失去数据，多样的数据品种和多样的环节导致了咱们接管到的数据品质参差不齐，而且问题还会间接传导到上游并逐级放大。而咱们因为离源头较远，不可能跨过数据商来提供精确的数据服务，只能退而求其次变成了提供及时的纠错服务。
市面上的数据商竞争强烈，同一份数据你有我也有，所以咱们是十分侥幸的，大多数的根底数据咱们都能够失去多份，这就为数据差别的发现带来可能，通过对多源数据进行穿插测验，获取差别数据，及时揭示并纠错。
在整个服务链路中，越早发现问题，它所造成的影响就越低。那么，如何更早地发现问题？分为以下三步：
- 第一步是 ID 拉齐，金融市场的股票大家都理解，交易规范、编码标准、一码贯通所有数据，然而更多的债和基并不如股票规范，数据商往往会针对金融实体设计内码，在数据商外部部分惟一，所以如果想做穿插测验，首先就要解决 ID 拉齐的问题，这是个体力活。
- 第二步是指标化，数据校验的需要往往是具体的，比方校验每日的股票收盘价这种。然而数据商针对校验点的数据结构往往差别较大，因而通过指标化，利用 Flink SQL 编写针对多源库的指标生成逻辑，将异构的数据结构拉齐。
- 第三步，实时校验窗口。开始想法比较简单，运行脚本再定期取数一比就能够了。然而随着指标校验需要的增多，数据量的增长，跑批的脚本解决能力略显乏力。所以利用 Flink 的窗口个性，咱们开发了用于校验的实时校验窗口，聚合所须要校验的指标，在工夫和数量维度上触发校验窗口计算，后果输入到 Kafka，能够反对音讯的实时推送。
Flink 中反对两种窗口，一种是基于工夫的窗口，另一种是基于数量的窗口。如果在工夫和数量两个维度上均要加以控制，应用全局窗口加触发器就能够实现多样的用户自定义窗口调配。图中放了几行伪代码，在全局窗口上，触发器别离在元素来的时候和定时器到的时候加以判断。
在校验窗口里，利用 maxcount 判断多元指标数据是否都已达到，达到则触发窗口函数，并比照指标值；如果某数据传输呈现问题，对应指标值未达到，则须要在工夫维度上加以控制，定义窗口的最大持续时间，到时就不再期待，间接触发窗口函数，并将对应的数据源指标定义为提早达到，最终的后果输入如右上表格。技术和业务人员均能够根据这份校验后果及时应答，最终实现绕路晋升数据服务的准确性。差别的及时发现和解决，使得对上游的影响降到最低。
Flink 在金融行业的利用，置信还有更多的场景值得摸索。搭上开源社区这班慢车，让咱们券商的金融资讯服务能够失去质的晋升。
四、将来瞻望
最初分享一些实时流解决方面的将来瞻望，蕴含正在沟通的一些场景和流批一体方向的摸索。
需要沟通中的场景分为以下几个方面：
- 账户资产，包含实时资产持仓指标统计，客户交易盈亏、交易记录的剖析；
- 营销常识，包含 mot 散失客户揭示与召回、开户未胜利客户揭示与跟踪、两融业务潜在新客户的开掘、电商 APP 流动的内容与内容经营；
- 风控，蕴含以客户维度的持仓集中度指标，以公司维度的融资额度占公司净资本等指标的剖析统计。
另一方面咱们项目组正在调研 OLAP 多维分析组件，因为目前实时开发依然采纳 Lambda 架构，后果表存储组件波及到关系型数据库比方 MySQL、SQL server、oracle 以及 NoSQL 数据库比方 HBase、ES、Redis。数据孤岛是目前面临的重大问题，心愿通过 OLAP 组件实现实时数据的与离线数据的对立写入，实现流批一体，突破目前数据孤岛的场面，心愿在流批一体存储层达到对立存储、对立对外服务、对立剖析解决的目标。
点击查看直播回放 & 演讲 PDF
更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～