大数据平台的毕业设计02:Spark与实时计算

本文涉及的产品
实时计算 Flink 版,1000CU*H 3个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 大数据平台的毕业设计02:Spark与实时计算

Spark、Kafka - 实时计算

现在提到实时计算,可能大家首先会想到flink。的确,flink在开源实时领域方面绝对算是TOP了。18年的时候,实时处理还是SparkStreaming应用的比较广泛。所以当时我安装的是Spark集群,来模拟的实时计算。

其实Spark/flink集群都是可以不搭建的,在Spark集群上运行程序属于standlone模式,如果使用yarn模式只需要有客户端就可以了。Spark程序运行在yarn上,能对cpu和内存进行资源隔离,而且不需要要单独维护一个Spark集群。

而作为实时处理配套,Kafka和Rabbitmq之间我还是倾向于Kafka。在Kafka搭建之前,先搭建zookeeper集群,zk是kafka的依赖组件,用来记录一些元数据。

下图命令操作就是消费写入Kafka的数据。

image.png

我们要做的就是将数据库/数据仓库中的离线数据,转换为数据流(Data Stream),作为生产者实时写入到Kafka中。

我们开发的Spark/flink程序作为消费者实时读取Kafka中的数据,实时处理并数据计算结果。如下图,为SparkStreaming的程序监控页面。

image.png

image.png

image.png

SparkStreming程序,可以使用Java、Scala、Python开发,但是选择Scala比较好一些。一是Scala的语法结构更贴合流式处理,二是源码都是Scala写的。

Flume - 数据交换神器

当初刚接触Flume的时候,真的没玩明白,云里雾里的。后来深入研究了一下之后,数据在oracle、MySQL、Kafka、HDFS以及其他存储平台上,就可以进行同步。不过MySQL和oracle需要自己定义Source和Sink。

Flume的简单之处在于配置化。当初我将数据从MySql抽取到Kafka,部分配置如下。

image.png

顺带一提,在大数据量的情况下,Flume很多参数还是需要调的。当初我将1W亿/天的数据从Kafka落地到HDFS的时候,写了几千行的配置,调了很多参数。

3. 数据展示

最后就是前台的数据展示了,使用了Springboot和Vue做了一个POI数据管理系统。主要实现分类查询和POI搜索标点地图展示功能。

但是这个系统,我只找到了登录页面和地图搜索标点的截图了....

image.png

image.png

数据管理系统发挥的空间还是挺多的,比如页面样式的优化,再比如前台可以使用Node + Vue,后端使用Springboot来实现前后端分离架构。

结语

主要是给大家提供一个大数据平台毕业设计的基本思路,很多细节的地方还可以优化。我们也不难发现,这里的大数据集群都是独立安装的,我们同样可以使用Ambari进行统一的安装、管理、启动、状态监控。

最近也是在研究Ambari,前几周刚花了一个星期,完成了Ambari2.7.5的编译安装工作。后期的目标是配合docker在一台机器上完成大数据集群的搭建工作,当然这里主要是玩,构建测试环境,性能啥的就不要考虑了哈。

忙完这一阵,完成Scrapy系列文章,就开始着手准备大数据平台系列文章的编写。期待下一次相遇。


相关文章
|
3月前
|
人工智能 分布式计算 大数据
大数据≠大样本:基于Spark的特征降维实战(提升10倍训练效率)
本文探讨了大数据场景下降维的核心问题与解决方案,重点分析了“维度灾难”对模型性能的影响及特征冗余的陷阱。通过数学证明与实际案例,揭示高维空间中样本稀疏性问题,并提出基于Spark的分布式降维技术选型与优化策略。文章详细展示了PCA在亿级用户画像中的应用,包括数据准备、核心实现与效果评估,同时深入探讨了协方差矩阵计算与特征值分解的并行优化方法。此外,还介绍了动态维度调整、非线性特征处理及降维与其他AI技术的协同效应,为生产环境提供了最佳实践指南。最终总结出降维的本质与工程实践原则,展望未来发展方向。
189 0
|
3月前
|
人工智能 分布式计算 DataWorks
一体系数据平台的进化:基于阿里云 EMR Serverless Spark 的持续演进
本文介绍了一体系汽配供应链平台如何借助阿里云EMR Serverless Spark实现从传统Hadoop平台向云原生架构的迁移。通过融合高质量零部件供应与创新互联网科技,一体系利用EMR Serverless Spark和DataWorks构建高效数据分析体系,解决大规模数据处理瓶颈。方案涵盖实时数据集成、Lakehouse搭建、数仓分层设计及BI/ML应用支持,显著提升数据处理性能与业务响应速度,降低运维成本,为数字化转型奠定基础。最终实现研发效率提升、运维压力减轻,并推动AI技术深度整合,迈向智能化云原生数据平台。
140 4
|
6月前
|
存储 分布式计算 Hadoop
从“笨重大象”到“敏捷火花”:Hadoop与Spark的大数据技术进化之路
从“笨重大象”到“敏捷火花”:Hadoop与Spark的大数据技术进化之路
286 79
|
10月前
|
分布式计算 大数据 Apache
ClickHouse与大数据生态集成:Spark & Flink 实战
【10月更文挑战第26天】在当今这个数据爆炸的时代,能够高效地处理和分析海量数据成为了企业和组织提升竞争力的关键。作为一款高性能的列式数据库系统,ClickHouse 在大数据分析领域展现出了卓越的能力。然而,为了充分利用ClickHouse的优势,将其与现有的大数据处理框架(如Apache Spark和Apache Flink)进行集成变得尤为重要。本文将从我个人的角度出发,探讨如何通过这些技术的结合,实现对大规模数据的实时处理和分析。
671 2
ClickHouse与大数据生态集成:Spark & Flink 实战
|
8月前
|
SQL 存储 大数据
Flink 基础详解:大数据处理的强大引擎
Apache Flink 是一个分布式流批一体化的开源平台,专为大规模数据处理设计。它支持实时流处理和批处理,具有高吞吐量、低延迟特性。Flink 提供统一的编程抽象,简化大数据应用开发,并在流处理方面表现卓越,广泛应用于实时监控、金融交易分析等场景。其架构包括 JobManager、TaskManager 和 Client,支持并行度、水位线、时间语义等基础属性。Flink 还提供了丰富的算子、状态管理和容错机制,如检查点和 Savepoint,确保作业的可靠性和一致性。此外,Flink 支持 SQL 查询和 CDC 功能,实现实时数据捕获与同步,广泛应用于数据仓库和实时数据分析领域。
4333 32
zdl
|
10月前
|
消息中间件 运维 大数据
大数据实时计算产品的对比测评:实时计算Flink版 VS 自建Flink集群
本文介绍了实时计算Flink版与自建Flink集群的对比,涵盖部署成本、性能表现、易用性和企业级能力等方面。实时计算Flink版作为全托管服务,显著降低了运维成本,提供了强大的集成能力和弹性扩展,特别适合中小型团队和业务波动大的场景。文中还提出了改进建议,并探讨了与其他产品的联动可能性。总结指出,实时计算Flink版在简化运维、降低成本和提升易用性方面表现出色,是大数据实时计算的优选方案。
zdl
419 56
|
10月前
|
SQL 机器学习/深度学习 分布式计算
Spark快速上手:揭秘大数据处理的高效秘密,让你轻松应对海量数据
【10月更文挑战第25天】本文全面介绍了大数据处理框架 Spark,涵盖其基本概念、安装配置、编程模型及实际应用。Spark 是一个高效的分布式计算平台,支持批处理、实时流处理、SQL 查询和机器学习等任务。通过详细的技术综述和示例代码,帮助读者快速掌握 Spark 的核心技能。
465 6
|
10月前
|
存储 分布式计算 Hadoop
数据湖技术:Hadoop与Spark在大数据处理中的协同作用
【10月更文挑战第27天】在大数据时代,数据湖技术凭借其灵活性和成本效益成为企业存储和分析大规模异构数据的首选。Hadoop和Spark作为数据湖技术的核心组件,通过HDFS存储数据和Spark进行高效计算,实现了数据处理的优化。本文探讨了Hadoop与Spark的最佳实践,包括数据存储、处理、安全和可视化等方面,展示了它们在实际应用中的协同效应。
442 2
|
10月前
|
存储 分布式计算 Hadoop
数据湖技术:Hadoop与Spark在大数据处理中的协同作用
【10月更文挑战第26天】本文详细探讨了Hadoop与Spark在大数据处理中的协同作用,通过具体案例展示了两者的最佳实践。Hadoop的HDFS和MapReduce负责数据存储和预处理,确保高可靠性和容错性;Spark则凭借其高性能和丰富的API,进行深度分析和机器学习,实现高效的批处理和实时处理。
392 1
|
10月前
|
分布式计算 Java 开发工具
阿里云MaxCompute-XGBoost on Spark 极限梯度提升算法的分布式训练与模型持久化oss的实现与代码浅析
本文介绍了XGBoost在MaxCompute+OSS架构下模型持久化遇到的问题及其解决方案。首先简要介绍了XGBoost的特点和应用场景,随后详细描述了客户在将XGBoost on Spark任务从HDFS迁移到OSS时遇到的异常情况。通过分析异常堆栈和源代码,发现使用的`nativeBooster.saveModel`方法不支持OSS路径,而使用`write.overwrite().save`方法则能成功保存模型。最后提供了完整的Scala代码示例、Maven配置和提交命令,帮助用户顺利迁移模型存储路径。

热门文章

最新文章