企业系统越建越多以后经常会出现一种反常现象数据越来越多真正想用数据的时候却越来越难。ERP里有订单和财务数据CRM里有客户数据MES里有生产数据WMS里有库存数据还有大量Excel、日志、接口和第三方平台数据。单个系统都能正常运行但一旦需要做跨部门经营分析就会发现系统连不起来、指标口径对不上、历史数据找不到同一个指标甚至能算出几个版本。这些问题背后本质上都指向一个词数据架构。如果正在做数据平台、数据治理或者数仓建设我整理了一份帆软FineDataLink《数据仓库建设解决方案》里面涵盖数据整合、治理和数据应用等内容适合进一步理解企业数据体系如何从底层系统逐步走向统一管理和应用。需要自取https://s.fanruan.com/7igmg复制到浏览器数据库、数据仓库、数据湖、数据中台听起来很像但它们解决的其实是不同层面的问题。​一、数据架构到底是什么很多人一提数据架构首先想到的是数据库选MySQL还是Oracle数仓用什么技术数据湖放在哪里。但这些都只是技术选型。真正的数据架构描述的是企业数据从产生、流转、加工、存储到最终使用的完整路径。至少要回答五个问题数据从哪里产生数据怎样进入数据平台数据在哪里存储和加工不同系统的数据如何形成统一口径最终怎样提供给报表、分析、算法和业务系统使用例如一笔销售订单产生后最初只是ERP中的一条交易记录。如果企业要分析客户利润就还需要关联CRM中的客户信息、财务系统中的成本和回款信息如果进一步预测客户流失还可能叠加用户行为、服务记录和历史交易数据。​于是一条完整的数据链路往往是业务系统 → 数据采集 → 数据存储 → 数据加工 → 数据模型 → 数据服务 → 数据应用所以数据架构真正关注的并不是“数据放在哪张表里”而是企业怎样把分散的数据组织成能够持续流动、统一加工和重复使用的数据体系。这里还要区分三个容易混淆的概念业务架构解决企业业务怎样运转应用架构解决系统怎样支撑业务数据架构解决这些系统产生的数据怎样连接和流转。企业系统越多数据架构的重要性反而越高。这一层最先要解决的往往就是“数据怎么连起来”。这一层如果没处理好后面数仓分层设计得再漂亮真正落地时还是会卡在取数、同步和数据更新上。像FineDataLink我觉得比较适合的就是这个位置。实际用下来它更像是把企业里这些零散的数据源先串起来。ERP、CRM、MES、数据库、API、Excel 等数据可以统一做同步和加工批量任务、实时任务、异常监控这些也能放在一条链路里管理。​二、数据库解决的是“业务如何把数据准确记下来”数据库最核心的任务并不是经营分析而是保证业务系统稳定、准确地完成交易处理。电商下单、银行转账、库存扣减、订单付款本质上都需要数据库快速记录业务状态。所以数据库通常更加关注数据写入和查询效率事务一致性高并发能力系统稳定性数据安全。例如订单系统可能有订单表、商品表、支付表CRM可能维护客户表、销售人员表MES则记录工单、设备和生产过程。这些表首先围绕的是业务操作本身而不是整个企业的数据分析。这就带来三个天然限制。​1、数据天然分散客户在CRM销售额在ERP成本在财务系统库存又在WMS。每个系统都只掌握业务链条中的一部分。一旦想分析“某客户贡献了多少收入、毛利和现金流”就可能同时跨越三四个系统。2、数据口径容易割裂同一家客户在CRM里可能叫“XX科技有限公司”在ERP里却使用客户编码C001。甚至同一个“销售收入”销售部门可能按照订单统计财务部门则按照收入确认规则统计。数据都是真的但由于业务定义不同最终结果仍然可能对不上。​3、数据库不适合承担大量复杂分析业务数据库最重要的任务是保证交易稳定。如果经营分析长期进行大范围历史扫描、复杂关联和大量聚合不仅效率低还可能影响生产系统本身。所以可以简单理解数据库负责记录“发生了什么”但并不擅长解释“为什么会这样”。而这正是数据仓库出现的原因。​三、数据仓库把业务数据重新组织成分析体系数据仓库和数据库最根本的区别不是数据量大小而是设计目标不同。数据库通常围绕业务流程设计数据仓库则围绕分析主题设计。例如ERP关注订单、出库和发票但经营分析真正关心的往往是客户、产品、区域、渠道、收入、成本和利润。因此数据进入数仓以后需要重新加工和组织。典型的数据仓库通常会经历ODS → 明细层 → 公共汇总层 → 应用层1、ODS先把数据集中起来ODS主要负责承接ERP、CRM、MES等源系统数据通常尽可能保留源数据原貌。它首先解决的是企业的数据能不能稳定汇聚到统一位置。这一层通常不会进行过度加工因为后续还需要保留源系统数据作为核对和追溯依据。​2、明细层统一业务事实这一层开始处理编码不一致、字段格式不同、重复数据、无效数据等问题。例如CRM中的客户A和ERP中的客户001本质上是同一家企业就需要建立统一映射。同时还要尽可能保留足够细的交易记录让后续分析能够继续追溯到订单、客户、商品甚至单笔业务。明细层解决的核心问题是让来自不同系统的业务事实能够按照统一规则被理解。3、公共汇总层沉淀可复用模型这一层会围绕客户、商品、订单、供应商、组织等核心主题构建公共数据模型。比如“客户月度销售额”不再由十张报表分别计算而是在公共数据层统一形成。这样当经营分析、财务分析和销售分析都需要销售数据时可以直接复用同一套结果。成熟数仓最大的价值不是多建几张表而是把高频重复的数据逻辑提前沉淀下来。​4、应用层面向具体业务场景财务分析、销售分析、供应链分析、经营驾驶舱等再基于公共数据形成自己的应用模型。因此数据仓库真正解决的问题是把原来按照“系统”组织的数据重新按照“业务分析”组织起来。数仓真正建起来以后我觉得最麻烦的往往不是某一张表怎么设计而是每天这么多数据任务怎么稳定跑下去。这一块用FineDataLink会比较顺手。比如源数据进来以后清洗、转换、关联、入库以及后续调度都可以继续放在同一条流程里做哪个任务先跑、哪个任务依赖上游也更容易统一管理。实际维护的时候这种方式比一堆零散脚本好管很多。尤其业务系统字段调整或者某个任务异常时不需要再到不同脚本里逐个找问题。​四、数据湖为什么企业还要保存大量“暂时不知道怎么用”的数据数据仓库非常适合结构化经营分析但它通常有一个前提数据进入仓库之前已经大致知道结构和使用方式。​例如销售事实表有哪些字段、客户维度怎样设计、收入指标怎么定义都需要提前规划。但随着互联网、IoT和AI的发展企业的数据已经不只是订单、客户和库存。还包括APP行为日志设备传感数据JSON数据图片和音视频文档算法训练数据大量半结构化原始数据。这些数据的共同特点是产生快、规模大、类型复杂而且企业一开始未必知道未来怎样使用。于是数据湖出现了。数据仓库更偏向先设计再存储。数据湖则更强调先尽可能保留原始数据再根据未来场景读取和加工。因此数据湖特别适合承载大规模、多类型、原始程度较高的数据。​例如一家制造企业产生大量设备传感数据。当前可能只使用其中几项指标进行设备监控但未来如果要做故障预测就可能需要重新分析过去几年保存的完整设备数据。如果一开始只保留“当前认为有用”的部分数据未来就没有重新建模的基础。但这里最容易出现一个误区数据湖不是“什么都往里面扔”。如果只负责存储却没有同步建立元数据管理数据目录数据质量权限控制生命周期管理数据血缘那么数据积累得越多使用难度反而越高。最后很可能从“数据湖”变成“数据沼泽”大家知道数据很多却不知道哪些能用、哪些可信、来源是什么。到数据湖这一层数据来源就更杂了。数据库、接口、文件等数据可能同时存在而且不同数据最后去的位置也不一样。这种场景下用FineDataLink就不用给每一种数据单独折腾一套接入方式。数据库里的业务数据、API数据、文件数据先统一接进来再根据实际用途决定后面进入哪条数据链路。​对日常使用来说这一点很重要。因为数据量一多真正麻烦的不是第一次把数据搬进去而是以后数据源越来越多时这些链路还能不能看得清、管得住。所以数据湖不是为了替代数据仓库。更常见的做法是数仓负责高质量、结构稳定、口径明确的数据分析数据湖负责承接海量、多类型和原始数据。两者解决的并不是同一个问题。五、数据中台核心不是“存数据”而是“复用数据”数据中台是这几个概念中最容易被误解的。很多人认为数据库升级成数据仓库数据仓库升级成数据湖最后再升级成数据中台。其实不是。数据库、数仓和数据湖更多讨论的是数据怎样存储和组织数据中台讨论的是数据能力怎样沉淀和复用。​举个例子。一家大型零售企业有电商、门店、会员和营销多个业务部门。这些部门都需要客户标签。如果电商自己计算一次营销部门重新加工一次会员部门再做一套就会带来三个问题重复开发、口径不一致、维护成本越来越高。数据中台希望做的是先把客户身份、消费行为、会员等级、价值标签统一加工形成公共客户数据能力。之后营销系统需要客户标签直接使用经营分析需要客户画像直接调用推荐算法需要用户特征也从统一体系获取。​因此中台真正沉淀的通常不是某几张表而是标准数据公共模型指标标签数据资产数据服务。它真正改变的是数据建设方式从过去的“一个需求做一套数据”变成“一套公共数据服务多个需求”。这也是为什么数据中台的核心从来不只是建平台。更难的是三个问题哪些数据值得沉淀怎样保证所有部门使用同一套标准沉淀后的能力怎样真正进入业务系统如果这些问题没有解决即使系统名称叫“数据中台”本质上也可能只是重新建了一套数据仓库。做到数据中台我反而不会只看里面沉淀了多少表、多少指标而会更关注一个问题这些已经加工好的数据后面的业务到底能不能直接用。FineDataLink用在这里我觉得比较实用的一点就是前面已经整理好的客户、商品、订单等数据还能继续往分析平台或者其他业务系统流转。这样实际有新需求的时候就不用每次再从源系统重新取数、重新加工一遍。​结语理解数据架构最重要的不是记住几个技术名词而是知道它们分别解决什么问题。数据库负责记录业务数据仓库负责统一分析数据湖负责承载海量、多类型数据数据中台则负责把成熟的数据能力沉淀下来并重复使用。它们并不是简单的替代关系而是共同组成企业的数据体系。真正成熟的数据架构也不应该只看建了多少平台、用了多少技术而要看数据能不能真正做到三件事流得动、说得清、用得起来。最终数据架构的价值不是让企业“拥有更多数据”而是让数据真正变成可信、可用、可复用的业务资产。