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

1极限存储设计原理及实践淘宝-数据平台与产品部 图海2024年4月21日2场景方案效果优化云梯云梯1前端RDBMS其他集群点击流日志LogServereverydayeverytime云梯的存储职责DataXTimeTunnelDBSync怎么办?20080101200801022008010320110720商品表500G502G505GG1000G“21世纪核心的竞争是数据的竞争”“谁拥有更多数据，谁就拥有未来”前端交易系统、商品中心、用户中心等出于效率的考虑，不会长期保存大量历史数据，而数据平台作为企业数据分析及挖掘的基础设施，天生具有保存历史数据的职责，非但如此，如何快速、高效的获取历史上任意一天的快照数据也成为设计历史数据存放方式时的重要考量。数据分类数据分类商品表:商品ID商品名商品状态创建时间所属类目交易表:订单ID支付ID物流ID支付时间订单状态 典型操作:新增商品/订单(new)商品/订单状态变更(update)商品下线/订单撤销(delete)典型的数据库增删改操作数据特点:有业务主键，确保记录唯一性全量快照数据量巨大(1TB)，数据分析需要全量快照数据每日变更量占比很少(远低于5%)数据记录冗余度非常高注:变更指发生增删改的记录当时存量数据中70%属于此类特征的业务数据，且记录冗余度高数据分类数据分类评价增量表:评价ID用户星级用户昵称评价记录商品名称点击流日志:记录时间IP地址引用链接机器ID用户ID数据特点:没有业务主键属于日志流水，每日新增数据数据记录重复程度非常低，每条都基本唯一数据记录冗余度基本为0存储总体占比不高，且数据冗余度较低，优化空间有限数据特点:有业务主键，确保记录唯一数据只有新增操作，不会变更或删除每天只需保留当天新增评价数据记录冗余度基本为0思考思考&讨论讨论20100906201009062010090620100906消失记录消失记录消失记录消失记录(包括被删除及被变更记录包括被删除及被变更记录包括被删除及被变更记录包括被删除及被变更记录)，占，占，占，占2%2%2%2%左右左右左右左右 20100906201009062010090620100906和和和和20100907201009072010090720100907未发生变更部分，占总体的未发生变更部分，占总体的未发生变更部分，占总体的未发生变更部分，占总体的95%95%95%95%以上，正是这部分的重复存储过多的消耗了存储成本以上，正是这部分的重复存储过多的消耗了存储成本以上，正是这部分的重复存储过多的消耗了存储成本以上，正是这部分的重复存储过多的消耗了存储成本20100907201009072010090720100907新增记录新增记录新增记录新增记录(包括纯新增及变更后记录包括纯新增及变更后记录包括纯新增及变更后记录包括纯新增及变更后记录)，占占，占，占3%3%3%3%左右左右左右左右 2010090620100907如何设计方案达到以下效果如何设计方案达到以下效果?减少/去除冗余数据，降低存储成本保证快照数据的快速访问对业务应用透明或降低应用改造成本参考方案参考方案增量数据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操作pInsert通常对应一条全新的记录，意味着记录的新生pDelete通常是原有的记录被删除，意味着记录的死亡pUpdate是在原有的记录上修改某些字段，一条Update操作可以拆分为Delete/Insert原子对操作，即从记录的维度来看，相当于前一条记录死亡，后一条记录新生因此，我们可以认为，任何一条记录(行数据)必定在历史上某天新生(start)，并在其后的某一天死亡(end)，而这个start-end对就定义为该记录的生命周期。活跃数据和死亡数据n活跃数据一条记录，在其产生之后直至当天仍旧存活(未被Delete/Update)，那么我们认为它是一条活跃数据对于活跃数据，其产生(start)日期已经明确，但死亡(end)日期并不确定数据标签:start-INFINITY(无穷大),如20110401-INFn死亡数据一条记录，在当天以前就被更改(被Delete/Update)，那么我们认为它是一条死亡了的数据对于死亡数据，其产生(start)和死亡(end)日期都已经明确数据标签:start-end如20110401-200110423INF目录存放在某一天新增并且一直未曾被删除或修改的记录(即活跃数据)此处省略一万字0901-09020901-09030901-09040901-09.0901-09300901-INF0902-09030902-09040902-09.0902-09300902-INF0903-09040903-09.0903-09300903-INF09n-09(n+1)09n-093009n-INF0929-09300929-INF0930-INF极极限限存存储储极限存储原理三个结论:任意一条记录，由于其生命周期确定，必定对应唯一的一个数据标签一个数据标签对应符合该生命周期的记录集合(该记录集合有为空的可能性)历史上出现的所有记录，必然可以成功的划分到不同的生命周期数据标签里去历史快照原理TimeLine 04130414 04150416 INF INF0414 INF0201 0413 03130314 INF 03130314 04150416 INF 04130414 04160417 INF 04130414 04170418 INF0414 INF0201 0413 03130314 04140415 INF 03100311 04210422 INF所有被蓝色线条经过的数据标签，其数据内容组合起来即为0414这天的数据全量快照同理，历史上任意一天的数据快照均可以该方式获得历史区间快照原理TimeLine 04130414 04150416 INF INF0414 INF0201 0413 03130314 INF 03130314 04150416 INF 04130414 04160417 INF 04130414 04170418 INF0414 INF0201 0413 03130314 04140415 INF 03100311 04210422 INF所有在两条蓝色线条以内以及穿过任意一条蓝色线条的数据标签，其数据内容组合起来即为0314-0415的数据全量快照方案主体逻辑包含以下主要步骤：1.通过主键关联对比昨天全量和今天全量的数据差异，并将这些数据区分为活跃(Lived)或过期(Expired)数据。2.对于对比的结果数据进行统计，获得每个生命周期下实际的数据条数，统计结果用来产生不同生命周期的记录到文件目录的映射。3.使用mapreduce数据对第1步结果进行分发，相同生命周期的数据会被写入到对应的唯一的生命周期目录下(依赖2的统计结果)。4.使用hive的双重分区映射生命周期目录，这样用户可以通过灵活的hive分区过滤来获得期望的数据。5.数据验证，为了保证应用极限存储后结果的正确性，因此增加了数据条数对比的验证规则。方案主体逻辑记录生命周期标签云记录生命周期标签云0401-04020401-04030401-04040402-04030402-04042010年4月23日全量2010年4月22日全量(极限存储)20100401-2010042320100402-2010042320100408-2010042320100422-2010042320100423-INF20100409-20100423数据分拣Hive介绍全文对比数据统计数据分拣分区映射数据验证遇到的问题u 产生的目录/文件数非常多产生目录数及文件数按日呈级数增长一个月产生465个目录,一年产生66795个目录文件数=目录数*reduce数(如1000)对NameNode压力非常大对应分区非常多，Hive元数据库压力也很大u文件大小不均匀u如何快速访问任意一天/一段时期的快照数据u分拣中运行出错会导致数据损坏或丢失u不同月份数据并行运行丢失数据问题u单个数据标签内数据损坏/丢失导致一段时期内快照不准u其他的一些保护机制应用效果迄今为止已有30余种业务数据完成应用，累积节省存储达15PB。极限存储使用方法uHive:取某天快照:select*from tb_users_exst where pt_start20100410取某天快照(UDF方式):select*from tb_users_exst where exst_pt(pt_start,pt_end,20100410)取一段时间快照:select*from tb_users_exst where pt_start20100410uHadoop:在调用setInputDir之前通过提供的方法获得生命周期目录列表，如下:List dateLists=DateListGenerator.generateExStoreListDirs(/group/taobao/taobao/hive/tb_users_exst,20100410);极限存储应用场景u查看一件商品2011年的变更历史:不使用极限存储:select*from tb_auctions where pt=20110101 and pt=20110731扫描数据量扫描数据量:450G*730=92TB使用极限存储:select*from tb_auctions_exst wherept_start20110731扫描数据量扫描数据量:450G*7*2膨胀率膨胀率=6TB(当前实现当前实现)450G*2膨胀率膨胀率=900G(理想情况理想情况)u获取某天增量(delta)数据:select*from tb_auctions where pt_start=20110105注:月头不适用，1号增量需要额外计算极限存储方案优化性能优化性能优化:支持从极限存储全量&当天增量产生极限存储数据计算时间从2个小时下降至1个小时计算成本下降了50%优化调整运行参数:set io.sort.spill.percent=0.80;set io.sort.mb=512;set io.sort.factor=32;set io.sort.record.percent=0.04;set mapred.reduce.parallel.copies=8;set mapred.job.shuffle.input.buffer.percent=0.70;易用性优化易用性优化:Hive层增加hook，实现SQL自动替换，对用户及上层业务透明。如:select*from tb_users where pt=20100410经过Hook层语意解析转换后变为:select*from tb_users_exst where pt_start20100410思考环节源表主键不唯一会出现什么情况?如何快速处理?与参考方案相比，优点在哪里？联系方式:微博:http:/ 淘图海 邮箱:Hive相关介绍什么是Hive?Hive 是建立在 Hadoop 上的、提供了类SQL界面的数据仓库基础构架。Hive分区表一个Hive表可以拥有一级或多级分区(组合分区)，每个分区对应一个目录，该目录下所有文件的数据合集为该Hive表的分区数据。Hive分区表中的分区字段为伪列，不实际占用任何存储空间，仅通过分区名进行保存判断分区时可以通过、=20110401 and pt=20110430获取4月份的所有分区Hive相关介绍Hive数据在云梯(Hadoop)上的存放形式 每个目录下有若干个数据文件，通常文件中每行数据对应Hive表的一条记录，列之前通过给定的分割符进行分割。数据文件可以是压缩的，也可以是非压缩的，只要和Hive元数据中保存的分区信息一致即可。pt=20100906/group/taobao/taobao/hive/$table/pt=20100906pt=20100907/group/taobao/taobao/hive/$table/pt=20100907pt=201009./group/taobao/taobao/hive/$table/pt=201009.$table返回全文对比通过Hive实现对相邻两天的数据全量对比，区分活跃与死亡数据，并同时获得其生命周期信息:FROM (SELECT*FROM tb_users_exst WHERE pt_start=pt_start AND pt_end 20100422 )oFULL OUTER JOIN (SELECT*FROM tb_users WHERE pt=20100423000000)nON o.id=n.idINSERT OVERWRITE TABLE t_ext_20100423_tb_users PARTITION(pt=EXPIRED)SELECT o.pt_start,20100423 WHERE n.id IS NULL OR(n.id o.id)OR(n.nick o.nick)INSERT OVERWRITE TABLE t_ext_20100423_tb_users PARTITION(pt=LIVE)SELECT if(o.id IS NULL OR(n.nick o.nick),20100423,o.pt_start)as birth_date,NULL as expired_dateWHERE n.id IS NOT NULLt_ext_20100423_tb_users比tb_users多了两个字段:birth_date:记录的产生日期，不可能为NULLexpired_date:记录的消亡日期，如果未死则为NULL返回数据统计通过Hive统计落在各个生命周期区间内的数据条数:INSERT OVERWRITE TABLE t_exs_tb_usersPARTITION(pt=20100423000000)SELECT birth_date,expired_date,count(1)FROM t_ext_20100423_tb_usersGROUP BY birth_date,expired_date注:这里的统计信息主要用来为下一步mapreduce作业提供参考，比如计算最终合理的文件数。返回数据分拣经过前面的处理，t_ext_20100423_tb_users两个分区(LIVED,EXPIRED)下的数据其最后两列分别为birth_date和expired_date,即对应数据记录的产生和死亡日期，因此mapreduce可以根据这个信息得知该目录应该存放至那个生命周期目录下。生命周期目录下云梯1上表现为如下形式:s_bmw_usres_exst-201004#每月数据存放在月份目录下|-201004#该目录下存放本月新增且至今未死亡的数据|-20100401#0401产生且未死亡|-20100402|-20100423#0423产生且未死亡|-20100401-20100402#0401产生且0402死亡(被删除或更新)|-20100401-201004030401产生且0403死亡(被删除或更新)|-20100401-20100404|-20100421-20100423 -20100422-20100423对于以下两条t_ext_20100423_tb_users表的记录，mapreduce会分别将其分发到/201004/20100403和/201004/20100403-20100405目录下。Record1 20100403 NULLRecord2 20100403 20100405返回分区映射极限存储目标表必定存在以下两个分区:Pt_start:起始日期，一定是一个合法8位日期Pt_end:死亡日期，对于活跃数据其值为$month_INFINITY仍然以上页的说明为例，说明分区的映射方式:s_bmw_usres_exst-201004|-201004|-20100401#pt_start=20100401,pt_end=201004_INFINITY|-20100402#pt_start=20100402,pt_end=201004_INFINITY|-20100423#pt_start=20100423,pt_end=201004_INFINITY|-20100401-20100402#pt_start=20100401,pt_end=20100402|-20100401-20100403#pt_start=20100401,pt_end=20100402|-20100401-20100404|-20100421-20100423 -20100422-20100423#pt_start=20100422,pt_end=20100423返回数据验证条数验证:SELECT count(1)FROM tb_users_exst WHERE pt_start 20100423;SELECT count(1)FROM tb_users WHERE pt=20100423000000;内容验证:类似于方案第一步中的数据全文对比，对每条记录中的每个字段进行一致性比较，从而最终确保数据内容正确无误返回