【问题标题】:Full text query in Amazon Athena is timing-out when using `LIKE`使用“LIKE”时,Amazon Athena 中的全文查询超时
【发布时间】:2020-08-25 12:40:25
【问题描述】:

像这样在 Athena 中获取全文查询的超时错误...

SELECT count(textbody) FROM "email"."some_table" where textbody like '% some text to seach%' 

有什么办法可以优化吗?


更新:

创建表语句:

CREATE EXTERNAL TABLE `email`.`email5_newsletters_04032019`(
`nesletterid` string,
`name` string,
`format` string,
`subject` string,
`textbody` string,
`htmlbody` string,
`createdate` string,
`active` string,
`archive` string,
`ownerid` string
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.OpenCSVSerde'
WITH SERDEPROPERTIES (
'serialization.format' = ',',
'field.delim' = ',',
'ESCAPED BY' = '\\'
) LOCATION 's3://some_bucket/email_backup_updated/email5/'
TBLPROPERTIES ('has_encrypted_data'='false');

以及 S3 存储桶内容:

# aws s3 ls s3://xxx/email_backup_updated/email5/ --human
2020-08-22 15:34:44    2.2 GiB email_newsletters_04032019_updated.csv.gz

此文件中有 1100 万条记录。该文件可以在 Redshift 中在 30 分钟内导入,并且在 Redshift 中一切正常。我更喜欢使用 Athena!

【问题讨论】:

  • 使用的源和文件格式的平均文件大小是多少?
  • 表格有多少行?什么是文件格式?数据是否被压缩? email 字段有多大?使用LIKE 效率非常低,因为 Athena 需要检查每一行并查看整个字段。

标签: amazon-web-services presto amazon-athena


【解决方案1】:

CSV 不是一种与 presto 引擎很好集成的格式,因为查询需要读取整行才能到达单列。优化 athena 使用的一种方法是切换到列式存储格式,例如 parquet 或 orc,这也将为您节省大量存储成本,您实际上可以通过查询来做到这一点:

CREATE TABLE `email`.`email5_newsletters_04032019_orc`
WITH (
      external_location = 's3://my_orc_table/',
      format = 'ORC')
AS SELECT * 
FROM `email`.`email5_newsletters_04032019`;

然后在新表上重新运行上面的查询:

SELECT count(textbody) FROM "email"."email5_newsletters_04032019_orc" where textbody like '% some text to seach%' 

【讨论】:

  • 如何向该表添加更多数据?我通常每个月都会收到更新。
  • 您可以像这样使用insert intoINSERT INTO destination_table SELECT select_query FROM source_table_or_view ,查看完整文档:docs.aws.amazon.com/athena/latest/ug/insert-into.html
猜你喜欢
  • 2018-08-03
  • 1970-01-01
  • 2017-11-22
  • 2018-07-24
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-10-02
相关资源
最近更新 更多