Spark平台在电信运营商的应用实践.pdf
《Spark平台在电信运营商的应用实践.pdf》由会员分享,可在线阅读,更多相关《Spark平台在电信运营商的应用实践.pdf(31页珍藏版)》请在三一文库上搜索。
1、Spark平台在电信运营商的应用实践 亚信大数据平台 田毅 目录 项目实践分享 基于Spark改造用户标签分析查询平台 基于Spark Streaming改造内容识别处理平台 一些心得分享 如何用好External DataSource API 高效的在Spark Streaming中引用外部数据 基于Spark改造用户标签分析查询平台 3 TCL脚本 基于Spark改造用户标签分析查询平台 改造前的设计 4 数据库 指标表 通信数据 上网数据 数据清洗指标计算标签计算 标签表接口表 用户 数据探索客户群计算 SQL 基于Spark改造用户标签分析查询平台 改造前的问题 1 标签数量越来越大,
2、数据库负载过高,扩展成本高 2 标签表的列数随着标签数量增加不断增多,部分现场达到2000+,只能通过分表的方式解决,查 询时需要Join操作 3 标签与指标的计算无法摆脱SQL的约束,无法快速集成机器学习的算法 TCL脚本 基于Spark改造用户标签分析查询平台 第一次改造设计: 小试牛刀 6 数据库 指标表 通信数据 上网数据 数据清洗指标计算标签计算 标签表接口表 用户 数据探索客户群计算 SparkSQL HDFS 基于Spark改造用户标签分析查询平台 改造后的好处 1 使用SparkSQL Parquet的方案,有效保证了查询效率 2 原有系统基本不用太大改造 3 查询系统具备平行
3、扩展能力 未解决的问题 1 标签与指标的计算无法摆脱SQL的约束,无法快速集成机器学习的算法 产生出来的新问题 1 增加了从数据库倒出数据,加载到HDFS的额外步骤 2 增加了从文本数据转化为Parquet格式的额外步骤 SparkSQL 基于Spark改造用户标签分析查询平台 第二次改造设计:大刀阔斧 8 HDFS 指标表 通信数据 上网数据 数据清洗指标计算标签计算 标签表接口表 用户 数据探索客户群计算 SparkSQL 基于Spark改造用户标签分析查询平台 改造后的好处 1 通过SparkSQL替换掉了原有的数据库,整个系统的扩展性进一步增强 2 两套SparkSQL可以根据各自忙闲
4、时的不同,共享整个系统的计算资源 遗留的问题 1 没有摆脱标签分析算法对于SQL的依赖 2 系统前端仍然依赖ETL系统对数据进行抽取加载 怎么破? 基于Spark改造用户标签分析查询平台 Spark 1.3.0 发布了 External Datasource API进一步增强 DataFrame提供了丰富多样的数据源支持 DataFrame提供了一整套用于操纵数据的DSL 外部系统 Spark Applications Based on DF 基于Spark改造用户标签分析查询平台 第三次改造设计:更进一步 11 HDFS 指标表 数据表1 数据表2 指标计算 标签计算 标签表 用户 数据探索
5、客户群计算 SparkSQL ExtDataSour ce 按需抽取数 据 原有SQL转化 为DF的API 基于Spark改造用户标签分析查询平台 改造后的好处 1 终于摆脱了对SQL的依赖,为后续引入复杂算法分析打下基础 2 利用External Datasource API可以根据计算需求从源表抽取指定的数据 3 基于DF的处理程序代码量仅有原程序的1/10,可读性大大提高 遗留的问题 1 如何控制对源数据库的压力问题 = 时间窗 2 Ext DS的实现对于不同的数据库类型需要进行细致的优化 基于Spark Streaming改造内容识别平台 内容识别平台功能介绍 产品目标:通过对上网日志
6、的分析还原用户上网时的场景 用户上网记录 入口识别: APP还是浏览器 应用识别: 微博,微信,UC URL内容识别: 新闻,体育 MapReduce Job Map Task 基于Spark Streaming改造内容识别平台 改造前的设计 上网数据输出目录输入目录 Distribute Cache 数据分析 后续系统 标签分析 日志查询 营销活动 识别规则 识别规则 基于Spark Streaming改造内容识别平台 改造前的问题 1 数据处理延迟较高 2 需要频繁加载规则数据到内存 3 数据源逐渐变为实时接口 Spark Streaming DStream.map() 基于Spark S
7、treaming改造内容识别平台 改造前的设计 上网数据 Kafka Broadcast 数据分析 后续系统 标签分析 日志查询 营销活动 Kafka input topic output topic 识别规则 将原有的HDFS 改为Kafka接口 MR引擎换为 Spark Streaming 原有MR的Map处理逻辑 迁移到DStream的map 方法 规则数据改为通过 广播发布到所有的 Executor 基于Spark Streaming改造内容识别平台 改造后的好处 1 数据分析的代码逻辑几乎没有修改, 兼容了原有的HDFS文件接口 2 规则数据只需要一次加载,可以长期保存在execut
8、or的内存中 3 通过kafka spark streaming实现了流式处理的要求 4 数据处理延迟从原有的分钟级别降低到秒级 改造过程的经验 1 序列化问题 = 使用Kryo序列化需要注意先注册 2 流处理框架和业务逻辑两部分代码建议完全隔离 3 业务逻辑可以保持java的实现方式,通过反射等方式调用业务逻辑的代码 如何用好External DataSource API External Datasource API 是Spark 1.2.0版本中一个重要的feature 赋予Spark平台高效灵活访问外部数据源的能力 我们日常的使用中也经常会遇到数据存在于多个数据源之中的场景 如何使用E
9、xt DS的API来实现对多个数据源的支持呢? 让我们用HBase作为外部数据源举个例子 18 如何用好External DataSource API 网上已经有很多HBase的Ext DS的实现,如: https:/ https:/ 我们简要的分析一下实现HBase的Ext DS的几个要点 Task Task Task Task Executor Executor Region Region Region Region RegionServer RegionServer 如何才能达到这样的实现呢?我们先来看看External DS的设计原理 如何用好External DataSource A
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Spark 平台 电信 运营商 应用 实践
链接地址:https://www.31doc.com/p-3331049.html