By

前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

一、基本术语

1、文档术语

简称 全称 翻译 说明
PRD Product Requirement Document 产品需求文档  
BRD Business Requirement Document 商业需求文档  
MRD Market Requirement Document 市场需求文档  
PMD Program Managment Document 项目管理文档 项目管理文档，一般包括项目进度、项目资源、责任人和项目输出物，常规通过visio进行甘特图绘制管理。该文档一般贯穿整个项目全程，衡量项目进度。
DRD DesignRequirementDrawing 交互设计文档 一般用来承载交互说明，并交付给前端、测试以及开发工程师参考的文档。
FSD Functional Specifications Document 功能详细说明 定义产品功能需求的全部细节。FSD一般通过一张张的截屏和一条条功能点来定义产品规格。这是一份可以直接让工程师创建产品的文档。
ERP Enterprise Resource Planning 企业资源计划系统  

2、人物术语

简称 全称 翻译 说明
PM Product Manager 、Project Manager 「产品经理」或 「项目经理」  
R&D Research and Development engineer 「研发工程师」  
FE Front End Engineer 「前端工程师」  
DBA Database Administrator 「数据库管理员」  
QA QA Engineer 「测试工程师」  

3、商业术语

简称 全称 翻译 说明
GMV Gross Merchandise Volume 商品交易总额 即商品交易总额，是成交总额（一定时间段内）的意思。多用于电商行业，一般包含拍下未支付订单金额。
ROI Return of investment 投资回报率 即投资回报率，计算方法为 回报/投入，比如投资了十块赚了一百，ROI就是十

4、技术术语

简称 全称 翻译 说明
SLA Service Level Agreement 服务等级协议 微服务架构中的 SLA 是指服务提供商针对每个微服务所制定的服务等级协议。它详细规定了微服务的可用性、性能标准、支持与维护等方面的要求和承诺，以及在未能达到这些标准时应采取的补救措施和赔偿方式。
EMA Exponential Moving Average 指数移动平均线 一种加权移动平均线，它给予较新的价格数据更高的权重，因此能够更快地反映价格趋势的变化，动态超时可以使用该理论
CQRS Command Query Responsibility Segregation 命令查询职责分离 是一种架构模式，用于分离读操作和写操作，以优化应用的性能和可扩展性。它源于传统的数据访问和业务流程设计中常见的问题，特别是当面对高并发读写操作和大量数据处理的场景时。
CAP 一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance） CAP定理 CA P定理指出，一个分布式系统不可能同时满足一致性、可用性和分区容错性这三个条件，最多只能同时满足两个。

5、系统术语

简称 全称 翻译 说明
OA Office Automation 办公自动化 OA 通过协作工具和办公自动化功能简化日常任务，主要集中在办公任务和协作上
CRM Customer Relationship Management 客户关系管理 CRM 通过优化客户关系管理流程提高销售效率，则关注于客户关系和销售
ERP Enterprise Resource Planning 企业资源规划 ERP 则通过整合企业各个部门的流程提高整体运营效率。则涵盖了更广泛的企业资源管理范围，包括财务、生产、供应链等。

二、专业术语

1、数据湖联邦查询

数据湖联邦查询：是数据管理与分析领域的重要概念，其核心在于解决数据湖环境下的跨源数据查询难题。以下从定义、核心价值、技术实现及典型场景等方面展开说明：

数据湖联邦查询的本质是 “让数据不动，计算动”，通过统一引擎打破数据孤岛，实现跨源数据的实时分析。在企业数字化转型中，这一能力可大幅提升数据利用率，降低数据整合成本

1）定义：打破数据孤岛的跨源查询能力

数据湖联邦查询指通过一套统一的查询引擎，对分布在不同存储系统（如对象存储、HDFS、数据库、数据湖等）中的数据进行跨源、无缝的联合查询，而无需将数据进行物理迁移或复制。

联邦：强调 “分布式、多源整合”，类似联邦政府对各州的统一管理，不同数据源保持独立存储，但可被统一访问。

数据湖： 通常指存储海量原始数据的集中式存储系统（如 AWS S3、MinIO、阿里云 OSS 等），数据湖中的数据可能结构各异（结构化、半结构化、非结构化）。

2）核心价值：解决数据湖场景的三大痛点

痛点 传统方案的局限 联邦查询的解决方案
数据分散，无法统一分析 数据存储在对象存储、Hive、MySQL 等多处，需手动同步数据，耗时耗资源。 过统一 SQL 接口直接查询多源数据，如同时查询 S3 中的日志文件和 MySQL 中的业务数据。
数据格式复杂，查询困难 非结构化数据（如 JSON、日志）需先清洗转换为结构化格式才能分析。 支持直接解析多种格式数据（如 Parquet、ORC、JSON、CSV 等），无需预处理。
计算与存储耦合，资源浪费 数据迁移至计算引擎本地存储，占用大量存储资源，且无法复用原始数据。 计算与存储分离，查询时仅读取所需数据，减少存储成本和数据冗余。

3）技术实现：联邦查询的核心组件与流程

a、关键技术组件

  • 统一查询引擎：如 Apache Doris、Trino（PrestoSQL）、Spark SQL 等，提供标准化 SQL 接口。
  • 数据源连接器（Connector）：适配不同存储系统的驱动（如 S3 Connector、Hive Connector、JDBC Connector 等）。
  • 查询优化器：自动规划跨源查询路径，减少数据传输量（如推下过滤条件到数据源执行）。

b、查询流程示例

用户提交SQL查询 → 引擎解析SQL → 通过Connector访问不同数据源 → 优化器规划执行计划（如并行查询S3和Hive）→ 结果合并返回

4）典型应用场景

a、企业数据湖整合

场景：某电商企业将订单数据存于 MySQL，用户行为日志存于 S3，通过联邦查询实时分析 “订单转化与用户浏览行为” 的关联，无需迁移数据。

b、数据湖与数仓的联动

场景：在 Doris 中构建统一数仓，同时通过联邦查询能力直接访问数据湖中的原始日志数据，实现 “数仓结构化数据 + 数据湖原始数据” 的联合分析（如广告投放效果与用户点击日志的关联分析）。

c、多云 / 混合架构数据查询

场景：企业数据分布在本地数据中心和阿里云 OSS、AWS S3等多云环境中，通过联邦查询统一访问，避免数据跨云迁移的网络延迟和成本。

2、即席查询

指用户根据临时需求发起的、非预定义的查询请求，通常没有固定的查询模式或模板，需要系统实时解析并执行。

1）即席查询、固定查询

维度 即席查询 固定查询（如定时报表）
查询发起 用户临时提出（如业务人员突然想分析某类数据） 按预设周期自动执行（如每日生成销售日报）
查询逻辑 灵活可变（支持自定义条件、排序、聚合等） 逻辑固定（如固定统计各地区销售额）
响应要求 需实时或低延迟返回结果（秒级响应） 可接受分钟级或小时级延迟（如定时生成）
使用角色 业务人员、分析师（无需技术背景） 技术人员预先开发，业务人员仅查看结果

2）技术实现：即席查询的核心挑战与解决方案

a、核心挑战

  • 查询复杂度高：用户可能组合大量过滤条件、多表关联，导致 SQL 复杂度骤增（如多维度下钻分析）。
  • 性能压力大：临时查询无法提前优化，需系统实时处理，易出现资源抢占（如全表扫描导致集群卡顿）。

b、技术解决方案

  • 查询优化引擎：
    • 如 Apache Doris 的 CBO（成本优化器）自动选择最优执行计划，避免低效查询（如自动选择索引、拆分并行任务）
    • 示例：用户查询 “按省份、性别、年龄分组的订单金额”，引擎自动选择分区裁剪和向量化聚合，提升性能。
  • 资源隔离与调度：通过队列优先级、资源组限制即席查询对系统的影响（如限制并发数、CPU / 内存占用）。
  • 预计算与缓存：：对高频即席查询的维度组合进行预聚合（如构建聚合模型），减少实时计算量。

3、MPP

MPP（Massively Parallel Processing）即大规模并行处理架构，是一种将计算任务分解为多个子任务，通过多节点并行处理以提升整体性能的分布式系统设计模式。其核心思想是：将数据与计算能力分散到多个节点，每个节点独立处理部分数据，最终汇总结果。

  1. 节点组成与分工
    • 计算节点（Compute Node）：每个节点包含独立的 CPU、内存、存储和网络接口，可自主处理数据。
    • 协调节点（Coordinator Node）：负责接收查询请求、分解任务、调度节点并行计算，并汇总结果。
  2. 数据分布策略
    • 分片（Sharding）：将数据按规则（如哈希、范围、随机）拆分至不同节点，确保数据均衡分布。
    • 示例：按用户 ID 哈希分桶，将用户数据分散到 10 个节点，每个节点处理约 10% 的数据。
  3. 并行处理流程
    1. 协调节点接收查询，分解为多个子任务（如过滤、聚合、关联）。
    2. 子任务分发至对应计算节点，各节点并行处理本地数据。
    3. 计算节点返回中间结果，协调节点汇总后返回最终结果。

ContactAuthor