当企业的 BI 平台使用多年后，问题通常不在于“缺少报表”，而在于报表太多、性能太慢、口径难以统一，业务人员不得不反复依赖数据团队。GoDaddy 将原有 BI 工具迁移到 Amazon Quick，历时两年，最终每年节省 15,000 小时，将仪表板数量减少 50%，渲染时间压缩到 5 秒以内，并把 AI 驱动的自助分析能力开放给全体员工。
这不是一次单纯的可视化工具替换，而是一次围绕指标、内容治理、性能和使用方式的分析体系重构。
先治理仪表板，再谈平台迁移
仪表板数量减半是这次转型中很有代表性的信号。遗留 BI 平台里常见的情况是：同一个核心指标被复制到多个部门报表中；相似仪表板仅因筛选条件不同而分裂；无人访问的内容仍持续占用维护成本。
迁移时若照单全收，旧平台的内容债务会原样搬进新平台。因此，迁移清单不应该只记录“有哪些仪表板”，还应补充以下维度：
- 最近访问时间与访问人数
- 所属业务域和内容负责人
- 上游数据集、核心指标及刷新频率
- 是否与其他仪表板存在明显重复
- 是否需要保留、合并、重建或下线
可以这样实践：先导出旧 BI 工具的使用日志和仪表板元数据，将低使用率内容标记出来，再由业务负责人确认去留。下面的 Python 脚本读取一个 CSV 清单，找出 90 天未被访问或访问人数过少的仪表板，作为治理候选项。
运行前，将 dashboards.csv 替换为实际导出的文件。文件需要包含 dashboard_name、last_viewed、unique_viewers 和 owner 四列，其中日期格式为 YYYY-MM-DD。
#!/usr/bin/env python3
import csv
from datetime import date, datetime, timedelta
INPUT_FILE = "dashboards.csv"
INACTIVE_DAYS = 90
MIN_VIEWERS = 3
cutoff = date.today() - timedelta(days=INACTIVE_DAYS)
with open(INPUT_FILE, newline="", encoding="utf-8") as file:
dashboards = csv.DictReader(file)
candidates = []
for dashboard in dashboards:
last_viewed = datetime.strptime(
dashboard["last_viewed"], "%Y-%m-%d"
).date()
viewers = int(dashboard["unique_viewers"])
if last_viewed < cutoff or viewers < MIN_VIEWERS:
candidates.append({
"name": dashboard["dashboard_name"],
"owner": dashboard["owner"],
"last_viewed": last_viewed.isoformat(),
"viewers": viewers,
})
for item in sorted(candidates, key=lambda row: (row["viewers"], row["last_viewed"])):
print(
f"REVIEW\t{item['name']}\towner={item['owner']}\t"
f"last_viewed={item['last_viewed']}\tviewers={item['viewers']}"
)
这类脚本不会自动决定删除哪些内容，但能把讨论从“感觉这个报表没人用”变成可审计的决策。对于仍有价值但结构重复的仪表板，更适合合并为一个主仪表板，并通过参数、筛选器或角色权限提供不同视图。
性能目标必须落到查询链路
GoDaddy 将仪表板渲染时间降至 5 秒以内，说明迁移工作不仅覆盖了前端图表，也覆盖了数据模型和查询路径。仪表板慢往往不是某一个图表造成的，而是多个问题叠加：数据集过宽、明细粒度不合适、每个视觉对象重复发起查询、跨数据源联接过重，或者刷新任务与高峰访问相互争用资源。
对核心仪表板，可以将性能目标明确写进验收标准，例如：
- 首页加载和关键筛选操作在目标网络环境下满足响应预算。
- 高访问量看板优先使用经过建模和预计算的数据集。
- 视觉对象只保留支持业务决策所需的字段与粒度。
- 同一指标的计算逻辑尽量沉淀到共享数据集或受治理的语义层。
一个实用的做法是，为每份待迁移仪表板建立性能基线。记录旧平台加载时间、查询次数、数据量和常用筛选条件；迁移后用相同条件回归测试。这样，“更快”才会成为可验证的结果，而不是演示环境中的主观感受。
自助分析的前提是受治理的数据入口
让所有员工获得 AI 驱动的自助分析能力，能显著降低数据团队处理临时报表需求的时间。但“人人可问数据”不意味着“人人可访问所有数据”。真正可扩展的自助分析，需要同时解决数据发现、权限和指标一致性。
可以把可开放的数据资产划分为三层：
| 层级 | 面向对象 | 内容特点 |
|---|---|---|
| 认证数据集 | 分析师和数据团队 | 可复用、带血缘说明、经过质量校验 |
| 主题数据集 | 业务团队 | 围绕销售、客户、运营等领域组织，隐藏不必要的技术字段 |
| 受控探索入口 | 全体员工 | 使用行级权限、字段权限和已定义指标，支持自然语言或可视化探索 |
在 AWS 环境中，可以这样实践：把访问控制作为仪表板发布的一部分，而不是上线后的补救工作。以下 CloudFormation 片段展示了一个 QuickSight 数据集权限配置的简化示例；实际使用时需要替换 AWS 账户 ID、区域、数据源 ARN、主体 ARN 和表定义。
AWSTemplateFormatVersion: "2010-09-09"
Resources:
SalesDataset:
Type: AWS::QuickSight::DataSet
Properties:
AwsAccountId: "123456789012"
DataSetId: "sales-governed-dataset"
Name: "sales-governed-dataset"
ImportMode: SPICE
Permissions:
- Principal: "arn:aws:quicksight:us-east-1:123456789012:group/default/sales-analysts"
Actions:
- "quicksight:DescribeDataSet"
- "quicksight:DescribeDataSetPermissions"
- "quicksight:PassDataSet"
- "quicksight:DescribeIngestion"
- "quicksight:ListIngestions"
PhysicalTableMap:
salesTable:
RelationalTable:
DataSourceArn: "arn:aws:quicksight:us-east-1:123456789012:datasource/warehouse"
Catalog: "analytics"
Schema: "reporting"
Name: "daily_sales"
InputColumns:
- Name: "order_date"
Type: DATETIME
- Name: "region"
Type: STRING
- Name: "revenue"
Type: DECIMAL
这个示例强调的是发布方式：数据集、权限和基础设施定义应进入版本控制，并通过评审和部署流程变更。敏感字段、跨区域数据和财务指标还需要结合组织自身的行级安全策略、审计要求与数据分类标准处理。
两年转型值得借鉴的节奏
GoDaddy 的案例表明，大型分析平台迁移通常不是一次性项目。两年的周期意味着平台切换、内容精简、用户培训和运行机制调整需要并行推进。
落地时可以按风险拆分阶段：
- 盘点数据源、仪表板和用户群，建立迁移优先级及下线规则。
- 先迁移高价值、逻辑相对清晰的看板，验证性能、权限和指标一致性。
- 建立共享数据集、认证指标和模板，避免每个团队重新构建同类内容。
- 面向业务用户开放自助与 AI 能力，同时保留数据质量反馈和人工支持通道。
- 持续观察访问率、加载时间、报表请求量和重复内容数量，把治理变成日常运营。
工具迁移可以带来更快的页面和更现代的交互，但真正产生长期收益的，是把仪表板当作产品来管理：有负责人、有使用数据、有明确的服务目标，也有到期和下线机制。GoDaddy 每年节省的 15,000 小时，背后正是这种从“持续生产报表”转向“持续交付可复用分析能力”的变化。