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. 实时数据栈
