一、平台建设业务目标
中原银行敏捷 BI 平台的建设目标为满足不同人群对数据查询、分析和探索的需求，为管理和业务提供数据依赖和决策支撑。
1、核心诉求：满足不同人群对数据的需求
不同的企业对于 BI 是有不同的诉求的。中原银行对 BI 的诉求，是满足行内不同人群对数据查询、分析和探索的需求，从而为管理和业务提供数据依赖和决策支撑。
主要是针对三类人群：
（1）第一类是管理决策层。让管理决策层能够看到准确、实时的数据，并依据数据去进行科学的决策。
（2）第二类是普通业务人员。比如针对业务数据统计，业务人员会在业务运营过程中涉及一些比如手工报表、人工统计、逐级取数等操作，使用 BI 平台可以提升他们的日常数据统计效率，让业务更多关注业务问题本身。
（3）第三类是技术人员或分析人员。通过打通各个业务系统，提供统一的查询服务，提升这类人员的日常数据分析效率。
这是我们对 BI 的整体诉求，依据这个业务目标，我们建设了 BI 平台。
2、中原银行 BI 建设历程
中原银行在 2019 年之前，使用的是采购的第三方报表系统。业务人员也已经养成看报表的习惯，现在整个行内有上千张报表，业务人员每天都会查询这些报表数据。
从 2019 年开始，为了实现之前提到的业务目标，中原银行开始建设整个的敏捷 BI 体系。
2019 年，把数据取数从线下转为线上，提升安全提数效率。可以满足一些比如日常的监管报送，或者领导临时的数据需求，并提升操作效率。
2020 年，针对业务人员提升数据统计的效率。开始建设智能拼表，低代码加工和可视化分析工具，可以让业务人员在无需借助比如 SQL 加工的方式下可以完成数据的加工。这里补充一下，智能拼表是结合中原银行的业务特点，允许业务通过低代码的方式进行报表拼接。
2021 年，为了提升 IT 人员或者技术人员的分析效率，构建了我们自己的报表系统，数据大屏等。
2022 年，构建了我们自己的业务指标库和数据门户。
以上是我们整个 BI 平台的建设历程，逐步完善整个 BI 体系。
二、敏捷 BI 平台建设
敏捷 BI 平台覆盖数据分析全流程，提供一站式、全链路数据分析解决方案。下面来介绍我们整个 BI 平台的整体概览。
1、中原银行敏捷 BI 平台架构
上图是整体平台架构。
自下而上来介绍，最下面是接入数据：
（1）数据库，包括关系型数据库如业务数据库、大数据集群和数仓等。
（2）业务人员收集或者填报的数据。
（3）第三方业务系统暴露出来的 API 接口。
（4）本地文件数据的导入。
然后基于这些数据，我们会一站式提供 8 个核心功能，包括：
（1）固定报表开发。
（2）低代码数据加工。用于支撑数据统计人员的工作。
（3）SQL 数据分析。用于支撑于技术人员和数据分析人员的工作。
（4）可视化分析。可以以更直观的低代码方式进行数据分析，展示数据结果。
（5）数据分发补录。用于本地数据线上化、数据分发确认。
（6）业务指标管理。是我们的指标库，建设构建唯一确定的没有二元性的指标，供业务日常的查询使用。
（7）个性化门户。是为了统一数据出口，把报表可视化看板以及大屏统一输出在一个门户中，供业务人员日常查询使用。
（8）数据下载。提供线上化的数据下载，简化下载流程。
基于这 8 个功能，我们构建了 6 个核心的数据应用，包括固定报表、数据大屏、可视化看板，安全提数、指标库以及数据门户，针对不同的人员提供不同的数据应用，基于这些应用进行能力输出，给业务使用。
在业务应用场景方面，包括管理驾驶舱、营销效果分析、业绩考核监测、日常数据通报、系统监测分析以及业务风险预警。
2、数据分析全流程覆盖
上图可以更好的帮助我们理解前面介绍的平台架构，把 8 个核心功能分布到数据分析的 4 个流程内，支撑数据分析的全流程覆盖。
我们把数据分析的流程归结为以下 4 部分：
（1）数据准备。平台支持多种数据来源，包括业务数据库、核心数据库、数仓内的数据库、数据湖内数据库、本地数据库以及用户收集的数据。
（2）数据加工。平台可以提供两种数据加工方式：一种是低代码拖拉拽的方式，集成常规的数据加工方式，供业务人员进行低代码加工；第二种是针对专业分析人员进行 SQL 的数据加工。
（3）数据分析。数据分析也可以归结为两类：一种是固定式的报表分析，基于报表平台所创建出来的报表；另一种是业务自助式的分析，可以基于看板或者是大屏，进行筛选、关联、跳转以及数据的上卷下钻等等。
（4）数据应用。我们提供多种的数据应用方式，包括数据大屏、数据看板、固定报表以及数据门户集成，所有数据应用的结果都可以进行预览、下载、分享等。
3、固定报表开发
下面具体介绍几个核心的功能。首先介绍固定报表的开发。
之前我们购买的第三方报表平台，使用中会存在一些问题：一个是平台架构比较老，查询性能上经常会出现 CPU 或者内存不足的情况；第二个是我们会有一些个性化的改造，这种改造通常需要一两个月才能开发完成，不仅成本非常高，而且需要进行排期。
针对以上几个问题，我们规划开发我们自己的报表平台，供业务日常查询使用。主要是做一些中国式的复杂报表，包括一些非常复杂的表头等等。
我们把报表制作分为 5 个步骤：
（1）数据源。就是我们能够连接到的数据源，比如常规的 Oracle、MySQL，还有我们的大数据集群使用的 Gauss，以及 StarRocks、ClickHouse 等。
（2）数据加工。通过 SQL 进行数据加工，这里强调一点，在 SQL 数据集中不会有太多复杂的 SQL，因为大部分逻辑已经是在数仓内通过跑批任务完成了，在报表里面更多的是查询已有的数据，我们使用专属的独立集群提升查询效率。
（3）报表制作。我们把报表归结为 4 类：第一类是即席查询类，就是 SQL 数据集里面加工的逻辑直接动态查询；第二类是类透视表，类似 Excel 中的透视分析，通过选择行列和指标进行维度的组合筛选；第三类是 Excel 表格，专门去制作一些复杂表头，或者是带 Excel 公式的电子表格类报表；第四类是刚实现的可视化类报表，当前常规的表格展示不能直观有效地表现数据的结果，因此我们引入一些图形化的比如折线图、条形图等做一些可视化报表。
（4）报表发布。第一，由于行内对数据安全的严格管控，需要进行数据脱敏，否则是不能进行正常的报表发布的；第二，安全审批，需要走一个报表发布的流程；第三，报表版本管理，报表有两个版本，一个是制作的版本，一个是线上的版本，制作的版本只有通过发布审批之后才会把线上的版本覆盖掉。
（5）业务应用。我们行内把报表归结为 4 大类：对公类、零售类、财务类和绩效类。在这里会进行报表的知识库构建，比如报表目录管理，报表技术及业务口径维护，报表关键字搜索等等。
4、低代码数据加工
低代码数据加工的建设，针对的是普通业务人员，为了简化数据统计分析的难度，平台通过集成常见的加工方式，让他们可以通过低代码的方式进行常规的数据加工。
我们集成了 10 种数据加工方式，比如字段设置、分类汇总、数据筛选、新增字段（基于已有的字段进行加减乘除运算）、数据排序、透视分析、查找替换、列转行，这些是比较好理解的。还有上下合并和左右合并，是为了在低代码方式下合并两张表，一种是上下合并，一种是左右合并，类似于 Left Join 的方式。
通过集成这 10 种加工方式，业务进行数据加工的过程中，他可以按需选择其中几种加工方式。我们在代码实践过程中，通过 Pipeline 管道模式组合，生成最终的 SQL 逻辑，以完成低代码的数据加工。
5、可视化能力：数据大屏及可视化看板
在可视化方面的建设，包括数据大屏、可视化看板等等，通过一些拖拉拽的方式去快速制作图表，帮助业务快速分析和洞察业务的趋势。
这部分很好理解，最开始的是数据来源；然后数据加工有两种方式，一种是专业人员的 SQL 数据加工，还有一种是低代码通过拖拉拽的方式去进行数据的基础加工；然后根据这些基础数据去进行数据图表的制作，我们支持 Echarts、AntV 这种常规的图表组件，还支持图表属性的自定义设置，后面会涉及到一些比如指标计算和数据下钻；图表制作完成之后，就会涉及到图表组合，支持可视化拖拉的方式去进行图表的组合，最终制作出来的大屏和可视化看板是支持结果分享、多端查看以及支持单 URL 访问嵌入等，最终支撑我们的可视化能力。
这部分我们是站在巨人肩膀上，也就是基于开源，再加上我们自己的个性化改造实现的。这些个性化改造，包括数据源的对接，图形组件的自定义等。业务在图表制作过程中，如果常规图表不能满足需求，会提需求让 BI 平台开发比较个性化的图表组件。
6、交互式 SQL 分析及安全提数
下面是安全提数的建设，为了规范数据下载流程，不会让数据轻易流出，需要在保证数据安全的前提下，促进数据的使用和价值释放。
我们在平台里面做了三个步骤的控制：
（1）事前预防。制定取数规范，进行安全宣导、事件通报等等。
（2）事中干预。进入平台之后，同样会进行干预，一部分是对表权限的控制，表权限的申请审批，书写 SQL 的规范评分等；还有一部分是对敏感数据的脱敏以及过滤。
（3）事后审计。包括日常用户的操作日志记录、风险的上报以及事后的安全审计等等。
7、数据门户
数据门户作为最终统一结果输出的地方，把报表、可视化看板，数据大屏以及第三方页面集成组合到一起。个人可以设置个人的数据门户，满足千人千面的个性化看数需求，获得清晰、直观、美观且沉浸式的看数体验。
8、指标库建设
第八个是指标库的建设，我们把它归结为 4 个步骤：
（1）指标梳理。自顶向下构建指标体系。
（2）指标整合。整合是按照数仓的星型模型构建的，构建我们的业务指标宽表。
（3）指标上架。在我们平台上进行指标上架后，业务能够正常的去查询，查看这些指标的口径。
（4）指标应用。结合自助低代码方式和可视化分析能力去满足业务后续的分析需求。比如借助低代码能力，可以进行基于指标表的自助加工；借助可视化能力，可以制作基于指标表的可视化分析。
三、业务场景支撑
上面主要介绍了平台整体架构以及核心能力，接下来将介绍一些具体使用场景，也就是业务人员或者数据分析人员在平台上做了一些什么工作。
1、数据分析场景全覆盖
我们把数据分析的场景归结为 4 大类：
（1）第一类个人自助分析。个人会有一些日常的数据查询需求，比如报表查询、数据统计，数据临时下载等等。
（2）第二类赋能业务系统。就是支撑业务系统对接集成，把我们的可视化能力，报表能力输出给业务系统集成，支撑他们去集成我们的可视化能力，降低他们的开发成本。
（3）第三类专题分析。针对于某一问题或者是某一措施之后的专项分析，评价其好坏，比如常规的营销效果分析，就是一类专题分析。
（4）第四类管理驾驶舱。是使用比较多的一个场景，做出一些看板报表，供领导管理层基于数据的科学决策。
2、个人自助统计分析
下面看一下 4 个场景里面的具体内容，比如在个人自助统计分析里面，我们将其归结为 4 类：
（1）报表、大屏及看板的日常查询。常规需求，大部分人员就是为了看数据，只有少部数据分析人员才会真正的去制作这些报表。
（2）业务日常通报、业绩考核。这是涉及到业务类的，之前是通过线下 Excel 的方式去进行汇总加工出来，然后每天都要繁琐的去做这项工作，现在通过我们平台就可以一次制作自动更新，免除他们日常繁琐的数据统计工作。
（3）总行支行数据上报。就是由总行下发任务，让分支行的人员进行数据的填报，之前是通过邮件的方式，一层层总行发给分行，分行发给支行，支行再发到对应的业务经理，流程是比较繁琐的。
（4）数据分析及临时提数。针对一些数据的分析人员，要去写 SQL 去进行日常查询，还有一部分是会涉及到一些临时的提数等等，这个是个人的数据统计。
3、业务系统集成
我们的研发效能洞察平台，就是通过集成我们的可视化能力去展示决策视图或者度量报告，算是我们平台能力的输出。这样一些业务平台就不需要另外去开发类似的可视化功能了。
4、场景化的专题分析
对于场景化的专题分析，针对某一问题或者是某一举措后的专题分析。以银行某一产品为例，从经营现状、资产质量、还款结构、转化流程以及渠道来源等去进行各个角度的分析展示。
5、可视化大屏
可视化大屏，我们需要在一些比如业务风险会议或者是业务监控里面会有大屏的展示。这里有两个例子，风险疫情大屏以及会计运营大屏，能够挂到某一个地方，领导或者同事能够日常的进行一些数据的查询。
6、实时 BI 解决方案
接下来介绍的是一个解决方案，是针对实时 BI 的解决方案。
它是有对应的业务需求的，比如我们的管理驾驶舱，营销效果分析以及风险预警等等，这些对实时数据是有比较强的诉求的。他们之前数据都是 T+1 的数据，这对预警场景来说已经是比较落伍了，T+1 的数据已经对于该场景已经没有什么效果了，所以我们会依据这些场景去构建实时 BI 的解决方案。
常规的数据源发送消息到消息队列 Kafka 里面，然后 Kafka 将消息发送到计算引擎 Flink 里面，Flink 把计算后的结果写到我们的存储引擎 StarRocks中。不同的业务场景可以使用不同的存储引擎，我们全部使用的是 StarRocks。同时 StarRocks 作为我们 OLAP 引擎作为后续的 BI 的一个查询引擎，比如我们的实时报表、实时大屏和实时看板，实现对数据的秒级实时分析，这是我们的实时大屏解决方案。
7、智能问答机器人
智能问答机器人是我们在智能化方面的一个建设。
整个流程就是用户在平台上提出问题后，后台在问答知识库进行匹配，如果匹配上的话直接会给出答案，如果没有匹配上就会有经过相似度模型跟其他的问答去进行匹配，看是否是相似的问题，通过阈值判断，如果超过阈值，就认为它们是相似的问题，就可以返回相应的答案，如果没有，会经过 NL2SQL 模型去构建对应的查询 SQL 给出相应的结果。
这个是我们在智能化方面的一个建设，不过目前因为数据量比较少，只能针对于单个固定式的那种场景去进行查询，是我们的一个尝试和探索。
四、未来展望
最后一部分是我们平台的未来展望。
1、正在做的
我们目前正在做的工作可以归结为四大部分：
（1）第一部分是完善我们自身平台能力，整个 BI 的功能完善。
（2）第二部分是平台的推广运营。酒香也怕巷子深，很多人是不了解平台工具能够做什么事情的。目前我们平台大概有上千人使用，月活也有上千人，我们后续会更大量地推广介绍我们的平台。
（3）第三部分是用户使用的平滑过渡。这里指的是传统 BI 到敏捷 BI 的一个过渡。更低的学习成本、更顺手的操作流程。
（4）第四部分是数据分析思维培养。不像互联网公司，所有的银行应该都会有这样的现状，分析还是依靠专业分析人员，在中原银行是依靠数据建模师。业务人员更多的是做一些数据统计上的工作，不会具体去分析这个现象为什么会产生、这个问题为什么会出现以及我需要怎么去做。这就需要我们进行一些数据分析的思维的培养，也是我们正在做的一个工作。
2、未来努力方向
未来努力的方向有两个方面：
（1）第一个是平台的智能化建设。通过融合 AI、NLP、模型算法等技术去简化用户的分析的难度。比如我们智能问答的尝试；后续会做一些智能洞察分析，是通过平台去自动发现问题，定位问题；另外是自动可视化，比如发现问题之后，怎么通过可视化展示这些问题，让用户可以看到这些问题，这是我们未来在智能化方面要探索的内容。
（2）第二个是平台的开放化建设。把我们的能力进行输出。我们的可视化能力，是每个平台都会有的一个需求，我们后续会慢慢的开放我们的 SDK，我们的 API 以及我们的页面嵌入能力，能够去支撑更多的业务场景。
五、问答环节
Q1：数据下载审批，审批流程有分不同的重要等级，走不同的审批流程吗？有的话等级是怎么标准？
A1：这个等级我们在数据资产中会有标记，把数据划分为 4 个等级，三四级是最高的。如果涉及到三四级数据的时候，敏感程度比较高，会涉及相应领导和安全人员的审批，如果涉及普通的一二级数据，只需要对应的表 Owner 审批就可以了。
Q2：整套系统里面是外采还是自营的，分别是哪些部分是外采，哪些是自营的？
A2：这个就是刚才讲的第一页的内容，我们 BI 系统的建设历程。我们从 2019 年开始研发自己的整个 BI 体系，现在所有这里面的东西都是我们自主研发的，涉及的 8 个核心功能都是我们自己在做的。
报表平台是外采的，现在还在用，但是现在我们有自己的报表平台了，后续也会慢慢的会弃用掉外采平台。
Q3：为什么不用 ClickHouse 或者 Doris 做多维分析工具？
A3：我们选用 StarRocks 也是多个团队一起合作的，涉及到一些跑批集群也会用，比如我们的数据开发、数据中台也会用；我们的报表涉及的主要是查询，所以他们会综合考虑到查询性能以及跑批写入的性能，以及我们对实时 BI 的需求。基于有这几点的考虑，所以最终选择是 StarRocks。还有一点就是，StarRocks 不需要自研或者外采，不用花太多的钱。
Q4：关于人才建设，是一个什么样的大致规划？
A4：行里面对整个科技是投入比较高的，采用的是行员 + 厂商协同开发的模式。
Q5：低代码后台实际还是 SQL 数据集吗？
A5：我们低代码去实现的功能，跟常规的那种拖拉生成表格还不一样，我们这种是针对数据加工分析而做的，常规的你需要写 SQL 去进行加工，但是我们对低代码的一个定位，是用户进行拖拉拽，我们平台去生成对应的 SQL。
Q6：低代码平台使用的场景是不是比较有限？
A6：低代码平台，我们的定位就是数据分析，我们不会涉及到比如常规的生成表格或者是生成业务表单等功能。我们只针对分析场景，针对性的把业务常用的几种加工方式集成进来，然后业务肯定是需要这些功能去做数据加工的。
