奎克的藏经阁 · MinerU 解析内容

人工智能与大数据技术导论

490 个 PDF 物理页 · 本页显示文件第 411–420 页

PDF 物理页索引 410

文件中的第 411 页 · 印刷页码:394

指数的设计是门大学问,这里简单提三个关键点:一是要遵循“独立和穷尽”的原则;二是要注意各指标的单位,尽量用“标准化”来消除单位的影响;三是权重和需要等于1。独立穷尽原则,即你所定位的问题,在搜集衡量该问题的多个指标时,各个指标间尽量相互独立,同时能衡量该问题的指标尽量穷尽(收集全)。举个例子,设计某公司销售部门的指标体系时,目的是衡量销售部的绩效,确定核心指标是销售额后,我们将绩效拆分为订单数、客单价、线索转化率、成单周期、续约率5个相互独立的指标,且这5个指标涵盖销售绩效的各个方面(穷尽)。我们设计的销售绩效综合指数=0.4×订单数+0.2×客单价+0.2×线索转化率+0.1×成单周期+0.1×续约率,各指标都采用max-min方法进行标准化。

12.3.7循环/闭环思维

循环/闭环的概念可以引申到很多场景中,比如业务流程的闭环、用户生命周期闭环、产品功能使用闭环、市场推广策略闭环等。这种思考方式是非常必要的。业务流程的闭环是管理者比较容易定义出来的,列出公司所有业务环节,梳理出业务流程,然后定义各个环节之间相互影响的指标,跟踪这些指标的变化,能从全局上把握公司的运行状况。循环/闭环思维图示如图12-5所示。

比如,一家软件公司的典型业务流程:推广行为(市场部)→流量进入主站(市场+产研)→注册流程(产研)→试用体验(产研+销售)→进入采购流程(销售部)→交易并部署(售后+产研)→使用、续约、推荐(售后+市场)→推广行为,一个闭环下来,各个衔接环节的指标就值得关注了:广告点击率→注册流程进入率→注册转化率→试用率→销售管道各环节转化率→付款率→推荐率/续约率……这里涉及漏斗思维,如前面所述,“千万不要用一个漏斗来衡量一个循环”。有了循环思维,能够比较快地建立有逻辑关系的指标体系。

人工智能与大数据技术导论

394

PDF 物理页索引 411

文件中的第 412 页 · 印刷页码:未识别

第13章

银行业大数据和人工智能

从十二五走到十三五规划期间,银行业面临的各方面的压力越来越大,从四大行的年报数字可以看出,它们的利润增长基本上趋近于零增长。在这样的情况下,怎样通过大数据和人工智能提升传统银行的竞争力,是摆在他们面前的一个很重要的课题。过去十多年期间,银行业务出现了一个重要拐点,这个拐点就是互联网银行慢慢取代柜员,IT从支持几万、十几万的柜员到支持面向所有的互联网客户,无论是服务的形态还是IT的支撑,都发生了根本的变化,这是移动和云技术在里面发挥了作用。这几年,银行三大互联网渠道已经建立:

手机银行已达到1.8亿多。

●网上银行有2亿多。

●微信银行占的客服服务总量已经超过了传统的客户服务。

这意味着银行的渠道、场景化的实践已经见到了效果,做大数据要具备的基础已经存在。但是,银行大数据依然面临着不少的挑战:

如何处理数据量的快速增长?这包括每天的交易量、外部互联网金融、银行的三大互联网平台造成用户的交易数据和行为数据有大幅的增长。

如何快速智能分析历史数据?四大行从2000年开始建立数据仓库以来,拥有了庞大的历史数据资产,在新的环境下怎么能够快速地智能分析,对银行提出了更高的挑战。

如何使用内外数据描述客户特征?在数据源方面,除了本银行数据外,也需要采纳外部的数据来配合进行分析。很多银行已经引入了征信数据、税务数据等,怎么做到以比较全面的数据去描绘银行的客户特征,这是银行的一个新的课题。

所以,下一个拐点是什么呢?银行要从原来做的账务性的、交易性的处理转向能够渗透到经济生活的方方面面,这是一个场景化。如果抓不住这个拐点,银行就要被互联网金融颠覆或者管道化。这就要做人工智能和大数据挖掘。对传统银行来讲,要解决三大问题:

怎么样提升对于客户的识别?

● 怎么样提升对于客户的营销?

●怎么样提升对于风险的防范?

对于银行业而言,无论是用传统的结构化的数据,还是用现在互联网形态下非结构化的数据,要解决的问题都是这些。目前,银行业有了更丰富的数据源,有了更好地进行数据处理的方法,银行业就是要实现数据挖掘和分析。比如,建设银行已经成立了上海大数据分析中心。

PDF 物理页索引 412

文件中的第 413 页 · 印刷页码:396

下面我们分析一下四大行的大数据和人工智能的进展。

13.1 四大行的进展

金融行业在有些技术的选择上还是相对比较保守的,一般不会用最新的技术,不会用最新的版本,这是因为银行的连续服务要求特别高。但是,在大数据技术和人工智能上,金融行业是最先使用的一个行业。

13.1.1 建设银行

建设银行大数据平台的策略是架构先行,已经有很好的基础架构。在基础框架上,搭建了一些基础的大数据分析工具。功能架构设计上和其他银行差不多,包含从采集、存储、分析、展现到应用。在数据设计上有一个演变过来的整体的结构。他们强调大数据是数据的一部分,结构化的数据是大数据的一部分。建行的大数据平台取得了不少的成果。

●在实时的数据仓库上,能够对客户经理做实时的数据提供和交付,无论是在并发的访问还是实时服务方面。

●在数据的应用模式上,有6类数据应用模式,包括挖掘类、数据实验室、机器查询、仪表盘、固定报表、自动查询等。

●建立“模型实验室”,能够发挥的作用越来越大,能够基于结构化和非结构化的数据支持大数据模型的研发,这个模型研发出来后,能够很快地把它部署到生产当中。

在非结构化大数据的应用方面做了不少探索,比如客户行为偏好的数据、录音文本、地理数据的应用,能耗数据的应用,媒体信息、员工商银行为数据的应用等。通过位置服务终端识别的新技术、新数据的采用,拒绝可疑风险事件,2017年上半年避免了1.9万起风险事件,避免客户损失1.4亿,这种数据越来越多。

13.1.2 工商银行

工商银行大数据战略思路是通过工商银行两库的建设来完善大数据体系的。两库是信息库和数据仓库,数据仓库在工商银行的建设和银行的建设中都是比较传统的,主要是应对之前的银行交易数据、账户数据,采用结构化的数据存储来进行相关的处理。从2013年开始,工商银行启动了信息库的建设,主要指非结构的数据。通过两库的建设,工商银行还建设了一支分析师队伍,能够对这些庞大的数据进行相关业务的加工处理和分析。

工商银行大数据的发展历程可以分为几个阶段,从TB级已经进入了PB级的建设阶段,接下来在可预见的几年内会进入EB级的庞大体量。最早在2000年初,那个时候大数据领域更多的还是应用在一些报表的快速展现上,所以那个时候工商银行基于比较传统的Oracle和SaaS做了T+1的动态报表,行领导和管理层能够在第二天上班前看到昨天的经营数据。2007年,工商银行基于当时最先进的企业级数据仓库体系架构启动了企业级数据体系的建设,做了全行统一的管理数据的大集中。2010年,基于数据仓库的数据支持,工商银行推出了MOVA管理会计系统,做了全行绩效考核的管理系统。2013年,随着大量数据爆发式的出现,工商银行引进了大数据领域在业界最流行的Hadoop技术,在Hadoop基础上搭建了信息库。2014年,工商银行基于大数据,自主研发了一个流数据平台,能够提供实时或者准实时的流数据处理,原来的大数据采用联机异步批量的方式,通过文件存储,无论是数据仓库还是信息库,在时效上相对来说都比较慢。2015年下半年和2016年开始推动分布式数据库的落地工作,这会和企业级数据仓库做一个互补。这是大数据的主要技术演进。

人工智能与大数据技术导论

396

PDF 物理页索引 413

文件中的第 414 页 · 印刷页码:397

在大数据平台上,工商银行把它抽象成如下几层:

●第一层是数据采集,统一针对外部和内部的数据进行相关的数据收集,包括日志信息、行为信息和业务信息。

●往上一层是计算层,不仅提供了传统数据仓库的批量计算能力,也通过一些流数据的技术提供了实时计算能力。

再往上一层是应用层,抽象了大数据相关的应用,包括用户可以自定义的查询功能。

通过这些分层的服务,把它们抽象到业务系统中。通过管理会计系统、分析师平台、风险系统、营销系统,为工商银行在数据的运营、风险控制和营销方面都提供了相关的支持,这就是主要的大数据分层体系。

分布式、开源、通用成为趋势。从大数据的起源开始,到目前的大数据应用新形势下,数据仓库已经在做非常大的升级换代和变化。2014年工商银行从高成本封闭的专业系统(如Teradata)开始向高性价比、通用设备和开放技术的系统转变。转型有两个原因:

(1)数据量太大了。原来只需要处理TB级的数据量,已经转向需要处理PB级的数据量,甚至以后将要处理EB级的数据量。这么大的数据量,运用传统的设备没有办法进行相关的处理。

(2)性价比。工商银行做过测量,通过开放式的弹性可扩展的普通PC服务器的方式,比传统设备在成本上可以节省十几分之一或者几十分之一。工商银行在新平台上一方面引进了Hadoop平台,基于普通的PC服务器进行搭建,短短一两年的时间已经扩展到几百个节点,存储空间已经超过1PB,超过建设了十几、二十年的Teradata的数据容量。

另外,工商银行也在尽快落地分布式数据库。这是基于开源的底层架构,基于普通的PC服务器完成数据仓库体系的扩充。后续在大数据的处理加工方面、会基于分布数据库进行处理。工商银行会保留Teradata,着重于高端的分析师分析挖掘的探索性的工作方面。后续的大数据体系会采用多种技术路线、多种技术平台共存的方式。

工商银行在大数据和人工智能应用方面主要侧重于风险防控。这是落地最快、最有成效的应用。工商银行通过大数据在事前、事中、事后三个环节的运用进行风险的柔性控制。

●事前,比如银行卡的授信过程中,或者信贷要进行发放做尽职调查中,数据能给它一个支撑。

●事中,比如银行卡最近比较多地发生盗刷行为,我们可以在事中通过大数据的方式发

第13章 银行业大数据和人工智能

397

PDF 物理页索引 414

文件中的第 415 页 · 印刷页码:398

人工智能与大数据技术导论

现银行卡的盗刷行为。

●事后,可以根据事后的交易或者发生的事件进行相关的分析,分析后续在业务的拓展或者风险控制方面有哪些需要进一步改进或者补救的工作。

下面是几个常见的大数据和人工智能案例。

●交易反欺诈,需要利用大数据流数据的技术,用户在交易的过程中采用主机旁路技术,交易没有完成之前,通过大数据在内存中进行一次判断。

大数据怎么运用模型,通过比较好的用户特征的总结和模型进行监控。通过标签信息,比如定义了两个标签,一个是用户开户的地区比较广泛,另一个是持有比较多的借记卡,就可以认为他有倒卖银行卡的嫌疑,通过大数据的计算可以把这些人员抓出来,进行后续的业务处理和防控。这也是大数据和人工智能应用得比较好的方面。

现在各个银行业碰到的比较大的困境是信贷资产的质量问题。工商银行持续在推动运用大数据和人工智能防控信贷风险,成立了信贷防控中心,运用大数据和人工智能技术进行相关的防控。

13.1.3 农业银行

做数据仓库的时候,四大行的选择面都很窄,除了农业银行没用TD外,其他银行都是用TD做的数据仓库。农业银行使用了南大通用的MPP架构数据库。Hadoop方面,目前使用的是CDH开源版,大概有100个左右的Datanode,容量是5PB左右。数据模型方面,农业银行融合了范式和维度的思路。在主库核心层面基本是用范式建模减少重复。维度方面以业务驱动的方式建立维度模型为主。

农业银行生产系统有60多个上游系统,通过一个交换平台为大数据服务,负责上游生产和下游数据消费系统总分行之间、总行各应用系统间的数据交互。几乎全行所有的生产系统的数据已经全部进来了。大数据平台是基于Hadoop的。上游来的全量数据在平台上做了归类。农业银行在Hadoop上封装了应用,为全行的数据挖掘提供服务支撑。

13.1.4 中国银行

中国银行的大数据战略如下:

●以平台为支撑构建大数据的技术体系。

● 以数据为基础充分整合数据资源。

●以应用为驱动深入挖掘数据价值。

●以人才为核心提升数据分析能力。

在实施方面,中国银行采用分行试点的模式,采取快速迭代、迅速试错的方式。中银开放平台是中国银行大数据实施的例子之一,2014年获得IDC金融的大奖,2015年获得人民银行嘉奖,亚洲金融家组织把它评为最佳的金融云服务产品。这个产品的主要设计思路是把整个中国银行的大数据进行归并整理之后,开发了1000多个标准的API接口,这些API接口可以用于分行,甚至是客户。他们可以通过这些API访问和使用中国银行的数据,用于加工得到自己想要的相关结果。目前,已经有很多分行利用这样的平台开发出了很多比较受欢迎的产品。

398

PDF 物理页索引 415

文件中的第 416 页 · 印刷页码:399

中国银行曾经表示,非常希望在合规的前提下充分利用银行外部的数据服务。因为银行或者金融企业的数据在深度上不是一般的互联网企业能够比拟的,如果金融行业跟其他的相关企业进行有效的数据交换,大家彼此利用对方的优势,就能够使这个银行的数据得到更完美的使用。中国银行以应用为驱动,深入挖掘数据价值,做大数据和人工智能应用的场景产品。比如,中国银行推出了口碑贷、中银沃金融的服务。中银精准地建设客户的营销平台,把线下的客户信息和线上的客户行为统一在一起,把结构化的数据和非结构化的数据有机地提炼并且整合,争取能够精确地描述客户的各项属性特征。

13.2 其他银行

坐拥海量信息,银行仍患“数据贫血症”,这是原工商银行董事长姜建清的深度解读。“一些银行坐拥海量信息,但由于数据割裂、缺乏挖掘和融会贯通,而患上数据贫血症’”,姜建清表示。姜建清提出,实现银行信息的“融会贯通”要把握8个字:集中、整合、共享、挖掘。

●运营集中:作业模式工厂化、规模化、标准化,业务集中处理、前中后台有效分离及各类风险集中监控。目的是提高质量和效率,降低成本,控制风险。

●系统整合:建立IT中枢和架构统一化,系统互联互通高效化,破除数据信息孤岛。目的是使经营管理灵活协调,市场客户响应快速及时。

●信息共享:形成便于检索的数据共享平台。目的是提高信息的可用性、易用性。

数据挖掘:通过对数据收集、存储、处理、分析和利用,使用先进的数据挖掘技术,使海量数据价值化。目的是据此判断市场、发现价格、评估风险、配置资源,提供经营决策、产品创新、精准营销的支持。

“信息化银行建设的成功实施会使银行间出现竞争力的代际’差异,赢者会持续保持战略优势”,姜建清称。

除了四大行外,下面看看其他银行在大数据和人工智能上的布局。

13.2.1 广发银行

广发银行将大数据工程定位为“智慧工程”,目标是打造广发银行的“大脑”,动态感知市场需求、经营状况、客户体验,实现快速决策、快速创新,推动以客户为中心的零售银行与交易银行战略转型。大数据工程同时也是广发银行的“人才工程”,广发银行计划用3年左右的时间培养打造一支100人的大数据专业人才队伍。2013年,广发银行制定了大数据5年规划,分三个阶段实施。

●第一阶段(2013、2014年):大数据技术平台建设与应用试点。

第13章 银行业大数据和人工智能

399

PDF 物理页索引 416

文件中的第 417 页 · 印刷页码:400

人工智能与大数据技术导论

●第二阶段(2015、2016年):大数据生态系统建设与重点业务领域应用突破。

●第三阶段(2017、2018年):大数据智能分析与业务全面推广应用。

目前已完成平台建设、应用试点、大数据生态系统建设和信用卡业务领域应用,即按分析与应用分离、读写分离的原则建设4个数据域。正在建设8个数据产品:客户全景视图、潜在客户视图、资金关系圈、自助分析平台、历史数据查询平台、实时营销平台、实时风控平台和客户信用评级。基于数据产品的多个业务应用正在试点或推广,并与多个外部伙伴开展了大数据合作。

13.2.2 江苏银行

江苏银行大数据平台建设起步于2014年底,2015年年中初见成效。目前,江苏银行利用大数据技术开发了一系列具有一定社会影响的大数据和人工智能应用产品,如“e融”品牌下的“税e融”“享e融”等线上贷款产品、基于内外部数据整合建模的对公资信服务报告、以实时风险预警为导向的在线交易反欺诈应用、基于柜员交易画面等半结构化数据的柜面交易行为检核系统等。

大数据和人工智能应用的本质是对客户需求的认识和释放,应用效果取决于银行的综合运营服务意识,而选择一个合适的技术平台也是大数据成功应用的不可或缺的因素之一。江苏银行在大数据技术平台建设方面进行了大量探索和思考。

  1. 为什么要建设大数据技术平台

江苏银行资产规模是数万亿元,积累了大量的内部数据,以往受限于高性能存储的成本和数据并行化处理能力,占总存储量80%以上的数据是“死”在系统里的。以对私客户的活期账户为例,一张拉链表的数据量就达数百GB,运行在IBMP系列小型机上的Oracle数据库统计一下表的行数就要3个小时,若需要全量回算历史数据,为避免影响生产,需要将数据导出到另外的数据库上,花费几天时间。又如,“柜员操作记录”这样的半结构化数据每天产生的数据量达几个GB,生产环境只能保留最近几天的数据,其他数据存储在磁带库上,使用时需花费大量的人力将数据从磁带库中导出。

另一方面,为减少贷前审查的录入成本,开发纯线上贷款产品等,江苏银行陆续引入了税务、法院、工商、黑名单等外部数据。随着内外部数据量的快速增长,大规模数据处理和实时响应的需求使得传统的数据处理平台遭遇瓶颈,江苏银行急需探索新的数据架构,采用新的数据处理技术。

当前,银行业面临的挑战主要来自两个方面:利率市场化和互联网金融。利率市场化拉近了传统银行与实体经济的横向联系,要求银行快速提升数据洞察能力;互联网金融使得银行的数据应用不能局限于传统的查询统计分析应用,还需提供高效精准的营销,并具备实时风险防控能力。相较于大型商业银行,城商行的竞争更加激烈,传统的数据产品和应用服务已无法满足新形势下城商行应对市场竞争的需要。

400

PDF 物理页索引 417

文件中的第 418 页 · 印刷页码:401

  1. 大数据技术平台架构分析

经过对主要大数据处理平台的深入研究,江苏银行将关注点聚焦在选择MPP还是Hadoop。为此,江苏银行更进一步从数据容量和数据处理能力的线性关系分析传统数据平台、MPP和Hadoop的关系,如图13-1所示。

传统观点认为,MPP的适用范围为1TB\~100TB的数据量,数据量超过100TB,Hadoop更具优势。当前,大中型城商行的数据量普遍在10TB级别,因此一些城商行选择MPP作为大数据处理平台。然而,近年来随着Hadoop开源社区的不断发展,特别是Spark的发布让Hadoop焕发了新的活力。Spark具有RDD(Resilient DistributedDatasets,弹性分布式数据集)和DAG(DirectedAcyclic Graph,有向无环图)两项核心技术,基于内存计算优化了任务流程,具有更低的框架开销,使得Hadoop在MPP擅长的100TB以下数据量的处理性能也大为改善。以目前的Hadoop技术,100GB以上的数据量处理性能不弱于传统关系型数据库和MPP,10TB以上的数据量性能优势更为明显。因此,如图13-1所示的混合架构的大数据处理平台模式逐渐淡出,形成了如图13-2所示的新型应用模式。

江苏银行从经济成本和未来数据的非线性增长趋势的角度分析认为,传统的交易系统运用关系型数据库处理OLTP事务操作,产生的交易数据通过异构数据的批量复制方式或消息队列的准实时方式更新至Hadoop平台,Hadoop平台进行大体量数据的分析和挖掘,并提供基于大数据的应用系统实时检索的模式,与城市商业银行目前的数据架构相适应,决定选择Hadoop平台。

第13章 银行业大数据和人工智能

401

PDF 物理页索引 418

文件中的第 419 页 · 印刷页码:402

  1. 大数据平台选型要点

在对产品化的发布版Hadoop平台选型的过程中,江苏银行总结了以下需重点考量的内容。

性价比和扩展性

前期,江苏银行在IOE传统架构上进行了大量投入,而城商行总体自主可控能力较弱、资产规模较小、盈利能力较低。因此,不论是从自主可控要求的目标出发,还是从降低软硬件成本投入的角度出发,都要求大数据产品需支持在x86虚拟化集群搭建开放和高度并行化的处理平台,既要适应高并发低时延的移动互联网实时数据检索需求,又要满足大体量数据的统计分析与业务建模要求,要求总体技术方案具备高性价比,能够实现在同一服务器集群上针对不同应用动态灵活分配内存、CPU等硬件资源并支持动态扩展,在出现资源瓶颈时能够快速解决。Hadoop产品具有支持x86和可动态扩展的性能,但目前大多数Hadoop平台在不同应用间的资源有效隔离方面都存在一定缺陷。

对 SQL 的兼容性

开源Hadoop对标准 SQL及 PL/SQL支持程度不高,许多常用函数都不支持,需要使用者编写程序实现。而银行以往的数据集市、数据仓库等应用大多基于SQL开发,根据江苏银行的数据架构规划,数据集市、数据仓库将迁移至Hadoop平台,为避免少则几百行多则上万行的程序编写,SQL兼容性成为Hadoop平台选择不可或缺的考虑因素之一。

●对于通用开发框架和工具的支持程度

江苏银行应用系统采用数据库+中间件+应用的三层模式,开发环境为JavaHibernate和Spring框架。为此要求Hadoop平台下的HDFS库、HBase以及内存数据库等组件能够通过ODBC或JDBC连接,以实现数据库对应用开发人员透明,并支持诸如BI、ETL、数据挖掘等工具,数据源可以根据实际需要选择配置Oracle或Hadoop。

●具备事务的基本特性

大数据平台不仅是关系型数据库数据转存储和统计分析的工具,更是一些新型应用,如客户线上行为等的原始数据库。为了确保数据的准确性,数据操作必须具备事务的基本特性:原子性、一致性、隔离性和持久性。Hadoop分布式计算的特点决定其本身不具备事务的基本特性,必须借助插件实现。

● 图分析与流处理能力

银行的实时营销和实时风险预警场景需要大数据平台具有历史数据快速统计、窗口时间内的信息流和触发事件及模型匹配、百毫秒级事件响应等性能,流处理技术是关键。目前,Hadoop平台通用的流处理引擎主要为Spark Streaming和Storm,两者各有千秋,Spark Streaming由时

人工智能与大数据技术导论

402

PDF 物理页索引 419

文件中的第 420 页 · 印刷页码:403

间窗口内的批量事件流触发,Storm由单个事件触发,单笔交易延迟方面,Spark Streaming高于Storm,但在整体吞吐量方面,Spark Streaming略有提升。在进行Hadoop产品选型时,江苏银行主要考量了经过优化的流处理引擎是否能够在流上实现统计类挖掘算法。

●数据存储形式的多样性

要求Hadoop产品至少支持3种数据存储形式:一是行式存储,用于数据由传统数据库向Hadoop数据库过渡;二是基于键值对的存储,用于大体量、高并发数据的实时查询;三是内存式数据库,用于交互式数据分析和挖掘,可通过构建分布式Cube加速性能,也可部分使用SSD代替,程序自动选择存储层。

●多用户多数据库的隔离

商业银行对数据安全非常重视,要求不同来源的数据在Hadoop平台上分库存放,并且为不同用户针对库、表、行的访问分配不同的权限。开源Hadoop平台不具有用户权限概念,许多使用者在Hadoop平台只建一个库,所有应用使用同一个用户名访问资源,数据资源完全开放。这种方式存在严重的安全隐患,预计随着平台重要性的提升,拆分数据库、细分用户权限的需求也将越来越迫切,为避免因前期规划不合理导致后期巨大的拆分工作量,江苏银行在大数据平台选型之初就将多用户多数据库的隔离作为重点考量的因素。

●平台的研发能力和开放性

Hadoop作为创新型技术,与传统数据库相比,技术成熟度不够。江苏银行选择使用产品化的Hadoop,目的在于借助专业技术厂商的强大自主研发和服务支持能力,快速修复技术缺陷,在充分理解银行数据应用复杂需求的基础上,充分发挥产品特性,支持银行业务创新。

●不同数据规模和应用场景下的性能表现

银行业的应用场景及需求较其他行业更为复杂,一些典型的应用场景和主要技术如下:

①用户行为采集分析:数据探头(JS、SDK、Nginx、ICE)、数据分发(Kafka)、离线数据存储及处理(HBase)、运营分析结果展现(MySQL)。

②跨部门数据整合:数据桥接(Sqoop)、日志接入(Flume)、数据分发(FTP)、离线数据存储及处理(HBase、ES)。

③离线用户画像和用户洞察(支持营销):离线数据存储及处理(HBase、ES)。

④实时用户画像及推荐:实时数据处理(Storm、Spark)、数据存储(Redis、MongoDB)。

⑤实时反欺诈:数据接口(API)、数据分发(MQ)、实时数据处理(Storm)。

此外,风险管理领域的应用场景包括实时反欺诈、反洗钱,实时风险识别、在线授信,等等;渠道领域的场景包括全渠道实时监测、资源动态优化配置等;用户管理和服务领域的场景包括在线和柜面服务优化、客户流失预警及挽留、个性化推荐、个性化定价等;营销领域的场景包括(基于互联网用户行为的)事件式营销、差异化广告投放与推广等。

第13章 银行业大数据和人工智能

403