一、发现问题
最近在使用 Metabase 做一些数据分析工作时，遇到了一个让人头疼的问题——自定义 SQL 查询结果中时区显示异常。这问题就像在好好的菜里突然发现一只小虫子，影响了整个分析的体验。
我当时的需求是从数据库里查询用户的登录时间，以此来分析用户在不同时间段的活跃情况。因为涉及到不同地区的用户，所以时区的准确性就非常重要了。我在 Metabase 里写了一段 SQL 查询语句，本以为能顺利拿到正确的数据，可结果却让我大跌眼镜。查询出来的登录时间明显和实际情况对不上，像是差了好几个小时。最初我还以为是数据库里的数据存错了，可是经过一番仔细排查，发现数据库里的数据是正常的，问题就出在 Metabase 对时区数据的映射上。
二、问题分析
2.1 Metabase 时区处理机制
Metabase 是一个开源的商业智能工具，它能让用户通过简单的操作来分析和可视化数据。在处理时区的时候，它会根据用户设置的时区，对从数据库里查询出来的数据进行转换。比如说，数据库里存的时间是 UTC 时间，而用户设置的时区是 Asia/Shanghai，那么 Metabase 就会把 UTC 时间转换成上海的时间。
但是这里面有个问题，Metabase 在进行时区转换的时候，依赖的是它自己内部的时区数据映射表。这个表就像是一个翻译字典，把不同的时区信息对应起来。可有时候这个“字典”会出问题，导致翻译不准确。
2.2 时区数据映射的错误情况
举个例子，我在使用 PostgreSQL 数据库的时候，数据库里的时间字段是带时区的。我在 Metabase 里设置的时区是 America/New_York，然后执行了下面这段 SQL 查询：
-- 技术栈：PostgreSQL
-- 查询用户登录时间
SELECT user_id, login_time
FROM user_login_history;
按照正常情况，Metabase 应该把查询结果里的时间转换成纽约时间。可实际结果却显示的时间和纽约时间相差了好几个小时。经过深入研究，发现是 Metabase 的时区映射表把 PostgreSQL 里的时区信息给映射错了。PostgreSQL 有自己一套独特的时区表示方法，而 Metabase 没有正确识别，就导致了转换结果出错。
三、解决方案
3.1 手动调整时区
既然 Metabase 的时区映射会出错，那我们可以手动来调整时区。还是上面的那个例子，我们可以在 SQL 查询语句里直接进行时区转换。
-- 技术栈：PostgreSQL
-- 查询用户登录时间并转换为纽约时间
SELECT
user_id,
login_time AT TIME ZONE 'UTC' AT TIME ZONE 'America/New_York' AS new_login_time
FROM user_login_history;
在这个 SQL 里，我们先把 login_time 从数据库的时区转换到 UTC 时间，然后再从 UTC 时间转换到纽约时间。这样就绕过了 Metabase 的时区映射，直接在数据库层面完成了时区转换。
3.2 更新 Metabase 版本
有时候，Metabase 的时区映射问题是因为版本太旧导致的。开发团队可能已经在新的版本里修复了这些问题。所以我们可以尝试更新 Metabase 到最新版本。
# 技术栈：Shell
# 停止当前运行的 Metabase 服务
docker stop metabase
# 拉取最新版本的 Metabase 镜像
docker pull metabase/metabase
# 启动最新版本的 Metabase 服务
docker run -d -p 3000:3000 --name metabase metabase/metabase
这里我们使用 Docker 来更新 Metabase。先停止当前运行的 Metabase 服务，然后拉取最新的 Metabase 镜像，最后再启动新的服务。更新完之后，再去执行 SQL 查询，看看时区显示是否正常。
3.3 自定义时区映射
如果更新版本还是解决不了问题，我们还可以考虑自定义时区映射。在 Metabase 的配置文件里，我们可以手动添加一些时区映射规则。
// 技术栈：JSON
{
"custom_timezone_mappings": {
"PostgreSQL_timezone_format_1": "Metabase_timezone_format_1",
"PostgreSQL_timezone_format_2": "Metabase_timezone_format_2"
}
}
在这个 JSON 配置里，我们把 PostgreSQL 里的时区格式和 Metabase 里的时区格式做了一个对应。这样 Metabase 在进行时区转换的时候，就会按照我们自定义的规则来处理。
四、应用场景
4.1 跨国业务数据分析
对于那些有跨国业务的公司来说，他们需要分析不同地区用户的行为数据。比如说电商公司，要分析不同国家用户的下单时间、浏览时间等。如果时区显示不准确，就会导致分析结果出现偏差。通过正确处理 Metabase 里的时区问题，就能准确地分析不同地区用户的行为规律，从而做出更合理的市场策略。
4.2 全球供应链管理
在全球供应链管理中，需要跟踪货物的运输时间、到达时间等信息。不同国家和地区的时间标准不一样，如果时区处理不好，就会影响到货物的调度和配送。使用 Metabase 进行数据查询和分析时，确保时区显示正确，就能更好地管理全球供应链。
五、技术优缺点
5.1 手动调整时区的优缺点
优点
- 灵活性高：我们可以根据具体的需求，在 SQL 里灵活地进行时区转换。比如说，我们可以把时间转换到任意一个时区，而不受 Metabase 时区映射表的限制。
- 准确性高：直接在数据库层面进行时区转换，避免了 Metabase 时区映射可能出现的错误，能保证时间数据的准确性。
缺点
- 工作量大：如果我们有很多个 SQL 查询都需要进行时区转换，那么每个查询都要手动添加时区转换的代码，工作量会比较大。
- 维护成本高：如果数据库的时区设置或者业务需求发生了变化，我们就需要对所有的 SQL 查询进行修改，维护成本比较高。
5.2 更新 Metabase 版本的优缺点
优点
- 简单方便：只需要执行几个简单的命令，就可以完成 Metabase 版本的更新，操作比较简单。
- 可能解决潜在问题：开发团队在新的版本里可能修复了很多已知的时区映射问题，更新版本后可能就不需要再手动处理时区了。
缺点
- 有风险：更新版本可能会引入新的问题，比如说和其他插件不兼容，或者出现新的 bug。
- 不保证解决所有问题：即使更新到最新版本，也不能保证所有的时区映射问题都能得到解决，还是可能需要手动处理。
5.3 自定义时区映射的优缺点
优点
- 针对性强：可以根据自己的数据库和业务需求，自定义时区映射规则，解决特定的时区映射问题。
- 可扩展性好：如果以后有新的时区映射需求，只需要在配置文件里添加新的规则就可以了。
缺点
- 配置复杂：需要对 Metabase 的配置文件有一定的了解，才能正确地配置时区映射规则。
- 容易出错：手动配置时区映射规则，很容易出现错误，导致时区转换结果还是不准确。
六、注意事项
6.1 数据库时区设置
在处理时区问题时，一定要确保数据库的时区设置是正确的。不同的数据库有不同的时区设置方法，比如说 PostgreSQL 可以通过 SET TIME ZONE 命令来设置时区。
-- 技术栈：PostgreSQL
-- 设置数据库时区为 UTC
SET TIME ZONE 'UTC';
6.2 Metabase 用户时区设置
Metabase 会根据用户设置的时区来进行数据转换，所以要确保用户的时区设置和实际需求一致。在 Metabase 的用户设置里，可以找到时区设置选项，选择正确的时区。
6.3 备份数据和配置
在更新 Metabase 版本或者修改配置文件之前，一定要备份好数据和配置。这样即使出现了问题，也可以恢复到之前的状态。
# 技术栈：Shell
# 备份 Metabase 数据文件
cp /path/to/metabase.db /path/to/backup/metabase.db.backup
# 备份 Metabase 配置文件
cp /path/to/metabase/config.yml /path/to/backup/config.yml.backup
七、文章总结
在使用 Metabase 进行自定义 SQL 查询时，时区显示异常是一个比较常见的问题，主要是由于 Metabase 与时区数据映射的坑导致的。通过本文的介绍，我们了解了 Metabase 的时区处理机制，分析了时区数据映射错误的情况，并给出了三种解决方案：手动调整时区、更新 Metabase 版本和自定义时区映射。同时，我们还介绍了这些解决方案的应用场景、优缺点以及注意事项。
在实际应用中，我们要根据具体的情况选择合适的解决方案。如果只是个别查询需要进行时区转换，手动调整时区是一个不错的选择；如果是因为版本太旧导致的问题，更新版本可能就能解决；如果有特殊的时区映射需求，自定义时区映射会更合适。总之，处理好时区问题，才能保证 Metabase 查询结果的准确性，为数据分析和决策提供可靠的支持。
评论
围绕“自定义SQL查询结果中时区显示异常：Metabase与时区数据映射的坑”参与讨论