—王勇极限存储设计原理与实践.pptxVIP

1 极限存储设计原理及实践 数据平台与产品部 图海 2017年5月28日 2 云梯1 其他集群 点击流日志 LogServer everyday… everytime… 云梯的存储职责 怎么办?怎么办?怎么办? 删除历史数据，立竿见影，省力又省事 怎么办? “21世纪核心的竞争是数据的竞争” “谁拥有更多数据，谁就拥有未来” 前端交易系统、商品中心、用户中心等出于效率的考虑，不会长期保存大量历史数据，而数据仓库作为企业数据分析及挖掘的基础设施，天生具有保存历史数据的职责，非但如此，如何快速、高效的获取历史上任意一天的快照数据也成为设计历史数据存放方式时的重要考量。 数据分类 商品表: 商品ID 商品名 商品状态 创建时间 所属类目 …… 交易表: 订单ID 支付ID 物流ID 支付时间 订单状态 …… 典型操作: 新增商品/订单(new) 商品/订单状态变更(update) 商品下线/订单撤销(delete) 典型的数据库增删改操作 数据特点: 有业务主键，确保记录唯一性 全量快照数据量巨大(1TB)，数据分析需要全量快照数据 每日变更量占比很少(远低于5%) 数据记录冗余度非常高 注:变更指发生增删改的记录 ※当时存量数据中70%属于此类特征的业务数据，且记录冗余度高 数据分类 评价增量表: 评价ID 用户星级 用户昵称 评价记录 商品名称 …… 点击流日志: 记录时间 IP地址 引用链接 机器ID 用户ID …… 数据特点: 没有业务主键 属于日志流水，每日新增数据 数据记录重复程度非常低，每条都基本唯一 数据记录冗余度基本为0 ※存储总体占比不高，且数据冗余度较低，优化空间有限 数据特点: 有业务主键，确保记录唯一 数据只有新增操作，不会变更或删除 每天只需保留当天新增评价 数据记录冗余度基本为0 思考讨论 问题: 如何设计方案达到以下效果? 减少/去除冗余数据，降低存储成本 保证快照数据的快速访问 对业务应用透明或降低应用改造成本 参考方案 注:类似于数据库系统中常见的增量备份或周期备份策略 优点: 易于理解，在数据库备份中广泛应用 实现较为简单 缺点: 访问快照数据成本太高 无法直接反应删除/被变更数据，需要额外设计 应用改造成本较高 记录生命周期 数据天生以行进行分割，行数据在数据库中称为一条数据记录(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 极限存储原理 三个结论: 任意一条记录，由于其生命周期确定，必定对应唯一的一个数据标签 一个数据标签对应符合该生命周期的记录集合(该记录集合有为空的可能性) 历史上出现的所有记录，必然可以成功的划分到不同的生命周期数据标签里去 历史快照原理 TimeLine 所有被蓝色线条经过的数据标签，其数据内容组合起来即为0414这天的数据全量快照 同理，历史上任意一天的数据快照均可以该方式获得 方案主体逻辑 包含以下主要步骤： 1.通过主键关联对比昨天全量和今天全量的数据差异，并将这些数据区分为活跃(Lived)或过期(Expired)数据。 2.对于对比的结果数据进行统计，获得每个生命周期下实际的数据条数，统计结果用来产生不同生命周期的记录到文件目录的映射。 3.使用mapreduce数据对第1步结果进行分发，相同生命周期的数据会被写入到对应的唯一的生命周期目录下(依赖2的统计结果)。 4.使用hive的双重分区映射生命周期目录，这样用户可以通过灵活的hive分区过滤来获得期望的数据。 5.数据验证，为了保证应用极限存储后结果的正确性，因此增加了数据条数对比的验