电信运营商数据处理架构转型中的思考 T hinking in Data Processing Architecture Transformation

© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

电信运营商数据处理架构转型中的思考Thinking in Data Processing Architecture Transformation

刘明 [email protected]云计算架构师惠普全球客户部

mailto:[email protected]


云计算和大数据时代数据处理技术的挑战和应对

© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.3

云计算和大数据时代，新的数据处理技术推动各行业业务的增长新技术带来新机遇

技术Sensors

XML LOBsIPV6

社交媒体

医疗卫生Electronic Patient Record

Medical Imaging GeneSequencing

合规Sarbanes-Oxley

HIPPABasel II

移动终端

地质勘探

传统企业ERPCRMProducts

Customers

Suppliers

Partners

金融服务Algorithmic Trading

High-frequency Trading

电信运营商

Call Detail Records


Facebook 2012

•月活动用户接近 8.5 亿•每天有 2.5 亿张图片上传•吸引互联网上 20% 的页面浏览•4.25 亿移动用户•1000 亿连接•Zygna 游戏收入占 Facebook总收入的 12%•每天 27 亿次“喜欢”点击行为•57% 的用户是女性


Twitter 2012•超过 4.65 亿账号•每天产生 1.75 亿条 tweets•每天增加 100 万账号•账号数量排名前 3 的国家是：美国 1.07 亿，巴西 3300 万，日本接近 3000 万•在 Twitter 历史上最繁忙的事件是 “ Castle in the Sky” TV ，每秒产生 25,088 条 tweets ( 之前的记录是 2012 Superbowl ，每秒产生 10,245 条 tweets).


YouTube 2012•根据 Alexa 数据， YouTube 是世界上第三大访问最频繁的网站，每天产生 20 亿访问量•占用全球 10% 互联网带宽消耗•YouTube 用户平均每天消耗900 秒•44% 的 YouTube 用户年龄介于12 到 34 岁之间•每天上传超过 829,000 视频文件•平均视频长度为 2 分 46 秒


这些对于数据处理系统意味着什么？

无处不在的数据生产和消费

难以预测的数据增长

更大的数据

更多不同种类的数据

要求更快的响应


数据处理系统变化日新月异• 关系型和非关系型• 分析型和操作型• 数据类型：

• Key Value• Document• Graph• Big table

• 数据接口• SQL• NoSQL• NewSQL

• 数据和缓存技术

Source: Database Landscape Map, 451 group, Dec 2012


传统关系数据处理系统的细分格局


几点思考

•技术上完美的通用数据处理系统是否存在？

•是否存在统一的准则来衡量各种数据处理系统的架构取舍？

•选择数据处理系统，有哪些关键架构决策？


数据处理系统需要遵循的客观规律


通用兼容

数据生命周期

技术上完美的通用数据处理系统是否存在？

强大的扩充能力

丰富的功能

快速响应

高吞吐量高度可靠

文档处理容易恢复

简单易用 ACID

自动分层自动优化

自动优化

不间断运行动态适应安全

适应各种数据


CAP 定理，限制分布式系统特性的通用法则CAP 定理，也被称为 Brewer 定理，最早在 1998 年秋季提出，1999 年正式发表，并在 2000 年登上 Symposium on Principles of Distributed Computing 大会的主题演讲，最终确立了该理论的正确性。 CAP 定理证明在分布式系统中不可能同时提供以下三种保证：

Consistency 一致性，所有节点在同一时间看到同样的数据

Availability 可用性，保证每个请求都能收到成功或失败的响应

Partition tolerance 分区容忍性，在消息传递丢失或者某个部分失效的情况下，系统仍然能够继续工作Source: CAP theorem, Wikipedia

http://en.wikipedia.org/wiki/Consistency_(database_systems)

http://en.wikipedia.org/wiki/Availability

http://en.wikipedia.org/w/index.php?title=Network_partitioning&action=edit&redlink=1


CAP 法则，三选其二不同的选择，将产生具备不同特性的数据处理系统

Consistent & Available

• 不允许分区• 通过各种技术避免

分区

Consistent & Partitionable

• 发生分区时，服务不可用以保证一致性

• 否则，一个节点和另外一个节点的数据将处于不同的版本

Available & Partitionable

• 发生分区时，允许不同的节点报告不同的数据版本，以保证整个系统的可用性

• 数据在短时间内的不一致难以避免

• 依赖于此的上层应用会受到影响

传统关系型数据库需要遵从 ACID 原则，因此通常选择 Consistent & Available ；而分布式系统将 Partitionable 视为首要原则，因此通常在 CP 和 AP 之间权衡选择


主流数据处理系统的 CAP 选择

A

C P

Availability:Each client canalways read and write.

ConsistencyAll clients alwayshave the sameview of data

Partition Tolerance:The system workswell despite physical network partitions

CA

RDBMSs(MySQL,Postgres,etc.)

Aster DataGreenplumVertica

AP

DynamoVoldermortTokyo CabinetKAI

CassandraSimpleDBCouchDBRiak

CPMongoDBTerrastoreScalaris

Berkeley DBMemcache DBRedis

Big TableHypertableHBase

Data Models

Rational(comparison)Key-ValueColumn-Oriented/TabularDocument-Oriented

Pick Two

Source: Visual Guide to NoSQL Systems, Nathan Hurst's Blog.


限制数据处理系统扩展能力的其他法则阿姆达尔定律 Amdahl’s Law限制分布式系统加速比


限制数据处理系统扩展能力的其他法则通用扩展性定律 Universal Scalability Law限制系统加速比，在 Amdahl’s Law基础之上进一步考虑处理节点之间的数据耦合度

Source: “Guerilla Capacity Planning”, Dr. Neil Gunther.


平衡与折衷

最大化扩展能力：•向外扩展•大量小型处理节点•Share-nothing•BASE•应用改造和拆分•软件容错

最大化功能性：•向上扩展•少量大型处理节点•Share-everything•ACID•避免分区•硬件容错

得：•几乎无限的扩展能力•低硬件采购成本

失：•编程模型复杂•管理运维成本高•人员技能要求高•应用功能限制多

得：•实现容易，特性丰富•架构简单•研发和运维容易

失：•扩展能力相对有限•硬件采购成本较高


结论没有完美的数据处理系统

扩展能力与应用架构高度相关

为不同的应用选择合适的架构


数据处理架构关键技术决策


• 数据架构决策− 是否采用 Share-nothing 架构？− 向外扩展还是向上扩展？− CA ， CP还是 AP ？

• 基础设施选择− 小节点还是大节点？

如何选择合适的数据处理系统？


Share-nothing 还是 Share-something

不仅仅是数据处理层架构，也是应用层架构，代表应用层访问数据层的方式：

选择 Share-nothing ：是否需要水平扩展？需要对上层架构进行解耦和拆分，重新梳理数据架构和应用架构面临 CAP 选择

Share-nothing 系统吞吐能力受 Amdahl’s Law约束，应着重优化串行操作，采用缓存，减少锁定，减少处理枢纽

Share-something ：根据 Universal Scalability Law ， Share-something 系统向外扩展能力有限，以向上扩展为主


向外扩展还是向上扩展？两者可以同时进行，但需要尽早决定以何为主

向外扩展可能意味着架构“突变”，传统应用很难“平滑过渡”

向上扩展非常容易，但扩展能力有限

适用于复杂的应用，难以切分的应用，小型应用，快速变化的应用

向外扩展提供灵活性，但增加系统复杂度，并立即对上层应用产生一致性和可用性的影响

适用于规模无法预测，功能相对单一的应用


向外扩展还是向上扩展 - TCO 分析

Initi

al In

vstm

t.(Cap

Ex)

Year

1

Year

2

Year

3

Year

4

Year

5

Year

6$0.00

$20,000.00

$40,000.00

$60,000.00

$80,000.00

$100,000.00

$120,000.00

向外扩展 ( 左 ) vs. 向上扩展 ( 右 ) TCO 比较

Facilities costsIn-Direct costsSW costsHW costs

结论：向上扩展可能更省。以主流服务器机型，开源操作系统和数据库管理系统为例，比较两种扩展方向 6 年内的总体拥有成本，配置如下：硬件配置• 向外扩展 :4x Dell PowerEdge R510

(Intel E5620 series, 16GB RAM)

• 向上扩展 :Dell PowerEdge R815 (4xAMD 6168 series, 128GB RAM)

软件配置• Red Hat Enterprise Linux Server for

32/64-bit x86

• Apache CassandraSource: Info-Tech Research Group


纯粹的向外扩展并不节省成本，带来的直接成本包括：• 更高的软件 license成本• 更高的设备故障率带来的硬件成本• 更多的机房占地和能耗带来的运维成本• 管理更多节点带来的运维成本

向外扩展还应考虑架构变化带来的间接成本：• 上层应用架构适应性调整的成本• 系统复杂度提升带来的额外管理和运维成本• 人员技能要求提高带来的额外人员成本

向外扩展还是向上扩展 - TCO 分析


CA ， CP 还是 AP ？

• 适用场景： CA 系统适合对一致性和可用性要求很高的 OLTP 类应用，通常能够提供非常丰富的特性，对应用功能性支持最好

• 架构补足： CA 系统可以考虑采用高速缓存，内存数据库网格，反向代理等技术提升单节点能力，弥补对外扩展能力的不足

• 适用场景： CP 系统适合批量类应用，这类应用读和写相对独立，对一致性和系统总体吞吐能力要求高，对不间断运行的要求相对 OLTP系统低

• 架构补足： CP 系统需要提升单节点的可用性弥补系统可用性的不足

对于向外扩展架构，需要选择适用场景并做好架构补足在同一套数据处理系统中可能同时存在多种选择：

• 适用场景： AP 系统适合超大规模数据处理类应用，这类应用由于节点数众多，节点物理失效为常态，因此必须从系统层面保证可用性；

• 适用场景： AP 系统非常适合只读类系统 ,这类系统不存在数据一致性问题

• 架构补足： AP 系统通常需要在应用层面采用 BASE设计，保证数据的最终一致性

CA

CP

AP


大节点系统还是小节点系统？大节点系统单节点能力强，扩展性好，能弥补系统水平扩展能力的不足

• 节点数更少，架构更简单，管理也更容易• 单节点通常具备很高的可靠性和可用性• 相对小节点系统，硬件成本较高• 大节点选型，应侧重模块化扩展能力，虚拟化能力，性能，

可靠性与可用性，安全等方面

小节点系统通常高度标准化，低成本，适合批量大规模部署环境

单节点可靠性和性能不高，通常需要从软件层面保证系统可用性节点数量较多，系统结构更加复杂，管理和维护成本较高小节点选型，应侧重标准化，模块化，计算密度，易管理性等方面


独立存储还是分布式存储主要考虑因素：性能，扩展能力，数据安全，成本，两种最常见的企业存储扩展模式：

1. 存储随计算节点扩展：使用计算节点直连存储，计算能力，存储容量，存储性能三者同时扩展

2. 存储系统独立扩展：使用独立的存储系统网络，计算能力，存储容量和存储性能三者各自独立扩展

第一种模式采购成本相对较低，需要重点考虑容错能力，扩展能力，对上层接口的多样性，易管理性；

第二种模式采购成本相对较高，需要重点考虑性能，效率，安全性，扩展性和对上层架构的 QoS 的支持。


几种典型架构模式

1. Share Nothing + Scale-Out + CP/AP + 小节点 + 分布式存储特点：高吞吐量，批量处理，软件定义基础设施典型实现： HP Vertica, HP StoreAll Storage

2. Share Nothing + Scale-Out + CP + 小节点 + 分布式存储 + 超高可靠技术

特点：高并发和高吞吐量，联机事务和批量处理典型实现： HP Non-stop

3. Share Everything + Scale-Up + CA + 大节点 + 独立存储特点：联机事务， HA ，关键业务典型实现： HP Integrity + StoreServ Storage

4. Share Something + Limited Scale-Out + CA + 大节点 + 独立存储

特点：高并发，高可靠，联机事务，关键业务典型实现： HP Integrity/Mission Critical x86 + StoreServ Storage


中国联通数据处理架构关键技术决策建议

© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.31 31

中国联通信息系统现状

管理信息系统以集中 ERP 为核心，基本完成MSS 全域集中建设，初步实现了财务、人力、采购、计划建设等基础管理的规范化支撑

生产支撑系统以集中 ESS 为龙头，推动经营活动的规范化管理，实现透明管控；集中结算、合作伙伴、渠道等系统的建设和应用，不断深化透明管控，有效提升竞争力

全面推进的集中数据分析系统的建设，为管理、经营提供统一口径数据，正在推进“一个集团，一副面孔”的深度实现

公司融合后，信息化始终坚持实施一体化战略， IT 一体化框架已经基本形成，集中化系统能力优势已初步显现。

确立了资源管理、电子运维集中化建设目标，继续推进专业网管优化整合


(1) 面向用户的请求处理型：订单受理、资料查询、订单处理等请求处理型应用。(2) 面向网络的重复性任务：话单采集、格式转换等简单、重复性计算处理。(3) 核心是复杂任务计算：复杂的计费、账务处理，以及基于关系型数据库的数据处理等。• 业务维度多，关联关系复杂

− 客户：品牌、分群、信用度、黑 /白名单、客户等级、服务等级等− 产品：类型、属性、状态等− 套餐：互斥、依赖、保底、优惠、协议时长

• 计费规则复杂：套餐、话单、计费规则。

(4) 海量数据分析与挖掘：经营分析、针对性营销等。

中国联通系统计算特点

①

②④

订单处理

采集、激活计费，及各数据库③


计算特点技术要求主要扩展方向

CAP 选择

节点

面向用户的请求处理型订单受理、资料查询、订单处理等请求处理型应用

典型的 OLTP 类型应用，应用变动频繁，一致性要求高，可靠性和可用性要求高

向上 CA 大节点 /小节点

面向网络的重复性任务话单采集、格式转换等简单、重复性计算处理

批量类应用，简单计算模型，数据量大，对总体吞吐量要求高

向外 /向上 CP 大节点 /小节点

核心是复杂任务计算复杂的计费、账务处理，以及基于关系型数据库的数据处理等

复杂计算，数据关联复杂，对数据库层查询分析功能要求高

向上 CA 大节点

海量数据分析与挖掘经营分析、针对性营销等

典型的 OLAP 类应用，海量数据处理

向外 AP / CP 小节点

分析和建议


Thank you

Documents

电信运营商 数据处理架构转型中的思考 T hinking in Data Processing Architecture Transformation

电信运营商数据处理架构转型中的思考 T hinking in Data Processing Architecture Transformation