多 Warebase 负载隔离
背景
ProtonBase 是一款结合存算分离架构优势的云原生数仓系统，其存储层与计算层独立拆分，提供弹性调整计算资源和负载隔离的能力。本手册介绍如何实现有效的负载隔离，从而应对多用户、多任务的复杂负载场景。
在数据仓库场景下，负载隔离是指通过资源和任务的逻辑隔离，避免不同用户或不同任务相互干扰，以保障任务执行的性能和准确性。ProtonBase 的存算分离架构通过 存储共用、计算资源独立 的方式便捷支撑这个场景。
Warebase 是 ProtonBase 的计算资源抽象，用户可以为不同的业务分配不同的 Warebase，实现负载的隔离，每个 Warebase 可以进行独立的数据加工、查询，多个 Warebase 对同一份数据的更新，具备串行的一致性保障。
Catalog 是 ProtonBase 的元数据管理抽象，在同一个 Catalog 下的所有 Database 可以被 Warebase 共享访问，同时 Catalog 也是实例升级的基本单位，在实例升级时，同一个 Catalog下的所有 Warebase 会统一升级，避免元数据存在多版本不一致。
在一个 Database 被多个 Warebase 同时访问时，需要首先明确该 Database 所绑定的 Warebase。被绑定的 Warebase 对该 Database 读写具备本地直读直写特征，典型是 TP 场景，性能更好，同时需要被绑定的 Warebase 处于运行状态，其他 Warebase 才可以读写该 Database。其他Warebase 与绑定的 Warebase 在功能上完全一致，但由于采用远程读写技术，在 TP 场景，性能偏弱，同时也会消耗绑定 Warebase 一定的计算资源。每个 Database 有且仅有一个绑定的Warebase。
因此在我们设计负载隔离的场景时，应该将被共享的多个 Database 设计为隶属同一个 Catalog，需要被隔离的负载设计为不同的 Warebase，直接写入和短查询的 Warebase 与 Database 绑定，基于 Shared Data 架构，实现灵活的负载隔离。
注：多 Warebase 共享 Database 的负载隔离属于“旗舰版”功能，如需体验，请升级合约到旗舰版。
负载隔离常见场景
- 开发与生产隔离
开发测试任务与生产任务分离运行，确保测试任务的意外高负载不影响关键生产任务。
- 多团队任务隔离
多团队或项目独立运行任务，避免资源争用冲突。
- 高优先级任务保护
某些任务优先级高，需独立分配稳定资源。
- 读写分离
某些系统会希望进行读写分离，基于读写不同的 IO 特征和权限要求，分配独立的资源。
设计 Warebase 与 Database 的关系
默认绑定的 Warebase
DataCloud 可以创建多个 Catalog，在创建 Warebase 时可以新建或者选择一个已有的 Catalog。
初次创建 Warebase 时会在 Catalog 下默认产生系统数据库，对于系统默认产生的 Database，包括 postgres、template0、template1 三个 Database，默认绑定当前创建的 Warebase。如果系统数据库绑定的 Warebase 停机，会自动在其他 Warebase 中重新选举一个 Warebase 再次绑定，以保持系统相关的元数据的可用性。
用户可以在任意 Warebase 中通过执行 CREATE DATABASE 命令创建更多的 Database，创建 Database 的 Warebase 自动绑定。用户可以通过 Database 列表页面查看每个 Database 所绑定的 Warebase。建议为不同业务场景创建独立的 Database，不要使用默认创建的负责元数据管理职责的系统 Database。
当绑定的 Warebase 停机，或者 Database 未关联绑定的 Warebase 时，该 Database 不可见，无法访问。
Warebase 访问 Database
任意 Warebase 无需额外操作，可以通过数据库连接字符串连接到同一个 Catalog 下的任意 Database，支持读写请求。注意，写请求会消耗Owner Warebase 的部分资源，可以通过监控指标观测到资源消耗。读请求在多个 Warebase 之间计算资源独立，每个 Warebase 可以独立调整计算资源，调整期间不影响其他 Warebase 的使用。
更换绑定的 Warebase
绑定的 Warebase 承担着对应 Database 本地直读直写的责任，因此建议把长期运行的，负责写入或者短查询的 Warebase 设置为该 Database 的绑定 Warebase。如果需要更换绑定 Warebase，需要先解绑原有绑定 Warebase，再点击该 Database 上的绑定，选择绑定到新的 Warebase ，绑定时需要给出新的 Database 命名，建议和原有 Database 命名保持相同。
当主 Warebase 停机时，无法解绑，运行态的主 Warebase 支持解绑 Database。
实践推荐
Database 的划分
通常 Database 的划分也是责任边界的划分，在同一个权限管理范围下的数据，适合聚合在一个 Database 内，不同的 Database 可以采用不同的授权策略。因此常见的做法是，一个团队管理的数据在一个 Database 里，团队里负责安全的同学负责管理 Database 的访问授权。数仓团队通常负责公司的多数据源聚合、清理、数据质量修正、基础数据模型的构建、维度建模，从而沉淀公司的数据资产，包括 Brozen Zone 和 Silver Zone。
如果数仓团队的责任包括多个完全独立的业务域，也应该基于业务的隔离进行 Database 的划分，确保数据的可见范围尽在指定业务范围内。
postgres、template0、template1 是系统默认产生的三个和元数据管理有关的默认 Database，不建议用户的业务数据保存在系统 Database 内，应该基于上述业务考虑，创建独立的 Database。
Database 的授权
尽管同一个 Catalog 下所有的 Database 对所有的 Warebase 可见。但这不意味着任何 Warebase 可以访问任意 Database 的数据，能否访问依赖于当前用户是否有对应 Database 的访问权限。如果账号是 Global User，需要显性将 Global User 加入到当前 Database 中（默认创建当前 Database 的Global User 自动添加到 Database 中）；如果账号是 Local User，需要明确通过 CREATE USER 命令，创建账号，不同 Database 的 Local User 互相不共享。
Warebase 的划分
Warebase 的划分相比 Database 会更加的灵活，由于 Warebase 的无状态和高度弹性能力，建议不同的应用场景，更细粒度拆分 Warebase。
将常驻运行，负责实时数据写入、实时加工的 Warebase 作为 Database 的绑定 Warebase，并保持相对稳定的计算资源。
将负责数据加工，有潮汐特征计算负载的任务划分在面向 ETL 的 Warebase 中，针对 ETL 作业的负载变化特征，在不同时间动态分配不同的计算资源，实现流量高峰时的稳定，以及流量低潮时的成本节约。
在数据消费和应用方面，将负责在线服务和团队内部使用的 Warebase分别独立划分，因为在线服务有更高的稳定性优先级，需要减少负载的波动，对外提供可预期的相应 SLA，团队内部 Warebase 稳定性要求略低，运维沟通半径更短，因此管理模式和在线应用不同，适合独立的、有弹性的 Warebase。