background

从论文看来, 用分布式文件系统 tectonic 取代了 blob/f4、data warehouse 的存储实现, 类似 azure 的底层文件系统的实现, blob/f4、data warehouse 作为上层 tenants, 直接和存储交互 (类似头条的 byteStore).

每个 tenant 是一个 namespace, 但是资源隔离是 tenant 级别的(后续看).

design

传统的 mds + data node + background service 组成, data node 写入时传统的 append 模式, mds 独立进程部署.

mds

data model:

分层存储 Name layer(“dir->list of subdir/name”)、File Layer(“file id->list of block id”)、Block Layer(“block->list of disk”&“disk->list of block”). 分层的模型在存储上分层存储, 降低热点, 提高可用性&容量扩展性

storage model(逻辑分层+物理分层):

自研了 ZippyDB(分布式线性kv存储): paxos+rocksdb, 数据管理是 shard 级别的, 这样, 一个 mds node 可能多个 shard. 常规的负载迁移等.

对于 d1 目录下文件 foo、bar, 会存储为 (d1, foo) 和 (d1, bar) 两个key. 遍历目录下的文件通过 scan 实现(用过的同学都懂的)

data model 的分层逻辑在存储上 经过 hash 负载到 node 上存储, 避免了 range 局部性热点的问题(比如读取目录下的文件)

一致性上 不支持跨分片的事务

小优化: 计算引擎经常需要遍历 目录下的文件读取, mds将 文件名+id 同时下发给 计算引擎 避免 mds 高负载

实践下来, 2/3 的metadata 操作是 block layer.

个人疑惑的地方: chunk 的逻辑关系在 metadata 上并没有清晰的表现出来, 但是 block 是逻辑表示, 确实 chunk构成的, 感觉 md 上缺少了部分的表述

chunk store/data node

持久化

tectonic 的 chunkstore 本质上就是一个对象存储, chunk 构成了上层的 logic block语义.

tectonic 提供了 block 级别的持久化语义, 空间存储、容量、性能都是 block 级别的, 目前支持 多副本/RS编码 的方式, RS 根据对象的持久性分层 RS(9,6) encoded(长期存储的对象)、RS(3,3)(短期存活的对象); rs 编码的写入15个有14个成功就返回了，剩下的失败的1个 会离线修复; 对于blob的副本模式, 采用 “partial block quorum appends”, 2/3 的quorum 写入就算成功. 根据 blob hot->warm/cold 的 age 属性, 采用 Reencoding优化方案: 将复制的blob 在 sealed(不会再写入) 之后 转变成 rs 编码.

论文中提到了 节点坏盘/高负载 导致 reconstruction read 形成 reconstruction storm 的问题, 为此采用优化 striped rs encoding(约束到10%, 避免成本过高)

存储实现上, 本地文件读写用 xfs, 比较有意思的是, 每个 storage node 都有 36 hdd+1Tb ssd( xfs md + 缓存 hot chunk).

placement

常规的copyset方案, 会根据情况保持 fixed copyset count.

论文提到 with only 5% of storage nodes unavailable, 80% of the block groups became unavailable for writes? 的这个问题 不是很理解.

IO Path

IO路径上, block 只允许创建者 进行 append, 避免多点写入的问题; 对于data awrehouse, 允许一个文件并发写入(个人认为还是chunk粒度的并发).

full-block 写入会先请求 资源分配, 在进行写入

sla

每个tenant本质上是上层抽象的存储逻辑业务, 每个租户对外提供服务给 各个app, 因为一个集群可能存放多个tenant, 那么 tenant 之前的资源问题就显得很重要.

论文中根据资源类型抽象了 持久化的资源(存储容量, 变化很慢, 不是隔离的重点) 和 非持久化的资源, 设计了 TrafficGroups, 每个 TrafficGrous 都有对应的 TrafficClasses: Gold, Silver, and Bronze, 分别对应于 latency-sensitive, normal, and background applications. tenant 内部, 空闲的资源(比如 disk time)根据 TrafficClass 进行调度.

本地资源采用 weighted round-robin (WRR) scheduler 避免quota用光过度使用资源的情况. 为了更好的处理高优请求, 使用了三种IO调度策略:

  • 使用了 贪婪的优先级算法，只要低优请求在 高优请求插队后 仍然爱有时间完成 那么鼓励插队. 限制低优请求量
  • 限制低优算法, 优先服务高优
  • IO重调度算法: 将disk阻塞超过阈值的 gold 请求 放到 non-gold 前面

客户端侧, 采用 分布式 counter 的限流 来保证 资源共享

background service

常规的设计比如 metadata gc、chunk rebalancer(copyset优化)&repair(clean deleted chunk)

tenant view

security: 分层的 token 鉴权和分发 data integration: 进程边界 checksum 保证, 不仅仅是 client 和 storage node 的边界 不支持 geo复制, 上层tenants(比如 blob/warehouse) 实现 远程数据获取走 代理

设计比如 Each tenant in a cluster typically owns one namespace.还是比较常规的. du 容易过时, 总的而言, 和现在的 dfs(头条的byteStore) 设计差异不大

论文中着重强调了 将 warehouse 和 blob 混部后 提高了 的资源利用率 并更好的隔离资源的效果, 也是不错的方向.

future 上来讲, 因为性能 kv 服务还没有迁移过来, 还是有很多work的

个人感受

虽然整体架构比较常规, 但是还是有很多可以借鉴的地方: mds 的 逻辑+物理分层设计 极大的避免了 热点问题. 各种IO调度策略优化 提高 SLA, reencode 统一了 blob hot/warm 模型(摒弃了 hystack/f4 两套系统).

参考