共计 5909 个字符，预计需要花费 15 分钟才能阅读完成。
背景
随着大数据业务的倒退，基于 Hive 的数仓体系逐步难以满足日益增长的业务需要，一方面已有很大体量的用户，然而在实时性，功能性上重大缺失；另一方面 Hudi，Iceberg 这类零碎在事务性，快照治理上带来微小晋升，然而对曾经存在的 Hive 用户有较大的迁徙老本，并且难以满足流式计算毫秒级提早的需要。为了满足网易内外部客户对于流批一体业务的需要，网易数帆基于 Apache Iceberg 研发了新一代流式湖仓，相较于 Hudi，Iceberg 等传统湖仓，它提供了流式更新，维表 Join，partial upsert 等性能，并且将 Hive，Iceberg，音讯队列整合为一套流式湖仓服务，实现了开箱即用的流批一体，能帮忙业务平滑地从 Hive 过渡到 Streaming Lakehouse。
Arctic 是什么
Arctic 是搭建在 Apache Iceberg 之上的流式湖仓服务（Streaming LakeHouse Service )。相比 Iceberg、Hudi、Delta 等数据湖，Arctic 提供了更加优化的 CDC，流式更新，OLAP 等性能，并且联合了 Iceberg 高效的离线解决能力，Arctic 能服务于更多的流批混用场景。Arctic 还提供了包含构造自优化、并发抵触解决、标准化的湖仓治理性能等，能够无效缩小数据湖在治理和优化上累赘。
Arctic Table 依赖 Iceberg 作为根底表格局，然而 Arctic 没有倾入 Iceberg 的实现，而是将 Iceberg 做为 lib 应用，同时 Arctic 作为专门为流批一体计算设计的流式湖仓，Arctic Table 还封装了音讯队列作为表的一部分，在流式计算场景下能够提供更低的音讯提早，并且提供了流式更新，主键唯一性保障等性能。
流体一批的解决方案
在实时计算中，因为低提早的要求，业务通常采纳 Kafka 这类音讯队列作为流表计划，然而在离线计算中，通常采纳 Hive 作为离线表，并且因为音讯队列不反对 AP 查问，通常还须要额定的 OLAP 零碎如 Kudu 以反对实时计算链接的最终数据输入。这就是典型的 Lambda 架构：
这套架构最显著的问题就是多套零碎带来的运维老本和反复开发带来的低效率，其次就是两套零碎同时建模带来的语义二义性问题，并且实在生产场景中，还会呈现实时和离线视图合并的需要，或者引入 KV 的实时维表关联的需要。Arctic 的外围指标之一，就是为业务提供基于数据湖的去 Lambda 化，业务零碎应用 Arctic 代替 Kafka 和 Hive，实现存储底座的流批一体。
为此 Arctic 提供了以下性能：
- Message Queue 的封装：Arctic 通过将 MessageQueue 和数据湖封装成一张表，实现了 Spark、Flink、Trino 等不同计算引擎拜访时不须要区分流表和批表，实现了计算指标上的对立。
- 毫秒级流计算提早：Message Queue 提供了毫秒级的读提早，并且提供了数据写入和读取的一致性保障。
- 分钟级的 OLAP 提早：Arctic 反对流式写入以及流式更新，在查问时通过 Merge on Read 实现分钟级的 OLAP 查问。
Table Store
Arctic Table 由不同的 Table Store 组成，TableStore 是 Arctic 在存储系统中定义的表格局实体，Tablestore 相似于数据库中的 cluster index，代表独立的存储构造，目前分为三种 TableStore。
ChangeStore
ChangeStroe 是一张 Iceberg 表，它代表了表上的增量数据，或者说最新的数据变更，通常由 Apache Flink 工作实时写入，并用于上游工作近实时的生产。
BaseStore
BaseStore 也是张 Iceberg 表，它代表了表上的存量数据。通常来自批计算的全量初始化，或者通过 Optimizer 定时将来自 ChangeStore 的数据合并入 BaseStore。在对 Arctic 表执行查问时，BaseStore 的数据会联结 ChangeStore 的数据一起通过 Merge-On-Read 返回。
LogStore
只管 Changestore 曾经可能为表提供近实时的 CDC 能力，但在对提早有更高要求的场景依然须要诸如 Apache Kafka 这样的音讯队列提供毫秒级的 CDC 数据散发能力。而音讯队列在 Arctic 表中被封装为 Logstore。它由 Flink 工作实时写入，并用于上游 Flink 工作进行实时生产。
Arctic 对 Hive 的兼容
在实在业务实际中，Hive 有着十分宏大的存量用户以及围绕其构建的中台体系，要想一步间接实现从 Hive 到湖仓零碎的转换难度十分大，因而如何利用已有的 Hive 生态是 Arctic 实现流批一体首先须要解决的问题。为此 Arctic 提供了 Hive 兼容的能力，以帮忙 Hive 用户能够平滑的迁徙到流式数仓中。具体到细节，Arctic 提供了以下 Hive 兼容能力：
- 数据拜访层面的兼容：Arctic 与 Hive 原生的读写形式放弃兼容，即通过 Arctic 写入的数据，Hive 能够读；Hive 写入的数据，Arctic 能够读。
- 元数据层面的兼容：Arctic 表能够在 HMS 上注册并治理，用户间接对 Hive 表执行 DDL 能够被 Arctic 感知到。
- Hive 生态的兼容：Arctic 表能够复用目前围绕 Hive 的生态，比方能够间接通过 ranger 对 Hive 进行权限治理的形式对 Arctic 表进行受权。
- 存量 Hive 表的兼容：海量的存量 Hive 表，如果有实时化的需要，能够以很低的代价将 Hive 表降级为 Arctic 表。
Hive 兼容的 Table Store
解决 Hive 兼容的首要问题是须要解决 Hive 和 Arctic 文件散布上的不同，在 Arctic 表中被分为 ChangeStore、BaseStore、LogStore 三个不同的 Table Store，从定义上，BaseStore 代表着表的存量数据，这与 Hive 的离线数仓定位是统一的，然而在实现上，Arctic 并未间接将 BaseStore 替换为 Hive Table，而是依然保留 Iceberg Table 作为 BaseStore 的实现以提供 ACID 等个性，并通过目录划分的形式，划分出对 Hive 兼容的目录空间，具体构造如下图所示：
重点咱们关注 Basestore 下的构造，其中辨别了两个目录空间：
- hive location: Hive 表（或分区）的目录空间，会记录在 Hive Meta Store 中，用原生的 Hive reader 会读到这部分数据。
- iceberg location: 存储近实时写入数据的目录空间，用 Iceberg 治理，蕴含 insert file 与 delete file，原生的 Hive reader 无奈读取到其中的数据，Arctic reader 能读取到。
两个目录空间的设计保障了反对 Arctic 残缺个性的根底之上依然兼容 Hive 原生读取。
Hive 数据同步
Hive location 的划分实现了 Arctic 写入数据对 Hive 查问引擎读的兼容，然而通过 Hive 查问引擎写入的数据或者 schema 变更却无奈让 Arctic 立刻辨认，为此 Arctic 引入了 Hive Syncer 用于辨认通过 Hive 查问引擎对表构造和数据的变更。Hive Syncer 包含 2 个指标：
- Hive 表构造变更同步到 Arctic
- Hive 表数据变更同步到 Arctic
_Table Metadata Sync_Hive
表构造信息的同步是通过比照 Arctic Table Schema 和 Hive Table Schema 的差别实现的，因为比照代价较小，Arctic 采取的形式是在所有的读取 / 写入 /schema 查问 / 变更 执行前都会执行 Metadata Sync 操作。通过对 Schema 的比照，Arctic 能够自动识别在 Hive 表上的 DDL 变更。Hive Schema 的同步能力使得 Arctic 的数据开发能够持续复用 Hive 生态下的数据建模工具，数据开发只须要如同对 Hive 表建模一样即可实现对 Arctic 表的建模。
_Table Data Sync_Hive
表数据的变更的查看是通过分区下的 transient_lastDdlTime 字段辨认的，读取 Hive 分区下数据时会比照分区的批改工夫是否和 Arctic 的 metadata 中记录是否统一，如果不统一就通过 HDFS 的 listDir 接口获取分区下的全副文件，并比照 Arctic 表最新 snapshot 对应的文件，如果文件列表有差别，阐明有通过非 Arctic 的路径对 Hive 表的数据进行了批改，此时 Arctic 会生成一个新的快照，对 Arctic 表的文件信息进行修改。因为 HDFS 的 listDir 操作是一个比拟重的操作，默认状况下是通过 AMS 定时触发 DataSync 查看，如果对数据一致性要求更高，能够通过参数 base.hive.auto-sync-data-write 配置为每次查问前进行 Data Sync 查看。Hive 数据同步的能力使得用户从离线开发链路迁徙到实时开发链接的过程中保留离线数据开发的逻辑，通过离线实现对实时的数据修改，并且保障了实时和离线建模的对立以及指标的对立。
存量 Hive 表原地降级
Arctic 不仅反对创立 Hive 兼容表，还反对间接将曾经存在的 Hive 表降级为一张 Arctic 下的 Hive 兼容表。在 AMS 上导入 HMS 对应的 hive-site.xml 即可看到 HMS 上对应的表，在对应的 Hive 表上点击 Upgrade 按钮即可对 Hive 表进行原地降级。
Arctic 还反对在进行原地降级时指定主键，这样能够将 Hive 表降级为有主键的 Arctic 表。
Hive 的原地降级操作是十分轻量级的，在执行 Upgrade 操作的背地，AMS 仅仅是新建一个空的 Arctic Table，而后扫描 Hive 目录，并创立一个包含所有 Hive 下的 Parquet 文件的 Snapshot 即可，整个过程并不波及到数据文件的复制和重写。
兼容 Hive 表的权限治理
围绕着 Hive 曾经有了一套残缺的大数据生态，其中对于表的权限治理和数据脱敏极为重要，以后 Arctic 的 Hive 兼容表曾经适配了 incubator-kyuubi 我的项目下的 spark-auth 插件 https://github.com/apache/incubator-kyuubi 通过该插件 Arctic 实现了对 Ranger 的适配，在理论利用中，通过 Ranger 对 Arctic 对应的 Hive 进行受权，在 SparkJob 中即可实现对 Arctic 表的鉴权。
基于 Hive 的流批一体实际
Arctic 的 Hive 兼容模式是为了帮忙适应了 Hive 的用户疾速上手 Arctic，对于 Hive 用户来说，如果满足以下其中一点：
1. 有大量的存量 Hive 表，并且其中局部 Hive 表有流式写入、订阅的需要
2. 在离线场景下有成熟的产品构建，并且心愿为离线赋予局部实时的能力，然而又不想对离线平台做过多的革新
即可尝试通过 Arctic Hive 兼容表解决你的痛点。
实际案例：网易云音乐特色生产工程实时化
网易云音乐的举荐业务围绕着 Spark+Hive 曾经构建了一套成熟的大数据 +AI 开发体系，随着业务的增长，业务对整套零碎的实时性要求在一直加强，然而间接通过 Flink + Kafka 构建的实时链路并不够欠缺。在离线链路中围绕着 Hive 有着欠缺的基础设施和方法论，数据开发和算法工程师通过模型设计核心实现表的设计，数据开发负责数据的摄取，荡涤，打宽，聚合等根底解决，算法工程师负责在 DWS 层的数据上实现特色生产算法，分析师通过对 ODS 层、DWD 层以及 DWS 层的表执行 Ad Hoc 式的查问并构建剖析报表以评估特色数据品质。整套链路层次分明、分工清晰，即最大限度的复用了计算结果，又比拟好的对立了指标口径，是典型的 T+1 的数仓建设。然而在实时链路中，数据开发仅仅帮助实现原始数据到 Kafka 的摄取，算法工程师须要从 ODS 层数据进行加工，整个链路不足数据分层，既不能复用离线计算结果，也无奈保障指标的一致性。
整个特色工程的生产路线的现状如下图所示：
因为存在大量的存量 Hive 表，并且还有来自 Presto 和 Impala 的查问链路须要复用 ODS 和 DWD 层的 Hive 表，整个特色工程想间接应用 Iceberg 或 Hudi 这样的零碎其切换代价还是很大的，零碎切换期间对系统整体 SLA 要求较高，新零碎磨合过程中如果造成数据产出提早，对于业务来说是不可承受的。最终咱们采纳了 Arctic Hive 兼容表的模式，分阶段的将 Hive 表降级为 Arctic 下的 Hive 兼容表，降级后的数据生产链路如下图所示：
降级后 Arctic 为整个特色工程带来了以下益处：
1. Arctic 以无感知的形式实现了约 2PB 级别的 Hive 表实时化，因为做到 Hive 的读写兼容，自身 T+1 的全量数据回补以及分析师的报表查问 SQL 不必做任何批改，降级过程中保障了不影响离线链路开发。
2. 实时特色的生产复用了数仓 DWS 层数据，不须要从 ODS 层间接构建特色算法，而数仓的荡涤、聚合均由数据开发实现，晋升了算法工程师的人效，使得算法工程师能够更好的专一于特色算法自身。均匀下来每个算法节俭人效约 1 天。
3. 实现了实时链路和离线链路的对立，在数据血统，数据指标，模型设计上能够做到更好的数据治理。
4. Arctic 自身能够为 ODS 和 DWD 层的表配置更激进的 Optimize 策略，以 10 分钟的频率对 Hive Table 的数据进行 Overwrite, 分析师能够享受到更加实时的剖析报表。
总结
本文介绍了网易数帆开源的新一代流式湖仓 Arctic 以及其基于 Hive 的流批一体实际。心愿读者能够经此文章理解 Arctic 并对业务构建流批一体的数据湖有帮忙。感激始终一来对 Arctic 社区的反对，如果您对 Arctic、湖仓一体、流批一体感兴趣，并想一起推动它的倒退，请在 Github 上关注 Arctic 我的项目 https://github.com/NetEase/arctic。也欢送退出 Arctic 交换群：微信增加“kllnn999”为好友，注明“Arctic 交换”。
理解更多
万字长文详解开源流式湖仓服务 Arctic
从 Delta 2.0 开始聊聊咱们须要怎么的数据湖
走向现代化数据分析架构：趋势与挑战
作者简介：
张永翔，网易数帆资深平台开发工程师，Arctic Committer，6 年从业教训，先后从事网易 RDS、数据中台、实时计算平台等开发，目前次要负责 Arctic 流式湖仓服务开发。
胡溢胜，网易云音乐数据专家，10 年数仓教训，波及通信、互联网、环保、医疗等行业。2020 年退出网易云音乐，目前负责网易云音乐社交直播业务线的数据建设。
