[Fabric&Power BI] Fabric OneLake & BI 的技术架构 - moxuemeivip/Microsoft-Analysis-Service-Or-Fabric GitHub Wiki

Fabric&Power BI

微软的 Power BI/Fabric OneLake 是一套以“统一数据湖”为核心、融合BI与数据工程的一体化分析平台，其技术架构、存储、查询优化和可视化均基于微软自研技术栈构建，同时在部分底层组件中兼容或集成了开源生态。
以下从四大核心维度拆解其底层技术，并明确开源技术的应用场景：

一、技术架构：基于“统一元数据+多引擎协同”的云原生架构

Fabric OneLake 的架构核心是 “一个数据湖，多个计算引擎”，通过统一元数据层打破数据孤岛，同时对接不同场景的计算引擎（BI、数据仓库、流处理等）。其底层技术支撑分为三层：

架构层级	核心组件	底层技术	开源关联
统一数据层	OneLake 数据湖	1. 基于 Azure Blob Storage 构建（分布式对象存储，提供高可用、低成本的原始数据存储）；2. Delta Lake 协议兼容（支持 ACID 事务、版本控制，解决数据湖“数据混乱”问题）	兼容开源 Delta Lake 协议（微软是 Delta Lake 开源社区的重要贡献者），但 OneLake 本身是自研封装的云原生数据湖，非直接使用开源 Delta Lake 代码
元数据与治理层	OneLake Metadata Hub	1. 自研元数据管理系统（统一存储表结构、权限、数据血缘、数据质量规则）；2. 基于 Azure Active Directory (AAD) 的细粒度权限控制（行级、列级、表级权限）	无开源依赖，元数据模型和治理逻辑为微软自研
计算引擎层	多引擎协同（Power BI 引擎、Lakehouse 引擎、Data Warehouse 引擎、Stream Analytics 引擎）	1. Power BI 引擎：自研的内存分析引擎（VertiPaq 核心）；2. Lakehouse/数据仓库引擎：基于 Azure Synapse 自研的分布式 SQL 引擎（支持 T-SQL、Spark SQL）；3. 流处理引擎：基于 Azure Stream Analytics（兼容 Apache Flink 语义）	流处理引擎兼容 Apache Flink 语义（可导入 Flink 作业），但核心计算逻辑为自研；Lakehouse 支持运行开源 Apache Spark 作业（用户可提交 Spark 任务处理 OneLake 数据）

二、存储模式：“统一数据湖+分层存储”，兼容开源格式

OneLake 的存储模式以“降低数据冗余、提升访问效率”为目标，采用“原始数据+优化格式”分层存储，同时兼容主流开源数据格式：

1. 核心存储技术：Azure Blob Storage + 自研分层策略

底层存储载体：完全依赖 Azure Blob Storage（微软云原生对象存储，支持冷、热、归档 tiers，按访问频率动态调整存储成本），所有数据（原始日志、结构化表、BI 缓存）最终落地为 Blob 对象。
分层存储逻辑：
- 原始数据层（Raw）：存储未加工的原始文件（CSV、JSON、Parquet、ORC 等），直接对接数据 ingestion 工具（如 Data Factory、Spark）；
- 优化层（Optimized）：对高频访问数据，自动转换为 Delta Lake 格式（带事务日志的 Parquet 文件），支持更新/删除/合并操作，避免数据湖“写时复制”的性能问题；
- BI 缓存层（BI Cache）：Power BI 报表访问时，将常用数据集缓存为 VertiPaq 压缩格式（列存储、内存映射），提升可视化查询速度。

2. 开源格式兼容

OneLake 不强制使用自研格式，而是全面兼容开源数据格式，降低数据迁移成本：

结构化/半结构化：Parquet（开源列存格式，高压缩比）、ORC（开源列存格式，常用于 Hadoop 生态）、CSV/JSON；
事务层：兼容 Delta Lake 格式（开源事务层，解决数据湖一致性问题），支持与开源 Spark 生态互通（如用开源 Spark 读写 OneLake 中的 Delta 表）。

三、查询优化：“自研引擎+规则/代价优化”，集成开源 Spark 能力

Fabric OneLake 的查询优化分为 “BI 交互式查询” 和 “大数据批处理/流处理” 两类场景，底层技术各有侧重：

1. Power BI 交互式查询优化（面向低延迟可视化）

核心依赖 Power BI 自研的 VertiPaq 引擎，优化技术包括：

列存储压缩：将数据按列存储，对重复值进行字典编码、Run-Length Encoding（RLE）压缩，压缩率可达 10:1~50:1，减少内存占用；
内存计算：将数据集全量加载到内存（或 Azure 内存优化虚拟机），避免磁盘 I/O 瓶颈，查询响应时间通常在毫秒级；
智能索引：自动为高频过滤列（如日期、维度列）创建索引，支持快速过滤和聚合；
查询折叠（Query Folding）：将 Power Query 的数据转换逻辑“下推”到数据源（如 OneLake 中的 Delta 表、Azure SQL），避免在客户端进行数据处理，减少数据传输量。

2. 大数据查询优化（面向批处理/流处理）

依赖 Azure Synapse 自研 SQL 引擎 和 集成的开源 Apache Spark，优化技术包括：

分布式查询计划：自研代价-based 优化器（CBO），根据数据量、索引、分区情况生成最优执行计划（如 Join 重排序、谓词下推、分区裁剪）；
动态资源调度：基于 Azure 云资源弹性扩展，自动为大查询分配更多 CPU/内存节点，避免资源浪费；
Spark 作业优化：支持用户提交 开源 Apache Spark 3.x 作业，并通过微软自研的“Spark 优化器”增强性能（如自动调整并行度、内存分配，优化 Shuffle 过程）；
流处理低延迟：基于 Azure Stream Analytics 引擎，兼容 Apache Flink 语义，支持毫秒级流数据摄入和实时聚合（如窗口计算、状态管理）。

开源技术应用

大数据处理场景中，直接集成开源 Apache Spark（用户可使用 Scala/Python 编写 Spark 代码，读写 OneLake 数据），但 Spark 运行环境是微软封装的“Azure Databricks 兼容版”，而非原生开源 Spark；
流处理优化中，兼容 Apache Flink 的 API 和语义（如 DataStream API、窗口函数），但核心流处理引擎为微软自研，非直接使用 Flink 代码。

四、可视化：基于“自研渲染引擎+组件化框架”，无开源依赖

Power BI 的可视化能力是其核心竞争力之一，底层完全基于微软自研技术，未使用开源可视化框架（如 D3.js、ECharts），但支持第三方自定义可视化（可基于开源框架开发）：

1. 核心可视化技术

自研渲染引擎：
- 基于 WebGL（硬件加速 3D 图形接口）实现高性能图表渲染，支持百万级数据点的实时拖拽、缩放（如散点图、地图）；
- 采用 矢量图形（SVG） 渲染静态图表（如柱状图、折线图），保证高清显示（无像素模糊），同时减少网络传输量。
组件化框架：
- 内置可视化组件（如矩阵、卡片、地图、漏斗图）基于微软自研的“Power BI Visual Framework”开发，支持组件间联动（如筛选、钻取）、动态刷新（数据更新时自动重绘）；
- 支持第三方自定义可视化（通过“Power BI Visual SDK”开发），第三方可基于 TypeScript + D3.js/ECharts/Three.js（开源可视化库）开发组件，但需符合微软的安全和性能规范。

2. 性能优化技术

数据采样：对超大规模数据集（如 10 亿+ 行），自动采样生成可视化（保持数据分布特征），避免全量渲染导致的卡顿；
增量刷新：仅更新可视化中变化的数据部分（如新增的日期区间），而非重绘整个图表，减少渲染耗时；
自适应布局：根据屏幕尺寸（PC/手机/平板）自动调整图表大小和布局，适配不同终端。

总结：自研为主，开源兼容的技术路线

Fabric OneLake/Power BI 的技术栈以 微软自研核心技术 为根基（如 VertiPaq 引擎、Azure Blob Storage、元数据管理系统），同时通过 兼容开源协议/格式/引擎 降低生态门槛，具体可概括为：

技术维度	核心自研技术	开源技术应用（兼容/集成）
技术架构	OneLake 统一元数据层、多引擎协同逻辑	兼容 Delta Lake 协议、集成 Apache Spark
存储模式	Azure Blob Storage 分层存储、VertiPaq 缓存	兼容 Parquet/ORC/Delta 等开源数据格式
查询优化	VertiPaq 引擎、Synapse SQL CBO 优化器	集成 Apache Spark 作业、兼容 Flink 语义
可视化	WebGL 渲染引擎、Power BI Visual Framework	支持第三方用 D3.js/ECharts 开发自定义组件

这种“自研+开源兼容”的路线，既保证了平台的性能和安全性（自研核心），又兼顾了生态开放性（兼容开源工具），适合企业从“传统BI”向“全链路数据智能”迁移。

ByteDance - Dataleap + ByteHouse 核心能力对比表

对比维度	Dataleap（火山引擎一站式数据研发治理平台）	ByteHouse（火山引擎云原生数据仓库）
使用模式	1. 数据集成：通过 DataSail 全域数据集成功能，支持 37+ 异构数据源（MySQL、Kafka 等）的全量/增量同步，提供 CDC 实时整库解决方案，一键对接 ByteHouse；2. 数据开发：提供 SQL/Python 多语言开发环境，支持可视化任务编排，组合跨引擎任务依赖，完成数据清洗、转换、数仓分层（ODS/DWD 等）加工，输出至 ByteHouse；3. 数据治理：构建数据资产门户（目录/分类）、元数据采集与血缘追踪，定义数据质量规则并检测，保障流入 ByteHouse 数据的准确性；4. 协作管理：支持多环境（开发/生产）引擎实例映射，同一任务配置自动切换数据源，配合权限控制实现团队协同。	1. 数据存储：承接 Dataleap 同步的海量数据，基于存算分离架构存储结构化/半结构化数据，支持无限扩容；2. 查询分析：提供高性能 OLAP 查询能力，处理 Dataleap 加工后的 PB 级数据，支持复杂多表关联、大宽表聚合，响应时间毫秒级；3. 资源适配：对接 Dataleap 的任务调度，动态分配计算资源，支持计算组隔离，匹配不同分析场景的资源需求；4. 数据输出：将查询结果回传 Dataleap，或对接外部可视化工具（如 QuickBI），支撑业务决策。
主要适用场景	1. 多源异构数据归集与同步（如 IDC 上云、他云搬站）；2. 复杂数据处理流程自动化（如 NLP 情感分析数仓开发、广告效果准实时加工）；3. 企业级数据治理与合规管控（医疗/金融敏感数据脱敏、质量监控）；4. 跨引擎数据研发协作（如 Spark 批处理 + ByteHouse 实时分析联动）。	1. 实时数据仓库构建（如实时营销活动分析，秒级响应数据查询）；2. 海量数据 OLAP 分析（如互联网广告投放效果、金融交易记录深度分析）；3. 高并发查询场景（如电商大促期间多维度销售数据统计）；4. 非结构化数据向量检索（如用户行为 embedding 向量匹配）。
技术架构	分为四层核心架构：1. 数据集成层：CDC 实时同步模块 + 离线同步模块，支持多数据源接入；2. 数据开发层：多语言开发环境 + 可视化任务编排调度系统，支持跨引擎任务依赖管理；3. 数据治理层：元数据管理模块 + 数据质量模块 + 资产门户，实现数据资产化；4. 协作管理层：多环境配置 + 权限控制 + 值班管理，保障团队协作与系统稳定。	分为三层核心架构：1. 服务层：资源管理器（动态分配计算资源）、服务节点（解析查询/生成执行计划）、元数据服务（管理表/文件元数据）、权限安全模块；2. 计算层：基于 Kubernetes 编排，以“计算组”为单位实现资源隔离与弹性扩缩容，承担数据写入/查询任务；3. 存储层：存算分离设计，依赖 HDFS/S3 等分布式存储，存储数据文件与索引，支持无限扩展。
自研技术	1. 可视化跨引擎任务编排调度系统，支持复杂流程拖拽配置；2. 自定义数据质量管控模块（规则配置、实时检测、异常告警）；3. 全链路数据血缘追踪系统，支持资产影响分析；4. 敏感数据安全策略（AES 加密、哈希脱敏），联动数据地图实现标签化管理；5. 多环境引擎实例映射与自动切换逻辑。	1. 基于 ClickHouse 重构的云原生架构（存算分离、多租户网络隔离）；2. 自研查询优化器，复杂查询性能较原生 ClickHouse 提升 3-10 倍；3. 智能资源管理器，支持计算资源动态调度、隔离共享与弹性扩缩容；4. 向量检索引擎，支持多种 ANN 算法（如 HNSW），适配非结构化数据分析；5. 租户级资源定制化分配逻辑，保障多业务隔离稳定运行。
开源技术	1. Notebook 功能基于开源 Jupyter 组件（JupyterLab、JupyterHub、Enterprise Gateway）二次开发；2. 数据集成模块兼容开源 CDC 工具（如 Debezium）能力，实现增量数据同步；3. 部分数据处理任务支持对接开源 Spark 引擎执行批处理。	1. 核心查询引擎基于开源 ClickHouse 构建，在此基础上重构架构与增强功能；2. 计算资源编排依赖开源 Kubernetes 实现容器化管理；3. 存储层依赖开源 HDFS 或兼容 S3 协议的开源对象存储；4. 数据导入导出模块借助开源 Spark 框架执行批量数据迁移；5. 日志收集与监控集成开源 Prometheus/Grafana 组件。

阿里云Quick BI

阿里云与微软Power BI对应的产品是Quick BI，与微软Fabric对应的产品无完全对等的单一产品，需通过组合DataWorks（数据开发治理）、AnalyticDB（实时数据仓库）、DTS（数据传输服务）、PAI（机器学习平台）、DataV（数据可视化） 等产品实现类似功能。以下从多维度对比分析：

一、阿里云Quick BI（对标微软Power BI）

1. 技术架构

整体架构：基于阿里云飞天操作系统构建，采用云原生分布式架构，包含数据接入层、计算层、分析层、可视化层。数据接入层支持多源数据连接，计算层依赖阿里云计算资源弹性调度，分析层提供智能计算与洞察能力，可视化层通过前端框架实现交互展示。

2. 适用场景

企业级报表与自助分析：适合零售、金融等行业的业务人员自主进行数据探查、报表制作，如电商平台的销售数据日报/周报生成。
实时业务监控：支持海量数据实时在线分析，可用于游戏行业的服务器性能监控、用户行为实时追踪。
多端协同分析：提供Web、移动端等多端访问能力，适用于企业管理层随时随地查看业务数据看板。

3. 存储

存储模式：自身不直接存储数据，通过数据连接能力对接阿里云AnalyticDB、MaxCompute、MySQL等多种数据源，依赖底层数据源的存储架构，如AnalyticDB的存算分离存储、MaxCompute的分布式存储。

4. 查询优化

自研技术：
- 智能查询加速：内置查询优化器，可根据数据量和查询语句自动选择最优执行路径，支持查询结果缓存。
- 亿级数据毫秒分析引擎（Quick引擎）：针对大数据量查询场景优化，通过预计算、索引优化等技术提升查询速度。
开源技术：兼容SQL标准，可复用开源数据库的查询优化逻辑。

5. 可视化

自研技术：
- 智能分析Agent（小Q系列功能）：集成大模型能力，支持自然语言问数（小Q问数）、自动生成分析报告（小Q报告）、智能搭建可视化看板（小Q搭建），实现数据分析流程自动化。
- 拖拽式可视化设计器：提供丰富的图表组件（柱状图、折线图、地图等），支持自定义配色、布局，满足中国式报表需求。
开源技术：可能参考开源可视化库（如ECharts）的设计理念，但核心交互与渲染逻辑为自研。

二、阿里云组合产品（对标微软Fabric）

微软Fabric是集数据集成、湖仓一体、BI分析、AI集成于一体的全链路平台，阿里云需通过多产品组合实现类似能力，核心组合为DataWorks（数据开发治理）+AnalyticDB（实时数仓）+DTS（数据传输）+PAI（AI集成）+DataV（可视化） ，以下按维度分析：

1. 技术架构

整体架构：各产品深度协同，形成“数据同步-开发治理-存储分析-AI建模-可视化”全链路架构。DataWorks作为中枢调度核心，DTS负责数据实时同步，AnalyticDB提供湖仓一体存储与计算，PAI提供AI建模能力，DataV负责可视化输出。

2. 适用场景

实时湖仓建设：适用于互联网、零售行业的实时数据仓库构建，如电商大促期间的实时销售数据整合与分析，通过DTS同步数据至AnalyticDB，DataWorks完成数据加工，DataV实现实时大屏展示。
多源数据联合分析：适合金融行业整合交易数据、用户数据、外部数据进行风险评估，AnalyticDB支持多源联合查询，PAI调用AI模型进行风险预测。
数据治理与合规管控：政务、医疗等对数据合规要求高的行业，通过DataWorks进行数据质量检测、敏感数据脱敏，保障数据安全与合规。

3. 存储

自研技术：
- AnalyticDB的玄武存储引擎：支持冷热数据分层存储，热数据存于高性能存储介质，冷数据存于低成本存储，兼顾性能与成本；支持一份数据满足离线与在线场景需求。
- AnalyticDB for PostgreSQL的Beam存储引擎：结合ESSD云盘（热数据）与OSS（冷数据），实现存储弹性扩展。
开源技术：
- AnalyticDB集成Hudi存储引擎：利用Hudi的增量数据处理能力，支持数据湖场景下的更新与删除操作。
- 依赖开源分布式存储：如HDFS、S3兼容的对象存储（OSS）作为底层存储介质。

4. 查询优化

自研技术：
- AnalyticDB的羲和计算引擎：支持MPP与BSP两种计算模式自动切换，复杂查询超时后自动转为BSP模式（任务切分、分批调度），提升大数据量计算能力。
- AnalyticDB for PostgreSQL的Laser执行引擎与Orca优化器：优化多表关联、复杂查询的执行效率，结合实时物化视图（IMV）加速查询。
- DataWorks智能调度：通过任务依赖分析与资源动态分配，优化数据处理流程的执行效率。
开源技术：
- AnalyticDB集成Spark计算引擎：利用Spark的分布式计算能力处理复杂离线任务。
- DTS兼容开源CDC工具（如Debezium）能力：实现增量数据同步，简化数据迁移流程。

5. 可视化

自研技术：
- DataV的空间数据可视化方案：结合PolarDB Ganos提供轻量级GIS服务，支持亿级空间数据实时渲染与交互分析，适配国产坐标系（CGCS2000）。
- 低代码可视化搭建：支持拖拽配置业务看板、指挥大屏，内置飞线图、水位图等特色组件，满足智慧城市、工业制造等场景的大屏展示需求。
开源技术：
- 基于WebGL的高性能渲染：复用WebGL的GPU加速能力，实现复杂图形的流畅渲染。
- 集成开源图表库理念：如参考ECharts的图表类型设计，但核心渲染逻辑为自研。

6. 其他核心能力（对标Fabric特色功能）

数据复制与实时同步：
- DTS（自研）：提供Oracle到其他数据库的实时同步能力，支持结构化数据迁移，依赖阿里云生态工具链；DataWorks数据集成支持CDC（变更数据捕获），但需手动配置任务。
AI集成：
- PAI（自研）：支持通过SQL或Python调用AI模型分析数据，但缺乏Fabric数据代理的自然语言交互能力；DataV可结合AI生成可视化洞察，但需用户主动配置分析逻辑。

阿里云的DataWorks、AnalyticDB、DTS、PAI、DataV分别对应Microsoft Fabric中不同的workload，以下是具体对应关系及功能对比：

DataWorks（数据开发治理）

对应Fabric workload：Data Factory（数据工厂）+ Lakehouse（湖仓）的组合 workload。
功能对应分析：
- 数据开发与任务调度：DataWorks的核心能力是数据开发、任务编排与调度，支持构建复杂的数据处理流程。这与Fabric中Data Factory的数据管道（Data Pipeline） 功能高度匹配，后者可通过可视化界面编排数据抽取、转换、加载（ETL）任务，并设置调度策略。
- 数据治理与元数据管理：DataWorks提供数据质量检测、元数据管理、数据血缘追踪等治理功能。Fabric的Lakehouse workload支持元数据自动采集、数据质量规则配置，同时结合Data Factory的任务监控能力，可实现类似的数据治理闭环。
- 跨引擎协作：DataWorks支持对接多种计算引擎（如MaxCompute、Spark），Fabric的Data Factory与Lakehouse也支持跨引擎任务协同，例如通过Spark Notebook处理数据后写入Lakehouse存储。

AnalyticDB（实时数仓）

对应Fabric workload：Warehouse（数据仓库）+ Real-Time Intelligence（实时智能）的组合 workload。
功能对应分析：
- 实时数据存储与分析：AnalyticDB作为实时数仓，支持高吞吐数据写入和低延迟查询，适用于实时营销、交易分析等场景。Fabric的Warehouse workload提供高性能结构化数据存储与OLAP查询能力，而Real-Time Intelligence workload则支持实时数据接入、流处理与分析，两者结合可实现类似AnalyticDB的实时数仓功能。
- 混合负载处理：AnalyticDB支持高吞吐写入、实时计算与在线分析等混合负载，Fabric的Warehouse通过资源隔离技术（如计算组）可同时承载批处理与实时查询任务，Real-Time Intelligence则负责流数据处理，共同满足混合业务需求。
- 物化视图与查询优化：AnalyticDB的实时物化视图功能可加速复杂查询，Fabric的Warehouse支持自动查询优化与索引管理，Real-Time Intelligence则通过流处理引擎优化实时数据查询性能，三者在查询加速逻辑上高度相似。

DTS（数据传输服务）

对应Fabric workload：Data Factory（数据工厂）的Dataflow（数据流）+ Eventstream（事件流） workload。
功能对应分析：
- 多源数据同步：DTS支持全量/增量数据迁移、跨库同步，兼容多种数据源（如MySQL、Kafka）。Fabric的Data Factory Dataflow可通过300+数据转换组件实现多源数据抽取与同步，而Eventstream workload则专注于实时事件数据接入（如Kafka、CDC数据），两者组合可覆盖DTS的核心数据传输场景。
- 实时同步与ETL集成：DTS支持实时CDC同步并集成ETL能力，Fabric的Eventstream可捕获数据库变更数据并实时传输，Dataflow则提供可视化ETL转换功能，与DTS的实时同步+数据处理能力一致。
- 任务监控与管理：DTS提供任务监控、告警与运维功能，Fabric的Data Factory与Eventstream也支持任务运行状态监控、日志查询及异常告警，保障数据传输稳定性。

PAI（AI集成）

对应Fabric workload：AI Engineering（AI工程）+ Machine Learning Studio（机器学习工作室）的组合 workload。
功能对应分析：
- 全流程AI开发：PAI提供数据标注、模型训练、部署等全流程AI工具链，支持分布式训练与自定义算法。Fabric的AI Engineering workload提供Spark Notebook、分布式训练环境等开发工具，Machine Learning Studio则支持低代码模型构建与部署，两者结合可实现类似PAI的AI开发能力。
- 资源管理与隔离：PAI通过工作空间与资源组实现计算资源隔离，Fabric的AI Engineering workload支持Spark池、DLC集群等资源管理，Machine Learning Studio则通过容量分配实现多用户资源隔离，均满足企业级AI开发的资源管控需求。
- 与数据平台集成：PAI可对接DataWorks、AnalyticDB获取数据，Fabric的AI workload也可直接读取Lakehouse、Warehouse中的数据，实现数据与AI模型的无缝联动。

DataV（可视化）

对应Fabric workload：Power BI（商业智能） workload。
功能对应分析：
- 可视化报表与大屏：DataV专注于数据可视化大屏制作，支持地理信息、实时数据渲染等功能。Fabric的Power BI workload提供丰富的可视化组件（如柱状图、地图、自定义视觉对象），可快速构建交互式报表与大屏，满足类似的可视化展示需求。
- 多源数据接入：DataV可对接AnalyticDB、MaxCompute等数据源，Power BI也支持连接Fabric内部的Lakehouse、Warehouse及外部数据源（如SQL Server、Excel），实现数据可视化的多源数据支撑。
- 智能分析与交互：DataV支持简单的数据分析交互，Power BI则提供更强大的智能分析功能（如自然语言问数、异常检测），并支持多端访问（Web、移动端），在交互体验与智能分析能力上更具优势。