跳到主要内容

从实时数仓优化看工作逻辑

· 阅读需 13 分钟
Vstay
Vstay
Sometimes coding, sometimes thinking

在实际工作中，所有任务都可以归结为围绕目标、指标、方案、排期四个核心维度展开。

  • 目标：明确要实现的最终结果或期望状态。
  • 指标：用以衡量目标是否达成的量化标准。
  • 方案：实现目标的具体路径与方法。
  • 排期：根据优先级和资源分配制定的时间计划。

这四个核心点，又可以进一步细分为短期、中期、长期三个时间维度，每个维度对应不同的侧重点与解决策略：

1. 短期方案​

短期方案专注于快速解决当前的紧急问题，常常作为“临时救火”或“特事特办”的解决办法。

  • 优点：实施简单、见效快，能够迅速缓解压力。
  • 缺点：灵活性较差，容易受限于当前场景。一旦有新的需求加入，或问题变复杂，短期方案可能难以为继，甚至需要返工。

2. 中期方案​

中期方案处于短期和长期之间，兼具灵活性与前瞻性。它既要解决当前的问题，又需要为未来的扩展性预留空间。

  • 优点：在当前需求和未来可拓展性之间找到平衡，能够容纳一定程度的新需求。
  • 挑战：需要权衡短期投入与长期收益，确保方案足够灵活但又不失稳定。

3. 长期方案​

长期方案立足全局，旨在彻底解决当前及潜在的问题，追求方案的全局最优。

  • 优点：系统性强，考虑周全，能够适应未来更多的场景变化，减少重复建设和返工的成本。
  • 挑战：通常需要投入较多的人力、物力和时间，短期内可能无法见效。

在实际工作中，短期方案适用于快速响应，短期见效；中期方案强调当前与未来的平衡；长期方案则专注于全局优化。三者并非互相替代，而是可以结合实际情况，逐步递进，通过阶段性优化最终实现长期目标。

从实时数仓的优化来看，制定方案时需结合短、中、长期维度，根据问题的紧急程度与复杂性合理分配资源和优先级，最终在动态中实现整体效率的提升与架构的稳健升级。

目标​

明确方向，定义终点​

目标是工作的起点，也是衡量最终成果的标尺。在任务开始前，明确目标的作用在于：

  1. 聚焦关键问题，确保资源投入到真正重要的事项上。
  2. 避免偏离方向，减少因需求不清或执行偏差导致的资源浪费。

定义工作项​

为更高效地推进任务，需要根据优先级对工作项进行排序，并结合短期、中期和长期目标分层规划：

前置准备：梳理现状，明确需求​

在所有工作开展之前，首先需要全面梳理现有的实时链路，了解以下核心内容：

  • 当前业务场景的全貌，包括上游和下游的特点。
  • 具体的需求与痛点。
  • 链路的使用量及性能瓶颈。
    这一步是后续优化工作的基础，确保解决方案能够精准对焦问题所在。

1. 短期目标：解决紧急问题，快速见效​

优先级：P0（重要且紧急）
示例任务：优化“财富总览”场景的性能问题，目标是解决其在高并发场景下的性能瓶颈。

  • 短期策略：针对性的 Case 优化，聚焦于当前最关键的痛点。
  • 特性：短期目标执行迅速，成效明显，但解决方案通常缺乏系统性，后续需要进一步调整和完善。

短期目标总结：快速解决高优先级问题，保障核心场景的业务连续性和易用性。

2. 中期目标：标准化提升，增强复用性​

中期策略：从现有实时链路中抽象模式，进行套路归并与标准化管理

  • 核心思路：通过分析大量实时链路的作用与特性（如实时表同步），提炼出适配大多数场景的固定 Pattern，推进以下两方面的改进：
    1. 工艺流程优化：通过模式化设计，让实时数仓的工艺流程更加标准化。前期梳理典型业务场景，后期推动业务系统对齐标准。
    2. 资源与需求管理：从团队角度简化资源调配和需求管理，提供统一的外部服务接口，提高协作效率。
  • 目标：提升链路的清晰性与复用性，减少重复性开发工作，增强系统的灵活扩展能力。

中期目标总结：在解决当前问题的基础上，为后续需求的快速响应和标准化建设奠定基础。

3. 长期目标：引入前沿技术，全面优化架构​

长期策略：引入新技术作为全局性解决方案

  • 核心举措：探索并引入前沿技术（如数据湖、物化视图等），打造一站式解决方案，全面应对当前及潜在的业务需求。
  • 目标：最大限度降低人力物力的投入，追求架构的全局最优，消除重复性返工。

长期目标总结：通过前沿技术的应用，为数仓优化提供终极方案，实现架构的高效、稳定和可持续发展。

通过分阶段目标的定义与实施，可以在不同的时间维度内逐步优化实时数仓架构：

  • 短期解决燃眉之急，快速见效；
  • 中期搭建标准化框架，提高复用性与管理效率；
  • 长期实现全局优化，为未来的业务扩展提供稳健支持。
    在实际工作中，需要灵活调整各阶段策略，根据问题的复杂度和优先级合理分配资源，逐步实现实时数仓的高效优化与持续迭代。

指标方面​

量化目标，跟踪进度​

指标是目标的具体化表现，通过量化数据直接反映目标的达成情况，是工作进展和成效的“晴雨表”。
在实际工作中，指标需要满足以下两点：

  1. 可衡量：指标应具有明确的数值表述，便于比较与评估。
  2. 可监控：指标数据应能实时采集和追踪，以便及时调整策略。

定义工作项​

结合实时数仓优化的实际场景，指标的设计需要覆盖多个关键维度，以全面反映优化效果：

1. 性能提升​

  • 方案总耗时：对比优化前后方案的总耗时，明确效率提升的幅度。
    • 示例：优化前总耗时 300ms，优化后总耗时 200ms，效率提升 33%。

2. 资源利用​

  • 内存占用：监控优化方案的内存使用情况，计算减少的资源占用量。
    • 示例：优化前存储过程的内存使用量 8GB，优化后减少至 5GB，节省 37.5%。

3. 扩展能力​

  • 横向拓展与不停机能力：对比原方案与新方案在性能瓶颈时的行为差异。
    • 示例：原方案性能瓶颈需要纵向拓展，停机耗时 3 小时；新方案通过横向拓展实现了零停机，节省了 3 小时维护时间。

4. 并发支持​

  • 性能阈值下的并发量：评估原方案在高并发场景下的性能极限，对比新方案在同等条件下的性能提升。
    • 示例：原方案在 10,000 并发时达到性能瓶颈，新方案在 15,000 并发下才达到瓶颈，提升了 50%。

5. 响应时间 (RT)​

  • 相同并发条件下的 RT 改善：对比原方案与新方案在同样并发量下的响应时间，明确优化效果。
    • 示例：原方案在 10,000 并发下 RT 为 500ms，新方案优化至 350ms，提升了 30%。

指标的作用​

通过以上指标，能够清晰地评估工作的进展和成效，并及时发现潜在问题，为策略调整提供数据支持：

  • 实时监控进展：通过指标监控工作进度，确保优化工作朝预期目标推进。
  • 辅助决策调整：根据指标数据动态调整优化策略，避免资源浪费或方向偏离。
  • 效果量化反馈：通过指标数据直观展示优化效果，提供决策依据。

方案方面​

方案是实现目标的具体路径，也是工作的执行计划。在制定方案时，通常需要经历以下几个步骤：

  1. 调研与分析：明确当前问题的核心与瓶颈，深入理解目标达成的难点。
  2. 头脑风暴：提出多种潜在解决方法，涵盖不同的技术和策略。
  3. 筛选与验证：根据成本、时间、效果、风险等因素，选出最优方案，并通过试验验证其可行性。
  4. 详细设计：将方案分解为具体的执行步骤，明确责任分工和时间节点。

定义工作项​

以实时数仓优化为例，针对不同场景和问题，可以提出以下几种方案：

方案 1：优化 SQL 语句、查询逻辑以及数据库参数​

  • 内容：优化 SQL 的执行计划、数据库参数和索引设置，并尽可能直接计算结果表而不是明细表。
  • 优势：工作量和改动量最小，适合现有配置接近最优的场景。但仍有继续优化的空间，例如继续优化某一存储过程的 session 内存占用。
  • 局限：优化空间有限，效果取决于当前的数据库状态和业务逻辑。例如，数据库参数和索引可能已被前人优化到接近极限。
  • 改造目的：通过减少不必要的计算和资源消耗来提升执行效率，降低查询响应时间，提高短期性能。

方案 2：使用分库分表​

  • 内容：将单一大表拆分为多个小表，通过分库分表缓解访问压力和 IO 瓶颈。
  • 优势：有效分散读写压力，显著提升查询性能。
  • 局限：改动量适中，需要对原有表结构和业务逻辑进行重构。
  • 改造目的：缓解单点压力，将查询和写入负载分散到多个表和库中，提升系统吞吐量和查询效率。

方案 3：服务编排，将存储过程迁移到应用层​

  • 内容：将存储过程的计算逻辑迁移至应用层，通过 API 编排实现横向扩展。聚合操作依然在ADB 中实现，在应用层做加和操作。
  • 优势：提升了横向扩展能力，通过增加应用服务器来避免单点瓶颈。
  • 局限：需要将存储过程逻辑从 SQL 转换为 Java 实现，同时对数据服务平台进行适配性改造。后续新增功能需要同步调整编排逻辑。
  • 改造目的：通过应用层扩展逻辑来分担计算压力，避免数据库成为单点瓶颈，提升系统弹性。

方案 4：基于 Flink + Hologres 的流式数仓​

  • 内容：建立实时数仓，通过 Hologres 实现预计算，应用层仅需执行简单的加和或返回操作。
  • 优势：在高并发场景下提供高效点查能力，将大部分复杂计算提前至数仓完成，提升整体性能。
  • 局限：改动量最大，涉及实时链路的全面重构，需要构建分层实时数仓，对人力和资源的需求较高。
  • 改造目的：通过预计算和分层处理实现复杂场景的高效查询，减少延迟并降低应用层的负载。同时便于支持未来大规模、高并发场景下的实时数据处理和查询需求，通过实时链路优化整体架构，达到性能的全局最优。

方案分析​

  1. 工作量与改动量最小的方案：
    主要通过优化已有资源来提升性能，适用于短期内见效的场景。但此方案改善有限，且受制于现有系统的优化空间。

  2. 平衡型方案：
    分库分表是常见优化的典型方式，通过调整表结构和分片策略提升性能。

  3. 提升横向扩展能力的方案：
    服务编排适合未来可能不断增加的需求场景，但需要投入一定的资源进行逻辑迁移和架构调整。

  4. 长期全局优化方案：
    基于 Flink + Hologres 的方案专注于全局最优，通过实时数仓支持复杂场景下的高效查询，适合面向未来的大规模系统架构，但需要较高的初始投入。

方案选择的决策权​

需要特别注意的是：具体选择何种方案，通常需要由领导决定。领导站在更高的视角，能够综合考虑企业的发展战略、资源分配以及团队能力，从而选择最符合当前实际情况的方案。作为执行者，需要为领导提供详尽的方案分析和数据支撑，帮助其做出合理决策。

排期​

排期是将方案落实为实际行动的重要一步。它明确了任务的优先级、负责人和时间节点。在排期时，需考虑以下因素：

  • 任务依赖：识别出哪些任务必须先完成，哪些可以并行推进。
  • 时间预算：为每个任务分配合理的时间，避免不切实际的压缩。
  • 风险评估：为可能的延误或问题设计缓冲时间和应对措施。

定义工作项​

以下是排期的具体工作拆解，以当前项目为例：

1. 实时任务盘点​

  • 任务：
  • 梳理所有实时任务的台账，确保数据全局清晰。
  • 梳理当前存储过程具体内容，调用session所占内存消耗
  • 了解前期阿里方优化存储过程具体内容，避免重复工作
  • 时间计划：
    • 第一周：完成 v1.0 版本，初步判断现状与问题。
    • 第二周：补充遗漏任务，完善细节与标准化。
  • DDL：12.20，一周判断v1.0，一周补充完善

2. 技术可行性验证​

目标：验证当前技术方案的适用性，避免在后续阶段因技术限制导致返工。
任务列表：

  • Blink 技术验证：
    • 检查是否支持提交 JAR 任务，验证自定义 Sink 和 Source 的可行性（用于搭建 Blink + Holo 标准版的实时数仓分层）。
  • Holo 技术验证：
    • 大宽表性能测试：评估复杂任务在 Holo 上的性能表现。
    • 极限并发测试：探查 Holo 在高并发场景下的性能上限。
  • ADB 技术验证：
    • dblink插件，实现跨库查询（用于支持分库分表）
  • Rill Flow 部署验证：验证服务编排是否可行。
  • DDL：12.27，根据验证结果同步调整优化方案

3. 方案预研​

目标：提前识别并优化方案中可能的瓶颈或不足，为后续落地奠定基础。
任务列表：

  • 存储过程分析：分析“财富总览”功能中的存储过程，记录重点 Session 的内存消耗情况（评估事前的优化空间）。
  • 服务器拆分压测：针对应用服务器进行性能测试，重点关注 QPS、RT 和内存优化表现（评估迁移后的承载能力和提升预期）。
  • DDL：1.18