导读：Cisco WebEx 早期数据平台采用了多系统架构（包括 Trino、Pinot、Iceberg 、 Kyuubi 等），面临架构复杂、数据冗余存储、运维困难、资源利用率低、数据时效性差等问题。因此，引入 Apache Doris 替换了 Trino、Pinot 、 Iceberg 及 Kyuubi 技术栈，依赖于 Doris 的实时数据湖能力及高性能 OLAP 分析能力，统一数据湖仓及查询分析引擎，显著提升了查询性能及系统稳定性，同时实现资源成本降低 30%。
WebEx 是 Cisco 推出的远程、实时的网络会议平台。全球财富 500 强公司中约有 95% 的公司采用 WebEx 来作为视频会议工具，日均会议次数突破 150 万次，全球业务市场超过 160 个。随着市场规模的扩大及使用者持续增加，亟需一个数据平台提供全面的数据及处理分析，以支持故障排查、批量和实时的分析、BI 和大模型的应用、可观测性与数据治理等需求。
在此背景下，WebEx 数据平台从早期的多系统架构（包括 Trino、Pinot、Iceberg 、 Kyuubi 等）改造为基于 Apache Doris 的统一架构。使用 Doris 替换了 Trino、Pinot 、 Iceberg 及 Kyuubi 技术栈，统一数据湖仓及查询分析引擎。显著提升了查询性能及系统稳定性，同时实现资源成本降低 30%。新架构目前已应用于 CCA Peak Ports 项目、Dashboard 系统、统一认证授权等业务场景中。
早期架构及痛点
为适配复杂的业务需求，早期架构融合了多种技术栈。数据源通过 Kafka 进行数据抽取，由 UDP 调度系统（Unified Data Platform：调度 ETL/Spark/Flink 等数据处理任务的平台）将数据调度并存储到湖仓层的 Iceberg 中。Trino、Kyuubi 收到查询请求后提供查询服务，Pinot 主要用于 OLAP 分析。
由于该架构技术栈多样、结构复杂，在实际应用中引发了诸多问题：
运维困难： 多种数据库并存，运维管理工作也变得繁琐且困难。
资源利用率低：数据冗余严重，查询入口不统一，难以实现 CPU 和内存资源的高效利用。
数据一致性问题频发：多个技术栈中数据独立计算，计算口径不一致，常常引发用户负面反馈。
数据治理挑战： 元数据来源多样且格式各异，数据的准确性和一致性难以保障，直接影响了数据治理的效率。
基于 Apache Doris 统一技术栈
01 技术选型
因此迫切需要统一技术栈、降低技术架构的复杂度，同时希望实现性能提升、降低使用成本及简化运维。经过调研，他们发现 Apache Doris 具备的特性能够很好满足这些需求。具体如下：
数据湖能力： Apache Doris 支持 Multi-Catalog 多源数据目录，通过扩展 Catalog 和存储插件，无需将数据物理集中至统一的存储空间，仅借助 Apache Doris 即可实现多个异构数据源的统一联邦分析。目前支持 Hive、 Iceberg、Hudi、Paimon、Elasticsearch、MySQL、Oracle、SQL Server 等主流数据湖、数据库的连接访问。
实时写入： Doris 支持直接从 Kafka 等数据源进行数据订阅和导入，避免了复杂的 ETL 过程，提高了数据的实时性。
简单易用：Doris 提供统一的架构，减少了对多种技术栈的依赖，降低了系统的复杂性，运维难度及工作量均较低，结合多数据源目录，可实现低成本快速迁移。
高性能查询： Doris 采用列式存储和高性能查询引擎，能够快速处理大规模数据集，实现低延迟的查询响应。
02 统一数据湖仓及查询分析引擎
基于上述优势，采用 Apache Doris 替换了原先数据湖仓 Iceberg ，统一了查询引擎 Trino、Kyuubi 以及 OLAP 分析引擎 Pinot。依托于 Doris Multi-Catalog 数据湖能力，无需进行数据传输即可直接查询底层引擎中数据；借助其 OLAP 能力，显著提升了数据分析的效率。
具体收益如下：
降低架构复杂性：由 Doris 替换多个技术栈，简化系统架构，减少组件间的依赖和集成工作。
简化 ETL 流程：原先数据传输需要经过一系列 ETL 与 Spark Load 转换，流程复杂且需要维护大量计算任务。而 Doris Routine Load 能够直接订阅 Kafka 数据，简化了 ETL 流程。
提升资源利用率： 1 个 Doris 集群即可替代原来多个集群，数据无需在多个数据库冗余存储，资源利用率大幅提升，成本节约 30%。
降低运维及使用成本：架构及 ETL 流程的简化，大幅降低潜在故障点的发生次数，系统稳定性得到较大的提升。
Apache Doris 架构下的业务改造实践
01 报表生成耗时缩短 50%
CCA Peak Ports 项目用于在基于 Peak Ports 套餐的计费模式下，计算 WebEx 与 Partner 之间的对账报表。该项目所采用的技术栈较为传统，数据处理链路较长，系统维护工作量较大，因此作为第一批基于 Doris 改造项目。
原方案：
首先，依赖于 Oracle 数据库中的原始表作为数据源，通过一系列存储过程进行计算，生成中间结果。
接着，Java 编写的定时任务进一步处理中间结果，并最终写入 Kafka 消息队列。
最后，通过 Spark Job 将 Kafka 中数据同步到 Iceberg 中提供报表服务。
在上述流程中，一旦数据计算过程中出现问题，排查和调试就会变得相当复杂和繁琐。特别是在 Oracle 存储过程的调试，往往不够直观和便捷，增加了解决问题的难度。同时也由于该流程过于复杂，对数据的实时性也产生了一定的影响。
新方案：
基于 Doris 进行改造，将 Oracle 的存储过程改造到 Spark 与 Doris UDF 中，并使用 Doris 替换了 Iceberg，借助 Doris 高效存储和分析能力直接提供数据服务。具体流程如下：
首先，所有数据已预先存储在 Kafka 中。
接着，通过 Doris 提供的 Doris-Kafka-Connector 插件，通过 Routine Load 可直接将 Kafka Topics 中数据写入 Doris 中，并将数据整合到明细表中构成 DWD 层。
最后，提前部署好的 Spark 作业会对明细数据进行深入的分析与处理，最终将结果写入 DWS 层，由 Doris 提供业务侧数据分析和报表生成的需求。
CCA Peak Ports 项目在基于 Doris 的改造下，整体技术栈风格更为统一，简化了数据处理链路，数据处理更加高效。 在时效性方面，报表更新周期从 T+2 缩短至 T+1；在查询效率方面，报表生成时间由原先 10 分钟缩短至 5 分钟，查询效率至少提升 1 倍多。
02 数据处理流程大幅简化
Dashboard 系统主要用于展示数据治理的全貌，特别是关于 WebEx 的数据资产概况和分析指标，为管理团队的业务决策提供坚实的数据支撑。
在早期数据治理平台中，依赖 Spark 定期任务提取数据进行 Schema 分析和 Lineage 分析。分析后的结果发送至 Kafka，随后由 Pinot 实时摄取，以便后续的处理展示。这种分散的处理方式可能使得数据治理的整体效率和效果受到限制。不同组件之间的数据交换和同步可能会带来额外的开销和延迟，同时也不利于数据的统一管理和优化。
为解决该问题，使用 Doris 替换了 Pinot ，并基于 Doris Multi-Catalog 能力对底层引擎分别建立了 Catalog，使用 Doris 定时任务抽取引擎中数据。抽取的数据被写入上层的主键模型和聚合模型表中。依赖于 Doris SQL 抽取能力以及其提供的数据模型，完全能够满足 Governance Dashboard 的数据需求。
这一方案的节省了原先 11 个 Spark 作业的维护工作，整个 Data Pipeline 都能够在 Doris 中创建和管理，处理流程更加清晰、简单、高效。同时，降低了 UDP 对 CPU 和内存资源的依赖，避免了偶发的因资源不足导致 Job 无法启动的问题。此外，尽管 Doris 相比 Pinot 查询性能并无巨大提升，但在执行相同的查询时，Doris 消耗的资源更少，更能保证查询正常返回。
03 统一查询服务，降低多平台管理难度
在早期认证授权场景中，面临查询入口不统一、用户查询复杂度各异的挑战。这不仅会导致资源利用率低下，还可能引发单个资源密集型查询对其他用户查询性能的严重干扰。
除上述问题外，从用户角度来说，他们需要管理多个系统之间的链接关联，加之各平台密码更新周期的不统一，反复申请认证授权等问题也消耗了大量的时间与精力。
为了解决这些问题，结合 Doris 实现了统一查询服务，整体框架下图所示：
使用 Doris 替换实现了统一的查询服务，依托于 Doris Multi-Catalog 能力，对底层 Trino、Iceberg 和 Pinot 引擎构建 Catalog。 所有应用和作业可以通过查询网关接入 Doris，直接对底层引擎中数据进行查询。
为便于用户使用，还为所有用户创建了 Query Book 服务，以便统一访问湖中数据。此外，结合 Apache Ranger 构建了 Web Auth 服务，将统一认证授权同步至 Doris。原先，用户和平台管理员原先需要在 3 个不同的平台（LDAP/Ranger/DB）中申请和审批权限，现在只需访问 WAP Auth 即可，降低多平台管理负担。还在 Web Auth 中开发了 SQL 规则集模块，支持将规则集的定义同步到 Doris，对高风险 SQL 进行拦截，避免潜在资源滥用。
基于 Doris 的数据治理
作为一个在全球范围内分布应用的在线会议产品，WebEx 面临各个国家、各个地区不同隐私数据保护的法案和相关要求，所以数据治理环节至关重要。
为确保企业数据资产的质量、安全和可用性，需要对 WebEx Data Platform 进行数据治理。在引入 Apache Doris 后，也需将其纳入数据治理体系中。这涉及到元数据融合、数据授权与审计、合规检查、质量检查的融合。为支撑这些融合点，需要构建元数据流、血缘数据流、审查数据流。
01 元数据流
元数据流作用在于确保元数据顺利同步。Schema Registry 可轻松地将元数据推送至 MetaHub，实现集中存储与管理。Doris 提供了丰富的元数据 API 接口，能够无缝接入大量有价值的元数据，增强 MetaHub 的数据完整性和实用性。
02 血缘数据流
血缘数据流整合有两部分：
静态信息拉取：从 Doris 数据库提取定义好的作业信息（如 Routine Job），反映数据从 Kafka 流向 Doris 表的路径。同时获取 Catalog 信息（部分 Catalog 条目对应外部表，Table 直接存储在 Doris 中），以确保捕获外部表的真实血缘关系。
动态数据血缘生成：当新 Job 读取或写入 Doris 时，生成新的数据血缘关系。为管理动态血缘开发了 Client Library，在平台调度 Job 时，Library 以 Sidecar 的形式注入 Job ，Client Library 解析 Job 的 DAG，并基于此生成数据血缘信息，并将信息发送到 MetaHub。
通过结合静态和动态数据血缘的方法，能够全面追踪数据的流动和变化，从而为数据治理和分析提供坚实的基础。
03 审查数据流
数据流审查主要集中在数据审计、合规性检查和质量监控三个方面。在数据审计方面，直接从 Doris 系统中提取 Audit_log 数据，实现高效审计。在合规性和质量监控上，采用定时任务主动扫描并验证 Doris 中的数据，以确保其合规性和质量达标。
在实时生成并写入 Doris 新数据时，可以利用 Client Library 提供的嵌入式功能，持续监测新生成或正在处理的数据，这一机制不仅提升了数据处理效率，还增强了数据管理的安全性与可靠性。
结束语
截至目前，WebEx 数据平台所部署的 Doris 集群近 5 个，总节点数十台。当前已支持在线服务的平均每日查询总数量已超过 10 万，存储总量 40TB+，实时导入的日增数据量高达 5TB+。Doris 的引入不仅带来了诸多降本增效的助力，也驱动其在更大范围内的业务发展探索改造思路与方向：
扩大 Doris 应用范围： 逐步迁移更多数据湖仓中的业务与数据应用层 App 进入 Doris。
增强数据平台功能与性能： 基于 Doris 构建高性能数据分析平台，逐步替代应用自建的分析性存储方案，如 TiDB，Kylin 等。
探索更多应用场景： 探索 AI on Doris 以及 Doris on Paimon 的场景。
加V：busulishang4668
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论