企业官网建设流程全解析

简介：《火山引擎智能数据洞察平台v2.0》PPT面向企业数据平台建设者、数据分析师与产品经理，围绕智能数据洞察（eABI）产品的定位与落地路径展开，帮助读者理解从报表制作、探索分析到数据洞察的能力体系。资料以1个PDF文件交付，压缩包约21.54MB，内容为完整演示文稿，便于按页查阅产品架构、能力矩阵与功能详解。已有789人学习下载，具备一定参考热度。文稿系统梳理平台自2014年内部启动至2020年对外开放的成长路径，并给出70%用户覆盖、3.1万+数据模型、73.5PB数据量、每日150万+查询等规模指标；同时展开跨源异构融合、可视化建模、秒级查询、AI+BI场景建模、仪表盘与大屏、嵌入式分析及OpenAPI等模块。读者可借此快速建立对火山引擎智能数据洞察产品能力边界、技术架构与典型分析场景的整体认知，为数据平台选型、方案汇报或产品设计提供参考。

1. 一份 2020 年 12 月的 v2.0 文档，为什么今天还值得翻

2020 年 12 月，某云厂商的数据平台解决方案团队整理了一份《智能数据洞察平台 v2.0》的对外材料，通篇没有产品广告词，全是能力矩阵、架构分层和运营数字。这份材料在 v2.0 发布半年后拿出来，与其说是版本介绍，不如说是一次产品化复盘。它值得现在翻，原因有两个。一是它把一个常被讲成概念的能力——增强分析——拆成了可验收的模块：报表制作、探索分析、数据洞察三条能力栈，每条栈下面挂着具体的算子、图表和查询链路，能看出哪些是真做完了、哪些还停在路线图上。二是它给了一套少见的规模口径：8 万+ 用户、3.1 万个数据模型、73.5PB 数据量、日均 150 万次查询、3.4 万份报表。在 BI 这个赛道，愿意把内部真实用量摆到对外材料里的团队不多，这种数字比任何功能描述都更能说明产品的实际负载。对做数据平台的人来说，这份材料的价值不在“它有什么功能”，而在“它在什么量级下还敢承诺什么”。

2. 六年时间线：从内部即席查询到对外产品，中间隔着什么

2.1 三个时间点，对应三次定位变化

材料里的时间线只有三个节点，但每一个节点背后都是一次产品定位的迁移。2014 年 5 月，这套系统在内部启用，定位是“数据平台元老级产品”，提供大数据平台的基础查询分析能力，核心形态是“即席查询 + 共享”：把查询结果和查询模板共享给其他人。这个阶段解决的问题非常朴素——数据躺在 Hive 里，业务方拿不到，只能排队找数据开发写 SQL。即席查询把“取数”这件事从工单变成了自助，共享模板则让重复问题不必重复回答。

2020 年 6 月，产品开始对外服务。这一步的难度经常被低估。内部工具转商业化，要过的不是功能关，而是三关：多租户隔离、权限粒度、可用性承诺。内部系统挂半小时，群里喊一声就过去了；对外产品挂十分钟，就是事故。材料里专门留了安全隐私说明的篇幅，也侧面说明这一关的分量。

2020 年 12 月的 v2.0 文档，则是一次能力栈的正式分层：数据接入、数据准备、数据展示三大块被拆开，查询分析系统、可视化系统、展现系统各自独立成层。从行业角度看，这种分层不是画得好看，而是组织结构的映射——当使用人数从几百涨到几万，一个团队不可能再同时维护取数、建模、出图三件事，必须按层切分职责，让每层有自己的接口和 SLA。六年半的时间里，这套系统完成的不是功能叠加，而是从“一个查询工具”长成“一个分层的数据服务”。

值得注意的是，材料里没有写 2016 到 2019 年发生了什么。但从结果可以倒推：3.1 万个数据模型不是一年能沉淀出来的，它意味着这套系统在对外之前，已经在内部把各个业务线的口径、维度、指标体系跑了一遍。这大概是这类产品最难复制的地方——功能可以照着做，模型沉淀不能。

2.2 8 万用户、73.5PB、150 万次查询，这几个数放在一起说明什么

材料披露的运营数字是：8 万+ 用户，覆盖公司 70% 的用户，500+ 业务与职能，覆盖运营、增长、产品、研发所有业务线；3.1 万+ 数据模型，总数据量 73.5PB；日均查询 150 万+；3.4 万+ 报表，每日查看报表人次 10 万+。

单个数字看不出什么，放在一起做几道除法就能读出结构。日均 150 万次查询分摊到 8 万用户，人均每天接近 19 次——这个频次说明它不是“季度汇报才打开一次”的工具，而是嵌进了日常工作流。73.5PB 摊到 3.1 万个模型，单个模型平均在 2.4TB 量级，说明建模粒度偏细，不是“一个大宽表打天下”的路子。最有意思的是报表这一组：3.4 万份报表，日查看 10 万人次，平均每份报表每天被看不到 3 次。这是典型的长尾结构——绝大多数报表建完就沉底，真正的流量集中在少数头部看板上。

这组数字对做数据产品的人是个提醒：报表数量不是资产，被订阅、被打开、被引用的报表才是。很多团队把“支持创建多少报表”当指标，实际上这个数字越大，口径维护成本越高。材料里提到“固定主题的报表和专项分析工具无法满足快速变化的业务需求”，本质上说的就是长尾报表的维护困境——需求变得快，报表跟不上，最后只能靠全流程自助化把维护权交回业务方。

再看 500+ 业务与职能这个数字。覆盖所有业务线意味着需求极度碎片化，运营要的是活动效果归因，产品要的是留存分群，研发要的是稳定性指标，这三类需求在数据模型上几乎没有交集。能用一套平台装下，靠的不是通用拖拽能力，而是主题化的预置模型。

2.3 场景化：为什么“抽象业务场景”比“通用拖拽”更难做

材料里有一句容易被划过去的话：产品的成长路径和垂直领域的业务场景深度融合，打造专项解决方案，让新业务快速步入正轨，让老业务发现更多可能。后半句是重点——同一套能力，对新业务和老业务的用法完全相反。

新业务没有历史包袱，需要的是“默认值”：预置好的主题数据集、现成的指标口径、能直接套用的分析模板，让它三步之内看到第一张有意义的图。老业务正相反，它有历史口径、有历史报表、有已经吵过很多轮的指标定义，需要的是“可改性”：能在既有模型上叠加新维度、能对比不同时期的口径、能把新发现的异常下钻到明细。

材料里列的六个主题——用户、活动、视频、商品、供应商、车主——就是这种思路的产物。每个主题背后是把一类业务的常用维度和指标提前固化，业务方进来不用从原始表开始搭，直接从主题数据集往下走。这种做法的代价是前期投入重：得先有人把业务逻辑抽象出来，再结合算法针对性优化分析流程。收益是使用成本直线下降，尤其对非专业用户。

从行业角度看，通用 BI 卖的是自由度，场景化 BI 卖的是默认值。前者上手门槛高、上限也高，后者上手快、但一旦业务模式变了，预置的主题可能集体失效。这份材料选择的是中间路线：底层保留可视化建模和自定义 SQL 的开放能力，上层用主题数据集做收敛。这个取舍在 2020 年是合理的，放到现在看也仍然是主流做法。

3. 三大能力栈：报表、探索、洞察各自卡在哪一环

3.1 报表制作：磁贴模式和自由模式不是审美差异

材料把仪表盘分成两类。普通仪表盘走磁贴模式，简单快速、效率高，适合业务人员快速搭建；高级仪表盘走自由模式，布局更灵活，支持文本、图片控件，能做出图文并茂的可视化报告。表面看这是排版自由度的区别，实际是两种交付模式的分工。

磁贴模式的本质是栅格约束。所有图表卡在固定网格里，好处是永远不会排歪、响应式适配稳定、多人协作时不会互相覆盖布局，代价是表达力受限，做不出“左边一张大图、右边三行注释”的汇报型页面。自由模式反过来，位置和尺寸都能随意调，能塞文本和图片，适合做月度经营报告这类需要叙事的场景，但排版质量取决于使用者，两个人做出来的东西可能完全不是一个水准。

真正决定报表层好不好用的，不是图表数量，而是“改一次口径要动几处”。材料里配套给的是看板编辑器、公共筛选器、目录管理、订阅报表这几项。公共筛选器的意义在于把时间、地域、渠道这类高频过滤条件从单张图里抽出来，做成全局参数，改一处全盘生效。目录管理解决的是报表多了以后找不到的问题。订阅报表则是把“人找数”翻转为“数找人”——这个转向在后面还会反复出现。

图表能力这块，材料列了自研图表库、图表交互、条件格式、文本解析、大盘趋势图、品类条形图、地域分布、对比同环比、LOD 表达式、参考线。这些名词单看很碎，归一下类其实是三组：基础图形（趋势、条形、地域）、分析增强（同环比、参考线、条件格式）、计算能力（LOD 表达式）。第三组才是分水岭，它决定了这张报表能不能表达“每个用户的历史累计订单数”这类跨粒度指标，而不是只能做当前视图内的加减乘除。

3.2 探索分析：FIXED 表达式和那段 SQL 才是真门槛

探索分析这一层，材料给的描述是“简化 Excel 的操作，直追 Excel 的灵活”：直接拖拽维度和指标、快速计算统计指标、切换可视化样式、多种场景化分析控件，再加上灵活分组、上卷下钻、一键分享 URL。

拖拽这件事本身不难，难的是拖拽背后能不能表达复杂口径。材料里给了一个很具体的例子：以{fixed[用户id]:uniq(订单id)}作为维度，查看不同购买频次的人数分布。这个写法是典型的 LOD（Level of Detail）表达式，含义是“忽略视图当前的分组，按用户 id 这一粒度计算去重订单数，再把结果当作一个新维度使用”。

等价的手写 SQL 大致是这样：

-- 内层：先按用户粒度聚合，算出每个用户成功下单的去重订单数 SELECT user_id, COUNT(DISTINCT order_id) AS order_times FROM orders WHERE status = 'succeed' -- 只统计成功订单，失败/取消不计入频次 GROUP BY user_id ; -- 外层：再按“下单次数”这个新维度分组，统计每个频次区间有多少人 SELECT order_times, COUNT(DISTINCT user_id) AS user_cnt FROM ( SELECT user_id, COUNT(DISTINCT order_id) AS order_times FROM orders WHERE status = 'succeed' GROUP BY user_id ) t GROUP BY order_times ORDER BY order_times DESC ;

这段 SQL 的关键点在两层聚合的粒度不同：内层是用户粒度，外层是频次粒度。如果在 BI 里直接拖“用户 id”和“订单 id”做去重计数，得到的是当前视图粒度下的结果，永远算不出“购买 3 次的人有多少”。LOD 表达式的价值就是让业务人员在不写子查询的情况下表达跨粒度计算。参数上要留意两点：fixed后面跟的维度决定了计算粒度，写错就是全表一个值；聚合函数的选择决定了去重逻辑，uniq和count distinct在近似去重场景下结果可能不一致，对账时要确认口径。

提示：LOD 表达式的结果不受视图筛选器影响这件事经常被误解。视图上加了时间筛选，fixed计算出来的值可能仍然是全周期的，做同比分析时尤其容易翻车，上线前务必用一段已知数据验一遍。

材料里另一个例子是对比同环比、快速建立 GMV 趋势分析表，“复杂 Formula、简单 MouseClick”。这句话的潜台词是：探索分析层的竞争不在能不能拖，而在拖出来的指标能不能直接用于决策。同环比看着简单，实际涉及日期维度的对齐、缺失日期的补齐、口径变更时的可比性处理，这些都不在拖拽动作里，在底层模型里。

分享协作这块，材料写的是“一键分享 URL，快速传递知识”。这个功能看着轻，实际是探索分析能否形成闭环的关键。分析的价值不在一个人看完，而在结论能传出去。URL 分享把“我的视图”变成“可复现的链接”，比截图强的地方在于对方能继续下钻。

3.3 数据洞察：AI 算子放在建模链路的哪个位置

材料对 AI 部分的描述分两块。一块是把 AI 塞进数据准备环节：BI 侧负责数据清洗——筛选、连接、聚合、合并、过滤、转置；AI 侧负责构建模型——判别、预测、分类、聚类、回归。两块拼起来叫“AI+BI 一体化场景建模”，目标是简化建模过程，让非专业群体也能用上模型算法。

另一块是分析侧的增强能力：增强分析引擎、归因服务、聚类、文本问答，配合指标监控和智能归因。这部分解决的是“指标异常了，先看哪里”。

把这两块放在一起看，能看出 AI 在这个平台里的定位很克制：它不负责给结论，负责降门槛和缩时间。降门槛指的是原本要写 Python、调参、做特征工程才能跑的聚类和回归，现在变成建模流程里的一个算子，业务方选好字段、点一下就能出结果。缩时间指的是指标出现波动时，归因服务先把可能相关的维度排一遍序，人不用从几十个维度里一个个试。

这种定位是有道理的。BI 场景下的数据绝大多数是结构化、口径明确、样本量充足的，这类数据上机器学习的边际收益主要来自“让更多人用起来”，而不是“做出更准的模型”。真正的难点在别处：模型结果怎么落回业务口径、预测值和实际值出现偏差时谁来解释、模型更新频率跟不跟得上业务变化。材料里没有展开这些，但从架构图看，增强分析引擎是挂在数据建模系统下面的，跟归因服务、聚类、文本问答并列，说明它输出的是“数据集”而不是“结论”，最终还是要回到报表和仪表盘里被人看。

4. 跨源融合与秒级查询：架构图里最难的两块

4.1 一张报表连六种数据源，难的不是连接

材料给了一个跨源查询的示例场景：电商平台订单数据走 API、自有 APP 订单存在关系型数据库、订单汇总数据在 Hive、用户收藏记录在 Hive、用户下单转化在 OLAP 引擎、线下地推活动的数据是 CSV 文件，六种来源在融合层汇总成订单数据集和用户信息数据集，分析时直接选数据集里的指标和维度。

连接本身不难，主流 BI 都能接。难的是连接之后的三件事。

第一是时延不一致。API 拉过来的订单可能是分钟级延迟，Hive 里的汇总表可能是 T+1，OLAP 里的转化数据是准实时的，CSV 是人工上传的。把它们放进同一张图里做趋势对比，如果不标注数据截止时间，结论很容易失真。材料里用“数据同步”这一层专门处理这个问题，配套的是系统编排与调度、流式同步、批量同步、API 集成、文件上传五种接入方式，加上同步数据依赖和数据回溯。数据回溯这个能力在实务中价值很高——上游重跑了一次，下游模型能不能跟着重算，决定了口径事故的修复成本。

第二是口径不一致。同一笔订单，API 里的状态字段和数仓里的状态字段命名可能都不一样，金额可能一个有税一个无税。跨源建模时如果不做字段映射和口径对齐，融合出来的数据集就是个黑匣子，谁也不敢用。材料里提到自动 DDL 和智能重名，“智能重名”这个功能名很不起眼，实际解决的是多源表字段重名时的自动区分问题，属于典型的脏活。

第三是权限不一致。不同数据源的权限体系往往各自独立，融合之后以谁的权限为准？材料给的答案是认证数据集加行列过滤加下载控制：数据集发布时做一次认证，行级和列级权限在数据集层面统一下发，下载行为单独管控。这套组合是把权限从“数据源”上收到“数据集”，让跨源分析不至于变成权限漏洞。

4.2 自研查询引擎：100 倍这个数字要怎么读

材料在性能这块写得很直接：自研查询引擎，为即时查询提供性能保障，对于大多数查询而言，处理速度至少提高了 100 倍；底层是基于某开源列式 OLAP 引擎做的升级版，在原社区版基础上做了大量开发和优化。

对“100 倍”这个数字，行业里的常规读法是：它一定对应特定查询类型和特定基线。明细级的点查、宽表上的聚合、带复杂条件的多表关联，这三类查询的加速比能差出一个数量级。材料说的是“对于大多数查询而言”，这个限定词很重要——它意味着存在一批查询达不到这个倍数，通常是超大结果集导出或者极端复杂的嵌套查询。真正该关心的不是峰值倍数，而是 P95 延迟稳不稳定，以及慢查询占比会不会随着数据量增长而恶化。

架构上能看出几个配套设计：缓存系统用 Redis 扛高频重复查询，OLAP 引擎扛明细聚合，数仓 Hive 作为底座，流式数据走 Kafka。这套分层的思路是“把不同温度的数据放在不同介质里”，冷数据留在 Hive 不迁，热数据进 OLAP，重复查询进缓存。听着朴素，但真要做到查询路由对用户透明，中间得有一层查询分析系统做改写和下发，材料里对应的模块是查询服务、订阅服务、指标监控、下载服务和数据接口 API 网关。

4.3 治理不是附加项，是融合的前置条件

材料里有一段话，讲的是产品演进的内在逻辑，值得单独拎出来：使用人数增多，共享频率增加，数据要有统一口径、合理安全的管控策略，这是让更多前线业务人员享受快捷数据洞察的前提。

这句话的顺序很讲究：先说使用人数增多、共享频率增加，再说统一口径和安全管控。意思是治理不是一开始就设计的，是被规模逼出来的。8 万人用一套系统，如果每个人都能自定义指标口径，同一张 GMV 报表能出八个版本，开会第一件事变成对数。所以才有指标监控、认证数据集、行列过滤、下载控制这一整套。

对应到架构图里，权限与项目中心和元数据系统是横跨所有层的两条竖线，不在任何单一模块内部。这种画法说明治理被当成基础设施，而不是某个功能。项目中心解决的是“谁能进哪个空间”，元数据系统解决的是“这个字段到底是什么意思、从哪来、被谁用过”。

注意：跨源融合和权限管控在实施顺序上不能颠倒。先接数据源再补权限，等于先把水放出来再修堤坝；正确顺序是先定项目空间和数据集的权限模型，再往里灌数据源。

5. 四个常见误读：把能力矩阵当成开箱即用的配置单

5.1 误读一：AI+BI 一体化等于系统自动给出结论

误判点：看到“判别、预测、分类、聚类、回归”这一串算子，加上“智能归因”“文本问答”，很容易得出一个印象——平台能自己发现问题、自己给出原因、自己生成结论，人只需要看结果。

为什么容易这么想：材料的表述方式确实容易引导这个理解。“AI 构建模型”和“BI 数据清洗”并列画在一起，视觉上像是流水线的两端，中间不需要人。加上“降低门槛”这个说法，读者会默认门槛降到了零。

怎么看：把 AI 在这个链路里的位置看清楚。它挂在数据建模系统下面，和归因服务、聚类、文本问答并列，输出的是数据集和候选维度排序，不是结论。归因服务能告诉你“这个指标下滑，渠道维度的贡献度最高”，但它不会告诉你“因为某个渠道出了问题”——后者需要业务判断。真正省掉的是枚举维度的时间，不是思考的时间。评估这类能力时，该问的问题不是“模型准不准”，而是“模型结果能不能被业务方复现和理解”。一个业务方看不懂特征重要性的预测模型，在 BI 场景里基本没有生命力。

5.2 误读二：跨源融合等于接一个万能连接器

误判点：既然能连 API、关系型数据库、Hive、OLAP、Kafka、CSV，那是不是意味着随便什么数据接进来就能直接分析？

为什么容易这么想：产品宣传里“跨源”总是和“融合”连在一起说，听起来像是连接完成之后融合自动发生。实际上连接是配置动作，融合是建模动作，两者之间隔着一整个数据准备层。

怎么看：融合的核心工作是三件——字段映射、口径对齐、粒度统一。六种数据源里的订单，金额字段可能一个有税一个无税，状态字段可能一个用英文枚举一个用数字编码，时间字段可能一个是本地时间一个是 UTC。这些不处理，融合出来的数据集比单源还危险，因为它看起来是对的。材料里把数据准备单独列成一层，配套数据清洗、数据合并、自定义指标、跨数据源建模、自动 DDL、智能重名、行列过滤，这一层的厚度决定了跨源到底能用不能用。选型时值得试的不是“能连多少种源”，而是“两个源的同名字段冲突时，系统怎么提示”。

5.3 误读三：秒级响应是硬件预算问题

误判点：千亿级数据量做到秒级查询，第一反应是堆机器、加内存、上更强的 OLAP 引擎。

为什么容易这么想：性能问题在直觉上就是资源问题，加钱能解决。而且“自研查询引擎”“处理速度提升 100 倍”这类表述，天然把注意力引向引擎本身。

怎么看：秒级响应的前提是数据被组织对了。同一份明细，按天分区和按用户哈希分桶，查询性能能差出几十倍；预聚合好的宽表和每次现算的明细表，差距更大。材料里的组合拳是：缓存系统拦重复查询、OLAP 引擎扛聚合、数仓 Hive 存明细、查询分析系统做改写下发。这套设计的意思是“让该快的查询走快的路径”，而不是“让所有查询都变快”。实务中的判断标准是慢查询分布：如果 P95 稳定但 P99 有长尾，通常是少数复杂查询拖的，优化方向是查询改写和资源隔离；如果整体都慢，才是引擎或数据组织的问题。上来就加机器，往往钱花了，长尾还在。

5.4 误读四：自助分析意味着人人都会用

误判点：既然支持拖拽维度指标、切换可视化样式、一键分享，那业务人员培训半小时就能自己分析数据了。

为什么容易这么想：自助 BI 的宣传口径一直是“把能力交给业务方”，加上界面确实做得像 Excel，容易让人低估背后的认知门槛。

怎么看：拖拽的门槛在手上，分析的门槛在脑子里。会拖不等于会问问题。一个业务人员打开数据集，面对几十个维度和上百个指标，第一反应通常是“我该看哪个”。这也是为什么材料里要花篇幅做主题数据集——把常用维度和指标提前收敛成几个主题，用户进来看到的是十来个字段而不是一百个，选择成本立刻降下来。自助的真正含义不是“什么都能自己做”，而是“常见问题不用求人”。评估自助能力有个简单办法：找一个非数据岗的同事，给一个具体业务问题，看他能不能在半小时内独立做出结论，中间求助了几次。求助次数比操作熟练度更能反映自助的真实水位。

6. 往后看三条线：增强分析的下一步和一份验收清单

从这份 2020 年的材料往后推，增强分析这个方向大致沿着三条线演进。

第一条是从“人找数”到“数找人”。材料里的订阅报表、指标监控、智能归因已经埋了这个伏笔，只是当时的形态还是“配置一条订阅，定时推给你”。下一步是异常主动触发：指标偏离基线时自动生成一条带下钻路径的通知，人收到的时候已经有初步归因，只需要判断和决策。这条线对平台的要求从“查得快”变成“看得准”，误报率会变成核心指标。

第二条是建模权继续下移，数据工程角色往口径和权限上收。材料里的可视化建模加 AI 算子，把特征工程和模型训练包装成了配置项。继续走下去，业务方会自己完成大部分探索性建模，数据团队的价值转移到定义什么是指标、谁能看什么数据、模型上线后怎么监控漂移。这个转变对组织的要求比技术更高。

第三条是分析能力的外延，BI 从系统变成组件。材料里给了 Iframe 嵌入、SDK 集成、OpenAPI 三种方式，覆盖 CRM、OA 和其他业务系统。这条线的终局是业务人员在日常系统里直接看到分析结果，不需要专门打开一个 BI 平台。对平台方来说，这意味着接口稳定性、鉴权体系、嵌入性能会变得和图表能力一样重要。

给正在评估这类平台的团队一份验收清单，五项，按顺序走：

这份材料毕竟是 2020 年的，里面的一些表述放到今天看已经属于标配，比如拖拽分析、主题数据集、URL 分享。但它记录的那个判断至今没过时：数据平台的竞争力不在功能清单的长度，在口径、权限、性能这三件事有没有真正做到可以交给非技术用户。踩过的坑告诉我，功能演示是最容易糊弄人的环节，因为演示数据永远是干净的、小规模的、口径统一的。从那以后我每次评估一个数据平台，都强制走一遍：拿三张源系统里真实存在、字段命名混乱、时间口径不一致的表，不找数据工程师，自己从建数据集做到一张能给别人看的仪表盘，全程记下卡住的次数。卡住超过五次，功能列表再长也没有意义。希望帮到你。

本文还有配套的精品资源，点击获取