阿里开源协议.docVIP

阿里开源协议 篇一：技术解读阿里去IOE后的系统架构 从Hadoop到自主研发，技术解读阿里去IOE后的系统架构 浏览次数：437次 CSDN 2014年11月02日 字号: 大 中 小 分享到：QQ空间新浪微博腾讯微博人人网豆瓣网开心网更多0 【导读】互联网的普及，智能终端的增加，大数据时代悄然而至。在这个数据为王的时代，数十倍、数百倍的数据给各个机构带来了无尽的机遇；然而，无可否认的是，数据体积的暴增同样前所未有的挑战着企业的基础设施。 在这个大背景下，各个机构不得不在控制好成本支出的同时，不停摸索着时刻激增用户数据的解决之道，其中阿里的成绩无疑令人艳羡——单集群规模5000+的飞天，以及多集群跨机房计算的支持。本次我们将以飞天为例，为大家分享大规模分布式系统打造过程中的艰难坎坷及应对之道。 本次分享共分为视点、技术专题、应用实践三大板块：“视点”从人物着手细分阿里当时所面临的形势及各个据测制定的依据；“技术专题”主要从实践出发剖析飞天5000节点扩展时所遭遇的艰难险阻及应对之道，涉及架构调整、性能优化、系统运维等多个领域；“应用实践”则更注重于云实践经验及用例分享。 目录 视点 1. 2. 3. 阿里云观察2014 阿里技术保障部：阿里云的幕后英雄 不期而遇的飞天之路 技术专题 探索5K巅峰，云梯架设的飞天之梦。在3个月deadline的情况下，阿里却选择投入更多人力物力及时间的云梯1（以Hadoop为底层的集群）和云梯2（以飞天为底层的集群）并行扩容，阿里人选择背水一战的原因究竟是什么？在这个过程中，他们又会遭遇哪些挑战？目标实现后的惊喜又是什么？ 优化无极限：盘古Master优化实践。盘古，飞天的分布式文件系统，在内部架构上盘古采用Master/ChunkServer结构，Master管理元数据，ChunkServer负责实际数据读写，通过Client对外提供类POSIX的专有API。在集群扩展到5K规模后，相关问题纷至沓来，主要可分为两个部分：首先，盘古MasterIOPS问题；其次，盘古Master冷启动速度。那么究竟是什么造成了这些问题？阿里工程师又该如何应对？ 走近伏羲，谈5000节点集群调度与性能优化。伏羲，飞天平台的分布式调度系统。在5K攻坚中，从设计到实现每一步都可能存在性能“陷阱”，原因主要在三个方面：规模放大效应；木桶效应；长路径模块依赖。5000节点后这些方面究竟存在什么样的问题？阿里人又通过了什么方法保证了服务的性能与稳定性？ 走近华佗，解析自动化故障处理系统背后的秘密。5K后的运维模式究竟会产生什么样的变化？阿里人究竟为什么会开发华佗？上通飞天系统，下达运维各种系统，华佗健壮、简单和开放的架构究竟表现在什么方面？系统又是如何实现了自动化的运维？ ODPS技术架构及应用实践。ODPS采用抽象的作业处理框架将不同场景的各种计算任务统一在同一个平台之上，共享安全、存储、数据管理和资源调度，为来自不同用户需求的各种数据处理任务提供统一的编程接口和界面。那么，在DT时代，不断扩大的数据规模又会给ODPS带来什么样的挑战？网站日志分析又该如何进行？ ODPS跨集群迁移与数据同步经验分享。阿里各业务部门如淘宝、天猫、一淘、B2B等每天都会产生大量的数据，日均增量数百TB。2013年初，阿里内部的生产集群PA所在机房的存储量最多可扩容到数十PB，而当时已使用75% 的存储量。存储容量告急，迫切需要将生产集群PA上的大量数据迁移到其他集群。那么阿里人该如何安全地跨集群迁移几十PB的数据和其上相关业务？数据迁移之后，两个集群间存在大量的数据依赖，需要互相访问最新的数据，如何安全快速地实现跨集群数据同步？ 飞天5K实战经验：大规模分布式系统运维实践。但短时间大规模快速膨胀的现状，给运维带来了巨大挑战，其中云梯2单集群规模更是从1500台升级到5000台。为此，运维需要做多个方向的调整，比如：提升全局掌控能力、实现系统的自我保护和自动化修复、大规模与精细化的平衡。那么，阿里又是通过什么途径完成这些工作的？ 应用实践 1. 2. 3. 节选 《不期而遇的飞天之路》——去IOE，飞天势在必行 翻开历史，淘宝曾启用全亚洲最大的OracleRAC集群，阿里更是购买过3年无限制的许可，阿里在IBM小型机以及EMC SAN存储上的投入也曾成为媒体争相报道的事件。但随着互联网爆发式发展，淘宝、支付宝和阿里巴巴B2B的注册用户数激增，阿里只能不停地通过水平和垂直扩展架构来应对新增用户生成的海量数据。而这种集中式数据库的架构，使得数据库成为了整个系统的瓶颈，越来越不适应海量数据对计算能力的巨大需求，更不用说越来越难以承受的高昂投入。阿里的“去IOE”已经势在必行：通过自主研发的分布式系统取