数据平台——从分散来源到决策级情报

我遇到的多数组织其实不缺乏数据。问题是数据散落在十个不同系统里——CRM、ERP、电子表格、导出文件、SaaS 报告——没有人掌握全貌。这导致了一个熟悉的模式：两个部门算同一个指标得到不同答案，讨论围绕数字而非决策，数据信任逐渐流失。

数据平台不能一夜之间解决一切。但它建立了单一事实来源——所有来源汇入共享模型的数据仓库——以及以可信方式采集、转化与呈现数据的体系。关键是先明确要做的决策，而非技术。业务每周、每月、每季度需要回答哪些问题？平台从这些问题倒推构建。

我常常发现最大的挑战不是技术而是组织。让不同部门就共享定义达成一致——什么才算是“活跃客户”——与让管道跑通同样重要。我的方法是以迭代方式构建：一次一条管道、一次一个仪表盘，并持续获得业务反馈。

现在人人都在谈湖仓一体是万能方案。实际上，仓库、湖仓还是数据湖的选择取决于您处理的类型以及想做什么。数据仓库（如 BigQuery）非常适合结构化工数据与快速聚合——是仪表盘与报告的理想选择。数据湖适合原始数据、机器学习以及不知道预先要问什么问题的场景。

湖仓一体试图兼得两者优点——可行，但其复杂度常常被低估。我的建议是：为关键数据（销售、客户、财务）从清晰的仓库模型开始，再用湖补充来自日志、传感器或外部来源的原始数据。这为您提供一个简单起点，随需求增长可扩展。

数据平台最薄弱处往往是管道。它们构建得很快、很少记录，一旦跑通就被遗忘——直到某天悄悄坏掉，一份报告两周后才发现数字不对。我按三条原则构建管道：必须受监控（数据缺席时告警）、必须可复用（同样的转化逻辑不重复）、必须被测试（沿途做质量检查）。

对大多数现代平台，我推荐 ELT 架构（提取、加载、转化）而非传统 ETL。区别是先加载原始数据再转化——可在不重新导入数据的前提下重新定义转化。工具选择（dbt、Dataform 或自定义代码）取决于团队能力与平台生态。