Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

1,600 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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.

×