大数据最新数据仓库解决方案——ODPS组件化改造之路(3)，面试必问

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

****▐ 组件的价值

如上，在实际业务实践中，有大量的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

▐ 按需调度，省时又省力

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

优化前，整个节点调度周期平均为：20分钟

优化后，日常天级调度周期平均为：15分钟

大促小时级调度周期平均：2分钟

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

感想

遇到一个问题，经过思考后往往有不止一种方案可以去解决它，也许我们最终只会采用其中的一种方案，而被采纳的方案一定是经过仔细地比较优缺点，衡量投入产出成本等多方面评估之后才做的决定。在本文中，笔者也不是一开始就知道可以通过ODPS的组件来解决问题，而是经过反复地查资料，咨询ODPS平台的同学等方式后才行成通过ODPS组件化的方式来解决问题。
开发中我们会遇到各式各样的问题，但很多问题，很多知识，我们可以做到融汇贯通，举一反三。就像本文的案例中，组件这一概念，其实我们在其他领域中已经接触过，如果我们能做到融会贯通，我们是不是一开始就会联想到在ODPS里会不会有组件（或者模板）呢？

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

中…(img-R1y2zR4s-1715450886493)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取