数据湖使用分享

1 引入背景：

目前我们实时接入binlog，用的是kudu，但kudu对大事务支持不好，关键成本比较高，大数据加胜同学建议尝试数据湖，从而开始了数据湖的探索。后续与培殿同学一直配合跟进数据湖，发掘出数据湖更多功能，用于生产。

2 数据湖基本概念

本质来讲，数据湖是一个关于存储的设计模式

2.1 数据湖基础概念snapshot

snapshot是iceberg比较重要的概念。Iceberg 基于MVCC（Multi-Version Concurrency Control）设计，每次commit都会生成一个快照（Snapshot），该快照包含唯一的snapshotId、时间戳timestamp及对应的manifest文件。

如下图所示，最新 snapshot 拥有该表的全局视图，每个snapshot包含多个manifest文件，每个manifest文件中记录本次事务中记录写入文件与分区的对应关系，且包含一些文件记录的统计信息（如lower_bound、upper_bound、added_rows_count、deleted_rows_count）用来快速筛选文件。一定程度上可以把 manifest 文件理解为索引文件。

基于Snapshot的设计，用户需要通过snapshot来访问iceberg中的数据，如果数据写入但没有commit成功，就不会生成新的snapshot，也因此不会访问到这部分不完整数据。

3 根据数据湖特点，我们能做什么事情

头脑风暴时刻，它有什么特性，为什么要引入，引入到底能解决什么问题

3.1 支持事务，行级别更新

利用这个特性，我们可以：

flink实时cdc

对于实时数仓，我们可以用更好的离线修复，做到万无一失

同时也可代替kudu，节约成本，提高实时性

3.2 去分区概念，小文件问题

iceberg使用不用care分区，解决hive分区痛点，hive如果不添加分区，可能造成灾难性的后果。iceberg有类似分桶概念，且后台可自助合并数据

对使用方更友好，直接给我表名完了呗，干啥又让我知道分区概念

3.3 实时兼容更好，生态形式

一个新组件的前景，可以从其特性与依赖的生态来推测。iceberg上接计算引擎，下接底层存储hdfs，像kudu就是自己搞的一套，提高读性能，牺牲写性能，定位介于hdfs，hadoop之间。

3.4 读写分离

基于snapshot，如果读写同时进行，当前写snapshot没有完成commit，读不可见，但可以读历史snapshot

3.5 schema动态切换

主要为更改schema结构，对非结构化数据比较好

3.6 统一存储

底层存储统一用iceberg，代替hive

不支持在 Docs 外粘贴 block

引入数据湖，首先需要解决与优化目前已有的痛问题为切入点去推动数据湖，随着使用的积累，可优化目前的实时架构。

两个能落地的项目

1 简化同步实时链路

前几版大致介绍，中间结果（timetravel spark找），最新版本介绍

1.1 监控hdfs路径

flink监控hdfs路径，只要这个路径下面有新增文件即同步。有几个缺点，读只有一个并发，新增与删除是两个流；对于重新回溯数据不太友好，需要删除所有数据；

1.2 基于talos，解决以上缺点

1. SparkStreaming 常驻进程写talos


2. Flink读取talos，通过状态对比，只发送更新或者新增数据


3. Binlog数据实时入kudu，hive与kudu表格对比找到删除数据；但kudu有延时，事务等问题

链路多了，数据量大了，各种问题就会被慢慢放大

1.3 中间过渡版本

数据湖支持timetravel，每个snapshot的数据都可以拿到，通过前后两个snapshot对比就可以拿到差异数据。不过目前不支持sql 方式，需要写代码解决

1.4 实时同步第三版

不支持在 Docs 外粘贴 block

经过多天运行后，事实如下：

flink可直接读取到变化数据，直接同步到下游

2 实时数仓

构建实时数仓的两种方式

1 cdc入湖，实时更强

cdc目前有两种方式mysql或者talos

1.1直连mysql方式

目前有集群白名单问题，不过感觉加个代理也可以解决

1.2 talos方式：自己生成或者已经授权的Talos

如果是我们自己的库比较方便，但其它业务业务系统，一般我们拿不到mysql连接，对方更愿暴露talos。

目前公司主要使用的方式，采集binlog到talos，再入kudu或者iceberg。

重新回溯数据一般采用置位删除

一般在建表之初直接采集binlog，如果后期，数据量太大，初始化会有几分钟的延迟

2 基于已有表格

基于其它已经表格之上构建实时数仓，得益于大数据培殿同学大力支持，我们可以自己使用merge into构建cdc数据

原理：

merge into 新语法+iceberg V2表格=带有新增，删除，更新功能的表格

数据生成：

新beeline(类似miquery) 读取hive等数据，使用merge into 语法，写入到iceberg

对于公共模块在精减ing，减少冗余

3 另外数据湖支持事务，可离线进行校正

不支持在 Docs 外粘贴 block

底层直接使用merge into，后面ads表格根据底层聚合后，也能识别，所以不需要再使用merge into，直写sql即可

1 队列改造

2 建表语句与sql改造

3 build脚本改造，能公用的都公用，去除重复劳动，

4 beeline 采用token方式，也没有了kerberos问题