Article body
正文
一、引言：企业数据集成面临的工程挑战
在企业数字化转型的深水区，数据早已不再是单一业务系统的”附属品”，而是驱动决策的核心资产。然而，现实中大多数企业面临的数据格局可以用一个词概括——碎片化。
生产系统的 MySQL、财务部门的 Oracle、分析团队的 ClickHouse、云上部署的 Amazon Redshift、实时采集的 InfluxDB 时序数据……这些数据源在架构、协议、方言上各不相同，要把它们汇聚到一个统一的分析平台，工程难度远超想象。
┌─────────────────────────────────────────────────────────────────┐
│ 企业数据孤岛全景 │
├─────────────┬─────────────┬─────────────┬───────────────────────┤
│ 业务系统 │ 分析平台 │ 大数据生态 │ 云服务 │
├─────────────┼─────────────┼─────────────┼───────────────────────┤
│ MySQL │ ClickHouse │ Hive │ Amazon Redshift │
│ PostgreSQL │ Doris 2.x │ Spark SQL │ MaxCompute │
│ Oracle │ Greenplum │ Impala │ AWS Athena │
│ SQL Server │ Hologres │ Presto │ ADB MySQL │
│ TiDB │ Denodo │ HBase │ AWS Bedrock │
│ 达梦/人大金仓│ Cloudberry │ MongoDB │ NetSuite / OceanBase │
│ PolarDB │ │ InfluxDB │ │
└─────────────┴─────────────┴─────────────┴───────────────────────┘这种多源异构的数据环境带来的核心痛点包括：
- 连接复杂度高：每种数据源都有独立的驱动、认证机制和 SQL 方言，逐一适配的工作量巨大。
- ETL 管道维护困难：数据清洗、转换、加载的逻辑散落在各种脚本和定时任务中，缺乏统一的编排和监控。
- 数据模型碎片化：不同数据源的字段命名、类型定义、关联方式各不相同，构建统一的业务语义层需要大量的映射和转换工作。
- 性能瓶颈：直接在大表上做跨源关联查询，往往会导致严重的性能问题，需要预聚合和物化策略。
HENGSHI SENSE 作为新一代的 BI 增强分析平台，在其三层架构中专门设计了数据适配层，系统性地解决了上述问题。本文将从工程实践的角度，深入剖析 HENGSHI SENSE 的数据集成能力，包括 20+ 数据源的适配策略、ETL 数据管道的实现、数据集市与逻辑建模，以及跨版本演进中的关键技术特性。
二、架构总览：三层解耦的数据集成体系
HENGSHI SENSE 的数据集成能力建立在一个清晰的三层架构之上：
┌─────────────────────────────────────────────────────────┐
│ 表现层 / 应用层 │
│ 仪表盘 · 报表 · 增强分析 · AI Copilot │
├─────────────────────────────────────────────────────────┤
│ 数据服务层 / 语义层 │
│ 数据集市 · 逻辑数据模型 · 聚合数据集 · 指标体系 │
├─────────────────────────────────────────────────────────┤
│ 数据适配层 / 集成层 │
│ 数据源管理 · ETL管道 · 数据清洗 · 类型映射 · 加载调度 │
├─────────────────────────────────────────────────────────┤
│ 数据源层 (20+) │
│ 关系型DB · 数据仓库 · 大数据平台 · NoSQL · 云服务 │
└─────────────────────────────────────────────────────────┘这种分层设计的优势在于：
- 数据适配层对上层屏蔽了不同数据源的技术差异，提供统一的连接、查询和写入接口。
- 数据服务层在适配层之上构建统一的业务语义，用户无需关心底层物理存储的细节。
- 表现层消费语义层提供的能力，实现可视化与分析交互。
本文重点关注数据适配层和数据服务层的工程实现。
三、数据源适配：20+ 数据源的统一接入
3.1 数据源分类体系
HENGSHI SENSE 将支持的数据源按类型划分为六大类，每类有针对性的适配策略：
| 类别 | 代表数据源 | 适配方式 | 典型场景 |
|---|---|---|---|
| 关系型数据库 | MySQL, PostgreSQL, Oracle, SQL Server, TiDB, 达梦, 人大金仓, PolarDB | JDBC 驱动 + 方言解析 | 业务系统数据同步 |
| 分析型数据仓库 | Greenplum, Redshift, Hologres, MaxCompute, ADB MySQL | 原生 SDK / JDBC | 大规模数据分析 |
| 大数据平台 | Hive, Impala, Presto, Spark SQL, Doris 2.x | Thrift / JDBC / REST | 离线/交互式分析 |
| NoSQL / 时序数据库 | MongoDB, HBase, ClickHouse, InfluxDB | 原生 Driver / HTTP API | 日志、IoT、文档数据 |
| 云服务 | AWS Athena, AWS Bedrock, NetSuite, OceanBase | REST API / JDBC | 云原生分析 |
| 数据虚拟化 / 目录 | Denodo, Cloudberry | REST API / JDBC | 跨源联邦查询 |
3.2 关系型数据库适配策略
对于关系型数据库，HENGSHI SENSE 采用 JDBC 驱动 + SQL 方言适配器 的模式。核心思路是：维护一套抽象的 SQL AST（抽象语法树），在执行时根据目标数据源的方言进行重写。
以一个典型的跨库同步为例，源端为 MySQL，目标端为 PostgreSQL：
-- HENGSHI SENSE 抽象 SQL (用户编写)
SELECT
DATE_FORMAT(order_time, '%Y-%m') AS month,
COUNT(DISTINCT user_id) AS unique_users,
SUM(amount) AS total_amount
FROM orders
WHERE status = 'completed'
GROUP BY DATE_FORMAT(order_time, '%Y-%m')
-- 重写后发送给 PostgreSQL
SELECT
TO_CHAR(order_time, 'YYYY-MM') AS month,
COUNT(DISTINCT user_id) AS unique_users,
SUM(amount) AS total_amount
FROM orders
WHERE status = 'completed'
GROUP BY TO_CHAR(order_time, 'YYYY-MM')日期函数、字符串函数、聚合语法的方言差异被适配层自动处理，用户无需手动维护多套 SQL。
国产数据库的支持是另一个重点。达梦数据库（DM）和人大金仓（KingbaseES）虽然兼容 PostgreSQL 协议，但在某些函数实现和数据类型上存在差异。HENGSHI SENSE 为它们维护了独立的方言配置，确保 IDENTITY 列、CLOB 类型、窗口函数等特性能正确处理。
3.3 NoSQL 与时序数据库适配
NoSQL 数据源的适配难度远高于关系型数据库，因为它们缺乏统一的查询标准。
MongoDB 适配是 HENGSHI SENSE 在 NoSQL 领域的重点投入方向：
- Mongo 直连：支持直接连接 MongoDB 集群，通过 MongoDB 原生协议进行数据读取。
- 自动 Schema 探测：自动扫描 MongoDB Collection 中的文档结构，推断字段类型。
- 手动字段补全：对于自动探测不到的字段（如稀疏字段、嵌套层级较深的字段），支持手动输入补充。
- Native ObjectId 解析：MongoDB 的
_id字段使用 ObjectId 类型，HENGSHI SENSE 能自动将其解析为可读的字符串形式，方便在 BI 分析中使用。 - JSON Array 拆分：支持将 MongoDB 文档中的 JSON Array 类型字段拆分为多行，实现类似关系型的扁平化处理。
// MongoDB 原始文档示例
{
"_id": ObjectId("662a1b2c3d4e5f6a7b8c9d0e"),
"user_name": "张三",
"orders": [
{ "product": "A", "amount": 100, "date": "2025-01-15" },
{ "product": "B", "amount": 250, "date": "2025-02-20" }
],
"tags": ["VIP", "高频用户"]
}
// HENGSHI SENSE JSON Array 拆分后的结果
┌──────────────────────┬──────────┬─────────┬────────────┬──────┐
│ _id (解析后) │user_name │ product │ amount │ date │
├──────────────────────┼──────────┼─────────┼────────────┼──────┤
│ 662a1b2c3d4e5f6a... │ 张三 │ A │ 100 │2025-01│
│ 662a1b2c3d4e5f6a... │ 张三 │ B │ 250 │2025-02│
└──────────────────────┴──────────┴─────────┴────────────┴──────┘InfluxDB 适配（6.1.0 版本新增）则针对时序数据的特点做了专项优化：
┌──────────────────────────────────────────────────────────┐
│ InfluxDB 适配架构 │
│ │
│ InfluxDB Line Protocol ──→ 字段/标签映射 ──→ 虚拟关系表 │
│ │
│ measurement ───────→ 表名 │
│ tags ──────────────→ 维度列 (GROUP BY) │
│ fields ────────────→ 指标列 (聚合计算) │
│ timestamp ─────────→ 时间列 │
│ │
│ 降采样策略： │
│ - 原始数据保留策略 (RP) 映射为数据生命周期 │
│ - CQ (Continuous Query) 映射为预聚合任务 │
└──────────────────────────────────────────────────────────┘时序数据通常数据量巨大，直接全量同步不现实。HENGSHI SENSE 支持配置 InfluxDB 的 Retention Policy 和降采样规则，只同步分析所需的粒度数据。
3.4 数据虚拟化：Denodo 适配
5.2.0 版本新增的 Denodo 支持标志着 HENGSHI SENSE 从”物理集成”向”逻辑集成”的延伸。Denodo 作为企业级数据虚拟化平台，本身就能对底层多种数据源进行联邦查询。HENGSHI SENSE 与 Denodo 的对接，使得用户可以在不移动数据的前提下，将 Denodo 暴露的虚拟视图直接作为 BI 分析的数据源。
┌───────────────────────────────────────────────────────────┐
│ 物理集成 vs 逻辑集成 │
│ │
│ 物理集成 (传统 ETL): │
│ [MySQL] ──ETL──→ [数据仓库] ──→ [BI 分析] │
│ [Oracle] ──ETL──→ [数据仓库] ──→ [BI 分析] │
│ │
│ 逻辑集成 (Denodo + HENGSHI SENSE): │
│ [MySQL] ─┐ │
│ [Oracle] ─┤──→ [Denodo 虚拟层] ──→ [HENGSHI SENSE] │
│ [S3] ──┘ ↑ ↑ │
│ 不移动数据 统一语义分析 │
└───────────────────────────────────────────────────────────┘这种模式特别适合对数据时效性要求高、数据治理策略不允许大规模复制数据的场景。
四、ETL 数据管道：从数据同步到智能加工
4.1 ETL 计算流程概览
HENGSHI SENSE 内置了完整的 ETL 计算引擎，支持从数据抽取、清洗转换到加载的全流程编排：
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ Extract │───→│Transform│───→│ Load │───→│ Verify │
│ 抽取 │ │ 转换 │ │ 加载 │ │ 校验 │
└────────┘ └────────┘ └────────┘ └────────┘
│ │ │ │
▼ ▼ ▼ ▼
增量/全量 数据清洗 写入目标表 行数/数值
同步策略 类型转换 索引创建 一致性校验
断点续传 关联聚合 分区管理 数据质量
并行抽取 去重过滤 事务控制 监控告警4.2 数据清洗与类型转换
数据清洗是 ETL 流程中最耗时的环节之一。HENGSHI SENSE 提供了以下核心清洗能力：
| 清洗操作 | 说明 | 示例 |
|---|---|---|
| 空值处理 | 填充默认值 / 前后值填充 / 删除 | NULL 金额填充为 0 |
| 类型转换 | 字符串↔数值↔日期 | ”2025-01” → Date 类型 |
| 去重过滤 | 基于主键 / 组合字段去重 | 相同订单号只保留最新记录 |
| 字符串清洗 | 去空格、统一大小写、正则替换 | ” VIP ” → “VIP” |
| 数据标准化 | 编码统一、格式规范化 | 手机号脱敏、金额单位统一 |
# HENGSHI SENSE ETL 数据清洗逻辑示意（伪代码）
pipeline = ETPipeline("order_cleaning")
# 抽取阶段：从 MySQL 增量抽取
pipeline.extract(
source="mysql_production.orders",
mode="incremental",
watermark_column="update_time",
watermark_value="${last_run_time}"
)
# 转换阶段：数据清洗
pipeline.transform([
# 空值处理
FillNull(column="discount", value=0.0),
FillNull(column="remark", value="无"),
# 类型转换
Cast(column="order_date", target_type="DATE",
format="yyyy-MM-dd HH:mm:ss"),
# 字符串清洗
Trim(column="customer_name"),
Upper(column="status"),
# 去重（按 order_id 保留最新记录）
Deduplicate(key_columns=["order_id"],
order_column="update_time",
strategy="keep_last"),
# 关联维度表
Lookup(source="dim_product",
join_keys={"product_id": "id"},
fetch_columns=["category", "brand"])
])
# 加载阶段：写入分析型数仓
pipeline.load(
target="greenplum_analytics.dwd_order_detail",
mode="upsert",
primary_key=["order_id"]
)4.3 关联聚合与预计算
在实际的分析场景中，大表直接关联查询往往是性能杀手。HENGSHI SENSE 通过聚合数据集机制，将大表预先聚合为小表，显著提升查询性能。
原始明细表 (1000万行) 聚合数据集 (1万行)
┌─────────────────────────┐ ┌──────────────────────┐
│ order_id | date | amount│ │ month | total_amount│
│ 1 | 01-01| 100 │ ══→ │ 2025-01| 1,250,000 │
│ 2 | 01-01| 250 │ │ 2025-02| 1,380,000 │
│ ... | ... | ... │ │ ... | ... │
│ 10000000 | 12-31| 80 │ └──────────────────────┘
└─────────────────────────┘
查询性能：从数秒级 → 毫秒级聚合数据集的核心配置包括：
- 粒度选择：按时间维度（年/季/月/周/日）和业务维度进行粒度切分。
- 度量聚合：COUNT、SUM、AVG、MAX、MIN 等聚合函数的组合。
- 刷新策略：全量刷新 / 增量追加 / 增量合并。
- 数据生命周期：自动清理过期聚合数据，控制存储成本。
4.4 API 数据源的配置化接入
传统 BI 工具对接 API 数据源通常需要编写 Groovy 或 Python 脚本，这对非开发人员来说门槛较高。HENGSHI SENSE 引入了API 数据源配置化创建能力，通过可视化配置即可完成接入：
┌────────────────────────────────────────────────────────┐
│ API 数据源配置流程 │
│ │
│ 1. 基础连接配置 │
│ ┌──────────────────────────────────┐ │
│ │ URL: https://api.example.com/v1 │ │
│ │ Method: POST │ │
│ │ Auth: Bearer Token │ │
│ │ Headers: Content-Type: JSON │ │
│ └──────────────────────────────────┘ │
│ ↓ │
│ 2. 请求参数配置 │
│ ┌──────────────────────────────────┐ │
│ │ Body: {"start_date": "${date}", │ │
│ │ "page": "${page}"} │ │
│ │ 分页策略: 游标翻页 / 偏移量翻页 │ │
│ └──────────────────────────────────┘ │
│ ↓ │
│ 3. 响应解析配置 │
│ ┌──────────────────────────────────┐ │
│ │ 数据路径: $.data.records │ │
│ │ 总数路径: $.data.total │ │
│ │ 字段映射: │ │
│ │ $.id → order_id │ │
│ │ $.amount → amount │ │
│ │ $.created → create_time │ │
│ └──────────────────────────────────┘ │
│ ↓ │
│ 4. 调度配置 │
│ ┌──────────────────────────────────┐ │
│ │ 频率: 每小时 / 每天 / Cron 表达式 │ │
│ │ 超时: 300s │ │
│ │ 失败重试: 3次，间隔60s │ │
│ └──────────────────────────────────┘ │
└────────────────────────────────────────────────────────┘这种配置化的方式大幅降低了 API 数据接入的门槛，业务分析师也能独立完成配置，无需依赖研发团队。
4.5 数据填报与批量导入
除了从外部数据源抽取数据，HENGSHI SENSE 还支持数据填报功能，允许用户手动录入数据。对于大规模的数据录入，支持 Excel 多 Sheet 批量导入：
- 支持一个 Excel 文件中包含多个 Sheet，每个 Sheet 对应不同的数据表。
- 自动进行数据类型推断和字段映射。
- 支持导入预览和错误数据定位。
- 导入结果可追溯，支持部分成功场景下的回滚处理。
五、数据集市与逻辑建模：构建统一的业务语义层
5.1 从物理数据到业务语义
数据集成只是第一步。在完成数据汇聚之后，如何让业务用户用他们熟悉的语言去查询和分析数据，是 BI 平台的核心价值所在。HENGSHI SENSE 通过数据集市和逻辑数据模型来解决这一问题。
┌────────────────────────────────────────────────────────────┐
│ 语义层构建路径 │
│ │
│ 物理层 逻辑层 业务层 │
│ ┌──────────┐ ┌──────────┐ ┌──────┐ │
│ │ MySQL │ │ │ │ │ │
│ │ orders │──┐ │ 业务数据集 │──┐ │ 仪表盘│ │
│ ├──────────┤ │ │ 映射关系 │ │ │ 报表 │ │
│ │ PG │ ├──ETL──→│ 逻辑数据 │ │─分析───→│ 即席 │ │
│ │ products │ │ 模型 │ 模型 │ │ 查询 │ 查询 │ │
│ ├──────────┤ │ │ │ │ │ │ │
│ │ ClickHK │──┘ │ 指标定义 │ │ │ │ │
│ │ logs │ │ │ │ │ │ │
│ └──────────┘ └──────────┘ │ └──────┘ │
│ │ │
│ 技术视角：表、字段、类型 业务视角： │
│ 事实、维度、指标、口径 │
└────────────────────────────────────────────────────────────┘5.2 业务数据集映射
业务数据集是物理数据表在语义层的”投影”。用户不需要直接操作底层物理表，而是基于业务数据集进行分析。核心映射关系包括：
| 映射维度 | 说明 | 示例 |
|---|---|---|
| 表名映射 | 将技术表名映射为业务名称 | ods_order_2025 → 销售订单 |
| 字段别名 | 将技术字段映射为业务名称 | cust_id → 客户编号 |
| 数据类型 | 逻辑类型与物理类型的解耦 | BIGINT → 金额(数值型) |
| 计算字段 | 基于物理字段派生新字段 | 利润率 = (收入 - 成本) / 收入 |
| 隐藏字段 | 隐藏不需要暴露的技术字段 | 隐藏 etl_time、is_deleted |
| 权限控制 | 行级 / 列级数据权限 | 华东区只能看到华东数据 |
5.3 逻辑数据模型与环形关联
数据模型是 HENGSHI SENSE 语义层的核心。它定义了不同业务数据集之间的关联关系，是构建跨表分析查询的基础。
HENGSHI SENSE 6.0 版本引入了数据模型环形关联支持，这是一个重要的架构升级。
在传统的星型/雪花型模型中，维度表通过外键与事实表关联，维度表之间通常不允许直接关联（避免扇出陷阱和环形依赖）。但在实际业务中，环形关联是一个非常普遍的需求。
传统模型（不允许环形）：
┌──────┐ ┌──────────┐ ┌──────┐
│ 客户 │────→│ 订单 │────→│ 产品 │
└──────┘ └──────────┘ └──────┘
│
↓
┌──────────┐
│ 订单明细 │
└──────────┘
环形关联模型（6.0+ 支持）：
┌──────┐ ┌──────────┐ ┌──────┐
│ 客户 │←───→│ 订单 │←───→│ 产品 │
└──┬───┘ └────┬─────┘ └──┬───┘
│ │ │
└───────────────┼───────────────┘
↓
┌──────────┐
│ 行为日志 │
└──────────┘环形关联的工程实现需要解决以下技术难题：
- 关联路径推导：当存在多条关联路径时，系统需要自动选择最优路径（基于成本估算）。
- 歧义消除：当用户从”客户”维度查询”产品”指标时，系统需要判断是通过”订单”还是通过”行为日志”进行关联。
- 循环检测：在构建关联图时，需要检测并处理循环依赖，避免无限递归。
- 查询性能：环形关联可能导致多表 Join，需要智能的查询优化策略（如谓词下推、Join 重排序）。
5.4 数据集市与预置模型
数据集市是面向特定业务域的数据子集，它将相关的业务数据集、指标和维度组织在一起，形成一个自包含的分析空间。
HENGSHI SENSE 支持数据集市创建者标记预置模型的功能，这意味着数据管理员可以：
- 为每个数据集市预置常用的数据模型和关联关系。
- 为新加入的业务用户提供”开箱即用”的分析环境。
- 确保不同团队使用一致的指标定义和口径。
┌──────────────────────────────────────────────────┐
│ 数据集市示例：销售分析 │
│ │
│ ┌──────────────────────────────────────────┐ │
│ │ 预置模型 (由数据管理员配置) │ │
│ │ │ │
│ │ 销售订单 ──→ 客户维度 ──→ 区域维度 │ │
│ │ │ │ │ │
│ │ ↓ ↓ │ │
│ │ 产品维度 ──→ 业绩指标 ──→ 时间维度 │ │
│ │ │ │
│ │ 预置指标: │ │
│ │ · 销售总额 = SUM(金额) │ │
│ │ · 同比增长率 = (本期-同期)/同期 │ │
│ │ · 客户留存率 = ... │ │
│ └──────────────────────────────────────────┘ │
│ │
│ 业务用户可直接基于预置模型构建分析，无需从零开始 │
└──────────────────────────────────────────────────┘六、高级特性与工程实践
6.1 JSON Array 拆分能力
随着 JSON 数据在互联网应用中的广泛使用，越来越多的业务数据以 JSON 格式存储。HENGSHI SENSE 针对 MySQL、ADB MySQL 和 StarRocks 中的 JSON Array 类型字段提供了原生拆分能力。
-- 原始数据：MySQL JSON Array 字段
-- 表: user_events
-- 列: user_id (VARCHAR), events (JSON)
-- 原始数据
┌─────────┬─────────────────────────────────────────┐
│ user_id │ events (JSON) │
├─────────┼─────────────────────────────────────────┤
│ U001 │ [{"type":"click","page":"home"}, │
│ │ {"type":"purchase","page":"checkout"}] │
│ U002 │ [{"type":"view","page":"product"}] │
└─────────┴─────────────────────────────────────────┘
-- HENGSHI SENSE JSON Array 拆分配置后
-- 拆分字段: events
-- 提取子字段: type, page
┌─────────┬──────────┬───────────┐
│ user_id │ event_type│ page_name │
├─────────┼──────────┼───────────┤
│ U001 │ click │ home │
│ U001 │ purchase │ checkout │
│ U002 │ view │ product │
└─────────┴──────────┴───────────┘这种能力让用户可以直接将 JSON 结构化数据转化为可分析的关系型数据，无需编写复杂的 JSON_EXTRACT SQL。
6.2 跨应用复制与数据集合并（6.2 版本）
在大型企业中，不同部门可能各自建立了自己的分析应用。6.2 版本引入的跨应用复制数据集功能解决了跨部门数据复用的问题：
┌──────────────┐ 复制数据集 ┌──────────────┐
│ 销售部应用 │ ─────────────────→ │ 管理层应用 │
│ │ │ │
│ · 订单数据集 │ 同时复制: │ · 订单数据集 │
│ · 客户数据集 │ - 数据集结构 │ · 客户数据集 │
│ · 指标定义 │ - 字段定义 │ · 指标定义 │
│ │ - 指标定义 │ │
│ │ - HE逻辑 │ │
└──────────────┘ └──────────────┘关键特性包括：
- 支持复制指标：数据集下的指标定义会被一并复制，确保分析口径的一致性。
- 合并数据集中的字段、指标：来自不同应用的数据集可以被合并，HENGSHI SENSE 会自动进行字段匹配和冲突检测。
- HE 及 Metric HE 代码逻辑复制：高级表达式（HE）和指标级高级表达式的代码逻辑也会被完整复制。
6.3 数据集成性能优化策略
在实际的生产环境中，数据集成的性能至关重要。以下是 HENGSHI SENSE 在工程实践中总结的关键优化策略：
| 优化维度 | 策略 | 效果 |
|---|---|---|
| 抽取优化 | 增量同步（基于时间戳/Watermark） | 减少 90%+ 数据传输量 |
| 抽取优化 | 并行分片抽取（大表按主键范围分片） | 线性提升抽取速度 |
| 转换优化 | 流式处理（逐批处理，避免全量加载到内存） | 支持超大数据集 |
| 转换优化 | 谓词下推（将过滤条件推送到源端执行） | 减少网络传输 |
| 加载优化 | Bulk Insert / COPY 命令 | 提升写入速度 5-10x |
| 加载优化 | 事务批量提交 | 减少事务开销 |
| 缓存优化 | 查询结果缓存 | 重复查询毫秒级响应 |
七、版本演进与功能路线图
HENGSHI SENSE 的数据集成能力在持续演进，以下是关键版本的特性更新：
| 版本 | 数据集成相关特性 |
|---|---|
| 5.2.0 | 新增 Denodo 数据虚拟化平台支持；增强 MongoDB Native ObjectId 解析 |
| 6.0.0 | 数据模型环形关联支持；聚合数据集性能优化 |
| 6.1.0 | 新增 InfluxDB 时序数据库支持；API 数据源配置化创建 |
| 6.2.0 | 跨应用复制数据集（支持指标复制）；合并数据集（字段/指标/HE 逻辑合并） |
从版本演进可以看出几个清晰的演进趋势：
- 数据源覆盖面持续扩大：从传统关系型数据库扩展到 NoSQL、时序数据库、数据虚拟化平台。
- 操作门槛持续降低：从脚本开发到配置化操作，让更多业务用户能自助完成数据接入。
- 跨团队协作能力增强：从单应用内的数据管理到跨应用的数据复用和合并。
- 模型能力持续深化：从简单的星型模型到支持环形关联的复杂语义模型。
八、总结
HENGSHI SENSE 的数据集成与多源异构数据引擎，本质上是在解决一个经典的工程问题：如何让分散在各个系统中的数据，以一种高效、统一、可维护的方式汇聚到一起，并转化为业务可理解、可直接分析的信息资产。
通过本文的分析，我们可以看到 HENGSHI SENSE 在这一领域的几个核心优势：
- 全面的数据源覆盖：20+ 数据源涵盖关系型、分析型、大数据、NoSQL、时序、云服务、数据虚拟化等全品类，满足了绝大多数企业的数据集成需求。
- 工程化的 ETL 管道：内置的 ETL 引擎支持增量同步、数据清洗、关联聚合、类型转换等全流程，配置化操作降低了开发门槛。
- 灵活的语义层建模：通过数据集市和逻辑数据模型，构建统一的业务语义层，支持环形关联等复杂场景，让业务用户能自然地进行跨表分析。
- 持续的版本迭代：从 5.x 到 6.2，每一版都在扩展数据源类型、降低操作门槛、增强协作能力，体现了对用户需求的持续关注。
对于正在面临数据集成挑战的企业和团队来说，HENGSHI SENSE 提供了一个值得深入评估的工程化解决方案。它不仅仅是一个 BI 工具，更是一个面向分析场景的完整数据平台。