一、开始
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