读数据质量管理：数据可靠性与数据质量问题办理之道02数据湖仓
https://img2024.cnblogs.com/blog/3076680/202411/3076680-20241112162053852-1235517729.png1. 组装
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. 湖仓一体未来几年大概会在各行各业的数据团队中变得越来越受欢迎，且越来越紧张
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]