数据仓库解决方案 (数据仓库解决什么问题)

数据仓库解决方案 (数据仓库解决什么问题)

场景还原

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

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

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

解决思路

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

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

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

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

初识 ODPS 组件

组件的定义

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

组件的价值

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

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

SQL 组件节点生成后的发布,调度的操作方法都和普通的 SQL 节点的操作方式是一样的。

组件的结构

一个组件就像一个函数的定义一样,由输入参数,输出参数和组件代码过程构成。

组件的输入参数

组件的输入参数具有参数名,参数类型,参数描述,参数定义等属性, 参数类型有两种:一个是表类型 table,一种是字符串类型 string。

✎ 表类型的参数

指定组件过程中要引用到的表,在使用组件的时候,组件的使用者可以为该参数填入其特定业务需要的表。

✎ 字符串类型的参数

指定组件过程中需要变化的控制参数,比如指定过程的结果表只输出每个区域的头 N 个城市的销售额,这个 n 是 1 还是 3 就可以通过字符串类型的参数进行控制;另一个例子,要指定过程的结果表输出那个省份的销售总额,可以设置一个省份字符串参数,指定不同的省份,就能获得指定省份的销售数据。

✎ 组件的输出参数

组件的输出参数具有参数名,参数类型,参数描述,参数定义等属性,参数类型只有一种:表类型 table。字符串类型的输出参数没有逻辑意义。

✎ 组件的过程体

在过程体中参数的引用格式为:@@{参数名}

过程体通过编写抽象的 sql 加工过程,将指定的输入表按照输入参数进行控制加工出有业务价值的输出表。

PS:其实作为码农,我们能很好地理解组件的概念,因为即使你没写过 ODPS 代码,不知道 ODPS 的组件,但你一定在你曾经用过的语言里找到类似的概念,例如,前端领域中的 UI 组件,移动 Android 开发中的组件,Java 开发中的各种框架,Jar 包等等都是一些组件。

牛刀小试

作为初识 ODPS 组件的小白,我们先尝试写一个 helloword,实现从一张大表中按业务拆分出多张子表,分别给到各自业务各自的表。

创建组件

过程体开发

PS: 组件过程的开发具有一定的技巧,组件过程的代码需要巧妙的利用输入参数和输出参数,使得组件过程能够在使用的时刻填入不同的输入参数和输出参数也能生成正确的可运行的 sql 代码。

填写输入输出参数

调试 &运行

在做完以上两步后,我们可以直接在组件开发的界面点击运行,输入测试的参数进行调试运行。

发布

组件具有版本号的功能,每次发布,版本号会自增,后面组件使用的地方会用到。

组件引用

在数据开发页面,在文件夹目录先右键选择创建 SQL 组件节点。

使用组件节点与 SQL 节点,大部分开发使用习惯都是一样的,包括调度配置也都一样,唯独不同的是组件节点关联了一个组件,如果需要更新节点,需要先更新组件的代码,然后更新节点的代码版本。

进阶使用

进阶思考

笔者在项目开发过程中,碰到一个问题,项目开始的时候给很多离线节点设置了小时级调度,但随着项目的数据日益增长,离线节点的调度时长很快接近一小时,离线调度很快将达到瓶颈。比较自然地想到的解决方法是,将每小时调度改为每 2 小时调度一次,或者将小时级调度切换成天级调度,但明显不是一种根本的解决方案。

能不能根据数据的重要程度,分配不同的调度优先级呢?想到这,立马有了灵感~

经过分析后,我们系统中存在两种类型的数据,大促数据和日常数据。大促数据由于具有时效性,过期的数据往往会进行清理,因此大促数据随时间不会大幅增长;而日常数据由于具有长期有效,随时间必然会持续的上涨。

另外大促数据时效性要求较高,日常数据变更频率慢时效性低。

通过以上分析,可以看出大促优先级较高,而日常优先级较低。因此我们可以将数据切分为大促数据和日常数据,大促走小时级调度链路,日常走天级调度链路。

通过统计可以看出数据分布大约为日常:大促=10:1

按需调度,省时又省力

下面举一个已优化过后的例子:

可以看出,经过改造后,大幅节省了原来小时级调度的计算资源和存储成本。

感想

参考文献

1、什么是 ODPS

、什么是>

、ODPS 组件

原文链接 :

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

声明:本文来自用户分享和网络收集,仅供学习与参考,测试请备份。