政企运营分析
ESOP
政企物理集市
客服专题、
重入网、
套餐分析、
客户细分、
资费预演、
客服综合运营分析
地市数据分析中心
营销快点、
取数快点、
自助报表
报表库
综合分析类表报\指标库、
持续性离网挽留、
多维成本分析、市场运营监控
大数据平台：为流量经营提供海量数据的存储和分析处理能力。
流量经营的应用还是部署在创新平台上。
互联网内容分析、WLAN运营分析、终端价格提升、
业务识别
流量价值提升
创新应用平台
校园市场、
存量维系、
家庭市场分析 、
客户标签库、
营销跟踪评估、
流量经营
VGOP应用
VGOP集市
TD挖掘平台
一人多号分析
应急库：
主库的备份：
包括数据和应用
片区化管理系统、
收入风险监控、
TD运营分析、
自营厅效益评估、
IMEI分析、KPI
ETL
主仓库
主仓库系统：实现从外围系统抽取，过滤、转换数据，并生成基础模型。
应急库是主库故障条件下的备份生产环境。
对不同流量资费、用户终端、需求偏好的用户群，采取差异化的流量经营策略，实现提升流量规模、提高用户活跃度和提升流量价值的营销目标。
个性化偏好优质的视频推荐，个性化微博社区频道关联订制，提升流量规模
关注的阅读、微博更新，需求应用软件下载，建立用户互动
精细化流量经营支撑系统建设目标
建立一个用户互联网行为分析及应用推广平台
进行用户访问互联网行为分析，掌握用户使用习惯喜好，准确定位用户移动互联网需求，展开精细化流量经营，提升流量价值；
进行移动互联网的自动分类即时热点信息采集，整合优质资源，针对不同用户推广，提升用户活跃度；
支撑全渠道流量经营，建立用户之间传播机制，拉升流量规模增长。
挖掘流量的内涵，建立并丰富移动互联网流量分析主题，为流量经营工作提供科学的决策依据。
由于Megafon比较早认识到话音业务将渐趋饱和，移动宽带业务是支撑未来收入持续增长的关键驱动力。因此Megafon将移动宽带定位为公司级战略，并开展了一系列业务创新举措；
有了流量基础，如何将流量转化为收入呢？Megafon认为关键是做好移动宽带的流量经营，并为此采取了一系列举措：包括激发用户的流量消费，推出了无限上网套餐、热点应用流量套餐、假日郊区套餐；同时，保证高价值用户业务的流量优先和网络公平使用，例如付费流量优于无限流量、无限上网流量限速、P2P流量限控、分时段计费等；
凭借这些，2010年Megafon的移动数据收入增长84%，占收入总增长额的34%；2011年Megafon的移动数据收入增长50%，占收入总增长额的37%，是该公司年收入增长第一贡献业务，并实现了Megafon在俄罗斯移动数据市场的Top1地位。2010年Megafon移动用户数量增长47%，一跃成为俄罗斯第二大移动运营商，2011年用户增长继续领先MTS。
由此可见，欧美发达地区的运营商已经进入流量促收入、收入促流量的正向反馈圈。
网络信令数据：网络侧Gn口信令报文。
实时融合感知：对Gn口信令报文进行采集、解析、预处理，根据用户行为轨迹增强中的配置信息，生成用户行为轨迹清单
内容语义解析&用户行为轨迹增强：接收未完全分类用户行为轨迹清单，爬取内容分类，生成用户行为轨迹增强清单。
库外数据处理：接收增强后的用户行为轨迹清单，接合经分数据进行关联、汇总，生成分析数据
流量数据库：对库外数据处理结果入库，面向业务需求整合数据，生成营销与用户应用结果数据
一、流处理说明
1，数据采集：采集、解析、预处理
在Gn口采用全量数据采集，将Gn口分光器的光信号转换成电信号——通过网卡接收，采集、解析GTP信令数据和流量数据
2，内容匹配
从解析的流量数据中读取一条URL，查询分布式缓存—向用户行为轨迹增强同步发起一次URL分类查询请求——接收分类结果。
发起异步网页分类查询服务
3，触发营销
营销规则配置实时下发——用户行为匹配规则——触发生成事件指令——营销活动派单、下发营销事件指令
二、分布式批处理说明
4，内容语义解析
对用户使用行为数据进行增强操作
对待增强URL进行内容语义解析操作（爬取、分类等）
5，用户行为类数据处理（数据关联聚合）
对增强后的用户行为类数据，进行处理入库
6，用户上下线数据处理（数据关联聚合）
对用户上下线类数据，进行处理入库
1.将原有的两次匹配改造为一次匹配，节约50%系统资源
2.SCA增加的字段：一级域名、完整域名、网站ID、频道ID、行为类型、分类状态、分类json，并将URL字段移至末尾
支持小时、日、月、年粒度；
小时数据不超过1小时；日数据不超过6小时；月数据不超过6天；年粒度不超过15天
手机用户实时位置查询分析系统：
流程：
移动公司网关设备产生数据（通过socke以消息形式发送）
亚信侧对应接口机通过socket连接数据源进行数据采集（就做在spout里）
将数据缓存到kafka消息队列 （你要准备点kafka的知识要点—分布式、可重复消费、副本，持久化。。。。）
用storm-kafka从消息队列消费数据
在storm的topo程序中对消息解析（通过查找内存数据库中的字典表<在内存数据库中：voltDB/redis>将消息中的位置码，通信行为码等转译成更有意义的位置信息,这个逻辑是封装好的）
将解析完成的数据写入内存数据库voltDB/redis，并按时间段(积累到128M)批量持久化到hdfs文件 —（内存数据库中的用户位置数据提供实时页面查询，hdfs中的历史数据传递给离线分析系统为用户画像提供维度数据）
技术要点：
采集机与网关设备的socket之间通过zookeeper实现了动态绑定（分布式锁，状态监控，主备切换，失败切换）
2、手机用户流量详单查询分析系统
流程：
移动公司计费系统产生流量详单原始数据
亚信侧对应接口机通过socket连接数据源进行数据采集
将日志数据缓存到kafka消息队列
用storm-kafka从消息队列消费数据
对流量日志数据进行解析（截取详单原始数据中详单查询所需要的字段并对单条日志的进行计费运算）
将解析之后的详单日志插入hbase数据库（hbase数据库一方面支撑前端页面在线详单查询、分析功能，另一方面，通过mapreduce程序对详单数据进行批量分析（批量分析是在每天凌晨定时运行，产生结果，插入分析报表），提供用户详单页面的“详单分析报表”功能）
技术要点：
亚信数据接收接口机与移动公司网关设备之间的关联是在storm程序启动时动态绑定，利用zookeeper实现
Storm与kafka的整合使用
Hbase的过滤查询、分页查询、协处理器（扩展一下你对hbase的原理的研究，和性能优化）
3、手机用户离线分析用户画像/内容分类分析系统
整体流程：
预处理系统跟外围接口对接，采集数据
并分类清洗合并后上传到SCA<内容识别&行为轨迹增强>的hadoop集群
SCA对用户上网行为日志进行分析：将日志中的url字段解析为相应内容信息(内容识别)，得到行为轨迹增强日志<行为轨迹增强>，然后传给TAS<tas是一个子系统的代号，也是这个开发团队的代号，主要的职责是ETL和业务模型分析>
TAS再将增强日志跟话单、短信日志数据、经分数据<经营分析，是移动公司传统的BI数据>、用户基站定位数据等综合建模分析，得出各种业务模型的统计结果维表
将统计结果数据导入mysql数据库中（定时启动sqoop进行导入），并通过一个web系统进行展示和查询
1、ftp方式采集数据
2、对方ftp服务器上实时不断产生数据（每五分钟一个目录，每分钟若干个文件），按照时间命名规则进行目录和文件命名
3、我方采集接口机上部署预处理子系统程序进行数据采集
4、接口机启动时会通过zookeeper获取分布式锁，然后绑定一台目标ftp服务器进行绑定采集
5、采集的步骤：
主线程启动，定时（扫描周期为10分钟）探测ftp服务器上的目录和文件，判断是否有需要采集的新数据（每次采集都会记录采集的状态）
如果有，则用ftp客户端获取要采集的文件路径列表，然后启动一个线程池下载文件到本地的一个临时目录tmp下，子目录结构及文件名跟ftp服务端保持一致
在本地对文件进行分类（参见《PSCE接口文档》文件名上有类型信息：http/wap/conn/mms/等）和合并（即10分钟内的文件会分类合并）
将合并文件上传到SCA的hadoop集群指定目录下（上传过程中，10分钟批量数据会放入一个“小时父目录”下，“小时父目录”名会带.processing后缀）
当一个小时的数据合并上传完成后，将hadoop中的“小时父目录”后缀更名为.done
并将本地的文件移往备份目录（24小时）
另外还有两个线程：异常文件处理线程（比如ftp服务器上超过时限才到达的数据，文件名有误的数据，空文件，校验和不通过的数据）和备份文件管理线程，具体工作流程参见《预处理流程图》
技术要点
采集程序是一个分布式集群，实现了动态的任务绑定和主备机切换，基于zookeeper
数据采集过程中实现了一定程度上的事务特性：10分钟批次级别的原子性，状态记录及失败回滚
为了后续mapreduce分析的效率，对小文件进行了合并操作（合并之前的小文件大约是100多M一个，合并之后是2G一个，文件blocksize512M，一个小时的数据在sca阶段，处理完成大约12分钟）
细节说明：
1、首先，系统中存在两个知识库：规则库和实例库，里面存放的内容是大量有代表性的URL所对应的网页的内容分析信息，如网页所属的网站、栏目、频道、标题，内容主题，关键词，作者，发表日期，影片名称、导演、主演。。。。。。
2、本子系统的输入数据是预处理送过来的合并日志文件，输出则是增强日志和待爬清单
3、本子系统的运行规则：由一个线程定时监控预处理系统的数据上传目录，发现有.done的文件夹时，获取文件夹列表，并提交一个mapreduce job进行处理，处理完成的两类结果分别写入两个不同的目录
4、处理完一批数据之后，会将这批数据转移到备份目录(hdfs)（3天）
5、mapreduce job的逻辑流程： map task逐行读取合并日志，获取其中的url字段在规则库和实例库中匹配内容分析信息，如匹配成功，则将内容分类信息追加到原日志内容后输出到增强日志目录；否则，只将url字段输出到待爬清单目录；
技术要点：
Mapreduce程序
Mapreduce中访问外部数据库（setup方法中将规则库加载到内存）
自定义outputformat，把不同的处理结果写入不同的路径
语义识别子系统
整体功能说明
抓取待爬清单中url所指向的网页，通过模板抽取和语义识别对网页内容进行分析，得到网页内容信息分析结果，并将分析结果存入“实例库”
流程说明：
子系统启动后会有一个线程扫描待爬清单目录
发现有.done的待爬清单目录，则启动爬虫调度，将待爬清单中的url读入任务队列
驱动爬虫程序nutch|httpclient抓取页面
对抓取到的页面进行分析
首先看该页面是否有对应的“内容抽取模板”
如有，则使用模板匹配方式抽取网页内容信息并存入“实例库”
如没有，则使用“语义识别”模块中的机器学习算法（SVM）对网页内容进行分析、提取主题，关键词，分类，并将结果存入“实例库”
技术要点
定向抓取爬虫系统（线程池任务调度、防封策略<动态代理，分散请求>、权限验证<预置一些账号>，ajax异步信息<人工分析后二次请求或者js解析引擎>,图片信息<OCR模式识别>）
任务队列
自然语言处理（SVM，你可以说成自己熟悉的某种语义分析算法，最好是来自于mahout）
模板匹配的思路，及实现中的xpath和xml技术应用
主仓库：数据来源于BOSS、CRM等源系统，可用空间51.6T，已用空间46T；
应急库：除包含主仓库全部数据外，还包含网络数据，可用空间87T，已用空间60T；
历史库：主要存储主仓库处理后的历史数据，详单保留3+1月，其他数据6-12月不等，可用空间114.8T，已用空间90T。
地市数据分析中心、创新应用孵化平台在集中化的建设过程中为了地市已有应用的迁移，其数据来源除了数据仓库外，还允许从BOSS、CRM直接抽取数据
报表库因先于数据仓库建设，也存在从BOSS、CRM直接抽取数据的情况
数据挖掘平台等集市的数据来源是数据仓库，不存在从BOSS、CRM直接抽取数据的情况
数据分布缺乏规则，数据仓库、各数据集市等共有4份ODS数据，存在冗余，造成空间浪费；
数据交互缺乏统一管理，仓库、集市存在多套ETL工具，接口形式存在文件接口、dblink等多种方式，同时集市违反统一数据源原则直接从源系统抽取数据的情况，不仅反复抽取对BC库造成压力，同时存在数据不一致的隐患，影响数据的准确性；
现有ELT模式将数据在库内进行清洗转换工作，不仅增加了数据仓库的处理负荷，而且导入和导出的动作影响到仓库与集市数据交互的及时性。