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

1,466 views
1,360 views

Published on

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

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,466
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

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

×