数据处理流程
? ? ? ? ? 数据采集-清洗-存储-计算-分析-应用(最重要的是存储和计算最重要)
MR处理流程
? ? ? ? map-hdfs-reduce-map-hdfs-reduce。。。。。这样就很慢
spark+flink 基于内存去处理数据，除了checkpoint以外不和磁盘交互
数据集市：面向主题，面向不同用户的需求
数据库：
主要做增删改查，但是难做数据关系，线性回归啥的
数据仓库：
统一规范存储所有数据，并未所有业务部门提供数据服务
数据仓库具有特性：
? ? 集成性，主题性，稳定性，时效性
数据湖是什么
数据仓库解决的问题和痛点：
? ? ? ? 数据仓库解决了不同业务系统数据库之间的数据孤岛问题，但是也有问题
1：没有非结构化的数据：图片，音频，视频，PPT等
2：数据仓库没有保留原始数据
数据湖:不同的数据格式河流汇入湖
结构化数据+非结构化数据
具有以下功能：
? ? 海量数据+数据格式不限制+较好的分析处理能力
? ? 追求统一存储和统一分析还有批流一体（敏捷）
不断完善的数据湖理念：
? ? ? ? 存储原始数据（结构化数据，半结构化数据，非结构化数据，二进制数据如图片）
? ? ? ? 灵活的底层存储（S3/HDFS/Parquet/Orc/Avro，数据缓存加速，轻量级索引）
? ? ? ? 完善的数据管理（多种数据源接入，数据连接，Schema连接，权限管理）
? ? ? ? 多种计算模型（批处理，流处理，交互式分析，机器学习）
LakeHouse理念：
? ? ? ? DataLake+DataWarehouse
开放性：使用的存储格式开放性和标准化，并且为各类工具和引擎，包含机器学习，Python/R，提供Api，以便可以直接访问数据
支持从非结构化数据到结构化数据的多种数据类型
BI支持：可以在数据源上使用BI工具
支持多种工作负载：包含数据科学，机器学习，sql分析
模式实施和治理：
? ? ? ? 更好管理元数据（Hudi的元数据在Hive），schema管理和治理，不让数据湖变成沼泽地
事务支持：
? ? ? ? 并发读写数据，对ACID事务的支持确保了多方并发读写时的一致性问题
端到端流：
? ? ? ? 为了构建LakeHouse，需要一个增量数据处理框架，如Hudi
数据湖和数仓对比：
????????数仓的数据价值必须提前明确，但是数据湖不必，直接导入再找到价值
? ? ? ? 数据仓库必须先定义Schema再存储，数据湖不用
? ? ? ? 数据仓的扩展成本是中成本，而数据湖扩展成本较低(支持upsert操作)
? ? ? ??
数据湖方案：
数据湖只是一种思想而已
1：基于hadoop生态的数据湖方案
? ? ? ? ? ? ? ? 存储：hdfs
? ? ? ? ? ? ? ? 数据分析：Spark，SparkSql（读时模式）
2：基于云上的数据湖方案
3：基于商业产品的数据湖方案
读时模式和写时模式
? ? ? ? 在传统数据库里，表的模式是在数据加载时强制确定的。如果在加载时发现数据不符合模式，则被拒绝加载数据。因为数据是在写入数据库是对照模式进行检查，因此这一设计有时被称为“写时模式”（schema on write）。
? ? ? ? ?Hive这种类型的数据处理模式对数据的验证并在不加载数据时进行，而在查询时进行。这称为“读时模式”
数据湖解决的痛点问题：
? ? ? ? 离线数仓痛点
? ? ? ? ? ? ? ? 1：TB级数据T+1离线数仓跑批失败，重跑之后浪费资源
? ? ? ? ? ? ? ? ? ? ? ? 某个节点数据跑错了，后面都要重跑
? ? ? ? ? ? ? ? 2：写时模型，字段变更怎么办
? ? ? ? ? ? ? ? ? ? ? ? 表都定义好了，要是字段变更了后面都要变化
? ? ? ? 实时数仓痛点
? ? ? ? ? ? ? ? 1：无分层方案：无中间加工逻辑，直接入库
????????????????????如果没有分层，kafka+Flink这样的开发简单，但是也没有模型，数据不能重用，浪费资源
? ? ? ? ? ? ? ? 2：多分层，中间结果基于MQ，深度加工入库，kafka(ods)->flink->kafka(dwd)->flink->kafka(dws)->flink->kudu/ck
? ? ? ? ? ? ? ? 但是kafka无法做海量数据的存储
? ? ? ? ? ? ? ? kafka也无法做中间模型层的OLAP分析
Lambda架构
? ? ? ? 数据源一分为二
? ? ? ? ? ? ? ? hdfs->hive/sparksql? （批处理层）
? ? ? ? ? ? ? ? kafka->flink/sparkstreaming（速度层）
? ? ? ? 上面的数据要在‘服务层’合并，但是数据的merge成本高，合并不方便
数据湖解决上面的痛点
离线数仓问题
? ? ? ? 数据湖读时模式在读取数据时才检验数据
? ? ? ? 而且增量更新
实时数仓问题
? ? ? ? 数据存在湖中，湖作为ods，dwd，dws。中间结果基于数据湖，结果入库
lambda的问题
? ? ? ? 现在全在数据湖，统一引擎（批流一体flink，spark），所以解决合并问题
升级数据中台目标：
? ? ? ? 1：底层存储标准统一化
? ? ? ? 2：构建实时化标准层，去T+1，保证时效性（分钟级别更新）
? ? ? ? 3：底层存储更安全，更全面，回溯性更便捷，运维成本更低（Hudi可做权限，数据湖可以记录数据的新老版本）
折中方案：
? ? ? ? 数据在湖，模型在仓
? ? ? ? 在数仓和kafak之间做datalake，但是datalake也直接查询。datalake相当于ods层了
? ? ? ? 数据湖可upsert也可以小文件合并
总结，数据湖需要的功能
? ? ? ? ? ? ? ? 高效的upsert操作
? ? ? ? ? ? ? ? 高效的回溯能力
? ? ? ? ? ? ? ? 支持Schema变更
? ? ? ? ? ? ? ? 支持ACID语义
? ? ? ? ? ? ? ? 支持flink写操作
? ? ? ? ? ? ? ? 支持小文件压缩合并
