2023 年大数据个人技术能力提升心得体会|社区征文

2023总结大数据

一、开始

2023年马上就接近尾声了,在这一年中大数据的技术组件也有很大的变化,很多技术趋于成熟,通过这一年的大数据技术能力的持续学习,深入理解,总结了一下大数据学习方式,也作为个人2023年技术总结与大家分享。

二、大数据处理流程

从 2008 年 Hadoop 成为 Apache 顶级项目开始,大数据迎来了体系化的快速发展,到如今已经走过十几个年头,这些年里大数据框架层出不穷,可以用“乱花渐欲迷人眼”形容,框架这么多,应该怎么学?

其实学大数据框架,最终还是要用到实际项目业务中的,我们梳理下实际大数据项目开发的整个流程,把这些流程中涉及到的技术,框架学会即可。

首先第一步是获取数据,也叫数据采集,只有把数据放到大数据平台,我们才能进行后面的操作,那么都获取哪些数据呢,无非就下面这几种:

  • 第一:业务库中的数据,比如存储用户信息的,订单信息的数据。这些数据一般都是存在关系型数据库如MySql中。

  • 第二:日志数据,日志数据包括,埋点的数据和系统产生的日志数据,埋点数据就是存储 哪个用户在什么时间什么地点,点击了平台上的什么按钮等等这类的数据,因为这类数据比较多,并且一般都比较杂乱,所以就不存在数据库中,直接存在文本文件中。

  • 第三:爬虫数据,有些数据对我们很重要,但是自己系统上没有,那么获取这些数据要么采购,要么直接爬取网上的数据。

同步这些数据到大数据平台怎么同步呢,数据少那就每天把表全部导入一遍,这叫全量同步;数据特别大,就只同步每天变化和新增的,这是增量同步。

第二步就是存储数据,数据采集过来之后,我们肯定要先存下来,但是我们采集的数据非常多,如果只存一台服务器上肯定不行,那么就得存在多台服务器上,采用分布式存储。

第三步处理数据,数据只存储也没什么用啊,最终我们还是要对存储的这些数据进行分析处理的,但是那么大的数据量,我们怎么能快速的分析这些数据呢,还是得采用分布式处理,也就是让多台服务器一块处理。

第四步数据应用,数据分析处理完成之后,那么就可以提供服务了,可以把处理好的数据,做成报表,通过数据分析业务;或者再推给业务系统用;也可以给数据挖掘、机器学习、人工智能等领域用。

第五步任务调度,上述四步组成了大数据的处理流程,但它们之间有先后顺序,也就是有依赖关系,必须数据采集完成之后才能处理数据,并且不能只执行一次就算完了,数据是源源不断产生的,处理数据我们不太可能每次都手动执行,所以就有了任务调度,它可以帮助我们定时执行任务,并且也可以配置上下游依赖,任务执行失败自动重启或者告警等,这就是调度工具干的事。

其实这里面还有一个问题,比如定时从业务那边同步数据到大数据平台,多久同步一次,是一小时,还是一天,还是实时同步;业务那边产生一条数据,就立马同步过来,还是产生数据之后,一批批的同步过来,这就涉及到两个概念,批处理和流处理。批处理就是每隔多长时间处理一次,流处理就是产生一条数据,就实时同步处理一条数据,就像水流一样,源源不断处理。这两种不同的处理方式,就产生了不同的处理框架,像Spark,Flink等。

我们再思考下整个大数据的流程是什么,数据采集->数据存储->数据处理->数据应用,再加一个任务调度。每个流程都有很多对应的大数据框架,我们学习其中一两个比较重要,也就是企业用的较多的框架即可。

三、数据采集

就是把数据从其他平台采集到我们大数据平台,只是负责采集数据,所以对这个流程的框架要求是会用即可,日志采集工具如Flume,实时监听文件变化,有变化就会捕获到,并且采集过来。

大数据平台与传统的数据库(mysql、postgresql...)间进行数据的传递工具如Sqoop,Datax,我们会用即可,这种工具上手也很快,没有太复杂的功能。

上面说的Sqoop,Datax都是批量采集业务库数据,也就是离线采集;但是通常会有实时采集的需求,也就是得监听业务库的变化,只要有数据变化,就会采集过来,那么实时采集框架有哪些呢,常见的有 canal,Flink CDC,Flink CDC是集成在Flink内的一个实时数据同步工具。

四、数据存储

数据存储就比较重要了,大数据如此流行,和大规模分布式数据存储快速发展有很大关系,当然数据存储的框架也比较多,不同的框架,功能不太一样,首先第一个:Hadoop HDFS,分布式文件系统,HDFS的诞生,解决了海量数据的存储问题, HDFS的设计目标是可以在廉价的硬件上存储海量数据,并能够提供高并发性的数据访问服务。

五、数据处理

大数据最重要的环节就是数据处理了,数据处理通常分为两种:批处理和流处理。

  • 批处理:对一段时间内海量的离线数据进行统一的处理,对应的处理框架有 Hadoop MapReduce、Spark、Flink 等;

  • 流处理:对运动中的数据进行处理,即在接收数据的同时就对其进行处理,对应的处理框架有 Spark Streaming、Flink 等。

批处理和流处理各有其适用的场景,时间不敏感或者硬件资源有限,可以采用批处理;

时间敏感和及时性要求高就可以采用流处理。随着服务器硬件的价格越来越低和大家对及时性的要求越来越高,流处理越来越普遍,如股票价格预测和电商运营数据分析等。

流处理就是来一条数据处理一条,来十条处理十条,那么大家有没有想过,万一某天的某一时刻突然来了十万条,百万条,服务器一下子处理不了这么多怎么办,比如快递员每天都只给你派送一件快递,你拿到之后钱货两清。然后突然一天快递员给你送一千件到你楼下,你下楼一件一件搬,快递员还得等你搬完才能回去,这得等到啥时候。聪明的你马上想到了,放快递柜呀,你有时间慢慢搬不就行了,也不占用快递员的时间了。

这就是消息队列,Kafka 就是起这样的作用:异步、解耦、消峰。canal或cdc获取到的数据一般会抛到kafka或RocketMQ,可以保存一段时间。然后下游程序再去实时拉取消息来计算。

有些人感觉这么多流程,写这么多代码太累了,有没有简单的方法,反正就是处理数据,大部分处理逻辑用SQL就能处理,并且SQL写起来比代码简单多了。大数据是一个非常完善的生态圈,有需求就有解决方案。为了能够让熟悉 SQL 的人员也能够进行数据处理与分析,使用SQL查询分析的框架应运而生,常用的有 Hive 、Spark SQL 、Flink SQL、Phoenix 等。这些框架都能够使用标准的 SQL 或者 类 SQL 语法灵活地进行数据的查询分析。

这些 SQL 经过解析优化后转换为对应的作业程序来运行,如 Hive 本质上就是将 SQL 转换为 MapReduce 或 Spark 作业,Phoenix 将 SQL 查询转换为一个或多个 HBase Scan。

六、数据应用

处理好的数据就可以输出应用了,如可视化展示;推动业务决策分析;用于推荐算法,机器学习等。其实处理完之后的数据可以先存起来,谁想用直接从这里面取,但是数据量这么大,存储肯定得选分布式存储的数据库,并且方便查询分析。这类的框架有HBase,Doris等,HBase和Doris都是分布式数据库,它们之间也有一些区别。例如,HBase更加适用于海量的结构化数据存储和处理,而Doris则更加适用于复杂的在线分析查询(OLAP)场景。此外,它们使用的数据存储方式和底层技术也有所不同。

七、任务调度

复杂大数据处理的另外一个显著的问题是,如何调度多个复杂的并且彼此之间存在依赖关系的作业?基于这种需求,产生了 Azkaban 、Oozie、dolphinscheduler 等工作流调度框架。

同时针对集群资源管理的需求,又衍生了 Hadoop YARN,资源调度框架。集群资源管理,这个怎么理解呢,比如我们有许多任务都在集群上跑,但是有些任务优先级高,有些优先级低,有些任务并不想让它占用太大资源等等,这就需要有个针对这些资源的管理工具,Yarn就是大数据平台上非常优秀的集群管理工具。

想要保证集群高可用,需要用到 ZooKeeper ,ZooKeeper 是最常用的分布式协调服务,它能够解决大多数集群问题,包括首领选举、失败恢复、元数据存储及其一致性保证。

至此,Hadoop的三大组件集齐了,HDFS,MapReduce,Yarn,功能分别是分布式文件存储、数据处理计算和资源调度。

八、数据处理组件进化

有人就有疑问了,对于数据处理,这不是有 MapReduce 了吗,为什么后面又出现了像Spark,Flink等这类处理框架。

对于数据处理框架 MapReduce,要写Java代码,但做数据的最好的工具是什么?SQL!所以Hive相当于这一套标准流程的SQL化。

Hive可以简单理解为,Hadoop之上添加了自己的SQL解析和优化器,写一段SQL,解析为Java代码,然后去执行MR,底层数据还是在HDFS上。

这看起来挺完美,但问题是程序员发现好慢啊。原因是MR,它需要频繁写读文件。这时基于内存的Spark出现了,Spark是替代MR的,它会为SQL生成有向无环图,加上各种算子和宽窄依赖的优化,使得计算速度达到了新的高度。

但是上面这些都是处理离线数据的,那么实时数据怎么处理呢

Spark streaming 就是处理实时流数据的好手。

Spark 是一整套组件的统称,比如你可以用 Java 写 Spark 任务,用 Spark SQL 去写 SQL,可以用 Spark MLib 完成机器学习的模型训练等等,Spark Streaming 就是用来微批地处理流式数据的。

具体而言,离线数据我们是等半夜数据都抽到 Hive 中再计算,而 Spark Streaming 则是实时数据来一小批,它就处理一小批。所以本质上讲,Spark Streaming 还是批处理,只不过是每一批数据很少,并且处理很及时,从而达到实时计算的目的。

Spark 本身的流行使得 Spark Streaming 也一直大范围使用。

这一套有什么逻辑缺陷吗?

我们可以想一想,实时数据和离线数据最大的差异,是时效性。离线数据像湖水,该多少就多少,就在那里;实时数据像水流,绵绵不绝。时间,便是非常重要的一个特质。当一条数据来的时候,我们需要知道这条数据是什么时候产生的,这便是业务时间。但我们拿到这条数据时往往是业务时间之后的一小会,这边是处理时间。真正世界里的实时数据肯定不是像 Spark Streaming 那样一批一批来的,而是一个一个的事件。对此,Flink 帮助我们解决了这些问题。Flink 不同于 Spark Streaming 的微批次处理,它是一条一条数据处理的。

以上,在分析大数据处理流程中,我们把常用的框架都说了下,基本上也是大数据中最常用的框架,尽量全部掌握。

以上框架大部分是用Java写的,有部分是用Scala写的,所以我们必须掌握的语言是Java、Scala,以便我们开发相关应用及阅读源码等。

本文首发于 InfoQ 写作平台:https://xie.infoq.cn/article/9fbbc83b82b665dc11dbc5b1c

1180
14
0
1
相关产品
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论