读数据工程之道：设计和构建健壮的数据系统09示例和范例 ...

1. 数据架构不是凭空设计的

1.1. 数据架构是一门抽象学科，所以它有助于通过示例进行推理
2. 数据仓库

2.1. 一个面向主题的、集成的、非易失性和时变的数据集合，以支持管理决策
2.2. 数据仓库是用于报告和分析的中央数据中心

• 2.2.1. 数据仓库中的数据通常针对分析用例进行了高度格式化和结构化
  
• 2.2.2. 是最古老和最美满的数据架构之一
  

2.3. 构造型

• 2.3.1. 构造型数据仓库架构构造与某些业务团队结构和流程相关的数据
  
• 2.3.2. 将联机分析处置惩罚(OLAP)与生产数据库（联机事件处置惩罚，Online Transaction Processing，OLTP）分离
  
• 2.3.3. 将数据移动到一个单独的物理系统中，可以将负载从生产系统转移出去，并进步分析性能
  
• 2.3.4. 传统上，数据仓库通过利用ETL从应用程序系统中获取数据
  
• 2.3.4.1. 提取阶段从源系统中获取数据
  

2.4. 技术型

• 2.4.1. 技术型数据仓库架构反映了数据仓库的技术性质
  
• 2.4.2. ETL的一种变体是ELT
  
• 2.4.3. 转换不是利用外部系统，而是直接在数据仓库中处置惩罚
  
• 2.4.4. 目的是利用云数据仓库和数据处置惩罚工具的巨大计算能力
  

2.5. 云数据仓库

• 2.5.1. 云数据仓库代表了本地数据仓库架构的重大演变，因此导致了构造架构的重大变化
  
• 2.5.2. 云数据仓库扩展了MPP系统的功能，以涵盖最近需要Hadoop集群的许多大数据用例
  
• 2.5.3. 通常支持允许每行存储数十兆字节原始文本数据或极其丰富和复杂的JSON文档的数据结构
  
• 2.5.4. 随着云数据仓库（和数据湖）的成熟，数据仓库和数据湖之间的界限将继续模糊
  

2.6. 数据仓库提供了开箱即用的基本数据管理功能，而SQL是编写复杂、高性能查询和转换的有效工
3. 数据集市

3.1. 数据集市是仓库的一个更精细的子集，旨在为分析和报告提供服务，专注于一个单一的子构造、部门或业务线
3.2. 数据集市使分析师和报告开发职员更容易访问数据
3.3. 数据集市在初始ETL或ELT管道提供的转换阶段之外提供了一个额外的转换阶段
4. 数据湖

4.1. 大数据期间出现的最流行的架构之一是数据湖
4.2. 数据湖有望成为一股民主化的力量，解放企业，让它们从无穷数据的源泉中畅饮
4.3. 数据湖1.0始于HDFS

• 4.3.1. 随着云越来越受欢迎，这些数据湖转移到基于云的对象存储，存储本钱极其低廉，存储容量险些是无穷的
  
• 4.3.2. 数据湖不依赖于存储和计算紧耦合的单一数据仓库，它允许存储任何巨细和范例的大量数据
  
• 4.3.3. 当需要查询或转换这些数据时，你可以通过按需启动集群来得到险些无穷的计算能力，并且你可以为手头的任务选择你最喜好的数据处置惩罚技术
  
• 4.3.3.1. MapReduce
  
• 4.3.3.2. Spark
  
• 4.3.3.3. Ray
  
• 4.3.3.4. Presto
  
• 4.3.3.5. Hive
  
• 4.3.4. 数据湖成了垃圾场
  
• 4.3.4.1. 数据沼泽、暗数据和WORN等术语是在曾经有希望的数据项目失败时创造出来的
  
• 4.3.5. 廉价的现成硬件将代替定制的供应商解决方案
  
• 4.3.5.1. 由于管理Hadoop集群的复杂性迫使公司以高薪聘请大量的工程师团队，因此大数据本钱激增
  
• 4.3.5.2. 公司通常选择从供应商处购买允许的、定制的Hadoop版本，以制止原始Apache代码库的裸线和锋利边缘，并得到一套脚手架工具，使Hadoop更加用户友爱
  
• 4.3.5.3. 纵然是制止利用云存储管理Hadoop集群的公司也不得不泯灭大量人才来编写MapReduce作业
  

4.4. 公司拥有足够的资源来构建成功的数据实践，并创建基于Hadoop的自界说工具和增强功能

• 4.4.1. 对于许多构造而言，数据湖变成了浪费、令人扫兴和本钱不断上升的内部超等垃圾场合
  

5. 数据湖仓一体

5.1. 数据湖仓一体一词暗示了数据湖和数据仓库之间的融合
5.2. 云数据仓库将计算与存储分开，支持PB级的查询，存储各种非结构化数据和半结构化对象，并与先进的处置惩罚技术（如Spark或Beam）集成
5.3. AWS、Azure、Google Cloud、Snowflake和Databricks是一流的领导者，每家都提供了一系列紧密集成的工具来处置惩罚数据，从关系型到完全非结构化
5.4. 未来的数据工程师可以根据各种因素，包括供应商、生态系统和相对开放性，选择一个融合的数据平台，而不是在数据湖或数据仓库架构之间进行选择
6. 现代数据栈

6.1. 现代数据栈是目前流行的分析架构，突出了我们希望在未来几年内看到更广泛利用的抽象范例
6.2. 现代数据栈的重要结果是自助服务（分析和管道）​、敏捷数据管理以及利用开源工具或具有明白定价结构的简单专有工具
6.3. 现代数据栈现在是并将继续是数据架构的默认选择
7. Lambda架构

7.1. 在Lambda架构中​，你的系统彼此独立运行——批处置惩罚、流处置惩罚和服务
7.2. 流处置惩罚

• 7.2.1. 流处置惩罚的目的是在“速度”层（通常是NoSQL数据库）中以尽可能低的延迟为数据提供服务
  

7.3. 批处置惩罚

• 7.3.1. 在批处置惩罚层，数据在数据仓库等系统中进行处置惩罚和转换，创建数据的预计算和聚合的数据视图
  

7.4. 服务层通过聚合来自两个层的查询结果来提供组合视图
8. Kappa架构

8.1. 通过直接读取实时事件流并重放大块数据以进行批处置惩罚，可以将实时和批处置惩罚无缝地应用于相同的数据
9. Dataflow模型

9.1. Dataflow模型的核心头脑是将所有数据视为事件，由于聚合是在各种范例的窗口上实行的
9.2. 持续的实时事件流是无边界的数据
9.3. 数据批次只是有界事件流，边界提供了一个自然窗口
9.4. “批处置惩罚作为流处置惩罚的特例”的理念现在更加普遍
10. 物联网架构

10.1. 物联网是装备的分布式集合，又称为事物——计算机、传感器、移动装备、智能家居装备以及任何其他具有互联网毗连的装备
10.2. 由定期或连续从四周情况收集数据并将其传输到目的地的装备生成
10.3. 物联网装备通常是低功耗的，并且在低资源/低带宽情况中运行
10.4. 物联网已经从未来主义的理想演变为海量数据工程领域
10.5. 装备

• 10.5.1. 装备（也称为事物）是毗连到互联网的物理硬件，可以感知四周的情况、收集数据并将其传输到下游目的地
  
• 10.5.2. 装备应该至少能够收集和传输数据
  

10.6. 物联网网关

• 10.6.1. 物联网网关是毗连装备并将装备安全路由到互联网上适当目的地的枢纽
  
• 10.6.2. 固然你可以在没有物联网网关的情况下将装备直接毗连到互联网，但网关允许装备利用极少的功率进行毗连
  
• 10.6.3. 充当数据保存的中转站，并管理与最终数据目的地的互联网毗连
  
• 10.6.4. 新的低功耗WiFi标准旨在降低物联网网关在未来的重要性
  

10.7. 存储

• 10.7.1. 存储要求在很大程度上取决于系统中物联网装备的延迟要求
  

10.8. 服务

• 10.8.1. 服务模式非常多样化
  
• 10.8.2. IoT的一种重要服务模式雷同于反向ETL
  

11. 数据网格

11.1. 数据网格是最近对庞大的单一数据平台（例如集中式数据湖和数据仓库）以及“数据大分水岭”的回应，其中数据分为运营数据和分析数据
11.2. 数据网格试图反转集中式数据架构的挑战，采用领域驱动设计的概念（通常用于软件架构）并将其应用于数据架构
11.3. 关键构成部门

• 11.3.1. 面向领域的分散式数据所有权和架构
  
• 11.3.2. 数据作为产品
  
• 11.3.3. 自助式数据基础架构作为平台
  
• 11.3.4. 团结计算治理
  

12. 其他数据架构

12.1. 数据中心
12.2. 缩放架构
12.3. 元数据优先架构
12.4. 事件驱动架构
12.5. 实时数据栈

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。