一、前言“数据库存数据，数仓做分析，数据湖什么都能放，中台负责共享。”但真到了项目里，还是容易困惑：MySQL 也能做统计，为什么还要数仓？数据湖已经存了所有数据，为什么不能直接出报表？买一套数据平台，是不是就有中台了？本篇我们就用一个网店的例子来重新认识一下。二、先看全局：它们解决的是不同层面的问题概念它要回答的问题常见交付物业务数据库这笔业务现在是什么状态，怎样正确地修改它？订单、库存、支付等业务记录数据仓库怎样把多处数据按一致规则整理，得到可信的分析结果？业务报表、分析模型、汇总指标数据湖怎样保存和管理多种形态的数据，供不同用途加工？原始文件、日志、图片及加工后的数据表数据中台怎样让多个团队持续复用可信的数据能力？公共指标、数据目录、标签、数据服务及管理规则前三者更多涉及数据如何存储、组织和处理，数据中台还涉及谁维护数据、怎样共享、如何交付给业务。三、第一步：顾客下单，数据库先保证正常交易假设网店正在促销，一双鞋售价 200 元。顾客下单后，系统至少需要记录订单、支付结果和库存变化。如下例子：订单号用户商品实付金额订单状态A001U01S01200已支付A002U02S01200待支付客服打开 A001，要立刻看到这笔订单；支付通知到达后，系统要正确更新状态；只剩一双鞋时，两个人同时购买，库存不能被无条件扣两次。这就是交易型数据库主要面对的工作：频繁处理小范围的读写，而且要配合业务逻辑维护正确性。通常称为OLTP，即联机事务处理。那么问题来了，数据库也能统计，为什么还需要别的系统？网店规模小时，统计当天的支付金额，直接查询业务数据库就能完成。但“查订单 A001”和“按渠道比较过去一年的退款率”是两种很不同的工作：对比项查一笔订单分析一年经营情况读取范围通常少量记录可能扫描大量记录主要操作精确查询、插入、更新筛选、关联、分组、汇总组织数据时优先考虑业务正确、写入方便、响应及时分析方便、历史可比、口径一致常见工作类型OLTPOLAP，即联机分析处理分析查询可能与下单争抢 CPU、内存和磁盘资源。这也是为什么“把 MySQL 配置调大”和“建设数仓”并不等价。前者主要增加处理能力，后者还要重新组织分析所需的数据。四、第二步：活动结束，数仓把数据整理成能算清的账活动结束后，领导问：“这次活动卖得怎么样？”运营查订单，财务查支付，售后查退款，三个部门交上来三个数字。先别急着判断谁算错了，他们可能回答的是不同问题。看一组假设数据：订单号下单金额成功支付金额已成功退款金额A0012002000A00220000A003300300100合计700500100这些数都可以成立，但实际扣除成功退款后的400 元，其实是不等于利润，更不能直接等同于财务确认的收入；利润分析还要考虑商品成本、广告费、履约费用等，财务收入则有相应的确认规则。数仓的价值，是把业务规则落实成能够重复计算、追溯来源的数据模型。它需要整合订单、支付、退款等来源，处理重复和异常，保存分析需要的历史，再形成公共明细与指标。1、算指标之前，先确定“一行代表什么”这叫数据的“粒度”，是数仓建模里最实用的概念之一。一行可以代表一笔订单、一件订单商品，也可以代表一次退款。它们不能随便混用。假设 A003 实付 300 元，后来分两次各退 50 元。如果把订单表直接关联退款明细，结果会变成：订单号支付金额本次退款金额A00330050A00330050这时直接汇总支付金额，会得到 600 元。SQL 没报错，数字却翻倍了。一种处理办法是先按订单汇总退款，再和每订单一行的支付结果关联。这样才能得到“支付 300、退款 100、净支付 200”。2、事实和维度，让分析有统一的组织方式“支付了 200 元”是发生的业务事实；“是哪位用户、什么商品、来自哪个渠道、发生在哪天”是分析它的角度，这些角度叫维度。可以简单记成：事实记录发生的事件，以及金额、数量等度量。维度描述事件的背景，让我们能按商品、时间、地区等角度观察。整理之后，同一份可信的支付明细，既能按天统计，也能按渠道比较，不必每张报表都重新理解一遍订单状态。业务库里可能有历史订单，并不代表分析所需的所有历史属性都已经保留下来了。3、分层，是为了让整理过程可以复用和追查项目里常见的数仓分层，可以落到这次活动上理解：常见层次这层做什么活动案例中的内容ODS，接入层接入来源数据，保留必要的来源信息订单、支付、退款来源记录DWD，明细层清洗、去重，按明确粒度整理业务事实每次成功支付、每次成功退款DWS，公共汇总层汇总高频使用的数据用户每天的支付金额、退款金额ADS，应用层面向具体报表或应用提供结果活动经营日报、渠道效果报表分层带来的实际好处是：报表错了，可以往上游追；新报表来了，可以复用已有明细和汇总；业务规则调整，也能定位需要重新加工哪些数据。五、第三步：想知道为什么有人没买，数据湖提供更多分析材料现在我们知道了支付金额，但领导又问：“广告点击很多，为什么最后买的人少？”光看订单不够。没有下单的人，根本不会出现在订单表里。需要进一步查看广告点击、页面浏览、加入购物车等行为。也许还要看商品图片、评价、客服对话，判断是不是图片误导、尺码描述不清楚。这些数据形态各异，未来用途也不一定一开始就能确定。数据湖适合把它们纳入统一的存储与管理范围，并保留足够的信息供后续加工。1、湖和仓，差别不只是“一个乱，一个整齐”数仓通常围绕相对明确的分析主题组织数据；数据湖通常更强调保留多样的数据形态，支持探索和多种加工用途。例如，一条浏览日志可能包含页面、时间、设备和活动编号。今天只分析访问量，下个月想研究用户在尺码说明页停留多久。如果来源日志保留了相应事件，就有机会重新加工；如果只留下每天一个访问量数字，后面就无法凭空恢复细节。2、一个能用的数据湖，至少要能完成四件事能力缺少它会怎样存储文件无处可靠保存，生命周期无法管理目录与元数据不知道数据在哪、字段是什么意思、版本有什么变化计算数据存着，却无法清洗、关联或查询治理不知道谁能访问、哪些数据可信、问题由谁负责例如：把浏览日志放进湖里，也不会自动得到“转化率”。还要定义一次访问是什么、怎样识别用户、订单归属哪个渠道，以及重复上报怎么处理。稳定下来后，这些规则可以进入公共分析模型。一般来说，数据湖保留分析材料，数仓组织可信的分析结果。它们经常协作，也可能共享一套底层存储。六、第四步：大家都想用这些数据，数据中台负责把能力交付出去数据中台通常指一套面向跨业务复用的数据建设与运营体系，依托数仓、数据湖等基础，把数据标准、加工、治理和服务组织起来。数仓已经整理数据，中台多做了什么？数仓侧重分析数据的组织和加工；数据中台进一步关注这些数据如何被多个业务持续使用，包括发现数据、理解口径、申请权限、调用服务、跟踪质量以及维护责任。数据服务也不只是开放一个查询接口。在线应用需要低延迟时，通常要把计算好的标签发布到适合在线查询的数据库或缓存，再通过服务访问；不能让每次打开会员页面，都现场扫描 30 天的交易数据。这里还可以顺便区分业务中台：会员注册、下单、发券属于可复用的业务操作；消费指标、用户标签、分析数据属于可复用的数据能力。前者偏业务中台，后者偏数据中台，两者通过服务协作。七、把全过程连起来：一笔数据怎样被反复使用？下面是一种常见组合，箭头表示数据流向，括号说明用途：订单、支付、退款数据库├─ 定时抽取或变更同步 → 数仓加工 → 指标、报表└─ 来源数据保留 → 数据湖↑ ↓ 按需要加工浏览日志、图片、客服记录 → 数据湖 → 探索分析、模型训练公共明细、指标、标签└─ 发布到服务存储 → 数据接口 → 营销、客服等业务应用数据中台建设涉及以上多个环节：标准、目录、权限、质量、责任与服务复用数仓可以直接接收业务数据，也可以从湖中加工；湖与仓可以共享存储，并不一定对应两套独立集群。业务数据库也可能同时向多个下游提供数据。湖仓一体放在哪里？湖仓一体主要在存储与分析架构这一层，尝试在湖的存储基础上补充表管理、事务、治理和查询优化等能力，让多种分析任务更方便地共享数据，减少不必要的复制。八、小结数据库负责把一笔笔业务可靠地记录下来；数据仓库把分散的记录按明确的粒度和口径整理成可分析的数据；数据湖保存和管理日志、图片、文件等多样的数据，为后续探索和重新加工留下材料；数据中台则把这些数据能力组织成多个团队可以持续复用的指标、标签和服务。它们各有分工，也存在重叠，可以按需要组合使用。
一、前言“数据库存数据，数仓做分析，数据湖什么都能放，中台负责共享。”但真到了项目里，还是容易困惑：MySQL 也能做统计，为什么还要数仓？数据湖已经存了所有数据，为什么不能直接出报表？买一套数据平台，是不是就有中台了？本篇我们就用一个网店的例子来重新认识一下。二、先看全局：它们解决的是不同层面的问题概念它要回答的问题常见交付物业务数据库这笔业务现在是什么状态，怎样正确地修改它？订单、库存、支付等业务记录数据仓库怎样把多处数据按一致规则整理，得到可信的分析结果？业务报表、分析模型、汇总指标数据湖怎样保存和管理多种形态的数据，供不同用途加工？原始文件、日志、图片及加工后的数据表数据中台怎样让多个团队持续复用可信的数据能力？公共指标、数据目录、标签、数据服务及管理规则前三者更多涉及数据如何存储、组织和处理，数据中台还涉及谁维护数据、怎样共享、如何交付给业务。三、第一步：顾客下单，数据库先保证正常交易假设网店正在促销，一双鞋售价 200 元。顾客下单后，系统至少需要记录订单、支付结果和库存变化。如下例子：订单号用户商品实付金额订单状态A001U01S01200已支付A002U02S01200待支付客服打开 A001，要立刻看到这笔订单；支付通知到达后，系统要正确更新状态；只剩一双鞋时，两个人同时购买，库存不能被无条件扣两次。这就是交易型数据库主要面对的工作：频繁处理小范围的读写，而且要配合业务逻辑维护正确性。通常称为OLTP，即联机事务处理。那么问题来了，数据库也能统计，为什么还需要别的系统？网店规模小时，统计当天的支付金额，直接查询业务数据库就能完成。但“查订单 A001”和“按渠道比较过去一年的退款率”是两种很不同的工作：对比项查一笔订单分析一年经营情况读取范围通常少量记录可能扫描大量记录主要操作精确查询、插入、更新筛选、关联、分组、汇总组织数据时优先考虑业务正确、写入方便、响应及时分析方便、历史可比、口径一致常见工作类型OLTPOLAP，即联机分析处理分析查询可能与下单争抢 CPU、内存和磁盘资源。这也是为什么“把 MySQL 配置调大”和“建设数仓”并不等价。前者主要增加处理能力，后者还要重新组织分析所需的数据。四、第二步：活动结束，数仓把数据整理成能算清的账活动结束后，领导问：“这次活动卖得怎么样？”运营查订单，财务查支付，售后查退款，三个部门交上来三个数字。先别急着判断谁算错了，他们可能回答的是不同问题。看一组假设数据：订单号下单金额成功支付金额已成功退款金额A0012002000A00220000A003300300100合计700500100这些数都可以成立，但实际扣除成功退款后的400 元，其实是不等于利润，更不能直接等同于财务确认的收入；利润分析还要考虑商品成本、广告费、履约费用等，财务收入则有相应的确认规则。数仓的价值，是把业务规则落实成能够重复计算、追溯来源的数据模型。它需要整合订单、支付、退款等来源，处理重复和异常，保存分析需要的历史，再形成公共明细与指标。1、算指标之前，先确定“一行代表什么”这叫数据的“粒度”，是数仓建模里最实用的概念之一。一行可以代表一笔订单、一件订单商品，也可以代表一次退款。它们不能随便混用。假设 A003 实付 300 元，后来分两次各退 50 元。如果把订单表直接关联退款明细，结果会变成：订单号支付金额本次退款金额A00330050A00330050这时直接汇总支付金额，会得到 600 元。SQL 没报错，数字却翻倍了。一种处理办法是先按订单汇总退款，再和每订单一行的支付结果关联。这样才能得到“支付 300、退款 100、净支付 200”。2、事实和维度，让分析有统一的组织方式“支付了 200 元”是发生的业务事实；“是哪位用户、什么商品、来自哪个渠道、发生在哪天”是分析它的角度，这些角度叫维度。可以简单记成：事实记录发生的事件，以及金额、数量等度量。维度描述事件的背景，让我们能按商品、时间、地区等角度观察。整理之后，同一份可信的支付明细，既能按天统计，也能按渠道比较，不必每张报表都重新理解一遍订单状态。业务库里可能有历史订单，并不代表分析所需的所有历史属性都已经保留下来了。3、分层，是为了让整理过程可以复用和追查项目里常见的数仓分层，可以落到这次活动上理解：常见层次这层做什么活动案例中的内容ODS，接入层接入来源数据，保留必要的来源信息订单、支付、退款来源记录DWD，明细层清洗、去重，按明确粒度整理业务事实每次成功支付、每次成功退款DWS，公共汇总层汇总高频使用的数据用户每天的支付金额、退款金额ADS，应用层面向具体报表或应用提供结果活动经营日报、渠道效果报表分层带来的实际好处是：报表错了，可以往上游追；新报表来了，可以复用已有明细和汇总；业务规则调整，也能定位需要重新加工哪些数据。五、第三步：想知道为什么有人没买，数据湖提供更多分析材料现在我们知道了支付金额，但领导又问：“广告点击很多，为什么最后买的人少？”光看订单不够。没有下单的人，根本不会出现在订单表里。需要进一步查看广告点击、页面浏览、加入购物车等行为。也许还要看商品图片、评价、客服对话，判断是不是图片误导、尺码描述不清楚。这些数据形态各异，未来用途也不一定一开始就能确定。数据湖适合把它们纳入统一的存储与管理范围，并保留足够的信息供后续加工。1、湖和仓，差别不只是“一个乱，一个整齐”数仓通常围绕相对明确的分析主题组织数据；数据湖通常更强调保留多样的数据形态，支持探索和多种加工用途。例如，一条浏览日志可能包含页面、时间、设备和活动编号。今天只分析访问量，下个月想研究用户在尺码说明页停留多久。如果来源日志保留了相应事件，就有机会重新加工；如果只留下每天一个访问量数字，后面就无法凭空恢复细节。2、一个能用的数据湖，至少要能完成四件事能力缺少它会怎样存储文件无处可靠保存，生命周期无法管理目录与元数据不知道数据在哪、字段是什么意思、版本有什么变化计算数据存着，却无法清洗、关联或查询治理不知道谁能访问、哪些数据可信、问题由谁负责例如：把浏览日志放进湖里，也不会自动得到“转化率”。还要定义一次访问是什么、怎样识别用户、订单归属哪个渠道，以及重复上报怎么处理。稳定下来后，这些规则可以进入公共分析模型。一般来说，数据湖保留分析材料，数仓组织可信的分析结果。它们经常协作，也可能共享一套底层存储。六、第四步：大家都想用这些数据，数据中台负责把能力交付出去数据中台通常指一套面向跨业务复用的数据建设与运营体系，依托数仓、数据湖等基础，把数据标准、加工、治理和服务组织起来。数仓已经整理数据，中台多做了什么？数仓侧重分析数据的组织和加工；数据中台进一步关注这些数据如何被多个业务持续使用，包括发现数据、理解口径、申请权限、调用服务、跟踪质量以及维护责任。数据服务也不只是开放一个查询接口。在线应用需要低延迟时，通常要把计算好的标签发布到适合在线查询的数据库或缓存，再通过服务访问；不能让每次打开会员页面，都现场扫描 30 天的交易数据。这里还可以顺便区分业务中台：会员注册、下单、发券属于可复用的业务操作；消费指标、用户标签、分析数据属于可复用的数据能力。前者偏业务中台，后者偏数据中台，两者通过服务协作。七、把全过程连起来：一笔数据怎样被反复使用？下面是一种常见组合，箭头表示数据流向，括号说明用途：订单、支付、退款数据库├─ 定时抽取或变更同步 → 数仓加工 → 指标、报表└─ 来源数据保留 → 数据湖↑ ↓ 按需要加工浏览日志、图片、客服记录 → 数据湖 → 探索分析、模型训练公共明细、指标、标签└─ 发布到服务存储 → 数据接口 → 营销、客服等业务应用数据中台建设涉及以上多个环节：标准、目录、权限、质量、责任与服务复用数仓可以直接接收业务数据，也可以从湖中加工；湖与仓可以共享存储，并不一定对应两套独立集群。业务数据库也可能同时向多个下游提供数据。湖仓一体放在哪里？湖仓一体主要在存储与分析架构这一层，尝试在湖的存储基础上补充表管理、事务、治理和查询优化等能力，让多种分析任务更方便地共享数据，减少不必要的复制。八、小结数据库负责把一笔笔业务可靠地记录下来；数据仓库把分散的记录按明确的粒度和口径整理成可分析的数据；数据湖保存和管理日志、图片、文件等多样的数据，为后续探索和重新加工留下材料；数据中台则把这些数据能力组织成多个团队可以持续复用的指标、标签和服务。它们各有分工，也存在重叠，可以按需要组合使用。