数据量比较大，字段频繁变更，数据频繁刷新，架构如何设计

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

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

2. 同时考虑字段频繁变化，后续数据存储时就要选择列可以随意增减，或者列增减成本不高的存储方案。我们考虑以上情况，发现Kappa架构还是较符合的，整体流程如图1

图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

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