一种在数据量比较大、字段变化频繁场景下的大数据架构设计方案

目前大数据中数仓建设方案有很多，但一般都是常规的设计方案，如果在数据量比较大，字段频繁变更，数据频繁刷新，大数据架构方面如何设计呢。

大数据架构的设计方案需要考虑多个方面，包括数据存储、数据处理、数据传输、数据安全等。但此处我们不考虑过多，讨论下较通用的架构设计。

1. 这种字段和数据都频繁变化的就不太适合设计链路过长和复杂的架构，后续维护这种架构会非常麻烦。但同时也不能过于简单，也要有一定的分层架构，不然耦合性太高，一旦源业务系统的业务规则发生变化将会影响整个数据清洗过程，并且对处理后的公共数据利用率也较低。

2. 同时考虑字段频繁变化，后续数据存储时就要选择列可以随意增减，或者列增减成本不高的存储方案。

我们考虑以上情况，发现 Kappa 架构还是较符合的，整体流程如图 1

从源系统同步过来的数据落到 ODS 层，但是要注意采集数据时需要能捕获到源系统表结构的变更，可以采用 Flink CDC 等。

ODS 层的数据落到 Kakfa 中，设置一个较长的保存周期。kafka 直接作为数仓的存储层，优点是不关心数据的格式，不管源系统字段怎么变，都可以 JSON、Avro、Protobuf 等格式存储，并且可以轻松地扩展，可以处理大量数据，达到高吞吐量和低延迟。同时可以实时数据处理，可以将多个数据源汇聚到同一个 Kafka 主题中，方便在数仓中使用。

注：Avro 和 Protobuf 都是二进制数据序列化格式,相比于 JSON 这种文本格式，它们在存储和传输时更加紧凑，解析和序列化效率更高。Avro 和 Protobuf 更适用于大数据量、复杂数据结构、数据结构变化频繁的场景。

ODS 层数据直接使用 Flink 进行清洗，加工等操作，将数据同步到 DWD 层，DWD 的数据是比较规整的明细数据。

DWD 层的数据也同样落到 Kafka 中，使用 Flink 做一些关联，轻聚合等操作，把可以直接对外使用的或者分析的数据落到 DWS 层。

DWS 层的数据不适合落到 Kafka 中，因为 DWS 的数据需要进行数据分析、对外等，所以 DWS 层的存储最好是能支持 SQL，即系查询分析等，以方便其他人员使用，同时还要支持字段频繁变更的需求。所以可以使用 Kudu，与 impala 进行整合，就可以使用 SQL 对数据进行实时 OLAP 分析。

上面的架构中间层的数据落到 Kafka 虽然有很多优势，但是 Kafka 本身不是一个数据库，不支持 SQL 查询，也不支持数据的索引和聚合，因此在数据分析方面的能力有限。另外 Kafka 是一个基于事件的系统，不同于传统的基于事实表和维度表的数据仓库建模方式，因此需要对数据的建模和 ETL 流程进行重新设计和开发。Kafka 的存储方式是基于主题分区的，每个分区的数据按时间顺序进行排序，因此也不适合存储需要复杂查询和复杂关联的数据。

所以在数据存储方面看看能不能有更好的替代 kafka 的方式。基于数据刷新频繁，字段变更频繁，需要找一个支持行级数据删除或更新及表的 Schema 变更非常容易的一个框架。

大部分数仓都难以实现较为高效的行级数据删除或更新，通常需要启动离线作业把整个表原始数据读取出来，然后变更数据后，写入到一个原始表，显然不符合需求。

目前数据湖技术发展非常迅速，iceberg 可以较好的支持上述需求。iceberg 成功把变更数据的范围从表级别缩小到了文件级别，从而可以通过局部变更来完成业务逻辑的数据变更或删除。并且 iceberg 在变更表结构的时候，历史数据并不需要全部重新按照新的 Schema 导出一份，从而使得 Schema 变更的速度非常快。同时，由于 iceberg 支持 ACID，有效地隔离了 Schema 变更对现有读取任务的影响，从而使得可以读取到结果一致的数据。

iceberg 是介于上层计算引擎和底层存储格式之间的一个中间层，我们可以把它定义成一种“数据组织格式”，底层存储还是 HDFS。

整体架构如图 2 所示，把 kafka 换成 iceberg，同时最后借助 Doris/Presto 等 OLAP 引擎来实现数据湖的分析。

同时图 2 展示的也是一个流批结合的实时数仓。之后对于日志类实时特征，实时大屏类应用走实时流计算。对于 Binlog 类业务分析走实时 OLAP 批处理。