Article body
正文
一、为什么需要加速引擎？
在企业数据分析的实际场景中，数据通常散落在多种异构存储系统中——关系型数据库（MySQL、PostgreSQL、Oracle）、大数据平台（Hive、Spark、Impala、MaxCompute）、数据仓库（ClickHouse、StarRocks、Redshift）等。当 BI 平台需要对这些数据进行联合查询、即席分析时，直接穿透到各个源系统会面临几个核心瓶颈：
| 痛点 | 具体表现 |
|---|---|
| 查询延迟高 | 大数据源（Hive、MaxCompute）的查询延迟通常在秒级甚至分钟级 |
| 并发能力弱 | 源系统并非为高并发 OLAP 场景设计，多用户同时查询易导致集群过载 |
| 跨源关联复杂 | 不同数据源之间的 JOIN 操作需要联邦查询引擎，实现复杂且性能差 |
| 建模能力受限 | 缺乏统一的语义层对异构数据进行标准化建模 |
HENGSHI SENSE 的加速引擎正是为了解决上述问题而设计。其核心思路是：将需要频繁查询的数据集导入到专用的 MPP 分析引擎中，通过列式存储、向量化执行、智能索引等 OLAP 技术实现亚秒级响应，同时对上层业务完全透明。
二、加速引擎整体架构
HENGSHI SENSE 的加速引擎架构可以分为三层：数据源接入层、加速引擎层和查询路由层。
┌─────────────────────────────────────────────────────────────┐
│ 查询路由层 (Query Router) │
│ │
│ ┌──────────┐ ┌──────────────┐ ┌────────────────┐ │
│ │ SQL 解析 │───▶│ 数据集元数据 │───▶│ 引擎直连 / 回退 │ │
│ └──────────┘ └──────────────┘ │ 源系统查询 │ │
│ └────────────────┘ │
├─────────────────────────────────────────────────────────────┤
│ 加速引擎层 (Accelerated Engine) │
│ │
│ ┌────────────┐ ┌────────────┐ ┌────────────────────┐ │
│ │ Greenplum │ │ StarRocks │ │ Apache Doris │ │
│ │ (默认) │ │ │ │ │ │
│ └────────────┘ └────────────┘ └────────────────────┘ │
│ │
│ ┌────────────────────────────────────────────────────┐ │
│ │ 外部引擎：MySQL / PostgreSQL / Oracle / ClickHouse │ │
│ │ / Redshift / TiDB / MongoDB / HBase / ... │ │
│ └────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────┤
│ 数据源接入层 (Data Source) │
│ │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────────────┐ │
│ │MySQL │ │PgSQL │ │Oracle│ │Hive │ │ MaxCompute │ │
│ └──────┘ └──────┘ └──────┘ └──────┘ └──────────────┘ │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │Spark │ │MongoDB│ │HBase │ │Impala│ │
│ └──────┘ └──────┘ └──────┘ └──────┘ │
└─────────────────────────────────────────────────────────────┘2.1 核心工作流
当用户在 HENGSHI SENSE 中对某个数据集发起查询时，系统的路由逻辑如下：
- 查询解析：系统解析用户的 SQL 查询，识别涉及的表和数据集。
- 元数据检查：检查该数据集是否已启用加速引擎。
- 路由决策：
- 若数据集已加速且引擎表可用，则将查询路由到加速引擎执行。
- 若数据集未加速或引擎不可用，则回退到原始数据源执行。
- 结果返回：将引擎执行结果返回给前端，用户无感知。
这个”查询直连 + 源系统回退”的双路由机制，保证了系统的鲁棒性——即使加速引擎出现故障，系统仍可通过源系统正常提供服务。
三、内置引擎选型：三种 MPP 引擎深度对比
HENGSHI SENSE 内置了三种 MPP（大规模并行处理）分析引擎，分别面向不同的部署场景和性能需求。
3.1 引擎对比总览
| 特性 | Greenplum（默认） | StarRocks | Apache Doris |
|---|---|---|---|
| 架构基础 | PostgreSQL 内核 | 自研向量化引擎 | 自研向量化引擎 |
| 部署复杂度 | 中等 | 较低（无依赖） | 较低（无依赖） |
| 实时导入 | 支持（Insert） | 流式导入，毫秒级 | 流式导入，毫秒级 |
| 多表 JOIN | 优秀（Hash/Sort Merge） | 优秀（CBO 优化） | 优秀（CBO 优化） |
| 列式存储 | 支持（AO 列存表） | 原生列式 | 原生列式 |
| 压缩比 | 高 | 高 | 高 |
| 社区活跃度 | 稳定 | 非常活跃 | 非常活跃 |
| 适用场景 | 传统企业级数仓 | 实时分析、高并发 | 实时分析、高并发 |
3.2 Greenplum：企业级数仓的首选
Greenplum 作为 HENGSHI SENSE 的默认引擎，其选择并非偶然。Greenplum 基于 PostgreSQL 内核，具备完整的 SQL 支持和丰富的数据类型，同时在 PostgreSQL 的基础上增加了 MPP 分布式执行能力。
技术优势：
- 完善的 SQL 生态：由于基于 PostgreSQL，Greenplum 对窗口函数、CTE（公共表表达式）、递归查询等高级 SQL 特性的支持非常成熟。
- AO 列存表：Greenplum 的 Append-Optimized 列存表（AOCO）能够提供极高的压缩比和查询性能，非常适合 BI 场景下的全表扫描和聚合计算。
- 成熟的运维体系：作为经过十余年生产验证的数据库，Greenplum 的监控、备份、恢复工具链非常完善。
配置示例：
# 基础配置
ENGINE_TYPE=greenplum
ENGINE_DB=jdbc:postgresql://192.168.211.4:15432/postgres
ENGINE_QUERY_USER=hengshi_query
ENGINE_ETL_USER=hengshi_etl
# 高级配置（通过环境变量）
export HS_ENGINE_TYPE="greenplum"
export ENGINE_CONN_POOL_SIZE=20 # 连接池大小，默认10
export DATASET_CACHE_MAX_SIZE_MB=100000 # 数据集缓存上限，默认50000MB
export INTERNAL_ENGINE_DATASET_PATH="public"
export INTERNAL_ENGINE_TMP_PATH="/tmp/hengshi_engine"工程实践建议：
ENGINE_QUERY_USER和ENGINE_ETL_USER的分离是重要的安全实践。查询用户只授予 SELECT 权限，ETL 用户负责数据的导入和更新。通过最小权限原则，即使查询层出现 SQL 注入风险，也不会影响引擎表的写入。
3.3 StarRocks 与 Apache Doris：新一代向量化引擎
StarRocks 和 Apache Doris 是近年来崛起的新一代 OLAP 引擎，它们的设计理念更加贴近实时分析场景：
- 向量化执行引擎：利用 SIMD 指令集实现批量数据处理，在宽表聚合场景下性能通常是传统行存引擎的 5-10 倍。
- 智能物化视图：内置的物化视图自动改写机制，可以在无需修改查询 SQL 的情况下，自动命中最优的预聚合表。
- 流式数据导入：支持 Flink Connector、Kafka 等多种流式数据源的直接写入，实现数据的近实时更新。
对于新建的 HENGSHI SENSE 部署，如果主要分析场景是实时看板和高并发查询，建议优先评估 StarRocks 或 Doris 作为内置引擎。
四、外部引擎集成：打通异构数据生态
HENGSHI SENSE 不仅支持内置引擎，还支持将外部已有的分析数据库作为加速引擎使用。这种”Bring Your Own Engine”的设计，让企业可以利用现有的数据基础设施，避免重复建设。
4.1 支持的外部引擎矩阵
| 数据库类型 | 引擎配置值 | 典型场景 |
|---|---|---|
| PostgreSQL | postgresql | 中小规模团队，已有 PG 实例 |
| MySQL | mysql | 轻量级部署，数据量在千万级 |
| Greenplum | greenplum | 企业已有 GP 集群 |
| ClickHouse | other | 极致性能要求的 OLAP 场景 |
| Oracle | other | 传统金融、电信行业 |
| SQL Server | other | 微软生态 |
| Amazon Redshift | redshift | AWS 云原生数仓 |
| TiDB | other | HTAP 场景 |
| MongoDB | other | 文档型数据的分析加速 |
| HBase | other | 大规模 KV 数据的分析查询 |
4.2 外部引擎配置详解
场景一：使用外部 PostgreSQL 作为加速引擎
# 标识引擎类型
export HS_ENGINE_TYPE="postgresql"
# 指定 JDBC 连接地址
export SYSTEM_ENGINE_URL="jdbc:postgresql://192.168.211.4:45433/engine"
# 数据集导入的 Schema 路径
export INTERNAL_ENGINE_DATASET_PATH="public"
# 标识为外部引擎（非内置部署）
export HS_ENGINE_IF_EXTERNAL=true场景二：使用 ClickHouse 作为加速引擎
ClickHouse 是目前开源社区中公认的单表查询性能最快的 OLAP 引擎。将其作为 HENGSHI SENSE 的外部加速引擎，可以在保持系统灵活性的同时，获得极致的查询性能。
# ClickHouse 使用 "other" 类型标识
export HS_ENGINE_TYPE="other"
# ClickHouse JDBC 地址（注意使用 8123 端口的 HTTP 协议）
export SYSTEM_ENGINE_URL="jdbc:clickhouse://192.168.2.250:8123/public"
# 数据集存储路径（对应 ClickHouse 的 Database）
export INTERNAL_ENGINE_DATASET_PATH="public"
# 标识为外部引擎
export HS_ENGINE_IF_EXTERNAL=true4.3 引擎选型决策树
在实际项目实施中，引擎的选择需要综合考虑数据量、查询模式、部署环境和团队技术栈：
数据量级？
│
┌────────┴────────┐
▼ ▼
< 1亿行 >= 1亿行
│ │
▼ ▼
是否需要实时更新？ 是否已有数据仓库？
│ │
┌─────┴─────┐ ┌────┴────┐
▼ ▼ ▼ ▼
是 否 已有 没有
│ │ Greenplum │
▼ ▼ Redshift ▼
StarRocks Doris ClickHouse │
Doris GP TiDB ▼
StarRocks
Doris五、数据导入与同步机制
启用加速引擎后，HENGSHI SENSE 需要将源数据导入到引擎中。这一过程涉及数据传输、字段映射、增量同步等多个技术环节。
5.1 全量导入流程
┌──────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────┐
│ 源数据集 │────▶│ 字段名编码 │────▶│ 数据类型映射 │────▶│ 写入引擎 │
│ (Source) │ │ (Base62) │ │ (Type Cast) │ │ (Engine) │
└──────────┘ └──────────────┘ └──────────────┘ └──────────┘
│ │
│ ┌────────────────────────────────────┘
│ ▼
│ ┌──────────────────────┐
└─▶│ 元数据注册 │
│ (数据集-引擎表映射) │
└──────────────────────┘5.2 Base62 字段名编码
这是一个在实际工程中容易被忽视但至关重要的细节。不同数据库对标识符（表名、字段名）的支持差异巨大：
| 数据库 | 最大标识符长度 | 支持的字符 | 不支持的特殊字符 |
|---|---|---|---|
| PostgreSQL | 63 字节 | 字母、数字、下划线 | 无 |
| MySQL | 64 字节 | 字母、数字、下划线 | 无 |
| Oracle | 30 字节（12c 前） | 字母、数字、$、_、# | 大量特殊字符 |
| ClickHouse | 63 字节 | 字母、数字、下划线 | 无 |
| SQL Server | 128 字符 | 字母、数字、@、#、$、_ | 无 |
当源数据集的字段名包含中文、空格、特殊符号或超长名称时，直接写入引擎会导致建表失败。HENGSHI SENSE 采用 Base62 编码算法 对字段名进行统一编码，确保跨数据库兼容性。
5.3 增量同步与更新计划
全量导入只是第一步。在数据持续变化的业务场景中，HENGSHI SENSE 通过更新计划（Update Plan） 实现引擎表与原始数据集之间的增量同步。
用户可以在管理界面中为每个加速数据集配置同步策略：
- 同步频率：支持每小时、每天、每周等周期性调度。
- 同步方式：全量覆盖或增量追加，取决于源系统的能力和数据特征。
- 冲突处理：当引擎表中的数据与源数据不一致时，以源数据为准进行覆盖。
注意：对于 Hive、Spark、Impala、Presto、MaxCompute 等大数据源，目前不建议将其数据大规模导入到加速引擎中。这些源系统本身的数据体量通常在 TB 甚至 PB 级，全量导入既不经济也不现实。推荐的做法是：在大数据平台上完成预处理和聚合，将聚合后的结果集导入加速引擎进行二次分析。
5.4 垃圾回收机制
随着数据集的不断创建、修改和删除，引擎中会逐渐积累不再使用的临时表和废弃表。HENGSHI SENSE 内置了垃圾回收（GC）机制来自动清理这些无用资源。
全量导入生成的引擎表使用随机表名，并在表名中嵌入创建时间戳。这种设计有以下好处：
- 避免表名冲突
- 通过时间戳识别长期未更新的过期表
- 结合数据集引用检查，实现精确的资源回收
六、ClickHouse 物化视图：多表联合的实时加速方案
当系统的加速引擎选择 ClickHouse 时，HENGSHI SENSE 提供了一种独特的优化手段——基于 ClickHouse 物化视图的多表联合加速。
6.1 传统方案的痛点
在传统的加速方案中，多表联合数据集（Join Dataset）的处理方式通常是在源系统执行 JOIN 操作，将结果写入引擎表，然后通过更新计划定期重新执行 JOIN 和写入。这种方式存在两个明显问题：
- 延迟不可控：取决于更新计划的频率，数据从源系统到引擎之间存在 N 分钟到 N 小时的延迟。
- 资源浪费：每次全量重新计算 JOIN 结果，即使源数据只有少量变化，也需要重新处理全量数据。
6.2 ClickHouse 物化视图方案
ClickHouse 的物化视图是一种特殊的数据库对象，它在数据写入源表时自动触发预计算，并将结果存储到目标表中。HENGSHI SENSE 巧妙地利用了这一特性，实现多表联合的实时加速。
6.3 核心特性解析
特性一：实时更新，无需更新计划
与传统的定时同步不同，基于物化视图的多表联合数据集不需要设置更新计划。每当左表有新数据写入时，ClickHouse 会自动触发物化视图的计算逻辑，实时更新结果表。
特性二：左表触发的增量计算
物化视图的触发机制有一个重要限制：只有左表的更新才会触发物化视图的重新计算。
工程启示：在数据集建模时，应将更新频率高的表（事实表）设为左表，将变更较少的表（维度表）设为右表。
6.4 使用限制与最佳实践
| 维度 | 建议 | 说明 |
|---|---|---|
| 表数量 | 建议不超过 5 张表的联合 | 复杂的 JOIN 链会降低物化视图的写入吞吐 |
| 左表选择 | 选择数据量最大、更新最频繁的表 | 确保物化视图能被充分触发 |
| 右表变更 | 右表变更时需手动触发重建 | 可通过管理界面操作或 API 调用 |
| 存储规划 | 物化视图会占用额外的存储空间 | 需要为结果表预留足够的磁盘空间 |
| 引擎版本 | 推荐使用 ClickHouse 21.3+ | 新版本的物化视图性能和稳定性大幅提升 |
七、聚合数据集：预计算的性能利器
除了直接导入源数据外，HENGSHI SENSE 还支持聚合数据集（Aggregated Dataset）。聚合数据集通过对现有数据集进行预聚合计算，将大表转换为小表，进一步提升查询性能。
7.1 聚合策略选择
| 聚合策略 | 适用场景 | 粒度损失 | 查询加速比 |
|---|---|---|---|
| 时间维度聚合 | 趋势分析、同比环比 | 丧失明细级分析 | 100x - 1000x |
| 维度组合聚合 | 固定报表、看板展示 | 丧失下钻能力 | 50x - 500x |
| 条件过滤聚合 | TopN 分析、异常检测 | 丧失全局视图 | 10x - 100x |
| 近似聚合 | UV/PV 统计、漏斗分析 | 存在误差范围 | 1000x+ |
八、引擎高级配置详解
| 配置字段 | 说明 | 默认值 | 调优建议 |
|---|---|---|---|
HS_ENGINE_TYPE | 引擎类型标识 | greenplum | 根据选型设置对应值 |
HS_ENGINE_IF_EXTERNAL | 是否使用外部引擎 | false | 外部引擎设为 true |
SYSTEM_ENGINE_URL | JDBC 连接地址 | - | 确保网络延迟 < 1ms |
INTERNAL_ENGINE_DATASET_PATH | 数据集导入路径 | public | 按业务线划分 Schema |
INTERNAL_ENGINE_TMP_PATH | 引擎临时文件路径 | 系统临时目录 | 使用高性能 SSD |
ENGINE_CONN_POOL_SIZE | 引擎连接池大小 | 10 | 高并发场景建议 20-50 |
DATASET_CACHE_MAX_SIZE_MB | 数据集缓存上限（MB） | 50000 | 根据可用内存调整 |
九、生产环境部署建议
9.1 硬件规划
最小生产配置（日均查询量 < 1000）：
├── CPU: 16 核
├── 内存: 64 GB
├── 磁盘: 500 GB SSD
└── 网络: 千兆以太网
推荐生产配置（日均查询量 1000 - 10000）：
├── CPU: 32 核
├── 内存: 128 GB
├── 磁盘: 2 TB NVMe SSD
└── 网络: 万兆以太网
大规模配置（日均查询量 > 10000）：
├── CPU: 64+ 核（分布式集群）
├── 内存: 256 GB+
├── 磁盘: 10 TB+ NVMe SSD（分布式）
└── 网络: 25G 以太网 + RDMA9.2 监控指标
| 监控维度 | 关键指标 | 告警阈值 |
|---|---|---|
| 引擎健康 | 引擎可用性 | 连续 3 次连接失败 |
| 查询性能 | P99 查询延迟 | > 5 秒 |
| 存储使用 | 引擎磁盘使用率 | > 80% |
| 连接池 | 活跃连接数 / 连接池大小 | > 80% |
| GC 效率 | 孤儿表数量 | > 100 |
| 同步延迟 | 更新计划执行偏差 | > 30 分钟 |
十、总结
HENGSHI SENSE 的加速引擎架构体现了现代 BI 平台在异构数据整合和高性能查询之间的工程平衡。通过 MPP 内置引擎（Greenplum/StarRocks/Doris）与外部引擎的灵活组合，系统能够适配从中小企业到大型集团的多样化部署需求。
核心技术亮点回顾：
- 双路由查询机制：引擎直连 + 源系统回退，兼顾性能与鲁棒性。
- Base62 字段编码：优雅解决跨数据库标识符兼容性问题。
- ClickHouse 物化视图：多表联合场景下的实时更新方案，消除定时同步延迟。
- 聚合数据集：通过预计算将十亿行数据压缩到百万行，实现数量级的性能提升。
- 自动化垃圾回收：结合随机表名和引用检查，实现安全的资源管理。
本文基于 HENGSHI SENSE 官方文档和公开技术资料整理，所有配置参数以最新版本为准。