各位领导、各位来宾、各位金融行业的同仁：
业务趋势
我们到目前为止500多亿的资产，资产规模在行业里面大概是第五六位，净利润水平在行业里面第四位，大概是这样的情况。消费金融的业务是什么呢？其实主要就是面向个人客户发放20万以下的信用贷款，没有抵押的，所以我们的业务其实是一个高频的线上交易模式。比如同样的100亿资产，银行放一笔房贷可能200万，我们放一笔消费贷可能就200块，去年有4点几亿笔的交易，放款加还款，放款1亿多笔交易里面有一半的交易单笔小于200块钱，大约有三分之一单笔小于100块钱，所以同样100亿资产对我们来讲是要有非常大量的交易，大量的业务才能构建起来，这是一个完全不同的商业模式。
信息系统发展历程
所以这种模式其实天然依赖的，对于信息系统、数据有非常强烈的需求，我大概列了一下我们业务系统发展的示意图，一个过程。
最早系统刚上线的时候其实目的是快速验证业务，这个跟互联网金融有点类似，保证业务能够快速验证，能够活下去。
所有的业务里面我的交易肯定是最主要的，先让交易能够走通，但是分析类的需求都是天然客观存在的，在最早的状态里面快速验证所以肯定是以交易系统建设为主，但是分析类需求会融合在交易系统里面，再往后会发现分析类的系统和交易类的系统天然差异逐步显现，越来越大，所以系统会演化，会分开。
2.同时我们还面临一个很现实的问题，就是随着交易量扩大，系统之间的复杂度提升、数据传输其实是一个很大的问题，后面我也会展开讲有大量的数据传输问题促使我们也做了新一代大数据体系的升级动力。
同时我们在交易量扩大的时候交易系统的复杂度也大幅度提升，我们之前从一套系统打天下到后面我们基本上有130多套系统，每个系统我们基本要会平均分布在10个实例上，每个实例上可能有上百个接口，所以系统之间的调用本身也是一个非常复杂的关系，以及包括我们原来交易数据库相对单一，后面因为数据量越来越大，会有引入读写分离、分库分表甚至不同异构的交易数据库，OLTP数据库也是异构的，不同数据库体系引入使这个体系会非常复杂。
我们在交易层面上做的自研APM体系就是通过agent抓各个系统服务接口之间调用，每天数据量会超过10亿，所以我们自研了数据总线系统，以及再往后我们整个大数据体系的存算分离架构，也是为了进一步降低成本提升整体运行的效率。
还有不可忽视的部分就是OLAP领域业务部门AD-HOC需求，最早没有太多需求，主要是风控部门要实时做分析，看各个策略运行情况，再往后越来越多的部门你只要是哪怕任何一个业务部门的任何一个分支业务都有配备自己的数据分析人员，都要去看数、比如营销，每个营销活动测算甚至到运营、财务等等就不用说了。
大量的风控、分析、业务、中后台运营部门都有自己的分析团队，而且分析师的规模也在越来越大，他们对于AD-HOC需求，对于在生产系统上取数包括分析系统上取数对于数据模型等等需求量越来越高，并且不可忽视的一点他们其实对于分析类应用的计算资源和存储资源需求也是在持续拉高，我们实际上也有遇到过业务的AD-HOC和生产系统的OLEP系统资源互相有冲突的实际情况，也有相应的生产问题。
数据流体系-数据流向
首先我们把体系做了类比，我既然讲数据，数据其实是流动的，类比最好的其实就是水文，拿中国来看主要就是从南向北，从西向东大江大河的流向，对于我们数据体系来讲我觉得很类似，首先分为上下两层北向我们称为OLTP就是所有的交易系统，基本上大部分数据都是交易系统产生的，下面南向就是OLAP（分析系统体系），从各种大数据平台、数据湖、数仓、集市、OLAP应用等等，大部分数据需要从北向向南流的，从东向西也有明显分布，比如所有交通系统里面基本按照业务过程去数据之间传递，从我们的APM抓的数据里面、系统调用数据里面，有一个很清晰地体现，因为绝大部分数据都是从渠道进件过来到信贷到资产到风控到支付，基本主要按照大的业务流程去传递的。
南向基本也是我落到数据湖里面，到ODS、数仓各个模型层、各种汇总层再到集市汇总再到各个分析类的报表平台，AD-HOC平台或者监管报送等等各种应用系统平台基本都有这样的流向，当然也有从南向北，比如很典型的就是我们有些风控的变量是需要批量，小批量算出来推送到交易系统里面，另外还有比较典型的就是营销，营销的体系比如说营销各种标签、变量、策略、规则都是分析系统里面批量算出来会推送到交易系统里面去实施执行。
这是我们整个体系，在这下面我们讲一些具体的问题。
问题1：无法实现低成本数据核对和数据回溯
第一就是数据传输，数据传输其实我们只要在交易系统和分析系统分离了之后就必然面临着数据传输的问题，而且只要业务量稍微大一点，其实都会或多或少遇到这个问题，我们之前也会发现说之前没觉得数据传输有什么问题，当你传输的数据量超过了几十亿之后，就总会有各种各样奇奇怪怪的问题，有时候当你发现之后会发现原来是可能十天以前就有这么一条数据是没有传过来，没有写入，你想再去把它找回来其实困难是非常大的，交易库的十几天前的东西想要再恢复回来，这个很难。
另外，有很多比如有些抖动或者我本身在分析库繁忙的时候有些同步，会有各种莫名其妙的问题，以及包括我的交易库里面可能有大表，十几亿的大表我增加一个字段，我光在同步字段增加的默认值可能就同步好几个小时都不一定同步的完，各种问题。
问题2：无法获取生产数据库中的实体数据变动明细
问题3：无法抽取精准的时点数据，不能保证多表数据一致
时点也是一个问题，就是我们很多时候希望能通过我们的OLAP平台拿到一个非常统一时点的数据，但是这个很难，我们即使说在某一个时点各个系统库同时采，就算同一个时点发出指令，真正到各个系统、各个库执行的时候总是有差异的，所以我们总会发现在我们的分析平台数据基础总会有些不同系统、不同表之间数据对不齐，这是一个事例。
问题4：无法获取跨系统精准日切数据，不能保证多表数据一致
一条两条无所谓，但是跟各位介绍我们业务量特点就是小额高频，所以这种问题对我们来讲是有蛮多的影响，可能每天都要修数或者对于业务分析来讲总是有各种数据对不齐、有差异等等。
数据总线产品核心能力
数据总线是我们自研的一套平台，基本是解决了以刚才说的几个问题点为驱动，因为我们之前也用了大量商业化的传输工具，好多种基本市面上都用过了，仍然有很多问题解决不了，因为大部分商业工具其实都是基于DTS、CBC的逻辑，就是分析系统、OLAP系统数据和OLTP系统数据基本保持近实时同步，本身对于我们从交易系统向分析系统，从北向向南向数据同步本质需求并不是很完全适应，某些情况下是有悖论的，这种CDC模式更适合北向向北向。通过数据总线第一解决了所有交易系统数据统一收集，能够高效地保证它没有错误，往我的分析系统OLAP体系传输，因为我们也有双路互相校验技术，既采了CDC也采了实时数据流等等，不同通路互相做校验保证OLAP的体系拿到的数据一定是对的，第二是刚才讲的数据增益，原来交易库APPdata过程信息通过平台把它全都抓过来了。
第三就是各种业务逻辑切分，通过这个平台能够很好支持，另外所有信息数据都实时入湖，保障了我整个后面成本的最低化。
数据总线产品生态图
应用架构，我们从数据的采集、交叉验证到我们所有数据的变动记录到后面的所有数据切分以及入湖、入仓，实际上现在数据总线直接接自研的数据湖，以及我们在硬件层面上也进行了拆分，我们原来比如MPP体系，一个集群里面可能都必须是性能很好的机器，任何有一个破机器进去就是木头原理。
另外所有成本跟我的数据量有很紧的线性关系，但是数据量使用命中率是有正态分布曲线的，我仍然有一大部分数据平时使用命中率很低，我们通过这个体系建设能够做到什么呢？把我们的硬件也进行了拆分，我们支持有一大批很便宜的机器但是大硬盘，能装好多数，同时我们也有十几二十万一台的高配机器可以组合，那些命中率比较高的数据属于正态分配的数据可以放在高配机器上，命中率比较低的相对冷的数据可以放到便宜机器上，对于整体成本来讲有非常大的贡献。
基于数据总线快速建设数仓-CDCEDODS
EDODS体系加上我们业务模型就是数仓完整的体系，后面加上数据集市以及各种应用基本构成了典型的企业级OLAP架构。
大数据应用架构—逻辑库规划原理
刚才讲到了AD-HOC稍微再多说两句，我们按照数据的稳定性，从数据稳定到不稳定，和程序从稳定到不稳定划分了四个象限，不同的应用系统做的划分，避免AD-HOC应用和线上应用混在一起。
大数据应用架构—资源隔离及数据权限（实现）
对于这块来讲主要要管理好资源权限，这个事情还是稍微有点麻烦，其实因为你对各个业务部门要核算的，他们IT成本占用等等，所以基本上按照存储资源、角色、数据对象分配好他们的权限。
最后谈几点思考：
1.数据湖技术结合，我觉得数据湖对于OLAP体系建设来讲还是一个比较基础的底层作用，我们其实用数据湖完全不是为了之前所说非结构化数据，因为之前有很多厂商向我们介绍能够支持各种非结构化数据，但是在OLAP的整个企业级实际应用，应用实践中对于非结构化的数据其实触底基本很少，我们也有大量的合同、签章各种东西，有OSS存储、业务系统做处理，分析领域里面用到的很少，但是实际上数据湖对于我们交易系统的结构化的文件，数据能带来蛮大帮助。
2.关于数仓，什么是数仓？数仓其实是逻辑体系、逻辑产品，以功能为视角的面向企业提供OLAP服务的，并不是一个物理的产品，尤其是技术和业务应用发展到现在，所以如何能够使用组合现有的技术面向功能，给企业提供更好的数据仓库的服务，这个是我们认为需要思考的。
3.实时数仓与OLTP系统也是我们的思考，因为之前大量厂商也和我们讲实时数仓是很神奇的事情，尤其我们大量做线上交易业务，线上风控等等，但是实际上从我们的实践经验来看以及包括我们思考，就是如果真的是实时的，并且消费端如果是机器的话，它就应该是放在OLTP体系里面，应该是风控团队去做而不是大数据团队做，因为本身两者之间对于系统开发的思考以及对于整个SLA的把控，这些更深层次的层面完全不一样，而不是因为他们都用了大数据平台的相同工具他们就是一回事，这个绝对不是这样的。
4.大模型应用与思考，大模型应用与思考以我们实践经验来看，自然语言toSQL我觉得离工业化应用还有距离，但是可以试验一下比如我们基于QOB（音）自然语言查询，就是有更完整的指标体系，对指标不同的维度都有汇总之后基于指标QOB进行自然语言分析还是可以的，大家也可以在实践应用中体验一下。