全文约9969字，阅读约58分钟
尊敬的各位来宾，大家下午好，我是东方国信资深数据架构师陈志刚，非常荣幸在此与大家共同探讨“金融数据库自主可控之路”这个专题。
我今天分五个主题进行介绍：
首先介绍金融企业的用数场景演进与当前的迫切用数需求梳理；
然后基于企业的用数场景探讨数据技术的演进趋势和关键的数据技术环节；
进而通过用数场景和数据技术双轮驱动了企业管理模式的优化，探讨金融企业数字化转型中的数据驱动和决策支持；
随后，通过企业管理模式的优化引导了业务模式的优化，探讨企业数据核心的形成和未来演进趋势；
最后分享一下东方国信CirroData在企业的数据核心一体化演进中的最佳实践和经验积累。
我们首先看用户的用数场景演进和用数需求。
如图所示，金融企业的数据需求最早为各个业务条线的专题报表，即首先解决各个业务部门出报表的问题，之后随着业务水平提升，需要基于条线数据的灵活查询和灵活报表，面向管理层需要管理驾驶舱。
之后，逐步有了面向全行数据的数据需求，包括针对贴源数据即原始业务数据的自助查询，针对数据仓库的自助分析。在做报表的过程中会涉及指标处理，但基本都是面向条线或者业务板块的，是局部的，由于存在口径的差别和大量重复工作，因此提出了全行统一指标体系，进而有了统一报表体系和统一标签体系，在此基础上又有了统一数据资产管理的需求。
再之后是对数据的深度应用，提出了数据实验室，能够面向全行提供数据挖掘的支持能力。随后有了数据服务的需求，即基于全行数据提供统一的标准化的数据服务，统一数据口径，前面的需求是面向用数人员的，而数据服务是面向系统的。最后有了数据服务和数据功能整合的需求，对数据应用进行统一管理，即数据门户。
从使用者角度来看，这些数据需求对应的是不同的用数群体，从下往上分别为各个业务部门的基层人员、管理人员、企业领导层、专业的分析团队、数据管理团队、数据挖掘团队、数据治理团队和数据服务团队等，现在各个银行都在建设独立的数据治理部门、数字银行部、数据服务部、数据挖掘部等，不同银行会根据自己不同的侧重点进行不同的组合。
从用户角度，可以将用数需求进一步细化，如下图所示：
结合这些需求，针对不同规模的企业，如大型、中型、小型，针对不同地域的企业，如东部沿海、中部和内陆，用数需求又会有所不同，各有不同的侧重点。
对于用数需求，有一个非常典型的场景对比，如下图所示：
左边是业务场景，包括核心系统、信贷系统、中间业务系统等在内的产生数据的系统，其典型特点是未操作，并发高、每次操作数据量小，侧重与增删改操作，属于A类系统，数据安全、系统稳定、高可用要求高。
右边是分析场景，包括数据仓库、数据集市、经营分析、监管报送、绩效考核、风控等系统，其典型特点是批量操作，并发没有那么高，但每次操作涉及数据量大，侧重于一写多用，即批量处理生成数据，然后对数据进行各类查询分析，一般为B类或C类系统，系统要求相对要低一些，当然只是目前的局面。
这两类典型的场景也就是典型的TP场景和AP场景，应区别对待，这样性价比会更高。
下面我们进行第二个专题，对数据技术演进趋势和关键技术进行探讨。
本次主要探讨目前比较关注的7个技术，如下图所示：
即数据库，这是核心技术，然后是湖仓一体、数据底座、数据开发平台、数据治理、数据灾备方案和数据门户。
一、数据库
如图所示：
数据库技术已经发展了几十年，详细过程很复杂，不过我们结合企业近二、三十年实际应用情况来看，主要可以分为两个阶段，即SMP架构阶段和MPP架构阶段。
SMP架构下依赖单机服务器性能，后来遇到瓶颈后使用集群部署，但此架构的集群扩展能力较弱，典型的是Oracle RAC。
后来MPP架构数据库发展起来，MPP数据库可以分为三个阶段：
第一个阶段是传统MPP，典型的代表是TD、GP等，其最大特点是ShareNoing，所有节点参与运算，扩展需要数据均衡、停服务；
第二个阶段是存算分离，其典型的特点是数据存储采用分布式文件系统，采用计算与存储分离、动态计算、动态存储，在并发能力、扩展能力、持续服务能力方面都克服了传统MPP的缺点；
第三个阶段是多引擎阶段，即多引擎并行，基础引擎解决数据库的基础能力，对于特定场景使用专用引擎处理，如基于内存计算、向量计算等解决高速查询场景、高并发查询场景等。但各个引擎对外透明，可基于统一界面进行使用，并进行统一管理。
这是新一代数据库，将成为企业级数据平台的基础产品，如下图所示：
即在企业里面，基于统一的分布式存储，包括采用分布式文件系统或者对象存储，只是目前对象存储的性能还不如分布式文件系统，或者说高性能对象存储代价还比较高。
基于统一的分布式存储，采用新一代数据库进行结构化数据的统一存储、处理和服务，而Hadoop生态将成为新一代MPP数据库的有力补充，即整个企业级数据平台底层基于分布式文件系统，基础储算能力基于新一代MPP数据库实现，Hadoop生态解决特定场景处理，处理方式为将MPP中的数据取出，处理后，将处理结果存到MPP数据库中，供全企业使用。
随着新技术被逐步纳入MPP数据库中，开发更规范，标准更统一，平台更完善。但新的处理需求又会持续引入新的Hadoop生态产品，从而形成了MPP为主+Hadoop生态为辅的良性发展态势。
数据库的HTAP能力还是一个不可规避的问题，但就当前的技术而言，实现难度要求是很高的，即使说某个产品具备了HTAP功能，一般来讲其TP能力可能不如专业的TP数据库，其AP能力可能不如专业的AP数据库。也就是说HTAP还在路上，就企业应用而言，远水不解近渴。
换个角度看，HTAP场景确实越来越多，不过相比之下，单纯的TP场景和单纯的AP场景更多一些，以金融行业为例，AP和TP的场景差别还是比较大的，AP与TP共存且都看重的场景并没有想象的那么多。因此，在目前没有真正的HTAP数据库的情况下，对AP和TP问题可以考虑分别解决，这样会更容易一些。
从目前情况看，HTAP很有可能会形成“TP为主、AP为辅”或“AP为主、TP为辅”两个方向，即分别解决现有TP系统中的AP问题、或AP系统中的TP问题。短期内，把TP和AP都做好有难度，但以一个为主一个为辅要容易的多，这也是目前很多数据库的做法。
正是这个原因，未来HTAP可能会出现组合，即某个AP数据库和某个TP数据库组合使用，可以是一个公司的两个产品，也可以是两个不同公司的产品，这进一步可能会推动研发团队的整合，包括收购或战略联盟。
在AP数据库和TP数据库进行组合时，核心点是数据同步，可以是TP给AP推送数据同步，也可以是AP从TP拉取数据库同步，相比之下，前者代价更小一些，即TP库将数据实时同步给TP，或者存储到特定格式的副本中，AP库可以直接读取，从而实现数据的实时同步。
下面再说一下企业级数据库和应用级数据库。企业级数据库是可以承载全企业数据底座的数据库，至少具备如下特点：
数据落地（对比内存数据库）
SQL支持好，复合场景支持好
兼容传统数据开发，如存储过程等
运行稳定（宕机情况少）
数据共享（避免大量重复存储和交换）
运维体系完整（安装、监控、维护）
数据安全和数据管控能力强
完整的周边工具和落地方案
应用级数据库例如ClickHouse、ES、Doris、Kylin等，在一定场景下其特点特别突出，但又存在明显的缺点，可以解决一类场景问题，但不足以解决企业级各类场景，并在安全、运维、统一开发等方面提供完整的成熟功能。当然，如果这些产品具备了企业级数据库的综合能力也是可以成为企业级数据库的。对于一个企业级数据库，应至少具备如下能力：
目前对于数据库的功能有蔓延趋势，有些功能不应纳入数据库功能，对此，希望数据库的功能还是要聚焦一下，探讨如下：
数据库的调度功能：此功能一般有独立调度系统实现，也会更为灵活，放在数据库中不是太合适；
列权限控制、行权限控制：此类功能在应用中实现更为简单和灵活；
数据核对，出具核对报告：同样也是在应用中实现会更为简单和灵活；
个性化很强的功能。
总之，数据库应专注于解决数据库通用性强的功能，专业的功能让专业的工具解决，数据库能够对接好即可，数据库在应用层面做的太多会顾此失彼，偏离重心。这只是个人见解，抛砖引玉，大家见仁见智。
最后要说一句的是，国产数据库都还在路上，企业在选型时应侧重最适合自身，可以从如下层面进行考察：
二、湖仓一体
湖仓一体经历了多个阶段，最早是数据湖，即DataLake，只存储原始数据，其他数据均通过原始数据计算得出，通过强大的计算能力解决各类数据需求问题。
但这种情况不适合企业，对于企业的数据需求是远远不能满足的，因此提出了LakeHouse，即湖仓一体，数据湖与数据仓库进行结合，湖仓一体实际也演进了几个阶段：
第一个阶段，存储原始数据和全局统一加工数据，提供统一数据服务。
第二个阶段，增加条线统一数据（仓内集市）和历史存储，扩展数据服务范围，强调数据共享，一存多用。
第三个阶段，进一步扩充湖仓范围，增加实时数据接入和处理，增加面向查询的缓存数据存储，增加湖、仓、集市等对外服务能力，增加统一数据服务，覆盖数据中台功能，实现基于湖仓一体的数据中台。
三、数据底座
数据底座的概念这也是最近几年提出来的，如下图所示：
最初，数据底座主要包括技术支撑平台、数据汇聚中心和数据储算中心，技术支撑中心包括容器、微服务、数据库及各类工具等，数据汇聚中心主要包括数据交换系统，数据存算中心包括数据湖、数据仓库、数据集市、实时处理系统、非结构化、历史库等。
随着数据底座的扩展，现在还包括了数据开发中心（含多个开发平台）、数据服务平台（含基础数据服务平台和指标系统、标签系统、报表系统、自主分析系统等多个专有服务平台）、数据资产管控中心（包含数据资产管理系统、数据治理系统、数据安全系统等）、数据总体管理中心（包含项目管理系统、流程管理系统、统一调度系统、运营管理系统等）、数据门户。
关于数据底座的技术选型建议如下：
数据底座是服务全企业的数据系统建设，是立足全企业的；
数据底座是相对稳定的，其稳定保证了上层应用的灵活多变，快速适应；
数据底座的稳定是需要团队保障的；
数据底座应追求性价比高且成熟的技术，尤其对于中小型企业；
数据底座的选型需要考虑学习成本、使用成本、升级成本、运维成本等综合成本；
企业在底座选型上求存更为重要。
四、数据开发平台
数据开发平台包括几种情况：
首先是批流一体开发平台，此类平台实现了实时流数据和微批数据的统一开发，但由于需要兼顾多种组件如kafka、flink、hbase、redis等，sql语法支持和功能有限，因此此开发平台与离线数据开发平台要独立。
接着是离线数据开发平台，一般离线数据开发会基于成熟的企业级MPP数据库，其对SQL支持比较强，一般至少支持标准SQL语法，并支持复杂逻辑，因此与批流一体开发平台区别，可支持更强大的开发功能，简化离线开发工作量，毕竟企业总95%以上是离线数据开发。
离线数据开发中还有一种基于配置的开发，这里需要对数据加工逻辑进行更高级的抽象和提炼，将加工处理逻辑分解为不同的处理模式，根据不同的处理模型形成不同的处理模板，数据开发人员在进行需求分析时填写Excel模板，然后基于模板自动生成处理程序（存储过程或者脚本），例如数据加载、拉链处理、快照加载、增量提取、交易汇总、账户汇总、客户汇总、机构汇总、汇率处理、日均加工、利率计算、指标加工、宽表整合等等。
随着大模型的流行，在数据开发中也可以引入大模型，目前至少在如下层面可以使用大模型技术：
智能推荐基于表的脚本
智能生成表关联
智能增加常用字段片段
智能生成表、字段描述
按模板批量生成
按模板增加特定处理逻辑
文字对话生成加工流程、控制操作流程
语音对话生成加工流程、控制操作流程
语法校验与自动补全
基于标准模板的智能操作等
五、数据治理
数据治理经历三个阶段：
第一个阶段为满足监管要求阶段，即解决数据治理平台有没有的问题，满足监管对数据治理的基础要求。
第二个阶段为数据治理独立建设阶段，即数据治理平台与湖仓一体大数据平台独立，仅通过数据提取实现元数据采集，数据治理平台无法起到对大数据平台的指导和辅助功能。
第三个阶段为数据治理平台与大数据平台一体化建设阶段，即数据治理平台建设团队本身就精通大数据平台建设，在完成数据治理平台的同时，能够为大数据平台建设提供指导和辅助，并体现在功能的互动上，即数据治理和大数据平台底层是想通的，大数据平台的元数据自动采集到数据治理平台并实时保鲜，能够第一时间发现大数据平台中的数据问题，并能够进行管控。
六、数据灾备方案
大数据平台的灾备与业务系统的灾备不同，对于业务系统而言都是小数据量操作，即每次的交易都是行级更新，涉及数据量比较小，尤其在合理的表分区设计下，表的变动更能集中在特定的数据块，这样可以以日志或者数据块进行实时同步。
但对于大数据平台来讲，其数据来自所有的业务系统，增量数据本身就比较大，比如对于大中型企业，每日增量数据会达到T级别甚至更多。而对于大数据平台的增量数据，后续会涉及临时层、贴源层、基础层、汇总层、各个集市层和各个数据应用系统层等多个层级的层层加工处理，原始数据至少会扩大3-5倍，再考虑存储层面的多副本存放，实际存储数据又会至少扩大3倍。
在这个情况下，如果要进行两个数据中心的数据实时同步，就会面临两个数据中心的带宽不足问题，或者需要花费很高的代价来满足带宽需求，否则正常带宽会被占光，进而影响正常业务的带宽需求。具体见下图：
如图中右边部分所示，数据的同步机制可以归结为四种：
以数据块为单位的底层数据同步：以数据库底层最小数据存放单元为单位进行双库数据同步，即识别新增和变化的存储单元，在其完成更新后进行同步操作。此方式优点是对外透明，缺点是同步数据量大，网络压力非常大；
基于底层数据操作日志的数据同步：记录基于数据的操作日志，同步日志，并基于日志进行同步操作。其优点是对外透明，缺点同样是同步数据量也很大（会比上一种少多副本的数据量），网络压力也很大；
基于SQL操作日志的数据同步：记录基于SQL的操作日志，然后基于SQL日志进行同步操作，需要结合数据导入导出操作，并保证操作顺序完全一致。优点是数据同步量最小，只需同步接口数据。缺点是需要与应用结合，且与主库不同，增加额外开发量，控制不够方便，需要通过数据校验工具保证数据一致性；
基于应用的双写数据同步：双库处理调度逻辑完全相同，基于同样接口数据进行双入处理，基于数据核对保证两边数据一致，如果出现数据不一致，以表或分区为单位进行数据同步覆盖。优点是数据同步量最小，只需同步接口数据；双库处理逻辑完全一致。其缺点是需要额外开发数据校验工具保证数据一致性。
对于大数据平台而言，最后一种是比较实用的，对带宽消耗最小，且能根据实际需求调度，达到对业务系统影响最小的目的。
下面讨论一下数据门户，如下图所示：
最底层为储算平台，之上是数据服务平台，数据服务包括平台级数据服务和应用级数据服务，平台级服务是自基于基础数据区的数据，即湖、仓、集市的公共数据提供的对外标准服务，面向全行或全企业的，应用级数据服务是指面向具体应用的专有数据服务。在平台级数据服务中会包括对平台级数据应用的特定数据服务封装，如包括报表平台、指标平台、数据分析平台、标签平台等企业级公共应用。
七、数据门户
企业级数据门户是将数据类应用尤其是数据展现应用整合，形成统一门户对外输出，便于全行或全企业的人员方便使用。
在数据门户中包括面向管理层的管理驾驶舱，对外发布的大屏展示，面向分析人员的自助探索分析，面向业务人员的分析报表、数据资产、统一指标、统一标签，还有面向全系统的通用搜索功能“一搜”等，以及系统管理功能。
在数据门户中引入互联网门户的频道管理概念，即面向不同类型功能使用不同频道，面向不同用户尤其是不同条线、不同板块的人员也可以使用专门频道，这样方便对全行级或企业级数据应用进行分门别类。
同时企业门户需要考虑日志记录、多版本管理、分流配置、限流熔断、多中心支持、风格管理、接入适配等多种能力，以适应全行或全企业的数据需求和数据应用接入。
下面说一下第三部分内容，数据驱动转型，即用数场景和数据技术双向驱动了企业管理模式的优化，探讨一下金融企业数字化转型中的数据驱动和决策支持。如下图所示：
湖仓建设解决了数据统一存储。基于对平台基础设施的监控如服务器、工具组件、任务、异常等解决了平台管控问题，保证了平台的稳定运行。基于数据治理尤其是大治理即把控数据标准、数据质量、数据资产、数据交换、元数据、数据安全、离线开发和批流一体开发等解决了数据有效管控的问题。进而通过数据服务平台包括基础数据服务和报表、指标、标签等专业数据服务解决了数据服务统一的问题。
在此基础上就可以实现或部分实现金融企业数字化转型中的数据驱动和决策支持，或者说是辅助决策支持，体现在如下四个层面：
数据的系统化展现：上述湖仓一体的数据平台实现了企业级数据的系统化展现，为全企业人员提供了统一用数、灵活用数、系统化用数的基础，未来业务人员的用数能力成为进入企业的入门能力；
数据服务全系统：基于完整数据建立起来的数据服务平台将服务于全企业的所有应用系统，基于统一的数据服务，这增强了应用系统的快速迭代、快速响应能力；
数据增强服务能力：即在数据类系统逐步完善的基础之上，可以面向全行或全企业提升综合的营销、考核、风控等条线的业务效率；
数据扩展业务范畴：即在数据服务能力提升基础之上，进而实现数据变现的能力，逐步产生了基于数据的业务能力，数据团队将逐步由成本中心转变为利润中心，首先体现在开源节流上，即一方面实现数据变现产生实际效益，一方面通过风险控制为企业规避不必要的损失。
下面说一下第四部分，数据核心的演进。如下图所示：
对于信息化程度高的企业将完成企业数字化转型的双引擎架构，即业务核心和数据核心。
随着业务系统的中心化建设将建立相互独立的业务中心组件，这些业务中心组件又依据重要性由核心向外围展开，每个业务中心组件有明确的价值体现，这些业务中心组件构成了企业业务核心。
随着数据平台的持续建设，将形成独立的数据服务中心组件，而这些数据服务中心组件同样依据重要性由核心向外围展开，每个数据服务中心组件有明确的价值体现，这些数据服务中心组件构成了企业的数据核心。
业务核心支撑了企业全部业务应用系统；数据核心支撑了企业全部数据应用系统，并覆盖到业应用务系统。业务核心底层依赖分布式交易数据库集群，数据核心依赖大数据分布式集群，包括新一代MPP数据库和Hadoop生态产品。
再上升一个高度来看，业务类系统产生数据，数据类系统基于数据产生决策，影响和优化业务系统，从而进一步完善业务数据，提升数据质量，进而产生更精确的决策，最终形成良性的企业信息循环，实现企业的智能化管理。
可以看出，未来企业信息化是企业发展的基础，而数据平台是企业信息化的基础。数据平台将逐步从后台走到前台，由辅助决策走向智能决策，成为企业发展的“指挥中枢”，成为企业发展的“超级大脑”。
关于数据核心的演进，对企业会产生很大的影响，举例如下：
数据服务平台将逐步成为数据ESB，应以ESB的规格要求建设数据服务平台；
数据存算平台将逐步成为企业的核心资产，两地三中心建设势在必行，并以多中心模式为主；
数据治理平台将和数据底座紧密结合，相辅相成，不断提升整体数据质量，对数据治理产品和团队提出更高要求；
大模型将在数据场景中实用，例如：
a. 报表辅助生成
b. 指标辅助生成
c. 查询SQL助写
d. 数据加工辅助生成
最后说一下东方国信CirroData数据库在企业的数据核心一体化演进中的最佳实践和经验积累。
东方国信在通信、金融、政府、工业等多个行业实现了湖仓一体落地，尤其在多个金融企业实现了真正意义上的湖仓一体大数据平台的落地。
在东方国信的湖仓一体落地方案中，打破了湖采用Hadoop技术、仓采用MPP数据库技术的传统做法，借助CirroData优秀的综合能力实现了结构化数据包括湖、仓、集市、数据应用的统一处理，而借助Hadoop生态重点解决实时处理、非结构化处理、数据采集交换、特定场景功能实现，真正意义上实现了Hadoop和MPP技术的有机结合，借助CirroData和Hadoop可以混合部署的能力实现了真正意义上的湖仓一体。具体说明如下：
CirroData支持和Hadoop统一部署：实现企业级的数据共享，即Hadoop数据和CirroData的数据共享，避免数据重复存放；
CirroData定制化DBlink支持数据底层共享：具体包括湖区数据对仓库、集市和应用系统的共享，仓库数据对集市、应用系统的共享，集市数据对应用系统的数据共享，避免了各层之间的数据冗余存放；
CirroData支持Oracle语法存储过程：同时存储过程可以稳定运行，这对于广泛熟悉Oracle数据库的开发者而言，学习成本极低，并可以快速迁移传统数据应用。此外，对于大中型企业，可以基于存储过程或者脚本对业务逻辑进行封装，避免了完全底层的基于SQL的管理，在系统稳定性和基于逻辑的可控管理上更适合面向企业的数据开发，而存储过程在调试、管理、可读性方面会更由于各类脚本（如perl脚本、shell脚本）；
CirroData三级租户实现资源层层管控：可以实现面向集群的统一管理，集群下面向应用的二级租户管理，应用下面向分支机构的三级租户管理，可以实现资源的层层下发，有效管控。而且，CirroData在研发之初就引入了大数据技术，且基于分布式文件系统进行了封装和优化，可以真正意义上实现资源的隔离；
基于CirroData支持全行各类复合查询的快速响应：包括精确查询、超过千亿的大表查询、多个亿级表的关联查询、上千字段的任意检索等各类查询场景；
CirroData定向研发能力：即东方国信面向企业应用提供定向研发能力；
基于CirroData建立双中心：目前已经有多个实际落地经验，东方国信可提供成熟的双中心建设方案。
东方国信提供了基于CirroData的大数据治理平台，如下图所示：
在数据治理平台中，基于自动采集的元数据，东方国信可实现真正意义上的企业级数据地图，展现从接入的接口数据到湖、仓、集市、数据应用的完整数据地图，如下图所示：
在东方国信的大数据治理平台中，提供了带自动数据迁移的数据开发平台，实现存储过程、脚本的自动转换：
可自动转换为如下加工流程：
并提供基于大模型的智能提示能力
东方国信提供基于大数据平台的数据挖掘平台，如下图所示：
东方国信购买了IBM SPSS全部源代码，实现完全自主可控，可快速替代包括SAS等传统应用，同时东方国信自主研发了数据挖掘平台，整合了Spark、TrensorFlow、Learn等计算框架，实现数据统一接入，和基于模型的全生命周期管理，实现基于模型的安全管控和共享，非常适合有较大规模数据挖掘团队的企业。
东方国信提供基于CirroData的全信创解决方案，如下图所示：
此外，东方国信提供了专业的咨询规划，是基于大数据平台丰富的建设经验形成的实战性比较强的企业级数据平台建设咨询规划，包括平台整体规划、数据模型设计、数据治理规划、专业培训、基于全行数据的专业数据支持服务等多个方面。东方国信有专业咨询团队，并拥有多个客户的咨询规划成功案例。
东方国信还提供了基于大数据平台的专业运维服务。鉴于全企业的进行平台化建设的复杂性，相对于传统技术，大数据平台的技术范围更广、更新更快、复杂度更高、问题解决难度更大，而且一个平台上运行着若干系统，一旦出现问题，影响面可能会大的多，因此对于企业级数据平台的运维与传统运维有所不同，专业运维能力在未来将非常重要。东方国信有专业的技术运维团队，并有多个客户的专业运维成功案例。
我今天的分享到此结束，感谢大家的聆听。
大家如果想进一步了解我们东方国信的CirroData，请关注CirroData公众号，再次感谢大家。
