设为首页 - 加入收藏 ASP站长网(Aspzz.Cn)- 科技、建站、经验、云计算、5G、大数据,站长网!
热搜: 创业者 数据 手机
当前位置: 首页 > 大数据 > 正文

从Delta 2.0开始聊聊我们需要怎样的数据湖

发布时间:2022-11-16 09:16 所属栏目:125 来源:互联网
导读:虽然 Databricks 的工程师反复强调性能测试来自第三方 Databeans,并且他们没有主动要求 Databeans做这项测试,但如果全程看完 delta2.0 发布会,会发现在 delta2.0 即将开放的 key feature 中,特别列出了 Iceberg 到 Delta 的转换功能,并且官方着重讲到了
  虽然 Databricks 的工程师反复强调性能测试来自第三方 Databeans,并且他们没有主动要求 Databeans做这项测试,但如果全程看完 delta2.0 发布会,会发现在 delta2.0 即将开放的 key feature 中,特别列出了 Iceberg 到 Delta 的转换功能,并且官方着重讲到了 Adobe 从 Iceberg 迁移到 Delta2.0 的实践,这就难免让人浮想联翩了。
  
 
  过去两年,我们团队在新型数据湖技术的研究、探索和实践上投入了大量精力,虽然我们主要投入的方向是 Iceberg,但 delta2.0 的开源,以及 Databricks 自身对 Iceberg 的重视,更加坚定了我们对数据湖,湖仓一体这个方向的信心,开源之争,本质上是标准之争,竞争会加速标准的确认和落地,而所有大数据的从业者都将从中获益。
 
  由于我们的工作更多将 Iceberg 当做一个底层依赖使用,在架构上具备解耦的可能,我们完全可以拥抱 Delta,所以这里我想站在一个第三方立场上讲讲对 Lakehouse 这个方向,以及几个主流开源产品的理解和思考,顺带也会简单讲讲我们的工作,另外希望大家可以和我共同思考和探索下面这个问题:
 
  企业究竟需要怎样的数据湖?
 
  1、Table format 三强之争
 
  Table format 最早由 Iceberg 提出,目前已经成为行业共识的概念, table format 是什么?简单概括的话:
 
  Table format 定义了哪些文件构成一张表,这样任何引擎都可以根据 table format 查询和检索数据;
  Table format 规范了数据和文件的分布方式,任何引擎写入数据都要遵照这个标准,通过 format 定义的标准支持 ACID,模式演进等高阶功能。
  目前国内外同行将 delta、iceberg 和 hudi 作为数据湖 table format 的对标方案,我们先来聊聊 delta,iceberg,hudi 这三个开源数据湖的背景。
 
  1.1 Delta
 
  delta 是 databricks 公司在 2017 年立项、2018 年公布、2019 年开源的数据湖产品,可以看到 delta 立项时 databricks 已成立 4 年,经历过几次融资,并且在有条不紊地布局商业版图,彼时 hadoop 发行版还不是公认难做的生意,delta 的诞生更像是 databricks 根据自身 spark 创始团队的基因打造的核心竞争力,这样也不难理解,为什么 delta 1.0 几乎不向其他引擎开放。
 
  delta 的推出是为了解决传统数据湖在事务处理,流计算,BI 分析上的不足,Databricks 用极强的讲故事能力为 delta 打造了一个 lakehouse 的概念,时至今日,lakehouse 和湖仓一体的概念已经深入人心,甚至老对手 snowflake 也采纳了这个概念,并且在官网中给出了更贴合自家产品的定义。在 2021 Gartener 数据库领导力象限中,Databricks 和 snowflake 一起晋升第一象限,lakehouse 也首次进入 hype cycle for data management,定位跃升期,依据 Gartner 的定义,lakehouse 技术距离完全成熟可能还有 3 - 5 年的时间。
  
  按照 Databricks 的构想,delta1.0 作为 lakehouse 解决方案,可以让数据湖更多,更快地作用于实时和 AI 场景,databricks 提出 delta 架构帮助用户从 lambda 架构中解放出来,核心思想是数据湖既可以跑批,也可以跑流,流计算和批计算的流程和代码可以复用,这样用户没有了维护 lambda 架构的负担,当然计算引擎必须是 spark。遗憾的是 spark streaming 和 struct streaming 在国内用户体量很小,绝大部分用户对 delta1.0 是望梅止渴,对 spark 的深度绑定也一定程度上限制了 delta 社区的发展,给 iceberg 的崛起预埋了伏笔,截止 2022 Q1 社区活跃度的一个对比如下:
  
  但另一方面,我们也绝不能忽略 Databricks 作为一家运营多年的商业公司,已有相当体量的付费用户,再加上对 spark 社区的主导权,成熟的营销和渠道能力,也许很容易重新建立开源上的优势。
 
  Delta 是 Lakehouse 的解决方案,Databricks 也被当做 lakehouse 的代表,但是 delta 这个项目自身的定义却经历了一些变化,我关注到去年某个时间点之前, delta 定义为 open format,引擎中可以直接用 delta 替换 parquet。
  
  Format 的定义与 iceberg 的 table format 的定义非常相似,但在目前官网中,以及各种相关的分享和博客中,再也见不到此类描述,目前 delta 被官方定义为 lakehouse storage framework,当然,无论 format 还是 framework,汤还是那个汤,只是菜谱更加丰满了。
 
  1.2 Iceberg
 
  Iceberg 是由 Netflix 团队研发并开源的数据湖 table format,创始人 Ryan Blue 是 spark,parquet,avro 的 PMC,在数据分析领域有非常丰富的经验和人脉,co-fonder 中还有一位来自 Cloudera 的资深工程师,从时间线上看,iceberg 2018年进入 apache 孵化,2020 年毕业,考虑到项目本身的研发周期,很难评判它和 delta 的时间先后,再加上创始人本身是活跃的 spark 贡献者,两个项目从一开始就高度相似。
 
  从功能上看,套用知乎上的一句话:不能说非常相似,只能说一模一样。从发展上看,iceberg 更加符合一个开源项目的气质,早期这个项目更多是为了应对 Netflix 对大体量数据分析的需求,重点强调了以下的特性:
 
  ACID 和 MVCC 的特性,读数据时不会读到写入的不一致状态
 
  Data skipping,通过在 table format 这一层 skip 文件,在一些场景下 query 性能有较大提升
  Plan 时不像 hive 需要过多地依赖 namenode,对超大集群来说 plan 的性能有巨大提升
  设计时更多考虑了 S3 上搭建 table format,让 iceberg 成为数据湖上云的一个很好选型
  Schema evolve 和 hidden partition,让表的变更和维护变的更加轻松
  创始人非常强调 iceberg 之于 hive 的优势,并且切实戳中了开发者,尤其有上云需求的用户痛点,很多圈内人提出 iceberg 会成为下一代的 hive,iceberg 引擎平权的特性,进一步促进了外围厂商的认同,目前公开信息可以了解到 Cloudera 主推 iceberg;snowflake 上支持 iceberg 外表;starrocks 支持 iceberg 外表;Amazon Athena 可以使用 iceberg 表,与 delta 相比,iceberg 的出身更加纯粹,被各家追捧也不奇怪,虽然 delta 2.0 也开始吸引 spark 之外的引擎开发者参与,但追赶目前 iceberg 的外围生态还需要一定的时间。
 
  我本人是在 2020 年接触 iceberg,当时在为 flink 寻找比 hive 更好的数据湖方案,以解决 upsert, 以及批流场景开发和运维割裂的问题,当时 iceberg 和 hudi 都在孵化,delta 依然是 spark 的 delta,而 hudi 当时也是一个 spark lib,只有 iceberg 让人眼前一亮,iceberg 也是最早支持 flink connector。
 
  Iceberg 社区对 roadmap 一直很克制,任何对底层表格式的修改都慎之又慎,保障了对任何引擎都足够友好,操作的可扩展性和 row-level api 则给开发者留足了想象空间,在引擎平权方面,iceberg 是独树一帜的,未来怎么样值得我们持续观察。
 
  1.3 Hudi
 
  Hudi 开源和孵化的时间线与 iceberg 比较相近,回溯开源之初,hudi 的全称是 hadoop upsert and incremental,核心功能是在 hadoop 上支持 upsert 和 incremental process,发展至今,hudi 已经不再局限于 hadoop 以及名字上的两个功能,hudi 不强调自己的数据 format,经过几次大的迭代,对自己的定义变地有些复杂,打开官网我们会看到这样的描述:
  
  Hudi is a rich platform to build streaming data lakes with incremental data pipelines on a self-managing database layer while being optimized for lake engines and regular batch processing.
  
 
  可以看出 hudi 想干很多事,并且给自己建立了像数据库一样的目标,这个目标的达成有很长的路要走。Hudi 在三个项目中最早提供 stream upsert 能力 ,如果不做二次开发,hudi 是开箱即用的数据湖 upsert 方案,并且 hudi 社区对开发者非常开放,和 iceberg 专注又谨慎的调性可谓两个极端,但 hudi 大版本之间的变化很大,这个方面先压下不表,有机会专门开个文章聊聊。
 
  最早的时候 hudi 只有 spark 下的实现,为了支持 flink 在重构方面社区下了很大的功夫(delta类似),这也是 2020 年没有选择 hudi 的最重要原因,在 hudi 的核心团队创业成立 Onehouse 之后,hudi 的定位明显和其他两家产生了较大的分化,databricks 作为一家商业公司,delta 是他吸引流量的重要手段,商业化上再通过上层的数据开发,治理和 AI platform 变现,同理从公开信息看, Ryan Blue 成立的 Tabular 也是在 iceberg 之上构建 platform,和 table format 泾渭分明。而 hudi 自身已经将自己拔到 platform 的高度,虽然功能上还距离很远,但可以预见长期的 roadmap 会产生较大不同。
 
  出于竞争的考虑,delta 和 iceberg 有的,hudi 可能都会跟进,所以 hudi 也可以作为 table format 来使用。当我们为企业做技术选型时,需要考虑是选择一个纯净的 table format 整合到自己的 platform 中,还是选择一个新的 platform 或者将 platform 融合。
 
  2、Iceberg 背刺与 delta2.0 的反击
 
  现在下判断,为时尚早。
 
  如果一定要对比,我更加喜欢对比 delta 和 iceberg,因为 hudi 的愿景和前两个有较大的不同,换句话说,就 table format 而言,delta 和 iceberg 可能更懂要做什么,就懂的层面两讲,iceberg 我认为更胜一筹。拿最近 delta 2.0 发布的内容来看,有兴趣的同学可以去看下 Databricks 官方举办的 Data + AI summit 2022 的 相关分享。
 
  发布会重点提及的功能总结如下:
 
  Data skipping via column stats:通过 format 级别的元数据做 data skipping
  Optimize ZOrder:这个应该是 delta 一直有的功能,只是在 2.0 中正式开源了
  Change data feed:支持 UPDATE/DELETE/MERGE INTO 下的 CDC 功能
  Column mapping:delta 也能像 iceberg 一样模式演进了,功能上相差不大
  Full ACID guarantees on S3:在提交阶段引入 DynamoDB,在 S3 上也能保障 ACID
  Flink、presto、trino connector:重点强调了 flink 和 trino,connector 和 delta 项目分开管理
  Delta standalone:我理解是提供了一层 format api,像 iceberg 一样不用通过引擎也可以操作数据
  对 Iceberg 不太了解的同学,可以去看下 iceberg 官网,引用上文中的一句话,不能说非常相似,只能说一模一样,而且大部分功能在 2 年前的 iceberg 中已经相当成熟了。
 
  在发布会后段,Databricks 工程师重点介绍了:
 
  Adobe 公司从 iceberg 到 delta 的迁移实践,对 iceberg 的重视可谓是写在脸上了
  Delta 不只是 databricks 公司贡献,2.0 中也 involve 了来自 flink,trino 社区的开发者,不过引擎开发者贡献的部分单独在一个 connector 项目,与 delta 的主体区分开,未来在引擎平权方面能不能做到或超越 iceberg,还需要观察
  引用第三方 Databeans 的测试,delta 2.0 性能比 iceberg 快 1.7 倍,比 hudi 快 4.3 倍
  我们团队也用 benchmark 工具对 delta2.0 和 iceberg 进行了对比,测试方案是在 trino 下测试 100 个 warehouse 的 tpch(测试工具实际是为测 stream lakehouse 量身定制的 chbenchmark,下文也有提及),当我们采用 delta 和 iceberg 开源版本默认的参数,对比下来 delta 确实惊艳,平均响应时间 delta 比 iceberg 快 1.4 倍左右,但我们注意到默认参数中有两个重要的区别:
 
  Trino 下 delta 和 iceberg 的默认压缩算法不同,trino写入 iceberg 默认的压缩算法是 ZSTD,而写入delta 默认的压缩算法是 SNAPPY,ZSTD 具有比 SNAPPY 更高的压缩比,通过实际观测ZSTD压缩出来的文件大小只有 SNAPPY 大小的 60%,但是在查询时SNAPPY对于CPU更友好,查询效率更高;
  Delta 和 iceberg 默认 read-target-size 不同,delta 默认32m,iceberg 默认 128m,plan 阶段组装更小的文件可以在执行计划采用更多并发度,当然这会带来更多资源消耗,从实践上看 32m 的文件大小对响应时间敏感的数据分析而言或许是更好的选择。
  将 delta 和 iceberg 的压缩算法设置相同,read-target-size 设置为 32m,实测下来 tpch 平均响应时间不再有差别,从原理上看,排除占比极低的元数据读取和 plan 时间,在相同的配置下,benchmark 测试的主要是 parquet 这类文件格式的 IO 性能,没有差异是比较合理的。后续 Onehouse 在性能测试上给出的 回击 也佐证这一点:
  
  作为一名相关从业者,Delta2.0 的完全开源是一件振奋人心的事,几乎可以下结论,delta2.0 和 iceberg 重叠的功能,会成为数据湖 table format 的事实标准,在这个方向上提前投资的产品和开发者有可能更快地收获果实。
 
  至于谁更优秀?iceberg 的开放,专注和执行力让人叹服,delta 的影响力,商业资源和成熟度不可忽略。从功能和外围生态看,iceberg 依然有至少 1-2 年的先发优势,但是生长在 iceberg 上原汁原味的 Tablur 还没影,delta 的平台背书本就超强,再向其他引擎开放了 connector 和 API 之后,相信开源的贡献者和影响力也会同步跟进,期待 delta 社区在活跃度上可以迎头赶上。
 
  3、新技术推广的困局
 
  作为一名基础软件工程师,自底向上倒逼需求是非常艰难的,想要业务团队切换基础软件可能同时需要天时地利人和,而研究数据湖的同学相信在过去两年推动业务时多少会遇到力不从心的局面,这里我来分享一些我的理解。
 
  我们将目前数据湖 Format 已经形成的标准能力做一个小结:
 
  结构自由,用户可以自由变更表结构,包括加列改列删列,数据无需重写
  读写自由,通过 commit 原语保障 ACID,可以并发写入和读取,不会读写到不一致状态
  流批同源,除了批读和批写外,通过增量读和流式摄取支持流计算
  引擎平权,支持大部分用户会用到的主流计算引擎,包括 flink、spark、trino 等
  现在用户使用数据湖,基本是在一个成熟的数据生产力平台中使用,代表有阿里 Dataworks,网易数帆有数平台,借用同事对网易大数据业务过去十年的发展实践,大体分为三个阶段:
 
  大数据平台:能够在 Hadoop 平台上开发工作流,支持基础的数据开发和运维,有一定数据治理能力。
  数据中台:将数据业务的更多共性需求抽象到中台层,围绕业务主题域构建指标体系,并打通数据模型、数据开发运维、为业务构建权限和质量评估体系,资产平台为业务提供更高阶的数据治理能力。
  3D 平台:我们从数据中台,升级到 Dataops,Datafusion,Dataproduct 的 3D 体系,3D 更加强调体系化和流程标准化,强调 CICD,强调多数据源融合。
  在市面上除了阿里,数据生产力平台基本还是围绕 Hadoop,Hive 的数据湖体系,或者云端的对象存储来构建,相比于 Delta,Iceberg 这类数据湖 Format,Hive 和对象存储的结构不自由,读写不自由的问题基本已通过流程规范和上层规避克服掉了。在新数据湖技术兴起阶段,大家津津乐道的模式演进, ACID,对一个成熟的数据生产力平台以及它所面向的平台运维,数据消费者,分析师基本无感,而引擎平权的特性,hive 自己已经做到了最佳。
 
  至于流批同源,在实践中归纳起来有以下两点:
 
  用数据湖 CDC 替代消息队列,理论上能够带来成本收益,但也会引入小文件问题;
  数据湖 + 读时合并,在一定程度上对 kudu,clickhouse,doris 等实时数仓方案形成替代方案。
  总体来说,以上两点是行业内讨论最多的数据湖实践,但这套技术在实践上客观说还不够成熟,比如说用数据湖 CDC 替代 kafka,延迟降低到分钟级别,先不说产品的适配成本,业务接受这种能力降级往往需要比成本优化更充分的理由,而且数据湖 CDC 还会引入小文件问题。对读时合并这点,我们测试下来,用流式摄取方式往 iceberg 表写入两个小时,AP 的性能下降至少一半。当然 delta/iceberg 带来的新功能不止于此,比如模式演进对特征的场景非常有用,MERGE INTO 的语法对补数的场景非常有用,UPDETE/DELETE SQL 对国外 GDPR/CPAA 的执行是强需求,但这些特性比较细,往往只是对特定场景有吸引。
 
  两年来我们跟不少同行做实践上的交流,大家大体上遇到的都是这样的问题:业务吸引不够,相比替代方案好像没有带来质的提升;产品适配意愿不强,三个项目都很牛,但似乎看不到能给产品带来什么实质的好处,又怕站错边选错路;叠加经济形势下行,业务风险偏好降低,对新技术也没那么上心了。
 
  所以当我们真正把新的数据湖技术应用到产品和实践中,不妨先自顶向下地思考这个问题:企业究竟需要怎样的数据湖?​
 
  4、企业需要怎样的数据湖?
 
  这个问题其实 Databricks 已经给了我们答案,Delta 用一套数据湖存储,将批计算和流计算融合,将传统数仓在数据分析上的优势,数据湖在 AI,数据科学上的优势结合起来,基于 Lakehouse 这个存储底座,实现数据业务的全场景覆盖。总结为一点,Delta 给 Databricks 带来的价值是用一套基础数据湖软件,实现全场景覆盖。

(编辑:ASP站长网)

    网友评论
    推荐文章
      热点阅读