【发布时间】：2019-10-19 05:08:12
【问题描述】：
目前，我们有一个 DMS 任务，它将获取 MySQL DB 的内容并将文件以 parquet 格式转储到 S3。
parquet 中时间戳的格式最终为 TIMESTAMP_MICROS。
这是Presto（Athena的底层实现）does not support timestamps in microsecond precision and makes the assumption that all timestamps are in millisecond precision.的问题
这不会直接导致任何错误，但它会将时间显示为某个极端的未来日期，因为它将微秒数解释为毫秒数。
我们目前正在通过在 Athena 表上创建 Athena 视图来解决此问题，这些视图采用这些时间戳，将它们转换为 unix 时间戳（即数字），除以 1000 以转换为毫秒分辨率，然后再转换回时间戳。
这对于概念验证和识别问题来说很好，但这对我们不起作用，因为我们有很多包含大量时间戳列的表，并且不想在顶部引入这个脆弱的视图层。
为 Athena 和 DMS 团队创建了支持票证，双方都确认了问题并在他们的末端创建了功能请求，以便为这种不兼容的问题创建本机解决方案，但两位支持工程师都无法提供内置的解决方法。 DMS 似乎不支持将列类型更改为毫秒精度或 varchar 字符串。对于 Athena，这只是一个记录在案的 Presto 限制。
以前有没有人遇到过这个问题并找到了解决方案？
在 MySQL 数据库中更改精度并不是一个真正的选择，因为它被许多客户使用，我们不想冒险破坏界面。
我正在考虑创建一个作业，该作业将在创建新镶木地板时运行，以查找 TIMESTAMP_MICRO 字段并将它们列到 TIMESTAMP_MILLIS。不完全确定解决此问题的最佳方法（Glue/Spark 工作？）
DMS 非常棒，让转储到镶木地板变得超级简单，可能还有其他方法可以从 MySQL 中提取数据。有没有其他工具可以在没有大量定制开发的情况下做到这一点？
【问题讨论】：
-
不确定 spark 是否会起作用，因为我正在试验它并且我们使用的许多数据类型不受支持（无符号整数）
-
能否请您创建一个问题github.com/prestosql/presto/issues？我不记得 Presto 中有任何关于 TIMESTAMP_MICRO 的问题。
-
我在问题中链接到它，这是一个记录的限制，请参阅 presto 的unsupported features 下的“时间戳限制”
标签： amazon-web-services parquet presto amazon-athena aws-dms