From Vision to Results

1

Oracle Enterprise Architecture

青海电信 甲骨文信息化技术研讨会

Software. Hardware. Complete

云计算关键技术分析

张强 企业架构师,大中华区企业架构部

Jason.z.zhang@oracle.com

2

目录

1 互联网IT架构 v.s 企业IT架构

X86服务器与小型机技术对比分析

一体机与软硬分离架构对比分析

虚拟化技术的引入策略

两种云中的数据库

3

互联网与电信企业的业务模式

盈利模式 电信运营商 互连网运营商

• 后向市场收费

• 应用平台自身盈利

• 数据增值业务使用费

• 企业客户接入费用

• 最终用户使用费

市场成长速度 低 高

$ $

low

low

high percentage

high percentage

互连网的业务模式与电信运营商相反

利用开放的互连网、技术创新和产销者(Presumar)市场的经营，以自有的互

连网平台技术（搜索、SNS、IM）进行后向市场或辐射市场的经营

电信运营商以前向收费为主，包括在通话、增值业务和企业接入

后向市场平台的建设（移动MM、黄页+Call Center等）刚刚起步

以运营能力而非技术创新能力见长

4

互联网与电信企业的IT架构特点

1.扩展性

应对爆炸式增长，提供

海量处理能力

2.可用性 “尽力而为”的服务提供能力

3.延迟 “8秒原则”

1.数据准确性

数据一致性

2.可用性 “5个9”的可用性 业务中断不可容忍 3.扩展性 应对线性增长

互联网 电信企业

5

互联网IT架构的演进

Salesforce

Apple

Twitter

Facebook

Google

Paypal

eBay

Amazon

• Oracle

• UNIX SMP小型机

• 商用存储

• Oracle

• UNIX SMP小型机

•

• NoSQL

• MySQL on PC Server

• 本地存储

• Web 2.0应用特定场景 – 特定应用，海量处理

– 简单数据管理

– 数据准确性一致性弱

• Web 2.0公司能力独特 – Google/Facebook：成百上

千的计算机博士维护其基础设施

– 阿里巴巴集团：中国最多的Oracle ACE/ACE Director DBA

试问：如果中国移动运营新浪微博，每月收取5元功能使用费，当用户发现无法对一条微博评论两次，会发生什么？

6

目录

2 互联网IT架构 v.s 企业IT架构

X86服务器与小型机技术对比分析

一体机与软硬分离架构对比分析

虚拟化技术的引入策略

两种云中的数据库

7

X86服务器与RISC小型机的对比 — 性能

• 将Xeon与IBM Power系列CPU进行比较，包括标准测试指标spec_int_rate 2006、spec_fp_rate 2006，X86的性能有了长足的进步

• 需要注意的是，服务器性能需要按照应用负载来看，有的应用需要高主频，有的需要大内存，有的需要高IO能力，不同的应用负载，X86与小型机有不同的表现。

8

X86服务器与RISC小型机的对比 —— RAS、可扩展性、运维管理

X86 服务器 小型机

RAS 弱 虽然X86 借鉴了大量RISC CPU的特性，但是还有一定的差距，在需要硬件支持关键任务环境中有一定的劣势。

强 小型机最大优势在于RAS指标，小型机使用了很多的冗余技术和高可用性，因此可靠性较高，同时也导致成本更高。

可扩展性 X86服务器的垂直扩展能力较弱。 水平扩展能力依靠集群技术可以实现较大规模的横向扩展。 水平扩展能力的发挥与应用的关系十分密切，例如，在应用服务器层面，可以实现几十台到上千台服务器的集群，但是能否实现线性扩展需要应用的配合和系统设计（负载均衡等）；在数据库服务器层面，也可以事先几十台服务器的集群，应用效果取决于网络、应用设计、应用类型等多因素。

垂直扩展能力强。 水平扩展能力依靠集群技术实现。 因为垂直扩展能力强，所以，在大多数场景下，可以通过垂直扩展（增加CPU、内存、板卡等）来获得处理能力的提升，因此，应用设计相对简单。

运维管理 工作量大。 由于X86服务器的RAS能力较弱，X86服务器单机处理能力较弱，X86服务器数量较多，为弥补其可靠性、可用性的不足，需要通过整体架构的设计来增强其稳定性，因此整体架构会更加复杂，导致其维护工作量加大，统一监控难度大，系统整体维护难度加大。

工作量小。 小型机运行稳定可靠，系统架构设计相对简单，可以简化运行维护工作。

RAS：Reliability, Availability, Serviceability

9

X86服务器与RISC小型机的对比 ——技术成熟度、第三方支持、售后服务

X86 服务器 小型机

技术成熟度 中 X86服务器将小型机的技术移植到服务器中来，使得其技术成熟度不断提高，能够满足越来越多的关键业务应用的需求。

高 服务器领域的很多技术都来源于小型机，如虚拟化、冗余、故障侦测技术等，因此，小型机技术技术成熟度明显要高。

第三方软、硬件支持

支持水平低 软硬件结合的紧密程度低，需要进行大量的兼容性测试认证

支持水平高 可以提供稳定的整体解决方案，选择了小型机实际上选择了一个整体解决方案

售后服务 低。 一般为第三方维保。

高。 原厂维保。

10

X86服务器与RISC小型机的对比 ——能耗、扩容、配件、采购成本与流程

X86 服务器 小型机

能耗 低 一般比小型机节能30%。

高

扩容/配件 高 扩容调配方便，配件通用性强

中

采购/维护成本

低 采购成本是小型机的1/4到1/5，维护费是小型机的1/10。

高

采购流程 简便 一般国内生产，不存在过关问题，到货周期短

复杂 一般海外生产，需要进关 到货周期长

11

X86服务器与RISC小型机的适用领域

X86服务器

1.Web 服务器

中间件服务器

2.中等负载的专用服务器 3.数据集市服务器 4.业务平台的数据库服务器

5.通过负载分担、集群、网络技术等系统架构设计补充X86服务器的不足

小型机

1.7x24小时不停机的关键业务

应用

2.核心OLTP数据库服务器

12

X86服务器与RISC小型机的对比分析

— 结论 • X86服务器最大的弱点是RAS能力的不足

• X86服务器的大规模引入所带来的最大挑战是运维管理能力的提升 – 维护的复杂度

– 维护的工作量

– 统一监控的难度

– 复杂系统架构设计的能力

• X86服务器的引入不仅仅是单一系统的问题，而是系统整体架构设计的改变 – 负载分担、集群、网络能力、应用的改造

– 应用开发商的配合

• RISC小型机在关键业务应用上仍将发挥不可替代的作用，X86服务器则可以依靠系统整体化设计弥补自身的不足

13

目录

3 互联网IT架构 v.s 企业IT架构

X86服务器与小型机技术对比分析

一体机与软硬分离架构对比分析

虚拟化技术的引入策略

两种云中的数据库

14

什么是一体机（Engineered Systems）？

Engineered Systems (PDF, 42

pages, published: November

2011)

An engineered system is an

integrated hardware and

software system dedicated to

providing a specific service, and

meeting predetermined levels of

capability, capacity, and scale.

一体机是软件与硬件预集成的系统，专用于提供特定的IT服务，同时能够满足预定的功能、能力与扩展性的要求。

•融合最佳实践

•缩短集成部署时间

•可预知的性能、能力与扩展性

•简化运维

•降低总体拥有成本

15

一体机提供高可用性和有效性的成熟软件

16

一体机代表了未来发展趋势

2008.09

2009.09

2010.07

2010.09

Oracle推出ExaData V1

Oracle推出ExaData V2

EMC收购GreenPlum

IBM 收购Netezza

2010.10 Oracle推出Exalogic Oracle推出ExaData X2-2/X2-8

2011 Oracle推出Exalytics, Big Data Appliance HP，Microsoft相继推出一体机产品

2010 财富49名战略影响力人物

1. Netflix - Reed Hastings

2. Ford - Alan Mulally

3. Apple – Steve Jobs

4. Facebook – Mark Zuckerberg

5. Bai Du – Li Yan Hong

6. Oracle - Larry Ellison

• Oracle 是领导者

• 即使是 Oracle的竞争对手, 也承认Oracle具有正确的方向

18

一体机的性能提升

19

一体机为什么那么快？ —— 革命性设计，“软件为体，硬件为用”的设计思路 预集成，平衡的设计，融合Oracle最佳实践

20

一体机的可靠性与可扩展性 —— 全双工/全冗余，垂直与水平扩展

硬件集群 + 冗余 + 镜像，确保万无一失

垂直扩展

水平扩展

21

混合列压缩 综合列压缩(EHCC)：技术获得10x－50x 超高压缩比，并提高磁盘I/O效率

智能闪存 Smart Flash Cache： 高达5.3TB 的 Flash Cache，随机I/O性能高达1M IOPS

智能扫描 Smart Scan：计算负载部分卸载至并行智能存储层，并只传输经筛选的有用数据

存储索引 StorageIndex：存储索引在内存中保存表数据的汇总信息

Infiniband网络 Smart Flash Cache： 高达5.3TB 的 Flash Cache，随机I/O性能高达1M IOPS

一体机与传统SMP架构对比

1台满配Exa*一体机 3台集采高端满配服务器集群

＋5台集采高端存储阵列

结论：1台满配Exa*一体机的处理能力＝3台集采高端满配服务器＋5台集采高端存储阵列，而功耗和占用机房空间分别仅是后者的1/6和1/7。

22 22

一体机与传统架构的对比 ——性能、可靠性、可维护性

一体机 传统架构

性能 高 相比传统架构，有10倍到数千倍的提升

低

可靠性 高 全双工，全冗余

高 通过集成，可实现全双工，全冗余

可扩展性 高 可实现纵向扩展和横向扩展

中 可实现纵向扩展，但受限于系统硬件配置 横向扩展存在理论上的可行性但是在实际工程中往往未预留设计而无法实现或扩展性有限

可维护性 高 可实现系统软件（数据库、应用服务器）、操作系统、存储、硬件、网络设备的一体化维护，包括：一体化监控、升级、打补丁、供应（provisioning）、配置

低 系统软件（数据库、应用服务器）、操作系统、硬件、网络、存储单独维护，管理复杂，配置困难

23

一体机与传统架构的对比 ——开放性对比

一体机 传统架构

支持开放标准 基于标准的硬件平台和“事实标准”系统软件平台

X86架构 Infiniband Oracle Database EE Oracle Weblogic EE

基于标准的硬件平台 “事实标准”系统软件平台通常会支持主流标准硬件平台¹

Vendor Lock 无 应用/数据可以随时迁入/迁出，迁移成本较低，对应用透明

无 应用/数据可以随时迁入/迁出，迁移成本较低，对应用透明

应用移植性 支持 以往应用可应用，透明，无修改移植

支持

硬件配置要求 为达到特定的性能，需要指定配置 相对灵活，但是性能不可预期

说明：开放性即基础软件对下层基础硬件的约束，是否可以运行在和目前非同构的硬件环境下。

24

一体机与传统架构的对比 ——标准化、成熟度、能耗、实施

一体机 传统架构

标准化程度

高 开放标准硬件

高 开放标准硬件

技术成熟度

高 硬件、存储与网络设备采用标准化成熟硬件 软件采用“事实工业标准”的软件平台

高 软件采用“事实工业标准”的软件平台

能耗/占地

低 能耗是同等设备（小型机+存储）的1/3到1/6，占用机房空间是同等设备（小型机+存储）的1/10

高

实施 短 预集成系统，可在极短时间内投入生产 原厂提供服务，易于实施

长 较多的集成工作，投入生产的平均周期为2个月¹

多厂商协调，难度大

说明：1）根据中国移动网管系统建设情况的调研。

25

目录

4 互联网IT架构 v.s 企业IT架构

X86服务器与小型机技术对比分析

一体机与软硬分离架构对比分析

虚拟化技术的引入策略

两种云中的数据库

26

虚拟化技术的主要问题 性能开销大、适合“大分小”的中小型应用、软硬件兼容性

1. 性能开销大，虚拟化一定带来额外的开销 – X86平台“在采用 4.0 虚拟 CPU 的虚拟机上，某虚拟化软件 可实现

90% 的本机性能”（10%的性能损失）

– SAP测试，X86平台虚拟化后，SAP应用损失可达20%甚至更高

– X86的虚拟IO方式性能损失严重， IO性能损失可达40%甚至更高

2. 兼容性问题，Hypervisor虚拟化技术带来了更大软硬件兼容性问题

– 例如：Oracle不支持在VMWare上的 RAC环境

3. 不适合小合大、IaaS使用的服务器虚拟化不可能聚小成大

27

虚拟化适用性矩阵

低

中

高 低中

系统资源利用率/需求

适合虚拟化 特别适合虚拟化

不适合虚拟化 可以虚拟化

并发用户规模

企业级文件服务器

企业级web服务器

企业级应用服务器

企业级数据库服务器

防病毒服务器

数据库主机(用户数量较大)

终端管理服务器

域控服务器

热备环境的备机

办公服务器

用户较少使用频率较低用途单一的服务器

数据库主机(用户数量较小)

部门级文件服务器

开发/测试服务器

支持并发方式部署的web服务器

小型应用服务器

小型数据库服务器

小型消息传递类服务器

NT服务器（Win2000）

¹

1：指一般用于功能性测试/开发的低负载的应用场景。

28

目录

5 互联网IT架构 v.s 企业IT架构

X86服务器与小型机技术对比分析

一体机与软硬分离架构对比分析

虚拟化技术的引入策略

两种云中的数据库

29

集群调度分布式文件系统

GFS分布式锁服务

主服务器

客户端

支撑层

Bigtable客户端（library）

服务层

用户层

元数

据表

子表服务器

子表

子表

子表

子表服务器

子表

子表

子表服务器

子表

子表

子表

存储 存储 存储 存储

高速网络互联

N+1集群

存储层

管理控制层

存储

SAN

基于key/value的键值非关系型并行数据库

云服务提供商：Google BigTable,Amazon SimpleDB,MS SDS

开源/独立：Hadoop Hbase, ldemort,Cassandra

商用产品：Oracle NoSQL Database

关系型数据库/数据仓库解决方案

OLTP&DW:Oracle,DB2,SQL server,Sybase,MySQL

DW:Teradata,Netezza,Greenplum

两种“云”中的数据库

思考：为什么各互联网公司都开发自己的NoSQL数据库？如果Facebook的Cassandra够好，别人为什么不用呢？

30

两种“云”中的数据库背后的理论基础

CAP理论：分布式数据库的理论基础 在2000的PODC（Principles of Distributed Computing）会议上，Brewer提出了著名的CAP理论。2002年，Seth Gilbert和Nancy Lynch证明了这一理论。CAP理论指的是：Consistency（一致性）、Availability（可用性）、Tolerance to network Partitions(分区容错性），任何分布式系统只可能同时满足二点，没法三者兼顾。架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。

BASE模型：非关系型（NoSQL）分布式数据库的理论基础 BASE来自于互联网的电子商务领域的实践，它是基于CAP理论逐步演化而来，核心思想是即便不能达到强一致性(Strong consistency)，但可以根据应用特点采用适当的方式来达到最终一致性(Eventual consistency)的效果。2002年来自ebay的Dan Pritchett 在《BASE: An Acid Alternative》文章中正式提出了BASE概念。BASE是Basically Available、Soft state、Eventually consistent三个词组的简写，是对CAP中C & A的延伸。BASE的含义： （1）Basically Available：基本可用； （2）Soft-state：软状态/柔性事务，即状态可以有一段时间的不同步； （3）Eventual consistency：最终一致性； BASE是反ACID的，它完全不同于ACID模型，牺牲强一致性，获得基本可用性和柔性可靠性并要求达到最终一致性。

ACID模型：关系型（SQL）分布式数据库的理论基础 ACID是Atomicity（原子性）, Consistency（一致性）, Isolation（隔离性）, and Durability（持久性）的缩写。 Atomicity（原子性）：事务的原子性是指事务中包含的所有操作要么全做，要么全不做（all or none）。 Consistency（一致性）：在事务开始以前，数据库处于一致性的状态，事务结束后，数据库也必须处于一致性状态。 Isolation（隔离性）：事务隔离性要求系统必须保证事务不受其他并发执行的事务的影响，也即要达到这样一种效果： 对于任何一对事务T1 和 T2，在事务 T1 看来，T2 要么在 T1 开始之前已经结束，要么在 T1 完成之后才开始执行。这样，每个事务都感觉不到系统中有其他事务在并发地执行。 Durability（持久性）：一个事务一旦成功完成，它对数据库的改变必须是永久的，即便是在系统遇到故障的情况下 也不会丢失。数据的重要性决定了事务持久性的重要性。

BigTable

RDBMS CouchDB

ACID BASE

31

两种“云”中的数据库

非关系型分布式数据库

针对某类特定需求而设计

具有很强的弹性和扩展能力

规模化提供较强的并发读写能力

数据弱一致性设计

数据一致性需要应用层保障

较弱的结构化查询统计能力，一般存在较多限制

非标准/部分标准的访问接口

关系型数据库

通用性设计，但也带来了

性能的限制

通过集群提供较强的横向扩展能力

较强的并发读写能力

数据强一致性保障

很强的结构化查询与复杂分析能力

标准的数据访问接口

特定/专用的应用领域，缺乏成熟的商业产品。

产品成熟，但要在性能和伸缩性上进一步增强

VS

32

NoSQL与RDBMS是互为有益的补充

•极端的问题， 必须也只能用极端的解决方案来解决反之亦然

• Hadoop与Map/Reduce是商用数据库的一个有益补充

– Hadoop与Map/Reduce适用于并行数据ETL

– 商用数据库用于数据处理与分析：数据高度关联、数据一致性要求高、实时数据查询

Source: 《MapReduce and Parallel Databases: Friends or Foes》Communication of the ACM | January 2010 | Vol.53 | No.1

Hadoop DBMS-X DBMX-Y Hadoop/DBMS-X Hadoop/DBMS-Y

Grep 284s 194s 108s 1.5x 2.6x

Web Log 1146s 740s 268s 1.6x 4.3x

Join 1158s 32s 55s 36.3x 21x

33

案例：Facebook数据仓库架构

• Scribe Server记录web server和后台搜索服务产生的数据

• HDFS, Hive提供类似SQL的语言，结合Map/Reduce产生汇总和报表，并执行历史分析查询

– 批量处理模式

• 使用Oracle RAC 发布汇总和查询结果，查询率很高，近乎实时的响应

• 结论： Hadoop平台处理海量Web数据，不要求数据严格一致性，Oracle关系数据库处理汇总和高实时性要求数据

Hadoop@Facebook 世界上第二大Hadoop集群

用于处理 log 和dimension data

Use Case • 从大量数据中产生每天和每小时的汇总.

• 在历史数据中执行 ad hoc jobs

• 事实上作为一个长期的数据归档

• 根据特定属性来查找log, 可用于维护站点的一致性，保护用户免受垃圾邮件影响

数据仓库架构

34

ExaData混合架构带来的全并行、分布式处理模型 刀片堆叠， Exadata实现了Map/Reduce并做了大量增强

M

M

R

R

M

node

node

node

• Exadata 智能存储服务器（Shared Nothing Architecture） – 在存储部件中实现数据密集型处理

• 进行表及索引扫描，过滤查询无关数据

• 数据库服务器承担计算密集型处理（Shared Disk Architecture）

– 求和, 统计, 数据转换, 等.

数据密集型处理 智能存储池 计算密集型处理

数据库服务池

Infiniband高速互联

的数据交换

35

产品方案

•3台1/4配Exadata X2-2

实施效果

•提升最低17倍业务执行效率，最高200多倍

客户成功 - 国内北方某大型电信运营商 基于Exadata实现数据仓库ODS优化，提升17倍业务效率，提供近实时运营分析和营销服务

客户挑战

•原主平台是HP 7640和EMC存储

•ODS数据采集变慢

•ODS数据处理变慢

•ODS基础架构容量渐趋饱和

•不能支持近实时运营分析和营销服务

应用方案

•数据仓库ODS优化

•第1期：原有ODS迁移；2012年上半年将二次采购

•替换原HP rp 7640和EMC DMX3存储

OLAP-基于Exadata实现数据仓库实时ODS

客户概览

主营该省中国电信集团固定电话、移动电话、宽带和增值业务。包括14个市州分公司、95个县级分公司和13个专业分公司

2011年3月上线

国内北方某大型电信运营商采用Exadata部署规划

1. 新的EDW在体系架构、系统平台、应用三方面都得到很大的提升

2. 数据库系统性能大幅提升（实测平均17倍）

3. 同时支持OLAP，OLTP的应用

4. 向数据库云平台平滑演进

5. 上线周期短，到货一周高性能数据库即可投产

6. 单机柜高容量，降低80%

以上的机房空间需求

7. 降低50%以上的电力需求，节能减排

产品方案

• 1台满配置Exadata X2-2

实施效果(POC)

•提升100倍+数据加载速度

•提升8倍多类OLTP和OLAP应用执行效率

•数据压缩率比高于Teradata 6~8倍

客户成功 – 国内南方某省大型移动运营商 基于Exadata满配置替换Teradata实现企业级数据仓库，数据加载速度提升100倍，多类混合应用执行效率提升8倍

客户挑战

•现有3000万客户的需求不断变化且数量日益增长

•按集团要求，2012年需完成NGBASS 3.5项目建设

•现有经营分析系统使用25节点Teradata平台，超

过50TB数据，其性能、容量、数据可用性、可扩

展性、开放性无法满足业务发展需求

•需保持业务先进性，形成服务化、标准化、低成

本支撑能力

应用方案

•替换现有Teradata平台，建立企业级数据仓库，打造新一代经营分析系统

•第1期：

所有新应用的数据需求由Exadata满足

迁移现有基于Treadata平台的应用到Exadata(Teradata脚本通过工具自动转换)

OLAP-基于Exadata满配置替换现有

Teradata平台,建立企业级数据仓库

客户概览

是国内南方某省大型移动运营商

2012年上线

逐渐将中央数据仓库过渡到Exadata上 逐渐淘汰Teradata作为历史库

数据集市与历史库

Oracle DB

省中心BOSS

Oracle

中央数据仓库

Oracle Exadata

temp

数据仓库历史数据

Teradata

• 省中心BOSS数据加载到Exadata中央数据仓库中，省级BI应用迁移到Exadata中央数据仓库中

• 中央数据仓库生成的地市数据集市与历史库所需要的中间结果或分析结果加载到数据集市与历史库中

• Teradata存储中央数据仓库的远期历史数据

Application

仓库应用

Application

集市应用

Application

仓库应用

Application

集市应用

Application

仓库应用

Application

集市应用

南方某省移动运营商经分Exadata部署案例

Page 39

回顾

• 互联网IT架构与企业IT架构

• X86服务器与小型机

• 一体机与软硬分离架构

• 虚拟化技术的引入策略

• SQL与No-SQL数据库

40

41

Questions..