教材篇

直到翻看了后面章节，才注意到封面上面的标语，中文意思是“禁止倾倒数据垃圾，违者务必读此书！”
大致祖师爷对杂乱无序的数据垃圾深恶痛绝，在这点上大凡上了点年头的数据工作者都是深有体会~
在这里插入图片描述

单向数据湖问题

一开始数据湖信息在设计时并没有考虑未来的访问和分析，机构会发现这样的数据湖仅仅是数据量大而已，大部分数据并不能真正支持他们的业务，企业花费大量成本却没有带来任何收益
在这里插入图片描述

数据湖的改良目标

改造数据沼泽从单向流动为成良性流动，迭代数据资产从青铜变成黄金未目标。比较喜欢沿用Delta Lake官网的图
在这里插入图片描述

数据湖改良篇

改良一：基础属性的丰富，让数据湖具备洞察能力

为了方式数据无序倾倒进数据湖，第一步其实对数据进行基础成分的扩充。
1、元数据(metadata)
数据湖是可以容纳结构/半结构/非结构信息的，所以元数据可以是不同形式。典型的我们对元数据表现形式包含记录、属性、键值、索引等，但是如果其他类型结构，我们则需要描述他内容信息，这点非常关键。
表结构元数据记录、属性、键值、索引
文档型的作者、字数、标题、章节等
图片、视频等作者、标题、时长、内容描述

2、整合图谱(integration mapping)
不同应用程序，通常有不同的语言编写、因为在线系统相对隔离，数据比较独立的放到数据湖中来，形成一个个瓦罐，这个时候为了让数据湖中的数据合理，就需要有一份“整合图谱”
3、语境(context)
语境表达的其实是需要描述清楚数据所处的上下文环境约束，数据内容脱离了上下文的意义不明确的数据，在很多情况下，不约束语境其实会造成错误。比如用户的身份信息，可以有多个都会产生：
在这里插入图片描述

4、元过程
数据被如何处理，数据何时产生、数据谁产生的、数据规模多大、日增多大、是账务及还是交易及、有无精准日切
数据如何被入湖的、是否有进一步的加工转换。
值得强调的是数据应当一开始入湖的时候就有这些信息、否则如果中途补上的话会丢失历史信息，数据缺少历史的连续性，很影响使用者判断

在这里插入图片描述

改良二：对数据进行划分、关注数据生产特征，进行不同语义处理

数据的产生特性其实代表对数据生命周期管理可以不一样的，比如我们的流量日志型数据和业务交易类型可能就不一样，，虽然数据的产生方式多种多样，但是按照生产规律来说还是可以划分的，因为数据具有如通用的特征，所以对数据的加工方式也可以抽象。
常规的划分
模拟信号数据 (analog data)
日志型、监控型、诊断数据等都属于这一类，大体上这类数据是巨大且反复的，这一类数据除了数据内容本身
应用程序数据 (application data)
应用类型的数据主要是数据库的数据，比较有规律的schema
文本数据 (textture data)
这类包含大部分半结构、非结构化的数据，文本、音频、视频等，这类特征是不会按照特定的格式存储、需要进一步使用
另一个视角划分
按照重复性和非重复进行划分