A feasibility analysis and estimation to store and serve Telecom CDR in Bigtable/HBase.

1. making data alive!
Bigtable数据模型
解决CDR清单存储问题的资源估算
Schubert Zhang
2010年8月24日

2. 2
目标
• 通过合理的应用数据schema设计，甚至
• 对某些代码实现部分的灵活调整
---- 评估和验证Bigtable数据模型管理超大规模数据集的可能性。
• 应当明了
– Bigtable不是一个具体的产品，而是一个技术方向或Design Pattern；
– 其实现可以是灵活多样的，不断根据不同业务需求灵活调整和发展；
– 我们以前的某些理解而得出的结论是不完全正确的；
– 重读Bigtable Paper，我们会发现其很重要的特点是Flexibility，其最终形成
的数据模型和实现原则是在各种折中的考虑下做出的；
• 而Dynamo和Cassandra等其他设计模型只解决了特定的问题，适用场合有限。
– Bigtable是我们研究和使用过多种设计和实现后，目前认为最好的模型。

3. 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。

4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16
Thanks
Bigdata Storage
We can store Bigdata.
Bigdata Query
We can query what you want from Bigdata.
Bigdata Mining
We can mine what the data speak from Bigdata.