数仓设计的几点原则

01 - 高内聚、低耦合

高内聚、低耦合是软件设计的常见概念，特别是在软件模块划分中会被常常提起，需要将功能相同的内聚在一起，将职责不同的功能解耦， 比喻说常见的MVC 分层模式，每一层负责单独的功能。高内聚、低耦合可以使得软件模块职责划分清晰，后期扩展性强，便于维护。

从上面的描述可知，高内聚、低耦合也就是怎么合、如何拆，对于数仓中合并与拆分，常常发生在模型设计中：水平拆分/合并、垂直拆分/合并，不管是对于实事表还是维表设计都需要做这两点的考量，可以将业务相似、表达粒度相同、产出时间相近的模型合并在一起。

02 - 复用

复用就是使用现成已有的能力，减少重复的建设工作。常见中台很重要的一个能力就是复用，常见电商中商品中台、交易中台等业务中台，其上层可以支撑跨境、本地化等不同的业务模式，减少每种业务模式下的基础能力建设工作。

在数仓建设中，复用主要体现在中间层的建设：一、在早期业务快跑模式下，可能会产生很多数据采集、清洗等标准化的工作，各个业务线或者是使用方建设自己使用的中间层，完全是一种烟囱式的开发方式，会造成模型混乱、不断重复建设，因此可以将中间层提取出来统一建设，使其可复用；二、计算指标复用，将一些被多次使用的指标沉淀下来，减少重复计算并且也可以减少指标一致性问题。

03 - 可重刷

可重刷也就是可以重复执行，在数仓中是比较常见的操作，经常性会因为逻辑变更、数据变更、任务失败等需要执行任务重跑操作。在数仓内部本身可通过insert overwrite方式保证任务重跑数据的正确性，在应用层数据同步到外部在线存储中，例如MySQL、HBASE等数据库，MySQL需要指定uniqueKey并且使用replace语法，HBASE本身rowKey唯一并且重复写入自动覆盖，通过这些方式保证重刷数据的正确性。

04 - 命名规范

好的命名规范保证了大家对表、指标的统一理解，便于后期维护与减少咨询工作，这里列举常见表的命名方式：

ODS	s_{dbName}   :  全量 s_{dbName}_delta ：增量
DWD	dwd_{业务板块}_{数据域}_{业务过程}_di : 按天增量 dwd_{业务板块}_{数据域}_{业务过程}_df ：按天全量
DIM	dim_{业务板块}_{维度}
DWS	dws_{业务板块}_{数据域}_{维度1}_{维度2}_1d/nd
TMP	临时表：tmp_dwd_{业务板块}_{数据域}_{业务过程}_di_0/1

这里只给出了部分的命名方式，在不同的公司有不同的规范，不管以何种方式命名，都需要保证遵守命名规范。

05 - 重构

重构并非是一个必须的动作，只有到一定的体量、一定的复杂度才会去考虑的事情。就像上面提到的：对于公共的中间层需要提取出来进行重构，以达到复用的效果，因此重构需要有一个目标，复用、性能、指标一致性都可以成为重构的目标。

当我们接到一个数据需求时，除非能够预判到该指标是一个公共指标，那么可以直接将其下沉到公共层作为可复用的公共指标，否则很有可能被作为一个个性化的指标放在应用层，当下次在遇到需要使用该指标时，要么两种情况：1. 直接复用，但是在应用层之间依赖必须遵守一定规范，不然模型依赖就会变得很混乱；2. 重新开发，增加指标一致性风险与计算成本。因此可以考虑模型重构，将该指标的计算沉淀到公共层或者集市层使其可复用。   

历史推荐

AliExpress 基于Flink的实时数仓建设

Flink 程序设计之道

数仓指标一致性

关于Event-Time 所带来的的问题

不得不掌握的三种BitMap