很多企业的数据仓库其实并不差。 ODS、DWD、DWS、ADS分层完整，ETL每天稳定运行，报表第二天早上也能准时出来。 但业务部门还是会越来越频繁地问： 为什么昨天的问题，今天才看到？ 上午订单突然下降，下午还拿不到完整数据； 库存已经见底，经营看板上的数字却停留在几个小时前； 促销活动正在进行，运营却要等活动结束以后，才能知道哪个渠道出了问题。 传统数仓依然有价值，只是企业使用数据的时间点正在不断前移。 过去，数据主要用于周报、月报和经营复盘；现在越来越多场景要求数据进入业务过程，在问题发生的时候就参与判断。
一、传统数仓最大的问题，是数据新鲜度开始跟不上业务了 传统数仓最典型的运行方式，是批处理。 业务系统白天持续产生订单、库存、客户、生产等数据，到了固定时间统一抽取，再经过清洗、转换、汇总进入数仓。 过去这种方式完全够用。 因为企业最常回答的是： 昨天销售多少？ 这个月完成率是多少？ 哪个区域利润下降了？ 这些问题晚几个小时甚至一天，并不会真正影响决策。 但现在很多业务问题已经变成： 刚刚发生了什么？
电商大促期间，10分钟内订单转化突然下跌； 生产线上某台设备连续出现异常指标； 门店核心商品库存快速下降； 某类异常交易在短时间内集中出现。 这时候，数据除了准确，还必须足够"新"。 假设业务要求5分钟内发现库存异常，但数据仓库每天凌晨才同步一次，那么第二天得到的数据即使完全准确，也已经错过了最佳处理时间。 所以很多企业改造实时数仓时，最先调整的往往是数据入口。 订单、库存、交易这类高频变化的数据，如果每天凌晨再统一抽取一次，数据量越大，扫描成本和同步窗口都会跟着增长。 用 FineDataLink 5.0 做这一层时，可以先完成存量数据初始化，之后再根据数据库日志持续捕获新增、修改和删除，把变化及时送到下游。 这样原来以"天"为周期的数据进入方式，就可以逐渐缩短到分钟级甚至更低，后面的实时计算才有数据可用。 如果数据入口本身还是T+1，后面的计算层、指标层再快，也很难真正实现实时。
二、实时数仓，也不等于所有数据都要秒级更新 很多企业第一次谈实时数仓，很容易产生一个误区： 既然做实时，那是不是所有数据都应该秒级同步？ 完全没有必要。 财务月结，T+1可能已经足够； 管理层经营指标，15分钟甚至1小时更新一次也能满足要求； 订单履约、库存预警，可能需要分钟级； 反欺诈、设备告警等场景，才真正需要秒级响应。 所以实时数仓建设之前，应该先定义一个非常重要的东西： 数据SLA。
也就是不同业务究竟允许多大的数据延迟。 企业完全可以把数据分成几类： 秒级数据：风险识别、设备状态、实时交易； 分钟级数据：库存、订单、物流、营销活动； 小时级数据：经营监控、门店表现、部分供应链指标； T+1数据：财务结算、历史报表、大规模经营分析。 这一步看起来简单，但它直接决定后面的架构成本。 因为实时意味着持续占用计算、存储、网络和运维资源。 一张每天只变化几十条的组织架构表，没有必要设计秒级CDC； 一张每分钟产生几十万条记录的交易表，如果每天还在全量扫描，也明显不合理。 所以实时数仓真正成熟的地方，在于： 不同数据采用不同的处理速度。 技术架构不需要追求"全部实时"，而是要让数据时效和业务价值匹配。
三、真正的架构变化：从"处理一批数据"变成"处理一次变化" 传统ETL通常处理的是一个数据集合。 例如凌晨2点任务启动： 找出昨天新增的订单； 清洗字段； 关联客户信息； 完成主题汇总； 最后写入ADS。 整个过程更接近： 一批数据到了，再统一处理。 实时架构面对的却是一连串持续发生的变化： 订单A创建； 订单A付款； 订单A退款； 客户B修改地址； 商品C库存减少。 因此实时数仓里非常关键的一个概念就是CDC，也就是Change Data Capture。
它关注的是数据库刚刚发生了哪些变化。 数据链路也随之发生改变。 传统模式通常是： 业务库 → 定时抽取 → ETL → 数仓 实时模式则会逐渐变成： 业务库 → CDC → 消息系统 → 实时计算 → 数仓 但CDC把变化抓出来以后，事情还没有结束。 真实业务里的变化数据，经常还要继续做解析、过滤、字段转换、关联甚至计算。 尤其是Kafka里的消息，很多本身就是JSON等半结构化数据，不能直接原样写进最终分析层。 这一步可以继续接到 FineDataLink 5.0 的实时任务里，从Kafka持续读取数据，在流转过程中完成JSON解析、字段处理和必要的转换，再把结果写入下一层；中间处理后的数据也可以继续输出到Kafka，交给后续任务继续加工。 到了这里，实时数仓处理的就不再只是一条数据库变更记录。 它需要让这条变化沿着整个数据链路持续流动，逐渐转化成业务真正能够使用的数据。 这也是实时架构复杂度明显高于传统批处理的地方： 数据不再等齐以后统一计算，而是在持续到达的过程中不断被处理。
四、实时数仓真正拉开的差距，是让数据进入业务过程 如果只是把早上8点才能看到的报表，提前到凌晨1点，其实只是把离线处理做得更快。 实时数仓更大的变化，是数据开始参与正在发生的业务。 假设一家零售企业发现某门店当天销售额下降20%。 传统模式下，第二天经营会上才看到这个问题，然后再往下拆： 客流下降了吗？ 转化率变了吗？ 商品缺货了吗？ 客单价有没有下降？ 最后发现，真正原因是下午某款爆品断货。 原因找到了，但当天的销售机会已经过去。
如果订单、库存、门店销售数据持续进入分析层，情况会完全不同。 下午2点，销量开始异常； 继续下钻，发现客流没有明显变化； 再看商品结构，某个核心SKU销量突然归零； 进一步查看库存，发现已经低于安全库存。 此时分析的下一步就会变成： 附近仓库有没有货？ 能不能马上补？ 其他门店是否也出现同样问题？ 当订单、库存、物流这些数据已经能够及时汇总，后面还要解决一个问题： 结果怎么送到真正需要它的业务环节？ 经营看板是一种出口，但并不是唯一出口。 有些库存结果需要返回业务系统，有些异常指标要交给预警应用，有些加工好的数据还要提供给其他系统继续调用。 这时候，FineDataLink 5.0 的数据服务可以把已经加工、融合的数据发布成API，让下游系统继续使用；一些外部数据也可以通过接口进入后续数据处理链路。
这样实时数据的流向就不只停留在数仓和看板内部，还可以继续进入预警、业务系统以及其他数据应用。 实时数仓的价值，也就从"更早看到结果"进一步延伸到： 更早触发下一步动作。 对于零售、制造、电商、物流、风控这些场景来说，这几个小时甚至几分钟的时间差，往往就是实时数仓最直接的意义。
五、实时数仓真正难的，往往是跑起来以后 很多实时项目建设初期，团队最关注的是： Kafka搭好了没有？ CDC通了没有？ 实时任务有没有运行？ 实时表有没有数据？ 但系统真正连续运行一段时间以后，问题才会逐渐暴露出来。
为什么实时数字和第二天离线数字不一样？ 这是非常典型的问题。 例如实时系统显示： 今日销售额1000万。 第二天离线数仓重新计算以后，却变成了980万。 原因可能很多： 退款晚到了； 部分订单被取消； 维度信息发生变化； 实时和离线使用了不同过滤条件； 迟到数据没有进入原来的统计窗口。 如果长期存在两个结果，业务最终一定会问： 到底应该看哪个？ 所以实时数仓必须解决实时口径和离线口径统一的问题。 指标定义、过滤规则、业务状态、维度关系最好尽量共享。 否则很容易形成两套逻辑： 实时任务写一套； 离线SQL再写一套。 时间久了，同一个"销售额""有效订单""库存金额"，可能出现不同版本。
数据迟到怎么办？ 现实世界的数据不会严格按照发生时间进入系统。 一笔10:01发生的订单，可能10:05才进入消息队列； 一台设备因为网络中断，半小时以后才补传数据。 这时候就会涉及： 事件时间、处理时间、统计窗口、迟到数据、结果修正。 如果系统完全按照数据到达时间计算，那么一部分迟到数据就可能被遗漏。 所以实时计算真正复杂的地方，是既要尽快出结果，又要给迟到数据留下修正空间。 很多时候，实时指标本身就是一个不断趋近最终结果的过程。 怎么知道实时链路没有丢数据？ 这是另一个很容易被忽略的问题。 任务显示绿色，只能说明程序还在正常运行。 但源端100万条变化，目标端最终是不是完整写入了100万条，仍然需要额外确认。 因此实时数仓运行以后，还需要持续关注： 源端和目标端数据量、关键字段一致性、同步延迟、消息积压、任务异常和断点恢复情况。 这一环节也可以直接放进数据同步链路里。 FineDataLink 5.0 的实时管道支持对来源端和目标端做数据一致性检测，定期核对上下游数据。某张表出现记录缺失或者内容偏差时，可以顺着同步链路继续排查，不用等到业务看报表时才发现数字对不上。 对于长期运行的实时任务来说，同步完成只是第一步，后面还需要持续确认数据有没有完整、准确地落到下游。
六、传统数仓最终会被实时数仓替代吗？ 大概率不会。 两类架构解决的问题并不完全一样。 实时数仓更擅长： 快速感知变化、持续计算、即时监控。 传统离线数仓依然擅长： 大规模历史计算、复杂关联、全量重算、周期性经营分析。 例如一张历史订单事实表有几十亿条数据，要重新计算过去三年的客户生命周期价值，没必要让实时任务持续承担这种工作。 财务月底结账以后，需要按照最终口径重算收入、成本和利润，同样更适合离线批处理。 所以企业最终更常见的架构，是： 实时 + 离线并存。 实时链路负责最新订单、库存、设备状态、实时指标和异常变化； 离线链路负责历史数据、复杂加工、财务核算、长期趋势和大规模重算。 然后再通过统一的数据模型、指标体系和数据服务，把两条链路的结果对齐。 这比追求所有任务都实时更现实。 因为一个成熟的数据架构，最终考虑的始终是三个问题： 业务什么时候需要数据？ 为了这个时效，需要付出多少成本？ 这个结果能不能长期稳定地保证准确？
写在最后 传统数仓越来越"不够用"，并不意味着传统数仓已经过时。 真正变化的是企业提出的问题。 过去更多是在问： 昨天发生了什么？ 现在越来越多业务开始问： 现在发生了什么？ 再往前一步，则是： 接下来应该做什么？ 数据系统面对的要求也随之改变。 过去，只要第二天能够把结果算清楚，很多业务就已经够用了。 现在还要继续考虑： 数据多久能进来、变化多久能被处理、实时和离线结果能不能对齐、链路中断以后能不能恢复、长期运行以后有没有发生数据偏差。 所以实时数仓真正缩短的，是业务事件发生到数据能够参与决策之间的时间差。 判断一家企业到底需不需要实时数仓，其实可以先问一个很简单的问题： 一个经营问题刚刚发生时，我们多久以后才能从数据里看到它？ 如果答案仍然是第二天，而业务已经要求当天、小时级甚至几分钟内采取行动，那么真正需要升级的，往往就是背后的整条数据链路。
