1、吴江/蔚来大数据开发&Olap平台 Tech LeadFlink在蔚来的应用实时计算在蔚来的发展历程#1#1实时计算平台#2#2实时看板#3#3CDP#4#4实时数仓#5#5其他应用场景#6#6#1实时计算在蔚来的发展历程实时计算在蔚来的发展历程正在进行实时计算平台2.02021-01实时计算平台1.02019-09引入Flink命令行方式提交和管理2018-05Spark streaming#2实时计算平台实时计算平台1.0YARN作业管理配置管理Metrics监控Flink版本管理集群资源管理告警提交运行停止恢复监控日志实时计算平台1.0实时计算平台2.0YARN作业管理配置管理Metri
2、cs监控Flink引擎版本管理集群资源管理告警开发测试提交运行停止恢复监控Flink SQL权限管理UDF管理日志空间管理资源管理调试#3实时看板实时看板的几个难点数据延迟上报怎么处理数据延迟上报历史和实时怎么统一流批一体多个维度值实时选择维度实时选择实时指标怎么验证指标的验证架构系统信息Mysql DorisDWS可加型指标推送离线数仓DWD实时指标展示推送指标(用于当天 聚合指标)Flink任务websocket拉取指标(用于历史任意时间段聚合指标)前端报表后台用户ID管理(用于前端计算UV)历史指标获取历史指标获取UV指标实时计算实时数仓历史指标展示实时UV统计维度值多选统计实时去重人数
3、UV一个用户可能对应多个城市维度值可以多选维度值在看板前端可以随时更改北京上海深圳实时UV统计维度值多选方案1在Flink状态中存储所有的user id和出现过的维度,并直接计算所有可能的维度组合的UV，并推送更新过的UV给前端缺点-维度爆炸-大部分计算都是无用的，浪费存储和计算资源因为用户选择的维度组合只会是很少的一部分实时UV统计维度值多选方案2-在Flink中计算user id和对应的维度-后台存储每个维度值下的user id list-前端选择维度后，只订阅该维度下的user id增量更新-前端通过set存储所有用户id，实时计算变化的UV数架构user id计算订阅用户张三的前端报表
4、后台北京Flinkuser id 1user id 2.上海user id 2user id 3.user id和对应城市订阅订阅北京+上海user id 1user id 2user id 3.上海user id 2user id 3.用户李四的前端报表订阅实时UV统计维度值多选Q:如果用户量很大，前端是否会占用很多内存?A:前端可以考虑bitmap方案Q:如果同时打开前端看板的用户很多，会怎么样？A:Flink和后台侧几乎没有影响，UV去重的存储和计算，都被分摊到了前端Q:前端会有很大的计算负载吗?A:不会，只有增量的user id会推送给前端，整个过程都是流式的#4CDPCustomer
5、 Data Platform架构Flink Jobs系统信息元信息Mysql DorisElastic SearchTidbOffline Jobs基础标签管理行为标签管理分群管理效果分析营销管理画像管理流量控制运营渠道 1运营渠道 N运营渠道 2.#5实时数仓实时数仓的考量点包括catalog管理元信息管理怎么合理的分层分层和离线数仓的建模方式有什么区别建模时延需要尽可能小链路尽可能短时效性架构元信息管理DWS权限管理DWDRAWDIMAPPLICATION血缘关系数据质量TiDBPGHiveKafka Topic规划中AIOTemporal JoinAIOBroadcast or Temp
6、oral JoinDorisTiDBCatalog管理Catalog功能目前还未开发，未来会考虑所有的数据源对应一个表，屏蔽底层的存储细节和差异结合即将上线的实时计算平台Flink sql功能，效果更好合理的分层分层越多，时延越大实时数据的质量监控，比离线更加复杂，分层越多，出现问题越难定位合理的业务领域垂直划分建模离线数仓，面对的更多是分析师离线数仓，大宽表有利于使用，可能用到的维度尽可能加上实时数仓，大宽表可能意味着更多的维度，更多的打宽操作，时延增加，维度按需添加实时数仓，面对的更多是开发，更偏重于实用时效性是否有专门的raw层，用于公共的CDC如果对接线上业务，倾向于单独的链路，减少时延如果用于内部的业务分析，数据展示，倾向于实时数仓#6其他应用场景#1CQRS类应用，比如统一实时搜索服务，统一用户视图指标监控，异常检测#2
sgpjbg002
工作日 8:30 - 17:30
报告分类
