演进式数据架构.pdfVIP

演进式数据架构

本文借助于《演进式架构》这本书中关于演进式架构体系的描述，探索我们如何在数据这

个领域，设计出演进式数据架构。

演进式架构支持跨多个维度的引导性增量变更。

——《演进式架构》

这是《演进式架构》这本书第一章第一节对“演进式架构”的作用做出的简洁定义，也就是说演进

式架构便是持续架构，因为在架构这件事上没有最终状态，它会随着软件开发体系的不断变化

而演进，我们只能将时间和变化作为维度来定义、引导架构的走向。

《演进式架构》一书对于软件系统架构如何演进给出了相对明确的方向，但是对于数据领域来

说，不但目前的基础设施相对落后，连数据系统构建相关的知识体系也异常匮乏，当我们尝试

将业务型的软件系统（此处特指事务形的业务系统）架构中的最佳实践硬套到数据领域后，便

会发现非常不兼容。

例如微服务和数据服务天生冲突，微服务通过多个无状态的服务进行快速切换，以确保业务侧

对于系统发生的宕机无感知，而数据服务天生具备的则是分布式多节点计算，并且需要持续较

长时间，要求任务具备高可用。DDD与数据建模也同样天生冲突，DDD基于聚合根将多个动作

圈定在同一个上下文中，结合云原生可以进行更好的弹性扩展，结合微服务的实现，各个服务

独享自有的存储，然而数据建模天生不是为某一个业务服务，而是为某一类或者多类业务服

务，因此天生就不具备上下文的概念。

即便如此，我们依旧在不断探索，在这个领域有哪些更好的方向值得我们去尝试，有哪些更好

的经验值得我们去借鉴。本文便是借助于《演进式架构》这本书中关于演进式架构体系的描

述，探索我们如何在数据这个领域，设计出演进式数据架构。

数据架构的类型

大部分场景之下，我们所看到的数据架构，更多是按照企业所处阶段或者业务性质来定义的，

例如数据仓库、大数据平台、大数据仓库甚至智能平台。这样的架构定义之间的跨度非常大，

甚至不存在“演进”的可能性，几乎就是替换和重做，因此这种数据架构的定义太过于狭义，不太

适用于我们去探讨数据架构如何演进。

让我们重新审视和定义一下数据架构的类型，那么从大的方向来说我们可以将数据架构划分为

一体化架构、分布式架构和领域分布式架构，仔细拆开来看是这样的形态：

单体架构（数据仓库）:

复用业务架构:和业务系统高度耦合，数据架构建立在业务系统之上，和业务系统共用

同一个DB。

大泥球架构:整体没有分层，耦合的架构。

LayeredDataArchitecture:采用了Kimball,Inmon,星形模型,雪花模型等分层模型

的数据架构，更加容易进行改变了创造适应度函数。

DataVault:整体架构进行了模块化的拆封，更加容易解耦，也更加容易进行模块替

换。

分布式数据架构（基于数据湖的架构）:

基于存储系统（S3，HDFS）:采用分布式存储系统对数据进行存储的数据存储解决方

案，数据难以修改。

基于NoSQL数据库(HBase,etc.):将数据存储在NoSQL的存储介质中，同时承担存

储和分析的职责，高度耦合。

SQLonHadoop:基于Hadoop的SQL解决方案，更加容易演进和分层设计。

实时数据处理架构:Lambda,Kappa等架构，很容易修改和演进，但是整体复杂度会很

高。

面向域的分布式数据架构（DataMesh）:

数据即服务:提供数据端到端开发所需要的工具和服务，架构既承担着工具提供的职

责，也负责维护工具产生的数据服务，更像是一个数据的SAAS平台。

数据平台即服务:提供数据PAAS的能力，架构提供更加灵活的能力，允许租户使用自

己的工具，也可以使用平台的工具，架构仅仅是基础设施。

即便是数据仓库，也是有不同的实现，最简单的便是嵌套在业务系统中，没有所谓的物理上的

数据仓库的概念，业务系统在生产数据的同时也承担着数据仓库的职责，这种系统相对来说很

容易就能抽象演变成独立的数据仓库系统。

除了内嵌到业务系统之外，也有不少企业选择以构建数仓的形式，为业务系统开启一个备库，

然后