1 / 34

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

电信运营商 数据处理架构转型中的思考 T hinking in Data Processing Architecture Transformation. 刘明 liuming@hp.com 云计算架构师 惠普全球客户部. 云计算和大数据时代 数据处理技术的挑战和应对. 新技术带来新机遇. 云计算和大数据时代，新的数据处理技术推动各行业业务的增长. 技术. IPV6. Sensors. 地质勘探. XML. LOBs. 医疗卫生. 社交媒体. Electronic Patient Record. 移动终端. 电信运营商. Medical Imaging.

zia-rodriguez
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 电信运营商数据处理架构转型中的思考Thinking in Data Processing Architecture Transformation 刘明 liuming@hp.com 云计算架构师 惠普全球客户部

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

  3. 新技术带来新机遇 云计算和大数据时代，新的数据处理技术推动各行业业务的增长 技术 IPV6 Sensors 地质勘探 XML LOBs 医疗卫生 社交媒体 Electronic Patient Record 移动终端 电信运营商 Medical Imaging Call Detail Records GeneSequencing 金融服务 合规 Algorithmic Trading Sarbanes-Oxley 传统企业 ERP CRM HIPPA Products Suppliers Basel II Customers Partners High-frequency Trading

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

  5. 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).

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

  7. 这些对于数据处理系统意味着什么？ 无处不在的数据生产和消费 难以预测的数据增长 更大的数据 更多不同种类的数据 要求更快的响应

  8. 数据处理系统变化日新月异 • 关系型和非关系型 • 分析型和操作型 • 数据类型： • Key Value • Document • Graph • Big table • 数据接口 • SQL • NoSQL • NewSQL • 数据和缓存技术 Source: Database Landscape Map, 451 group, Dec 2012

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

  10. 几点思考 • 技术上完美的通用数据处理系统是否存在？ • 是否存在统一的准则来衡量各种数据处理系统的架构取舍？ • 选择数据处理系统，有哪些关键架构决策？

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

  12. 技术上完美的通用数据处理系统是否存在？ 强大的扩充能力 高吞吐量 安全 高度可靠 动态适应 不间断运行 丰富的功能 自动优化 自动分层 容易恢复 文档处理 通用兼容 自动优化 快速响应 适应各种数据 ACID 简单 数据生命周期 易用

  13. CAP定理，限制分布式系统特性的通用法则 CAP定理，也被称为Brewer定理，最早在1998年秋季提出，1999年正式发表，并在2000年登上Symposium on Principles of Distributed Computing大会的主题演讲，最终确立了该理论的正确性。CAP定理证明在分布式系统中不可能同时提供以下三种保证： Consistency一致性，所有节点在同一时间看到同样的数据 Availability可用性，保证每个请求都能收到成功或失败的响应 Partition tolerance分区容忍性，在消息传递丢失或者某个部分失效的情况下，系统仍然能够继续工作 Source: CAP theorem, Wikipedia

  14. CAP法则，三选其二 • 不同的选择，将产生具备不同特性的数据处理系统 Consistent & Available Consistent & Partitionable Available & Partitionable • 不允许分区 • 通过各种技术避免分区 • 发生分区时，服务不可用以保证一致性 • 否则，一个节点和另外一个节点的数据将处于不同的版本 • 发生分区时，允许不同的节点报告不同的数据版本，以保证整个系统的可用性 • 数据在短时间内的不一致难以避免 • 依赖于此的上层应用会受到影响 传统关系型数据库需要遵从ACID原则，因此通常选择Consistent & Available； 而分布式系统将Partitionable视为首要原则，因此通常在CP和AP之间权衡选择

  15. 主流数据处理系统的CAP选择 Rational(comparison) Key-Value Column-Oriented/Tabular Document-Oriented A Availability: Each client can always read and write. Data Models AP CA Aster Data Greenplum Vertica RDBMSs (MySQL, Postgres, etc.) Cassandra SimpleDB CouchDB Riak Dynamo Voldermort Tokyo Cabinet KAI Pick Two C P CP Consistency All clients always have the same view of data Partition Tolerance: The system works well despite physical network partitions Berkeley DB Memcache DB Redis MongoDB Terrastore Scalaris Big Table Hypertable HBase Source: Visual Guide to NoSQL Systems, Nathan Hurst's Blog.

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

  17. 限制数据处理系统扩展能力的其他法则 通用扩展性定律Universal Scalability Law限制系统加速比， 在Amdahl’s Law基础之上进一步考虑处理节点之间的数据耦合度 Source: “Guerilla Capacity Planning”, Dr. Neil Gunther.

  18. 平衡与折衷 • 得： • 实现容易，特性丰富 • 架构简单 • 研发和运维容易 • 得： • 几乎无限的扩展能力 • 低硬件采购成本 • 最大化扩展能力： • 向外扩展 • 大量小型处理节点 • Share-nothing • BASE • 应用改造和拆分 • 软件容错 • 最大化功能性： • 向上扩展 • 少量大型处理节点 • Share-everything • ACID • 避免分区 • 硬件容错 • 失： • 扩展能力相对有限 • 硬件采购成本较高 • 失： • 编程模型复杂 • 管理运维成本高 • 人员技能要求高 • 应用功能限制多

  19. 结论 没有完美的数据处理系统 扩展能力与应用架构高度相关 为不同的应用选择合适的架构

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

  21. 如何选择合适的数据处理系统？ • 数据架构决策 • 是否采用Share-nothing架构？ • 向外扩展还是向上扩展？ • CA，CP还是AP？ • 基础设施选择 • 小节点还是大节点？

  22. Share-nothing还是Share-something 不仅仅是数据处理层架构，也是应用层架构，代表应用层访问数据层的方式： 选择Share-nothing： 是否需要水平扩展？ 需要对上层架构进行解耦和拆分，重新梳理数据架构和应用架构 面临CAP选择 Share-nothing系统吞吐能力受Amdahl’s Law约束，应着重优化串行操作，采用缓存，减少锁定，减少处理枢纽 Share-something：根据Universal Scalability Law，Share-something系统向外扩展能力有限，以向上扩展为主

  23. 向外扩展还是向上扩展？ 两者可以同时进行，但需要尽早决定以何为主 向外扩展可能意味着架构“突变”，传统应用很难“平滑过渡” 向上扩展非常容易，但扩展能力有限 适用于复杂的应用，难以切分的应用，小型应用，快速变化的应用 向外扩展提供灵活性，但增加系统复杂度，并立即对上层应用产生一致性和可用性的影响 适用于规模无法预测，功能相对单一的应用

  24. 向外扩展还是向上扩展 - TCO分析 结论：向上扩展可能更省。 以主流服务器机型，开源操作系统和数据库管理系统为例，比较两种扩展方向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 Cassandra Source: Info-Tech Research Group

  25. 向外扩展还是向上扩展 - TCO分析 纯粹的向外扩展并不节省成本，带来的直接成本包括： 更高的软件license成本 更高的设备故障率带来的硬件成本 更多的机房占地和能耗带来的运维成本 管理更多节点带来的运维成本 向外扩展还应考虑架构变化带来的间接成本： 上层应用架构适应性调整的成本 系统复杂度提升带来的额外管理和运维成本 人员技能要求提高带来的额外人员成本

  26. CA，CP还是AP？ 对于向外扩展架构，需要选择适用场景并做好架构补足 在同一套数据处理系统中可能同时存在多种选择： • 适用场景： CA系统适合对一致性和可用性要求很高的OLTP类应用，通常能够提供非常丰富的特性，对应用功能性支持最好 • 架构补足： CA系统可以考虑采用高速缓存，内存数据库网格，反向代理等技术提升单节点能力，弥补对外扩展能力的不足 CA • 适用场景： CP系统适合批量类应用，这类应用读和写相对独立，对一致性和系统总体吞吐能力要求高，对不间断运行的要求相对OLTP系统低 • 架构补足： CP系统需要提升单节点的可用性弥补系统可用性的不足 CP • 适用场景： AP系统适合超大规模数据处理类应用，这类应用由于节点数众多，节点物理失效为常态，因此必须从系统层面保证可用性； • 适用场景： AP系统非常适合只读类系统,这类系统不存在数据一致性问题 • 架构补足： AP系统通常需要在应用层面采用BASE设计，保证数据的最终一致性 AP

  27. 大节点系统还是小节点系统？ • 大节点系统单节点能力强，扩展性好，能弥补系统水平扩展能力的不足 • 节点数更少，架构更简单，管理也更容易 • 单节点通常具备很高的可靠性和可用性 • 相对小节点系统，硬件成本较高 • 大节点选型，应侧重模块化扩展能力，虚拟化能力，性能，可靠性与可用性，安全等方面 小节点系统通常高度标准化，低成本，适合批量大规模部署环境 单节点可靠性和性能不高，通常需要从软件层面保证系统可用性 节点数量较多，系统结构更加复杂，管理和维护成本较高 小节点选型，应侧重标准化，模块化，计算密度，易管理性等方面

  28. 独立存储还是分布式存储 主要考虑因素：性能，扩展能力，数据安全，成本 ，两种最常见的企业存储扩展模式： 存储随计算节点扩展：使用计算节点直连存储，计算能力，存储容量，存储性能三者同时扩展 存储系统独立扩展：使用独立的存储系统网络，计算能力，存储容量和存储性能三者各自独立扩展 第一种模式采购成本相对较低，需要重点考虑容错能力，扩展能力，对上层接口的多样性，易管理性； 第二种模式采购成本相对较高，需要重点考虑性能，效率，安全性，扩展性和对上层架构的QoS的支持。

  29. 几种典型架构模式 • Share Nothing + Scale-Out + CP/AP + 小节点+ 分布式存储 • 特点：高吞吐量，批量处理，软件定义基础设施 • 典型实现：HP Vertica, HP StoreAll Storage • Share Nothing + Scale-Out + CP + 小节点 + 分布式存储 + 超高可靠技术 • 特点：高并发和高吞吐量，联机事务和批量处理 • 典型实现：HP Non-stop • Share Everything + Scale-Up + CA + 大节点 + 独立存储 • 特点：联机事务，HA，关键业务 • 典型实现：HP Integrity + StoreServ Storage • Share Something + Limited Scale-Out + CA + 大节点 + 独立存储 • 特点：高并发，高可靠，联机事务，关键业务 • 典型实现：HP Integrity/Mission Critical x86 + StoreServ Storage

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

  31. 中国联通信息系统现状 公司融合后，信息化始终坚持实施一体化战略，IT一体化框架已经基本形成，集中化系统能力优势已初步显现 。 管理信息系统以集中ERP为核心，基本完成MSS全域集中建设，初步实现了财务、人力、采购、计划建设等基础管理的规范化支撑 生产支撑系统以集中ESS为龙头，推动经营活动的规范化管理，实现透明管控；集中结算、合作伙伴、渠道等系统的建设和应用，不断深化透明管控，有效提升竞争力 确立了资源管理、电子运维集中化建设目标，继续推进专业网管优化整合 全面推进的集中数据分析系统的建设，为管理、经营提供统一口径数据，正在推进“一个集团，一副面孔”的深度实现

  32. 中国联通系统计算特点 • (1)面向用户的请求处理型：订单受理、资料查询、订单处理等请求处理型应用。 • (2)面向网络的重复性任务：话单采集、格式转换等简单、重复性计算处理。 • (3)核心是复杂任务计算：复杂的计费、账务处理，以及基于关系型数据库的数据处理等。 • 业务维度多，关联关系复杂 • 客户：品牌、分群、信用度、黑/白名单、客户等级、服务等级等 • 产品：类型、属性、状态等 • 套餐：互斥、依赖、保底、优惠、协议时长 • 计费规则复杂：套餐、话单、计费规则。 • (4)海量数据分析与挖掘：经营分析、针对性营销等。 ① 订单处理 ④ ③ ② 计费，及各数据库 采集、激活

  33. 分析和建议

  34. Thank you

More Related