Apache Iceberg 对数据安全的商业化思考和方案
01 背景
曾经有位牛逼的大数据从业者说过，数据安全的问题是 now or never。
作为一个技术老兵，我坚信技术可以改变一切，但实践告诉我，如果把数据安全当做一个事后的工作，或者当成一个可插拔的上层组件，其通用性，可靠性，最终落地的推广程度都会受到极大挑战，对于一个数据系统而言，安全确实是一开始就应该考虑的问题。
当前主流数据平台的安全解决方案是借助开源项目 Ranger，为数据平台构筑符合企业安全需求的角色和权限体系，比如网易有数在 Ranger 上的实践已经有近 6-8 年的时间，从实践上看，Apache Ranger 与大数据其他项目高度解耦，定制化自由度高，但同时也给产品设计和适配带来了相当的工作量，由于 Ranger 与大数据引擎解耦的特性，如果引擎层未适配 Ranger，使用上可以绕够整个安全体系，有巨大隐患，下文中会具体分析造成这个问题的原因。另一方面，在上云成为企业发展重要趋势的大背景下，各种大数据平台基于 Hadoop 和 Ranger 体系构建的安全体系可能会遇到各种水土不服的问题，客观上需要一套更通用和标准的安全解决方案。
Tabular 作为 Apache Iceberg 的商业化项目，依托于 Iceberg 开源社区应用场景和解决方案有非常深入和独到的见解，这篇文章前半部分主要引自 Tabular 联合创始人 Jason Reid 在 Tabular 官博中发布的两篇文章[1][2]，后半部分则是我个人的一些理解和观点。
02 Tabular 是什么
Tabular 是什么，官方给了很多解释[3]。
从我的视角看，Tabular 是 Apache Iceberg 核心团队依托于 Iceberg 构建的元数据中心，安全中心，数据优化中心，将这些能力打包在一起构建的 SAAS 服务。
Tabular 的本质是一个 Catalog service，所有计算引擎都需要通过 Catalog 访问元数据，因此可以成为元数据中心，每次加载表都需要通过 Catalog service，因此可以实现访问控制，因为 Catalog service 记录了所有表的元数据及其变化，因此知道什么时候需要优化数据。
03 Hadoop 安全架构
Tabular 安全架构基本原则：保护数据而非访问方式。
这个道理似乎显而易见，但这却不是大多数数据平台今天的工作方式。相反，基于 Apache Ranger 典型的模式是独立保护每种访问方法。
我们授予计算引擎（例如 Hive 或 Spark）对底层存储的完全访问权限，然后使用 Apache Ranger 的策略来授权 Hive 查询所需的数据访问。Ranger 存储访问策略，但计算引擎必须在运行时支持与 Ranger 进行检查以执行这些策略，这就是我们俗称的引擎对鉴权的支持：
这种方法的主要问题是，对于每个需要访问数据的新计算引擎，我们必须重复这种模式。但每个系统都会暴露略微不同的权限集，并且每个系统都有其自己的定义和管理访问的方式。
例如，Ranger 具有独特的资源类型和权限集，并且仅适用于基于 Hadoop 的工具。存储在 S3 或其他对象存储中的数据没有支持。这使我们处于一个艰难状态：多个计算环境广泛访问我们的数据，我们必须尝试在这些系统之间同步访问策略。
对于像 Spark 或 Python 这样没有内置访问控制的环境来说问题更多，如果环境本身具有完全访问权限，那么没有真正的方法来限制个别用户可以或不可以与哪些数据进行交互：
计算机引擎对 Ranger 是否适配决定了产品层面是否具备数据安全的特性，从多年从业经验看，绝大多数企业的 Flink 引擎因为各种原因鲜有支持 Ranger 鉴权的功能，那么 Flink 的用户就可以绕过 Ranger 直接访问底层的数据。当然除了 Ranger 以外，还有 kerberos 兜底，可以在 HDFS 层面拒绝没有身份的访问，但是角色和权限的缺失，以及粗粒度的访问控制依然让实时计算的数据治理难以控制。
04 Tabular 安全架构
还是回到那个原则：保护数据而非访问方式。
Tabular 要求在存储层的一个地方管理和执行访问策略。默认情况下，不授予对计算环境的广泛访问权限，而是授予零访问权限。
在这种设置中，所有的读和写操作必须通过一个单一的、一致的访问控制系统进行授权。这种设计适用于 SQL 引擎（如 Trino）、开放计算环境（如 Spark），甚至是用户本地机器上的 Python 直接访问。
从第一天开始，Tabular 作为 Iceberg 表的安全存储层，提供 SELECT、UPDATE、DROP 等用户所期望像所有数据库一样的标准 SQL 访问控制。无论是 Trino 集群的 OLAP 查询还是定期的 Spark ETL 作业，每个对 Tabular 表的访问都必须得到授权。授权机制是通过在目录和文件访问级别应用授权决策来实现，就像操作系统在任何应用程序尝试在本地文件系统中读取或写入文件时所做的那样：
在上面的例子中，用户试图访问存储在 S3 桶中的 Iceberg 表。
在尝试从表中读取文件时，Spark 首先将用户标识、表标识符和文件标识符传递给 Tabular 授权服务。
Tabular 检查当前授权用户的角色，并根据配置的访问策略确定是否应该授权数据访问权限。
如果是，则返回一个授权的文件访问请求给 Spark。
然后，Spark 使用授权的文件访问请求从 S3 检索文件。
如果没有授权的访问请求，Spark 就不能直接访问 S3 上的表文件。这个模式意味着数据所有者可以轻松地管理谁可以访问哪些数据，而不必担心消费者可能选择使用那种计算引擎或工具。相同的表可以安全地使用 Spark 进行 ML 的数据科学家或使用 BI 工具的业务团队共享。
事实上，这个模式还可以用于跨组织安全地共享数据，就像它可以用于跨团队协作一样简单。Tabular 利用这一功能让客户之间可以贡献 Iceberg 表，Iceberg 表能够包含数据仓库中发生的一切信息，包括对授权决策的审计。
05 PoLP 应用实践
数据安全核心实践：人们只能访问他们需要执行工作的数据，这通常被称为最小权限原则（PoLP）。
为了说明这一点，让我看一个真实的例子。分析工程师 Alex 有一个 Spark 的 ETL 作业，用于填充公司的客户表。Alex 经常被要求对客户数据进行即席分析，以帮助产品团队更好地了解客户行为。在这种情况，Alex 需要在运行 ETL 作业时对“客户”表进行读写访问，并在使用 Trino 进行即席分析时对“客户”和“收入”表进行只读访问：
为了将 PoLP 原则应用到数据中，解决方案的一个关键组成部分是身份认证。如果在进行授权决策时，我们不知道是谁（或什么）在发出请求，那么所有的访问策略都不会起作用。
在我们的例子中，我们需要知道 ETL 作业和 Trino 查询是由 Alex 运行的，并且应该具有他的访问权限。对于组织中的其他人，即使他们正在使用共享的计算集群，也需要做出类似的独立决策。
这一直是一个棘手的问题。即使有一套基于 Apache Ranger 的安全体系，通常的实践中也很难有效执行最小权限访问原则，因为很难为所有授权决策提供准确的用户身份认证。
最小权限访问取决于知道谁或什么正在请求该访问。我们需要有一个一致地执行的策略集来应用于我们的数据，这意味着我们需要一个一致的身份、用户和服务集合作为该策略的一部分。
我们需要简单、一致的机制，让数据架构中的所有组件都可以安全地共享用户身份上下文作为所有数据访问请求的一部分，一直到存储层。这也要求我们的身份认证概念是灵活的，例如可以代表运行即席查询的用户以及预定的 ETL 作业。
06 Tabular 身份机制
Tabular 提供了三种身份策略来应对不同的数据安全场景。
1. 基于 Key 的认证
为数据访问决策提供身份认证的最简单方法是让用户直接提供用户凭据，类似于 API 密钥。例如，在配置 Tabular 的 Iceberg 目录时，可以将该凭据作为 Spark 或 Flink 会话的一部分提供。会话期间执行的所以读写操作都受限于用户的数据访问策略。这可以是他们桌面上的 Spark shell 或提交到共享集群的作业。
2. 授信的身份认证
在许多分布式计算环境中，用户是由受信任的身份提供进行身份验证的。在这些情况下，Tabular 使得受信任的基础设施能够传递已认证的用户身份以及验证机制，以换取用于数据授权决策的安全令牌。这是从诸如 Trino 到 Tabular 传递身份的绝佳选择。
3. 基于 AWS 的 IAM Role
对于许多 AWS 环境，将权限授予分配给特点计算实例的 IAM 角色是一种常见的最佳实践。Tabular 使得 IAM 角色可以映射到 Tabular 的基于角色的访问控制系统中定义的数据访问角色。这使得管理在 AWS 中运行的计划作业或进程的数据访问策略变得简单。
06 Tabular vs UnityCatalog
相比于 Databricks 和 Snowflake，当前的 Tabular 可能连后起之秀都还算不上。
但这并不影响对手们的重视，Delta 3.0 中公布了一项有意思的功能叫 Universal format，官方的描述是[4]：
Universal format(Uniform) allows data stored in Delta to be read from as if it were Apache Iceberg or Apache Hudi. UniForm takes the guesswork out of choosing an open data format and eliminates compatibility headaches by offering automatic support for Iceberg and Hudi within Delta Lake.
而 Iceberg 在 Tabular 的官方博客中也郑重地宣布了这件事情[5]：
Databricks announced future support for Iceberg as a compatibility layer –tacitly acknowledging the momentum Iceberg is gaining in the larger marketplace.
然后在 Databricks 的 meetup 中，Databricks 的工程师揶揄地说道，Delta 兼容 Iceberg 的 format，用起来比 Iceberg 自身还快 30%，有点惺惺相惜又相爱相杀的味道了。
所以抛开 Tabular 的商业成熟度不谈，在开源领域 Iceberg 绝对是可以和 Delta 掰掰手腕的存在，叠加 Apache 的 buf，在开源领域还隐隐有胜出的趋势，过去我们讲过，Delta 和 Iceberg 在功能上的趋同，意味着数据湖 format 标准的逐步确立，而 Delta 和 Iceberg 背后的商业化产品，即 UnityCatalog 和 Tabular，则很大程度引领了对这类数据湖 format 的最佳实践。
回到这篇文章的主题：数据安全。
无论是 Tabular 还是 Databricks UnityCatalog，都使用 Catalog service 作为数据安全的解决方案，在这个领域，UnityCatalog 更早，更成熟，也更加标杆，Databricks 为 UnityCatalog 定义了一套完整的 DSL（Domain Specific Language）来灵活定义角色和权限，下面的 SQL 佐证这一点[6]：
CREATE VIEW < catalog_name >.< schema_name >.< view_name > asSELECT id, CASE WHEN is_account_group_member(< group_name >) THEN email ELSE 'REDACTED' END AS email, country, product, totalFROM < catalog_name >.< schema_name >.< table_name >;GRANT USE CATALOG ON CATALOG < catalog_name > TO < group_name >;GRANT USE SCHEMA ON SCHEMA < catalog_name >.< schema_name >.< view_name >;TO < group_name >;GRANTSELECT ON < catalog_name >.< schema_name >.< view_name >;TO < group_name >;为什么 Catalog service 适合作为数据安全的解决方案，上文 Jason 已经做了清晰地阐述，当然我们也需要看到这类方案在兼容性上存在的不足：如果你使用 Spark2 这类不支持 Catalog 的引擎版本，那自然无法通过 Catalog service 来实现数据权限。
UnityCatalog 和 Tabular 都使用 Catalog service 来实现数据安全，偶然中存在必然，对大数据平台开发者，数据开发者而言，数据安全封装在了一个独立的领域中，基础功能下沉，简化了数据安全架构，解放了数据平台复杂度，便于迁移和维护，是一举多得的事。
不光是数据安全，在 Arctic 过去小一年的开源实践中，我们发现 Catalog service 作为计算引擎的收敛中心，还可以做很多事，很多企业可能搭建了自己的 catalog service 来存储平台必要的元数据，但很少有人把它当做一个基础设施来看待，久而久之这个系统可能会承载很多不必要的功能，无法抽象出一个高度精练的领域。在这个项目的实践过程中，我们一直在尝试回答这样的问题：企业究竟需要怎样的数据湖？这个问题的答案可能还需要持续迭代，从我们自身实践出发，再去看 Databricks、Tabular 这些行业大佬的解决方案，我们认为一个高度抽象的 Catalog service 能够给湖仓一体的实践带来更多的价值，比如我们去看 UnityCatalog，可能比行业内任何数据治理和数据安全的方案都要精致和高效。
目前 Tabular 只支持在页面上对权限进行配置，我们会持续关注后续 Tabular 提供的更多功能。
07 总结
本文主要阐述了 Apache Iceberg 背后的商业化公司 Tabular 在大数据安全领域的思考和方案，从行业当前主流的 Ranger 架构存在的痛点开始， Ranger 是一个与大数据基础设施解耦的组件，非常方便使用，Ranger 包含了授权和鉴权两部分，授权通过 Ranger service 配套的工具完成，鉴权则需要每个访问数据的引擎分别去接入和适配，这会带来两个问题：
一是没有接入 Ranger 的引擎读写数据无异于裸奔，没有安全可言，比如很多企业的实时计算平台，目前还没有接入到 Ranger，那 Flink 读写数据湖的数据就面临一定的安全威胁。
Ranger 是一个开源生态组件，对公有云数据湖并没有很好的适配，这种安全方案一般需要专业的基础设施服务商提供，对大数据平台而言，基于 Ranger 的安全架构在日后上云的挑战中可能面临更多适配工作。
Tabular 为此提供了一个更加通用的架构和服务，将授权，鉴权，catalog service 整合为一个 tabular 服务。在当前主流的计算引擎中，都面向 catalog 来接入和管理元数据，catalog 成为了所有计算引擎的公共入口，这个入口为数据鉴权提供了完美的卡点位置，所以将 catalog service 和数据安全结合起来考虑是非常合理的考量。
其实在 Tabular 之前，Databricks 的 UnityCatalog 就已经为行业指明了这个方向，catalog service 不光能够成为数据安全的基础设施，同时也可以为组织之间共享数据提供依据，这也是 UnitiyCatalog 和 Tabular 在商业化故事中的一个重点功能。我们进一步举一反三，catalog service 作为所有计算引擎统一入口，还能为大数据的上层建筑提供数据治理的底层原语，比如小文件合并，快照管理，layout 优化，让数据产品更加关注业务治理。catalog service 可以为大数据百花齐放野蛮奔跑的生态，带来收敛的可能，以基础软件的方式和标准化的接口，为数据平台，数据产品提供湖原生基础架构的底座，这便是我们在做的开源项目 Arctic 未来长期的定位。
Reference
[1] https://tabular.io/blog/securing-the-data-lake-part-1/
[2] https://tabular.io/blog/securing-the-data-lake-part-2/
[3] https://tabular.io/product/
[4] https://www.databricks.com/company/newsroom/press-releases/announcing-delta-lake-30-new-universal-format-offers-automatic
[5] https://tabular.io/blog/iceberg-in-modern-data-architecture/
[6] https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/best-practices
END
看到这里 记得关注、点赞、转发 一键三连哦~
精彩回顾：
企查查基于 Apache Iceberg 与 Arctic 构建实时湖仓实践
手把手教你使用 Arctic 自动优化 Apache Iceberg
关于 Arctic 的更多资讯可查看：
【GitHub】 地址：https://github.com/NetEase/arctic 【Arctic】 文档地址：https://arctic.netease.com/ch/
【社群】：后台回复【社群】添加小助手 （或扫描下方二维码↓，邀你进群）