大数据经典论文解读
徐文浩
bothub 创始人
13844 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 59 讲
大数据经典论文解读
15
15
1.0x
00:00/00:00
登录|注册

17 | 从Dremel到Parquet(二):他山之石的MPP数据库

你好,我是徐文浩。
在上节课里,我们看到了 Dremel 这个系统的数据存储是怎么回事儿的。不过,只是一个支持复杂嵌套结构的列存储,还没有发挥 Dremel 百分之百的威力。像 Hive 也在 2011 年推出了自己的列存储方案 RCFile,并在后续不断改进提出了 ORC File 的格式。
列存储可以让一般的 MapReduce 任务少扫描很多数据,让很多 MapReduce 任务执行的时间从十几分钟乃至几个小时,下降到了几分钟。更短的反馈时间,使得数据分析师去探索数据,根据拿到的数据反馈不断从不同的角度去尝试分析的效率大大提高了。
不过,人们总是容易得陇望蜀的。当原先需要花几天时间写 MapReduce 程序才能分析数据的时候,我们希望能够通过写 SQL 跑分析数据。当原先 SQL 运行要 30 分钟、一个小时的时候,我们通过列存储把 SQL 执行的时间缩短到 5 分钟。但是在这 5 分钟里,我们的数据分析师该干嘛呢?只能去倒杯咖啡发个呆么?所以,我们自然希望 SQL 在大数据集上,也能在几十秒,甚至是十几秒内得到结果。
所以 Google 并没有在列存储上止步,而是借鉴了多种不同的数据系统,搭建起了整个 Dremel 系统,真的把在百亿行的数据表上,常见 OLAP 分析所需要的时间,缩短到了 10 秒这个数量级上。那么,这节课我们就来看看 Dremel 是通过什么样的系统架构,做到这一点的。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

Dremel系统是一个高效的列存储系统,采用了多种数据系统设计思路,包括MPP数据库、搜索引擎的分布式索引和MapReduce的推测执行,实现了百亿行数据表的分析工作在1分钟以内完成的惊人效率。其核心技术特点包括采用列存储大幅减少数据扫描浪费、优化MapReduce程序执行时间、解决MapReduce的额外开销问题,使得SQL查询可以在10秒内得到结果。Dremel系统的设计极大地提高了数据分析的效率,对未来的架构设计工作具有借鉴意义。 Dremel系统的底层计算引擎采用了多层服务树的架构,包括根服务器、中间服务器和叶子服务器,实现了SQL查询的分布式处理和聚合。此外,Dremel系统采用了行列混合存储的MPP架构,将数据存储和计算放在同一个节点,以及将用户SQL查询重写并行分发到多个节点并汇总查询结果,极大提高了系统的并行处理能力和查询效率。 Dremel系统通过创新的架构设计和技术实现,为大规模数据分析提供了重要的技术支持和借鉴价值。其架构设计借鉴了搜索引擎的分布式检索机制,实现了树形分发的搜索引擎架构,以及从MapReduce借鉴了“容错”方案,保证了系统的稳定性和高效性。 Dremel论文的作者在2020年的VLDB里发表了一篇新论文,讲述了Dremel系统后续的迭代更新,包括数据存储迁移到共享的GFS上、通过内存Shuffle架构提升性能等内容,值得一读。这些更新展示了技术架构在不断的权衡、优化中进步的过程。 总之,Dremel系统的设计理念和技术实现为大规模数据分析提供了重要的技术支持和借鉴价值,其高效的数据分析处理能力对未来的架构设计工作具有启发意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《大数据经典论文解读》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(11)

  • 最新
  • 精选
  • 在路上
    徐老师好,我想Dremel一开始把数据放在硬盘上,是因为当时“计算和存储分离”还不是大数据领域的主流思想,MPP数据库把计算和存储放在一起的思路,在过去证明是有效的,Dremel借鉴过去的成功经验是理所当然的。在Dremel 2020年的论文的第3.1节提到“At the time, it seemed the best way to squeeze out maximal performance from an analytical system was by using dedicated hardware and direct-attached disks. As Dremel’s workload grew, it became increasingly difficult to manage it on a small fleet of dedicated servers”。也就是说,那个时候大家都认为把计算和存储放在一起才是最佳的方法,但是随着数据规模和查询负载的增加,服务器管理越来越困难。 在今天看来把数据放在GFS上,一定比放在本地好,但是这中间其实经过了很多优化,一开始的时候选择把数据放在本地是更好的选择,因为相关的技术都是很成熟的,把数据放在GFS上需要解决很多未知的问题。把数据放在GFS上有很多好处,第一,数据扩容方便,管理简单;第二,数据拥有多个副本,对容灾友好;第三,数据可以被Dremel之外的工具使用,也方便和其他团队共享。
    2021-11-02
    1
    21
  • 乐天
    分开存储的好处:计算和存储分离,可以提供资源的利用率,数据量大就单纯增加存储节点,计算量大就增加计算节点,能更好的利用资源。同时任务调度时不用综合考虑节点的性能和数据的位置。 坏处:增加了网络传输的时间。 这样做是因为硬件性能特别是网络传输设备的提升很大,大数据量的传输已经不是大问题了,数据传输的时间可能比任务等待调度执行的时间还要短。
    2021-11-23
    10
  • 好处:不用管存储的高可用,解决struggle的问题。 坏处:打破了数据计算在同节点的设计,造成一定网络开销,解决方法:gfs能够提供固定block位置的api。 问题:开源OLAP系统中,有像dremel这样可以加入中间层(层数> 1)的OLAP引擎吗? 以及如何确定中间层数。
    2021-11-01
    3
  • 陈迪
    尝试回答思考题:采用GFS最明显的好处是,存储扩展容易! 分片存储存本地硬盘,不可避免的、由于本地硬盘存不下了,要人肉做数据搬迁 或者 加一个元数据层进行管理,这不就是GFS么 另外,Dremel这个多层树状汇聚,很拉风!!
    2021-11-05
    2
  • LJK
    老师好,感觉Dremel的这种计算方式只适合简单计算,如果涉及join操作的话还如何通过这种树形服务拆分呢?
    2022-02-19
    1
  • 斜面镜子 Bill
    好处理解是本地访问性能和数据质量相对好保证,处理逻辑也相对简单。坏处就是弹性和IO的吞吐会比较限制。当然也想听听作者的解答。
    2021-11-01
    1
  • 哈达syn$
    分开存储的好处:计算和存储分离,可以提供资源的利用率,数据量大就单纯增加存储节点,计算量大就增加计算节点,能更好的利用资源。同时任务调度时不用综合考虑节点的性能和数据的位置。 坏处:增加了网络传输的时间。 这样做是因为硬件性能特别是网络传输设备的提升很大,大数据量的传输已经不是大问题了,数据传输的时间可能比任务等待调度执行的时间还要短
    2023-02-19归属地:四川
  • ?
    我觉得这个趋势是因为基础设施的发展,最开始数据和代码在一起是因为那时候网络的带宽有限。从远程读取数据对整个系统的性能影响较大。随着网络的发展,网络的开销逐渐不是影响架构的决定性的因素。其他的因素『扩容方便』『容灾恢复更快』占了决定性因素。
    2022-09-04归属地:四川
  • 核桃
    思考题的那里,问题就是以前存储和计算是不分离的,但是放在了GFS上面,那么数据的容错管理那些就交给了GFS了。但是这里也有一个潜在的问题,数据倾斜问题。不知道多少朋友遇到过。以前使用spark计算的时候,调度算法中如果优先在数据节点计算,那么当该节点中的数据很多都是热数据时,那么就容易出现问题了。当时还出现过生产事故,后面改了调度算法为公平调度才解决的。 所以如果避免存储系统的数据倾斜问题,一直以来都是一个痛点和难点,哈希算法目前来说,已经真的快走到头了。
    2022-02-22
  • piboye
    clickhouse 做到秒级别
    2022-01-16
收起评论
显示
设置
留言
11
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部