金融行业实时数据仓库建模和数据存储等难点解读

Posted 2021-04-24 twt企业IT社区

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了金融行业实时数据仓库建模和数据存储等难点解读相关的知识，希望对你有一定的参考价值。

对于银行来说，目前实时数仓应用与风险控制场景完美契合，可以使风险识别提前，有效降低银行的损失，保证银行的利益。此外，由于互联网金融业务发展越发迅猛，实时数据量要比传统数据量更加大的多，在此场景下对实时数仓的需求也越发重要。

前不久，twt社区组织了十多家银行金融单位进行“准实时数仓的应用场景及对应的技术架构路线”交流探讨，下文是本次探讨的总结，供广大金融企业同行参考。

1、银行数据处理时效性越来越高，业务需求方对准实时数据处理的业务场景有哪些？离线数据处理、实时数据处理、准实时数据处理对于业务场景要怎样适配？

@Ott 广州某银行科技部项目经理：

业务场景：

1、实时交易反欺诈，对客户交易行为进行实时分析，根据风险级别对客户资金交易进行预警或者阻断，保障客户资金安全。

2、实时营销，实时采集客户各渠道行为信息，结合推荐模型，采取事件式实时营销。

3、在线业务实时监测，尤其是在线信贷业务，自动化审批流程替代了传统的人工审批，对后台的实时监测、分析、预警提出了更高的要求。

4、头寸管理，对各分支机构的头寸进行实时监测，提升资金利用率

离线数据处理、实时数据处理、准实时数据处理与业务场景的适配要充分考虑银行交易系统、分析系统、管理系统的整体架构，从业务应用的角度出发，构建技术体系。数据要应用才能产生价值。

2、传统数据仓库与大数据平台的准实时仓库，在模型设计上会有什么差异？

@周光明 PBOC 软件架构设计师：

谈点个人理解：

1)一般业务系统或者一般应用系统：

对于一般业务系统或者一般应用系统之上补充增加一些实时分析或者实时监控，这个模型建立与业务系统/应用系统耦合比较紧密，这样的模型建立的五花八门，没有统一、更没有标准。这样的case在许多银行的许多系统都是这样。

2)专业型数据仓库系统：

对于专业型数据仓库系统来说，传统数据仓库和大数据准实时数据仓库，在模型设计上应该是统一的、一致的，存储上应该也是统一的+差别化。

未来，传统数据仓库和大数据准实时数据仓库，在系统上必然是融合和统一的。

因为，从本质上来说：传统数据仓库和大数据准实时数据仓库之间差异就是时间粒度。但是，统一的数据模型是能够解决时间粒度问题。

所以，个人认为未来的数据仓库会是历史数据仓库和实时数据仓库的融合，即传统数据仓库和大数据实时数据仓库的融合。

@王奇阜新银行项目经理：

个人理解，实时和准实时更多的是服务于业务查询、指标、或T0的报表，数据应该不会像传统数仓那样有很多的数据，他的模型应该更简单，数据的准确性和时效性应该更重要。

3、实时数据仓库与传统数据仓库的融合：实时数据仓库与历史数据仓库是否考虑统一建模还是分开建模？实时数据与历史数据是统一存储还是分开存储?

@王奇阜新银行项目经理：

所谓的实时数仓，最主要的就是当天的数据，银行最重要的是当天的流水。所以更多的需求都应该是银行的流水数据产生的。实时的数据量很少。只有当天或几天的数据（保存几天的数据可以增加容错的机制），各个理解时时数仓关注的应该是指标。而非各种各样的数据。模型也应该是轻量级的。而非传统的数仓是非常沉重而沉淀的数据。

@gengyang 民生银行数据仓库工程师：

1，关于建模

首先传统数仓的建模已经很成熟，而实时数仓才刚刚起步处于探索阶段，如果盲目效仿传统数仓，可能会因为复杂度过高而阻碍探索的步伐。我个人认为实时数仓的建模应该根据实际应用场景尽量简化，在实际应用的探索过程中逐步完善并形成标准。

2，关于存储

这个就更没必要统一了，传统数仓接入的数据基本都是格式化数据，而实时数据有日志有报文有格式化数据形式不一，如果有必要两者完全可以在服务层合并，而不是在仓库层。

@周光明 PBOC 软件架构设计师：

1）无论实时数据仓库还是历史数据仓库，感觉建立模型是非常关键的，以模型为中心，以模型为驱动。数据分析本质上还是模型+算法。

2）实时数据仓库与历史数据仓库，在数据采集技术和数据传播技术等技术实现会有较大差别，但是模型上应该统一、融合的。

3）实时数据与历史数据，最好考虑统一规划、统一存储，方便以后各种粒度数据的分析利用。

@jamiee 某股份制银行数据库架构师：

1）实时数据更加强调数据采集、数据加工、数据应用的实时性，实时数据处理的技术实现上与历史数据有比较大的差异，数据模型要统一比较困难，是否可从以下两点去尝试。

1.数据分层体系上可以借鉴传统数仓，比如数据数据采集是否可与贴源数据对应，实时的数据清洗和标准化是否可以整合层对应起来。

2.实时数据采集和加工结果可以批量持久化到存储中，用于仓库的贴源数据采集和整合层加工。

2）实时数据处理过程由于时效性的考虑，应该使用访问效率比较高的存储，比如SSD、内存，我认为两者的存储是要独立的。结合上面的第2点如果可以实现的话，最终采集和加工也可以与历史数仓整合到一起。

@黑民湖南农信软件开发工程师：

1.关于建模。个人认为银行业实时数据的处理目前常用的场景还是对账户和流水的应用，相对来说账户和流水的模型应采用比较简单的模型，快速处理、高效处理，用来适应场景。

2.关于存储。个人偏向于分开存储，实时数据一般只用于当天，历史数据在T+1日后会再次同步，因此分开存储更有利于架构上的清晰和数据的应用。

4、实时数据仓库与历史数据仓库应该如何应对高维数据建模和处理?

【问题描述】现在，无论实时数据仓库还是历史数据仓库，数据的维数越来越高，用户分析需求也越来越复杂，我们应该如何对高维实时数据和高维历史数据进行建模、存储和分析？如果维数很高，比如银行账户，维数达到100或者上千个，我们怎么灵活地建模？同时考虑分析的效率?

@匿名用户：

我觉得分几步来做:

1.数据全部收集到一个数据平台。不管是实时的还是历史的。

2.做好数据库的清洗和基础关联，和宽表的建立。

3.根据对数据的实时性要求进行分级处理。

4.成立每个业务分析团队在款表上做分析。

5.分析的数据再返回宽表，并形成数据模型，供以后或其他业务线使用。譬如标签体系，用户体系。

@海阳某平台架构部高级技术经理：

维度多没关系，只要元数据一份并且已经做好，一个维度就是写一个SQL而已。建模不是维度方面的事情。他更多的是对业务的理解和梳理。分析效率更多的在于三个方面，1.底层数据的统一，不重复建设。2.清晰的业务目标，不乱提需求，控制需求的准确性。3.找个数据科学家，对业务的元数据建模，就像做好积木块。

@王奇阜新银行项目经理：

模型是业务的产物，维度是不同粒度的数据有不同的维度。相同粒度的数据不同的维度就是二个不同的SQL，不会很难。难的是对业务掌握的程度。

5、如何把控实时数据仓库的实时数据的粒度与历史数据仓库的历史数据的粒度？

@jamiee 某股份制银行数据库架构师：

实时数仓的数据粒度应该要跟技术实现有关，我理解有起码有两类实现方式，一类存储指标等汇总数据，另一类是存储清洗后原始数据：

1.一类是基于根据实时采集的数据，在历史存储的指标基础上行加工新的指标值。这种实现方式是没有存放实时采集的数据，存储和使用的都是指标。这样做的好处是存储比较小，提供指标查询服务方便，用于报表展示、实时决策等应用的效率也比较方便。劣势是如果需要调整指标的统计口径，比如由统计一天调整成7天，只能从调整口径后累计7天的数据或者通过批量的方式从源系统导入7天的数据进行累加，两种方式都不太方便。

2.另一类是将实时采集的数据按照要求清洗后存储下来，由使用方发起请求时再计算指标值。这种方式存储的是清洗后的流水或状态类的数据，相对第一种数据存储比较大，好处是像上文提到那种指标口径变化比较方便，且除了提供指标数据外，还能直接提供明细或状态等的查询服务。

6、准实时数据如何高效存储，比如增量如何处理，存量如何存储？

【问题描述】准实时数据如何高效存储，比如增量如何处理，存量如何存储，既保证时效性，又保证准确性，防重防漏。

@gengyang 民生银行数据仓库工程师：

既然是需要实时接入的数据应用场景也都是对实效性要求较高，再考虑的可用性和负载要求所以对实时中间数据最好用类似kafka这样的分布式消息中间件，对于加工后的结果数据可以放到mysql hbase，redis，hbase，redis或者hbase，redis，hbase，redis或者kafka本身，这个就需要根据具体应用场景和容量进行评估。

@jamiee 某股份制银行数据库架构师：

我也提了一个类似的问题，考虑到目前业务系统现状，很难配合进行实时数据采集的改造，很多场景是采用网络旁路或者OGG等方式进行数据采集，对于数据的业务状态和数据丢失无法完全保证。我自己的想法是应该结合应用场景，有些场景需要强一致性，有些不需要，如果技术手段上无法保证防重防漏，可以业务手段兜底。我举两个应用场景的例子。

一是在营销的场景中，用实时数仓计算的指标和一些规则进行实时的营销决策，决策结果用于推荐用户购买某个产品，由于推荐规则本身也存在准确性的问题，是否能防重防漏，对业务流程和推荐结果并大的影响，这种场景可以不用熬了防重防漏的问题，数据来了就收、漏了就不要了。

另一个场景同样是营销，不过这个场景是通过指标计算和营销活动规则判断是否给用户返送无门槛购物券。这类场景如果数据一致性出差错，比如遗漏了数据可能导致该送券没送券用户会投诉，导致不该送券的送了券，被薅了羊毛。这种场景要么技术上做数据一致性的保障，比如数据采集时要避免使用网络旁路方式，在数据加工时要进行主键判断避免数据重复，另外在业务流程上要进行调整，业务系统要增加用户投诉受理和差错处理的接口给客服处理一次情况。

7、实时拿到数据后如何真正进行实时跑批？

【问题描述】很多实时数仓在使用CDC等技术后能够达到秒级数据同步，但后续加工仍然比较依赖传统数据库和传统的加工方式，导致只能定时跑批。如何能够达到实时etl加工？

@gengyang 民生银行数据仓库工程师：

肯定要用类似streaming或flink这样的流处理组件而不是跑批。具体可以两种实现方案，一是cdc的目标不要设置为数据库而是设置为kafka，然后对接kafka或者flink，这种比较容易；二是目标为数据库，然后自己写程序实现轮训，这种比较复杂但对大数据组件没要求，适合小数据量处理。

@chailei_8306 银行研发工程师：

如果必须实时跑批，也就是让后续的表能够实时变化。那么能想到的方案也就是用视图了。但这样就限制了实时数仓的规模。

8、不同实时性（如完全实时性、秒级实时性等）如何采用不同技术?

【问题描述】不同实时性如何采用不同技术?例如完全实时性、秒级实时性、分钟级实时性、小时级实时性、天级实时性。我们应该如何选型方案和不同技术？

@jamiee 某股份制银行数据库架构师：

我们曾经做过一个风控类的项目，大概在几十毫秒完成指标计算，并将指标反馈给实时决策引擎。思路有两个。一是业务系统将交易报文下发给实时指标加工模块进行处理，指标加工模块完成指标计算后同步返回加工结果；另一个是上游业务系统将交易报文写入消息队列，指标加工模块从队列读取报文数据加工指标并将结果写入结果队列中，决策引擎通过队列读数据。我们用的第一种方式。

@王奇阜新银行项目经理：

天级的就是传统的数仓，ODS ,其他的实时性技术选型应该一样，只是频度不一样，技术方案应该都是一样的。

9、准实时数仓的采用的技术架构，场景及落地情况？

【问题描述】

1、关于准实时数仓的采用的技术架构
2、其他银行准实时数仓产生的背景及数据场景（并发，数据量等）
3、准实时数仓和现有的传统数据仓库分别如何定位和发展
4、准实时数据的应用场景有哪些，分别的技术架构及落地情况

@gengyang 民生银行数据仓库工程师：

现在很多银行包括互联网公司也都是在探索阶段。

关于背景其实没必要多说什么，现在对多种场景对数据的时效性要求都越来越高，从系统监控到实时营销，从内部管理到监管报送等诸多场景都要求建设实时数仓。

传统数仓在监管报送 / 风险管理 / 数据统计等方面已经做的很成熟，但在面对时效性要求较高的实时报送 / 实时营销 / 事中风控 / 实时资金管理与调拨等场景显得力不从心，这也是我们会在这里讨论实时数仓的原因。

关于实时数仓的技术，还是需要从四方面进行说明：数据接入 / 数据存储 / 数据加工 / 数据服务。数据接入：这块重点要考虑对源系统的侵入性、实时数据的负载等多种因素综合而定，目前有复制网络包， CDC ，日志收集等方式。数据存储：考虑到对数据时效性的要求，一般都是用分布式消息系统作为中间数据的存储。数据服务：实时数据服务从实时数仓角度考虑有两种类型，一是主动推送型，如有转账时的实时营销场景，二是被动查询型，这种类型是在应用系统需要使用的时候再发起查询服务。

其实在建设实时数仓的过程中，可以参考下大家的普遍做法，但更多的是需要结合自己的实际情况，技术不是越新越好而是越适合自己越好。