分析系统平台化探索与实践

| |

在数据驱动决策的实践中，企业通常需要多种分析工具的组合支持。本文描述了如何应对多元分析场景的技术复杂性，构建统一、灵活、可复用的平台，在标准化与定制化间寻找平衡，实现开发效率、系统质量与运维成本的最优解。

一、背景​​

在数据驱动决策的实践中，企业通常需要多种分析工具的组合支持。例如，用户行为分析、地理位置潜力评估、供给动态追踪、人口流动研究以及业务交叉分析等场景，往往需要差异化的解决方案。
这些工具在技术实现上呈现显著差异：

  • ​​功能形态​​：从标准化分析模型到高度定制化报表，从支持秒级响应的即席查询到需数小时计算的离线任务
  • ​​数据架构​​：既有基于多表关联的动态计算模型，也有依赖预聚合的快速查询方案
  • ​​技术栈​​：涉及OLAP引擎、批处理框架、NoSQL数据库等多种技术选型
  • ​​交互需求​​：包含只读/读写模式、数据上传/下载等不同功能特性
    ​​平台化建设的核心挑战​​
    在构建模块化数据分析平台时，我们面临多维度的复杂度：如何通过统一的底层架构，兼容多样的分析主题（用户/地理/供给等）、计算模式（实时/离线）、技术引擎（内存计算/批量处理）以及功能需求，同时实现三个核心目标——
  1. ​​开发提效​​：通过标准化组件降低重复建设
  2. ​​质量保障​​：建立统一的质量监控体系
  3. ​​成本优化​​：通过资源调度与弹性扩缩容降低运维成本
    这要求平台设计既要有足够的扩展性适配当前技术生态，又要具备前瞻性以应对未来3-5年的业务演进。我们在分层架构设计、计算引擎抽象、服务治理等领域持续探索，力求在灵活性与标准化之间找到最佳平衡点。

二、分析类应用构建方式演进

阶段一、需求驱动（使用平台之前采用的建设方式）

平台建设之前，所有系统，传统的业务开发方式，根据产品模块（业务）的划分将系统拆分为对应的一个个微服务（或者单体），case by case 实现功能。例如 用户分析 有用户细查、用户报告、路径分析等模块，系统层就对应了同等数量的微服务。仅用户分析一个产品就十几个服务，再加上其他产品，导致服务数量膨胀过多，带来较高的复杂度。每个服务都有完整的 Controller、Service、DAO层，有完整的存储引擎和中间件和发布项、流水线，需要单独部署运维。由于人力不能随之增加，容易超出承载能力。

此种开发方式存在的问题：
由于支持的产品数量变多，缺乏统一规划，容易导致服务拆分不合理、缺少复用性、难以统一维护，造成服务和代码数量膨胀（仅用户分析一项服务数20多个）、系统质量问题频发（用户分析 2022年线上问题数45个）、日常运维耗时耗力（2022年每周耗时 2～3pd 排查处理问题）、研发成本增高（2022年用户分析上线一个模型要40天）等问题。

阶段二、分而治之、中心化开发方式（业界采用的方式）

业界采用的构建方式一般根据产品的类型的不同，分为通用分析和报表分析不同的分析方式。不同的分析方式使用完全不同的构建方式。

通用分析类（例如神策、字节TEA）：常见的建设方式是使用统一的数据模型（明细模型），存储引擎（ClickHouse）构建。系统层基于统一的数据层开发，往往比较薄，架构较为简单。​​

报表分析类：

  • 报表托拉拽式生成（公司魔数、字节 DataWind），通过组合各种组件配置成看板。组件通过页面选择、配置方式完成，整体无需写代码即可完成开发。该方式的优势在于开发门槛低、上线速度快，缺点在于灵活度不够，无法满足复杂的交互和计算需求。
  • 框架开发（BIQuery、筑底），在微服务中嵌入框架，部分逻辑使用框架提供的功能开发，例如数据库连接。这种开发方式的问题在于：1）需要一定的学习成本和代码门槛 2）且框架不支持自定义扩展，增加新组件需要修改框架本身 3）框架非平台，无法统一管理各个应用。

业界的构建方式不完全适合公司，原因是：
1) 公司分析产品的建设具有特殊性。例如与字节对比，由于组织架构不同、分析系统业务范围不同，因此系统复杂度不同。其他公司负责通用分析与定制化分析在不同的团队，分开建设，往往是同类产品（指的是定制分析类和通用分析类）内部架构统一，不同类系统建设统一化平台架构的需求不高。
**2) 探索分析产品建设中有快速迭代试错的需求。**产品需要快速迭代上线产品，以验证不同的分析模式，下线效果不佳的分析模式。这些分析模式短时间内难以抽象为通用的分析模型，通过产品迭代进行探索。

3) 分析产品建设与通用化报表建设思路不同。相比于通用分析报表，具有产品化（独立产品而非报表集合）、重体验（针对用户使用习惯优化）、强交互（例如地图缩放、联动）、高性能（即席分析的性能要求）的业务特点，通用化的平台（例如公司魔数、字节风神）难以满足。

因此，业务特点导致业界没有完全对标的产品。需要根据业务特点，吃透竞品建设内在逻辑，设计出符合公司业务需要、可以解决实际问题的，具有创新性的系统性甚至先进性的方案。

阶段三、统一使用平台平台化开发（目前的开发方式）
平台平台形成了“平台搭台，业务唱戏的合作模式”。平台提供了常用的功能，业务方通过插件扩展业务逻辑，通过配置编排流程。增加新功能模块从增加服务，变成了增加配置和插件包，更加轻量和简单。同时平台和业务也能配合，业务可以扩展平台功能，业务插件也可以更好的下沉到平台层复用。
相对于阶段一，新增模块不再需要新增微服务，只需新增配置+插件包，服务数量从十几个减少到个位数，变得更为轻量和精简。
相对于阶段二，1）平台不再区分通用分析和报表分析开发方式，两者使用统一的应用构建方式，便于统一设计、统一开发、统一运维。2）解决了平台无法扩展，无法灵活满足业务需求的痛点。

三、平台平台应用建设

3.1 平台应用与技术模型

为了应对分析类产品的多样性与复杂度，需要对产品进行建模。以下是平台分析类产品应用建模与对技术实践的建模。

平台分析类产品应用模型：

  • 产品应用层指整个的对外产品，例如用户分析、地理位置分析。
  • 产品应用下包含不同的分析模型（模块），例如 用户分析 包含用户报告分析模块，留存分析模型，地理位置分析包含潜客洞察模块、人口迁徙模块等。
    以上两个层次是用户看得见的，下面的层次是在用户心智之外的概念层。概念层的建模用于更加容易推导出技术模型。
  • 分析模型（模块）按照查询的即时性分类，可以分为在线分析和离线分析。
  • 在线分析和离线分析有自己不同的业务过程，在线分析分为前置查询（查询菜单配置，例如可选的业务线、城市等）和结果查询（分析结果）两步，离线分析包含前置查询、离线任务运行与状态管理、结果查询三步。其中前置查询和结果查询都可以有同步查询
  • 同步查询和异步查询两者都可以由功能点拼接出来。例如城市列表下载功能可以由数据源数据取回功能+数据格式化功能+下载功能组成。

平台技术模型：
目前仅使用到编排层抽象，看板层抽象按需建设，看板模板层暂无需求。

  • 看板模板：技术模型里产品是由多个看板模板（不是具体的看板）组合而成的。例如用户分析是由用户报告类看板、用户路径类看板等构成。用户报告类看板下有用户配置的自己的报告看板。当前没有动态构建产品的需求，无需这一层能力。
  • 编排/看板：每个分析模块，可以使用同一个看板模板配置出多个看板。看板也可以单拿出来作为一个功能，用户可以配置自己的看板。对于不是很复杂的功能或者原子性的分析组件，使用编排。编排指的是将多个功能接口组合成一个逻辑功能接口提供服务。
  • 平台服务：产品中在线分析和离线分析分别对应在线服务和离线服务。
  • 平台框架：业务过程固化成框架，确定每一个业务过程对应技术层所干的事情。
  • 平台/业务插件：产品功能点可以封装为插件，以插件粒度开发和复用，后面有相同功能时，可以复用该插件实现功能，无需再次开发。

3.2 平台标准建设

基于上述模型，平台定义了一些标准与协议，用于规范认知与实践落地，包含分析业务流程、网关接口标准结构、插件数据流转协议、插件编写标准、配置文件标准结构等。

  • 分析业务流程：
    • 在线分析分为前置处理、引擎执行前、引擎执行、引擎执行后、结果后处理五步。所有使用平台在线分析框架（FastBI）构建的应用，均遵循以上业务流程。
    • 离线分析业务流程：模型渲染、模型调度、模型执行、数据导入、模型后处理
  • 插件编写标准：前处理插件，需要继承 PreHandle、分析处理插件需要继承 BuIldInAnalysis、后处理插件需要继承 PostHandle。​​
  • 网关接口标准结构：
    • 接口路径：/api/bi/{appKey}/{queryId}
    • 请求方法：POST
    • 接口参数：JSON类型，要求可以反序列化成 Map<String,Object>
    • 返回结构：code、message、data、pageInfo

3.3 平台操作流程、SOP

基于上述标准，平台总结出常见场景下的操作流程，用于快速、标准化地支持应用建设，例如插件部署流程、问题定位处理流程、项目搭建操作流程等。

四、回顾与展望

4.1 2023 应用建设过程回顾

基于上述模型与平台实现，2023年平台应用于用户留存分析专项一期二期、地理位置分析节假日迁徙报告专项、地理位置分析场景专项开发中，约占整体需求专项的50% 。

  • 效率方面：2023年使用平台开发的专项需求中，无需求delay，研发效率提升50%以上，地理位置分析即席查询场景下实现了每个多维分析报表开发时间从3.5PD提升至0.55PD；2023年产品需求交付未影响产品侧的正常规划 （2022年产品侧反馈需求迭代困难）。
  • 成本方面：节约机器数 12 台，节省人力成本12PD/周（之前每周需要23PD排查问题，现在需要0.5PD ），仅需 L6同学（L7指导） 即可完成日常需求开发（之前需要L7主力，L8指导）
  • 质量方面：截止2023年，有6个产品模块同时使用平台，支持的MAU 1000+，有关平台平台线上问题数为0
    随着支持的需求变多，效果会更加明显。

模型应用（建设过程）：
以用户分析留存分析专项为例
应用模型建设：

产品 产品功能 涉及到的分类 业务过程 功能点
用户分析 留存分析 在线分析、离线分析 在线分析：

- 前置查询：查询ID体系枚举、查询客户端枚举、查询应用枚举

- 结果查询：查询配置的留存日期范围内、第某日留存，可分人群查询。如果在线查询超过10s，降级为离线分析

离线分析：

- 离线查询SQL渲染

- 离线任务提交

- 离线状态流转

- 离线结果导入

​​		 - 数据源连接

- 数据处理

- 查询降级

- 离线任务提交

- 离线数据导入

- 离线任务结果查询

技术模型建设：

看板模板 编排/看板 平台服务 平台框架 平台/业务插件
未涉及该层次 编排：

将留存指标和支付下单指标、按日周月查询编排到一起		 调用在线分析服务、离线分析服务 - 使用在线分析框架（FastBI），处理流程：

网关接收参数→参数校验前处理→Doris 引擎查询 →结果处理→ 平台服务返回

- 离线分析管理框架，处理流程：

网关接收参数→渲染留存分析SQL→任务提交Tolas→任务状态流转到成功状态→结果导入到Doris查询		 数据处理插件（留存业务开发）、下载插件（平台提供）、参数处理插件……

4.2 2024 规划

总体从家庭作坊式开发 → 自动化阶段(人工处理少部分特殊业务逻辑，剩下的平台帮助解决)→ 智能化阶段（AI 员工辅助开发）三步走。
2024年主要的产品专项有：可视化应用升级（分析看板）、转化分析组件、路径分析组件、事件分析组件、用户分析（用户分层）组件。

  • 需求支持度方面：1）转化分析组件、路径分析组件、用户分析组件能力基本具备，与留存分析类似。2）分析看板能力对应技术模型的第二层，待建设。3） 事件分析可能用到元数据管理服务，新建能力还是复用已有能力待定。
  • 开发效率提升方面：配置的托拉拽开发（对标业界开发方式）、AI驱动开发(下一代开发方式)可以按需建设。