我是如何将零散的数据转化为一个可用于人工智能的平台-36氪¶

站点: 36氪 抓取日期: 2026-04-14 URL: https://36kr.com/p/3766418380816899

Title: 我是如何将零散的数据转化为一个可用于人工智能的平台-36氪

URL Source: https://36kr.com/p/3766418380816899

Published Time: 2026-04-14T20:33:34+08:00

Markdown Content:

我是如何将零散的数据转化为一个可用于人工智能的平台-36氪¶

Image 1: 36氪

账号设置我的关注我的收藏申请的报道退出登录

登录

搜索

36氪Auto 数字时氪未来消费智能涌现未来城市启动Power on 36氪出海 36氪研究院潮生TIDE 36氪企服点评 36氪财经职场bonus 36碳后浪研究所暗涌Waves 硬氪氪睿研究院媒体品牌
企业号企服点评 36Kr研究院 36Kr创新咨询企业服务
核心服务城市之窗政府服务
创投发布 LP源计划 VClub VClub投资机构库投资机构职位推介投资人认证投资人服务
寻求报道 36氪Pro 创投氪堂企业入驻创业者服务
创投平台
AI测评网

首页
快讯
资讯
- 推荐
- 财经
- AI
- 自助报道
- 城市
- 最新
- 创投
- 汽车
- 科技
- 专精特新
直播
视频
专题
活动
广东
江苏
四川
河南
湖北
安徽
海南
浙江
陕西
重庆
山东
湖南
贵州

搜索

寻求报道

我要入驻

城市合作

我是如何将零散的数据转化为一个可用于人工智能的平台¶

王建峰· 2026年04月14日 12:11

我是如何将零散的数据转化为一个可用于人工智能的平台

分层架构，整合数十个异构数据源，实现人工智能，并将结果反馈到整个运营中，零风险，且无需重写原始系统中的任何一行代码。

所有运营超过五年的公司都面临着同样的问题：当初没有人规划过各个系统之间的互通。CRM 系统运行在 MySQL 上，财务系统运行在 PostgreSQL 上，运营平台使用着一个完全不同的 MySQL 实例，营销数据通过电子表格和 SaaS 工具以各自的 API 接口运行，而数据则散落在队列、缓存、存储桶以及 NoSQL 数据库中——这些数据库是当初为了某个试点项目而搭建的，后来却一直沿用至今。每个系统在它诞生的那个阶段都是最佳选择。真正的问题始终在于缺乏整合策略。

当一位主管问“我想要一份关于客户参与度和收入的报告”时，许多公司给出的诚实回答是：“我们需要两周时间和三个Excel表格拼凑在一起。”

本文描述了我为解决此问题而设计和实现的架构，重点阐述了每个决策背后的原理。

场景：数据量很大，但没有实际用途。

客户多年来积累了数十个系统：不同版本的 MySQL 数据库、PostgreSQL 实例、第三方 API、作为整个部门“数据库”的共享电子表格，以及只能通过手动导出访问的 SaaS 工具中的数据。数据量相当可观，但却存在三个关键问题：

碎片化。 同一个实体（客户、合同、交易）存在于两到三个系统中，这些系统具有不同的模式、不同的ID和不同的数据更新级别。没有单一的数据源。

过时。 废弃的字段、重复的记录、不再反映企业实际运营情况的类别。数据在数据库中老化，无人维护。

对人工智能而言，不透明性 是决定性因素。该公司希望利用人工智能进行推荐、自动化和预测分析。人工智能依赖于一致且结构化的数据。如果语言模型接收到零散的上下文，就会产生零散的响应。如果评分模型输入的是重复数据，那么生成的排名将无人信任。

挑战既有技术上的，也有战略上的：既要让公司的数据资产能够被人工智能使用，又要不中断依赖现有系统的运营。

原则：对资源零影响¶

第一个架构设计决策，也可能是最重要的决策，就是完整地保留原有的系统。

重写旧版客户关系管理系统（CRM）或将财务企业资源计划（ERP）系统迁移到统一数据库这类项目往往耗时数月，带来运营风险，而且经常失败。我亲眼见过这种情况。“全新升级”的系统上线后，仅保留了旧系统70%的功能，运营团队不得不花费六个月的时间手动弥补这些功能缺失。

我采用的方法基于一个简单的前提：保持所有原始应用程序的运行状态不变，并照常向其各自的数据库、API 和存储设备提供数据。每个数据源，无论采用何种技术（MySQL、PostgreSQL、REST API、存储桶文件、SaaS 导出），都会以增量式、非侵入式的方式镜像到集中式数据湖。

实际上，运营团队的日常工作并没有任何变化。客户关系管理系统 (CRM) 继续运行，企业资源计划系统 (ERP) 继续开具发票，网络平台继续为用户提供服务，市场部门继续填写电子表格。在后台，所有这些数据源的每一次更改都会被捕获并复制到单独的存储层，无论这些更改来自关系数据库、API 还是存储桶中的 CSV 文件。

分层架构¶

最终设计分为四个不同的层次，每个层次都有明确的职责。

第一层：原始应用程序

MySQL 的不同版本、PostgreSQL、SaaS API、电子表格、消息队列、存储中的文件。每个系统都像往常一样继续运行。唯一的交互点是适用于每种技术的捕获机制：关系数据库使用 CDC，SaaS 使用 API 连接器，导出和电子表格使用文件导入，队列使用消费者。难点就在于如何处理这种多样性，同时又不给源系统强加单一标准。这一层仅被观察，绝不被修改。

第二层：数据湖

这里的数据按三个区域进行组织：

原始 数据区 直接接收源系统输出的数据，不做任何转换或清理。它是每个系统生成数据的真实历史记录，对于审计以及业务规则变更时的重新处理至关重要。

暂存区执行初步转换：数据清理、去重、类型校正和质量验证。例如，MySQL 中原本为自由 varchar 类型的“phone”字段在此被标准化。重复记录会被识别并标记。

在“精选区” ，数据被赋予了业务结构。实体被整合：原本分散在三个系统中的“客户”现在成为一个拥有统一属性的单一实体。关系模型开始反映业务的实际情况，并与运营和公司术语保持一致。

第三层：丰富性和智能

在这一层，数据开始对人工智能发挥作用，这也是该架构差异化价值的主要体现。

在精选区整合的基础之上，该层运行各种流程来添加信息。评分模型计算倾向性、相关性和风险。匹配算法交叉比对个人资料以生成推荐。外部增强功能添加第三方数据（地理编码、市场数据、补充记录）。业务指标预先计算并呈现，以便快速使用。

关键在于，一些终端应用程序已经运行在这一层。例如，匹配系统以服务的形式运行，能够近乎实时地消费和生成数据。这一层是整个运行过程中不可或缺的一部分。

第四层：终端应用（消费和反馈）

仪表盘、智能 API、自动化流程和 AI 代理。所有这些应用都使用已经整合、清洗和丰富过的数据。AI 代理回答有关客户的问题时，查询的是一个已经整合并丰富了来自所有来源信息的单一数据层。

这一层的一个基本特点是它能够反馈到之前的所有层。机器学习模型计算出的分数可以写回源数据库，因此传统应用程序也能受益于生成的智能信息。自动化流程产生的新数据会流入数据湖。人工智能代理的结果会触发增强层中的指标重新计算。整个系统形成一个循环：每一层都受益于其他层的贡献。

重要的决定¶

一些技术决策值得关注，因为它们对项目的成功至关重要。

数据库使用变更数据捕获 (CDC)，其他所有数据则使用连接器。 变更数据捕获仅复制关系数据库中已更改的内容，从而减少延迟窗口和处理成本。但 CDC 只是众多策略之一。对于 SaaS API，可以使用定期同步的连接器。对于电子表格和导出文件，可以使用基于文件事件的摄取方式。为每个数据源选择合适的机制是架构设计的一部分，任何错误的选择都会导致管道脆弱性。

原始区域的读取时模式 (Schema-on-read)。 允许数据在没有固定模式的情况下到达，可以吸收源系统的变更而不会中断数据管道。当产品团队向 CRM 添加字段时，数据湖会自动吸收它。转换发生在后续层，这些层可以进行控制。

指标物化视图。 预先计算的关键绩效指标 (KPI) 逐步更新，无需进行复杂的实时查询。仪表盘加载速度低于 2 秒，这得益于繁重的计算工作已预先完成。

将数据丰富化和数据消费分离。 将智能层与消费层分开，使得不同的应用程序可以使用不同级别的处理。一个简单的仪表盘可以直接从精选专区获取数据。而人工智能代理则需要经过数据丰富化处理的数据。这种灵活性避免了为简单的用例进行过度设计。

层间反馈循环。 允许终端应用程序将数据写回之前的层，使架构成为一个动态系统。数据在每个循环中不断改进：第 3 层生成的分数可以优化第 1 层中的处理过程，从而在下一个数据摄取循环中生成更高质量的数据。