解决数据孤岛｜RisingWave 与 Cube.js：如何在流数据之上构建数据语义层

数据孤岛，指数据被存储在不同的系统或部门，无法有效流通和共享，从而导致信息难以整合和利用，增加重复数据、冗余工作，影响决策质量。解决方法包括建立统一的数据管理平台，制定数据标准和规范，促进跨部门合作，以确保数据流动和整合，提高组织运营效率。

打破数据孤岛一直是现代数据管理的核心问题，由此衍生出的理念和架构名词层出不穷，包括联邦查询、数据湖、数据网格（Data Mesh），诸如此类。而今天我们要介绍的是“数据语义层”，同样是解决数据孤岛的问题，只是它解决问题的层面有所不同。

在本文中，我们将探讨如何将 RisingWave 无缝集成到语义层解决方案 Cube.js，从而为实时分析带来更多可能。

1. 理解数据语义层

所谓“语义层”（Semantic Layer），其出发点是：

• 将分散在各个数据系统的数据统一起来，打破数据孤岛；
• 以业务视角对数据模型进行更直观易懂的转译，使得数据更容易被多团队使用；
• 为数据赋以通用的访问接口，例如 RESTful API、GraphQL、SQL、甚至是人类自然语言。

不同产品或企业内或许对语义层有不同的具体实现，但总的来说，这类平台至少应该具备这样一些能力：

• 为各种数据源的表对外暴露 HTTP 查询接口，使得前端工具可以无缝接入，同时为接口调用提供实时监控（延迟和流量监控等）；

• 对数据表进行标准化建模和注释，以及一些数据清理，使数据的意图能够被充分理解。

• 为不同部门赋予不同的数据访问权限；

• 对接各类可视化工具。如 Tableau，PowerBI，一旦接入了语义层，就等于接入了所有数据源；

2. 语义层的热门工具

当前业内有几个产品专为语义层所打造，其中包括 Cube.js 和 dbt Semantic Layer。还有一些产品，例如 Hasura 和 Dremio，也具备一定的数据源集成 + 查询的能力，本质上也属于语义层的范畴，但它们的焦点会有所不同。比如 Hasura 更专精于 GraphQL，而 Dremio 则偏向于作为一个数据湖仓。

但总的来说，这些工具都秉持一个共同的目标，即打破数据孤岛，为用户提供统一的数据体验。

3. 零代码提供 GraphQL 接口

在我看来，语义层工具的关键功能之一就是对 GraphQL 接口的支持。

GraphQL 的最大特点是其高效灵活的查询能力。与 REST 风格的接口不同的是，GraphQL 能避免返回不必要的数据，极大减小网络与数据库的开销。

利用 Cube.js 作为 RisingWave 的 GraphQL 网关，用户无需编码就能快速对 RisingWave 的物化视图数据进行产品化。

4. BI 工具集成

与主流商业智能（BI）工具的集成能力也是对语义层解决方案的一个重要考量点。

虽然 RisingWave 也集成了不少主流的 BI 工具，如 Metabase、Superset、Looker 等，但由于开发资源有限，仍有一些工具还未被支持或验证。而 Cube.js 则专精于此。

Cube.js 支持了对 Hex、Tableau、Power BI 和 ThoughtSpot 等等的 BI 工具的无缝连接。用户可以借 Cube.js 为代理来将 RisingWave 集成进各种 BI 平台，实现对 RisingWave 的生态扩展。

5. 商业友好的开源许可

值得一提的是，Cube Core 采用 Apache 2.0 许可证和 MIT 许可证双重许可，这意味着使用其基本功能无需支付软件费用，在商业环境中部署也没有限制。

6. Demo：RisingWave Cloud 和 Cube Cloud 连接

好消息是，RisingWave 和 Cube 支持云和云之间的集成。在 Cube Cloud 上创建一个新的 PostgreSQL 数据源，填入 RisingWave Cloud 的连接信息后即可完成接入。

假设我们要基于 RisingWave 系统表 rw_events_log  开发一个数据应用，那么第一步我们需要为其封装一个 GraphQL 接口，避免前端直接访问数据库。在 Cube Cloud 控制台内选择“生成数据模型”，选择需要绑定的表，导入之后该表自动就拥有了一个 GraphQL API，无需编写任何代码。

我们可以尝试调用该接口，从而得到不同事件类型各自的条数。

curl \
  -H "Authorization: xxxx" \
  -H "Content-Type: application/json" \
  --data-raw '{"query":"{cube{rw_event_logs{count event_type}}}"}' \
  https://xxx.aws-us-east-1.cubecloudapp.dev/xxx/cubejs-api/graphql

{
  "data":{
    "cube":[
      {
        "rw_event_logs":{
          "count":10,
          "event_type":"BARRIER_COMPLETE"
        }
      },
      {
        "rw_event_logs":{
          "count":1,
          "event_type":"META_NODE_START"
        }
      }
    ]
  }
}

另一方面，Cube.js 也使得 RisingWave 的用户得以尝试许多新兴的工具，例如 Observable。在本文编写前，由于缺失一些系统表功能，RisingWave 尚未完整支持 Observable，但我们可以略微变通，借由 Cube.js 来代理，从而实现这一集成。

Observable 是一个精巧有趣的 Notebook 工具，它允许用户快速编写一个数据分析报告，SQL 代码编写完成即可见，用户可以基于数据进一步编写各种图表并嵌入到报告中。

以 rw_event_logs 举例，我们可以按事件类型分别统计条数，并将结果以柱形图直观呈现。

7. Cube.js 用户需考虑的因素

对于像 Snowflake 或 Redshift 这样的分析数据库，Cube.js 的缓存和预聚合的能力能够发挥很大的效用，降低复杂分析的查询延迟。但对于 RisingWave 而言，这一能力的收益会比较有限。

RisingWave 本身即是 Postgres 或 MySQL 等应用数据库的加速层，额外的缓存层在实际场景一般收效甚微。

8. 总结

RisingWave 站在实时分析的前沿，为统一语义层方案 Cube.js 提供了无缝集成。两者的组合为用户带来了实时分析 + GraphQL API 的方案，也帮助 RisingWave 的用户带来了更多生态工具，覆盖了更多应用场景。未来我们还会进一步优化与 Cube.js 的集成体验，如您遇到任何相关的问题，欢迎给予我们反馈！

9. 关于 RisingWave