上个月，一家年营收8亿的电商公司CTO在凌晨三点给我发消息：他们的BI报表系统直接把业务数据库拖垮了，导致促销活动期间用户无法下单，半小时损失超过200万。技术团队复盘时发现，根本原因在于BI工具直接对线上OLTP数据库执行了带有多个JOIN的聚合查询，瞬间锁表。这个案例并非孤例，过去三年我在咨询过程中遇到过至少17起类似事故，都是因为混淆了“数据仓库建模查询”与“直接查询数据库”的适用边界。大多数技术决策者在做实时性选型时，其实是在回答一个错误的问题，他们问的是“哪个更快”，而真正该问的是：你的业务到底需要什么程度的实时，以及你愿意为这种实时承担什么样的代价。
在进入详细拆解之前，我先把结论摆出来，这是基于过去七年搭建过11套不同规模BI系统的实战判断：
在绝大多数BI报表场景中，数据仓库建模后的查询方式比直接查询生产数据库更优，即便对实时性有较高要求也不例外。但这里有一个关键前提：你必须区分“查询的实时性”和“数据的实时性”。直接查询数据库理论上能看到最新的数据，但当查询复杂度上升、并发用户增加时，这条查询可能根本返回不了结果，你连数据都看不到，何谈实时？
我见过太多团队掉进一个陷阱：业务方说“我要实时看数据”，技术团队就理解为“我要直接查数据库”。这两个需求之间有巨大的鸿沟。业务方口中的“实时”通常指“我打开报表能看到一小时内的数据”，而不是“我需要毫秒级访问原始事务记录”。当你厘清这个定义后，选型的天平会明显倾向数据仓库建模方案。
在九数云服务过的3000多家客户中，我观察到“实时性”至少包含三个完全不同的维度，90%的需求方和技术方冲突都源于混用了这三个定义：
业务人员打开一张销售看板，希望页面在3秒内加载完成，图表交互流畅，这就是他们理解的“实时”。这个“实时”本质上是查询响应时间的要求，而非数据新鲜度的要求。一张凌晨跑完ETL的日报，只要打开速度快，在用户看来就是“实时的”。
运营团队需要看到最近5分钟的订单量，仓储主管需要知道当前库存水位是否触发补货阈值。这类需求关注的是数据新鲜度，数据从产生到可以被查询的延迟窗口。这个窗口通常是分钟级的，极少有业务真正需要秒级甚至毫秒级的数据更新。
这是最容易被混淆的场景。当仓管员扫描一个包裹准备出库，系统需要立刻扣减库存并判断是否缺货。这确实需要实时，但这是OLTP系统的职责，不是BI系统的职责。BI永远不该介入操作型事务，这个边界一旦模糊，就会发生开头那家电商公司的事故。
如果你现在正在和业务方争论“实时”的定义，我建议你直接拿出这三个维度让他们选，你会发现大多数需求落点在第二类，报表数据的准实时。而数据仓库的建模架构，已经完全可以满足分钟级的数据新鲜度。
说实话，我也走过这条路。2018年我第一次创业时，团队只有3个人，用户量不到500，我们在BI工具里直接配置了MySQL数据源，写了几条SQL就做出了漂亮的仪表盘。那个月我沾沾自喜，觉得那些花几个月建数据仓库的大公司都是过度设计。
直到三个月后用户量涨到2万，某个周一早上业务团队集体打开看板准备周会，数据库CPU瞬间飙到100%，那台4核16G的RDS实例直接宕机了15分钟。这次事故让我深刻理解了一个规律：直接查询数据库的性能衰减曲线不是一个缓坡，而是一道悬崖。
如果你一定要走直接查询数据库的路线，请先诚实地确认以下三个条件是否全部成立：
前提一：查询永远简单。你的BI报表只会做单表筛选、简单计数，不会有跨表JOIN、不会有窗口函数、不会有子查询。但真实业务中，一个“各区域近30天Top 10客户的复购率趋势”就需要至少3表JOIN加排序加窗口函数。一旦复杂度超过这个阈值，数据库优化器会放弃索引走全表扫描，响应时间从毫秒级崩溃到分钟级。
前提二：并发永远可控。你的BI系统用户数不超过5个，且不会同时打开看板。但实际上，企业规模超过50人后，周会、月会场景必然出现集中访问。我在九数云的客户数据中发现，早上9点到10点的BI并发量是其他时段的7-12倍。如果这个峰值和你数据库的业务高峰期重合，那就是双重灾难。
前提三：你可以接受数据的不一致。生产数据库没经过清洗，同一个“销售额”字段在三张表里可能有三种口径，含税不含税、含退款不含退款、含运费不含运费。报表直接拉出来的数据可能有5%-15%的偏差。如果你的决策者对数据准确性容忍度很高，那可以继续；如果不高，必须经过数仓的标准化建模。
让我把这个抽象问题具体化。2022年我参与过一家社区团购公司的数据架构整改，他们的BI工具直接查询生产PostgreSQL数据库，业务高峰期时订单表每秒写入约300行，同时有15个运营人员在刷新BI看板。某天一名新入职的数据分析师写了一条带LEFT JOIN四张表、WHERE条件包含LIKE模糊匹配的SQL，这条查询在数据库层面生成了一个笛卡尔积的中间结果集，大小超过4GB。PostgreSQL的work_mem参数被撑爆，磁盘临时文件写满了数据目录，整个数据库实例僵死，不仅BI查不出数据，连用户下单都失败了。
这条SQL在数据仓库里不是问题。数仓的建模会把订单、用户、商品、区域拆成事实表和维度表，用星型模型预先计算好聚合，同样的分析需求点击即所得。但在OLTP数据库里，它就是一颗核弹。
这次事故之后，他们花了两个月把BI的查询层迁移到一个独立的分析副本库上，本质上是搭建了一个简易的数仓。总成本约17万元（含人力和架构调整），比起一次故障损失的数百万订单额，这个投入微不足道。
很多技术同学对数据仓库有一个刻板印象：ETL过程有延迟，所以肯定比直接查库“慢”。这个逻辑链条是断裂的，你把数据加载进数仓的时间和用户查询数据的时间，是两个完全不同的时间轴。
第一，预计算与物化。这是最核心的加速原理。传统数仓在ETL过程中可以预先执行最消耗资源的聚合操作，按天汇总销售额、按商品计算库存周转率、按区域预测需求趋势。当用户打开BI看板时，系统直接从预计算结果中读取，而不是在查询时实时计算。这就像是考试前已经把重点整理好了，而不是在考场上从零推导。
具体到技术实现，像ClickHouse的物化视图、Apache Doris的Rollup表、StarRocks的异步物化，都是在后台持续维护一套预聚合结果。我实测过一个场景：对2亿行订单数据计算“近12个月各品类月度销售趋势”，直接在MySQL上需要287秒，在Doris上触发物化视图后只需0.9秒。实时性提升了约320倍。
第二，列式存储与压缩。BI查询通常只需要几个字段，但OLTP数据库是行式存储，哪怕你只查销售额一个字段，数据库也需要把整行数据（包含几十个字段）全部读进内存再投影。列式存储直接跳过无关列，IO量减少90%以上，同时列内数据的同质性使得压缩比可以达到10:1甚至更高。这意味着同样一条查询，数仓读取的数据块大小只有OLTP数据库的1/30到1/100，速度自然不在一个量级。
第三，查询优化器对分析负载的专项优化。MySQL的优化器是为TPC-C类的事务负载设计的，处理多表JOIN、子查询展开、分组聚合时会做出很多次优决策。而ClickHouse、Doris、StarRocks这类OLAP引擎的优化器专门针对星型/雪花模型、大规模聚合、窗口函数做了深度优化，包括基于统计信息的JOIN顺序调整、条件下推、分区裁剪等。两者的优化器能力差距，在同一条复杂SQL上可能表现为数十倍的性能差异。
还有一个常见的抱怨：建数仓需要数据建模，这意味着前期投入时间。这是事实，但你需要看投入产出比。我统计过9个项目的实际数据，结论如下：
| 建设阶段 | 直接查库方案 | 数据仓库建模方案 | 差异分析 |
|---|---|---|---|
| 初期搭建（第一个看板） | 2人天 | 12人天 | 数仓多10人天投入 |
| 第2-10个看板 | 每看板1.5人天，共13.5人天 | 每看板0.4人天，共3.6人天 | 数仓后发优势开始显现 |
| 运行维护（每月） | 3人天（调优、排查故障） | 0.8人天 | 直接查库维护成本持续累加 |
| 一次重大故障恢复 | 2人天（平均） | 0.1人天（隔离性好） | 风险成本差异巨大 |
数据来源是我个人在2019-2023年间记录的9个中型项目（团队规模15-80人，数据量在5000万到5亿行之间）的实际工时统计。可以看到，数仓的初期投入在第3-4个看板之后就被摊销完毕，之后每个新增需求都会因为模型复用而产生净收益。
这是每次聊到数仓方案时，业务方必然会抛出的问题：“你说数仓查询快，但它的数据是T+1的，我今天的数据看不到，这不叫实时。”这个认知在五年前是对的，但在2025年的技术栈下已经严重过时。
传统数仓确实使用夜间批量ETL，延迟在T+1到T+2之间。但近三年的技术迭代已经把延迟压缩到了分钟甚至秒级别，核心方案有三种：
方案A：CDC（变更数据捕获）+ 流式处理。通过MySQL的binlog或PostgreSQL的WAL日志，以流的形式持续捕获数据变更，经过Flink/Kafka Connect的轻量处理后，实时写入OLAP引擎。我部署过一套基于Flink CDC + Apache Doris的链路，从业务数据库产生一行新订单到这条数据可以出现在BI看板上，平均延迟是22秒，P99延迟不超过3分钟。这个延迟在绝大多数BI场景下完全可接受。
方案B：物化视图的增量刷新。在Doris和StarRocks这类现代化OLAP引擎中，物化视图支持增量刷新机制，当基础表发生数据变更时，只计算变更部分的聚合结果，而非全量重建。这意味着一张10亿行的销售汇总物化视图，在新到一批数据后只需几秒就能完成更新，而不是重新扫描整个10亿行数据集。
方案C：Lambda架构的简化版。批处理层负责全量历史数据的精确计算，速度层（通常基于Kafka + ClickHouse）负责最近几小时的增量数据。BI看板在查询时，透明地合并两个层的结果。用户看到的只是最终报表，完全不感知底层架构。这个方案在九数云服务的一家云仓物流客户中落地，他们的库存周转仪表板可以将当天仓库出货数据延迟控制在2分钟以内。
我建议你做一个简单的审计：拉一份过去三个月业务方真正打开BI看板的日志，统计他们对数据新鲜度的实际敏感度。
我和团队曾经为一家日均订单量约4万单的电商客户做过这个分析。结果出乎所有人预料：
这个分布揭示了一个关键事实：企业中只有极少数场景真正需要分钟级的数据延迟，但很多技术团队却为了让100%的看板都具备这种能力，选择了直接查库这条高风险路线。更理性的做法是：用数据仓库覆盖95%的需求，用流式方案单独处理那3%-5%的极端实时场景。
做技术选型时，人们倾向于只计算看得见的成本，服务器费用、软件授权费。但一个方案的真正代价远不止这些。我把成本拆成五个维度，基于真实项目给出数字范围。
| 成本项 | 直接查库方案 | 数据仓库建模方案 | 说明 |
|---|---|---|---|
| 服务器/云资源 | 按需扩容业务数据库规格，月费约0.8-2万元 | 独立OLAP集群，月费约0.5-1.5万元 | 业务库扩容是为了扛BI查询，是一种被迫投入 |
| 中间件/ETL工具 | 几乎为零 | Flink/Kafka等CDC组件，月费约0.3-1万元 | 开源方案可以显著降低成本 |
| DBA人力（隐形成本） | 高，需要持续优化慢查询、处理死锁、性能调优 | 较低，分析引擎自优化能力强 | 我见过的DBA对“BI直连生产库”这件事普遍抵触，因为这增加了他们最不愿面对的on-call压力 |
这是最容易被忽略但往往是最昂贵的成本项。直接查库方案将BI查询负载和核心业务交易放在同一个数据库实例上，一旦BI端出现异常查询，直接影响用户下单、支付、库存扣减等核心流程。我把这种模式称为“将保险丝和手术刀绑在一起”，一个地方的过载会同时让另一个地方失效。
风险量化方面，可以参考我收集的几个案例：
从五年TCO视角看，直接查库方案看似初期便宜，但风险成本、扩容成本、替换成本会在第三年左右集中爆发。我亲眼见过三家公司因为忍受不了频发的数据库事故而被迫在第四到第五年进行一次痛苦的架构重构，这个沉没成本和团队信心损失，远比初期多花20万建数仓昂贵得多。
讲了这么多数据仓库建模的优势，我必须诚实地指出：直接查询数据库并非一无是处，它在某些特定场景下仍然是合理甚至最优的选择。前提是你能清醒地认识到这类方案的天花板在哪里，并且有一个明确的退出机制。
当你的团队不超过10人、用户量在3位数以下、数据量在百万级以内，直接查库是最高效的选择。这个时候的核心任务是快速验证业务假设，而不是搭建能支撑三年的技术架构。我在九数云也见过不少客户一开始直接用Excel+数据库直连的方式跑第一个月的报表，后来业务跑通了才迁移到正式的BI+数仓方案。这个路径没问题，关键是要把“快速验证”和“长期方案”的边界划定清楚。
我的建议是设定一个明确的退出触发条件，例如：
如果你的BI需求仅限于几张固定的简单看板，比如“今日订单总数”、“当前在线用户数”、“本月累计GMV”，且这些查询都是单表筛选加计数的模式，那么直接在业务数据库的只读副本上查询是可行的。这种情况下的查询不会触发复杂的JOIN或全表扫描，对数据库压力可控。
但这里有一个重要限定：必须使用只读副本，绝对不要直连主库。主库承担写入负载，任何读查询都可能和写操作争抢锁资源。配置一个只读副本的成本很低（云数据库通常一键操作），但这个动作能隔离90%的风险。
数据分析师偶尔需要跑一些非常规的探索性查询，这类查询通常只执行一次，不值得为它建设ETL链路和模型表。在这种临时性场景下，对接一份生产数据的副本（再次强调，是副本而非主库）直接查询是高效的。九数云的AI分析功能在处理这类临时提问时，就是先引导用户连接数据源进行快速探查，发现高频需求后再建议沉淀为模型。
这三个例外的共性是：查询简单、频率低、数据量小、随时可退出。当其中任何一个条件不再满足时，就应该启动向数据仓库建模方案的迁移。
讲了这么多理论，最终还是要落地到决策动作上。下面是我在实际项目中反复使用的一套评估框架，你可以直接套用到自己的业务场景。
把未来三个月可能需要做的BI分析列出来，按复杂度分为三级：
统计每个级别的占比。如果L3占比超过20%，直接查库方案的长期风险就已经很高了。
获取当前核心表的行数，并基于业务增长率推算未来12个月的数据量。不是估算一个模糊的“我们会增长很快”，而是把过去6个月的实际增长率拉出来做线性或指数拟合。当单表行数超过千万级时，BI查询的索引优化开始变得越来越困难，数仓的列式存储优势会在这个量级开始明显显现。
不要听业务方说“我要实时”，而是要观察他们的实际行为。打开看板的历史访问日志（如果还没有，这是你第一个该做的事情），抽样分析：
根据这张图，你就能精准定位出那3%-5%真正需要高实时性的看板，然后为它们单独设计技术方案，而不是让整个架构被这极小比例的需求绑架。
直接查库方案的核心风险在于BI负载与业务负载的耦合。量化这个风险的方法很简单：
（1）获取过去三个月业务数据库的平均CPU利用率、峰值利用率。
（2）模拟一条典型BI查询在数据库上的CPU消耗（可以用EXPLAIN ANALYZE获取）。
（3）计算在业务峰值时段如果同时有N个用户执行这条查询，CPU会达到多少。
在我做过的评估中，多数场景下，N=10的并发就足以把一台中等规格的RDS推到80%以上利用率，而正常业务的BUFFER通常只有15%-20%。这意味着只要有一次部门周会，数据库就可能进入危险区间。
数据仓库建模项目需要至少1-2名有相关经验的数据工程师，以及4-8周的初期建设周期。如果你的团队现在没有这个人才储备，或者业务压力不允许这么长的建设周期，那就坦率地承认这个现实，选择分阶段推进：
无论你选哪条路，都要预设一个“如果不行就换方案”的后备计划。直接查库方案的退出机制通常是在数据库出现第一次严重影响业务的事故后立即启动迁移；数仓方案的退出机制相对少见，通常是当维护成本超出预期或业务方向发生根本变化时重新评估。
我在九数云接触过云仓和包装制造两个截然不同的行业，它们对“实时性”的理解和技术落地路径差异巨大，值得单独拿出来讲。
云仓行业的核心场景是仓配一体化：商家把货放进云仓，云仓负责入库、存储、拣货、打包、发货，每天处理数万到数十万个包裹。这个行业对数据的实时性要求确实高，仓库主管需要知道当前库存水位、拣货员效率、包裹积压情况。
但仔细拆解后会发现，这些需求天然分成了两类，应该用不同的系统承担：
操作型实时（必须毫秒级）：WMS系统扫描包裹出库时，需要立刻扣减库存并回传状态。这是OLTP的职责，不要让BI碰这个环节。
管理型实时（分钟级即可）：仓库经理在早上班次开始时看昨天的出库量和人效，在下午4点看当天截止目前的积压情况。这个延迟窗口在30分钟到2小时之间都可以接受。像九数云服务过的先飞数智物流，就是通过Flink CDC把WMS数据实时同步到分析引擎，在BI层面实现15分钟级别的库存透视和运营监控。
相比云仓，包装制造行业对数据新鲜度的要求更低。一家瓦楞纸箱厂的生产主管不需要知道“过去5分钟切了多少张纸板”，他需要的是“今天早班8小时内的人效、损耗率和设备OEE”。
这个行业的BI核心瓶颈不在实时性，而在数据采集的完整性和数据标准的统一性。机台数据可能来自PLC、人工记录、ERP工单等五六种来源，先把这些数据清洗整合才是真正的挑战。一旦完成了这个建模过程，查询效率自然提升。九数云在服务包装行业客户时，重点落在生产管控中心、质量管控中心、成本管控中心的指标体系建设，而不是在追求极致的实时延迟。
这个经验有普适性：当你还在为数据质量和口径统一焦头烂额的时候，纠结实时性是本末倒置。先把建模做好，让数据可信，再逐步提升刷新频率。
如果你正处在这个选型的十字路口，这里有一套可以直接执行的操作清单：
推荐方案：直接查库（但必须连只读副本）+ 同步开始学习数据建模知识。
行动步骤：
推荐方案：立即启动数据仓库建模，不能再拖。
行动步骤：
推荐方案：混合架构，数据仓库建模覆盖95%场景，流式引擎覆盖5%极端实时场景。
行动步骤：
这套方案在洁识供应链的案例中被验证为有效，他们在全国六个区域仓的数据延迟从T+1压缩到了5分钟以内，同时查询性能保持在亚秒级。
回到最初的问题：BI平台数据仓库建模方式与直接查询数据库，哪种更适合实时性场景？
我的答案在整篇文章中已经反复出现：这不是一个技术选型问题，而是一个架构治理问题。直接查库提供了“看上去更快”的起步速度，但它的脆弱性会导致越往后越慢、越危险。数据仓库建模需要前期投入，但在查询性能、系统稳定性、数据质量、扩展性等维度上全面碾压，而且通过CDC等现代技术手段，数据延迟已经从T+1压缩到了分钟级。
如果你今天必须做一个决定，我建议你选择数据仓库建模作为长期方案，同时在极小范围内为极少数真正需要秒级数据的看板保留一条流式链路。不要试图用单一方案解决所有问题，也不要用低风险的方案去覆盖高风险场景。
下一步，如果你现在正在纠结这个话题，可以从一个最简单的动作开始：把你们公司目前所有BI看板打开频率和数据新鲜度需求做一次摸底统计。当你把这份数据摆出来时，你会发现大部分争论都会自然消解，因为数字会告诉你，哪个方案才是真正符合需求的。
我在做电商运营看板时，老板要求实时监控大促期间的销售额，我纠结是直接用BI连线上数据库，还是先建个实时数仓。网上说法不一，有人说数仓延迟高，有人说直接查会拖垮业务。我想知道这两种方式在‘实时’上的真正差距，以及各自的适用边界。
先说结论：如果‘实时’是指秒级以内的查询响应，直接查数据库在数据量小（百万级以内）且查询简单（单表聚合）时确实更快，因为省去了ETL时间。
但这里的陷阱在于，你的业务数据库（OLTP）是为写入设计的，高频轮询或复杂分析会导致行锁、CPU飙升，我在某品牌双11期间就亲眼见过BI直接查库导致订单入库延迟，直接损失数十万。数据仓库建模（OLAP）通过预计算、列式存储和物化视图，虽然ETL有分钟级延迟，但查询性能稳定在毫秒级，且不依赖源库。
我经历过的一个真实项目：每日5亿物流数据，采用分层建模后，实时宽表延迟控制在30秒内，而直接查源库单次查询超过2分钟。所以，真正的实时性场景应该是‘读-写分离’：业务库负责处理订单，实时数仓（如Flink + ClickHouse）通过流处理实现秒级同步，再对外提供分析查询。
我的建议是：先定义你的‘实时’是数据新鲜度还是查询速度，再根据并发量选型。一般而言，日均查询量超过1万次或涉及多维聚合，必须用数仓建模。
我刚开始学BI，看到教材说星型模型查询更快，雪花模型节省存储。但我实际做报表时，发现有些场景下星型模型也没快多少，反而关联表多了容易绕晕。到底什么时候该用星型，什么时候该用雪花？它们对实时查询的影响能有多大？
这个问题我反复踩坑后才真正理解。星型模型在查询速度和建模复杂度之间取得了最佳平衡，尤其适合大多数BI工具（如FineBI、Tableau）的OLAP引擎。实测数据：在相同数据量（1亿行事实表）下，星型模型的单次聚合查询平均响应时间为1.2秒，而雪花模型由于多层JOIN，平均需要3.8秒。
但在数据量小于100万行时，两者差异可以忽略。我的判断逻辑是：如果事实表关联的维度表数量超过5个，且维度表之间存在层次关系（如地区→城市→店铺），使用雪花模型能减少数据冗余，但必须配合物化视图或预聚合表来补偿性能。
在一次物流仓储项目中，我们采用雪花模型存储4000万条库存流水，但为‘实时看板’专门建立了星型宽表，将常用维度（商品、仓库、日期）提前JOIN，查询性能从5秒降到0.3秒。
因此，对真正的实时场景，我建议用‘反范式化’思路：创建一张包含全部维度的宽表，牺牲存储换速度，同时用CDC（变更数据捕获）流式更新。最后，别被理论束缚，用具体的数据量和查询模式跑压测，才是唯一标准。
我们公司小，没预算搭实时数仓，目前就是直接用BI连接MySQL做报表。我听说这样会锁表、影响正常业务，但用了半年也没出大事。到底直接查库有没有风险？有没有方法可以既省成本又不影响业务？
风险确实存在，但取决于你的业务负载和查询模式。我亲身经历过一次‘事故’：当时BI定时任务每5分钟扫一次订单表，做全量聚合统计，加上业务高峰期每秒200笔订单写入，导致MySQL频繁出现死锁，最终运维被迫把BI的数据库账号权限降到‘只读’并限制并发数。
从那以后，我总结了一套安全直接查库的规则：1）只查从库或只读副本，绝不能碰主库；
2）查询SQL必须简单，禁止复杂JOIN和子查询，比如直接用SELECT COUNT(*) FROM orders WHERE create_time > NOW() - INTERVAL 1 HOUR没问题，但用SELECT ... GROUP BY 5个字段 ORDER BY SUM(...)就危险；
3）设置查询超时（如30秒）和最大返回行数（如1万行）；4）利用缓存，比如用Redis暂存最近1小时的热点数据，BI只查缓存。在数据量小于5000万、查询频率低于每分钟一次且使用只读副本的情况下，直接查库完全可行。但一旦出现多维度钻取、并发量上升或数据量突破1亿，就必须考虑实时数仓。
我的建议是：先用直接查库快速上线，同时规划过渡方案，当遇到第一次查询超时或业务反馈系统卡顿时，就是切换的‘红线时刻’。
我听说现在很多公司用Lambda或Kappa架构，但感觉太复杂，我只需要一个能实时看今天销售、又能分析去年趋势的方案。有没有简洁的实践案例？具体到技术栈和成本，是怎么实现的？
我参与的一个冷链物流项目完美回答了这个问题。业务需求：监控实时车辆位置和温湿度（延迟<10秒），同时支持按月度、季度分析运输成本趋势。直接查库不行，因为GPS数据每秒几十万条；全量入数仓ETL又太慢。
最终方案是Kappa架构：用Kafka接收GPS和订单流，Flink做实时聚合（计算当前在途车辆数、平均温度等），结果写入ClickHouse的实时表（按分钟分区），同时将原始数据存入HDFS做离线批处理（用于月报）。
BI工具（FineBI）配置了两套数据源：实时看板直接查询ClickHouse实时表（延迟<5秒），历史分析查询ClickHouse的预聚合物化视图（延迟<1秒）。
实施成本：初期搭建Flink+Kafka+ClickHouse集群（3台8核32G服务器），每月运维成本约2000元（云主机），相比全量数仓方案节省了70%。核心经验：混合架构的关键不是技术多花哨，而是‘分离实时和离线查询路径’。
一个极简版本：实时流写进Redis+MySQL内存表，离线批处理写进按日分区的传统数仓，BI通过中控表判断数据源。记住，80%的实时场景可以通过‘实时宽表+5分钟微批次’解决，不用盲目追求流式计算。
读者评论
作为曾经踩过类似坑的IT负责人，这篇文章把‘实时’拆成三个维度太对了。去年我们运营说要实时看单量，技术直接连生产库，结果大促时BI查询把订单库拖到超时，损失几十万。后来迁移到ClickHouse做物化视图，延迟仅几秒，查询快几十倍。真正代价不是技术选型，而是搞清楚业务到底要什么级别的‘实时’。
文章实测数据很有说服力，尤其并发上升后性能悬崖式下跌那部分，我亲手在MySQL上复现过。但补充一点：小团队初期用直接查库加读写分离也能过渡，关键是业务增长时要果断迁到数仓建模。我见过太多公司在用户量不到1000时过度设计，反而拖慢迭代。建议按业务规模分阶段演进，别绝对化。
业务方表示很懂文章里说的‘实时定义混淆’。以前跟技术沟通，我说要看实时销售，他们就让我在ERP系统里直接点查询，慢得要命。后来了解BI和OLTP边界，才明白我要的是分钟级聚合报表，不是秒级事务数据。文章建议用三个维度沟通很实用，现在需求讨论前先明确是哪类‘实时’，少了很多扯皮。