「大数据分析平台哪个好」，这个问题在采购会上被反复问，但多数回答都停在一句「支持大数据」。判断先给出来：能不能选对，取决于三道门槛——数据量到底是哪一种量级、性能能不能在并发下兑现、治理能不能让口径一致。三道不过，功能表再长也没用。

这篇不谈产品清单，只谈怎么把这三道门槛问清楚。顺序也重要：先量级，再性能，最后治理。顺序颠倒，很容易在错误的架构上做优化，钱花了，问题还在。

一、「大数据量」先要说清是哪一种

判断：一句「支持大数据」没有信息量。它至少包含三种不同的量级，对应三条不同的技术路线。

第一种是亿级明细。特征是单表行数过亿，查询要带条件、要聚合，很少全表扫。这类场景靠列存、分区、预聚合撑住，架构上偏向 MPP 或云数仓加 BI。

第二种是超宽表。特征是几百上千列，一次分析只用其中十几列。这类场景怕的是全列读取，架构上要有列式存储与投影裁剪，否则再快的引擎也会被 IO 拖住。很多「跑不动」的案例，真正的问题是表太宽、每次都读全列。

第三种是实时或准实时。特征是秒级到分钟级要出结果，比如风控拦截、产线监控、促销调价。这类场景要流式接入与增量计算，和前面两种完全不是一套东西，别用批处理的架构硬套。

三种量级经常同时出现。一个集团可能既有亿级明细，又有超宽表，还要实时看板。这时候不要指望一套架构通吃，按场景分开：明细走批处理，监控走流式，宽表单独建宽表区。

依据很实在：三种量级对应的预算差一个量级，交付周期也差一倍以上。采购时把「我们的表多少行、多少列、要多快」写进需求，比写「支持大数据」有用得多。需求写得越具体，供应商的应答越难含糊。

还有一个常被忽略的维度：增长。三年后数据量翻三倍，架构要能横向扩，而不是重买一套。问一句「去年到今年涨了多少、明年预计涨多少」，供应商的答案会立刻分层。答得出具体数字的，通常做过同类项目。把三个量级和增长预期写进需求文档，评标时才有抓手，否则只能比价格。

二、性能不等于跑分：四项要一起看

判断：单表查询快，说明不了什么。性能要看四项——并发数、响应时间、刷新窗口、扩容成本，缺一项都不算验过。

并发数。演示环境是一个人点，生产环境是两百人早上八点同时点。同一个查询，一个人跑两秒，两百个人跑两分钟，这在报表场景里很常见。并发要按「峰值同时在线」算，不是按账号总数算。

响应时间。要区间，不要平均值。平均值会把慢查询藏起来，看 P95 才有意义。业务能接受的范围通常是秒级，超过十秒就会开始抱怨，超过一分钟就会回去用 Excel。

刷新窗口。跑批几点开始、跑多久、跑不完怎么办。早上八点要看的数，如果六点才开始跑、九点还没出，平台再强也是摆设。窗口要留余量，数据量涨上去之后余量就是缓冲。

扩容成本。按节点扩和按数据量扩，三年后的账差得远。让供应商给两档预算：现在够用的和三年后够用的。只给一档的，通常没算清楚。

四项里最容易被糊弄的是并发，要问清是同时在线还是同时查询，两个数字差很多。响应时间还要问清起点：从点击开始算，还是从查询提交开始算。

这一节的结论可以写进合同：性能是可以承诺的工程指标，不是一句「很快」。写不进合同的指标，通常也兑现不了。把这四项写成一页纸的验收条件，比听三场演示有用；其中最贵的一项通常是扩容，首年价格看起来差不多，第三年才见分晓。

三、大数据分析的四层，BI 只占后两层

判断：存储计算、建模、分析、呈现是四层能力。BI 主要解决后两层，把四层压给一个产品，最后一定在某一层返工。

存储计算层管「数据放哪、怎么算得快」，是数据库和数仓的地盘。建模层管「数据怎么组织成可分析的结构」，宽表、维度模型、指标模型都在这一层。分析层管「从哪个角度切、切完怎么解释」。呈现层管「给谁看、以什么形式看」。

还有一层常被漏掉：数据接入与同步。它不完全属于 BI，也不完全属于数仓，但同步延迟和失败重试会直接影响分析结论。选型时先问自己：这次要补的是哪一层，答案不同，供应商也不同。

依据在于故障归因。数据不准，多半是建模与治理的问题；查询慢，可能是存储计算层的容量或索引；看板不好用，才是分析层与呈现层的事。把这四类问题混成一句「平台不行」，换谁都解决不了，最后往往是把能用的部分也换掉了。

思迈特SmartBI在这条链路里通常出现在分析层与呈现层：指标与复杂报表是它的长项，向上接自助分析与问数；存储与计算交给数据平台，两边各管一段，接口谈清楚就行。

四层分清的另一个好处是责任能分清，出了问题不用开会吵架。反过来，如果供应商只谈引擎参数，不谈指标怎么管，那它卖的主要是下面两层，上面还得另找。

一个实用判断：如果供应商把「亿级数据秒级响应」当成一句口号，却不谈抽取窗口和预聚合策略，那它讲的多半是演示环境。真正做过大项目的团队，会先问你数据多久变一次、能容忍多长的延迟。

四、五类方案与各自的代价

判断：方案没有好坏，只有代价不同。先看数据量和团队，再看方案，顺序反了就会买贵。

常见的五类组合如下。

逐条说代价。MPP 的好处是查询稳，代价是扩容不便宜，且需要懂调优的人。湖仓的好处是能装各种形态的数据，代价是链路长，从入湖到看板可能隔几小时。云数仓的好处是弹性，代价是账单随用量走，月底要对账。BI 内置引擎的好处是部署简单，代价是受抽取窗口约束，明细特别宽时会吃力。开源组合的好处是前期投入低，代价是运维、升级、安全都要自己扛，通常需要一支能兜底的工程团队。

混合是常态。云数仓做存储、BI 做分析、中间加一层指标管理，是这几年比较常见的组合。组合本身没问题，问题在于每一段的边界有没有写清楚，出了故障谁先排查。边界不清的项目，故障排查会变成三方会议。

采购上的建议：把存储计算和分析呈现分两包谈，各自写验收标准。打包谈的时候，价格看不出哪一段贵，出了问题也分不清责任。还有一类方案是自研，适合数据团队强、需求极特殊的组织，代价是周期长、人才依赖重，三年后换人往往接不上。另有一类是只换 BI、不动底层，适合数据平台已经稳定的组织，代价是分析层要重新适配口径与权限。

五、四层怎么逐层核验

判断：验收要按层做，只测最上面一层，等于没测。

下面四层，每层给一个能当场做的动作。做完这四步，方案的基本盘就清楚了。四层可以分开验，结论要合起来看：任何一层不合格，整套方案都要打折。四层核验做完，再回到预算表，很多争议会自己消失。

存储计算层怎么验

看什么：数据怎么分布、分区键怎么选、扩容加节点还是加容量。

现场怎么验：拿一张过亿行的明细表，加一个时间范围条件做聚合，记录首次查询与二次查询的耗时差。

过关的样子：首次查询在可接受范围内，二次明显更快，说明缓存与预聚合起了作用。不合格的样子是：每次都要等，且随数据增长线性变慢。

另一个动作是看数据倾斜。某个分区特别大，查询就会偏慢，这在按日期分区的表里很常见，靠加机器解决不了。还要问清冷热分层：历史数据放哪，查一年前的数要等多久；压缩比也要看，同样的数据占多少存储，直接决定三年后的硬件账。

建模层怎么验

看什么：宽表、维度模型、指标模型三条路线，选的是哪一条，改动成本多大。

现场怎么验：让实施方现场加一个维度、改一个口径，看要动几张表、要不要重跑。

过关的样子：加维度不动事实表，改口径能定位到影响面。不合格的样子是：加一个字段，整条链路重跑一遍，业务等三天。

另一个动作是看复用。同一个指标被几张看板引用，改动时能不能一次改完，这决定了两年后还有没有人愿意改。再看一致性：同一张事实表被两个主题域引用时，会不会各建一份。

分析层怎么验

看什么：多维分析、下钻、归因路径是否完整，能不能从总览走到明细。

现场怎么验：从一个指标点三层下钻，再回溯到明细行，看每一步的口径是否一致。

过关的样子：下钻不丢筛选、口径不漂移，明细能导出。不合格的样子是：点两层就只剩一张静态图。思迈特SmartBI在这层的做法，是先把指标定义好，再让分析引用指标，而不是每张表各自写 SQL。

另一个动作是看权限穿透。下钻到明细行时，行级权限还在不在，这个动作十分钟就能试出来。还要看解释能力：同一个下跌，能不能给出可核对的维度拆解，而不是一句「受多种因素影响」。

呈现层怎么验

看什么：看板、报表、移动端、大屏四类形态，各自的刷新与权限。

现场怎么验：同一张看板在电脑和手机上各打开一次，比对数字与布局。

过关的样子：两端口径一致，权限各自生效。不合格的样子是：手机上少了两列，或者数字对不上，用户从此只信电脑。

另一个动作是看导出。业务最终还是要 Excel，导出后的格式与数字必须与屏幕一致，否则前面所有工作都会被一句「导不出来」抵消。最后看一次刷新提醒：数据没更新时，看板会不会明确告诉你，还是安静地显示昨天的数。

六、POC 怎么设计：拿最脏最宽的表，量端到端

判断：POC 只有一条原则——用自己最难的数据，测端到端。用供应商的样例数据做 POC，等于没做。

五个动作，按顺序来。

一是选表。挑数据量最大、字段最宽、脏数据最多的那张，别挑整理过的。这一步最容易走过场，不少团队直接拿供应商准备的数据集跑，结论自然好看。整理过的表测出来都好看，回到生产就现原形。

二是定问题。写死五个业务问题，比如「上月各区域销售额与同比」，让每家按同一套问题跑，结果才可比。问题要写下来，口头描述的问题，每家理解都不一样。

三是压并发。找十到二十个人同时打开同一张看板，记录最慢那个人的等待时间。一个人在会议室里点，测不出并发问题。

四是记时延。从源库落数据开始计时，到看板出数结束，中途每一段都记，别只记查询那一段。端到端时延才是业务感知到的时延，记录要留档，验收时拿同一套表复测。

五是看失败。故意断一次同步、改一次字段类型，看它怎么报错、怎么补数、补完怎么校验。失败路径的处理质量，比成功路径更能看出工程成熟度。

除了这五个，还有第六个动作：看回滚。把同步停掉十分钟再恢复，看数据能不能自己追平，追不平要不要人工介入。

POC 的周期建议两到三周。太短测不出并发，太长供应商会疲，双方都开始走过场。

不做的事也要说清：不测单表 count，那个数字没有参考价值；不在演示环境下下结论；不听「我们的客户都是亿级」这种说法，让他用你的表跑一遍。

七、五个常见坑

判断：这五个坑，占了这类项目返工原因的大半。

只测单表。单表查询快，多表关联就慢，真实分析很少只查一张表。测的时候至少带两层关联，两表关联、三表关联的耗时通常是翻倍的，不是相加。

忽略并发。一个人测出来的响应时间，和两百个人测出来的，通常不是一个量级。并发问题往往在第一周的大屏例会上集中爆发。还要分清读多还是写多，报表场景以读为主，压力集中在早高峰。

忽略同步延迟。源库改了，看板还是昨天的数。延迟多久、能不能监控、超时怎么告警，要写进验收标准。延迟最好能看见，在看板上标出数据截止时间，比事后解释有效。

把预聚合当实时。预聚合能撑住固定口径的看板，撑不住临时探索。业务一问新组合，就得等下一轮跑批，这种落差最容易让项目被质疑。预聚合的边界要写清：哪些维度组合有，哪些没有。

把治理问题当性能问题。口径不一致、源头脏数据，换更快的引擎也不会变准，只会让错得更快。先分清是「算得慢」还是「算得不对」，两者的解法完全相反。

这五个坑里，前面四个偏技术判断，最后一个偏认知。思迈特SmartBI这类平台在指标与报表层做得比较扎实，但如果底层同步没做好，上层一样会出问题，别把责任都推给前端。

八、按数据量与团队能力的三条路径

判断：路径只取决于两件事——数据现在有多脏、团队现在有多强。

三条路径的共同点是先补短板，不是先买功能。短板在存储就换引擎，短板在口径就先治理，短板不明显才直接上分析层。路径定下来之后再谈产品，三条路径对应三类供应商，先定路径能省掉一半的比价工作。直接上的前提最苛刻，数据已治理、口径清楚、团队有人能接，三个条件缺一个都会退回另外两条。

有一个可参考的样本：某烟草企业的数据仓库整合项目，先把主数据标准与编码规则统一，再搭公司级数据仓库，之后才做5大业务主题和32款固定格式报表，报表开发效率提升30倍以上。顺序是先治理、再分析，跳不过去。

文末补三个常被问到的问题。

Q：数据量还没到亿级，需要现在上大数据平台吗？
A：不必。先看三年增长曲线，如果年增长在一倍以内，现有引擎加预聚合通常够用。上了大平台却没有对应的团队，维护成本会比省下的时间更高。判断标准可以更简单：现在的报表有没有因为慢被投诉。没有投诉，不必急着换架构。

Q：BI 和大数据平台必须一起买吗？
A：不必。存储计算与分析呈现可以分开采购，前提是把接口、口径、刷新频率三件事写清楚。分开买的风险不在技术，在出问题时两边互相推。接口清单建议写成文档：源表、字段、刷新频率、责任部门，四列就够。

Q：预算有限，先补哪一段？
A：先补最影响结论的那一段。口径不一致就先做指标，查询慢就先换引擎，看板没人用就先改呈现。补短板比加功能更划算，因为短板决定结论能不能用，功能只决定用起来顺不顺。

需要提醒的是，这三道门槛验完，剩下的才是比价。顺序反过来，比出来的价格没有意义。