数据仓库解决方案——ODPS组件化改造之路

场景还原

---

不知道你是否在写离线代码时遇到过以下几种情况：

• 相同的业务代码逻辑分散在各个地方，需要维护多份相似功能代码；

• 存在多张相同结构的表输入，需要经过相同或相似的逻辑计算加工，并输出给下游表；

• 有一个计算逻辑非常复杂，需要经过多个子流程或多个节点处理，如何理清楚这些这些节点的逻辑和层次关系？

这里举几个场景，好让你更形象地理解。

1. 在某个系统中，数据分大促活动数据和日常数据。大促活动数据优先级较高，需要每小时地调度计算，日常数据优先级较低，只需要天级调度。PS：在这个场景中，我们处理这些数据的逻辑高度地相似甚至相同，并且输入表和输出表的schema也是一样的，唯一不同的是调度周期。

2. 在某系统中需要统计分析不同维度下的销售数据，比如城市、省份、时间段（天、周、月）、区域等等

3. 某平台需要给多个业务输出数据，希望不同业务间的数据做隔离，一个业务只能读取本业务范围内的数据。

不知道现在有没有体感了，如果有了，请继续往下看。

---

解决思路

---

---

其实以上问题归根结底，我们需要有一套代码模板来实现代码的复用，我们可以通过参数的控制实现差异化的功能。

开始，笔者想到的是通过Java后台来生成这套模板代码，然后在ODPS 上创建Python脚本，通过Http请求Java后台的服务，以动态脚本的方式离线调度执行。

但很快发现这种方式存在诸多问题：

• 代码在JAVA侧，JAVA侧拼接SQL极易出错，需要经常发布JAVA应用来实现某个离线小功能的迭代，并且离线代码侵入后台系统本身也不太合理。

• SQL是动态生成的，缺少代码格式化，只能通过运行日志找到实际运行的代码，可读性差。

• 代码存在两个系统中，较为黑盒，代码测试和debug都较为困难。

最后，在翻阅ODPS的官方文档后发现，其实这些问题ODPS平台上已经具备相应的解决方案了——ODPS组件。

初识ODPS组件

============

---

▐  组件的定义

组件是一种带有多个输入参数和输出参数的SQL代码过程模板, SQL代码的处理过程一般是引入一到多个源数据表，通过过滤，连接，聚合等操作，加工出新的业务需要的目标表。

****▐  组件的价值

如上，在实际业务实践中，有大量的SQL代码过程很类似，过程中输入的表和输出的表的结构是一样的或者是类型兼容的，仅仅是名字不同而已。这个时候组件的开发者就可以将这样的一个 SQL 过程抽象成为一个SQL组件节点，将里面可变的输入表抽象成输入参数，把里面可变的输出表抽象成输出参数，就可以实现 SQL 代码的复用。

组件的使用者在使用 SQL 组件节点的时候，只要从组件列表中选择和自己业务处理过程类似的组件，为这些组件配置上自己业务中特定的 输入表和输出表，不用再重复复制代码，就可以直接生成新的组件 SQL 节点 从而极大提高了开发效率，避免了重复开发。

SQL 组件节点生成后的发布，调度的操作方法都和普通的 SQL 节点的操作方