海量数据的高效存储_---_淘宝云梯极限存储的原理和实践.pptVIP

* * * * * * * * * * * * * * * * * * * * * * 非分区表:dual 单分区表:tb_users 多分区表:tb_auctions * 非分区表:dual 单分区表:tb_users 多分区表:tb_auctions * * * * * * * 极限存储设计原理及实践 淘宝-数据平台与产品部 图海 * * 云梯1 前端RDBMS 其他集群 点击流日志 LogServer everyday… everytime… 云梯的存储职责 DataX TimeTunnel DBSync 怎么办?20080102……商品表 500G 502G 505G …G 1000G “21世纪核心的竞争是数据的竞争” “谁拥有更多数据，谁就拥有未来” 前端交易系统、商品中心、用户中心等出于效率的考虑，不会长期保存大量历史数据，而数据平台作为企业数据分析及挖掘的基础设施，天生具有保存历史数据的职责，非但如此，如何快速、高效的获取历史上任意一天的快照数据也成为设计历史数据存放方式时的重要考量。 数据分类 商品表: 商品ID 商品名 商品状态 创建时间 所属类目 …… 交易表: 订单ID 支付ID 物流ID 支付时间 订单状态 …… 典型操作: 新增商品/订单(new) 商品/订单状态变更(update) 商品下线/订单撤销(delete) 典型的数据库增删改操作 数据特点: 有业务主键，确保记录唯一性 全量快照数据量巨大(1TB)，数据分析需要全量快照数据 每日变更量占比很少(远低于5%) 数据记录冗余度非常高 注:变更指发生增删改的记录 ※当时存量数据中70%属于此类特征的业务数据，且记录冗余度高 数据分类 评价增量表: 评价ID 用户星级 用户昵称 评价记录 商品名称 …… 点击流日志: 记录时间 IP地址 引用链接 机器ID 用户ID …… 数据特点: 没有业务主键 属于日志流水，每日新增数据 数据记录重复程度非常低，每条都基本唯一 数据记录冗余度基本为0 ※存储总体占比不高，且数据冗余度较低，优化空间有限 数据特点: 有业务主键，确保记录唯一 数据只有新增操作，不会变更或删除 每天只需保留当天新增评价 数据记录冗余度基本为0 思考讨论20100907 参考方案 增量数据 2010年4月2日全量 latest分区 2010年4月2日失效分区 2010年4月1日全量 2010年4月2日 2010年4月1日 2010年4月3日全量 latest分区 2010年4月3日失效分区 2010年4月3日 2010年4月30日全量 latest分区 2010年4月30日失效分区 2010年4月30日 … 增量数据 增量数据 注:类似于数据库系统中常见的增量备份或周期备份策略 优点: 易于理解，在数据库备份中广泛应用 实现较为简单 缺点: 访问快照数据成本太高 无法直接反应删除/被变更数据，需要额外设计 应用改造成本较高 记录生命周期 数据天生以行进行分割，行数据在数据库中称为一条数据记录(Record). 一条记录对应可能有Insert/Update/Delete操作 Insert通常对应一条全新的记录，意味着记录的新生 Delete通常是原有的记录被删除，意味着记录的死亡 Update是在原有的记录上修改某些字段，一条Update操作可以拆分为Delete/Insert原子对操作，即从记录的维度来看，相当于前一条记录死亡，后一条记录新生 因此，我们可以认为，任何一条记录(行数据)必定在历史上某天新生(start)，并在其后的某一天死亡(end)，而这个start-end对就定义为该记录的生命周期。 活跃数据和死亡数据 活跃数据 一条记录，在其产生之后直至当天仍旧存活(未被Delete/Update)，那么我们认为它是一条活跃数据 对于活跃数据，其产生(start)日期已经明确，但死亡(end)日期并不确定 数据标签:start-INFINITY(无穷大),INF 死亡数据 一条记录，在当天以前就被更改 (被Delete/Update)，那么我们认为它是一条死亡了的数据 对于死亡数据，其产生(start)和死亡(end)日期都已经明确 数据标签:start-end,200110423 INF目录存放在某一天新增并且一直未曾被删除或修改的记录(即活跃数据) 此处省略一万字 0901-0902 0901-0903 0901-0904 0901-09.. 0901-0930 0901-INF 0902-0903 0902-0904 0902-09.. 0902-0930 0902