数仓学习总结

### 数仓学习总结

#### 1. 数仓概念

数据仓库是信息（对其进行分析可做出更明智的决策）的中央存储库。通常，数据定期从事务系统、[关系数据库](https://aws.amazon.com/cn/relational-database/)和其他来源流入数据仓库。业务分析师、数据工程师、数据科学家和决策者通过[商业智能 (BI) 工具](https://aws.amazon.com/cn/quicksight/)、SQL 客户端和其他分析应用程序访问数据。

数据和分析已然成为各大企业保持竞争力所不可或缺的部分。企业用户依靠报告、控制面板和分析工具从其数据中获得洞察力、监控企业绩效以及更明智地决策。数据仓库通过高效地存储数据以便最大限度地减少数据输入和输出 (I/O)，并快速地同时向成千上万的用户提供查询结果，为这些报告、控制面板和分析工具 由数据仓库提供支持。

##### 1.1 什么是数据仓库

数据仓库简称数仓，其英文名为 Data Warehouse（简写为 DW 或 DWH）。按照数据仓库系统构造方面的领衔设计师 William H. Inmon 的说法，“数据仓库是个面向主题的、集成的、时变的、非易失的数据集合，支持管理者的决策过程”。这个简短而又全面的定义指出了数据仓库的主要特征。四个关键词，面向主题的、集成的、时变的、非易失的，将数据仓库与其他数据存储系统（如关系数据库系统、事务处理系统和文件系统）相区别。

- 面向主题的（subject oriented）：数据仓库围绕一些重要主题，如顾客、供应商、产品和销售组织。数据仓库关注决策者的数据建模与分析，而不是单位的日常操作和事务处理。因此，数据仓库通常排除对于决策无用的数据，提供特定主题的简明视图。
- 集成的（integrated）：通常，构造数据仓库是将多个异构数据源，如关系数据库、一般文件和联机事务处理记录集成在一起。使用数据清理和数据集成技术，确保命名约定、编码结构、属性度量等的一致性。
- 时变的（time-variant）：数据存储从历史的角度（例如，过去 5~10 年）提供信息。数据仓库中的关键结构都隐式或显式地包含时间元素
- 非易失的（nonvolatile）：数据仓库总是物理地分离存放数据，这些数据源于操作环境下的应用数据。由于这种分离，数据仓库不需要事务处理、恢复和并发控制机制。通常，它只需要两种数据访问操作：数据的初始化装入和数据访问。

##### 1.2 数据仓库和数据库的比较

由于大多数人都熟悉商用关系数据库系统，将数据仓库与之比较，就容易理解什么是数据仓库。

联机操作数据库系统的主要任务是执行联机事务和查询处理，这种系统称做联机事务处理（Online Transaction Processing, OLTP）系统，它们涵盖了企业的大部分日常操作，如购物、库存、制造、银行、工资、注册、记账等。另一方面，数据仓库系统在数据分析和决策方面为用户或数据分析员提供服务，这种系统可以用不同的格式组织和提供数据，以便满足不同用户的形形色色的需求，这种系统称做联机分析处理（Online Analytical Process ing, OLAP）系统。

OLTP 和 OLAP 的主要区别概述如下：

- 用户和系统的面向性：OLTP 是面向顾客的，用于办事员、客户和信息技术专业人员的事务和査询处理。OLAP 是面向市场的，用于知识工人（包括经理、主管和分析人员）的数据分析。
- 数据内容：OLTP 系统管理当前数据，通常，这种数据太琐碎，很难用于决策。OLAP 系统管理大量历史数据，提供汇总和聚集机制，并在不同的粒度层上存储和管理信息，这些特点使得数据更容易用于有根据的决策。
- 数据库设计：通常，OLTP 系统采用实体一关系（ER）数据模型和面向应用的数据库设计，而 OLAP 系统通常采用星形或雪花模型和面向主题的数据库设计。
- 视图：OLTP 系统主要关注一个企业或部门内部的当前数据，而不涉及历史数据或不同单位的数据，相比之下，由于单位的演变，OLAP 系统常常跨越数据库模式的多个版本。OLAP 系统还处理来自不同单位的信息，以及由多个数据库集成的信息。由于数据量巨大，OLAP 数据也存放在多个存储介质上。
- 访问模式：OLTP 系统的访问主要由短的原子事务组成，这种系统需要并发控制和恢复机制。然而，对 OLAP 系统的访问大部分是只读操作（由于大部分数据仓库存放历史数据，而不是最新数据），尽管许多可能是复杂的查询。

OLTP 和 OLAP 的其他区别包括数据库大小、操作的频繁程度、性能度量等，详见下表。

| 特征         | OLTP                        | OLAP                               |
| ------------ | --------------------------- | ---------------------------------- |
| 特性         | 操作处理                    | 信息处理                           |
| 面向         | 事务                        | 分析                               |
| 用户         | 办事员、DBA、数据库专业人员 | 知识工人（如经理、主管、分析人员） |
| 功能         | 日常操作                    | 长期信息需求、决策支持             |
| 数据库设计   | 原始的、高度详细            | 汇总的、统一的                     |
| 数据         | 当前的，保证最新            | 历史的，随时间推移保持准确性       |
| 视图         | 详细的、一般关系            | 汇总的、多维的                     |
| 工作单元     | 短的、简单事务              | 复杂查询                           |
| 访问         | 读/写                       | 大多为读                           |
| 关注         | 数据进人                    | 信息输出                           |
| 操作         | 主键上索引/散列             | 大量扫描                           |
| 访问记录数量 | 数十                        | 数百万                             |
| 用户数       | 数千                        | 数百                               |
| 数据库规模   | ﹤TB                        | ≧TB                                |
| 优先         | 高性能、高可用性            | 高灵活性、终端用户自治             |
| 度量         | 事务吞吐量                  | 查询吞吐量、响应时间               |

##### 1.3 数据仓库的基本概念

数据仓库中的基本概念及其关系如下图所示：

![data-warehouse-concepts](https://blog.jaggerwang.net/content/images/2021/09/data-warehouse-concepts.png)

- 业务板块：一个业务板块代表一条业务线，比如某集团公司下的电商业务和外卖业务，各自成为一个业务板块。
- 数据域：业务板块下可进一步划分数据领域，比如电商业务板块下包含交易域、仓储域等。
- 维度：维度建模由 Ralph Kimball 提出，主张从分析决策的需求出发构建模型，为分析需求服务。维度是度量的环境，是观察业务的角度，用来反映业务的一类属性。属性的集合构成维度，也可以称为实体对象。例如，在分析交易过程时，可以通过买家、卖家、商品和时间等维度描述交易发生的环境。
- 属性：维度的属性，是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键，比如买家的性别、职业等。
- 业务过程：业务过程是业务活动中不可拆分的事件，例如下单、支付和退款。
- 度量：在维度建模中，将度量称为事实，将环境描述为维度，维度是用于分析事实所需要的多样环境。度量通常为数值型数据，作为事实表的事实。
- 指标：指标分为原子指标和派生指标。原子指标是基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，是具有明确业务含义的名词，体现明确的业务统计口径和计算逻辑，例如支付金额。 
  - 原子指标=业务过程+度量。
  - 派生指标=时间周期+修饰词+原子指标，派生指标可以理解为对原子指标业务统计范围的圈定。
- 修饰词：统计的业务范围，筛选出符合业务规则的记录（类似于 SQL 中 where 后的条件，不包括时间区间）。
- 时间周期：统计的时间范围，例如最近一天，最近 30 天等（类似于 SQL 中 where 后的时间条件）。
- 统计粒度：统计分析的对象或视角，定义数据需要汇总的程度，可理解为聚合运算时的分组条件（类似于 SQL 中的 group by 的对象）。粒度是维度的一个组合，指明您的统计范围。

##### 1.4. 数据分层

数据仓库分层可以让数据结构更清晰，减少重复开发，并统一口径，一般来说自下而上分为三层：数据引入层（ODS，Operation Data Store）、数据公共层（CDM，Common Data Model）和数据应用层（ADS，Application Data Service）。

- 数据引入层（ODS）：存放未经过处理的原始数据至数据仓库，结构上与源系统保持一致，是数据仓库的数据准备区。主要完成基础数据引入到数据仓库的职责，同时记录基础数据的历史变化。
- 数据公共层（CDM）：包括维度层（DIM）、明细事实层（DWD）和汇总事实层（DWS），由 ODS 层数据加工得到。主要完成数据加工与整合，建立一致性的维度，构建可复用的面向分析和统计的明细事实表，以及汇总事实表。 
  - 维度层（DIM）：基于维度建模理念思想，建立整个企业的一致性维度，降低数据计算口径和算法不统一风险。维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应。
  - 明细事实层（DWD）：以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，即宽表化处理。明细事实层的表通常也被称为逻辑事实表，用于存放原子指标。
  - 汇总事实层（DWS）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总事实表，以宽表化手段物理化模型。构建命名规范、口径一致的统计指标，为上层提供公共指标。汇总事实层的表通常也被称为汇总逻辑表，用于存放派生指标。
- 数据应用层（ADS）：存放数据产品个性化的统计指标，根据 CDM 和 ODS 层的数据加工得到。

各层之间的数据流向如下图所示。其中，DIM 层一般会同步到所有存储系统，ODS 层和 DWD 层通常会放在数据中间件中，供下游订阅使用，而 DWS 层和 ADS 层的数据往往会落地到在线存储系统中，下游通过接口调用来获取。

![data-warehouse-layers](http://47.98.208.51:10086/media/202207/2022-07-22_172835_7950200.39387867694308243.png)

#### 2. 数仓架构

##### 2.1数仓架构的发展

数据仓库有两个环节：数据仓库的构建与数据仓库的应用。

早期数据仓库构建主要指的是把企业的业务数据库如 ERP、CRM、SCM 等数据按照决策分析的要求建模并汇总到数据仓库引擎中，其应用以报表为主，目的是支持管理层和业务人员决策（中长期策略型决策）。

随着IT技术走向互联网、移动化，数据源变得越来越丰富，在原来业务数据库的基础上出现了非结构化数据，比如网站 log，IoT 设备数据，APP 埋点数据等，这些数据量比以往结构化的数据大了几个量级，对 ETL 过程、存储都提出了更高的要求。

![实时数仓,什么是数据仓库,大数据数据仓库架构图,数据仓库的应用案例,数据仓库建设](https://www.fanruan.com/bw/wp-content/uploads/2020/06/%E5%AE%9E%E6%97%B6%E6%95%B0%E4%BB%932.jpeg)

总结来看，对数据仓库的需求可以抽象成两方面：实时产生结果、处理和保存大量异构数据。

##### 2.2 数据仓库架构的演变

数仓架构经历了最初的传统数仓架构——离线数仓库——离线大数据架构、Lambda 架构、Kappa 架构以及 Flink 的火热带出的流批一体架构，数据架构技术不断演进，本质是在往流批一体的方向发展，让用户能以最自然、最小的成本完成实时计算。

###### 2.2.1 离线数仓

- **离线数仓部署架构**
![](/media/202207/2022-07-25_222655_2526720.05527180480808935.png)

###### 2.2.1.1 传统数仓

![实时数仓,什么是数据仓库,大数据数据仓库架构图,数据仓库的应用案例,数据仓库建设](https://www.fanruan.com/bw/wp-content/uploads/2020/06/%E5%AE%9E%E6%97%B6%E6%95%B0%E4%BB%933.jpg)

离线数仓+计算引擎，通常是使用大型商业数据库来承担，例如Oracle、DB2、Teradata等。

###### 2.2.1.2 离线数仓—大数据架构

随着数据规模的不断增大，传统数仓方式难以承载海量数据。随着大数据技术的普及，采用大数据技术来承载存储与计算任务。当然，也可以使用传传统数据库集群或MPP架构数据库来完成。例如Hadoop+Hive/Spark、Oracle RAC、GreenPlum等。

![hadoop-data-warehouse](https://blog.jaggerwang.net/content/images/2021/09/hadoop-data-warehouse.png)

Hive 数仓与传统数仓的对比如下：

|          | Hive 数仓                                                    | 传统数仓                                                     |
| -------- | ------------------------------------------------------------ | ------------------------------------------------------------ |
| 存储     | HDFS，理论上可无限扩展                                       | 集群存储，存在容量上限。只能适应于数据量比较小的商业应用，对于超大规模、半结构和非结构化数据无能为力 |
| 执行引擎 | 有 MR/Tez/Spark 多种引擎可供选择                             | 可以选择更加高效的算法来执行查询，也可以进行更多的优化措施来提高速度 |
| 使用方式 | HQL（类似 SQL）                                              | SQL                                                          |
| 灵活性   | 元数据存储独立于数据存储之外，从而解耦元数据和数据           | 低，数据用途单一                                             |
| 分析速度 | 计算依赖于集群规模，易扩展，在大数据量情况下，远快于普通数据仓库，但复杂的关联交叉运算其速度很慢，宽表用 Hive 做比较低效 | 复杂查询性能高于 Hive，简单大规模查询性能较 Hive 弱          |
| 索引     | 低效，目前还不完善                                           | 高效                                                         |
| 易用性   | 需要自行开发应用模型，灵活度较高，但易用性低                 | 集成一整套成熟的的报表解决方案，可以较为方便的进行数据分析   |
| 可靠性   | 数据存储在 HDFS，可靠性高，容错性高                          | 可靠性较低，一次查询失败需要重新开始。数据容错大部分依赖于硬件 Raid，软件角度不同产品差异较大 |
| 依赖环境 | 依赖硬件较低，可适应一般的普通机器                           | 依赖于高性能的商业服务器，对 X86 服务器的配置统一性要求较高  |
| 价格     | 开源产品                                                     | 商用比较昂贵                                                 |

###### 2.2.2 实时数仓
- **实时数仓部署架构**
![](/media/202207/2022-07-25_222750_2333670.9830286206875176.png)

-  **Flink 部署 K8S 方案:**
![](/media/202207/2022-07-26_221426_5809710.32843280705989075.png)

前面讨论的传统数仓和大数据数仓，都是通过定时任务按批处理数据，批处理任务调度周期一般为天（快的话可以做到小时级别），有比较大的延时，他们可以统称为离线数仓。在某些业务场景，比如监控报警、大屏显示，延时需要控制在分钟级甚至秒级，这种时候就需要实时数仓了。

实时数仓有两种典型架构，分别是 Lambda 和 Kappa。

###### 2.2.2.1 Lambda 架构

![data-warehouse-lambda](https://blog.jaggerwang.net/content/images/2021/09/data-warehouse-lambda.png)

Lambda 架构在大数据数仓批处理层的基础上，增加了一个流处理层（也称为速度层）。批处理层处理今天之前的历史数据，延时以天计，但准确性高，计算逻辑和出错处理都比较简单，而流处理层处理当天实时数据，延时为分钟级或秒级，但容易出错，计算逻辑也比较复杂。注意，流处理层处理的当天数据，会在第二天被批处理层重新处理，这样即便流处理层计算有误，也会在批处理层被修正。

Lambda 架构兼顾了离线批处理和在线实时处理两种方式，适合以批处理为主，实时处理为辅的业务场景。这种架构的弊端在于，需要同时实现批处理和流处理两种方式，容易出现两边计算逻辑不一致，并且通常批处理和流处理使用的技术工具不同，在人员和技术上无法实现统一，造成冗余和浪费。

具体来说，Lambda 架构的痛点有：

1. 同时维护实时和离线两套引擎，运维成本高
2. 实时和离线两种处理需要维护两套框架不同但业务逻辑相同的代码，开发成本高
3. 数据有两条不同链路，容易造成数据的不一致性
4. 数据更新成本大，需要重跑链路

###### 2.2.2.2 Kappa 架构

![data-warehouse-kappa](https://blog.jaggerwang.net/content/images/2021/09/data-warehouse-kappa.png)

Kappa 架构完全废弃了批处理层，即便是批处理也是通过消息队列回溯以流计算的方式来完成，这样就实现了批流一体，从而避免了冗余工作，并简化了技术栈。

但 Kappa 架构并非就是完美的，在实际落地时其痛点有：

1. 对消息队列的存储性能和稳定性要求高，消息队列的回溯能力不及离线存储
2. 消息队列中的数据有存储时效性，且当前无法使用 OLAP 引擎直接分析消息队列中的数据
3. 全链路依赖消息队列的实时计算，可能会因为数据的时序性导致结果不正确

Lambda 架构与 Kappa 架构的对比：

![实时数仓,什么是数据仓库,大数据数据仓库架构图,数据仓库的应用案例,数据仓库建设](https://www.fanruan.com/bw/wp-content/uploads/2020/06/%E5%AE%9E%E6%97%B6%E6%95%B0%E4%BB%9311.jpeg)

###### 2.2.3 混合架构

上述架构各有其适应场景，有时需要综合使用上述架构组合满足实际需求。当然这也必将带来架构的复杂度。用户应根据自身需求，有所取舍。在一般大多数场景下，是可以使用单一架构解决问题。现在很多产品在流批一体、海量、实时性方面也有非常好的表现，可以考虑这种“全能手”解决问题。

![实时数仓,什么是数据仓库,大数据数据仓库架构图,数据仓库的应用案例,数据仓库建设](https://www.fanruan.com/bw/wp-content/uploads/2020/06/%E5%AE%9E%E6%97%B6%E6%95%B0%E4%BB%936.jpg)

###### 2.2.4 数据湖

前面我们看到 Kappa 架构的痛点主要是因其使用的消息队列（比如 Kafka）在存储功能上的一些限制导致，那么是否存在一种存储技术，能够同时支持高效的数据回溯，数据更新，以及数据批流读写了？答案是数据湖。

###### 2.2.3.1 什么是数据湖

数据湖是一类存储数据自然/原始格式的系统或存储，通常是对象块或者文件。数据湖通常是企业中全量数据的单一存储。全量数据包括原始系统所产生的原始数据拷贝，以及为了各类任务而产生的转换数据，包括报表、可视化、高级分析和机器学习等。数据湖中包括结构化数据（通常来自于关系型数据库）、半结构化数据（CSV、日志、XML、JSON 等）、非结构化数据（Email、文档、PDF 等）和二进制数据（图像、音频、视频等）。

![data-lake-capability](https://blog.jaggerwang.net/content/images/2021/09/data-lake-capability.png)

目前市面上有三大开源的数据湖方案，分别是 Delta Lake（Databricks 开源）、Apache Hudi（Uber 开源）和 Apache Iceberg（Netflix 开源）。其中 Iceberg 以自身独特的优势被越来越多开发者关注，其特点如下：

1. Iceberg 的架构和实现没有绑定到某一特定引擎，实现了通用的数据组织格式，利用此格式可以与不同引擎（Flink、Hive、Spark 等）对接。
2. Iceberg 拥有良好的架构和开放格式。相比于 Hudi、Delta Lake，Iceberg 的架构实现更为优雅，同时对于数据格式、类型系统有完备的定义和可进化的设计。
3. Iceberg 在数据组织方式上充分考虑了对象存储的特性，避免耗时的 listing 和 rename 操作，使其在基于对象存储的数据湖架构适配上更有优势。

###### 2.2.3.2 什么是湖仓一体

![data-lake-warehouse-union](https://blog.jaggerwang.net/content/images/2021/09/data-lake-warehouse-union.png)

1. 湖和仓的数据/元数据无缝打通，互相补充，数据仓库的模型反哺到数据湖，湖的结构化数据沉淀到数据仓库
2. 湖和仓有统一的开发体验，存储在不同系统的数据，可以通过一个统一的开发/管理平台操作
3. 数据湖与数据仓库的数据，系统可以根据规则自动决定哪些数据放在数仓，哪些保留在数据湖，进而形成一体化

#### 3. 数仓实施

数仓模型设计到实施构建上线的整体流程涉及数据调研、模型设计、模型构建、测试验收、发布应用 五个主要环节，对每个阶段的输出与输入文档进行规范。

![数仓实施流程](http://doc.mypaas.com.cn/bigdata/assets/datawarehouse-process-1.jpg)

##### 数据调研

对集团业务体系和数据进行盘点，了解核心业务的数据现状。收集和理解业务方需求，就特定需求的指标口径达成统一，在对需求中涉及到的业务系统或系统模块所承担的功能进行梳理后进行表字段级分析，并对数据进行验证，确保现有数据能够支持业务需求。

##### 模型设计

根据需求和业务调研结果对模型进行初步归类，选择合适的主题域进行模型存放；确定主题后进入数据模型的设计阶段，逻辑模型设计过程要考虑总线结构构建、模型规范定义等关键问题。

##### 模型构建

物理模型设计以逻辑模型为基础，兼顾存储性能等因素对逻辑模型做的物理化的过程，是逻辑模型的最终物理实现.物理模型在一般情况下与逻辑模型保持一致，模型设计完成后需要输出表结构进行需求匹配的验证。 逻辑模型物理化的过程，既可以通过产品平台的模型构建自动生成运行代码和脚本，也可以通过业务流程节点自定义代码开发的形式完成。其中包含了数据映射、计算实现、测试验证等开发过程。

##### 测试验收

单元测试完成后需要通知业务方一起对模型数据进行业务验证，对验证问题做收集，返回验证模型设计的合理性。

##### 发布应用

完成验证后的模型就可以在线上生产环境进行部署，一方面通过数据源的方式接入到数据分析平台进行自助查询和可视化分析，另一方面可以配置API接口服务，提供给业务系统调用。上线后需要为模型配置监控，及时掌握为业务提供数据服务的状况。模型实体和属性说明文档可以发布给数仓数据的使用者，使模型得到更好地应用。

#### 4.关键技术和工具的系统理解

##### 4.1 **数据编排技术**

###### 4.1.1 **Alluxio**

![Ecosystem](https://camo.githubusercontent.com/0ecbdce04c6aa975b5dede469bb0335eab3ad54f7e33078e5b6aec47ce1e355c/68747470733a2f2f6433396b7161743177706e316f352e636c6f756466726f6e742e6e65742f6170702f75706c6f6164732f323032312f30372f616c6c7578696f2d6f766572766965772d723037313532312e706e67)

- **内存速度 I/O**：Alluxio 能够用作分布式共享缓存服务，这样与 Alluxio 通信的计算应用程序可以透明地缓存频繁访问的数据（尤其是从远程位置），以提供内存级 I/O 吞吐率。此外，Alluxio的层次化存储机制能够充分利用内存、固态硬盘或者磁盘，降低具有弹性扩张特性的数据驱动型应用的成本开销。
- **简化云存储和对象存储接入**：与传统文件系统相比，云存储系统和对象存储系统使用不同的语义，这些语义对性能的影响也不同于传统文件系统。在云存储和对象存储系统上进行常见的文件系统操作（如列出目录和重命名）通常会导致显著的性能开销。当访问云存储中的数据时，应用程序没有节点级数据本地性或跨应用程序缓存。`将 Alluxio 与云存储或对象存储一起部署`可以缓解这些问题，因为这样将从 Alluxio 中检索读取数据，而不是从底层云存储或对象存储中检索读取。
- **简化数据管理**：Alluxio 提供对多数据源的单点访问。除了连接不同类型的数据源之外，Alluxio 还允许用户同时连接同一存储系统的不同版本，如多个版本的 HDFS，并且无需复杂的系统配置和管理。
- **应用程序部署简易**：Alluxio 管理应用程序和文件或对象存储之间的通信，将应用程序的数据访问请求转换为底层存储接口的请求。Alluxio 与 Hadoop 生态系统兼容，现有的数据分析应用程序，如 Spark 和 MapReduce 程序，无需更改任何代码就能在 Alluxio 上运行。

##### 4.2 DataLake（数据湖）

###### 4.2.1 hudi

- Hudi通过hadoop提供流式处理能力 
  - Update/Delete操作记录
  - change流能力

支持的能力

- 支持ACID 
- 快速Upsert能力 
- Schema Evolution 
- 多种视图读取接口 
- 多版本

###### 4.2.2 iceBerg

- Apache Iceberg是用于大型分析数据集的开放表格式。 Iceberg在Trino和Spark中添加了使用高性能格式的表，该格式的工作方式类似于SQL表。

用户特性:

- schem演进支持添加、删除、更新或重命名，并且没有副作用
- 隐藏分区可以防止导致错误提示或错误查询的用户错误
- 分区布局演变可以随着数据量或查询模式的变化而更新表的布局
- 时间旅行可实现使用完全相同的表快照的可重复查询，或者使用户轻松检查更改
- 版本回滚使用户可以通过将表重置为良好状态来快速纠正问题

可靠性和性能:

- 对于生产环境来说iceberg单表可以支撑数10PB级别的数据，这些数据甚至可以在没有分布式SQL引擎的情况下读取。
- Iceberg是为了解决最终一致的云对象存储中的正确性问题而设计的

###### 4.3 KVStore

**K-V结构存储,如Hbase、RocksDb(内嵌KV存储)等**

###### 4.3.1 rocksDB

- RocksDB是基于key/value的存储引擎，其中键和值是任意字节流。它是在Facebook上基于LevelDB开发的，并为LevelDB api提供向后兼容支持。它支持点查找和范围扫描，并提供不同类型的ACID保证。
- RocksDB有三种基本的数据结构：mentable，sstfile以及logfile。mentable是一种内存数据结构——所有写入请求都会进入mentable，然后选择性进入logfile。logfile是一种有序写存储结构。当mentable被填满的时候，他会被刷到sstfile文件并存储起来，然后相关的logfile会在之后被安全地删除。sstfile内的数据都是排序好的，以便于根据key快速搜索。

[![img](https://github.com/collabH/bigdata-growth/raw/master/bigdata/kvstore/rocksdb/img/Rocksdb%E7%BB%93%E6%9E%84.png)](https://github.com/collabH/bigdata-growth/blob/master/bigdata/kvstore/rocksdb/img/Rocksdb%E7%BB%93%E6%9E%84.png)

###### 4.3.2 HBase

- Hbase是一个在HDFS上开发的面向列的分布式、可扩展支持海量数据存储的NoSQL数据库，如果需要实时访问超大规模数据集可以使用。
- 自底向上地进行构建，能够简单地通过增加节点来达到线性扩展。

###### 4.4 Hadoop

###### 4.4.1 HDFS

###### 4.4.2 MapReduce

###### 4.4.3 Yarn

##### 4.5 Engine

**计算引擎相关，主要包含Flink、Spark等**

###### 4.5.1 Flink

- Apache Flink 是一个分布式大数据处理引擎，可对有限数据流和无限数据流进行有状态或无状态的计算，能够部署在各种集群环境，对各种规模大小的数据进行快速计算。
- 有状态的计算，状态容错性依赖于checkpoint机制做状态持久化存储。
- 多层API(Table/SQL API、DataStream/DataSet API、ProcessFunction API)
- exactly-once语义，状态一致性保证
- 低延迟，每秒处理数百万个事件，毫秒级别延迟。

###### 4.5.2 Spark

##### 4.6 Collect

**数据采集框架，主要包含Binlog增量与SQL快照方式框架**

###### 4.6.1 Canal

###### 4.6.2 Debezium

###### 4.6.3 Flume

###### 4.6.4 Sqoop

##### 4.7 MQ

**消息中间件相关，主要包含大数据中使用比较多的Kafka和Pulsar**

###### 4.7.1 Kafka

###### 4.7.2 Pulsar

###### 4.7.3 Zookeeper

##### 4.8 Schedule

###### 4.8.1 Azkaban

###### 4.8.2 DolphinScheduler

##### 4.9 OLAP

**主要核心包含Kudu、Impala相关Olap引擎，生产实践及论文记录等。**

###### 4.9.1 Hive

###### 4.9.2 Presto

###### 4.9.3 clickhouse

###### 4.9.4 Druid

###### 4.9.5 Kylin

###### 4.9.6 Kudu

##### 4.10 Graph

**图库相关**

###### 4.10.1 nebula graph

##### 4.11 Tools

**工具集相关，包含计算平台、sql语法Tree等**

###### 4.11.1 zeppelin

###### 4.11.2 calcite

#### 5. 其他

##### 5.1 数据平台设计  http://kmgy.top/doc/162/
##### 5.2 数仓常用平台  http://kmgy.top/doc/302/