大数据技术学习带来的思考

本文涉及的产品
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 大数据技术可分类如下:存储计算资源管理

技术场景


1.png


大数据技术可分类如下:


存储

计算

资源管理


HDFS


最基本的存储技术。日常应用把通过各种渠道得到的数据,如关系数据库、日志、埋点、爬虫数据都存储到HDFS,供后续使用。


HBase


NoSQL英杰,可划分到存储类别,它的底层存储也用到HDFS。


主要用途


某些场景代替MySQL数据存储访问,利用可伸缩特性,存储比MySQL多得多的数据量。


比如滴滴司机每隔几s就将当前GPS数据上传,而滴滴司机数量号称千万,每天会产生数百亿GPS数据,滴滴选择将这样海量的数据存储在HBase,当订单行程结束时,会从HBase读取订单行程期间的GPS轨迹数据,计算路程和车费。


大数据计算框架最早MapReduce,目前Spark用的最多。但直接写MapReduce或Spark程序机会不多,通常用Hive或Spark SQL大数据仓库工具进行大数据分析和计算。


MapReduce、Spark、Hive、Spark SQL主要解决离线大数据计算,针对历史数据进行计算分析,比如针对一天的历史数据计算,一天的数据是一批数据,也叫批处理计算。


Storm、Spark Streaming、Flink这类的大数据技术是针对实时的数据进行计算,比如摄像头实时采集的数据、实时的订单数据等,数据实时流动进来,也叫流处理大数据技术。


批处理、流处理计算都需庞大计算资源,需要将计算任务分布到一个大规模的服务器集群上。如何管理这些服务器集群的计算资源,如何对一个计算请求进行资源分配,这就是大数据集群资源管理框架Yarn的主要作用。各种大数据计算引擎,不管是批处理还是流处理,都能通过Yarn来资源分配,运行在一个集群中。


所以上面所有这些技术在实际部署的时候,通常会部署在同一个集群中,也就是说,在由很多台服务器组成的服务器集群中,某台服务器可能运行着HDFS的DataNode进程,负责HDFS的数据存储;同时也运行着Yarn的NodeManager,负责计算资源的调度管理;而MapReduce、Spark、Storm、Flink这些批处理或者流处理大数据计算引擎则通过Yarn的调度,运行在NodeManager的容器(container)里面。至于Hive、Spark SQL这些运行在MapReduce或者Spark基础上的大数据仓库引擎,在经过自身的执行引擎将SQL语句解析成MapReduce或者Spark的执行计划以后,一样提交给Yarn去调度执行。


这里相对比较特殊的是HBase,作为一个NoSQL存储系统,HBase的应用场景是满足在线业务数据存储访问需求,通常是OLTP(在线事务处理)系统的一部分,为了保证在线业务的高可用和资源独占性,一般是独立部署自己的集群,和前面的Hadoop大数据集群分离部署。


人生感悟

王小波说:“我活在世上,无非想要明白些道理,遇见些有趣的人,做一些有趣的事。倘能如我所愿,我的一生就算成功。”不一定要出人头地才叫成功,我能把自己的一生过得有趣、好玩,就算没白活。


但是如果简单的把好玩、有趣理解成自得其乐、不思进取,这样的生活肯定是有问题的。看王小波的其他文章就会明白,这个好玩、有趣也不是一件容易的事,没有一定的知识、见识,没有有深度的思考,没有经历过足够的困难、挫折,就根本不能理解哪些是真正好玩、有趣的人和事。


所以你必须还是要努力拼搏、锐意进取,然后在这个过程中才能真正明白一些道理,并且会遇到一些有趣的人。“我只愿蓬勃生活在此时此刻,无所谓去哪,无所谓见谁。那些我将要去的地方,都是我从未谋面的故乡。以前是以前,现在是现在。我不能选择怎么生,怎么死;但我能决定怎么爱,怎么活。”


想通了这一点后,就不再纠结自己是不是足够的优秀,能够成就什么样的事业。我只要每天都有一点点进步,明白一点点道理,生活就是值得的。所以毕业以后我觉得编程好玩,就去自学编程;觉得自己学得差不多了,就去找了一份程序员的工作;觉得缺乏创造、不断重复的程序员工作并不好玩,就去考计算机专业的研究生;后来又去北京、杭州、上海不同的城市生活;去阿里巴巴、Intel、创业公司等不同的公司去工作;期间遇到过很多有趣的人,跟很多聪明的人合作,明白了一些道理,也做过一些有趣的事。


能不能把这些技巧提炼出来,让大家一起用,所以看到《敏捷软件开发:原则、模式与实践》这本书的时候,非常激动。《敏捷软件开发》这本书把设计模式上升到设计思想的高度,书中说“软件设计不应该是面向需求设计,而应该是面向需求变更设计”,也就是说在设计的时候,主要要考虑的是当需求变更的时候,如何用最小的代价实现变更。优秀的工程师不应该害怕需求变更,而应该欢迎需求变革,因为优秀的工程师已经为需求变更做好了设计,如果没有需求变更,那就显示不出自己和只会重复的平庸工程师的区别。这就非常有意思了。


因为比较关注设计,并且后来又做了一些架构设计、框架和工具开发的工作,也因此我看到《企业应用架构模式》这本书的时候特别震撼。当时自己觉得能够做框架、工具的开发很了不起,能够做架构设计、指导其他工程师开发挺厉害,但是看了《企业应用架构模式》这本书,才发现我做的这些事情只不过是在更大的领域解决方案、架构模式里非常小的一个部分,同类的东西还有很多。当时我感觉自己真的是坐井观天、夜郎自大,也非常羞愧。


如果感觉《敏捷软件开发》的作者Bob大叔、《企业应用架构模式》的作者Martin Fowler比自己牛太多还没有太多感觉,因为毕竟隔得太远、没有交集,所以触动还不是特别大,那么后来在工作中遇到被高手全方位碾压的时候,就真正的感受到:生活还真是有意思呢。


如果你也有和我一样有过类似的困惑,不知该如何面对理想和现实之间的差距,希望我的经验可以给你一些启发。人类的进步是因为人们对美的不懈追求,而有趣也是美的一种,追逐有趣就是在追求进步,而一点一滴的进步终会引领我们实现自己的人生价值和目标。


淘宝高级技术专家李鼎聊过流式业务架构重构的心得体会

数据流是久经考验的典型思路,在网络协议(如TCP)、数据平台这样场景,早就应用多年习以为常了。淘宝业务的应用架构升级可以认为是把这样思路应用到了业务系统开发中,把「流g作为业务表达上的一等概念和手段,并在业务架构/系统能力优化提升。简单地说,因为业务面向数据流来编写,一方面业务逻辑表达可以自然接近业务流程;另一方面逻辑运行可以是全异步有很好的性能提升,一核心后端应用在双11线.上,单机QPS提升30%,RT下降40%。流程的表达与异步/同步执行方式是分离的(如果了解过像RxJava,这句会容易理解: )。


另外,流也为业务系统的保护提供新的一些方法,在思路上其实和流计算平台是一样

的,这对业务大型系统的稳定性来非常重要。当然,业务的流式架构,在业务编写上有些

FP风格(简单地说比如充分使用了Lambda),平时我们大家业务,上主要是用命令式顺序平铺方式来表达,会有要个熟悉过程,虽然不见得有多难:)


其他的一些思考

比如机器学习,可能有很多人和我有同感,基本上是从入门到放弃。我自己也思考了

原因。主要是恐惧心态,因为数学差,恐惧那些数学公式,而现在又崇尚几十天学会xxx,

这会让人更加焦虑,更不能静下心学习。所以我认为解决问题主要根本也就是调整心态,想

象学数学公式就像谈恋爱,从陌生到熟悉,再到走入婚姻的殿堂,不是一蹴而就,罗马不是一天建成的。所以公式一遍看不懂就看两遍,三遍,刻意练习,逃离舒适区。念念不忘,必

有回响!


很多人还是”面向工具“学习,对层出不穷的”工具“,感到困惑。但归根结底,这些工具本身还是计算机科学中很多基础概念的具象化,因此,”面向思想“学习应

该是更好的一种做法。先对一种最原始的实现透彻的研究,理解其背后的思想和设计理念,然后再逐步学习后期更为先进的技术,这种学习路径应该更为有效。


工作中,一个新的方案出现时,如果它在某个或某些方面优于当前最好方案,我- -定会

去思考它的catch(另一面)是什么?比如新方案更快,我就大概会看看它的空间使用率、可

维护度、全面度。一般都会发现一些问题。生活里也是如此,对表面.上只有好处而无需付出或者代价很低的东西永远保持警惕。说白了,世上没有免费的午餐,都是权衡利弊的结果。


常见的产品经理:


经常说,这是客户的要求必须马上改,用客户来压制研发


比较以自我为中心,把自己的观点等同于用户的观点。常常想当然,结果用户一看不是我想要的。结果就是开发人员一次次的从坑里刚爬上来,又被产品一脚踹下去。


不管解决技术问题,还是设计产品都需要深刻的洞察力。遇到问题先猫在后面(虽然这种方式比较猥琐),冷静思考,暗中观察,从别人的方案或者错误中总结发现规律,然后顺势而为。

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
目录
相关文章
|
2月前
|
存储 机器学习/深度学习 SQL
大数据处理与分析技术
大数据处理与分析技术
184 2
|
2月前
|
存储 分布式计算 NoSQL
【赵渝强老师】大数据技术的理论基础
本文介绍了大数据平台的核心思想,包括Google的三篇重要论文:Google文件系统(GFS)、MapReduce分布式计算模型和BigTable大表。这些论文奠定了大数据生态圈的技术基础,进而发展出了Hadoop、Spark和Flink等生态系统。文章详细解释了GFS的架构、MapReduce的计算过程以及BigTable的思想和HBase的实现。
153 0
|
1月前
|
分布式计算 大数据 数据处理
技术评测:MaxCompute MaxFrame——阿里云自研分布式计算框架的Python编程接口
随着大数据和人工智能技术的发展,数据处理的需求日益增长。阿里云推出的MaxCompute MaxFrame(简称“MaxFrame”)是一个专为Python开发者设计的分布式计算框架,它不仅支持Python编程接口,还能直接利用MaxCompute的云原生大数据计算资源和服务。本文将通过一系列最佳实践测评,探讨MaxFrame在分布式Pandas处理以及大语言模型数据处理场景中的表现,并分析其在实际工作中的应用潜力。
82 2
|
1月前
|
SQL 运维 大数据
轻量级的大数据处理技术
现代大数据应用架构中,数据中心作为核心,连接数据源与应用,承担着数据处理与服务的重要角色。然而,随着数据量的激增,数据中心面临运维复杂、体系封闭及应用间耦合性高等挑战。为缓解这些问题,一种轻量级的解决方案——esProc SPL应运而生。esProc SPL通过集成性、开放性、高性能、数据路由和敏捷性等特性,有效解决了现有架构的不足,实现了灵活高效的数据处理,特别适用于应用端的前置计算,降低了整体成本和复杂度。
|
2月前
|
机器学习/深度学习 存储 大数据
在大数据时代,高维数据处理成为难题,主成分分析(PCA)作为一种有效的数据降维技术,通过线性变换将数据投影到新的坐标系
在大数据时代,高维数据处理成为难题,主成分分析(PCA)作为一种有效的数据降维技术,通过线性变换将数据投影到新的坐标系,保留最大方差信息,实现数据压缩、去噪及可视化。本文详解PCA原理、步骤及其Python实现,探讨其在图像压缩、特征提取等领域的应用,并指出使用时的注意事项,旨在帮助读者掌握这一强大工具。
135 4
|
2月前
|
机器学习/深度学习 存储 大数据
云计算与大数据技术的融合应用
云计算与大数据技术的融合应用
|
2月前
|
SQL 存储 大数据
单机顶集群的大数据技术来了
大数据时代,分布式数仓如MPP成为热门技术,但其高昂的成本让人望而却步。对于多数任务,数据量并未达到PB级,单体数据库即可胜任。然而,由于SQL语法的局限性和计算任务的复杂性,分布式解决方案显得更为必要。esProc SPL作为一种开源轻量级计算引擎,通过高效的算法和存储机制,实现了单机性能超越集群的效果,为低成本、高效能的数据处理提供了新选择。
|
2月前
|
SQL 存储 算法
比 SQL 快出数量级的大数据计算技术
SQL 是大数据计算中最常用的工具,但在实际应用中,SQL 经常跑得很慢,浪费大量硬件资源。例如,某银行的反洗钱计算在 11 节点的 Vertica 集群上跑了 1.5 小时,而用 SPL 重写后,单机只需 26 秒。类似地,电商漏斗运算和时空碰撞任务在使用 SPL 后,性能也大幅提升。这是因为 SQL 无法写出低复杂度的算法,而 SPL 提供了更强大的数据类型和基础运算,能够实现高效计算。
|
2月前
|
存储 大数据 定位技术
大数据 数据索引技术
【10月更文挑战第26天】
82 3
|
2月前
|
存储 大数据 OLAP
大数据数据分区技术
【10月更文挑战第26天】
108 2

热门文章

最新文章