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，以便我们开发相关应用及阅读源码等。