数据蒋堂 | 数据分段讨论

来源:数据蒋堂

作者:蒋步星

本文共1600字,建议阅读5分钟。
本文和大家讨论了关于数据库怎么高效的将数据分段。




现代计算机一般都有多CPU核,而日益广泛应用的固态硬盘也有较强地并发能力,这些硬件资源都为并行计算提供了有力的保证。不过,要实现并行计算还需要有较好的数据分段技术,也就是能方便地把待计算的数据拆分成若干部分,让每个线程(或进程,这里以多线程为例讨论,多进程情况是类似的)分别处理。

设计数据分段方案时,有这么几个目标:

1. 每段的数据量基本相同

并行任务的最终耗时是以那个最慢的线程为准的,而同一机器中各线程的处理能力基本相当,因此数据分段要能做到尽量平均,使各线程的计算时间基本相同。

2. 分段数可灵活动态指定

在数据准备阶段经常并不清楚实际计算用机器的CPU数,而且即使知道,线程数也不能简单地按机器CPU核数去算,因为硬盘的并发能力常常小于CPU;并且,在有并发计算时,能有多少CPU核用到本计算任务也不能事先预知。实际计算用的线程数最好是根据当时场景动态决定,范围从几个到几十个都有可能,这要求能够按随意的数量将数据分段。

3. 每个分段是连续紧凑存储的

因为硬盘不适合频繁随机访问(即使固态硬盘也不适合频繁小量的随机访问),为了保证遍历性能,我们希望每个线程要处理的数据在硬盘上要尽量连续存储,而不是频繁跳跃。

4. 允许数据追加

数据并不是固定不变的,会随着时间不断增长,我们当然希望每次追加数据时不必重新整理所有数据,只需要把追加的数据补上即可。

使用文本文件存储数据时,可以同时保证这4个目标。只要简单地按总字节数把文件分成多段,每个线程读取其中一段即可。

文本中用回车作为记录(行)的分隔符,文本记录的数据本身中不可能出现回车字符,所以用它用为记录的分隔符不会产生歧义。按文件字节数分段时,分段点可能会落到某一行的中间,这时使用去头补尾的方法进行调整,即就是每个分段从分段点继续读到一个回车符才开始,而越过下一个分段点继续读到一个回车符时才结束,这样就可以保证每个分段都只包含完整的记录(行),这也是HADOOP常用的方法。

但是,文本本身的解析实在太慢了,我们还是要考虑二进制的存储方案。

二进制数据中没有回车这种可用于分隔记录的字符,任何字节数值都可能是数据本身,这时就无法识别出记录何时结束。如果一定要人为制造一个分隔符,那就要足够长才能避免和数据本身重复的可能性,每条记录上都增加这么一段字节,会增加大量无意义的数据量、降低性能;而且,这也只能降低出错率而不能彻底杜绝。

改进的方法是使用区块,把数据存入若干相同大小的区块,分段时以区块为单位,只要总区块数量足够多,每个线程分配到的区块数量也就相对比较平均,也就能满足目标1和目标2了。不过目标3却有些问题,区块大小是存储数据之前就确定的,不大可能正好和记录长度匹配,如果要求每个区块中都存储完整的记录,就可能造成区块中的空间浪费(剩余空间存不下一条完整记录时只能作废)。在区块较小且记录字段较多时这个浪费会很严重,影响目标3希望的紧凑性。如果允许一条记录被拆分到两个区块,那又不能按区块为单位来分段了,否则可能造成某个分段将只处理半条记录的情况。

这时候可以借鉴文本的去头补尾方案,允许同一记录拆分到两个区块,在读取分段的第一个区块时跳过第一条(可能是半条)记录,而读取最后一个区块时再继续读下一个区块把当前区块中最后的记录读完整,这样可以保证数据的紧凑性了。这种方法要求在区块中有个标记表明本区块中第一条记录是否是上一区块记录的延续以及最后一条记录是否完整,空间成本不算高,但在遍历数据时总要被这些标记打断,处理起来麻烦不少,会影响性能。

数据库一般也使用区块方案,但由于数据库将所有表的数据存储在一起,它的区块分配算法不会去保证同表数据所占用的区块之间的连续性。而为提高数据的连续性,就要让区块更大,这和区块多又有点矛盾。如果再考虑到数据的可追加性,则还需要一个不断变大的索引表来管理这些区块,在区块数量很多时,这个索引表本身的连续性也不容易得到保证(它的长度事先不知道,在数据追加过程中动态增长)。

专栏作者简介

润乾软件创始人、首席科学家


清华大学计算机硕士,著有《非线性报表模型原理》等,1989年,中国首个国际奥林匹克数学竞赛团体冠军成员,个人金牌;2000年,创立润乾公司;2004年,首次在润乾报表中提出非线性报表模型,完美解决了中国式复杂报表制表难题,目前该模型已经成为报表行业的标准;2014年,经过7年开发,润乾软件发布不依赖关系代数模型的计算引擎——集算器,有效地提高了复杂结构化大数据计算的开发和运算效率;2015年,润乾软件被福布斯中文网站评为“2015福布斯中国非上市潜力企业100强”;2016年,荣获中国电子信息产业发展研究院评选的“2016年中国软件和信息服务业十大领军人物”;2017年, 自主创新研发新一代的数据仓库、云数据库等产品即将面世。


数据蒋堂

《数据蒋堂》的作者蒋步星,从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞,虚拟与现实的相互交织,产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点,站在研发人员的角度从浅入深,进行全方位、360度无死角深度剖析;对于一些业内观点,站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展,站在业内专家角度给予预测和推断。静下心来认真研读你会发现,《数据蒋堂》的文章,有的会让用户避免重复前人走过的弯路,有的会让攻城狮面对扎心的难题茅塞顿开,有的会为初入行业的读者提供一把开启数据世界的钥匙,有的甚至会让业内专家大跌眼镜,产生思想交锋。


往期回顾:

数据蒋堂 | JOIN延伸 - 维度其它应用

数据蒋堂 | JOIN延伸 - 维度查询语法

数据蒋堂 | JOIN延伸 - 维度概念

数据蒋堂 | JOIN提速 - 有序归并

数据蒋堂 | JOIN提速 - 外键指针的衍生

数据蒋堂 | JOIN提速 - 外键指针化

数据蒋堂 | JOIN简化 - 意义总结

数据蒋堂 | JOIN简化-消除关联

数据蒋堂 | JOIN简化 - 维度对齐

数据蒋堂 | JOIN运算剖析

数据蒋堂 | 迭代聚合语法

数据蒋堂 | 非常规聚合

数据蒋堂 | 再谈有序分组

数据蒋堂 | 有序分组

数据蒋堂 | 非等值分组

数据蒋堂 | 还原分组运算的本意

数据蒋堂 | 有序遍历语法

数据蒋堂 | 常规遍历语法

数据蒋堂 | 从SQL语法看离散性

数据蒋堂 | 从SQL语法看集合化

数据蒋堂 | SQL用作大数据计算语法好吗?

数据蒋堂 | SQL的困难源于关系代数

数据蒋堂 | SQL像英语是个善意的错误

数据蒋堂 | 开放的计算能力为数据库瘦身

数据蒋堂 | 计算封闭性导致臃肿的数据库

数据蒋堂 | 怎样看待存储过程的移植困难

数据蒋堂 | 存储过程的利之弊

数据蒋堂 | 不要对自助BI期望过高

数据蒋堂 | 报表的数据计算层

数据蒋堂 | 报表应用的三层结构

数据蒋堂 | 列式存储的另一面

数据蒋堂 | 硬盘的性能特征

数据蒋堂 | 我们需要怎样的OLAP?

数据蒋堂 | 1T数据到底有多大?

数据蒋堂 | 索引的本质是排序

数据蒋堂 | 功夫都在报表外--漫谈报表性能优化

数据蒋堂 | 非结构化数据分析是忽悠?

数据蒋堂 | 多维分析的后台性能优化手段


校对:林亦霖

为保证发文质量、树立口碑,数据派现设立“错别字基金”,鼓励读者积极纠错

若您在阅读文章过程中发现任何错误,请在文末留言,或到后台反馈,经小编确认后,数据派将向检举读者发8.8元红包

同一位读者指出同一篇文章多处错误,奖金不变。不同读者指出同一处错误,奖励第一位读者。

感谢一直以来您的关注和支持,希望您能够监督数据派产出更加高质的内容。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值