导读 火花思维，专注于线上思维类教育，目前拥有逾 20 万注册学员，每日积累大量数据。自 2021 年起，我们采纳火山引擎作为主要分析平台，重塑数据管理体系。本文将分享在建设之初所面临的挑战，方案选型的心路历程，落地实践和运营策略，以及对未来的展望。
1. 痛在哪里 - 自研系统的局限性
2. 方案选型 - 为何选择火山引擎
3. 运营策略 - 如何将工具潜力变成业务能力
4. 未来展望 - 大模型时代的数据分析长什么样？
5. 问答环节
分享嘉宾｜冯俊晨博士 火花思维教育科技有限公司 火花思维大数据技术总监
编辑整理｜王红雨
内容校对｜李瑶
出品社区｜DataFun
痛在哪里 - 自研系统的局限性
在早期，即 2020 年前后，火花思维自研系统面临着诸多挑战。最为突出的问题是 BI 系统对 SQL 高度依赖，必须要会写 SQL 才能做分析。尽管当时交互式分析已成为行业主流，但由于技术水平的限制，我们的初代系统未能实现即时的交互分析，而是采取了“保存 SQL 为图表”的方案，这意味着每次查询都需要写 SQL 指令，自然也没有下钻、上卷等高级的分析功能。进而导致响应速度慢，整体效率低。技术架构方面，最初选择了 Presto 直接查询，但很快发现其查询速度不尽人意，后续尝试通过 Redis 缓存部分表格以提高性能，但这并未从根本上解决问题。对比 Superset 或火山引擎等行业标杆，缺少高性能的行列查询计算引擎成为了明显的软肋，导致系统性能不佳，特别是在图表加载时间上，P95 值达到了惊人的 30 秒以上，严重影响了用户体验。此外，考虑到许多业务团队仅在早晚查看一次仪表板的习惯，即便存在冷热缓存机制，但很多看板没有二次展示机会，因此当时引发了广泛的系统性能投诉。数据结构方面，系统初期未设立明确的数据集（dataset）概念，这意味着 SQL 与图表之间不存在有效的关联桥梁。理论上，理想的架构应允许一个 SQL 查询对应一个数据集，进而一个数据集可关联至多个图表，以此减少冗余劳动，简化数据管理。遗憾的是，原系统未能实现这一目标，加剧了整体运维负担。例如，当同一类型的行为数据分布在日、月、周三种周期的报表中时，不得不分别编写三段 SQL 查询语句，导致了不必要的重复工作和高昂的维护成本。行为日志系统面临的最大的问题就是点位爆炸。最初，系统采用了页面 ID 和行为 ID 相结合的方式来标识特定的用户动作。然而，这种方法忽视了场景之间的联系性和通用性，导致即便是相似的“点击”操作，只要出现在不同的页面上，就必须视为独特的事件进行注册。这一设计直接引发了火花思维点位数量的激增，远远超过了同类应用的平均水平。据统计，尽管我们的日数据量仅为竞争对手的百分之一，但点位数目却超过了一万个，形成了巨大的管理负担。此外，系统缺乏自助验证机制，阻碍了产品经理和分析师的有效协作。大多数成熟的商业行为日志系统均配备了一键验证功能，允许相关人员通过扫描二维码或访问测试环境快速检查点位配置的准确性，且无需技术人员介入。但在火花思维的原有框架下，质量保证（QA）人员依据需求文档进行初步检验，往往忽略了具体应用场景下的细节差异，如触发时机和多点位协同效应等问题。这种脱节导致看似合格的点位在实际使用过程中频繁出现兼容性错误，迫使分析师在发现问题后再次启动修改流程，造成时间和资源的极大浪费。系统缺乏交互式分析功能也是一大硬伤，分析师被迫依赖复杂的 SQL 查询进行数据分析，尤其在涉及行为日志时，其复杂程度远超常规业务数据库操作。鉴于行为日志通常包含多达七个以上的点位，并可能跨多个页面发生，加上点位有效性检测的繁琐过程，分析师面对庞大的脏数据集时倍感头疼。尽管拥有万余点位，但由于上述因素，真正用于行为日志分析的图表产出极为有限，大大抑制了数据价值的发挥。当时的数据产品研发团队包括两名产品经理、两名前端工程师、三名后端工程师和两名测试人员，总计约 8 至 10 人，这一规模符合行业中等规模企业数据团队的标准配置。然而，随着外部经济环境的变化，特别是教育行业在 2021 年后所承受的压力增大，如何合理控制成本成为摆在管理层面前的重要课题。继续维护现有的老旧系统显然成本过高，而从零开始构建新一代系统，人力又不足。综合考虑各种因素，火花思维作出了战略性决策：停止自主开发，转而采买第三方系统。方案选型 - 为什么选择火山引擎
第二部分，深入解析为何火花思维最终选择了火山引擎。在 BI 系统选型过程中，我们从多个角度对比了火山引擎、Superset 和帆软三款产品。Superset 凭借其强大的社区生态系统，提供了极其丰富的图表种类，尤其在附加组件的支持下，图表多样性首屈一指。当然，火山引擎与帆软虽稍逊一筹，但也覆盖了多数基础图表类型，可以满足常见需求。在格式自定义方面，主要考察内容包括单元格合并、字体大小、样式设定，以及一些复杂格式如同比、环比显示等等。帆软在这方面展现出了超群实力，提供了高度自由的表格样式调整功能。对于那些对报告美观性有着严格要求的企业，如国有企业或其他对文书标准较高的组织，帆软的表现无疑极具吸引力。火山引擎紧随其后，仍远强于 Superset，后者在字体细节调节等方面显得较为乏力。上卷、下钻以及看板间数据联动的能力是现代 BI 工具不可或缺的部分。经评估，三款产品在这一领域表现相当，均能满足深入数据分析的需求。鉴于火花思维旧系统在处理大规模数据时的性能瓶颈，我们对备选方案实施了严苛的压力测试，模拟高并发查询场景。实验结果显示，火山引擎的查询响应时间领先，尤其是在大数据量条件下表现出色。但优势仅在数秒之内，对于用户体验不甚明显。火山引擎的一项独特亮点在于其内置的辅助分析模块，集合了表格汇总、行列合计以及各类比率计算，能够有效提升数据分析效率与准确度。在数据预处理方面，我们重点关注了以下几点。首先是数据源接入种类，三者能力相近，均能高效连接多种数据源，不过，鉴于火花思维对飞书生态的应用，而火山引擎在这方面表现尤为出色，尤其是在飞书文档、多维表格的集成上，API 接口的完善度远超其他工具，所以是一大加分项。我们曾一度忽略了一个关键议题——调度系统的稳健性，后来成为采用第三方工具后遭遇的最大挑战。根据当时的调研，火山引擎在调度系统上的设计明显优于 Superset，其具备一项重要特性：当遇到空分区时，系统会自动等待而非立即报错，这对于处理大规模延迟情况尤为重要。火山引擎的另一项独特优势在于其可视化的数据建模功能。这项特性使非技术背景的用户也能通过直观的拖放操作完成数据处理任务，无需掌握复杂的 SQL 语法。智能归因分析功能是火山引擎的一项独门绝技，也是当时选型的决定性因素。下面简单展示一下智能归因分析的作用。![]()
上图中展示了火花思维内部 AI 工具平台过去两周内用户会话数和消息数的变化趋势。面对这类数据异动，智能归因分析便可以大显身手。首先，该工具将选定数据集下的所有维度变量逐一拆分，对比前后两期数据变动。对于加法性质的指标，分析结果能够完全覆盖数据波动，揭示 100% 的变化源头所在。每个维度旁标注的可能性权重数值，反映了其对异常波动的影响程度，数值越大，意味着该维度更可能是引发异动的关键因素。对于加法性指标，如 DAU、GMV 等，运用此工具进行异动分析极为便利，可以立即定位潜在原因，免去了上卷、下钻等繁复的手工分析步骤。![]()
对于乘法性质的指标，如调度及时率，整个系统的调度及时率是由各个子系统的及时率乘以各系统的权重，再相加得到的。这里分析结果中的百分比不再直接映射物理意义，而是一种参考值，蕴含着算法逻辑，但归因列表同样有助于快速定位问题所在。综上所述，智能归因分析功能为分析师减轻了沉重的报表制作负担，尤其适用于火花思维希望深入探究多维度数据特征的场景。可视化分析领域，火山引擎与神策旗鼓相当。神策广泛服务于各行各业，积累了丰富的行业模板，对于技术资源有限的企业而言，直接采纳其定制化套件，门槛会更低。神策系统的一大缺陷是自身不带埋点平台，不具备治理能力，而这正是我们希望解决的一大痛点。二者的可视化测试环境相差不多。火山引擎还具备一项额外的功能，支持点位生命周期管理，能够追踪点位使用频率，但对于火花思维的场景而言，该功能价值并不是很大，因为我们的点位并不是很复杂。最终选择火山引擎的决定性因素是其动态分流系统，在国内的生态里，它是唯一一个能够通过私有化部署或 SaaS 方式使用的定制化埋点平台。动态分流能力有很多好处。简而言之，实验组和对照组的流量分配比例不固定，如果实验组的效果好，就会自动扩量；如果实验组效果不佳，则自动缩量。这样一方面可以保护业务结果，降低实验风险；另一方面，还能缩短实验周期，传统静态分流可能需要 14 天甚至一个月的实验，而在动态分流中可能仅需要 8 天甚至更短的时间，特别有利于小流量实验。![]()
举个例子，如上图所示，在静态分流实验中，每个组分配三分之一的流量，其中一个组指标显著，一个组不显著，可以看到三个组的流量占用非常大。在下面的动态分流实验中，最初设置的流量分配是 2:4:4 的比例，随着实验的推进，效果不好的实验组，其流量下调了 6%，这部分流量分配给了效果好的实验组。综上，动态分流能力对于提升业务结果和缩短实验周期有着重要意义，绝大多数公司的 AB test 在静态分流下都难以实现显著，而动态分流将会使实验事半功倍。整体而言，火山引擎虽然价格略贵，但其具备的一些特别的功能对我们是非常有价值的。运营策略– 如何将工具潜力变成业务能力
接下来介绍我们是如何运营这些工具从而使其价值充分发挥的。首先我们需要思考一个问题，数据分析产品应该是需求驱动的还是供给驱动的。需求驱动，指的是业务需求先行，由业务需求决定生产。而供给驱动，是从生产效率出发，提高生产效率以满足更多需求。在系统迁移之初，我们认为瓶颈主要在于供给，由于工具缺陷导致效率低下，跟不上需求，导致业务方的不满。然而在运营火山引擎之后，我们发现其实还是应该由需求驱动的，数据分析产品本质上就是一个需求驱动的内容平台。在刚刚迁移至新平台的时候，出乎我们意料的一个问题是，业务仍会使用大量表格来进行分析，即便火山引擎提供了非常丰富的图表和分析功能。经过探访实际工作发现，一线管理者在管理组员的过程中，使用明细表格仍是最方便的。另一个问题是关于归因分析功能，我们倾力推广，坚信其为提升分析效率的利器。确实，在某些特定场景下，如大数据团队进行算力资源的细粒度监控，或产品部门追踪日活用户变化时，都会使用归因分析功能。然而，对于更重要的一个场景——漏斗分析，即比率的分析，并且是多步漏斗分析，归因分析就显得力不从心了。加之，其输出指标晦涩难懂，普及之路遇阻，最终未能很好地落地，转化为实实在在的生产力。由以上两个问题可见，更高级的形式不一定是更有效的解决方案。除此之外，我们得到的另一个结论是，创造看数的需求比提高产数的效率更重要。当有了火山引擎这一平台后，供给不再是瓶颈，需要关注的是如何吸引更多用户来平台上看数。作为内容平台，只有更多、更高质量的内容才能吸引来更多用户，因此提高内容生产效率必不可少。对于专业数据分析人员而言，需要依靠系统能力，提高分析效率。而对于非专业分析人员，则需要尽量降低门槛，通过培训和工作坊等形式，普及相关能力。同时，做好业务核心场景的数据集市，控制数据集的认知复杂度。![]()
上图中第一张图表展示了新 BI 系统的活跃用户变化情况，第二张图表展示了分析师团队创建的图表占总图表数的比例，可以看到越来越多的业务人员开始自己动手在系统中做数据分析，平台价值得到了更加充分的利用。![]()
2023 年末，设计团队做了名为《为设计插上数据的翅膀》的分享。他们在使用数据分析平台后，经过不断打磨其物料，使朋友圈有效分享率提升了 12%。在第一阶段中，我们与设计团队合作，聚焦于深入理解其独特需求，帮助其实现为素材打上风格标签的诉求。为此，我们进行了细致入微的数据管道构建与数据清洗工作，旨在建立风格标签与营销成效之间的直接联系。同时，根据设计团队的定制请求，提供了一系列可视化看板，为定期会议提供了有力的数据支撑。初期，设计团队成员普遍对数据分析持有畏惧心态，经过频繁接触与实践，平台运用渐入佳境，设计师们惊喜地发现，数据不再遥不可及，反而成为了启迪创意、指引方向的灯塔。通过培训、工作坊，设计团队开始利用系统自问自答，从猜想到验证，工作过程发生了巨大变化，因此业务效果也得到了大幅提升。![]()
第二个成功案例来自于后服务团队，即辅导老师团队。每个大区有约 150 位辅导老师，分为若干组。每个大区有一位数据运营，每日需手动下载各类报表，随后按组别拆解并分发，他们称自己为“数据的搬运工”，这一过程耗时耗力。有了新的 BI 系统后，利用其可视化建模和行列权限的功能，数据运营只要搭好看板、设好权限，就可以让一线管理者直接下载相关数据，大幅提升了生产效率。原来数据搬运的时间，现在可以用来专注于策略效果分析。此外，由于学校活动频繁，政策变化多，每次都依赖分析师提取数据效率非常低下。因此业务人员会根据分析师提供的 SQL 查询模板，调整参数后自行提取数据。更进一步，如果对分析师的 SQL 有了一定的理解，无需深入掌握 SQL，就可以利用可视化建模工具独立完成定制化操作。这一转变意味着，只要具有基础数据处理能力，即可应对绝大多数业务需求，仅少数长期固定项目才需提出数据宽表需求。由此，运营团队与 BI 团队间的信息交互更加顺畅，整体数据服务能力得到了显著提升。未来展望- 大模型时代的数据分析长什么样？
最后来探讨一下在 AI 蓬勃发展的背景下，如何重新定义 BI 系统的作用与潜能，以期更好地服务于业务决策。首先，我们热切期望未来的 BI 系统能够直接产出业务洞见。虽然当前很多 BI 产品在数据分析方面展现出了强大的实力，但仍侧重于加速可视化分析过程，和实质业务洞察之间仍存在一定距离，这正是我们需要着重攻克的关键环节。我们大胆设想，现有的 OLAP 分析框架可能并非大模型时代下的终极解决方案。未来的分析模式将摒弃传统维度和指标的限制，转向问答形式，无需经过中间图表展示或复杂的上卷下钻操作，而是直接从数据中获得洞见。在探索这一愿景过程中，还需明确企业和工具供应商的职责范围。我们认为，企业应专注于管理和深化自身业务知识，包括但不限于业务的抽象建模，以及企业知识和元数据的管理，这些一定会沉淀在企业内部。未来建设的重心，将从数据集市变为问题集合，关注业务团队面临的具体问题，并利用大模型给出答案。在未充分沉淀业务场景元数据的情况下，我们缺失业务视角，难以准确识别出业务面临的根本问题。数据架构虽已形成，诸多数据表相互交织，却未能清晰映射出业务部门如何依托这些数据解答关键问题。构建有效的业务问答体系，需先了解业务需求，进而设计能直接回应这些需求的指标体系。这里，语义层与指标层的概念至关重要。以 Superset 为例，该系统早在设计之初便采用了 metrics
Layer，允许超过三分之二的分析操作脱离具体数据表的约束，仅依靠算法运算符、聚合函数与过滤条件实现数据处理，而无需指定数据来源。这种做法强调的是指标的抽象化与通用性，意味着开发者只需关注指标本身的含义与计算逻辑，而非底层数据的具体组织形式。这不仅简化了分析流程，提高了分析速度，还促使业务人员更加聚焦于业务目标本身，而非数据获取途径。未来理想的业务问答体系应像电影《钢铁侠》中的 JARVIS 一般，具备高度智能化的对话接口。当业务人员提问时，系统能够直接提供答案，而非要求用户详细说明数据来源或具体查询步骤。这意味着问答系统不仅要能够理解和转换自然语言表述的业务问题，还要能自动识别并调用相关数据与算法，以高效生成答案。总之，大模型时代对业务建模提出了全新要求，呼唤更加智能的问答体系出现。这不仅需要技术上的重大突破，还需业务与技术部门深度协作，共塑未来业务分析的新格局。面对这一前景，我们满怀憧憬，期待见证数据分析领域的又一次变革。问答环节
A：“点位”一词是火花内部的专业术语，可以理解为埋点事件。起初，内部团队习惯将页面代码（page
code）与功能代码（fun code）结合称为一个“点位”。如今，随着行业标准的普及，更为通用的名称就是“埋点事件”，意在捕捉用户行为轨迹中具有营销价值的瞬间。2017 年获得芝加哥大学博士，一直深耕互联网教育行业的数据分析、算法应用和 AI 落地。在 EDM 等国际教育数据会议上发表多篇论文，并担任人民大学商学院和统计学院双聘企业导师。
