行业报告 AI展会 数据标注 标注供求
数据标注数据集
主页 > 大数据 > 正文

Arctic的数据湖数据仓库一体践行之路

本文将系统地介绍 lakehouse、table format 概念,阐述湖仓一体作为数据湖流批一体的解决方案,可以发挥哪些价值。在这个价值驱动下,我们过去两年开发了 arctic 这个流式湖仓服务,并在今年下半年开源。

湖仓一体拓展了数据中台和 dataops 的边界,让业务基于数据湖,数据中台也能做流式更新;实时数仓,让数据湖能够具备传统数仓,kudu,doris 的能力,为业务极大地降本提效。

1.前数据湖是什么

数据湖这个概念最早由 Pentaho 创始人兼 CTO James Dixon 在 2010 年提出,从当时背景看,这个点子主要是为了推销自家公司基于 hadoop 的 BI 产品方案,时至今日,虽然 Pentaho 已被日立公司收购,这位大佬也另谋出处,而数据湖的含义已远远超出原先的定义,经过各个大厂,尤其是 AWS,Azure 这类公有云厂商的加持,基于数据湖已衍生出非常多样的工具和方法论。

简单说,我们可以把数据湖当做一个存储各类结构化、半结构化和非结构化数据的池子,这个池子可以是私有化的 hadoop 集群,也可以是云端的对象存储,因为我们要存储体量非常大的原始数据和明细数据,这个池子的成本必须足够低,开启 EC 的 HDFS 或对象存储无疑是最佳选择。这个大需要多大?我们用 AWS 提供的一张图来说明:

图片

 

有了很大的池子存储原始数据和明细数据,数据分析师再也不用担心数据无法溯源,明细丢失的问题,但是按照传统的 BI 方法论,依然需要将数据湖的数据导入到数仓中,才能构建出终端想要的数据集市,那么为什么我们不能放弃旧框架,直接在数据湖上做分析,不是更快更省?

于是乎,数据湖开始了红红火火的十年,在过去十多年中发生了很多标志性事件,我们将数据湖过去十年的发展拆为两个阶段:

第一个五年(2010-2015)打地基,像 mapreduce,spark,flink 这些计算引擎让数据湖之上的 ETL,数据清洗和加工变得简单,parquet、orc 这类列存文件格式,impala、presto、trino 这些基于数据湖的 OLAP 引擎让数据湖之上的数据分析触手可得。

第二个五年(2015-2020)造建筑,不管是云端还是私有环境,各种数据模型,研发工具 ,治理平台玩地风生水起,网易有数、阿里 Dataworks 都是在这个时期诞生的数据中台产品。总体来看,数据湖技术经过五年的打地基,五年的造建筑,目前基于数据湖的工具和方法论已经非常成熟,比如网易做大数据的同学,很多人都接触过有数,或者直接使用过 hadoop、hive。

与几十年根基的传统数仓相比,数据湖近十年发展历程可谓占尽天时地利人和,越来越多的企业在强调数字化转型,越来越多的业务需要大数据帮助决策,此为天时;强大的扩展性,让任何企业都可以通过堆机器来应对爆炸的数据体量,不被任何商业公司绑架,不管你需不需要数仓,你可能都需要一个数据湖,此为地利;hadoop 开源体系,给用户带来了丰富的生态资源,也给企业培养了海量的大数据人才,大家喜欢开源,此为人和,另外,AI、机器学习、数据挖掘这类非标业务非常依赖生态资源的加持,数据湖在这方面有得天独厚的优势。

但同时,数据湖缺乏标准化的服务,生态内的组件大多各自为战,这带来了几个问题:

  • 建筑造地累,比如有数在产品侧需要对接非常多的组件,每个组件都有自己的玩法,架构难免臃肿,人效上不去,当然如果产品不做这些事,就得业务自己做,人效更低;
  • 会导致数据沼泽问题,哪些表在给哪些业务用,哪些数据有浪费,有重复建设,这些都必须在上层定制方案,基础设施这一层缺乏有效的度量和管理支撑,过去企业分享数据中台效果,动辄节省一大半的成本,说明数据湖之上的沼泽问题是非常严重的;
  • 对流和实时场景支持有限,因为数据湖的生态中没有支持行级更新的服务,行业内基本上用数据湖做离线数仓,实时数仓会选择其他方案;
  • 数据质量,因为数据湖非常开放,并且本身会存很多原始数据,在数据质量方面有天然不足,需要上层产品在质量保障方面多加考量。

2.火爆的湖仓一体

湖仓一体是个舶来词,英文叫 lakehouse, 由 databricks 公司首先在2020年3月提出,在 databricks 的理念中,传统数据湖在批计算,AI,机器学习等领域有丰富的资源和实践,但是在流计算,数据质量和数据治理方面相较于传统数仓有较大不足,为此 databricks 提供了 lakehouse 平台,基于数据湖之上提供不弱于传统数仓的能力,也能享受数据湖在 AI,机器学习,批计算上的积累。

Databricks 作为一家商业化公司来讲 lakehouse 的故事,必然有营销的成分在,但必须承认 lakehouse 这个概念已经深入人心,包括 databricks 的老对手 snowflake,也在讲自己是 lakehouse。感兴趣的同学建议看看 Databricks 工程师最早提出 lakehouse 的博客:

What Is a Lakehouse?

说到 lakehouse,就必须提到 table format 的概念,Table format 最早由 iceberg 提出,现在基本成为行业共识, table format 是什么?简单概括:

  • Table format 定义了哪些文件构成一张表,这样任何引擎都可以根据 table format 查询和检索数据;
  • Table format 规范了数据和文件的分布方式,任何引擎写入数据都要遵照这个标准,通过 format 定义的标准支持 ACID,模式演进等高阶功能。

目前国内外同行将 delta、iceberg 和 hudi 作为数据湖 table format 的对标方案,在 databricks 的故事中,delta 是 lakehouse 的存储底座,所以 table format 和 lakehouse 有非常密切的关系,我们有理由相信,lakehouse 方案应当是基于数据湖 table format,涵盖数据研发和数据治理的一整套方案。

湖仓一体有多火,关注行业动态的小伙伴应该会有切身感受,比如从今年开始基本上任何有体量的大会、论坛、meetup 都会组织湖仓一体相关的分会场,我们也能看到各个大厂在这个方向上的积极探索和实践,在 gartner 发布 Hype Cycle™ for Data Management 权威报告中,lakehouse 目前处于跃升期位置,相比于成熟期的 deta lakes,lakehouse 未来还有 3-5 年的发展成熟周期: 

图片

还有一份报告值得关注,在 2021 (2022 的报告还未发布)最新发布的数据库魔力象限中,主打 lakehouse 产品的 databricks 和 snowflake 携手进入领导力第一象限,而去年这份报告中,只有 snowflake 处于挑战者的位置:

图片

Lakehouse 不光在技术圈受捧,在资本圈也是鼎鼎有名,巴老爷子加持的 snowflake 千亿神话自不必说,databricks 经过多轮融资之后,也达到了 380 亿美金的估值。就在前不久,delta2.0 完全开源了(过去只开源了一部分)。

3.为什么做 Arctic

2020 年开始,通过用户走访和行业调研,我们开始尝试用 flink + iceberg 打造流批一体数据湖的方案,首要的目标是先构建存储的流批统一,在流批一体的数据湖之上,再去探索代码的流批一体,但是在实践中发现,iceberg 作为 table format,直接拿来匹配流批一体的需求还存在很大的 GAP,arctic 这个项目便是在这个背景下产生的。

3.1 企业需要湖仓一体

流批一体和湖仓一体是什么关系,这是过去两年被问的最多的问题。

简单说,流批一体是需求,湖仓一体是方案,就好比我说我想吃甜的东西,你拿给我一块蛋糕,甜是流批一体,蛋糕是湖仓一体。我们可以蛋糕是甜的,但不能是甜的东西就一定是蛋糕,从 lakehouse 提出的背景看,湖仓一体一定是流批一体,但流批一体不一定基于数据湖,事实上很多传统数仓都具备流批一体的能力。

企业为什么需要湖仓一体,可以拆成两个问题:

  • 企业为什么需要流批一体
  • 为什么要在数据湖上做这个事

我们来看看目前主流的流批共存的架构是怎么样的:

图片

场景中用 hive 做批表,kafka 做流表,实时场景下需要用户构建数据库同步到 hbase 的实时任务,需要用户实现 join hbase 维表的流计算任务,把数据写到支持实时更新的 kudu 中,最后由业务根据实时和离线的需要选择查询 kudu 表还是 hive 表,在此之前,用户需要分别在数据模型中建表,使用 kudu 的工具建表,并且自己处理两个系统的差异。在这个架构中,用户遭受了割裂的体验,并且需要在上层做很多工作。

在这套 lambda 架构中,用户使用 hive 和离线开发工具构建离线数仓,使用 kudu,hbase 和实时开发平台构建实时任务,相同的业务逻辑构建了两套数据模型,维护两套数仓和两套任务链路,造成人效和资源的浪费,语义的二义性也会给维护带来更大的成本,对数据分析师,算法工程师,数据科学家,去熟悉两套规范和工具,理解更多的底层概念也是一项很大的挑战。比如对网易云音乐而言,数据分析师和算法工程师很多,怎样尽可能提效和降本是一个很有意义的课题,而对一些规模有限的业务团队,人力紧张,也可能没有多余的预算来搭建两套系统,既快且省可能是第一位的诉求。

理解了流批一体的必要性,那么为什么要基于数据湖做流批一体?

第一数据湖是个兜底的存储中心,具有极强的弹性伸缩能力,符合“省”的要求,第二过去我们围绕数据湖已经搭建了非常丰富的工具,而且现在依然在向 dataops 的方向持续演进,基于这套方法论也沉淀了非常多的规范和实践,如果基于数据湖做流批一体,数据中台上的很多能力可以复用,快速上手,符合业务对“快”的需求。

反之如果我们使用其他数仓做流批一体,比如 doris,相当于在数据湖之外又构建了一个数据孤岛,在依然需要数据湖的情况下,业务需要自己处理 doris 和数据湖的传输和一致性,没有从根本上解决问题。

3.2 Table format 不等于湖仓一体

我们从数据分析的可用性,数据加工的实时性,湖仓的管理三个方面来说明 table format 与我们需要的 lakehouse 之间的 gap。

3.2.1 数据分析可用性

与 Hive 相比,delta/iceberg/hudi 最核心的不同是在表格式中抽象出快照的概念,表的任何数据变更都会构造出新的快照,delta/iceberg/hudi 通过快照的隔离实现数据写入的 ACID 和读取的 MVCC,更好地支持数据实时摄取和计算,如下图所示:

图片

 

Table format 是数据湖之上比 hive 更进一步的元数据封装,遵循所读即所写的原则,而在用户的读写之间应当有一个标准化的服务,比如在流和实时场景下,会在数据湖中写入很多碎片文件,这些小文件会导致读性能的急剧下降,在 chbenchmark中,我们发现流式写入 2 小时就会导致 olap 性能下降 1 倍以上,不管是数据去重还是小文件合并,我们需要需要一套持续优化的服务来保障数据分析持续可用。

3.2.2 实时数据加工

湖仓一体的特性让批和流的数据加工、数据分析、科学计算、机器学习都能在数据湖中完成,在这几个环节中,数据加工是最基础的步骤,流批一体的数据加工可以让 BI 和 AI 共享 lakehouse 高人效,低成本,强弹性的红利。

目前生产环境中大多使用 hive 和 kafka 分别作为批表和流表选型,实时场景下再搭配 flink 和 kudu 这类支持行级更新的列存数据库做实时数仓方案,用消息队列的优势在于毫秒到秒级的数据时效性,如果我们用 lakehouse 替换掉 hive 和 kafka,在离线数仓和批计算上,可以做到平替,但是在实时数仓和流计算上,由于数据湖的增量读有分钟级延迟,会出现毫秒/秒级的时效性到分钟级时效性的降级。而且从实践上讲,以 kafka 或 pulsar 作为流表实现更加成熟,这令数据湖在实时加工链路中天然吸引不足。

在大量用户调研后,我们发现用户大多能接受数据分析分钟级别的时效性,但对端到端的处理延迟有更高的要求,尤其对数据开发同学,KPI 指标可能是构建的数据建设的复用度,低时效性的数据处理可能丧失对更多场景的吸引,同时面对复杂的数据分层场景,会让端到端的延迟更加不可控。

另一个实时数据加工的问题是维表关联,就是我们俗称打宽的场景,在上文的 lambda 架构中,当用户需要维表关联时,往往需要引入一套 hbase 或 redis 这样的 KV 系统,数据开发同学、算法工程师不光要耗时耗力学习和使用 kv,还需要自己构建数据库到 kv 的同步,接收和处理这些同步任务的报警,处理 kv 数据的序列化反序列化,严重降低了数据开发和算法工程师的幸福度。

在 databricks 的理念中,lakehouse 能做到开箱即用的流批一体,但显然用户期望的流批一体和 delta、iceberg 这类 table format 之间还有较大的 gap,用户对 lakehouse 的期望既要兼顾到端到端的延迟,数据打宽时也要能像离线 join 一样做到即插即用。

3.2.3 怎么做湖仓管理

上文提到,小文件是典型的湖仓管理要解决的问题,过多的小文件会让 OLAP 性能下降,HDFS 的 NN 不堪重负。而当我们在数据湖之上构建更多的实时数仓,会面临更多成本、时效性和性能的管理需求:

  • 表的时效性怎么量化,是否达到用户预期?
  • 湖仓表当前的查询性能有多少可优化空间?
  • 数据优化的资源怎样量化,怎样最大化利用?
  • 怎样灵活分配资源,为高优先调度资源?

区别于 MPP 架构的传统数仓,湖仓是个天然存算分离,弹性伸缩的架构,过去部署一套 greenplum,部署了几台机器,就用几台机器,如果发现容量或性能不足,就去扩容,数据迁移。对这种传统存算一体的架构,对应的管理系统目标是尽可能把内部的运作黑盒化,对外提供一些度量和指标来衡量系统的健康度或性能。

而在湖仓中,首先这套管理系统是缺失的,hive 以及现在的数据湖 table format 归根到底只是定义了表在数据湖上的元数据形态,并没有动态的湖仓管理机制,其次如果我们想做一套湖仓管理系统,思路和存算一体的 MPP 数据库也会有所区别,比如湖仓在后台进行的数据优化动作,用户需要为这些弹性的优化行为花钱,而这个钱会直接作用在湖仓的时效性和性能上,存算分离的管理系统需要为用户更加透明地梳理好时效性,性能,成本之间的关系:

图片

 

这套湖仓管理系统,需要在保障性能、可用性的前提下,利用好数据湖弹性伸缩的能力帮助用户最大限度降本,为用户花出去的每分钱负责。

4.Arctic 是什么

我们聊了企业为什么需要流批一体和湖仓一体,也聊到了 table format 和湖仓一体之间的 GAP,生产场景中会存在的需求和问题,Arctic 便是我们团队对这些需求和问题的答案。

Arctic 目前已经开源,我们对 arctic 目前的定位是流式湖仓服务,是基于 lakehouse 开箱即用的流批一体服务,流式强调在数据湖之添加了更多实时的能力,如更加优化的 CDC 摄取,流式更新,生产可用的实时合并,对用户无感的流式数据自优化等,服务强调 arctic 是搭建在 table format 之上的管理服务,如上文所属,arctic 管理服务聚焦在为用户梳理时效性,性能以及成本之间的关系,帮助用户做好容量规划,数据管理和治理。目前 arctic 是搭建在 iceberg 之上,理论上说,arctic 未来也可以基于 delta 和 hudi。

Arctic 架构如下图所示:

图片

可以看到,Arctic 的核心组件包含 AMS 和 Optimizer,在 arctic 中,AMS 被定义为新一代 HMS,AMS 管理 Arctic 所有 schema,向计算引擎提供元数据服务和事务 API,以及负责触发后台结构优化任务。

Arctic 作为流式湖仓服务,会在后台持续进行文件结构优化操作,并致力于这些优化任务的可视化和可测量,优化操作包括但不限于小文件合并,数据分区,数据在 Tablestore 之间的合并转化。

Optimizer container 是 optimizing 任务调度的容器,目前生产环境主要是在 yarn 上调度,支持扩展 optimizer container 实现调度到 k8s 或其平台。Optimizer group 用于资源隔离,optimizing container 下可以设置一个或多个 optimizer group,也可以通过 optimizer group 实现优先级的功能,在 yarn 上 optimizer container 对应队列。

篇幅关系不再对 arctic 的架构与概念进一步展开,感兴趣的同学可以移步我们的文档,后续我也会在其他的文章里聊聊 arctic 在架构设计中的考量,与其他产品的差异。

5.能用 Arctic 做什么?

Arctic 的目标是开箱即用的流批一体:

图片

与原先流批割裂的 lambda 架构相比,arctic 用存储统一了数据生产的链路,arctic 表既可以作为离线表给 spark 用,也可以作为流表给 flink 用,还可以用 impala/trino 的 OLAP 引擎查询 arctic 表,构建数据集市。值得一提的是,arctic 的流表能够做到毫秒到秒级,arctic 将用户需要的消息队列,作为 broker service 封装到 arctic 的管理体系里,用户只需要在创建表的时候指定是否需要引入队列,在后续的使用中即可透明无感地用到消息队列实时分发的能力,arctic 在对接 flink 的 connector 中,封装了消息队列与数据湖的双写和一致性保障。

在 AP 性能上,arctic 通过 optimizer 机制实现表的结构自优化,在我们的 benchmark 测试中,流式写入 iceberg 表 1 个小时以后,因为小文件问题,以及一些不完善,性能下降会非常厉害,1.5 小时候数据已经跑不出来了,arctic 的平均延迟维持在 20s 左右,而 hudi 30s 左右(平均延迟越小,性能越好),详细的 benchmark 报告可以移步:https://arctic.netease.com/ch/benchmark/

图片

Arctic 流批一体的能力可以拓展数据中台,或 dataops 的边界,更直观点说,用户可以直接用各种有数的中台工具来实现流批一体,比如今年我们在帮有道做的替换 doris,和传媒一起做的替换 clickhouse,业务在使用之前的系统时,缺乏高效率的工具,还要为这些独立部署的资源买单,切到 arctic 之后,由于数据湖高度弹性的能力,和低成本的特性,可以给用户省钱提效。

Arctic 不光可以用在大数据场景,今年调研发现,在线业务也有一些需要存储大体量的历史数据,或者 AP 和 TP 混用的场景,比如风控场景需要存储非常多日志清洗后的数据,而这些数据全部存储在 ES 里成本会失控,我们和云音乐团队一起做了一个数据湖与 ES 混合使用的方案,数据湖来兜底,会存储非常久的数据,并且是实时入湖,在我们测量下,用数据湖来实现冷热分离,占用的空间小 XX 倍,成本上则带来几十倍的提升。

6.期望与规划

要做到开箱即用的流批一体,arctic 还有不少的工作要做。

比如不依赖外部 kv 的维表关联,在前不久发布的 arctic v0.3.1 版本中,我们发布了这项功能的 beta 版本,在一些维表不是很大的场景下,可以做到生产可用,未来还需要做哪些优化工作,已经在 roadmap 里,再比如 inline upsert 功能,让 flink 任务可以流式更新大宽表中的部分列,从而代替状态过大的多流 join,这两个是我们今年在流场景下想要重点打造的功能。完整的 roadmap 记录在 这里 。

在批场景,我们已经支持了相当一部分业务,通过 spark 的读时合并让业务能够独到准实时的数据,用户也可以通过有数提供的 impala 对接 arctic 实现分钟级时效性的实时数仓,用 trino 的用户,可以将 arctic 的 trino connector 集成到自己的 trino 集群中,我们的小伙伴会做好对接工作。

未来 arctic 也将不断丰富管理功能(这块在 lakehouse 领域还比较空白),arctic 作为网易数帆重点打造的一个开源项目,非常欢迎内外部的开发者能够关注、使用和参与,一起打造行业领先的湖仓管理系统,未来一年我们极有可能尝试在 apache 孵化。

微信公众号

声明:本站部分作品是由网友自主投稿和发布、编辑整理上传,对此类作品本站仅提供交流平台,转载的目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,不为其版权负责。如果您发现网站上有侵犯您的知识产权的作品,请与我们取得联系,我们会及时修改或删除。

网友评论:

发表评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
用户名: 验证码:点击我更换图片
SEM推广服务

Copyright©2005-2026 Sykv.com 可思数据 版权所有    京ICP备14056871号

关于我们   免责声明   广告合作   版权声明   联系我们   原创投稿   网站地图  

可思数据 数据标注行业联盟

扫码入群
扫码关注

微信公众号

返回顶部