making data alive!

Bigtable数据模型解决CDR清单存储问题的资源估算

Schubert Zhang

2010年8月24日

2

目标

• 通过合理的应用数据schema设计，甚至

• 对某些代码实现部分的灵活调整

---- 评估和验证Bigtable数据模型管理超大规模数据集的可能性。

• 应当明了

– Bigtable不是一个具体的产品，而是一个技术方向或Design Pattern；

– 其实现可以是灵活多样的，不断根据不同业务需求灵活调整和发展；

– 我们以前的某些理解而得出的结论是不完全正确的；

– 重读Bigtable Paper，我们会发现其很重要的特点是Flexibility，其最终形成的数据模型和实现原则是在各种折中的考虑下做出的；

• 而Dynamo和Cassandra等其他设计模型只解决了特定的问题，适用场合有限。

– Bigtable是我们研究和使用过多种设计和实现后，目前认为最好的模型。

3

某省移动CDR清单规模

• 用户规模

– 1亿用户

• 清单数据量

– 每条：按400B估算。

– 每月：清单量500亿条，数据20TB。

– 每周：清单量100亿条，数据4TB。(按平均每月5周算，包括非完整周)

– 每天：清单量17亿条，数据680GB。(每秒2万条)

– 总6个月：清单量3000亿条，数据120TB。

• 集群规模

– 规划20台DELL PowerEdge C2100

– 每台12*1TB数据硬盘

– 这样每个节点需管理120TB/20=6TB，压缩(3:1)后2TB，HDFS层存储3个复制，即每个节点磁盘空间需求也是6TB。

Data Patterns

• A short set of temporal data that tends to be volatile.

• An ever-growing set of data that rarely gets accessed.

4

5

Bigtable数据schema设计

• RowKey: 用户号码– RowKey数量不会无限增长

• Column Family: 时间段(月或周或日)，和Access Group一致。– 如果按月就有约6个– 如果按周就有约30个– 如果按日就有约180个

– 如何选择关系到系统资源需求和查询方法的折中。

• Column Qualifier: 空– 这里不需要

• Timestamp: CDR清单的实际Timestamp– 每个用户号码(RowKey)在某个时间段内

(CF)对应的所有CDR都按Timestamp排序。

• SSTable中的Key– (用户号码,时间段:空,Timestamp)– 估算长度约32B=(11+8+8+?)

• 数据schema的语义理解– 首先按照用户号码range进行水平

partition。 => 对应Tablet划分。– 其次按照时间段进行垂直partition。=> 对

应CF划分。– 一个用户号码在某时间段内，所有CDR清

单是连续按照Timestamp顺序存储的(并且是时间最新的在前)。

• 此模型的查询路径– 由用户号码查询Metadata定位到所在

Tablet及其所在节点；– 由时间段确定CF；– 在某Tablet的某CF内查询所有SSTable文件

本地索引；– 由SSTable本地索引定位到数据

Block(64KB)，顺序扫描查找该Block得到返回数据。

6

Tablets

• Tablet– 一个RowKey Range就是一个Tablet；– 每个Tablet内可以有多个CF；– 是个逻辑概念，其size threshold无法定义，因为可能有多个不同size的CF。

• Tablet-CF (size=1GB，压缩后)– 一个Tablet的一个CF，其size threshold可以定义。即我们理解的Tablet size threshold其实是

Tablet-CF size threshold 。– 选用较大的size可以减少Tablet数量，从而减少Memtable数量。– 选用较大的size可以减少Tablet split次数；– 选用较大的size可以减少Metadata数据量(Metadata定义RowKey Range的每个CF对应的Tablet及

其Location)。注：HBase目前不支持Metadata tablet的split。

– 为Tablet-CF定义size threshold，目的是作为最小数据管理单位，更好地Partitioning，Balancing, Compaction等，因此size threshold不应该是刚性的。

• 压缩– 压缩比3:1 (以一般的Gzip/LZO的平均情况)；– 6个月总数据120TB (压缩后40TB)，平均每节点6TB (压缩后2TB)。

• Memtable大小: 64MB– 每个Tablet-CF可以有1GB/64MB=16个新flush的SSTable(未Compact的情况下)；– Bigtable的具体实现(HBase/Hypertable)不一定总是等Memtable写满后才flush ，也可能当系统总

的Memtable内存达到全局配置上限(如HBase当每个节点所有的Memtable内存达到总heap的40%)时flush，但我们后面的估算总是以写满为准。

7

Tablet Splitting & Load-Balancing

• Tablet Splitting– 在数据量如此大的情况下，随着数据写入，每个Tablet的数据量不断增长，就需要split。– Tablet Split的触发条件是判断某个Tablet-CF的所有SSTable size是否达到配置的上限(如1GB)。一

个Tablet-CF触发的分裂，将分裂整个Tablet内的所有Tablet-CF。– Splitting引起下列两个问题

• split和重新assign过程中，读写操作暂停 (过程很短，如几秒)。

• split后，新旧tablet中都会有垃圾数据，必须靠compaction来清理 (compaction的开销比较大)。

– 设计和数据建模应减少频繁split。– 实现(如HBase)可以判断当一个节点的Tablet数量达到一定上限后就不再Split，这可以防止Tablet

过多。

• Load-Balancing– 空系统第一个时间段/CF的数据量达到一定程度，split出足够多的Tablet/(RowKey Range)后，系

统即趋于balance。因Tablet是以RowKey为边界的，即RowKey Range分配均衡。– 所以后续创建的其他CF也将均衡分布在所有节点上(因为RowKey Range已经分好了)。

• 这种建模特点的优点– 一旦第一个CF写完后，Tablet /(RowKey Range)的划分已经基本稳定。– 后续的CF，因为RowKey Range已经分好了，直接均衡分布了。– 因为Split是判断Tablet-CF的size的，因此后续的split也很少(在CDR数据量的分布比较稳定的情况

下，期望是很少几乎没有新的split)。– 唯一的risk是：如果CDR数据量分布频繁摇摆skew，则会导致系统中的tablet/range数越积越多。

• 这种情况应该很少出现

• 寻找解决方案？如模糊化split条件（认为比较靠谱）。

• Tablet支持合并？(在Bigtable Paper看到，但不知如何实现)

8

资源估算-Index

• 6个月总数据120TB，平均每节点6TB。

• Index所需内存

– 所有SSTable的Index都载入内存。

– Block的64KB是指压缩前。

– 以HBase/HFile为例，BlockSize=64KB，每节点Index数量为6TB/64KB=93,750,000，按100,000,000(一亿条)计算。

– HBase/HFile Hold Index的内存公式为: (56+AvgKeySize)*NumBlocks, AvgKeySize=32B，需内存: 9GB。

• 考虑其他开销，为Index留10GB内存。

• 考虑其他策略

– 将SSTable的Index修改成不完全load，而采用cache或每次需要时临时load，可以节省内存。比如节省一半的内存。

– 所起到的作用不很明显，只能节省10GB以下的内存。

9

资源估算-Memtable (CF: 月)

• 每月数据20TB，平均每节点1TB (压缩后334GB)。以下计算单节点……

• 第一个月/CF的数据1TB (压缩后334GB)，需334个1GB的Tablet (即将整个RowKey空间划分为334份)。

• 假设后续月份CDR数据仍然像第一个月一样均匀分布，Tablet数一直维持不变334 。

• 前5个月对应CF的数据不再更改，即每个节点上有5TB静态数据。Memtable内存可被释放。

• 当月对应CF不断写入新数据，即每个节点上有1TB (压缩后334GB)写活跃数据，需要占用Memtable内存。

• Memtable所需内存

– 334个Tablet维持不变。并且每个Tablet需两个Memtable。

– 只有最后一个月/CF活跃，64MB的Memtable，需内存(334*64MB*2)=43GB。

10

资源估算-Memtable (CF: 周)

• 每周数据4TB，平均每节点200GB(压缩后67GB)。以下计算单节点……

• 第一周/CF的数据200GB (压缩后67GB)，需67个1GB的Tablet (即将整个RowKey空间划分为67份)。

• 假设后续周CDR数据仍然像第一周一样均匀分布，Tablet数一直维持不变67 。

• 前29周对应CF的数据不再更改，即每个节点上有(6TB-200GB)静态数据。Memtable内存可被释放。

• 当前周对应CF不断写入新数据，即每个节点上有200GB (压缩后67GB)写活跃数据。需要占用Memtable内存。

• Memtable所需内存

– 67个Tablet维持不变。并且每个Tablet需两个Memtable。

– 只有最后一周/CF活跃，64MB的Memtable，需内存(67*64MB*2)=8.6GB 。

11

资源估算-Memtable (CF: 日)

• 每日数据680GB，平均每节点34GB (压缩后12GB) 。以下计算单节点……

• 第一日/CF的数据34GB (压缩后12GB)，需12个1GB的Tablet (即将整个RowKey空间划分为12份)。

• 假设后续日CDR数据仍然像第一日一样均匀分布，Tablet数一直维持不变12 。

• 前179天对应CF的数据不再更改，即每个节点上有(6TB-34GB)静态数据。Memtable内存可被释放。

• 当日对应CF不断写入新数据，即每个节点上有34GB (压缩后12GB)写活跃数据。需要占用Memtable内存。

• Memtable所需内存

– 12个Tablet维持不变。并且每个Tablet需两个Memtable。

– 只有最后一日/CF活跃，64MB的Memtable，需内存(12*64MB*2)=1.6GB 。

12

资源估算- Compaction

• Compaction

– Compaction在每个Tablet-CF范围内执行。

– 在不Compact的情况下，每个Tablet有1GB/64MB=16个SSTable (不是很多)。

– 实际上因为tablet是split繁殖的，compaction是必然的。

• 不同的Column Family策略下

– 月：每节点有1TB(压缩后334GB)活跃数据Compacting。

– 周：每节点有200GB(压缩后67GB)活跃数据Compacting。

– 日：每节点有34GB (压缩后12GB)活跃数据Compacting。

– Column Family时间段越小，Compaction占用资源越少。

13

资源估算-Summary

CF/时间段资源要素

月 周 日

活跃数据量(每节点/集群) 334GB/6680GB(1TB/20TB)

67GB/1340GB(200GB/4TB)

12GB/240GB(34GB/680GB)

活跃Tablet-CF数(每节点/集群) 334/6680 67/1340 12/240

总Tablet数(每节点/集群) 334/6680 67/1340 12/240

总Tablet-CF数(每节点/集群) 2004/40080 2010/40200 2160/43200

活跃Memtable内存需求 43GB 8.6GB 1.6GB

活跃Compacting数据量(每节点/集群) 334GB/6680GB(1TB/20TB)

67GB/1340GB(200GB/4TB)

12GB/240GB(34GB/680GB)

Index内存需求(每节点) 10GB 10GB 10GB

内存汇总(Index + Memtable) (每节点) 53GB 18.6GB 11.6GB

可能推荐的内存配置(考虑活跃数据的少量Overlap以及系

统其他开销)

64GB 32GB 32GB

14

结论

• Column Family: 日或周或月都是可行的– 内存配备是可以达到的。

• HBase或Hypertable的实现需保证下列假设成立– Memtable

• 一定时间(如1小时或1天)没有update的Memtable需Flush到硬盘。

• Flush后，原来的Memtable数据占用内存需回收。

– Tablet split的条件是Tablet-CF的SSTable size。

– 如果上述假设在实现中存在问题，需修改之。

• CDR清单数据数据需满足下列假设– CDR数据量分布对于用户号码相对时间段比较均匀(符合实情情况)。

– 否则修改Bigtable split为模糊分裂。

• 将SSTable的Index修改成不完全load，而采用cache或每次需要时临时load，可以节省内存。

• 在Tablet数量较多时，Memtable占用内存是主要部分，较少时Index所占内存是主要部分。

• 负载均衡可以得到保证。而且数据分布稳定后，split将会很少。

• 折中考虑前述的所有因素建模数据。

15

HBase中可以修改优化的部分

• Metadata Tablet目前还不支持Split，所以Tablet-CF的数量不能太多，否则会引起Metadata Tablet太大。但目前一个1GB的Metadata Tablet应该已经够用了。

– 例如一个Tablet-CF占用1KB，那么1GB的Metadata Tablet可以存储1,000,000个Tablet-CF，已经足够了。

• HBase的Memtable还不支持超时Flush。

– 例如2天没有修改就Flush。

– Work-around的方法是从客户端强制flush。

• Tablet Split判断条件模糊化，例如：

– 当只有当前CF内有数据时，只要当前Tablet-CF size大于设定门限就split；

– 而当其他CF中也有数据时，模糊化为：当前Tablet-CF size大于设定门限的1.5倍才split。

• 采用Cloudera的HBase+Hadoop可以保证CommitLog的安全。

16

Thanks

Bigdata StorageWe can store Bigdata.

Bigdata QueryWe can query what you want from Bigdata.

Bigdata MiningWe can mine what the data speak from Bigdata.