如何让 MSCK REPAIR TABLE 在 AWS Athena 中自动执行

Question

我有一个每小时执行一次的 Spark 批处理作业。每次运行都会生成新数据并将其存储在 S3 中，目录命名模式为 DATA/YEAR=?/MONTH=?/DATE=?/datafile。

将数据上传到S3 后，我想使用Athena 进行调查。另外，我想通过连接到 Athena 作为数据源在 QuickSight 中可视化它们。

问题是每次运行我的 Spark 批处理后，Athena 不会发现存储在 S3 中的新生成的数据，除非我手动运行查询 MSCK REPAIR TABLE。

有没有办法让 Athena 自动更新数据，这样我就可以创建一个全自动的数据可视化管道？

Answer 1

有多种方法可以安排此任务。您如何安排工作流程？你是使用Airflow、Luigi、Azkaban、cron 之类的系统，还是使用AWS Data pipeline？

从其中任何一个中，您都应该能够触发以下 CLI 命令。

$ aws athena start-query-execution --query-string "MSCK REPAIR TABLE some_database.some_table" --result-configuration "OutputLocation=s3://SOMEPLACE"

另一个选项是AWS Lambda。您可以有一个函数调用MSCK REPAIR TABLE some_database.some_table 以响应新上传到 S3。

一个示例 Lambda 函数可以这样编写：

import boto3

def lambda_handler(event, context):
    bucket_name = 'some_bucket'

    client = boto3.client('athena')

    config = {
        'OutputLocation': 's3://' + bucket_name + '/',
        'EncryptionConfiguration': {'EncryptionOption': 'SSE_S3'}

    }

    # Query Execution Parameters
    sql = 'MSCK REPAIR TABLE some_database.some_table'
    context = {'Database': 'some_database'}

    client.start_query_execution(QueryString = sql, 
                                 QueryExecutionContext = context,
                                 ResultConfiguration = config)

然后，您将配置一个触发器以在您的存储桶中的 DATA/ 前缀下添加新数据时执行您的 Lambda 函数。

最终，在使用作业调度程序运行 Spark 作业后显式重建分区具有自我记录的优势。另一方面，AWS Lambda 对于这样的工作很方便。

Answer 2

您应该改为运行ADD PARTITION：

aws athena start-query-execution --query-string "ALTER TABLE ADD PARTITION..."

这会从您的S3 位置添加一个新创建的分区 Athena 利用 Hive 对数据进行分区。 要创建带有分区的表，您必须在 CREATE TABLE 语句期间定义它。使用PARTITIONED BY 定义用于分区数据的键。

Answer 3

有多种方法可以解决问题并更新表格：

1. 致电MSCK REPAIR TABLE。这将扫描所有数据。这是昂贵的，因为每个文件都被完整读取（至少它是由 AWS 完全收费的）。它也非常缓慢。简而言之：不要这样做！

2. 通过调用ALTER TABLE ADD PARTITION abc ... 自行创建分区。从某种意义上说，这很好，无需扫描数据并且成本低。查询也很快，所以这里没有问题。如果您的文件结构非常混乱而没有任何通用模式（在您看来并非如此，因为它是一个组织良好的 S3 密钥模式），这也是一个不错的选择。 这种方法也有缺点： A) 难以维护 B) 所有分区都将存储在 GLUE 目录中。当您有很多分区时，这可能会成为一个问题，因为它们需要被读取并传递给 Athenas 和 EMR Hadoop 基础架构。

3. 使用分区投影。您可能想要评估两种不同的风格。这是在查询时为 Hadoop 创建分区的变体。这意味着没有 GLUE 目录条目通过网络发送，因此可以更快地处理大量分区。缺点是您可能会“碰到”一些可能不存在的分区。这些当然会被忽略，但在内部将生成所有 COULD 与您的查询匹配的分区 - 无论它们是否在 S3 上（因此请始终将分区过滤器添加到您的查询中！）。如果操作正确，此选项是一种一劳永逸的方法，因为不需要更新。

CREATE EXTERNAL TABLE `mydb`.`mytable`
(
   ...
)
  PARTITIONED BY (
    `YEAR` int,
    `MONTH` int,
    `DATE` int)
  ...
  LOCATION
    's3://DATA/'
  TBLPROPERTIES(
      "projection.enabled" = "true",
      "projection.account.type" = "integer",
      "projection.account.range" = "1,50",
      "projection.YEAR.type" = "integer",
      "projection.YEAR.range" = "2020,2025",
      "projection.MONTH.type" = "integer",
      "projection.MONTH.range" = "1,12",
      "projection.DATE.type" = "integer",
      "projection.DATE.range" = "1,31",
      "storage.location.template" = "s3://DATA/YEAR=${YEAR}/MONTH=${MONTH}/DATE=${DATE}/"
  );

https://docs.aws.amazon.com/athena/latest/ug/partition-projection.html

4. 仅列出所有选项：您也可以使用GLUE crawlers。但这似乎不是一个有利的方法，因为它不像宣传的那样灵活。

5. 您可以直接使用Glue Data Catalog API 对 GLUE 进行更多控制，如果您有很多自动化脚本，这可能是方法 #2 的替代方法 做准备工作来设置你的桌子。

简而言之：

• 如果您的应用程序以 SQL 为中心，您喜欢没有脚本的最精简方法，请使用分区投影
• 如果您有很多分区，请使用分区投影
• 如果您有几个分区或分区没有通用模式，请使用方法 #2
• 如果您的脚本繁重，并且脚本完成了大部分工作并且更容易为您处理，请考虑方法 #5
• 如果您感到困惑并且不知道从哪里开始 - 请先尝试分区投影！它应该适合 95% 的用例。