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

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

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

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批处理。

本文首发于InfoQ，原文链接；https://xie.infoq.cn/article/f8e37c2205b4aae921aa7946c