一、前言“数据库存数据数仓做分析数据湖什么都能放中台负责共享。”但真到了项目里还是容易困惑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 天的交易数据。这里还可以顺便区分业务中台会员注册、下单、发券属于可复用的业务操作消费指标、用户标签、分析数据属于可复用的数据能力。前者偏业务中台后者偏数据中台两者通过服务协作。七、把全过程连起来一笔数据怎样被反复使用下面是一种常见组合箭头表示数据流向括号说明用途订单、支付、退款数据库├─ 定时抽取或变更同步 → 数仓加工 → 指标、报表└─ 来源数据保留 → 数据湖↑ ↓ 按需要加工浏览日志、图片、客服记录 → 数据湖 → 探索分析、模型训练公共明细、指标、标签└─ 发布到服务存储 → 数据接口 → 营销、客服等业务应用数据中台建设涉及以上多个环节标准、目录、权限、质量、责任与服务复用数仓可以直接接收业务数据也可以从湖中加工湖与仓可以共享存储并不一定对应两套独立集群。业务数据库也可能同时向多个下游提供数据。湖仓一体放在哪里湖仓一体主要在存储与分析架构这一层尝试在湖的存储基础上补充表管理、事务、治理和查询优化等能力让多种分析任务更方便地共享数据减少不必要的复制。八、小结数据库负责把一笔笔业务可靠地记录下来数据仓库把分散的记录按明确的粒度和口径整理成可分析的数据数据湖保存和管理日志、图片、文件等多样的数据为后续探索和重新加工留下材料数据中台则把这些数据能力组织成多个团队可以持续复用的指标、标签和服务。它们各有分工也存在重叠可以按需要组合使用。