企业做数据平台时经常会遇到几个问题已经有 MySQL、Oracle为什么还要建数据仓库有了数仓为什么又要做数据湖MongoDB、Redis 这些 NoSQL 到底解决什么问题ClickHouse、Doris 又应该放在哪一层之所以容易混淆是因为它们都和“存数据”有关但真正解决的问题并不在同一个层面。关系型数据库主要支撑业务交易NoSQL解决特殊数据结构和访问模式OLAP数据库负责大规模分析计算数据仓库解决跨系统数据统一数据湖承担海量原始数据沉淀而湖仓一体试图进一步降低湖与仓之间的割裂。所以判断一种存储技术是否合适不能只看“能存多少、查询快不快”而要同时考虑数据是什么形态、怎样读写、对一致性要求多高、最终拿来做什么。如果正在规划企业数据底座也可以结合这份《数据仓库建设解决方案》一起看。里面涉及数据集成、数据治理以及数据平台建设等内容可以把本文讲到的存储技术进一步放回企业真实架构中理解业务系统里的数据怎样被采集出来不同数据库、数仓和数据湖之间怎样流转最后又怎样进入分析和应用环节。需要自取https://s.fanruan.com/ahhl0复制到浏览器一、关系型数据库核心是把每一笔业务“记准确”关系型数据库最典型的代表是 MySQL、Oracle、SQL Server、PostgreSQL。它按照表、行、列组织数据并通过主键、外键、唯一约束和事务机制维护数据之间的关系。例如一次订单支付可能同时涉及订单创建、库存扣减、支付记录写入和账户余额更新。如果库存已经扣减但支付失败就会造成业务状态不一致。因此关系型数据库非常强调ACID事务。从业务视角理解就是一组相关操作需要有明确的一致性边界要么全部成功要么全部回滚不能留下“完成一半”的状态。这也是它适合ERP、CRM、财务、订单、库存等核心业务系统的原因。但业务数据库主要优化的是大量用户同时对少量记录进行快速增删改查。经营分析恰恰相反。查询一个订单状态可能只读取一条记录但分析过去三年的客户复购率就需要扫描大量订单再按照客户、时间等维度进行关联和聚合。如果复杂统计长期直接跑在生产库上分析任务与业务交易就会争抢CPU、内存和IO资源。因此需要区分业务数据库负责记录业务事实分析平台负责重新组织和解释这些事实。真正做项目时还会遇到一个更现实的问题ERP在OracleCRM在MySQL生产系统又使用SQL Server。过去做跨系统报表时常见做法是给不同数据库分别写抽数脚本。系统少的时候还能维护一旦数据源和同步任务变多字段变化、增量规则、失败重跑都会逐渐成为日常工作。这类链路通常会集中到数据集成平台处理。例如在FineDataLink中维护不同业务库到分析侧的同步任务订单按照增量字段更新主数据按固定周期刷新源系统出现结构变化时也能沿着对应任务排查。这样关注点就不再停留在“怎么连上这个数据库”而是转向整条数据链是否持续稳定。二、NoSQL解决关系模型“不擅长”的那部分数据NoSQL并不是一种数据库而是一类非关系型存储技术。常见的包括键值数据库如Redis文档数据库如MongoDB宽列数据库如HBase图数据库。它出现的原因并不是关系型数据库“不够先进”而是不同业务的数据结构和访问方式差异很大统一塞进二维表并不合理。例如Redis擅长根据一个Key快速定位一个Value。商品缓存、Session、计数器、排行榜等场景往往并不需要复杂关联却存在大量高频读取。MongoDB处理的又是另一类问题。例如用户画像中不同用户拥有的标签、设备和行为特征差异很大。如果使用固定关系表可能频繁增加字段或者产生大量空值文档模型允许不同记录保留相对灵活的结构。所以理解NoSQL的关键不是记住数据库名称而是先判断访问模式。如果核心需求是强事务、复杂关联和结构化数据管理关系型数据库依然重要如果面对Key-Value访问、灵活文档、海量稀疏数据或者复杂关系遍历NoSQL则可能承担其中一部分工作。数据库选型匹配的是工作负载而不是单纯的数据量。一亿条结构清晰、事务要求很高的订单并不会因为“数据量大”就天然应该迁移到NoSQL。三、OLAP数据库重点是“扫得少、算得快”如果说业务数据库擅长处理单笔交易那么OLAP数据库主要面向大规模统计分析。典型场景是对几亿条订单按照地区、客户、产品和月份同时汇总收入、数量、毛利和客单价。这类查询通常具有几个特点读取的数据很多真正参与分析的字段较少修改操作相对少而过滤、聚合、分组非常频繁。因此ClickHouse、Doris、StarRocks等分析数据库通常采用列式存储。假设一张订单表有100列而报表只计算日期、地区、商品、收入4列。行式存储可能读取大量本次查询用不到的数据而列式存储可以集中读取真正参与计算的字段。同时OLAP数据库还会通过分区减少扫描范围压缩降低IO向量化执行批量计算分布式节点并行处理。所以OLAP优化的核心并不仅仅是“机器性能更强”而是尽量减少一次分析真正需要读取和处理的数据。但要特别注意OLAP数据库不等于数据仓库。OLAP数据库主要回答“数据怎样存、查询怎样算得快”数据仓库回答的是“企业分析数据应该按照什么规则组织”。例如企业把Doris作为分析引擎后真正麻烦的往往不是建表而是每天怎样把ERP、CRM、电商等系统的新增数据稳定送进来。实际维护中订单可能每10分钟同步一次客户每天刷新部分大表只同步当天增量还要处理失败重跑和任务依赖。把这些链路放在FineDataLink中统一维护后分析数据库只负责承接和计算数据抽取频率、增量范围和加工顺序则留在数据开发链路中处理两类职责能够明确分开。四、数据仓库真正解决的是“企业到底相信哪套数据”数据仓库最大的价值不是把很多表搬到一个服务器而是重新定义企业分析数据的组织方式。例如“销售收入”看起来只是一个指标实际上就可能存在多种口径按下单日期统计按发货日期统计按签收日期统计按财务收入确认日期统计。如果各部门直接从自己的系统取数即使SQL都没有写错结果仍然可能不同。因此数仓建设需要对源数据逐层加工。ODS尽量保留源系统原貌解决“原始数据有没有完整进入平台”。DWD形成统一业务明细处理编码映射、字段标准化、清洗规则以及业务逻辑。DWS沉淀公共分析能力围绕客户、商品、订单、供应链等主题形成公共汇总。ADS服务具体应用面向经营分析、财务分析、营销分析等场景形成应用数据。这一过程真正解决的是三个问题同一个对象能不能识别成同一个对象同一个业务事件能不能按照同一套规则解释同一个指标能不能得到统一口径。所以数据仓库本质上是一个数据语义统一工程。而真正进入实施阶段之后数仓分层也不是画出ODS、DWD、DWS几层架构图就结束了。每天的数据要按照依赖关系持续跑起来先同步订单再关联商品和客户再生成销售明细最后才能计算主题汇总。数据团队在FineDataLink里维护这类开发任务时关注的通常就是这些具体问题上游数据什么时候到、哪些任务依赖它、执行失败后从哪个节点恢复、某个字段变化会影响哪些后续加工。此时产品本身处在数仓生产链路里而不是额外悬在架构之外。如果只完成数据搬运没有主数据、维度、指标和业务规则统一那么得到的仍然只是一个“大号数据库”而不是成熟的数据仓库。五、数据湖不是“什么都存”而是保留数据未来被利用的可能数据仓库擅长结构化数据但企业现在产生的数据远不止数据库表。还有日志、JSON、图片、音视频、PDF、IoT设备数据以及AI训练数据。这类数据有一个共同特点采集的时候往往还无法完全确定未来怎样使用。如果要求每种数据进入平台之前都必须提前设计完整模型建设成本会很高。数据湖采用的是另一种思路先尽量保留原始数据真正使用时再根据具体场景加工。因此数仓更强调Schema on Write写入之前先确定结构。数据湖更强调Schema on Read数据先保存在读取和计算时再解释结构。例如一批设备日志今天可能只是用来排查故障未来还可能被用于训练预测性维护模型。只要原始数据仍然保留就还有重新解释和加工的空间。但“什么都能存”同样带来风险。如果只有文件进入数据湖却没有元数据、数据目录、权限、质量和生命周期管理几年之后很容易出现大量不知道来源、含义和可信度的数据。数据湖真正的风险不是容量不够而是数据的可发现、可理解和可治理能力跟不上。实际架构中一份源数据也未必只有一个去向。比如订单明细进入数仓服务经营分析完整历史数据进入湖中长期保存业务日志直接落湖供算法使用。做这种多目标链路时FineDataLink更多承担的是“分发”角色不同来源按照各自规则进入不同目标存储同一份数据需要进入数仓和数据湖时也分别维护对应同步链路。这样设计的重点就不再是“所有数据到底应该放进仓还是湖”而是根据后续用途决定数据的落点和加工方式。六、湖仓一体真正要减少的是数据重复和架构割裂传统架构中数据湖和数据仓库往往各自发展。于是可能形成源系统 → 数据湖 → 数据仓库 → 数据集市 → BI同一份数据在不同层之间不断复制。数据湖具有开放、扩展性强的特点但传统湖架构在事务、一致性和高性能SQL分析方面存在短板数据仓库分析能力成熟但并不是为大量原始、半结构化和非结构化数据设计的。湖仓一体试图解决的正是这种割裂。它的核心并不是简单把湖和仓“拼起来”而是让同一套底层数据同时拥有数据湖的开放性以及数仓需要的表管理、事务、元数据和分析能力。于是同一份数据可以同时面向BI分析数据开发实时计算机器学习AI训练。这背后真正希望降低的是三类成本。第一数据复制成本。减少同一份数据反复在湖、仓、数据集市之间搬运。第二口径分裂成本。尽量让BI、算法和其他数据应用基于一致的数据底座工作。第三平台维护成本。减少多套存储长期并行带来的任务、权限和治理复杂度。但湖仓一体也不是“传统数仓升级版”的同义词。如果企业数据主要来自ERP、CRM、财务和供应链系统核心需求仍然是报表分析、指标统一和经营决策那么成熟的数据仓库完全可能继续承担核心作用。只有当非结构化数据增加、AI场景增多、湖仓之间反复复制越来越明显时湖仓一体的价值才会进一步体现。技术升级应该来源于实际架构问题而不是来源于技术名词更新。结语关系型数据库、NoSQL、OLAP数据库、数据仓库、数据湖和湖仓一体对应的是企业数据生命周期中的不同问题。关系型数据库关注交易是否准确NoSQL关注特殊数据模型和访问方式OLAP数据库关注大规模分析效率数据仓库关注企业分析口径能否统一数据湖关注原始、多类型数据能否长期沉淀湖仓一体关注如何减少湖与仓之间的复制和割裂。所以真正做技术选型时不应该先问“现在最流行什么数据库”而应该先回答数据在哪里产生读写模式是什么需要多强的一致性是服务交易、分析还是AI需要保存加工结果还是保留原始数据把这些问题回答清楚之后很多技术选择其实会自然浮现。数据架构的成熟度从来不取决于用了多少种数据库而取决于是否让每一种存储技术承担了它真正应该承担的工作。