2pm.space直接连接你正在使用的数据库
支持六种引擎，从你自己服务器上的 Postgres 到 BigQuery 项目。选择类型、粘贴凭据、挑选数据表 — 连接在保存前会先经过测试。
PostgreSQL
主机、端口 5432、SSL 模式
MySQL
主机、端口 3306、SSL 模式
ClickHouse
主机、HTTP 端口 8123
Snowflake
账户、仓库和 schema
BigQuery
服务账号密钥和位置
Redshift
集群端点、端口 5439
从连接字符串到看板
建模只是一版供你修改的初稿，而不是需要排期的项目。
连接数据库
连接 PostgreSQL、MySQL、Redshift、ClickHouse、Snowflake 或 BigQuery。凭据加密存储，连接还可以设为只读，除了 SELECT 什么都不会发到数据库。
整理模型
系统会自动读取表结构，生成第一版数据立方体、关联和指标。隐藏不该被查询的内容，重命名只有作者才看得懂的字段，再补上你的业务真正要汇报的指标。
提问，然后固定
用日常语言提问，核对答案背后的 SQL，把值得保留的答案固定到团队每天早上都会打开的看板上。
连接数据库
连接 PostgreSQL、MySQL、Redshift、ClickHouse、Snowflake 或 BigQuery。凭据加密存储，连接还可以设为只读，除了 SELECT 什么都不会发到数据库。
整理模型
系统会自动读取表结构，生成第一版数据立方体、关联和指标。隐藏不该被查询的内容，重命名只有作者才看得懂的字段，再补上你的业务真正要汇报的指标。
提问，然后固定
用日常语言提问，核对答案背后的 SQL，把值得保留的答案固定到团队每天早上都会打开的看板上。
不会编造数字的自助分析
问题之下有一层语义层，所以答案之间彼此一致。
用日常语言提问
像问同事一样输入问题。答案以表格返回，并配上最适合结果形态的图表——还附带实际运行的查询，任何人都能核查计算过程。
靠语义模型，而不是靠猜
指标、维度和关联只需定义一次，并编译进每一条查询。“营收”在每个答案里含义都相同；模型无法表达的问题，也不会悄悄变成一个凭空捏造的关联。
验证过的问题始终有效
把你核对过的回答保存为已验证示例。它的问题和 SQL 会加入模型写查询前要读的示例中，下次遇到类似问题时就会沿用你认可的写法。
由答案组成的看板
任意答案都能固定到看板上。看板支持多个标签页、共享筛选，以及始终保持相对的日期范围——保存为“最近 7 天”的看板，下个月打开依然是最近 7 天。
其余的交给 SQL Lab
有些问题直接写比解释更快。基于同一个语义模型自己写 SQL，保存常用的查询，把结果画成图表并固定到看板。
共享数字，而不是凭据
共享的看板只展示数字，不会交出背后的数据库。访问权限按数据源授予，查看者拿到的是看板，而不是查询控制台。
能连接什么，能得到什么
建模层、看板和 SQL 控制台实际支持的全部内容。
数据库和数据仓库
- PostgreSQL 和 MySQL
- Redshift 和 ClickHouse
- Snowflake 和 BigQuery
- 连接时选定数据表——模型只读取这些表
语义层
- 根据表结构生成数据立方体，再由你整理
- 你定义的指标和计算维度
- 根据键推荐关联，由你确认
- 派生立方体，应对单靠 SQL 会写得很难看的数据形态
- 模型会读取的业务背景和术语表
看板和图表
- 一个看板内含多个标签页
- 始终保持相对的日期范围
- 看板级筛选，从每个卡片中提取出来统一设置
- 根据结果形态自动选择图表
- 通过链接共享，不暴露数据源
写给会写 SQL 的人
- 在同一个连接上使用 SQL Lab
- 经过验证的问题与 SQL 对
- 表范围——模型能看到和不能看到什么
- 每条查询都强制行数上限
- 数据仓库变更后刷新表结构
智能体也能用
- 智能体可以查询同一个语义模型
- 答案可送达聊天、收件箱或定时报告
- 供外部客户端使用的 MCP 端点
- 每次运行都记录问题、查询和成本
控制
- 按数据源授予访问权限
- 只读连接
- 凭据加密存储，绝不返回给浏览器
- 共享看板不附带连接
团队为什么不再截图仪表盘
当数字能自己回答问题时，会发生什么变化。
每个关于数据的问题都要排进分析师的队列，下周才有答复
任何人都能用日常语言提问并得到答案，附带 SQL
让 LLM 直接对着原始表，自信满满地把两个错误的列关联起来
查询由你定义、可审计的语义模型编译而来
“营收”在财务表格里是一个意思，在运营仪表盘里又是另一个意思
每个指标只有一个定义，所有答案和看板都使用它
保存为“最近 7 天”的仪表盘，悄悄地永远停留在三月的某一周
始终保持相对的日期范围
共享一个数字，就得共享一份数据库凭据
共享看板，不附带背后的连接
关于向数据提问的问题
数据团队在把它接入生产环境之前会核实的事。
PostgreSQL、MySQL、Redshift、ClickHouse、Snowflake 和 BigQuery。连接可以设为只读，除了 SELECT 什么都不会发到数据库；凭据加密存储，绝不会回传给浏览器。
对着原始表名猜测的模型，很容易把两个错误的列关联起来，然后自信地给你一个错误的数字。在这里，问题基于语义模型运行：你只需定义一次指标、维度和关联，每个答案都由这些定义编译而来。“营收”在每张图表里含义都相同；模型无法用语义模型表达的问题，也不会悄悄变成一条凭空编造的查询。
不必。连接时系统会自动读取表结构，为你生成第一版数据立方体、关联和指标。之后由你来整理——隐藏不该被查询的表，重命名只有创建者才看得懂的列，再补上你的业务真正要汇报的指标。
可以。SQL Lab 在同一个连接和语义模型上运行你手写的 SQL——保存常用查询，把结果画成图表并固定到看板，或把查询转成派生 cube。已验证示例则来自 ChatQL 本身：保存一个你信得过的回答，它的问题和 SQL 就会引导之后为类似问题编写的查询。
每个答案都会返回表格，以及平台根据结果形态选择的图表，任意一个都可以固定到看板上。看板支持多个标签页，拥有自己的筛选条件和日期范围，还可以共享给需要看数字的人，而无需开放背后数据库的访问权限。
访问权限按数据源授予，共享的看板不会附带连接——查看者看到的是看板，而不是查询控制台。只读连接、每条查询的行数上限，以及每次运行记录提问内容和成本的日志，全程生效。