读数据湖仓04数据架构与数据工程

1. 大容量存储器

1.1. 几乎是到最后时刻，大容量存储器才被引入基础数据的基础设施中

• 1.1.1. 分析人员通常不会直接在大容量存储器中进行数据分析

• 1.1.2. 大容量存储器在基础数据中扮演的角色也特别重要，它能够在许多方面支持数据分析人员自由灵活地完成工作，也为数据湖仓的高效使用奠定了基础

1.2. 大容量存储器可以利用大量廉价的存储介质存储数据

1.3. 尽管大容量存储器的访问速度不够快，效率也不够高，但大容量存储器可以持久保存数据，而且还可以通过应用程序直接访问

1.4. 大容量存储器在许多方面与棒球比赛中的替补投手角色类似，尽管大容量存储器在系统架构中可能不会起到突出作用，但也是绝对必要的

1.5. 优势

• 1.5.1. 由于数据是以数字化形式存储的，因此用户仍然可以随时访问数据，并且能够长期存储

• 1.5.2. 在大多数情况下不会随着时间的推移而产生数据异常问题

• 1.5.3. 大容量存储器的真正优势在于价格便宜

  • 1.5.3.1. 采用大容量存储器方案的用户则可以承担几乎无限量的数据存储

  • 1.5.3.2. 大容量存储器能够有效降低整个组织的存储成本

1.6. 缺点

• 1.6.1. 通常无法直接访问数据

  • 1.6.1.1. 在大容量存储器中检索数据时，我们需要按顺序访问

• 1.6.2. 当需要在大容量存储器中检索数据时，通常需要开发大量自定义应用程序，这严重限制了对大容量存储器的使用

  • 1.6.2.1. 不应该使用大容量存储器来支持OLTP

1.7. 大容量存储器适合存储访问概率较低的数据

1.8. 许多类型的数据都属于低访问概率的范畴

• 1.8.1. 法律要求组织长期存储相关数据，即使这些数据被访问的可能性很低

• 1.8.2. 在其他情况下，数据只是随着时间的推移而变得陈旧和过时

1.9. 大容量存储器也是存储大多数机器生成数据的理想选择，这些数据很可能不会被频繁访问或以其他方式用于分析，因为当机器正常运行并生成正常结果时，所生成的测量数据并不重要

1.10. 尽管大容量存储器并非基础数据的核心关注点，但它仍然是基础数据重要和必要的组成部分

• 1.10.1. 大容量存储器是高性能存储器的基础和补充

2. 访问概率

2.1. 将访问概率较低的数据存储在大容量存储器中，这样，当系统需要检索访问概率较高的数据时，就无需检索大容量存储器中的数据，从而提高工作效率

2.2. 在实际场景中，当需要处理大量数据时，访问概率较高的数据可能会“隐藏”在其他数据之后

2.3. 在低访问概率的数据丛林中，确保高访问概率的数据不被埋没则非常重要

2.4. 提供高访问概率的可用数据可以简化分析人员的操作，加快检索速度，降低数据检索的处理成本

2.5. 通过区分数据访问概率的高低，可以实现更高的收益

• 2.5.1. 需要确定哪些数据被访问的概率高，哪些数据被访问的概率低

2.6. 使用词语并非确定访问概率的唯一标准，更常见的方法是通过数据的年龄(Age of Data)来衡量

• 2.6.1. 随着时间的推移，数据被访问的概率会逐渐降低，不同数据降低的速度可能不同

• 2.6.2. 所有数据的访问概率都会降低，当访问概率降低时，就应该考虑采用大容量存储器进行归档

3. 索引

3.1. 索引的作用是更高效地访问数据，如果我们对数据的访问概率有较高的预期，则可以为对应数据生成索引

3.2. 尽管大容量存储器中数据的访问概率较低，但仍然存在被访问的可能性

• 3.2.1. 需要为大容量存储器中的数据创建索引，这都是为了“以防万一”

• 3.2.2. 这种类型的索引通常可以创建在有空闲的机器上

• 3.2.3. 如果需要检索大容量存储器中的数据，创建索引能够节省大量时间

3.3. 当需要检索大量数据时，检索过程必须快速完成，而直接在大容量存储器中进行检索则无法满足这个需求，因为这种方式是无法快速完成的

• 3.3.1. 在这种情况下，使用索引则可能解决这个问题

4. 元数据

4.1. 大容量存储器的另一个重要特点是对元数据的需求

4.2. 虽然大容量存储器中数据的访问概率不高，但并不意味着大容量存储器不需要元数据

4.3. 如果我们在没有元数据的情况下将数据转存到大容量存储器中，那么将很难再次找到并使用这些数据

4.4. 元数据描述对于大容量存储器和高性能存储器同样必不可少

5. 数据架构与数据工程

5.1. 数据架构与数据工程就像是技术领域的阴阳两面

5.2. 没有数据架构的数据工程就像没有舵的船

• 5.2.1. 没有数据架构的数据工程毫无意义

5.3. 架构师与工程师会共同构建复杂的信息系统

• 5.3.1. 架构师注重考虑长期因素

• 5.3.2. 工程师则更关注战术性的问题

5.4. 数据架构师与数据工程师之间同样也是合作互补的关系，他们能够融合彼此的技能和视角，共同创建一个现代化的信息系统环境

5.5. 数据架构师和数据工程师共同合作创建了数据基础——数据湖仓

• 5.5.1. 创建一个成功的信息系统环境

• 5.5.2. 将自己的工作建立在另一角色所创造的基础之上

6. 数据架构师和数据工程师共同兴趣点

6.1. 结构化数据只是数据架构师与数据工程师的第一个共同兴趣点

• 6.1.1. 数据架构师着眼于项目的大局和长期视野

  • 6.1.1.1. 是在最高级别的模型中定义的

  • 6.1.1.2. 在需要转换时可以进行转换

  • 6.1.1.3. 具有完整的数据血缘

  • 6.1.1.4. 被正确归档

  • 6.1.1.5. 被设计用于容纳大量数据

• 6.1.2. 数据工程师要关注项目的具体细节，包括代码、数据库以及操作系统等方面的实现细节

  • 6.1.2.1. 数据的标准化

  • 6.1.2.2. 汇总和派生数据

  • 6.1.2.3. 选择正确的数据源

  • 6.1.2.4. 明确定义的转换

6.2. 第二个共同兴趣点是文本数据

• 6.2.1. 数据架构师与数据工程师在本体、分类标准、情感分析、相关性分析、语言、多义词和缩略语等方面有共同的兴趣点

• 6.2.2. 数据架构师对本体的完整性、大容量存储器的使用以及将数据转换为基础数据等方面感兴趣

  • 6.2.2.1. 本体的来源

  • 6.2.2.2. 分类标准的相互关系

  • 6.2.2.3. 分类标准的重叠部分

  • 6.2.2.4. 分类标准的层次级别

  • 6.2.2.5. 分类标准的维护

• 6.2.3. 数据工程师对将文本转换为数据库的ETL、将要使用的数据库、数据从大容量存储器到高性能存储器的流动等方面感兴趣

  • 6.2.3.1. 分类标准的新鲜度

  • 6.2.3.2. 本体与组织实体之间的关系

  • 6.2.3.3. 分类标准的完整性

  • 6.2.3.4. 分类标准的具体程度

6.3. 第三个共同兴趣点是组织中的模拟/物联网数据

• 6.3.1. 都对用于数据蒸馏的算法、模拟/物联网环境中不同类型数据的数据结构和组成部分、大容量存储器管理等方面感兴趣

• 6.3.2. 数据架构师关注的方面包括即将面对的数据量、用于蒸馏的算法、存储在高性能存储器中的数据内容和结构等

  • 6.3.2.1. 模拟/物联网数据创建的速率

  • 6.3.2.2. 模拟/物联网数据的粒度级别

  • 6.3.2.3. 模拟/物联网数据满足的业务需求

  • 6.3.2.4. 蒸馏算法的效率

• 6.3.3. 数据工程师关注蒸馏算法的实际编码、将数据加载到大容量存储器和高性能存储器的过程、将高性能存储器提供给终端用户使用等方面

  • 6.3.3.1. 对蒸馏后的数据进行维护的能力

  • 6.3.3.2. 蒸馏算法的精度

  • 6.3.3.3. 蒸馏后的数据所经历的分析处理过程

  • 6.3.3.4. 偶尔需要重新定义蒸馏的参数

6.4. 第四个共同兴趣点是跨不同数据类型跟踪和移动数据的能力

• 6.4.1. 尽管并非所有数据都可以被用于跨数据类型的应用，但如果数据能够在不同数据类型之间流动，就存在巨大的可能性

6.5. 第五个共同兴趣点是数据血缘

• 6.5.1. 数据在组织内通常是流动的

• 6.5.2. 当我们移动数据时，就会发生数据转换，而且一些数据会被反复移动

• 6.5.3. 在整个组织的数据流中，我们需要考虑进行数据转换的算法和选择用于转换的数据

  • 6.5.3.1. 当数据从一种数据类型转换为另一种数据类型时，就会引发许多问题，这也是数据架构师与数据工程师都非常关心的问题