spark菜鸟教程 spark项目实战代码

文章插图
前言大数据开发的日常工作中，开发人员经常需要使用 Spark、Flink 等计算引擎作为工具来实现一些业务逻辑的计算。
以 Spark 为例，开发人员会使用 SparkSQL、DataFrame、RDD 等不同形式的API来实现业务需求。
通常情况下，简单的需求都可以通过 SparkSQL、DataFrame 很方便的实现，其简洁的API也是其深受数据分析师青睐的原因之一。
但是正是因为 SparkSQL、DataFrame 的高层次封装，在复杂度较高的计算需求实现中，可能会出现实现复杂或者API的功能性无法满足，或者千方百计实现需求之后性能表现低下，代码段复杂而庞大的情况。
尽管Spark允许开发人员通过UDF、UDAF等形式提供自定义的函数功能，但是此时很多人会选择使用较为底层的RDD接口进行开发：可控性好、开发与调试方便、性能强劲。
但是使用RDD接口来开发业务需求时，很多小的项目团队并没有一个统一的项目规范，需求开发完全由开发人员个人自己发挥。
各个业务项目的大致流程基本是相同的：
创建SparkSession用 spark.table or spark.textFile 等API读取数据源进行RDD的各种 Transformation 和 Action 操作得到数据结果之后再调用 saveAsTable or saveAsTextFile 写入外部数据源中虽然看起来流程挺一致的，但是其中仍然存在以下问题：
业务代码混乱团队成员代码风格不一，有的喜欢一长串一长串的写，有的喜欢将过程封装即使将过程封装了，但是封装的边界没有明确定义，仍然会有人不小心“越界”读写数据源的API使用不统一各个计算引擎对各个数据源都有不同的读写API接口提供使用，一些比较繁杂的API可能会被人“错误”使用同时也会有人时常忘记对应接口如何使用，反复查阅资料重复的编码工作理论上所有业务项目，除了业务逻辑是变化的之外，其余应该都是一个不变的模板开发人员应该专注于变化的业务逻辑，而不是每次都要分一些精力出来处理其他“边边角角”的事情没有规范任由团队成员发挥的话，尽管有些成员能写一手漂亮的代码，但是你并不能保证所有人都这么优秀。
时间一久项目中代码的坏味道会越来越多，最后混乱的程度可能会超出你的想象。
为了解决以上问题，我们建议：定义一个项目规范，所有业务项目都需要遵守这个规范。
俗话说，有规矩成方圆。
有了项目规范，所有人都遵守这个标准来开发。
有了这个标准，我们就可以在标准化的基础上做很多事情，比如定义自动化工具来帮助开发人员解放双手。
本文讨论的项目规范可以作为一种参考，以供读者与相关开发人员翻阅。
一、项目规范和Java项目规范类似，以模块化项目的结构来定义项目规范可以为业务项目提供结构化标准，其可以规整所有混乱的业务项目结构。
项目结构标准化的重要性：
项目统一管理与生成方便快速搭框架所有开发人员遵守相同的编码规范易于交接与维护以下模块划分和Java项目类似，略微有些细节差异。
1.1 api模块业务计算逻辑模块，不应该出现任何 Spark等执行框架的API 以保持模块独立性与可移植。
理论上该模块可以独立构成一个单机程序执行，这样可以将最重要的业务逻辑根据需要迁移到任意计算引擎中，如 Spark 到 Spark Streaming、Flink 甚至 Hive UDF 等。
对外只提供接口调用，不可直接在外部实例化具体类（工厂模式）所有service业务逻辑需要有对应的测试用例事务控制、所有异常捕获和处理依赖common1.2 common模块项目内通用的常量、枚举、POJO实体类、工具函数等，视情况分离，可集成到 context 中

以上关于本文的内容，仅作参考！温馨提示：如遇健康、疾病相关的问题，请您及时就医或请专业人士给予相关指导!

「四川龙网」www.sichuanlong.com小编还为您精选了以下内容，希望对您有所帮助：