Snowflake 发布 Data Connectivity Proxy：让 Openflow 安全连接私有数据

DCP 是什么？一句话说清楚身份

2026 年 9 月 14 日，Snowflake 官方发布了 Data Connectivity Proxy，简称 DCP。它是 Snowflake Openflow 的一个新功能，由 Snowflake 自己开发，采用闭源服务方式提供，不是开源软件。它能帮企业把本地数据库、私有 Kafka 等“藏在深闺”的数据安全地连到 Snowflake 上，而且不用打开防火墙的入站端口。打个比方，就像你住在一个只允许自己打电话出去、不允许别人打进来的小区，DCP 就是一部只能往外拨号的电话，它主动打给 Snowflake 总部，让总部通过这条电话线把数据安全地取走，而小区大门始终关着。

DCP 已经在 AWS、Azure 和 Google Cloud 上正式可用，支持 Standard、Enterprise 和 Business-Critical 版本的 Snowflake 客户。它不需要你升级到更高版本，也不需要你重新设计网络。官方原文没有说明它的具体价格，也没有说明是否所有区域都能用。

为什么需要 DCP？私有数据连接的老大难

很多大公司把重要数据放在自己的机房里，比如财务系统用的 Oracle 数据库，或者实时消息用的 Kafka 服务器。这些数据被防火墙保护着，通常规定“只准出、不准进”。以前要把这些数据连到 Snowflake，要么自己搭一套复杂的 ETL 系统，要么花几个月时间申请打开防火墙端口，还要经过网络工程团队、安全团队层层审批。这就像你想从邻居家借本书，但小区规定不能随便开门，你只能自己修一条路过去，费时费力。

现有的办法各有各的局限。云厂商自带的 PrivateLink 只能解决同一朵云里的连接，管不了你机房里的服务器。VPN 和专线虽然能用，但每个网络边界都要单独配置，维护起来很麻烦。第三方代理工具能解决问题，但又多了一个供应商、一份合同和一套要维护的系统。DCP 就是来填补这些空白的。

DCP 怎么工作？只出不进的秘密通道

DCP 的工作方式很巧妙，它把传统的“拉”变成了“推”。以前是 Snowflake 主动伸手进你的网络拿数据，现在是你网络里的一个小代理主动向外连接 Snowflake。这个代理是一个轻量级的软件，可以跑在本地数据中心、私有云、VPC 或者任何有 Docker 的 Linux 机器上。它只做一件事：通过 443 端口向外建立一条加密隧道，然后 Snowflake 通过这条隧道去访问你的私有数据源。

整个过程就像你给 Snowflake 寄了一把只能从里面打开的锁，Snowflake 拿到锁后，通过你主动建立的通道来取数据，而你的防火墙只看到一条向外拨出的电话线。代理本身不检查、不解析、不存储经过它的数据，它只是一个透明的管道。源数据的账号密码始终留在 Snowflake 那边，不会落到代理上。

安全怎么保证？双向验证和自动换证

DCP 的安全设计很细致。首先，代理和 Snowflake 之间使用双向 TLS 加密，意思是双方都要出示证书来证明自己的身份，就像两个人见面互相检查身份证。其次，你需要在 Snowflake 里生成一个一次性的启动令牌，把它放到代理机器上。代理用这个令牌去换取一张属于自己的证书，之后所有的通信都用这张证书来验证。这张证书 Snowflake 会在后台自动更换，不需要你手动操作。

另外，你可以在 Snowflake 里设置允许访问的目标主机和端口，只有名单上的地址才能被连接。你还可以限制哪些源 IP 可以跟 DCP 控制平面通信。如果你删除了 DCP 对象，代理的证书会立刻失效，即使证书还没到期。这些设计让安全团队能清楚地审计每一次连接。

能连接哪些数据源？覆盖三大场景

DCP 主要解决三类以前很难连上的数据源。第一类是本地机房里的数据库，比如 Oracle、SQL Server、PostgreSQL 和 MySQL，它们躲在公司防火墙后面。第二类是私有 VPC 或数据中心里的 Kafka 消息队列。第三类是跨云数据，比如你的数据在 AWS 上，但 Snowflake 账号在 Azure 上。这些场景以前要么连不上，要么需要复杂的网络配置。

代理只需要出站 443 端口，所以不管你的数据在 AWS、Azure、Google Cloud 还是本地，用的都是同一套方法。如果你之前用第三方工具拼凑着解决这些问题，DCP 可以替代那些零散的工具，提供一个 Snowflake 原生的统一路径。官方原文没有说明它是否支持所有类型的数据库，但明确列出了 Oracle、SQL Server、PostgreSQL、MySQL 和 Kafka。

怎么开始用？四步就能跑起来

官方给出了快速上手的步骤。第一步，在 Snowflake 里创建一个 DCP 对象，用一句 SQL 命令就行。第二步，生成一个启动令牌，这个令牌有效期为 7 天。第三步，在代理机器上运行一个 Docker 容器，把令牌文件挂载进去，并指定你的 Snowflake 账号。第四步，用 DESCRIBE 命令验证一下是否配置成功。整个过程不需要 Kubernetes，任何支持 Docker 的 Linux 机器都可以。

代理还支持断线重连，如果隧道断了它会自动恢复。证书轮换也是在后台自动完成，不会中断正在进行的连接。如果你有本地数据库、私有 Kafka 或者跨云数据源一直连不上 Snowflake Openflow，现在就可以试试 DCP。官方文档提供了详细的架构说明、安全模型和监控方法。

谁适合用？有什么限制？

DCP 适合那些有私有数据源、又不想打开防火墙入站端口的企业。比如中型制造商有本地 Oracle 数据库，或者区域银行有防火墙后面的 PostgreSQL，都可以用 DCP 把数据连到 Snowflake。它不需要你升级到更高的 Snowflake 版本，Standard 版就能用。对于金融、医疗和制造业这些有严格合规要求的行业，DCP 的“只出不进”模式特别友好。

不过也有一些限制。官方明确说，代理主机需要直接出站访问 Snowflake 的 443 端口，目前不支持通过企业正向代理来转发代理自身的出站流量。另外，原文没有说明 DCP 的具体定价、是否支持所有 Snowflake 区域、代理的资源消耗指标，以及未来是否会支持正向代理。这些信息需要等官方进一步公布。