王尘宇

如何在保障跨IDC容灾能力的前提下，还能降低50%存储成本？

快手经历了10年的高速发展，存储了大量的视频数据，存储成本非常高，需要对对象数据进行治理，在保障跨IDC容灾的前提下，降低50%存储成本。本文主要从三个层面，介绍整个项目的设计与落地过程：快手对象存储架构；快手对象存储跨IDC EC架构设计阶段；快手对象存储跨IDC EC架构落地阶段。

一、快手广告推广对象存储架构

如图所示，整个架构的核心思想是：通过HBase存放对象索引，多个对象数据合并后，以大文件的形式存放在HDFS上，同时使用MemoryCache作为缓存层，缓存热点对象数据，避免直接对底层存储的冲击。除此之外，整个架构是通过双AZ四副本的形式，实现跨AZ容灾；读取时，通过AZ亲和性策略，优先选择本AZ集群进行数据读取，Miss或者失败后，再回落到远端AZ集群读取。快手经历了10年高速发展，目前已经拥有几EB存量数据，几PB日增量数据，对象存储的成本非常高，需要对对象存储进行数据治理，在保障跨IDC容灾的能力下，降低50%存储成本。接下来的篇幅，重点介绍下，为了实现这个目标，我们都做了哪些事情。

二、快手广告投放整体方案选择

降低存储成本的方法有很多，综合考虑后，以下三大类方法比较match场景：删除无用对象数据；降低对象数据副本冗余度；采用低成本存储介质存放对象数据。由于目前整个架构是通过双AZ四副本实现的跨AZ容灾，所以准备采用数据EC处理，来降低对象数据副本冗余度。也就是，我们准备采用数据EC技术和归档存储的方式，在Hot存储层的基础上，引入低成本存储层，进一步完善整个对象存储架构。通过数据“热 -> 温 -> 冷”的逐级流转，实现降低对象存储成本的效果。

经过对数据的热度分析后，发现：数据冷热周期分明；历史数据存在被随机访问的场景；历史数据访问时延有一定要求。所以我们决定第一阶段的主要工作，集中在：实现一套功能完备的EC Warm低成本存储层。通过数据“热 -> 温”的自动流转，实现保持跨AZ/IDC容灾的前提下降低50%存储成本的大目标。

三、快手对象存储 跨IDC EC架构设计阶段

先来看下，在架构设计阶段，我们需要做哪些抉择。

1.EC算法选择

在算法选择时，由于是对象存储，对数据重构代价要求比较高；同时又需要具备跨AZ/IDC容灾能力，对容灾能力要求也比较高。综合考虑后，我们决定采用LRC算法，作为整个EC Warm架构的主算法。但是LRC算法的参数应该如何设置呢？

2.LRC算法参数确定

LRC算法的容灾能力和RS算法一样，所以我们主要通过RS(n + m)来推到下LRC算法的具体参数：假设：最少有 X 个IDC实现容灾；每个IDC内均匀散列Block。要求：任何一个IDC故障，数据都可修复；RS数据重构成本尽可能低；任意一个IDC故障后，还可以容忍其余IDC各自坏掉一个Block；副本冗余度 <= 200%。中间推导：每个IDC内存放 (n + m)/x 个Block；每个IDC最多存放m个Block。

经过推导后，我们发现，下面两种算法，比较满足场景要求。LRC(6 + 3 + 3)；LRC(6 + 2 + 4)。通过局部修复数据压测，以及结合目前IDC个数现状，所以，我们准备采用LRC(6 + 3 + 3)算法，即：6个source block，产生3个全局校验(Global Parity)块和3个局部校验块(Local Parity)，支持跨IDC容灾，且能降低50%副本冗余度。

3.EC块布局方式选择

数据EC块布局方式选择，直接影响整个项目落地的风险和难度，所以也是至关重要的。结合现状：温数据 + HDFS大文件 + IOPS要求偏高 + CDH HDFS版本，所以我们决定采用连续块布局方式。也就是整个的EC Warm架构，采用LRC(6 + 3 + 3)算法，在稳定的HDFS内核版本基础之上，封装一层功能完备的数据EC和数据重构流程，在实现大目标的同时，尽可能的降低风险。

4.EC Warm架构层面跨IDC容灾能力

通过上面EC算法和块布局方式的抉择后，我们只需要将ZK、Journal、DN、Active NN、Standby NN散列在不同的IDC内，就可以实现EC Warm架构层面的跨IDC容灾能力，在某个IDC故障后，整个架构可以自愈。除此之外，整个架构：通过Router + ObserverNN组合，提升架构主节点读吞吐功能。

四、快手对象存储 跨IDC EC架构落地阶段

确定大方向后，我们再来看下，为了实现一套功能完备的EC Warm低成本存储层，我们还需要解决哪些问题。

1.数据EC流程

首先我们需要一套智能的数据“热 -> 温”转换流程，如图所示，在整个流程中，有几点相对比较重要：将LRC算法调度到文件所在Hot集群上，可以避免读取Source时产生跨IDC流量；添加统一跨IDC流量控制模块，严格控制数据转换流程中对跨IDC带宽的影响；LRC算法同时输出Source和Parity，严格保障一个Stripe 12个Block的块放置策略；Global Parity 和 Local Parity按照固定次序，存放在同一个Parity文件中，并且通过文件前缀与Source文件进行匹配，简化索引信息。同时，我们调整了一个Stripe 12个Block的布局方式，为了在满足跨IDC容灾的前提下，尽可能均衡IDC间的流量，如图所示：

2.数据Fixer流程

其次，我们还需要一套智能的数据重构流程，重点介绍下LRC算法的重构实现。LRC(6 + 3 + 3)算法在进行数据重构时，按照先局部、再全局、再局部的思想，将12个块分成7层。优先使用局部修复；局部无法修复时，再进行全局修复；当全局修复完成后，再进行一轮局部修复。为了最小化LRC数据重构成本，Stripe数据重构时，最好能在第一轮局部修复就完成。所以，期望在IDC内，任何一层设备出现故障时，只出现一个块丢失，从而保障局部可修复。

3.数据块放置策略

一个Stripe 12个Block除了跨IDC散列之外，IDC内部四个Block也要散列到不同的Domain、Tor、Rack、DN、Disk上，从而实现IDC内任何一层设备出现故障时，只出现一个MissingBlock，都可局部修复。为了严格保障这样的块放置策略，需要完成以下几个功能：NN需要支持逻辑UpgradeDomain概念，从而加速Decommission和Balance速度；NN需要支持LRC BlockPlacement Policy，将12个块按照四个为一组分成4组。分配DN时，组间跨IDC、组内散列在不同的Domain；数据EC时，一次性向NN申请一个Stripe 的 Block，然后按照对应关系，将EC后数据，写到对应的DN上；数据Fixer时，按照当前DN的情况，向NN申请满足放置条件的DN，将Fixer后的数据，写到对应的DN上。通过每个数据变更环节，强保障Stripe块的放置策略，从而可以最小化Stripe 数据重构代价。

4.数据正确性保障

接下来，我们再来看一个问题：如何保障转换前后，数据正确性问题？在数据转换过程中，可能存在诸如：磁盘故障、内存故障、网络异常、程序BUG、未知异常等各种异常，导致数据转换后，数据异常。所以保障数据转换前后正确性，是至关重要的。

为了保障数据正确性，我们做了以下几件事情。数据EC阶段：LRC算法EC时，将产出的中间临时数据，并发的写到HDFS上；LRC算法完成后，通过HDFS Concat操作，将HDFS 临时文件合并成最终的Source文件和Parity文件；按照Block粒度，计算Source文件和Parity文件的对应Block的CRC，并记录到HBase中，供Fixer数据重构时使用。为了保障数据EC后，HBase内Block对应CRC的正确性，尤其是Parity Block CRC的正确性，在EC完成后，又添加了完备的Checker流程，通过模拟局部修复、全局修复流程，强保障Local Parity和Global Parity的正确性，从而保障HBase内Block对应CRC的正确性。数据Fixer阶段：LRC算法进行数据重构时，中间临时数据直接写到HDFS上；通过类Transfer的流程，将HDFS中文件数据，端到端的写到对应DN；Transfer最后阶段，完成CRC校验后，再Finalize Block。通过以上各阶段的工作，从而保障变更前后，数据的正确性。

5.索引一致性

由于EC Warn集群中，Parity文件和Source文件，通过文件前缀的方式进行索引匹配的，所以就有可能存在两个文件信息一致性问题，比如：高级用户误删除Parity文件、用户仅改变Source文件属性等。为了解决Parity文件和Source文件索引一致性问题，我们做了以下几件事情：回收Parity文件的目录权限为admin权限；NN端捆绑Source文件和Parity文件操作，比如：rename、delete、settime等；Source文件append时，自动提升Source副本数，并删除对应Parity文件；除了上面各个阶段保障：数据高容错性、数据变更前后正确性、索引一致性等，还需要一个兜底服务，定期的扫描全量EC文件，确保各个状态的正确性，以便能够及时发现、并解决任何导致数据丢失的隐患，严格保障数据的可靠性。

五、快手信息流推广业务IO流程变化

最后，整个对象存储架构，引入了EC Warm低成本存储层，通过数据“热 -> 温”动态流转，实现保持跨AZ/IDC 容灾的前提下，降低50%存储成本的效果。在取得明显受益后，我们再从业务的视角看下，整个架构的变更，对业务侧的影响：数据“热 -> 温”转换后，更新HBase中文件的索引信息，对业务透明；业务读取时，自动从warm集群读取数据；读取Warm集群数据时，如果出现数据丢失异常，不仅会实时同步修复，还会异步周知数据重构服务，进行异步修复。

六、结尾

目前整个架构已经上线大半年时间，取得几百PB数据空间节省的收益，同时，未出现任何数据可靠性问题。当然，整个架构还需要承载更多的数据，还需要进一步扩大，现在不代表未来，我们团队会不忘初心，怀着敬畏之心，继续匠心前行。

---