读数据湖仓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. 当数据从一种数据类型转换为另一种数据类型时,就会引发许多问题,这也是数据架构师与数据工程师都非常关心的问题