分层架构，整合数十个异构数据源，实现人工智能，并将结果反馈到整个运营中，零风险，且无需重写原始系统中的任何一行代码。
所有运营超过五年的公司都面临着同样的问题：当初没有人规划过各个系统之间的互通。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 层中的处理过程，从而在下一个数据摄取循环中生成更高质量的数据。
结果：数据作为一种战略资产
该公司获得了一个统一的数据平台，该平台为公司运营中的每一项人工智能和自动化计划奠定了基础。
原本需要数周人工完成的功能，现在几天即可部署完成。新的人工智能代理无需自定义集成即可连接到平台。新应用从一开始就能使用已经整合和丰富的数据。
没有停止或重写任何原有系统。运营风险为零。在数据基础设施并行构建的同时，团队的工作也保持正常。
对于那些面临同样挑战的人来说
如果你的公司数据分散在多个系统中，并且正在努力使人工智能项目可行，那么最有成效的问题是：“我们的数据是否已准备好可靠地为人工智能提供数据？”
大多数情况下并非如此。而未来的发展方向是在现有系统之上构建一个智能层。
这就是我构建和交付的项目类型：数据成熟度评估、整合架构设计以及将碎片化数据转化为人工智能就绪战略资产的平台实施。
本文来自微信公众号 “数据驱动智能”（ID：Data_0101），作者：晓晓，36氪经授权发布。
