读数据质量管理：数据可靠性与数据质量问题解决之道02数据湖仓

1. 组装

1.1. 对于任何数据从业者来说，解决生产过程中的数据质量问题都是一项关键技能，但只要有适当的系统和流程，就基本可以防止数据宕机

1.2. 数据在管道的任何阶段都可能会受到操作数量、编程甚至数据相关性的影响，也许只需一次模式更改或代码推送，就会让下游报告处于混乱状

1.3. 元数据驱动的构建模块，以便在管道的每个阶段都确保高质量的数据，并保证成功建立数据基础设施

2. 差异

2.1. 事务型与分析型是在生态系统中对数据进行分类的方法

2.2. 管理事务型数据的质量和可靠性通常属于开发运营(DevOps)的领域

2.3. 站点可靠性工程和其他软件学科更关注由分析型数据构建的软件产品

2.4. 事务型数据

• 2.4.1. 在运营过程中产生的数据，即组织日常持续运营过程中所产生的数据

• 2.4.2. 某一时刻的库存快照、客户曝光次数和交易记录都是事务型数据的示例

• 2.4.3. 事务型数据记录了来自实际业务流程中的数据，以便快速更新系统和流程

• 2.4.4. 事务型数据在运行业务

• 2.4.5. 在数据管道中，事务型数据几乎总是出现在分析型数据的上游

2.5. 分析型数据

• 2.5.1. 在分析过程中用到的数据

• 2.5.2. 分析型数据是由数据驱动的业务决策背后的数据类型

• 2.5.3. 客户流失情况、点击率和在全球地区的曝光次数都是分析型数据的示例

• 2.5.4. 分析型数据则被用于更可靠、更高效的分析

• 2.5.5. 分析型数据在管理业务

• 2.5.6. 分析型数据在某种程度上推动了商业智能的发展

• 2.5.6.1. 人们很可能会觉得分析型数据对组织的成功更为重要或更为“核心”

• 2.5.6.2. 实际上，分析型数据往往依赖于事务型数据的转换和聚合

• 2.5.7. 分析型数据能够（并且）经常包含事务型数据存储的聚合或扩充

• 2.5.8. 分析型数据库则迎合了用户对海量数据集进行大规模聚合的需要

2.6. 与联机事务处理(On-Line Transaction Processing，OLTP)和联机分析处理(On-Line Analytical Processing，OLAP)之间的比较相同

2.7. 吞吐量与延迟

• 2.7.1. 吞吐量-延迟的约束会影响任何具有固定计算能力的系统

• 2.7.2. 传统的吞吐量指的是在某一单位时间内处理的数据量

• 2.7.3. 延迟指的是数据被处理之前所等待的时间

• 2.7.4. 吞吐量和延迟并不是完全相反的

• 2.7.4.1. 与现实中数据处理系统的构建方式有关

• 2.7.4.2. 与有限数量的请求处理程序有关

3. 数据仓库

3.1. Kimball集团

• 3.1.1. 现代数据仓库的概念部分归功于Kimball集团

• 3.1.2. 该集团在20世纪80年代开发了数据仓库/商业智能生命周期方法论

• 3.1.3. 工程师最常从事的数据摄取和预处理阶段

3.2. 数据仓库通常以结构化（行-列）的格式来存储数据

• 3.2.1. 模式级别的表类型

• 3.2.2. 数据仓库需要“写时模式”访问，这意味着我们在数据进入仓库时就设置了数据的结构

• 3.2.3. 数据仓库是完全集成和托管的解决方案，使其易于构建和开箱即用

• 3.2.4. 数据仓库通常需要更多的结构和模式，这通常会对数据清洗的过程要求更高，并在读取和使用数据时降低复杂性

3.3. 常见的数据仓库技术

• 3.3.1. Amazon Redshift

• 3.3.1.1. 第一个广受欢迎（且随时可用）的云数据仓库

• 3.3.1.2. Amazon Redshift位于AWS之上，利用源连接器将数据从原始数据源传输到关系型数据库中

• 3.3.1.3. Redshift的列式存储结构和并行处理使其成为分析型工作负载的理想选择

• 3.3.2. Google BigQuery

• 3.3.2.1. Google BigQuery利用了Google的专有云平台GCP(Google Cloud Platform)并使用了列式存储结构，通过并行处理来实现快速查询

• 3.3.2.2. BigQuery是一种可根据使用模式进行扩展的无服务器解决方案

• 3.3.3. Snowflake

• 3.3.3.1. Snowflake的云数据仓库功能由AWS、Google、Azure和其他公有云基础设施提供支持

• 3.3.3.2. Snowflake允许用户为计算和存储单独付费，这让数据仓库成为寻求更灵活支付方案的团队的绝佳选择

3.4. 与管理数据质量相关的缺点

• 3.4.1. 灵活性有限

• 3.4.1.1. 数据仓库并不是市面上最灵活的数据存储解决方案

• 3.4.1.2. 数据的格式是有限的

• 3.4.1.3. 像JSON(JavaScript Object Notation)这样的半结构化数据及其查询通常不受支持，而且不良数据常常会被遗漏

• 3.4.2. 仅支持SQL

• 3.4.2.1. 查询数据仓库需要使用查询语言

• 3.4.2.2. 通常不支持使用Python等指令式编程语言进行数据操作，尽管这些语言由于强大的库生态系统对机器学习非常有用

>  3.4.2.2.1. 许多机器学习的实现需要通过SQL将数据移出仓库，以便进一步处理

• 3.4.3. 工作流之间存在冲突

• 3.4.3.1. 写时模式系统提供的清洁度带来的问题比好处要多

3.5. 数据团队同时采用数据仓库和数据湖来处理分析型工作负载的情况并不少见，因为它们分别有着不同的用途

4. 数据湖

4.1. 数据湖的概念最早是由软件公司Pentaho的创始人兼前首席技术官James Dixon提出的，他将其描述为“在一个更自然的环境中的一大片水域

• 4.1.1. 数据湖的内容从源头涌入并填满整个湖泊，湖的不同用户都可以来检查、探索或取样”​

• 4.1.2. 文件级别的操作

4.2. 数据湖能存储任何结构化数据、半结构化数据和非结构化数据

• 4.2.1. 与数据仓库不同，数据湖不需要具有高度指定的数据输入程序，你可以将任何喜欢的格式转储到湖中并直接访问它

• 4.2.2. 其结果是系统的容量通常更高，并且在治理和数据方面往往更加复杂

• 4.2.3. 数据湖是现代数据系统另一种日益流行的存储和计算选择，它也依赖于高质量的分析型数据来提供最佳结果

4.3. 数据湖架构允许“读时模式”访问

• 4.3.1. 这意味着我们可以在准备使用数据时再推断数据的结构

4.4. 数据湖是数据仓库的DIY版本，允许团队根据系统需求选择自己想要使用的各种元数据、存储和计算技术

• 4.4.1. 数据湖非常适合希望构建定制化平台的数据团队，通常由少数（或更多）数据工程师提供支持

• 4.4.2. 借助数据湖，数据科学家、机器学习工程师和数据工程师可以从更大的数据池中提取半结构化数据和非结构化数据

4.5. 早期的数据湖主要建立在Apache Hadoop MapReduce和HDFS(Hadoop Distributed File System)上，利用Apache Hive通过SQL引擎来查询数据

4.6. 通用特征

• 4.6.1. 解耦存储和计算

• 4.6.1.1. 不仅可以节省大量成本，而且有助于解析并丰富数据以进行实时流式传输和查询

• 4.6.2. 支持分布式计算

• 4.6.2.1. 分布式计算有助于提高大规模数据处理的性能，因为它允许更好的分段查询性能、更容错的设计和更佳的并行数据处理能力

• 4.6.3. 定制化和互操作性

• 4.6.3.1. 由于其“即插即用”的特性，随着公司数据需求的演进和成熟，数据湖可以让栈中的不同元素轻松地协同工作，从而支持数据平台的可扩展性

• 4.6.4. 主要基于开源技术进行构建

• 4.6.4.1. 有助于降低供应商被锁定的风险并提供强大的定制功能，对于拥有大型数据工程团队的公司来说非常适用

• 4.6.5. 处理非结构化或弱结构化数据的能力

• 4.6.5.1. 数据湖可以支持原始数据，这意味着在处理数据时具有更大的灵活性，非常适合数据科学家和数据工程师

• 4.6.5.2. 使用原始数据可以更好地控制聚合与计算

• 4.6.6. 支持复杂的非SQL编程模型

• 4.6.6.1. 支持Apache Hadoop、Apache Spark、PySpark等高级数据科学和机器学习框架

4.7. 突出挑战

• 4.7.1. 数据完整性

• 4.7.1.1. 数据湖中的资源在文件级别进行操作时无法保证其数据模式

• 4.7.1.2. ”盲目ETL”(blind ETL)的危险操作

• 4.7.1.3. 由于不可预见的上游变化，转换可能会在任何时候失败

• 4.7.2. 沼泽化

• 4.7.2.1. 沼泽化是指数据湖随时间推移产生技术负债和隐性知识的趋势

• 4.7.2.2. 必须依靠熟练的数据工程师或数据科学家来了解特定数据所在的位置、利益相关方是谁，并预计数据将如何变化

• 4.7.2.3. 意味着没人能完成任何工作，因为数据认知所需的学习成本实在是太高了

• 4.7.3. 更多端点

• 4.7.3.1. 人们可以通过更多方式来收集、操作和转换数据

• 4.7.3.2. 管道中的步骤越多，出错的可能性就越大

• 4.7.3.3. 数据湖通常被用作大量非结构化数据的收集点

4.8. 较小的团队可能会使用数据湖作为唯一的数据存储工具，以实现快速移动的目的，而不是依赖强大的基础设施

• 4.8.1. 始终警惕“数据沼泽”问题

4.9. 数据湖与数据仓库的不同之处主要在于它们允许更为灵活的存储格式

5. 湖仓一体

5.1. 数据湖也添加了提供仓库式特性的技术，例如SQL功能和模式

5.2. 数据仓库和数据湖之间的差异如今正在不断缩小，所以你能够在一个软件包中获得两全其美的体验

5.3. 高性能SQL

• 5.3.1. Presto和Spark等技术在数据湖上提供了接近交互速度的SQL界面

• 5.3.2. 开辟了数据湖直接服务于分析和探索需求的可能性，而无须对传统数据仓库进行汇总和ETL

5.4. 模式

• 5.4.1. Parquet等文件格式为数据湖表引入了更严格的模式，以及用于提高查询效率的列式格式

5.5. 原子性、一致性、隔离性和持久性(Atomicity，Consistency，Isolation，and Durability，ACID)

• 5.5.1. Delta Lake和Apache Hudi等数据湖技术在写入/读取事务中引入了更高的可靠性，并让数据湖更接近传统数据库技术标准中的理想ACID属性

5.6. 托管服务

• 5.6.1. 对于希望减少与构建和运行数据湖相关的运营成本的团队，云服务供应商提供了各种托管湖服务

5.7. 湖仓一体未来几年可能会在各行各业的数据团队中变得越来越受欢迎，且越来越重要