说说数仓(9)-上下游约定

---

数仓总结目录：
说说数仓(1) - 什么是数仓
说说数仓(2) - 传统数仓与互联网数仓
说说数仓(3) - 数仓架构
说说数仓(4) - 指标字典
说说数仓(5)-最重要的维度之日期维度
说说数仓(6)-关于命名规范
说说数仓(7)-浅谈数据治理
说说数仓(8)-关于增量
说说数仓(9)-上下游约定
说说数仓(10)-任务注释

---

我平时比较喜欢说数据平台，现在数仓逐步变成了数据平台的一部分，偏向建模这块儿。

由于数仓的特性和定位，它就需要强依赖上游的业务系统，当然也会有一些下游系统，所以定好上下游的规范，变更的通知机制是非常有必要的。

感觉好像写过上下游的事情，刚才没找到，这里就再重新写写。

上游

这里说的主要是基于小公司，类似我目前所在的创业公司为例，像发展成熟的大公司，各种流程规定、容错监控类的机制都很完善，对于这些场景，我说的可能就不适用了。

对于数仓来说，最重要的就是数据了，数仓中的数据，主要来源是业务系统，就是公司各种业务数据，所以数仓需要不断的将业务系统数据同步到自身平台来，所以一旦上游业务系统发生变化，数仓也要同步变化，不然，这种同步操作很可能失败。

• 表结构变更
  上游的表结构经常会发生变化，新增字段、修改字段、删除字段（除非真的不用这个字段了，通常会选择标识为弃用）。

表结构最好要维护清楚，表名、字段名、字段类型、字段描述，都整理清楚，不使用的字段要么删除，要么备注好，当业务频繁发生变化或者迭代优化的时候，很容易出现，我写了半天的代码，最后发现表用的不对，字段用的不对，这就尴尬了。

对于这种变化，人工处理的话，就是手动在数仓对应的表中增加、修改字段，然后修改同步任务；这个最好可以搞成自动化的，比如，自动监控上游表结构的变更，变化后，自动去修改数仓中的表结构，自动修改同步任务。

• 枚举值
  业务系统中会有很多的常量，用来标识一些状态或者类型，这种值经常会新增，数仓中会对这些值做些处理，比如转换成维度，会翻译成对应的中文，而实际上这种映射关系，我们是不知道的，只有业务开发才知道，所以最好可以让他们维护一张枚举值表，我们去同步这张表。

• create_time & update_time
  正常来说，create_time，当这条记录插入后，就不会再变了，但是某种情况下，哈哈，开发同学会去更新它；update_time，当这条记录变化后，这个时间也要变，有的开发同学不去更新它......
  所以在做增量操作的时候，一定和开发说好这两个字段的定义和使用场景。

• is_delete & is_valid
  有些场景下，我们需要删除某些数据，一般不会物理删除，会通过一个字段来做逻辑删除，请和开发同学沟通好，使用固定的一个字段，并确认该字段双方的理解是一致的，不然后面又很多坑。

下游

说完了上游，我们说说下游，对于数仓来说，一般的邮件、报表、可视化平台都是下游，所以当我们在数仓中进行某些重构、优化操作的时候，也需要通知他们。

主要就是对数仓模型做好维护，表的使用场景、字段描述等。

对上游的要求，自己也要做好，因为自己也是上游。