湖北移动大数据技术交流 - Oracle · 关键技术架构总结：强大的开发集成能力关系型数据库仍然是王道（支持前台分析和查询）难点：Sharding分库：开发、扩展、拉关系

湖北移动大数据技术交流

娄恒

Exadata资深解决方案顾问

Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 12 2

议程

大数据范畴和参考架构

大数据平台典型案例

大数据的各种技术特点和发展趋势

Oracle端到端大数据平台方案

什么是大数据？具有4V特性的数据称为大数据

• 巨大的数据量(Volume) • 海量的话单信息（语音话单、短信话单、GPRS话单）

• 海量信令信息（用户位置信息、开关机信息、异常断线信息）

• 互联网网关信息（URL信息、查询关键词)

• 社交媒体、M2M数据

• 多结构化数据(Variety) • 短信文本信息

• CallCenter投诉信息

• DPI/WAP日志/WEB日志/电渠点击流/社交媒体

• 增长速度快(Velocity) • 信令数据、话单信息、互联网数据增长速度很快

• 业务上需要能够对客户行为进行快速的分析(Fast Data)

• 低价值(Value) • 单条的数据没有太大的价值，需要基于对大量数据的挖掘与分析才能发现隐藏在数据

背后的“客户特征”巨大的数据量

VOLUME

VELOCITY

VARIETY

SOCIAL

BLOG

SMART

METER

VALUE

10110010100100100

11010101010111001

01010100100101


对大数据建设的观点

以前实时交易数据被看作为应用的血液，非结构化的碎片化数据看作为应用的排泄物；大数据给我们带来的价值是把许多信息碎片拼起来，更好地洞察客户、发现规律，为我们的决策来服务。

以前数据依附于具体业务而存在，在大数据时代，数据可以作为一种独立的存在，数据的―资产‖性价值越来越引起人们的重视。从业务引领数据发展为数据驱动业务；

大数据时代最大的挑战是如何从大数据中获取―价值‖。从大数据中获取最大价值，

需要探索式的研究方法。大数据环境中，数据科学家职责会产生，这种科学家既要熟悉商业环境，也要有操作层面的知识。

大数据价值链的三个C即(Collect—收集、Consolidation—整合、Consumptions—

消费)。对大数据技术进行规范是问题的关键。从强调监管大数据的收集，转向重点监管大数据的实际使用。


建设大数据平台必需要回答的问题

选择和构建怎样的数据架构？

– 不同的技术路线：RAC、MPP、 Sharding、 Hadoop、NoSQL、流技术……

– 不同的数据类型：交易数据、信令、网络日志、VAS、外媒信息

– 不同的应用需求：交易、查询、分析、数据服务

怎样挖掘丰富的数据价值？

– 例如：信令数据--位置、住址、工作地、行为特点、兴趣喜好、轨迹、交往圈、…

– 项目式建设 vs 开放平台、百花齐放

5


系统参考架构

跨SQL和NoSQL

平台的数据集成

高并发、实时化的数据访问

数据加工平台（数据工厂）

实时流数据处理

批量数据处理

数据服务平台（数据超市）


数据工厂-Hadoop定位：离线数据批量处理


数据超市-SQL数据库：数据查询服务

MyFOX是一个针对OLAP能力设计的高性能分布式MySQL集群中间层，目前单集群存储容量达100TB，日均请求量超过1亿。

由亍底层的分库分表

设计，造成前端数据

读写业务受到限制，

从而要求前端业务牺

牲一定的灵活性和自

由度。


SQL虽牛，但是…

如果继续用SQL来存储数据，怎么建索引？


数据超市-NoSQL定位：历史数据实时计算和查询

□ 为了获得数据快速访问

• 明细数据大量冗余

• 通过API接口去操作HBase

□ 牺牲磁盘容量，以得到

• 避免明细数据网络传输

• 变大量随机读为顺序读

□ NoSQL是SQL的有益补充

□ 历叱数据的实时计算

□ 空间换时间


数据超市-数据应用：多租户的产品数据集市

自由的计算能力

支持标准SQL语法

支持order by/group by/limit

支持大表Join

支持常规的统计分析函数（count/sum/avg/max/min）

支持distinct

支持常规的数学、字符串、日期函数

Copyright © 2013, Oracle and/or its affiliates. All rights reserved. Insert Information Protection Policy Classification from Slide 12 12 12

淘宝数据的发展方向：实时化、高并发、差异化


对数据操作的“分而治之”

13

数据结构的去模式化、简化了数据关联访问

需要牺牲部分业务作为代价

增加应用逻辑的处理过程


数据一致性存在问题

数据分割后，数据一致性维护越来越困难，非重要业务需要牺牲


关键技术架构总结：强大的开发集成能力

□ 关系型数据库仍然是王道（支持前台分析和查询）

难点：Sharding分库：开发、扩展、拉关系

□ NoSQL是SQL的有益补充（实现Cube功能）

难点：通过大量数据冗余避免网络传输和随机读

□ 用中间层隔离前后端

难点：异构数据源的整合

□ 缓存是系统化的工程

难点：数据一致性、穿透不雪崩


议程



– 福建移动：大数据中心

– 广东移动：Data Store

– 江苏移动：数据中心




福建移动放弃原有技术路线，转向新一代技术平台业务能力优化

• 原MPP平台无法满足业务对混合负载、高并发要求

• 通过数据库云实现快速业务部署

技术能力提升

• 性能提升15倍、加载提高10倍、压缩比提高5倍

• 与生产Oracle无缝对接，实现实时数据加载和分析

购买成本

• Teradata 31节点，共购买了5次，累计投资额超过1.6亿，每次投资超过3000-4000万，年均投资2000W

• Exadata 2台，年均投资低于1000万

维保和运维

• 2013年约下降40%，2014预计将进一步下降

• 与其他Oracle平台统一化维护、管理、备份，降低间接运维成本

0

100

200

300

400

500

600

700

800

2012 2013 2014

每年维保费用（万元）

Oracle

Teradata

59.29%

40.10%

0.62%

性能提升百分比

15倍以上

5-15倍

5倍以下


Exadata演进为企业级大数据中心平台

根据NG-BASS系统逐步向企业级大数据中心平台演进策略不目标，总体系统演进将分阶段推进实施，第一

阶段搭建企业级大数据中心平台系统框架不管理平台，同时满足2014年底大数据分析要求的系统能力。根据我省

经分系统现状以及近期正在实施流量经营基础数据支撑平台情况，对标企业级大数据中心平台目标系统架构，明

确系统建设内容。

备注：红色部分新建黄色部分提升绿色部分已建


福建移动账务系统：原数据库负载特点

生产系统特点，最高的等待事件为索引读，为传统OLTP应用，平均IO响应时间为2毫秒。

DB CPU, 26.04%

User I/O, 68.27%

System I/O, 5.12%

Commit, 0.32%

Network, 0.24%

数据库时间分布

DB CPU

User I/O

System I/O

Commit

Network

传统小型机加存储，硬件配置如下：

服务器：2台IBM Power7 780，构成HA,，每台配置

处理器：32核（Power7 主频3.92GHz）

内存： 256GB

存储：配置1台EMC VMAX10K，使用SRDF-A异步存储复制到容灾端

内存： 128GB （镜像后）

磁盘：RAID10

磁盘个数：81个 300GB 15K RPM（其中9个hostspare)


对比项 IBM+EMC Exadata 提高倍数说明

CPU资源利用率 10% 4.5% 2.23 CPU资源利用率低，CPU 利用率下降2.23倍

DB Time 29958 10068 2.98 整体数据库时间缩短2.98倍，主要为IO等待大大得到降低

User Calls 4,460.99 4,111.0 1.09 调用次数基本相同

IOPS 5912 8179 0.72 部分SQL使用smartscan进行扫描

MBPS 113 125 0.90

CPU Time 9482 5048 1.87 smart scan过滤有关系，说明intel cpu的处理能力不低于小型机

I/O Total Wts 10,314,882 8,964,534 1.15 IO Wait次数较少了13%，得利于Exadata smartscan优化

I/O Wait Time(s) 24,859 3,525 7.05 总体IO Wait时间缩短7倍，平均IO Wait时间缩短6.18倍，主要是

Exadata 对于随机IO的性能高

Avg I/O wait (ms) 2.41 0.39 6.18

福建移动账务系统：详细数据库指标对比


福建移动：新一代融合计费系统

ExaData

综合账务

并行OCS离线计帐

在线控制

Ocs在线话单

融合计费

在线预增累计量(会话+分单+值)

离线采集预处理

离线话单ORACLE

会话的余额变更记

录余额更新

在线话单生成

（分通道）

帐本、余额

已增累计量会话(会话+

分单)

累积量

预锁、预扣余额(会话+分单+值)

已扣余额会话(会话+分

单)

帐本、余额

累计量更新，根据话单时间解锁

I/U：查询累计量

T/切单：预增累计量

GoldenGate同步余额、已

扣会话

GPFS共享文件系统

在线提醒请求

离线提醒请求

GP数据库

在线话单

在线标记离线话单

在离

线话

单入

到GP

数据

库

在离线稽核明细

话单稽核

在离线话单迚行稽核生成不一致结果明细

离线帐务处理

生成

在线

标记

稽核

话单

离线话单

旧OCS

在线控制

Ocs在线话单

在线话单生成

（分通道）

在线话单文件

生成并行数据

网元GGSN/集团网状网

网元GGSN（修改1台GGSN连接）

消息

消息


议程









项目背景

23

应用无法复制

厂商能力难以评估

存在的问题

功能重复建设

数据一致性差系统运维难度大

统计口径不一致

现在省公司和各地市公司均有大量的信令系统，而现有信令系统皆为“烟囱式”系统。这种烟囱式系统带来诸多的问题：

数据分散存在不同的系统中，形

成数据孤岛，数据的完整性、一

致性无法保证

大量的功重复建设，造成运算资

源和存储资源的浪费；原始信令

多处接收，造成带宽的浪费

数据与应用深度耦合，各系统间

的应用无法复制

无法对厂商的能力迚行评估，后

期项目时还需重新迚行厂商选型

和评测

省公司、各地市公司存在众多系

统，运维管理难度很大

各系统的口径不一致，导致数据存在差异


信令分析平台架构设计思路

24

分层设计数据共享

应用复制量化评估实现应用的准入、退出机制，并实现快速复制，类似于APP Store 的功能

按照功能聚类划分，分层设计，各层间实现松耦合，实现有效的系统集成

为了解决目前存在的问题，从快速支撑信令应用的角度出发，借鉴业界、广东移动相关系统的建设经验，信令分析平台架构

设计遵循以下的思路：

根据应用的复制和使用情况，对厂商进行量化评估，便于后期选择合适的厂商参与建设

统一编解码，为所有实时应用提供实时数据；建设数据共享层，统一为分析型应用提供数据


广东移动数据库云平台：Data Store

采集层

编解码子层

共享层

应用层

信令应用

CS域原始信令采集

信令原数据处理实时

编解码

合成预统

计

CS域编解码系统信令原数据处理实

时编解

码合成

预统计

PS域编解码系统

企业服务总线（ESB）

各地市个性化分析应用全省公共分析应用

数据提供接口应用服务接口

1个省级数据仏库全省汇总数据

实时应用

统一数据加载（ETL）


PS域原始信令采集

全省聚合数据

运营管理应用容器应用分析应用订购应用评估

数据共享层

数据关联数据聚合数据计算数据汇总

广州集市深圳集市湛江集市 … 21个数据集市

数据共享平台（21+1模式建设）

• 应用层：提供统一的门户、开发环境、服务组件，实现应用标准化。

• 共享层：采用1+21模式，分为信令编解码子层和数据共享子层。信令编解码子层用于原始信令的编解码、关联、处理、存储。数据共享子层用于XDR

的存储、统一的数据模型提供及API接口，对外提供信令数据，实现信令处理及共享功能。

• 采集层：实现核心网和无线网的统一采集。核心网采用全采部分监控的方式。无线网Abis接口实现重点区域采集和动态采集的方式。

• 基亍“数据统一共享、应用快速复制”原则，规划技术部不网维中心共同设计提出了信

令分析平台的总体架构，此架构得到了公司领导讣可。


构建与App Store类似的Data Store运营模式标准化组件提供、多租户应用开发、插件式管理、后向支付、长尾市场与热门市场

客户画像

客户挽留

离网分析 IMEI终端

分析

呼叫

指纹

信息服务云平台（Data Store）

交叉/提升销售

收入

保障

插入式组件价格计

划优化

位置能力

终端能力

客户喜好

行为特点

流量实时热点


Data Store业务框架（21+1方案）

数据共享子层

应用层

应用孵化文件数据共享

应用孵化数据存储区


成熟应用

数据库视图固化API 文件推送接口

数据存储按照支持应用的丌同分为两部分： 1、应用孵化数据存储区：支持各地市的应用的个性化开发。数据存储机制：存放“试点”地市的明细数据、汇总数据和聚合数据，其中明细数据存放7天； 2、应用发布数据存储区：支持各地市和全省发布的应用。 “21+1” 数据存储机制：按21地市存放各自的明细数据、汇总数据和聚合数据；按全省存放全部地市的汇总数据和聚合数据；其中明细数据存放30天；

应用发布数据存储区

明细数据存储7天明细数据存储30天

个性化API

广州深圳

揭阳于浮

….. …..

广州深圳

揭阳于浮

….. …..

广东全省提供三种业务能力： 1、数据库视图：以可见的数据图表的形式对外提供数据，例如JDBC/ODBC 2、应用服务共享：封装成SOA形式对外提供服务，例如WebService 3、数据文件共享：以文件传输的方式对外提供数据，例如SFTP/FTP 数据共享子层对外进行明细数据提供的原则是：只提供历叱的CDR数据，实时的CDR数据提供由编码子层提供。

明细数据汇总数据聚合数据图例


数据共享层支持的“百花齐放、应用共享”模式

场景三：佛山应用变为全省应用

发布

佛山

省中心

佛山应用

孵化区

应用开发、使用

应用发

布申请

应用发

布批准

应用发布

全省应用发布

区

应用查看、评论

应用复制发布

应用复制申请

应用发布评审

应用复制申请审核

应用全省复制评审

佛山应用

发布区

深圳应用

孵化区

深圳应用

发布区

广州应用

孵化区

广州应用

发布区

深圳广州

应用复制申请

应用复制发布

全省应用发布

1

2

3

4

5

场景一：佛山自主开发应用

幵发布使用。

场景二：佛山应用复制到

需要的其它地市。

1 应用查看、评论 1

2 2

3

4

4

1

2

实行“谁开发，谁负责”制度，即对亍已发布应用，其它市公司有更新需求，将统一汇总到应用的原开发公司处，由其负责版本升级，最后由省公司进行应用同步。


Data Store API开放模式

Exadata

历史数据

30天全量CDR SQL

汇总表元数据

库外计算

预汇总数据

表

WebService WebService

个性汇总表

SQL

个性化揑件

SQL

TASK计算结果

A

B C

元数据

1. A方式——使用现有SAI数据模型和处理能够满足业务需求--NSN

2. B方式——使用SAI元数据配置功能，定义符合项目需要的指标—应用厂商

3. C方式——使用数据库计算能力迚行计算，使用元数据描述结果数据结构-—应用厂商

评审：有平台运营管理团队迚行评审, 评审的目的：系统安全性，性能，数据共享

数据流

控制流

评审

评审

TASK计算结果


Data Store模式下的应用建设 A、B、C三种模式的分工情况

A模式：32个应用

B模式：3个应用

C模式（含B）：10

个应用

应用 ABC建模方式厂商

本网发起骚扰电话 A 华为

本网收到骚扰电话 A 华为

本网发起骚扰短信 A 华为

本网收到骚扰短信 A 华为

HTTP业务质量分析 A 华为

手机业务流向分析 A 华为

目标小区错漏 B 鼎利

IMSI附着高频检测 A 鼎利

错误短信中心检测 B 鼎利

寻呼黑户分析 B 鼎利

批量用户短信分析（TASK） C 鼎利

终端综合分析 A 鼎利

寻呼黑洞 A 鼎利

历叱信令回溯 A 瀚信

用户模型分析 A 瀚信

重点行业APN分析 A 瀚信

KPI指标及失败原因分析及溯源分析 A 瀚信

2/3G信令和业务量统计分析 A 瀚信

浏览业务质量分析 A 瀚信

网元业务分析 A 瀚信

通用数据业务分析(1) A 瀚信

应用 ABC建模方式厂商

IMSI未识别 A 瑞原

鉴权失败 A 瑞原

中继超短通话 A 瑞原

2G切3G检测 A 瑞原

手机中毒检测（短信） A 瑞原

长途来话失败分析 A 瑞原

投诉用户预警和主劢关怀分析 A 瑞原

TD潜在用户挖掘 B+C 宜通

T网补盲 B+C 宜通

TD用户锁G网探测 B+C 宜通

用户开关机信息提取 B+C 宜通

批量用户轨迹分析 B+C 宜通

VIP历叱查询 B+C 宜通

微区域营销支撑 B+C 宜通

漫入用户轨迹分析 B+C 宜通

用户而业务不流量分析 C 宜通

PS域：通用数据分析 A 宽广

PS域：数据业务营销分析 A 宽广

PS域：自有/非自业务分析 A 宽广

PS域：终端分析 A 宽广

PS域：TD倒流分析 A 宽广

PS域：WIFI终端分流分析 A 宽广

PS域：网站分析 A 宽广

PS域：移劢亏联网资源分析 A 宽广


平台应用成效

应用使用情况目前已开发45个应用，上线后共使用15362次，7月平均每天使用量约300次。查询速度已有明显提升，响应速度在15秒以内。

应用开发速度 45个应用用1个半月的时间开发完成，平均1天开发1个应用。传统的做法，应用开发从需求分析、数据准备、模型开发、

接口联调、部署上线加起来，快的两周，慢的要一个月。利用开放的架构，需求分析，数据准备，接口连调部署等可以由丌同应用厂家共同开展，模型可以给丌同应用共用，开放架构得到最明显体现。

应用开发费用以前市公司开发一个应用需15万元，目前开一个应用需5万元，节省67%。

数据模型梳理目前已建立数据模型260个。


分布式库外数据处理集群

采用Exadata作为省中心数据

仓库（汇总数据）

应用层应用应用应用应用应用应用

库外处理结果文件

Infiniband

A B C

D E

A地市 B地市 C地市

Exadata

view 模型

报表

聚合区汇总区

xx xx xx 存储

资源池

文件服务器存放XDR文件

XDR文件

分布式ETL处理集群

XDR文件

清洗后的XDR文件

WebService服务器集群

分布式存储集群

（明细数据）

广东移动信令共享平台架构

每天30TB数据实时加载，每10分钟一

个加载作业

库内800个幵发，200-300个活跃幵发查询，秒级响应时间

多租户模式

高压缩比6:1


议程









江苏移动BI总体架构 – 数据层视图

34

实时流处理

数据集成

管理中心

分布式大数据平台

企业数据仓库

基础设施（服务器、存储、网络）

元数据调度任务配置数据调查信息质量管理配置讣证授权信息安全监控审计

客户

产品

订购

服务

清单

帐务

资源

结算

渠道

WAP

缴费

终端

竞争对手

合作伙伴

其他…

xDR DPI

内容 Web日志文档

位置 SMS

社交离线分析数据

预处理数据

大数据预处理/预分析数据： • 会话化的log • 客户行为标签 • 关键词筛选结果 • 文档分析结果 • 网站分析摘要 • 社交关系图谱 • …

关联与汇总数据

事件信令流位置流日志流社交流决策规则决策依据

数据源

网络DPI/ Wap log

平台LOG不内容

位置

CRM/BOSS

电子渠道

人工搜集

亏联网监听

合作伙伴共享

……

抽取

清洗

转换

加载

搜集

集成

３ＮＦ模型灵活模型

集市数据

Cube、模型

固定报表

其他分析组件

元数据等管理数据

流数据数据特点：持续产生、快速、海量承载应用：实时监控、欺诈控制、事件营销等

新型大数据数据特点：海量、结构多样、低密度承载应用：预处理、离线分析、简单实时查询

结构化数据数据特点：TB级、结构化、高密度承载应用：在线分析、复杂关联、复杂交亏、幵发

开放门户

数据产品

数据服务

开放目录

欺诈控制

实时精准营销不服务

业务监控

报告不查询

统计分析

多维分析

预测/挖掘

仦表盘/预警

搜索/探索

可视化

应用门户


大数据平台：数据中心（数据加工和数据服务）

35

元数据、数据质量管理

ETL、运维管理(备份/性能/负载/容量/日志…)

数据管理

数据中心应用层服务层

指标应用

报表

主题分析

数据仓库

专题分析

其他分析应用

精品BI Store

WEB门户

数据服务中心

数据整合层

数据服务层

数据引入层

数据汇总层

数据交换层

数据存储层

电子渠道

CRM

网络资源管理系统

信令监测系统

基地_全网业务平台

财务 ERP/LIS

数据封装

服务封装

服务管理

…… webservice

WEB门户

应用集市应用集市

应用集市

市场部

客服中心

数据部

地市公司

财务部

公司领导

源系统应用中心

应用层访问层

接口访问

精确营销

网络系统

客服系统

其他系统

业务平台

CRM/BOSS

使用者

新建数据服务中心，与数据仓库组成数据中心，数据服务应用与数据仓库原有的分析应用组成应用中心，逐步实现“数据”与“应用”的解耦、数据服务能力集中化、规范化

数据服务

经营分析

应用数据转换

实时数据

非实时数据

BOSS

客服

省内业务平台

结构化数据

非结构化数据


• Database services 隔离数据库云中的工作负载

• 每一个server pool中运行多个 database services

• 服务器动态分配池中的资源满足需求

• 服务器池之间可以动态调配服务器

地市级数据沙箱（DB Farm）

镇江 FREE 地市1 苏州

Service 1

Service 2

Service 3


议程






不同数据处理形式适用的各类场景

数据结构批处理实时处理

小并发、海量数据处理高并发、小数据处理高并发、海量数据处理

非结构化数据 1）MapReduce + HDFS 2）NoSQL DB

结构化数据 3）Shared Nothing/MPP数据库

4）Shared Disk/RAC数据库 5）Sharding数据库

6）混合架构数据库（Shared Nothing+Shared Disk）

结构化数据非结构化数据

OLTP 混合负载非实时实时

数据处理

数据仓库


技术路线1：MapReduce+HDFS，适合于“分而治之”的处理模式

MapReduce任务以全量、离线、简单为主

1. 并行预处理（如各种日志文件的清洗、去噪、合幵

等，后集成进入DW）

2. 简单的统计分析与数据挖掘（用户访问行为摘

要生成、流量统计汇总、简单客户分类不行为分析等）

3. 非结构化数据的处理与分析（如爬虫网页的分

析处理、音频、批量文档等处理）

HDFS

优点缺点

大文件低延迟

一次写入大量小文件

多次读取多个写入器

文件更新

不适合场景：

1、低时间延迟数据访问的应用。例如几十毫秒范围，原因：hdfs是为高数据吞吐量应用优化的，这样就造成可能会以高时间延迟为代价

2、大量小文件原因： namenode将文件系统的元数据存储在内存中，因此文件系统所能存储的文件总数受限于namecode内存容量。根据经验，每个文件，目录和数据块的存储信息大约占150字节，如果一百万个文件，且每个文件占一个数据块，那至少需要300MB的内存，但是如果存储十亿个文件，那么需要的内存将是非常大的

3、多用户写入，任意修改文件：现在hdfs文件可能只有一个writer,而且写操作总是写在文件的末尾


Hadoop平台：适合固定模式计算，不善于“拉关系”

Create table 数据装载 Select 数据查询

Sum/Group By 数据聚合 Join 数据关联

Source：《A Comparison of Approaches to Large-Scale Data Analysis》

Hadoop是商用关系型数据库的有益补充：

1. Hadoop的HDFS不MapReduce适用亍幵行数据ETL

2. JOIN查询的效率非常低

3. 数据只可以进行ADD/DELETE，丌能进行update

4. HDFS不MapReduce的组合丌适合进行高幵发，小结果集查询

Hadoop最重要的优点是性能可随节点数量线性增长


工作量

单位用户成本

互联网

电信企业

工作量和单位成本的平衡


Facebook MapReduce离线分析

Facebook数据仏库 HDFS

MapReduce

Hive

CLI

JDBC/ ODBC

Web GUI Mgmt,etc

Meta Store

DDL Query

Thrift

BI Tools

Hive QL

Sparse Planner

Execution

Web Servers

Scribe Servers

Filers

Hive on Hadoop Cluster

Oracle RAC Federated MySQL

来自亍Web服务器不内部服务的海量日志数据通过scribe搜集到NFS服务器

大量日志复制到Hadoop集群上的HDFS实例（Map Only）

大量维度数据从MySQL获取幵复制到HDFS（Map Only）

使用Mapreduce 以及Hive创建不发布报告，幵做历叱分析

发布报告不摘要，提供高幵发在线的低延迟查询不统计


SimpleDB 的主要特点：

1. 无范式，范式化是关系数据库有效组织数据的一个过程，其目的是消除冗余数据，同时确保数据依赖的意义，SimpleDB数据模型不遵守任何形式的范式，相反，它是完全反范式的，SimpleDB的无范式化允许你更灵活地处理你的数据模型，允许在你的数据中使用多值属性。

2. 无连接，SimpleDB不支持连接的概念，相反，它为一个属性提供了存储多值的功能，从而避免了检索所有值需要的连接操作。

3. 无模式，在SimpleDB中，表是没有列的概念的，SimpleDB数据的表格视图只是为了增强可读性而设计的，并非表现的是它的数据结构，SimpleDB中唯一的结构就是由项目名和属性/值对组成的，下面是更恰当的SimpleDB数据结构表现形式。

4. 只有字符串类型

5. 最终一致性

SimpleDB与传统关系数据库相比，它也是有缺点的：

◆那些需要强调严格数据一致性的应用程序不能采用SimpleDB；

◆使用SimpleDB需要开发团队成员熟悉有别于RDBMS的存储模型；

◆因为关系不象关系数据库中定义的那么明确，需要在应用程序代码中实现对数据的约束；

◆如果你的应用程序需要存储非字符串数据类型的数据，存储之前需要先编码；

◆SimpleDB存储多个属性的方法需要习惯了RDBMS的开发人员适应它。

原文名：《Amazon SimpleDB versus RDBMS》

技术路线2：NoSQL DB Amazon的非关系型数据库云SimpleDB


技术路线3：集群数据库MPP

Shared Disk和Shared Nothing是两种主要的数据库集群技术，各自都有自身特点

Shared Nothing把应用代码移到数据端运行

当相关数据量很大（高并行）、而应用

代码并发量很小时，Shared Nothing更加适

合这种典型的OLAP应用；

主要特点：大数据量处理高并行、低并发、低可用性（由于数据非共享，当节点故障，其他节点要接管故障节点数据）


MPP架构最不适合多租户架构

少多租户间共享资源


技术路线4：集群数据库Shared Disk

Shared Disk和Shared Nothing是两种主要的数据库集群技术，各自都有自身特点

Shared Disk把数据传输到应用代码端

当应用代码量很大（高并发）、相关数据

量比较小时，Shared Disk更加适合这种典

型的OLTP应用；

主要特点：高并发、高可用性（由于数据共享，当

节点故障可以透明切换到其他数据库节点运行作业）


技术路线5：分片式关系数据库（Sharding DB）

数据分片(Sharding)的原理就是将数据做水平切分，类似于hash分区的原理，通过应用架构解决访问路由和数据合并的问题。Sharding架构的优势在于，集群扩展能力很强，几乎可以做到线性扩展，而且整个集群的可用性也很高，部分节点故障，不会影响其他节点提供服务。Sharding原理简单，容易实现，是一种非常好的解决数据库扩展性的方案。

但是Sharding对应用场景的要求很高，因为一旦使用数据分片架构，如果需要跨不同的节点做join，或者统计类型的操作，将会变得非常困难，应该尽量避免。所以说 Sharding架构会损失部分关系型数据库的特性，比如join、数据全局性，从而使数据库退化为Key-Value store类型的存储。所以，并不是所有的应用都适合做Sharding，它可能会造成应用架构复杂或者限制系统的功能，这也是它的缺陷所在。


传统Sharding面临的问题

48


Google新一代数据库发展方向：关系型、混合架构、自动Sharding

《MapReduce：一个巨大的倒退》：

做为一个数据处理模型，MapReduce呈现出

了一个巨大的退步。数据处理在四十年中学到了以下三个经验：

* 结构描述是好的。

* 将结构描述从程序中分离是好的

* 高阶的访问语言是好的

Google 新数据架构的目标： Consistency required，Eventual consistency

too complex and painful

SQL Query without code

Relational schema

Auto Parallel degree control

Consistent indexes

Transparent sharding, data movement

Synchronous replication

24/7 availability


技术路线6：关系型、混合架构、自动化Sharding

智能存储层(Shared Nothing)

存储资源池

数据库处理层(Shared Disk)

数据库资源池

超高速并发网络层

880Gb/s/机架

Exadata提供一种混合式的数据库架构,能够有效解决两者的冲突,吸取两种架构长处; 既可以满足OLTP的高并发、高可用特点；又可以满足OLAP的大数据量处理要求；

具备良好的普适性架构:Shared

Nothing and Shared Disk

Exadata Cell

InfiniBand 交换网络

Exadata Cell

Exadata Cell

….

SunFire SunFire SunFire


Share Disk 高并发、低延时扩展性较差高并发、交易

MPP 海量数据、高扩

展并发能力低

建模、关联计算、汇总

Sharding DB

海量数据、高扩展、高并发

数据分割、无法关联、应用复杂

可分割数据查询、客户画像

Hadoop 海量数据、高扩

展

非实时、数据一致性差、开发复

杂

模型填空、价值数据提取

NoSQL 海量数据、高扩展、低延时

数据一致性差、开发复杂

非结构实时数据服务、实时位置信息

结构化数据

（SQL）

非结构数据

企业数据货架

Oracle

Exadata

优点缺点新一代数据平台

Oracle

BigData

适用场景


议程

大数据范畴和典型架构





5

3

大数据核心：技术的创新来驱动商业价值

“大数据”的范畴=“全数据”

Run the Business Integrate existing systems

Support mission-critical tasks

Protect existing expenditures

Ensure skills relevance

Relational Hadoop

Change the Business

Disrupt competitors

Disintermediate supply chains

Leverage new paradigms

Exploit new analyses

NoSQL

Scale the Business

Serve data faster

Meet mobile challenges

Scale-out economically


企业级大数据平台的关键点

系统集成开发技术安全

Engineered Systems：稳定、高效、快速、

SQL on All Data：简单易用、应用平滑

Database Security on

All Data

SQL


Oracle的大数据端到端解决方案

Oracle No SQL

Database

Cloudera

Hadoop

Oracle Big Data

Connectors

Oracle Advanced Analytics

SQL

Oracle Business Analytics Foundation Oracle Exalytics

Oracle Big Data Appliance Oracle Exadata


关键技术1：面向大数据的混合型RDBMS Exadata

数据云平台灵活的计算、存储虚拟资源池

部门应用程序 1

CRM应用程序共享

服务务

Oracle Enterprise Manager

共享服务

ERP 应用程序

感知需求高峰

资源的自动化按需能力供应

Exadata数据库云资源池

数据库节点

感知需求高峰

调整容量

调整容量

Sales Pool

Sales ClientsBack Office

Clients

Most Critical Least Critical

Back Office Pool

Memory

Physical

计算资源的动态调整

Sales Pool

Sales ClientsBack Office

Clients

Most Critical Least Critical

Back Office Pool

I/O能力资源的分配

Exadata Cell

InfiniBand Switch/Network

HR ERP

Exadata Cell Exadata Cell

• 不同数据库分配不同的I/O 资

源

• OA Database: 33% I/O资源

• ERP Database B: 67% I/O资

源

• 库间、库内的不同用户和任务

分配不同I/O资源

• OA Database:

• Portal: 60% of I/O资源

• SOA: 40% of I/O资源

• ERP Database B:

• 报表: 30% of I/O资源

• 批处理: 70% of I/O资源

数据仓库

OLTP

多租户

高压缩

智能扫描

Client

Storage

DB

Exadata 数据库计算节点

Exadata 智能存储层

SUM

Select sum(sales) whereDate=’24-Sept’ …

Smart Scan在TB 级数据中扫描匹配请

求的数据

构建并发Smart Scan请求

仅仅返回满足条件的数据

智能扫描Smart Scan ROW使用“where”谓词筛选

行 COLUMN列筛选 JOIN联接筛选增量备份筛选

问题：昨天的销售业绩如何？

存储索引

1 ASM AU

…

1 ASM Disk

1MB Storage Region

Table T1

A B C D

… 5 … …

… 8 … …

… 3 … …

存储节点内存中的存储索引

Min B = 3Max B = 8

Min B = 1Max B = 5

Region Index

B:1/5 B:3/8 ……

Table T2

E F G

a … 4

d … 7

j … 9

Table T1

A B C D

… 1 … …

… 3 … …

… 5 … …

E:a/jG:4/9

SELECT * FROM T1 WHERE B<2;

DBA

Only first block can match混合式列压缩

Compression Unit (CU)

CU Header

Block Header

C1

C2

Block Header

C2

C3 C4

C5

Block Header

C5

C6

Block Header

C8 C7

RAC TAF

RAC TAF用亍保护数据库服务器故障，做到应用零中断

ASM管理下，存储任一份数据同时分布在2个丌同的Fail Group，任何2个丌同的FailGroup 一定来自丌同Storage Cell；Normal方式是2个FailGroup ，增加数量可实现3重保护；

ASM

高可用性

高可扩展性

云资源池


关键技术2:高性能Hadoop平台高性价比的高性能 Hadoop 一体机

最高性能的预优化 Hadoop 一体机

‒ 同类产品中最佳的优化软件集成

到 Exadata 的超快连接能力: 15TB/Hour

‒ 分区与非分区；在线与离线数据装载

预先集成优化的软件系统

‒ Linux, Java VM, Cloudera Distribution of Hadoop

‒ Oracle R Distribution & NoSQL Database

从小配置起步逐步扩展，处理能力与存储同步提升


关键技术3：Hadoop与RDBMS的集成

Oracle Loader for

Hadoop

Oracle Direct

Connector for

Hadoop 外部表

Oracle Data Integrator

Application Adapter

• MapReduce任务加载数据到Oracle

• 分区&未分区表

• 在线与离线加载

• 从Oracle直接通过SQL访问Hadoop数据

• 并行访问停留在hadoop中的数据

• 声明式的定义数据集成过程

• 自动生成MapReduce任务代码

Oracle

Big Data

Connector

Oracle R

Connector

For Hadoop


集成：通过Oracle Loader For Hadoop完美集成将数据从Hadoop加载Exadata

SHUFFLE

/SORT

SHUFFLE

/SORT

REDUCE

REDUCE

REDUCE

MAP

MAP

MAP

MAP

MAP

MAP

REDUCE

REDUCE

ORACLE LOADER FOR HADOOP Oracle提供的端到端工具

性能远超基于开源的sqoop实现的方式

直接在Hadoop层面编程，利用Hadoop的并行处理能力

三种加载方式

JDBC：最灵活，速度慢

HDFS外部表：最高性能，无需fuse，直接访问HDFS，需要较多Exadata

资源

HDFS数据泵：直接在hadoop生成datapump格式文件，最节约Exadata

资源


集成：通过Oracle SQL Connector完美集成Hadoop 在Exadata中直接访问HDFS数据

在Exadata的数据库中直接访问Hadoop中的数据

直接执行查询

通过外部表进行数据加载

HDFS

Infini band

DCH

外部表

DCH DCH HDFS

客户端

Oracle 数据库

SQL 查询


集成：利用ODI实现大数据集成过程的端到端可视化 Transforms

Via MapReduce(HIVE)

Loads

Activates

Oracle

Loader for

Hadoop


Oracle Exadata

• 帮助定义与实现大数据集成过程的专业ETL工具

• 自动生成MapReduce代码 • 加载文件到HDFS • HDFS内文件转换 • 集成HDFS到Oracle

• 利用大数据 • 简化集成复杂性、可视化 • 与Oracle其他产品的集成（

BI/DW/SOA)

http://hadoop.apache.org/


package pigstuff;

import java.io.IOException;

import java.util.ArrayList;

import java.util.Iterator;

import org.apache.pig.EvalFunc;

import org.apache.pig.PigException;

import org.apache.pig.backend.executionengine.ExecException;

import org.apache.pig.data.BagFactory;

import org.apache.pig.data.DataBag;

import org.apache.pig.data.DataType;

import org.apache.pig.data.Tuple;

import org.apache.pig.data.TupleFactory;

import org.apache.pig.impl.logicalLayer.FrontendException;

import org.apache.pig.impl.logicalLayer.schema.Schema;

/**

*

* @author nbayliss

*/

public class W_FINDER extends EvalFunc<Tuple> {

private class V0Line {

String state = null;

String[] attributes;

String prev = "";

String next = "";

public V0Line(String[] atts) {

attributes = atts;

}

public String[] getAttributes() {

return attributes;

}

public void setState(String state) {

this.state = state;

}

public String getQuantity() {

return this.attributes[4];

}

public String setState(V0Line linePrev, V0Line lineNext) {

String q = this.getQuantity();

if (linePrev == null) {

prev = "";

} else {

prev = linePrev.getQuantity();

}

if (lineNext == null) {

next = "";

} else {

next = lineNext.getQuantity();

}

if (!q.isEmpty() && (prev.isEmpty() || (eq(q, prev) && gt(q, next)))) {

state = "S";

return state;

}

if (gt(q, prev) && gt(q, next)) {

state = "T";

return state;

}

if (lt(q, prev) && lt(q, next)) {

state = "B";

return state;

}

if (!q.isEmpty() && (next.isEmpty() || (gt(q, prev) && eq(q, next)))) {

state = "E";

return state;

}

if (q.isEmpty() || eq(q, prev)) {

state = "F";

return state;

}

return state;

}

private boolean eq(String a, String b) {

if (a.isEmpty() || b.isEmpty()) {

return false;

}

return a.equals(b);

}

private boolean gt(String a, String b) {


return false;

}

return Double.parseDouble(a) > Double.parseDouble(b);

}

private boolean lt(String a, String b) {


return false;

}

return Double.parseDouble(a) < Double.parseDouble(b);

}

public String getState() {

return this.state;

}

}

BagFactory bagFactory = BagFactory.getInstance();

@Override

public Tuple exec(Tuple input) throws IOException {

long c = 0;

String line = "";

String pbkey = "";

V0Line nextLine;

V0Line thisLine;

V0Line processLine;

V0Line evalLine = null;

V0Line prevLine;

boolean noMoreValues = false;

String matchList = "";

ArrayList<V0Line> lineFifo = new ArrayList<V0Line>();

boolean finished = false;

DataBag output = bagFactory.newDefaultBag();

if (input == null) {

return null;

}

if (input.size() == 0) {

return null;

}

Object o = input.get(0);

if (o == null) {

return null;

}

//Object o = input.get(0);

if (!(o instanceof DataBag)) {

int errCode = 2114;

String msg = "Expected input to be DataBag, but"

+ " got " + o.getClass().getName();

throw new ExecException(msg, errCode, PigException.BUG);

}

DataBag bag = (DataBag) o;

Iterator<Tuple> valueIt = bag.iterator();

while (!finished) {

if (valueIt.hasNext()) {

Tuple nextTuple = valueIt.next();

line = nextTuple.get(0).toString();

String ordk = nextTuple.get(1).toString();

String part = nextTuple.get(2).toString();

String supp = nextTuple.get(3).toString();

String q = nextTuple.get(4).toString();

String ship = nextTuple.get(5).toString();

pbkey = nextTuple.get(6).toString();

thisLine = new V0Line(new String[]{line, ordk, part, supp, q, ship, pbkey});

if (lineFifo.isEmpty()) {

thisLine.setState("S");

} /*else {

if (!lineFifo.get(0).getGroup().equals(thisLine.getGroup())) {

thisLine.setState("S");

}

} */

lineFifo.add(0, thisLine);

if (!valueIt.hasNext()) {

noMoreValues = true;

thisLine.setState("E");

}

} else {

thisLine = null;

}

String evalState = null;

if (lineFifo.size() == 3) {

processLine = lineFifo.get(1);

if (processLine.getState() == null) {

prevLine = lineFifo.get(0);

nextLine = lineFifo.get(2);

processLine.setState(prevLine, nextLine);

}

evalLine = lineFifo.remove(2);

evalState = evalLine.getState();

} else {

if (noMoreValues) {

evalLine = lineFifo.remove(lineFifo.size() - 1);

evalState = evalLine.getState();

}

}

if (evalState != null) {

matchList += evalState;

if (matchList.length() > 5) {

matchList = matchList.substring(1);

}

if (matchList.equals("SBTBE")

|| matchList.equals("TBTBE")

|| matchList.equals("SBTBT")

|| matchList.equals("TBTBT")) {

//String[] atts = evalLine.getAttributes();

c++;

}

}

if (lineFifo.isEmpty()) {

finished = true;

}

}

Tuple outputTuple = TupleFactory.getInstance().newTuple(3);

outputTuple.set(0, line);

outputTuple.set(1, pbkey);

outputTuple.set(2, new Long(c));

return outputTuple;

}

@Override

public Schema outputSchema(Schema input) {

Schema.FieldSchema linenumber = new Schema.FieldSchema("linenumber", DataType.CHARARRAY);

Schema.FieldSchema pbykey = new Schema.FieldSchema("pbykey", DataType.CHARARRAY);

Schema.FieldSchema count = new Schema.FieldSchema("count", DataType.LONG);

Schema tupleSchema = new Schema();

tupleSchema.add(linenumber);

tupleSchema.add(pbykey);

tupleSchema.add(count);

return new Schema(tupleSchema);

}

}

传统Hadoop平台面临的巨大的开发难度 Snapshot of Oracle SQL Analytic Functions

Simplified, sophisticated, standards based syntax

SELECT first_x, last_z

FROM ticker MATCH_RECOGNIZE (

PARTITION BY name ORDER BY time

MEASURES FIRST(x.time) AS first_x,

LAST(z.time) AS last_z

ONE ROW PER MATCH

PATTERN (X+ Y+ W+ Z+)

DEFINE X AS (price < PREV(price)),

Y AS (price > PREV(price)),

W AS (price < PREV(price)),

Z AS (price > PREV(price) AND

z.time - FIRST(x.time) <= 7 ))

250+ Lines of Java UDF 12 Lines of SQL

20x less code

以双底分析Double Bottom (W)为例

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. 62

Ticker


关键技术3: Big Data SQL

Profit and Loss

Relational Hadoop

Application Logs

NoSQL

Customer Profiles

SQL


Big Data SQL：简化开发、性能最大化

跨平台的数据查询：Oracle Database, Hadoop & NoSQL

Query Data in RDBMS,

Hadoop & NoSQL

Oracle SQL

Oracle NoSQL DB

BDS Server

HDFS Data Node

BDS Server

Oracle NoSQL DB

BDS Server

HDFS Data Node

BDS Server

Oracle Database

Storage Server

Oracle Database

Storage Server

Fast Massive Parallelism

Filtered Locally

Minimized Data Movement


关键技术4: 大数据安全 Hadoop, NoSQL & Relational

Existing Capability

– 认证Authentication through Kerberos

– 授权Authorization through Apache Sentry

– 审计Auditing through Oracle Audit Vault

– Encryption for Data-at-Rest

– Network Encryption

Big Data SQL adds

– Advanced Security on Hadoop & NoSQL

Masking and Redaction

– Virtual Private Database

Fine-grain Access Control


Oracle Big Data管理系统解决方案

SO

UR

CE

S

数据加工数据服务

Oracle Database

Oracle Industry Models

Oracle Advanced

Analytics

Oracle Spatial & Graph

Big Data Appliance

Apache Flume

Oracle GoldenGate

Oracle Event Processing

Cloudera Hadoop

Oracle NoSQL

Oracle R Advanced Analytics for Hadoop

Oracle R Distribution

Oracle Database

In-Memory, Multi-tenant

Oracle Industry Models

Oracle Advanced Analytics

Oracle Spatial & Graph

Exadata

Oracle GoldenGate

Oracle Event Processing


Oracle Big Data Connectors


ORACLE BIG DATA SQL


运营商大数据应用场景

运营优化市场占有和客户洞察收入增长及盈利

新产品发布

客户洞察社交媒体情感

大数据增强

电商点击流分析

欺诈检测

实时推荐上下文相关的信息/广告

基于位置的信息/广告

新的收入流市场分析

M2M分析作为服务网络优化

网络规划

服务质量

DPI分析和监测

资产生命周期管理

设备监控和诊断

现场服务分析



Query Execution on Hadoop

select last_name, state,

movie, genre

from movielog m,

customer c

where genre=‗comedy‘

and c.custid = m.custid

1

Query compilation determines: • Data locations • Data structure • Parallelism

1

2

Parallel reads using Big Data SQL Server: • Parallel unit: PQ Slaves & InputSplits • Filter rows and project columns

2

Hive

Metastore

HDFS

NameNode

3

Process filtered result • Move relevant data to database • Join with database tables • Apply database security policies

3

HDFS Data Node

BDS Server

HDFS Data Node

BDS Server


大数据平台关键点：大数据的集成

Sales

Custs Prods

MapReduce/Hive/R

分布式存储

（如 HDFS）

RDBMS

（如Oracle）

分布式存储

（如 HDFS）

RDBMS

（如Oracle）

MapReduce/Hive/R

Weblog汇总

分布式存储

（如 HDFS）

RDBMS

（如Oracle）

Weblog

Sales Weblog

Weblog

Weblog

分布式存储

（如 HDFS）

RDBMS

（如Oracle）

NoSQL/Hive

Sales 2012 Sales 2011 Sales 2010

Sales 2011

Sales 2010

引用RDBMS中的数据；或将RDBMS数据导入到HDFS做离线分析海量大数据的分析结果进入RDBMS提供二次分析&在线查询

通过HDFS进行数据结构化、去噪、组织、进入RDBMS进行分析与挖掘

Custs

HDFS作为RDBMS的分布式历史归档，共同提供对外查询

Online

Analysis

Query&

Online Analysis

Documents

湖北移动大数据技术交流 - Oracle · 关键技术架构总结：强大的开发集成能力 关系型数据库仍然是王道（支持前台分析和查询） 难点：Sharding分库：开发、扩展、拉关系

湖北移动大数据技术交流 - Oracle · 关键技术架构总结：强大的开发集成能力关系型数据库仍然是王道（支持前台分析和查询）难点：Sharding分库：开发、扩展、拉关系