现代数据平台非常复杂。如果你查看参考架构，比如下面来自A16Z的架构，它包含了30多个组件。每个组件可以是一个或多个工具，具体取决于你的设计。你可能不需要所有这些组件，但在现实世界中我们看到的数据平台通常包含10多个工具。

https://a16z.com/emerging-architectures-for-modern-data-infrastructure/

虽然这看起来可能令人望而生畏，但在数据界，构建这样的数据平台已经相当普遍了。如果你去找云供应商，你可以直接获得许多这样的工具，你只需要一个简单的 Terraform 脚本来进行配置。或者，如果你真的想保持简单，可以在他们的控制台中点击几下即可完成。想想将几个 AWS 服务与 Snowflake 结合起来，或者在 Azure 上设置 Databricks，甚至在本地运行一个传统的 Cloudera Hadoop 集群。如今，建立一个能够处理几个由集中式数据团队构建的用例的数据平台，只需要几天、几周，最多几个月的时间。

但是，你最终只拥有一堆工具。这带来了一些挑战：

• 你没有减轻认知负担: 每个开发者需要理解你数据平台中的每个工具，并需要以某种方式将它们结合起来以适应他们特定的使用场景。
• 没有接口: 更改或升级工具很难。每个使用场景都是一系列触发底层工具的脚本。更改或升级工具意味着破坏所有使用场景。
• 难以看清全局: 仪表板中出现问题了吗？那是因为上游某个随机的笔记本中存在一个错误。你需要检查你的CICD系统以了解该笔记本的最后一次部署，然后打开github来查看实际更改。

再次强调，如果你只是为几个用例构建一个小型的中央数据团队，这是可以接受的。你可以培训每个人，并对每个用例给予特别的关注和照顾。

数据网状结构、数据织构、公民数据科学、自助BI……你可以用任何流行词汇来形容，但有一个明显的趋势是，让企业中的每个人都有能力使用数据做些事情。显然，这是因为业务用户需要并希望使用数据来让生活更轻松。

让后排的人也听到：业务用户需要并且希望利用数据来让生活更轻松。

不相信吗？走进你公司的任何业务部门，观察他们用Excel和Access做的一些疯狂复杂的事情。检查他们在仪表板工具中构建的超级高级数据管道。看看他们的分析师每个月如何花7天时间手动从不同系统中汇总数字，并将结果放入PowerPoint中。

我们在一家大型公司做了一个项目，该公司仍然使用一个单一的数据仓库。只有一个团队负责构建所有用例，这通常需要6个月到2年的时间，而且他们有一个9个月的待办事项列表。所以，如果某个业务部门想要某个功能，他们可能需要等2年才能得到。我们为他们建立了一个自助服务的数据平台，3个月内，我们为来自200多个业务用户的100多个用例进行了上线，这些用户会通过MS Access连接到数据。“哦，天哪，太可怕了”？不，这很棒。至少我们知道谁在使用哪些数据集以及用途是什么。有比Access更好的工具吗？是的。他们的业务逻辑会一团糟吗？是的。但这是否是我们最优先解决的问题？不是。业务逻辑是他们自己的。

我的意思是：你希望平台上的用户能够消除中央瓶颈，一旦这些用户入驻平台，你就不能只是给他们一袋工具了。

没有汽车类比的工程博客是不完整的。在Gregor Hohpe所著的《Platform Strategy》一书中，他指出汽车行业很久以前就摒弃了“工具包”方法。如果一家制造商想要推出一款新车型（==构建一个新的应用场景），他们不会去一个长长的工具架上挑选工具，就像A16Z上面的图表所示。他们不会选择一个活塞、一个方向盘、一个散热器……然后开始为他们的特定车型组合这些工具。

顶部图片由作者提供。底部图片来自 Gregor Hohpe 的《Platform Strategy》

相反，他们只构建一次平台，并允许在该平台上构建多个模型。这相比于工具集合的方法带来了多个好处：

• 减轻认知负担: 驱动汽车的所有工程方面都被抽象化了。平台团队可以专注于平台的性能、耐用性和成本效益。模型团队可以专注于客户体验。
• 模型构建者界面简洁: 他们只需要确保驾驶员能够使用方向盘和踏板。他们不需要知道刹车和悬挂是如何与车轮集成的。这些细节可以随着时间的推移而变化，而不会影响模型构建者的界面。
• 容易看到全局: 作为界面的一部分，平台构建者在仪表板上显示状态信息：“需要更换机油”，“液体几乎用完”……对于更高级的状态消息，专家可以连接到汽车的CAN总线。

数据平台团队应该为数据平台提供相同的方法。他们不应该仅仅为用例团队提供一堆工具，而应该考虑他们希望为用例团队提供的功能以及需要哪些接口来实现这些功能。

图片由作者提供

这个界面可能因公司而异。此外，这也取决于您所在平台的发展成熟度。但总体而言，您可以在数据平台上构建四种类型的应用场景：

• 数据仓库: 集成数据源，跟踪历史变化，构建报告
• 数据科学与GenAI: 使用数据进行预测，提供推荐或提供建议
• 关键业务用例: 高SLA运行，与业务流程集成
• 公民数据分析: 通常称为“最后一英里分析”：使业务用户能够进行一些简单的转换并构建仪表板

每个这些用例原型都经过相同的4个阶段：发现、实验、实施、监控。甚至可能还有“退役”阶段。公司对这些阶段有不同的命名，并且有时会将它们细分。发现阶段可以包括制定商业案例、与公司战略对齐、识别所需的数据源、获取预算批准等。

用例团队能够理解这些概念。他们不一定理解“Airflow DAG”、“Iceberg Table”或“pip install”这些术语。你的任务是为这些用例团队提供便捷的道路。因此，当他们选择“我想创建一个新的数据科学用例”时，后台会自动创建一个 git 仓库，构建一个 mlops 数据管道，添加一个模型仓库，创建一个笔记本……

上个月，我们介绍了我们的开源Data Product Portal。对于希望采用Data Product方法的团队来说，这是一个很好的方式，可以为他们的用例团队提供一个独立于技术的界面：用例团队可以定义新的数据产品，向数据产品添加用户，将数据集链接到数据产品，等等。而在幕后，这将根据您的特定基础设施（无论是Snowflake、Databricks还是AWS）进行转换。

这里有一些我们API文档的截图，让你了解一下我们提供的界面：

https://portal.public.demo1.conveyordata.com/api/docs#/

无需详细说明每个端点，此接口允许你以技术无关的方式构建和配置数据产品。实际工具链是如何实现的，则是另一个博客的主题。

当然，并不是每个用户都会说“API”。因此还有一个 web UI。公共演示 这里。

https://portal.public.demo1.conveyordata.com/data-products/ffcf5286-8f14-4411-8dfe-75dc7ed9ec36

这篇博客的信息是，作为一名平台工程师，你应该做的不仅仅是为用户提供一套工具。你应该设计一个与技术无关且符合公司特定需求的数据平台接口。

如果你正在采用数据产品思维，请查看数据产品门户，它作为一个开源项目在 Github 上可用。如果你有任何问题或想要分享你的想法？加入我们的 Slack 社区 并直接与我们联系。