2017全球互联网技术大会 互联网金融 Fintech场景下大数据处理的挑战与实践

2017全球互联网技术大会 互联网金融 Fintech场景下大数据处理的挑战与实践

ID:8141735

大小:1.38 MB

页数:16页

时间:2018-03-07

2017全球互联网技术大会 互联网金融 Fintech场景下大数据处理的挑战与实践_第1页
2017全球互联网技术大会 互联网金融 Fintech场景下大数据处理的挑战与实践_第2页
2017全球互联网技术大会 互联网金融 Fintech场景下大数据处理的挑战与实践_第3页
2017全球互联网技术大会 互联网金融 Fintech场景下大数据处理的挑战与实践_第4页
2017全球互联网技术大会 互联网金融 Fintech场景下大数据处理的挑战与实践_第5页
资源描述:

《2017全球互联网技术大会 互联网金融 Fintech场景下大数据处理的挑战与实践》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库

1、Fintech场景下大数据处理的挑战与实践徐佳晶@人人贷互联网信贷事业群GITCNov.20172!AGENDA01我看互金这6年02风控:传统金融VSFintech03技术团队面临的挑战•业务/获客方式的转变•人VS机器•数据量•用户数、交易数的激增•评分卡VS模型•计算复杂度•风控思维的转变•从业人员skillset•服务可靠性04经验&实践05再过三五年……•由一起线上事故说起•行业•Kafka•政策•HBase•团队•其它•技术3!业务/获客方式的转变"#$线下网点,业务人员地推电销互联网方式插卡、陌拜、线下活动……电话外呼渠道、合作、流量交换•开设线下门店,配

2、置业务人员•客户名单获取•更偏向互联网获客模式,导流、引流、精准客户营销、投放•增加门店、提高人均产能•扩大规模、提高名单质量、提升电销人员效率、优化外呼策略•提高转化率、合作渠道数量与质量•核心业务系统•CRM•中间件、系统群、云、大数据环境……4!用户数、交易数的激增201220132014201520162017Q3%第一单!第一千单!第一万单!&10亿!50亿!100亿!……新增50万用户/月,10亿/月5!风控思维的转变“本人”、“真实意愿”、“借款用途”、“还款意愿”、还款能力”人工审核每一个客户01部分应用外部数据电核、面审、实地,以确认用户填02写的信

3、息的真实性为主要依据人工搜索开放数据结合联系人交叉验证一些行业内部黑名单,精准命中对接专业三方数据03自动化数据验真主要用于信息验真04面部识别、身份证比对、活体检测三方数据公司的崛起大量外围数据交叉验证自动化审核05将三方数据引入模型直拒、直批+人工审核“团伙识别”全自动化审核06关系图谱6!风控:传统金融VSFintech"'人VS机器评分卡VS模型从业人员skillset•50件/人/天VS5000件/小时,全年无•feature有限,调整权重,谨慎VS大量数•行业经验VS数据分析、挖掘能力休据维度&调整极快且“浪”•银行(信用卡、抵押贷)、小贷、保险•培训、初

4、审、终定、质检……VS只要没•半年一次迭代VS一周多次迭代&AB相关从业经验VS机器学习、神经网络、bug、机器够TestAI•套用规律、借鉴规律VS发现规律、验证•金融、统计相关专业VSCS规律、学习规律•SAS、SQL、ExcelVSPython、MR、模型稳定、固化,模型不可识别的都为Hive、Spark、R异常VS识别与模型的差异并进行非监督学习,发现新的模型7!技术团队面临的挑战几百张表*几十列;百万行;二维,范式建模(数据量几十张表*几千列;千万行起;稀疏、维度建模+5TB/月(压缩后,40%)“在10000用户间建立单向关系网络”“在100万用户间建立双向

5、关系图谱”计算复杂度)“从短信中筛选特定关键字。样本不多,大概2000多万”“目前系统压力大,通知前线,压一下进件量”服务可靠性“系统需要加硬盘,周末停机维护”24*365,SLA8!系统架构演进“ABC”+“传统”互联网阶段大数据阶段AI阶段关系型数据库*Hadoop生态集群*混合云/公有云DAS、SAN、NASNoSQLGPU,混合体系架构中间件私有云系统集群,HA、LB9!“金融”互联网VS“互联网”金融○*RESTAPIMRHiveSparkRedisKafkaStream.MongodbKafka,&HBasehHDFS10!一次线上事故Ka!a队

6、列积压随着业务量的增加,Kafka队列的积压问题日益频繁且严峻。除了Kafka本身的运维优化外,通过监控发现网络架构问题,最终调整解决平时活动线上参数调优Consumer异步处理过时消息丢弃网络限流问题解决11!Kafka~100MPS;95th消息大小:~500KB;95th消息处理时长:~0.7s;95th消息延迟:~1.2sPartition/Consumer规划消息压缩参数调优•Partition越多越好?•压缩协议:gzip、snappy、lz4?无压缩•吞吐VS延迟Kafka借助partition提升并发能力吞吐最高?•ProducerPartitio

7、n内消息有序,而partition间顺序•考虑客户端的是否支持,Java、PHP、max.request.size无保障batch.sizePython……•Producer发送消息时注意partition倾斜•Consumer(murmur2)session.timeout.msfetch.min.bytes•Consumer数量略多于partition数量fetch.max.wait.ms12!HBase数据量:~20TB;读取:~2,000RPS,L1:400RPS,L2:~200RPS012集群/Region规划Rowkey设计C

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。