Weitere ähnliche Inhalte Ähnlich wie Bigtable数据模型解决CDR清单存储问题的资源估算 (20) Mehr von Schubert Zhang (17) Bigtable数据模型解决CDR清单存储问题的资源估算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.