在Athena/Quicksight中处理数组的高性能方法
我目前有一个很大的json数据集，我想导入到Amazon Athena中，以便在Amazon Quicksight中可视化。在每个json中，有两个字段:一个是逗号分隔的In字符串(orderlist)，另一个是字符串数组(locations)。因为Quicksight不支持数组搜索，所以我现在求助于创建一个跨两个字符串数组生成交叉联接的视图：
select id,
try_CAST(orderid AS bigint) orderid_targeting,
location
from advertising_json
CROSS JOIN UNNEST(split(orderlist, ',')) as x(orderid)
CROSS JOIN UNNEST(locations) t (location)使用两个交叉连接，这可以将数据爆炸到原始大小的20x-30x。
如果我在Athena上处理单个查询，我可以使用Presto数组函数在数组中进行搜索。有没有更好的方法让这些字段可以在Quicksight上进行过滤？
回答 1
Stack Overflow用户
发布于 2020-10-05 19:25:50
您有两个选择:继续做您正在做的事情，或者实现一个定期实现视图的ETL工作流，例如使用CTAS。后者还有一个额外的好处，那就是您可以生成拼图文件，这有助于加快查询速度。
另一方面，它并不像听起来那么简单。如果您幸运的话，您可以使用INSERT INTO将当前表中的分区在某个时间点之后转换为优化表-但根据我的经验，大多数情况下，您的最新数据会在某个窗口期间更新，但您仍然希望能够在该窗口中查询它。在这种情况下，ETL过程变得复杂得多，因为您需要从优化的表中删除数据，以避免以重复数据结束。这并不难，它只需要大量的代码和S3和Glue data Catalog操作，这样您就不会有重复数据或数据太少的表。
除非你觉得你当前的视图设置太慢了，否则不要去实现一些大而复杂的东西。请记住，您要为在Athena中扫描的字节数付费，而不是为Athena花在处理查询上的时间付费。你运行你的查询会得到相当多的计算能力，根据我的经验，查询的微优化很少有任何意义，无论是通过巧妙的分区还是转移到列式文件格式，你所获得的收益都比最小化你处理的数据量低几个数量级。大多数时候，从小优化中获得的收益是不可测量的，因为雅典娜的查询队列和等待S3操作导致的错误条。你可能会让你的查询快50毫秒，但有时它会排队500毫秒，然后再花2000毫秒在S3上做列表操作，那么你怎么判断呢？
如果您决定沿着物化路线走下去，首先使用CTAS执行一次，然后针对结果运行QuickSight可视化。在确认所获得的性能明显更高之前，不要实现整个ETL工作流。
如果您所担心的是在取消数组嵌套后应用筛选器的性能不如使用数组函数，那么编写两个版本的查询并对它们进行基准测试。我怀疑数组函数的- but速度会稍微快一些，因为我上面提到的同样的原因，收益可能会淹没在雅典娜的排队和其他操作导致的错误栏中。
请确保在一天中的不同时间点进行基准测试，并特别注意这样一个事实，即雅典娜的最高时刻行为与其他时间非常不同(在10:00运行查询，然后在10:10运行- your总执行时间将非常不同，因为每个人的cron作业都在最高时刻运行)。
https://stackoverflow.com/questions/64163744
复制相似问题
腾讯云开发者
