报告预览

4-2 Akulaku 智能计算系统及应用.pdf

编号：102484

PDF 32页 3.50MB 下载积分：VIP专享

下载报告请您先登录！

4-2 Akulaku 智能计算系统及应用.pdf

1、大数据计算架构峰会DataFunSummit2022.04.23（周六）09：0017：202021AkulakuAkulaku智能智能计算计算系统及系统及应用应用DataFunSummit黄泓资深算法开发工程师2022|CONTENTS目录场景与需求Akulak业务和相关背景01难点智能计算系统实现的难点02案例与架构智能计算系统的实现细节03总结我们学到了什么04DataFunSummit|Subject01背景Akulaku的场景与需求DataFunSummit|Akulaku的场景与需求DataFunSummit|Akulaku是一家主打海外市场的互联网金融服务提供者，服务内容包括网

2、上购物和分期付款，现金贷，保险等等。主要的应用场景包括金融风控，电商智能客服以及电商推荐等等总体架构DataFunSummit|对接业务的上层应用以及各层服务之间的关系如下Subject02难点智能计算系统构建的难点DataFunSummit|核心难点DataFunSummit|线下分析线上部署高吞吐量低延时时效性好，尽可能快地反映数据变更逻辑一致线下分析和线上部署的逻辑需要完全一致特征和模型的类别DataFunSummit|时间窗口类群组关联类举例：近X天的XX个数举例：近X天同一团伙所有成员的订单个数关联关系类K度图查询，特定子图模式机器学习模型序列模型举例：xgboost举例

3、：TCN 深度NLP模型BERTSubject03架构与案例智能计算系统的实现DataFunSummit|特征的计算：两种计算方式DataFunSummit|场景驱动数据驱动业务调用环节驱动，调用时计算结果底层数据驱动，数据变更时计算，调用和计算解耦案例一：时间窗口DataFunSummit|需求：近XX天的订单个数场景驱动？要求实时更新，时间窗口实时滑动下单环节延时不能超过200ms后续会有复杂的关联需求，比如“团伙内近3天订单个数”一个简单的想法：直接在关系型数据库里面怼sql问题：延时不可控，在极端情况下有可能超过200ms 数据驱动？尝试用Flink计算引擎实现滑动窗口的逻辑Sel

4、ect count(*)from orderswhere create_time=current_time-3*24*3600*1000 案例一：时间窗口（Flink的滑动窗口？）DataFunSummit|Flink滑动窗口问题：步长窗口大小步长窗口大小在滑动窗口操作中，Flink会生成窗口大小/步长个窗口如果步长窗口大小，窗口对象会过多，导致过慢或者OOMFlink的滑动窗口并不能真正的滑动社区进展：无案例一：时间窗口（基于Flink CDC的方案）DataFunSummit|基于变更的数据计算（1）使用中间存储保存窗口表，对于新进入的数据，只维护近X天的数据（2）Flink c

5、dc捕捉窗口表的变更，计算出最终结果案例一：时间窗口（Flink SQL的方案）DataFunSummit|Flink CDC的方案（1）Flink cdc有sql支持，但是sql并不直观（2）必须依赖中间存储，吞吐量和灵活性不够真正滑动的窗口复用Flink的高可用和状态管理，同时实现灵活的入窗出窗操作思考的基点：Dynamic Table案例一：时间窗口（Flink SQL的方案）DataFunSummit|起点：流式去重假如有如下数据流，每个产品product_id的我们要获取每个产品最新的价格（product_id:1,price:2 ,update_time:100L）（produ

6、ct_id:1,price:3 ,update_time:200L）（product_id:2,price:3 ,update_time:1000L）（product_id:2,price:4 ,update_time:1201L）（product_id:2,price:3.5 ,update_time:1100L）SELECT*FROM(SELECT product_id,price,ROW_NUMBER()OVER(PARTITION BY product_idORDER BY update_time DESC)AS row_numFROM product)WHERE row_num=1案

7、例一：时间窗口（Flink SQL的方案）DataFunSummit|第二步：时间窗口还是这个数据流，站在A这个位置，看近100ms有更新记录的product的最新记录（product_id:1,price:2 ,update_time:100L）（product_id:1,price:3 ,update_time:200L）（product_id:2,price:3 ,update_time:1000L）（product_id:2,price:4 ,update_time:1201L）（product_id:2,price:3.5 ,update_time:1100L）A站在A的截面，看到的

8、应该是这个（product_id:2,price:4 ,update_time:1201L）案例一：时间窗口（Flink SQL的方案）DataFunSummit|第二步：时间窗口（product_id:1,price:2 ,update_time:100L,is_valid:1）（product_id:1,price:3 ,update_time:200L,is_valid:1）（product_id:2,price:3 ,update_time:1000L,is_valid:1）（product_id:2,price:4 ,update_time:1201L,is_valid:1）（pro

9、duct_id:2,price:3.5 ,update_time:1100L,is_valid:1）在product_id1的数据应该出窗的时候，需要多发射回撤的记录对应发射的is_valid=0,且时间戳+1的信息（product_id:1,price:2 ,update_time:101L,is_valid:0）（product_id:1,price:3 ,update_time:201L,is_valid:0）（product_id:2,price:3 ,update_time:1001L,is_valid:0）案例一：时间窗口（Flink SQL的方案）DataFunSummit|第二

10、步：时间窗口还是这个数据流，站在A这个位置，看近100ms有更新记录的product的最新记录（product_id:1,price:2 ,update_time:100L,is_valid:1）（product_id:1,price:3 ,update_time:200L,is_valid:1）（product_id:2,price:3 ,update_time:1000L,is_valid:1）（product_id:2,price:4 ,update_time:1201L,is_valid:1）（product_id:2,price:3.5 ,update_time:1100L,is_v

11、alid:1）问题：怎样发射出窗的记录？SELECT*FROM(SELECT*FROM(SELECT product_id,price,ROW_NUMBER()OVER(PARTITION BY product_idORDER BY update_time DESC)AS row_numFROM product)WHERE row_num=1)WHERE is_valid=1案例一：时间窗口（Flink SQL的方案）DataFunSummit|第二步：时间窗口SELECT*FROM(SELECT*FROM(SELECT product_id,price,ROW_NUMBER()OVER(PA

12、RTITION BY product_idORDER BY update_time DESC)AS row_numFROM product)WHERE row_num=1)WHERE is_valid=1维护两个数据结构：（1）一个MapState，key为时间戳，value为Row的List，这个状态由Flink管理（2）一个优先队列，维护在内存中，只包含时间窗口内的数据的数据时间同时还保留一个watermark变量每处理一条数据，进行如下操作（假设时间窗口为m）：（1）维护watermark，记录当前的水位（2）将当前记录的时间戳加入优先队列（3）从优先队列中退出watermark-m以外

13、的时间戳，在MapState中取出这些时间戳为key的row，将时间字段+1，将is_valid置为0案例一：两种数据驱动的方案对比DataFunSummit|Flink CDC思路：（1）使用关系型数据库作为中间存储（2）数据变更通过中间状态的变更触发最终数据的更新优点：（1）便于状态的初始化（2）运维比较稳定方便缺点：（1）依赖外部数据库性能（2）虽然有sql，但是和线下回溯的sql差异比较大，不易理解 Flink SQL思路：（1）使用Flink SQL动态表的抽象（2）使用优先队列和MapState管理数据过期数据的出窗优点：（1）尽可能复用Flink的特性，包括状态管理（2）SQL语

14、义与回溯比较接近，便于做流批一体缺点：踩着Flink特性的边界来做案例一：时间窗口（基于openmldb）DataFunSummit|场景驱动的调用可以使用openmldb，更加高效地“现用现算”（product_id:1,price:2 ,update_time:100L）（product_id:1,price:3 ,update_time:200L）（product_id:2,price:3 ,update_time:1000L）（product_id:2,price:4 ,update_time:1201L）（product_id:2,price:3.5 ,update_time:110

15、0L）SELECT COUNT(*)FROM w100msWINDOW w100ms AS(PARTITION BY product_id ORDER BY update_timeROWS_RANGE BETWEEN 100ms PRECEDING AND CURRENT ROW)思路：（1）用空间换时间使用持久化内存，避免RocksDB的写放大和读放大（没有Level）（2）使用SQL作为离线和在线的桥梁场景驱动（openmldb）和数据驱动（flink cdc）性能对比DataFunSummit|（1）数据量：10亿/天（2）openmldb:3x256G三节点集群（3）一天内的窗口特征，

16、openmldb和直接读polarDB的延时基本相同（4毫秒左右）（4）两者性能基本相当场景驱动和数据驱动的对比DataFunSummit|场景驱动思路：现用现算，在调用时计算优点：（1）实现简单（2）线上线下容易保持一致，回溯容易缺点：（1）硬件依赖性比较高（2）维护业务稳定性比较有挑战数据驱动思路：数据变更时计算，调用和计算解耦优点：（1）业务调用时间与计算时间无关，业务可用性高（2）计算结果与场景无关，一次计算，多场景调用缺点：（1）复杂性较高（2）线上线下逻辑不容易保持一致（3）会有大量无关的数据两种计算方式在架构中的位置DataFunSummit|场景驱动：openmldb数据驱动

17、：flink+rocksDB/polarDB优点：1.海量任务调度能力2.毫秒级别的延迟3.异构任务的支持4.任务拓扑图动态修改的能力DataFunSummit|Ray介绍应用：自动特征工程AutoML:超参搜索通过AutoML,迁移学习等能力在新风险环境或新业务环境下快速上线/更新模型，保持风控水平案例二：场景Pipeline数据流进入系统后，每经过一个策略节点或模型推理节点，会根据该节点的输出动态的进行下一步分支的执行，基于动态图actor调度的优势在于只需实现几个必须组件（如右图），节约大量编码。基于ray的另一个优势是轻松实现单数据流多策略差异化并行执行的方式，是生产的大规模在线学习式推理任务或ABtest类推理任务极具智能化的解决方案。案例三：使用基于Ray的动态控制流设计模型推理决策系统DataFunSummit|架构中的位置DataFunSummit|Ray+autoMLSubject04总结我们学到了什么DataFunSummit|总结DataFunSummit|场景驱动和数据驱动的特征计算方式有各自适用的场景 Ray本身是作为一个轻量级的python分布式框架使用，作为我们机器学习平台中数据科学和机器学习的底座，承接前面生成的特征生成模型THANKS！今天的分享就到这里.Ending2022DataFunSummit|

友情提示

1、下载报告失败解决办法
2、PDF文件下载后，可能会被浏览器默认打开，此种情况可以点击浏览器菜单，保存网页到桌面，就可以正常下载了。
3、本站不支持迅雷下载，请使用电脑自带的IE浏览器，或者360浏览器、谷歌浏览器下载即可。
4、本站报告下载后的文档和图纸-无水印,预览文档经过压缩，下载后原文更清晰。

本文（4-2 Akulaku 智能计算系统及应用.pdf）为本站（云闲）主动上传，三个皮匠报告文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若此文所含内容侵犯了您的版权或隐私，请立即通知三个皮匠报告文库（点击联系客服），我们立即给予删除！

温馨提示：如果因为网速或其他原因下载失败请重新下载，重复下载不扣分。

上海品茶

4-2 Akulaku 智能计算系统及应用.pdf

4-2 Akulaku 智能计算系统及应用.pdf