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