jamiee
作者jamiee2019-09-06 10:06
数据库架构师, 某股份制银行

金融行业大数据下准实时数据仓库应用场景及技术架构探讨总结

字数 7136阅读 1463评论 0赞 7

实时数仓应用的场景的情况在金融传统行业如何呢?结合银行来说目前实时数仓应用与风险控制场景完美契合,对于实时数仓的使用,可以使用风险的识别提前,有效的降低银行的损失,保证银行的利益。另外一个场景银行的互联网金融业务发展越发迅猛,实时数据量要比传统数据量更加大的多,因此在此场景下对实时数仓的需求也越发重要。然后这些应用场景应该如何选择合适的技术架构,不同的技术架构会给实时数仓带来不同的实时性要求以及数据的准确性,对企业决策起到至关重要作用。

金融企业在做实时数仓时也需要面临是否需要考虑把离线和实时整合在一起,技术架构如何改变?实时任务监控的同时,发生故障,如何保证及时恢复任务等等问题都是需要进行探讨的。这次,twt社区组织了十多家银行金融单位进行:准实时数仓的应用场景及对应的技术架构路线进行行业的交流探讨,通过这次的交流希望能让传统行业人员更加清晰的认识:
1、准实时数据仓库的应用场景有哪些,让大家能比较好的明确现在金融行业的应用场景情况;
2、关于准实时数仓的采用的技术架构的情况,比如技术路线有哪些?不同的应用场景是否需要对应不同的技术路线?
3、准实时数仓和现有的传统数据仓库在行业的定位和趋势发展。
本期线上交流活动金融大数据下准实时数据仓库的应用场景及对应技术架构路线在线探讨 (精彩回顾)

以下是本次交流的总结:

1、实时数据仓库与传统数据仓库的融合:实时数据仓库与历史数据仓库是否考虑统一建模还是分开建模?

实时数据仓库与传统数据仓库的融合:
1)实时数据仓库与历史数据仓库是否考虑统一建模还是分开建模?
2)实时数据仓库的实时数据与历史数据仓库的历史数据是统一存储还是分开存储?

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

嘉宾2:gengyang  数据仓库工程师 , 民生银行
1,关于建模
首先传统数仓的建模已经很成熟,而实时数仓才刚刚起步处于探索阶段,如果盲目效仿传统数仓,可能会因为复杂度过高而阻碍探索的步伐。我个人认为实时数仓的建模应该根据实际应用场景尽量简化,在实际应用的探索过程中逐步完善并形成标准。
2,关于存储
这个就更没必要统一了,传统数仓接入的数据基本都是格式化数据,而实时数据有日志有报文有格式化数据形式不一,如果有必要两者完全可以在服务层合并,而不是在仓库层。

嘉宾3:周光明  软件架构设计师 , People's Bank of China
1)无论实时数据仓库还是历史数据仓库,感觉建立模型是非常关键的,以模型为中心,以模型为驱动。数据分析本质上还是模型+算法。
2)实时数据仓库与历史数据仓库,在数据采集技术和数据传播技术等技术实现会有较大差别,但是模型上应该统一、融合的。
3)实时数据与历史数据,最好考虑统一规划、统一存储,方便以后各种粒度数据的分析利用。

嘉宾4:jamiee  数据库架构师 , 某股份制银行
1)实时数据更加强调数据采集、数据加工、数据应用的实时性, 实时数据处理的技术实现上与历史数据有比较大的差异,数据模型要统一比较困难,是否可从以下两点去尝试。
1.数据分层体系上可以借鉴传统数仓,比如数据数据采集是否可与贴源数据对应,实时的数据清洗和标准化是否可以整合层对应起来。
2.实时数据采集和加工结果可以批量持久化到存储中,用于仓库的贴源数据采集和整合层加工。
2)实时数据处理过程由于时效性的考虑,应该使用访问效率比较高的存储,比如SSD、内存,我认为两者的存储是要独立的。结合上面的第2点如果可以实现的话,最终采集和加工也可以与历史数仓整合到一起。

嘉宾5:黑民  软件开发工程师 , 湖南农信
1.关于建模。个人认为银行业实时数据的处理目前常用的场景还是对账户和流水的应用,相对来说账户和流水的模型应采用比较简单的模型,快速处理、高效处理,用来适应场景。
2.关于存储。个人偏向于分开存储,实时数据一般只用于当天,历史数据在T+1日后会再次同步,因此分开存储更有利于架构上的清晰和数据的应用。

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

嘉宾1:周光明  软件架构设计师 , People's Bank of China
谈点个人理解:
1)一般业务系统或者一般应用系统:
对于一般业务系统或者一般应用系统之上补充增加一些实时分析或者实时监控,这个模型建立与业务系统/应用系统耦合比较紧密,这样的模型建立的五花八门,没有统一、更没有标准。这样的case在许多银行的许多系统都是这样。
2)专业型数据仓库系统:
对于专业型数据仓库系统来说,传统数据仓库和大数据准实时数据仓库,在模型设计上应该是统一的、一致的,存储上应该也是统一的+差别化。
未来,传统数据仓库和大数据准实时数据仓库,在系统上必然是融合和统一的。
因为,从本质上来说:传统数据仓库和大数据准实时数据仓库之间差异就是时间粒度。但是,统一的数据模型是能够解决时间粒度问题。
所以,个人认为未来的数据仓库会是历史数据仓库和实时数据仓库的融合,即传统数据仓库和大数据实时数据仓库的融合。

嘉宾2:王奇  项目经理 , 阜新银行
个人理解,实时和准实时更多的是服务于业务查询、指标、或T0的报表,数据应该不会像传统数仓那样有很多的数据,他的模型应该更简单,数据的准确性和时效性应该更重要

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

嘉宾:jamiee  数据库架构师 , 某股份制银行
实时数仓的数据粒度应该要跟技术实现有关,我理解有起码有两类实现方式,一类存储指标等汇总数据,另一类是存储清洗后原始数据:
1.一类是基于根据实时采集的数据,在历史存储的指标基础上行加工新的指标值。这种实现方式是没有存放实时采集的数据,存储和使用的都是指标。这样做的好处是存储比较小,提供指标查询服务方便,用于报表展示、实时决策等应用的效率也比较方便。劣势是如果需要调整指标的统计口径,比如由统计一天调整成7天,只能从调整口径后累计7天的数据或者通过批量的方式从源系统导入7天的数据进行累加,两种方式都不太方便。
2.另一类是将实时采集的数据按照要求清洗后存储下来,由使用方发起请求时再计算指标值。这种方式存储的是清洗后的流水或状态类的数据,相对第一种数据存储比较大,好处是像上文提到那种指标口径变化比较方便,且除了提供指标数据外,还能直接提供明细或状态等的查询服务。

4、银行数据处理时效性越来越高,业务需求方对准实时数据数据处理的业务场景有哪些?

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

Ott  项目经理 , 广州某银行科技部
业务场景:
1、实时交易反欺诈,对客户交易行为进行实时分析,根据风险级别对客户资金交易进行预警或者阻断,保障客户资金安全。
2、实时营销,实时采集客户各渠道行为信息,结合推荐模型,采取事件式实时营销
3、在线业务实时监测,尤其是在线信贷业务,自动化审批流程替代了传统的人工审批,对后台的实时监测、分析、预警提出了更高的要求。
4、头寸管理,对各分支机构的头寸进行实时监测,提升资金利用率
离线数据处理、实时数据处理、准实时数据处理与业务场景的适配要充分考虑银行交易系统、分析系统、管理系统的整体架构,从业务应用的角度出发,构建技术体系。数据要应用才能产生价值。

5、准实时数据如何高效存储,比如增量如何处理,存量如何存储?

准实时数据如何高效存储,比如增量如何处理,存量如何存储,即保证时效性,又保证准确性,防重防漏

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

嘉宾2:jamiee  数据库架构师 , 某股份制银行
我也提了一个类似的问题,考虑到目前业务系统现状,很难配合进行实时数据采集的改造,很多场景是采用网络旁路或者OGG等方式进行数据采集,对于数据的业务状态和数据丢失无法完全保证。我自己的想法是应该结合应用场景,有些场景需要强一致性,有些不需要,如果技术手段上无法保证防重防漏,可以业务手段兜底。我举两个应用场景的例子。
一是在营销的场景中,用实时数仓计算的指标和一些规则进行实时的营销决策,决策结果用于推荐用户购买某个产品,由于推荐规则本身也存在准确性的问题,是否能防重防漏,对业务流程和推荐结果并大的影响,这种场景可以不用熬了防重防漏的问题,数据来了就收、漏了就不要了。
另一个场景同样是营销,不过这个场景是通过指标计算和营销活动规则判断是否给用户返送无门槛购物券。这类场景如果数据一致性出差错,比如遗漏了数据可能导致该送券没送券用户会投诉,导致不该送券的送了券,被薅了羊毛。这种场景要么技术上做数据一致性的保障,比如数据采集时要避免使用网络旁路方式,在数据加工时要进行主键判断避免数据重复,另外在业务流程上要进行调整,业务系统要增加用户投诉受理和差错处理的接口给客服处理一次情况。

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

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

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

嘉宾2:chailei_8306  研发工程师 , 银行
如果必须实时跑批,也就是让后续的表能够实时变化。那么能想到的方案也就是用视图了。但这样就限制了实时数仓的规模。

7、大数据平台和传统数据库如何进行有机结合?在金融行业适用的场景有哪些?

如何把建立的传统数仓与创建的大数据平台进行有机结合?比较适合切分到大数据平台上的业务场景有哪些?目前有想法切分部分海量的流水或台账数据到大数据平台上,不知道批量的效率是否理想?为了支撑上层智能报表的开发,大数据平台是否能胜任,需要做哪些适应性改造吗?

嘉宾1:周光明  软件架构设计师 , People's Bank of China
个人理解:
1)现在,各个银行都在考虑和规划把传统数据仓库和大数据技术整合,以便最后形成一个整体(或者说融合为一个整体),即金融大数据平台。
2)然后,基于这个金融大数据平台之上发展数据生态,包括实时数据分析、实时营销、业务决策等等诸多应用。
3)最后,整合的金融大数据平台,关键在于模型的建立必须是统一的、一致的,也就是说技术上可以在统一规划下采纳不同技术思想和工具,但是数据仓库模型建立必须是统一的。

嘉宾2:chailei_8306  研发工程师 , 银行
不建议在大数据平台替代传统数仓.
可以把海量数据处理,如日志收集处理、历史库、数据挖掘计算等放在大数据平台。
大数据平台处理结构化数据不是不可以,它的效率和运维成本比关系型数据库或列存储数据库差不少。

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

不同实时性如何采用不同技术?例如完全实时性、秒级实时性、分钟级实时性、小时级实时性、天级实时性,
我们应该如何选型方案和不同技术?

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

嘉宾2:王奇  项目经理 , 阜新银行
天级的就是传统的数仓,ODS ,其他的实时性技术选型应该一样,只是频度不一样,技术方案应该都是一样的

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

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

嘉宾:gengyang  数据仓库工程师 , 民生银行
现在很多银行包括互联网公司也都是在探索阶段。
关于背景其实没必要多说什么,现在对多种场景对数据的时效性要求都越来越高,从系统监控到实时营销,从内部管理到监管报送等诸多场景都要求建设实时数仓。
传统数仓在监管报送 / 风险管理 / 数据统计等方面已经做的很成熟,但在面对时效性要求较高的实时报送 / 实时营销 / 事中风控 / 实时资金管理与调拨等场景显得力不从心,这也是我们会在这里讨论实时数仓的原因。
关于实时数仓的技术,还是需要从四方面进行说明:数据接入 / 数据存储 / 数据加工 / 数据服务。数据接入:这块重点要考虑对源系统的侵入性 / 实时数据的负载等多种因素综合而定,目前有复制网络包, CDC ,日志收集等方式。数据存储:考虑到对数据时效性的要求,一半都是用类似 kafka 这样的分布式消息系统作为中间数据的存储。数据加工:目前成熟的有 storm/spark streaming/flink 等,目前用的较多的是 spark streaming ,但 flink 的批流合一的特色使得它有越来越流行的趋势,但这些组件对专业要求较高。数据服务:实时数据服务从实时数仓角度考虑有两种类型,一是主动推送型,如有转账时的实时营销场景,二是被动查询型,这种类型是在应用系统需要使用的时候再发起查询服务。
其实在建设实时数仓的过程中,可以参考下大家的普遍做法,但更多的是需要结合自己的实际情况,技术不是越新越好而是越适合自己越好。

10、实时数仓的主流技术架构及组件选型?

实时数仓的主流技术架构有哪些,分别适应哪些典型场景,各组件的选择考虑哪些因素?实时数仓如何与批量数据整合提供数据服务?

嘉宾1:jamiee  数据库架构师 , 某股份制银行
实时数据采集方面讲有OGG可以通过数据库日志的方式采集数据,Flume和logstash通过日志抓取数据,APM、F5等工具通过流量镜像抓取数据。
从数据加工角度来讲,有Kafka、rabbitMQ等队列进行数据接收和消费,有Storm进行流式数据计算处理。
从数据存储方面有redis、voltdb等内存数据库进行实时的数据和指标加工。
实时数据的处理结果可以异步持久化成文件,每天写成的文件可以在T+1日用于批量数据整合,这样处理批量数据的接口几乎不用特别修改,把实时数据处理当成一个批量数据源就成。

嘉宾2:王奇  项目经理 , 阜新银行
OGG :抽取和解析日志。做为数据的源头
数据的传输:FLUME ,LOGSTASH  个人理解:FLUME更注重数据的归集和分发。LOGSTASH 更多的是数据的过滤。
KAFKA:消息的订阅和发布。
时时计算:SPARK-STREAMING.
存储:REDIS

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

现在,无论实时数据仓库还是历史数据仓库,数据的维数越来越高,用户分析 需求也越来越复杂,我们应该如何对高维实时数据和高维历史数据进行建模、存储和分析?

嘉宾:匿名用户
我觉得分几步来做:
1.数据全部收集到一个数据平台。不管是实时的还是历史的。
2.做好数据库的清洗和基础关联,和宽表的建立。
3.根据对数据的实时性要求进行分级处理。
4.成立每个业务分析团队在款表上做分析。
5.分析的数据再返回宽表,并形成数据模型,共以后或其他业务线使用。譬如标签体系,用户体系。

嘉宾:周光明   软件架构设计师 , People's Bank of China
如果维数很高,比如银行账户,维数达到100或者上千个,我们怎么灵活地建模?同时考虑分析的效率?
  海阳回复:纬度多没关系,只要元数据一份并且已经做好,一个纬度就是写一个SQL而已。 建模不是纬度方面的事情。他更多的是对业务的理解和梳理。 分析效率更多的在于三个方面,1.底层数据的统一,不重复建设。2.清晰的业务目标,不乱提需求,控制需求的准确性。3.找个数据科学家,对业务的元数据建模,就像做好积木块。
 周光明回复:从我们的实践来看,数据仓库建模,“维度很高”,是个难题,还是比较难于处理的,不知是否有比较好的实践经验或者推荐的内容材料。
王奇回复: 海阳兄,说的很对,模型是业务的产物,维度是不同粒度的数据有不同的维度。相同粒度的数据不同的维度就是二个不同的SQL,不会很难。难的是对业务掌握的程度 。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

7

添加新评论0 条评论

Ctrl+Enter 发表

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30