我在EMR5.19.0中运行Presto 0.212,因为AWS雅典娜不支持Presto支持的用户定义函数。我使用的是配置为使用胶水模式的EMR。我已经在S3中以正确的分区格式存在已存在的Parquet文件。
最近的Presto版本似乎取消了创建和查看分区的能力。这就引出了一个问题:如何添加单独的分区?我可以在AWS中使用雅典娜控制台并运行MSCK REPAIR mytable;,从而正确地创建分区,然后我可以使用Presto或HUE成功地查询分区。但是,我如何在Presto中做到这一点呢?
如果我在EMR主节点上的presto-cli中尝试这样做的话:
use hive.default;
I
我遇到了一个问题,正确地阅读时间戳,没有任何自动转换的Presto上的电子病历。
示例:在AWS Glue目录中,我有一个表,其中包含UTC时间中的时间戳列(数据类型为时间戳)。当他们在雅典娜询问时,他们会如愿以偿地回来。当在Presto中查询EMR (EMR5.26,Presto 0.220)时,会出现对不同时区的自动转换。
Presto在这里描述了禁用此行为的一种方法- 。
The legacy semantics can be enabled using the deprecated.legacy-timestamp config property. Setting it to true
通过使用EMR上的presto-connector-mysql配置选项,我能够在EMR上创建一个名为mysql的目录。
但是,我想连接到多个mysql数据源。向/etc/presto/conf/catalog添加第二个数据源,然后执行restart presto-server是不完全正确的,因为虽然我可以正确地查询mysql数据源并显示第二个目录,但是在那里查询一个表会得到如下结果:
Query 20170407_040307_00008_qjgse failed: No nodes available to run query
有办法重置整个集群吗?是否需要在所有节点上安装新目录?
我已经连接了Glue目录到雅典娜和一个EMR实例(预置)。我试着在这两种情况下运行相同的查询,但得到的结果不同。EMR为0行,雅典娜为43行。使用left join、group by和count distinct查询非常简单。该查询如下所示:
select
t1.customer_id as id,
t2.purchase_date as purchase_date,
count(distinct t1.purchase_id) as item_count
from
table1 t1
left join
table2 as t2
on t2.purchase_id=
我在使用AWS EMR PrestoDB时遇到了问题。我启动了一个集群,其中主节点作为协调器,核心节点作为工作节点。核心节点是spot实例。但是,主节点是按需的。在群集启动5周后,我收到了以下错误消息 Terminated with errorsAll slaves in the job flow were terminated due to Spot 是不是所有的slaves都被销毁了,集群本身也会被销毁?我看到了现货价格的历史记录,它没有达到我设定的最高价格。 我已经做了什么?我已经检查了转储到s3的日志。我没有找到任何关于终止的原因的信息。它只是说 Failed to visit ..
我有大约300 GB的 of data on S3。让我们说,这些数据看起来像:
## S3://Bucket/Country/Month/Day/1.csv
S3://Countries/Germany/06/01/1.csv
S3://Countries/Germany/06/01/2.csv
S3://Countries/Germany/06/01/3.csv
S3://Countries/Germany/06/02/1.csv
S3://Countries/Germany/06/02/2.csv
我们正在对数据做一些复杂聚合,因为一些国家的数据很大,而一些国家的数据很小
基于的非常基本的地理空间连接每次都会超时。
表polygons包含340K个多边形,而points包含具有纬度/经度对(和ID)的5K行。这两个文件在S3中都是单独的.csv文件。
查询:
SELECT poly.geometry, p.id
FROM polygons as poly
CROSS JOIN points as p
WHERE ST_CONTAINS (ST_POLYGON(poly.geometry), ST_POINT(p.lon, p.lat));
上面的SQL查询永远不会在默认的30分钟Athena查询时间限制内完成。
我发现大型数据集上的普通雅典娜查询性能相当高,但我