此博客是我们的Admin Essentials系列的第二部分，我们将重点关注对管理和维护 Databricks 环境的人来说很重要的主题。在本系列中，我们将分享工作空间管理、数据治理、运营和自动化以及成本跟踪和退款等主题的最佳实践- 敬请关注更多博客！
自从我们上次在 2020 年 6 月发布关于审计日志的博客以来，Databricks Lakehouse 平台已经取得了长足的进步。我们创造了世界纪录，收购了公司，并推出了新产品，将湖屋架构的优势带给数据分析师和公民数据科学家等全新受众。世界也发生了巨大的变化。我们中的许多人大部分时间都在远程工作，而远程工作对可接受的使用政策以及我们如何衡量它们是否被遵循带来了更大的压力。
因此，我们认为现在是重新审视Databricks Lakehouse Platform审计日志主题的好时机。在此博客中，我们将为您的 Lakehouse 上发生的所有重要事件提供最新的最佳实践建议以及可用的最新功能 - 允许您将表盘从回顾性分析转移到主动监控和警报：
帐户级审计日志
使用 Unity Catalog 进行集中治理 使用
Delta Live Tables
轻松可靠地处理审计日志 使用 Databricks 轻松查询 SQL 使用 Databricks
轻松可视化 SQL 使用 Databricks
自动警报 SQL
信任，但通过 360 度可见性验证 Lakehouse
最佳实践综述
结论
帐户级别审核日志记录
出于多种原因，审核日志至关重要 - 从合规性到成本控制。它们是您对湖屋中发生的事情的权威记录。但在过去，平台管理员必须为每个工作区单独配置审计日志，导致开销增加，并且由于创建的工作区未启用审计日志而导致组织盲点的风险。
现在，客户可以利用单个 Databricks 帐户来管理他们的所有用户、组、工作区，您猜对了 - 审计日志 - 从一个地方集中管理。这使平台管理员的工作变得更加简单，从安全角度来看，风险也大大降低。一旦客户在帐户级别配置了审计日志记录，他们就可以安然入睡，因为他们知道我们将继续为他们的 Lakehouse 上发生的所有重要事件提供低延迟流 - 对于在该帐户下创建的所有新工作区和现有工作区。
立即查看文档（AWS、GCP）为您的 Databricks Lakehouse 平台设置账户级审计日志。
使用Unity Catalog进行集中治理
Unity Catalog (UC) 是世界上第一个用于跨云的所有数据和 AI 产品的细粒度和集中式治理层。将集中式治理层与全面的审计日志相结合，您可以回答以下问题：
- 我的组织中最受欢迎的数据资产是什么？
- 谁试图未经授权访问我的数据产品，他们试图运行什么查询？
- 我的 Delta 股票是否仅限于受信任的网络？
- 我的达美股票是从哪些国家/地区访问的？
- 我的达美股票从美国哪些州被访问？
- 从哪些位置访问我的Delta 股票？
已经在 UC 预览版中的客户可以通过在审核日志中搜索事件 WHERE serviceName == “unityCatalog” 或查看提供的存储库中的示例查询来查看其外观。如果您正在为您的 Lakehouse 寻找这些功能，请在此处注册！
使用Delta Live Tables轻松可靠地处理审计日志
我们一遍又一遍地看到成功客户的一个标志是，那些将数据质量作为第一要务的人比那些不关注数据质量的人发展得更快。从历史上看，这说起来容易做起来难。已经不得不花太多时间担心基础设施规模、管理和扩展等事情的工程师现在需要花时间将他们的代码与开源或第三方数据质量和测试框架集成。更重要的是，这些框架通常难以扩展到海量数据，这使得它们对离散集成测试很有用，但是当工程师想要验证具有代表性的性能测试的结果时，他们又会感到头疼。
输入 Delta Live Tables (DLT)。借助 DLT，工程师能够将他们的数据视为代码并利用内置的数据质量控制，因此他们原本必须花费在上述任务上的时间和精力可以转而用于更具生产力的活动——例如确保质量差的数据永远不会接近企业的关键决策过程。
由于处理审计日志的 ETL 管道将从 DLT 提供的可靠性、可扩展性和内置数据质量控制中受益匪浅，因此我们将 ETL 管道作为我们之前博客的一部分共享，并将其转换为DLT。
此 DLT 管道使用 Autoloader 读取包含您的审计日志的 JSON 文件，这是一种简单且可轻松扩展的解决方案，用于将数据摄取到您的 Lakehouse（请参阅 AWS、Azure、GCP 的文档）。然后，它为帐户和工作区级别的操作分别创建一个青铜表和白银表，转换数据并使其在每一步都更易于使用。最后，它为每个 Databricks 服务创建一个黄金表（请参阅AWS、Azure、GCP的文档）
银表允许您对所有 Databricks 服务执行详细分析，例如调查特定用户在整个Databricks Lakehouse 平台上的操作。同时，黄金表允许您执行与特定服务相关的更快查询。当您要配置与特定操作相关的警报时，这特别有用。
以下示例适用于 AWS 和 GCP 上的客户。对于已将诊断日志设置为传送到 Azure 存储帐户的 Azure Databricks 客户，可能需要进行细微调整。原因是Azure 上的诊断日志架构与AWS和GCP上的略有不同。
要在您的环境中运行新的 DLT 管道，请使用以下步骤：
1.使用 Git 集成的存储库克隆Github 存储库（请参阅AWS、Azure、GCP的文档）。
2.创建一个新的 DLT 管道，链接到dlt_audit_logs.py笔记本（请参阅AWS、Azure、GCP的文档）。您需要输入以下配置选项：
a.INPUT_PATH：您为审计日志传递配置的云存储路径。这通常是一个受保护的存储帐户，不会向您的 Databricks 用户公开。
b.OUTPUT_PATH：要用于审核日志 Delta Lakes 的云存储路径。这通常是一个受保护的存储帐户，不会向您的 Databricks 用户公开。
c.CONFIG_FILE：在您的存储库中签出后的audit_logs.json文件的路径。
3.注意：编辑可通过 UI 配置的设置后，您需要编辑 JSON，以便将使用 INPUT_PATH 和 OUTPUT_PATH 进行身份验证所需的配置添加到集群对象
a.对于 AWS，将 instance_profile_arn 添加到 aws_attributes 对象。
b.对于 Azure，将服务主体机密添加到 spark_conf 对象。
c.对于 GCP，将 google_service_account 添加到 gcp_attributes 对象。
4.现在您应该准备好配置管道以根据适当的计划和触发器运行。成功运行后，您应该会看到如下内容：
您应该注意以下几点：
1.管道根据上面引用的CONFIG_FILE的可配置日志级别和服务名称列表处理数据。
2.默认情况下，日志级别为 ACCOUNT_LEVEL 和 WORKSPACE_LEVEL。目前，这些是我们在 Databricks 使用的唯一审计级别，但不能保证我们将来不会添加额外的日志级别。值得定期检查审计日志架构，以确保您不会因为添加了新的审计级别而丢失任何日志（请参阅AWS、Azure、GCP的文档）。
3.随着我们向平台添加新功能和服务，服务名称可能会发生变化。它们还可能因您是否利用PCI-DSS 合规性控制或增强安全模式等功能而有所不同。您可以定期检查我们的公共文档（AWS、Azure、GCP）上的服务名称列表，但由于这种可能性更大，我们还在 DLT 管道中添加了一种检测模式，让您了解是否引入了新服务进入你不期望的日志，因此摄入你的湖屋。继续阅读以了解有关我们如何使用 Delta Live Tables 中的期望来检测此类潜在数据质量问题的更多信息。
期望通过验证和完整性检查防止不良数据流入表，并通过预定义的错误策略（失败、丢弃、警报或隔离数据）避免数据质量错误。
在dlt_audit_logs.py笔记本中，您会注意到我们为每个表包含以下装饰器：
@dlt.expect_all({})
这就是我们为 Delta Live Tables 设置数据预期的方式。您还会注意到，对于青铜表，我们设置了一个名为 unexpected_service_names 的期望，其中我们将 serviceName 列中包含的传入值与我们的可配置列表进行比较。如果在我们未在此处跟踪的数据中检测到新的 serviceNames，我们将能够看到此预期失败并知道我们可能需要将新的或未跟踪的 serviceNames 添加到我们的配置中：
要了解有关预期的更多信息，请查看我们的AWS、Azure和GCP文档。
在 Databricks，我们相信Delta Live Tables是 ETL 的未来。如果您喜欢所见并想了解更多信息，请查看我们的入门指南！
使用Databricks SQL轻松查询
既然您已将审计日志整理到青铜、白银和黄金表中，Databricks SQL让您可以以超高的性价比查询它们。如果您导航到数据资源管理器（请参阅AWS、Azure的文档），您将在上述 DLT 配置中指定的目标数据库中找到青铜、白银和黄金表。
这里的潜在用例可能是任何事情，从对潜在滥用的临时调查到找出谁在创建超出预算的巨大 GPU 集群。
为了帮助您入门，我们提供了一系列示例帐户和工作区级别的 SQL 查询，涵盖您可能特别关心的服务和场景。克隆存储库时，您会发现这些已作为 SQL 笔记本签出，但您只需复制并粘贴 SQL 即可在 Databricks SQL 中运行它们。请注意，查询假定您的数据库名为 audit_logs。如果您在上面的 DLT 配置中选择将其命名为其他名称，只需将 audit_logs 替换为您的数据库名称即可。
使用Databricks SQL轻松实现可视化
除了通过一流的 SQL 体验和闪电般的快速查询引擎查询数据外，Databricks SQL 还允许您使用直观的拖放界面快速构建仪表板，然后与关键利益相关者共享它们。更重要的是，它们可以设置为自动刷新，确保您的决策者始终可以访问最新数据。
很难抢占您可能希望在此处向主要利益相关者展示的所有内容，但希望此处展示的SQL 查询和相关的可视化可以让您对可能的情况有所了解：
我的达美股票是从哪些国家/地区访问的？
我的工作有多可靠？
随着时间的推移失败的登录尝试
登录尝试失败的峰值可能表明暴力攻击，应监控趋势。例如，在下面的图表中，每月的定期峰值可能是 30 天密码轮换政策的征兆，但 1 月份某个特定用户的巨大峰值看起来很可疑。
除了 repo 中提供 的示例 SQL 查询之外，您还可以找到用于构建这些可视化的所有 SQL 查询以及更多其他查询。
使用Databricks SQL自动发出警报
与任何平台一样，有些事件您会比其他事件更关心，有些事件您非常关心，以至于您希望在它们发生时主动得到通知。好消息是，您可以轻松配置 Databricks SQL 警报，以便在计划的 SQL 查询返回对这些事件之一的命中时通知您。您甚至可以对我们之前向您展示的示例 SQL 查询进行一些简单的更改以开始使用：
- 更新查询以使其具有时间限制（即通过添加时间戳 >= current_date() - 1）
- 更新查询以返回您不希望看到的事件计数（即通过添加 COUNT(*) 和适当的 WHERE 子句）
- 现在您可以将警报配置为每天运行并在事件计数 > 0 时触发
- 对于基于条件逻辑的更复杂的警报，请考虑使用 CASE 语句（请参阅AWS、Azure的文档）
例如，以下 SQL 查询可用于随时发出警报：
1、最近一天工作空间配置有变化：
SELECT
requestParams.workspaceConfKeys,
requestParams.workspaceConfValues,
email,
COUNT(*) AS total
FROM
audit_logs.gold_workspace_workspace
WHERE
actionName = 'workspaceConfEdit'
AND timestamp >= current_date() - 1
GROUP BY
1, 2, 3
ORDER BY total DESC
- 已经下载了可能包含最后一天工作区数据的工件：
WITH downloads_last_day AS (
SELECT
timestamp,
email,
serviceName,
actionName
FROM
audit_logs.gold_workspace_notebook
WHERE
actionName IN ("downloadPreviewResults", "downloadLargeResults")
UNION ALL
SELECT
timestamp,
email,
serviceName,
actionName
FROM
audit_logs.gold_workspace_databrickssql
WHERE
actionName IN ("downloadQueryResult")
UNION ALL
SELECT
timestamp,
email,
serviceName,
actionName
FROM
audit_logs.gold_workspace_workspace
WHERE
actionName IN ("workspaceExport")
AND requestParams.workspaceExportFormat != "SOURCE"
ORDER BY
timestamp DESC
)
SELECT
DATE(timestamp) AS date,
email,
serviceName,
actionName,
count(*) AS total
FROM
downloads_last_day
WHERE timestamp >= current_date() - 1
GROUP BY
1,
2,
3,
4
这些可以与如下所示的自定义警报模板相结合，为平台管理员提供足够的信息来调查是否违反了可接受的使用政策：
Alert "{{ALERT_NAME}}" changed status to {{ALERT_STATUS}}
最后一天发生了以下意外事件：
{{QUERY_RESULT_ROWS}}
查看我们的文档以获取有关如何配置警报（AWS、Azure）以及添加其他警报目的地（如 Slack 或 PagerDuty（AWS、Azure））的说明。
信任但通过 360 度全方位了解您的 Lakehouse 进行验证
Databricks 审核日志提供对您的 Lakehouse 执行的操作的全面记录。但是，如果您不使用Unity Catalog（相信我，如果您不使用，那么您应该使用），那么您最关心的一些交互可能只会在底层云提供商日志中捕获。一个示例可能是对您的数据的访问，如果您使用云原生访问控制，则只能在存储访问日志允许的粗粒度级别上真正捕获。
根据我们之前关于该主题的博客，出于这个原因（以及其他原因），您可能还希望将 Databricks 审计日志与从底层云提供商捕获的各种日志记录和监控输出相结合。虽然上一篇博客中的建议仍然适用，但请继续关注未来的修订版，包括用于这些工作负载的 DLT 管道！
最佳实践综述
总而言之，这里有 5 个针对管理员的日志记录和监控最佳实践，我们在整篇文章中都谈到了：
1.在帐户级别启用审核日志记录。从您的 Lakehouse 旅程一开始就具有可审计性，可以让您建立历史基线。通常，您只有在真正需要审计日志时才意识到自己需要多少审计日志。相信我，拥有这个历史基线比从这个错误中吸取教训要好。
2.采用 Unity 目录。启用跨云和跨工作空间分析为 Lakehouse 带来了新的治理和控制水平。
3.自动化您的日志记录管道 - 最好使用 DLT。这可以确保您在不需要大量复杂代码的情况下强制执行数据卫生和及时性，甚至可以让您设置简单的通知和警报（如果（以及何时）发生故障或更改）。
4.为您的日志数据使用奖章架构。这确保了一旦您的管道为您带来了高质量、及时的数据，它就不会被转储到没有人可以找到的数据库中——并且使用 Databricks SQL 查询变得非常容易！
5.使用 Databricks SQL 为您真正关心的事件设置自动警报
6.将您的 Databricks 审核日志合并到更广泛的日志记录生态系统中。这可能包括云提供商日志，以及来自您的身份提供商或其他第三方应用程序的日志。在当今动荡的安全环境中，创建 Lakehouse 上正在发生的事情的 360 度视图尤其重要！
结论
自上一篇关于审计日志的博客以来的两年中，Databricks Lakehouse 平台和世界都发生了巨大变化。在那段时间里，我们大多数人一直在远程工作，但远程工作对可接受的使用政策以及我们如何衡量它们是否被遵循带来了更大的压力和审查。幸运的是，Databricks Lakehouse 平台已经（并将继续取得）巨大的进步，使数据团队更容易管理这个问题。
原文标题：Monitoring Your Databricks Lakehouse Platform with Audit Logs
原文作者：Andrew Weaver and Silvio Fiorito
原文地址：https://www.databricks.com/blog/2022/05/02/monitoring-your-databricks-lakehouse-platform-with-audit-logs.html
