企业级大数据技术框架

Posted 2023-03-16

大数据尝试从海量数据中，通过一定的分布式技术手段，挖掘出有价值的信息，最终提供给用户，进而产生实用价值和商业价值。

从数据在信息系统中的生命周期看，大数据从数据源开始，经过分析、挖掘到最终获得价值一般需要经过6个主要环节，包括数据收集、数据存储、资源管理与服务协调、计算引擎、数据分析和数据可视化，每个环节都面临不同程度的技术挑战。

1、数据收集层

数据收集层由直接跟数据源对接的模块构成，负责将数据源中的数据近实时或实时收集到一起。数据源具有分布式、异构性、多样化及流式产生等特点：

• 分布式：数据源通常分布在不同机器或设备上，并通过网络连接在一起。
• 异构性：任何能够产生数据的系统均可以称为数据源，比如Web服务器、数据库、传感器、手环、视频摄像头等。
• 多样化：数据的格式是多种多种多样的，既有像用户基本信息这样的关系型数据，也有如图片、音频和视频等非关系型数据。
• 流式产生：数据源如同“水龙头”一样，会源源不断地产生“流水”（数据），而数据收集系统应实时或近实时地将数据发送到后端，以便及时对数据进行分析。

由于数据源具有以上特点，将分散的数据源中的数据收集到一起通常是一件十分困难的事情。一个适用于大数据领域的收集系统，一般具备以下几个特点：

• 扩展性：能够灵活适配不同的数据源，并能接入大量数据源而不会产生系统瓶颈；
• 可靠性：数据在传输过程中不能够丢失（有些应用可容忍少量数据丢失）。
• 安全性：对于一些敏感数据，应有机制保证数据收集过程中不会产生安全隐患。
• 低延迟：数据源产生的数据量往往非常庞大，收集系统应该能够在较低延迟的前提下将数据传输到后端存储系统中。

为了让后端获取全面的数据，以便进行关联分析和挖掘，通常我们建议将数据收集到一个中央化的存储系统中。

2、数据存储层

数据存储层主要负责海量结构化与非结构化数据的存储。传统的关系型数据库（比如mysql）和文件系统（比如Linux文件系统）因在存储容量、扩展性及容错性等方面的限制，很难适应大数据应用场景。

在大数据时代，由于数据收集系统会将各类数据源源不断地发到中央化存储系统中，这对数据存储层的扩展性、容错性及存储模型等有较高要求，总结如下：

• 扩展性：在实际应用中，数据量会不断增加，现有集群的存储能力很快将达到上限，此时需要增加新的机器扩充存储能力，这要求存储系统本身具备非常好的线性扩展能力。
• 容错性：考虑到成本等因素，大数据系统从最初就假设构建在廉价机器上，这就要求系统本身就有良好的容错机制确保在机器出现故障时不会导致数据丢失。
• 存储模型：由于数据具有多样性，数据存储层应支持多种数据模型，确保结构化和非结构化的数据能够很容易保存下来。

3、资源管理与服务协调层

随着互联网的高速发展，各类新型应用和服务不断出现。在一个公司内部，既存在运行时间较短的批处理作业，也存在运行时间很长的服务，为了防止不同应用之间相互干扰，传统做法是将每类应用单独部署到独立的服务器上。该方案简单易操作，但存在资源利用率低、运维成本高和数据共享困难等问题。为了解决这些问题，开始尝试将所有这些应用部署到一个公共的集群中，让它们共享集群的资源，并对资源进行统一使用，同时采用轻量级隔离方案对各个应用进行隔离，因此便诞生了轻量级弹性资源管理平台，相比于“一种应用一个集群”的模式，引入资源统一管理层可以带来众多好处：

• 资源利用率高：如果每个应用一个集群，则往往由于应用程序数量和资源需求的不均衡，使得在某段时间内有些应用的集群资源紧张，而另外一些集群资源空闲。共享集群模式通过多种应用共享资源，使得集群中的资源得到充分利用。
• 运维成本低：如果采用“一个应用一个集群”的模式，则可能需要多个管理员管理这些集群，进而增加运维成本。而共享模式通常需要少数管理员即可完成多个框架的统一管理。
• 数据共享：随着数据量的暴增，跨集群间的数据移动不仅需花费更长的时间，且硬件成本也会大大增加，而共享集群模式可让多种应用共享数据和硬件资源，这将大大减小数据移动带来的成本。

在构建分布式大数据系统时，会面临很多共同的问题，包括leader选举、服务命名、分布式队列、分布式锁、发布订阅功能等，为了避免重复开发这些功能，通常会构建一个统一的服务协调组件，包含了开发分布式系统过程中通用的功能。

4、计算引擎层

在实际生产环境中，针对不同的应用场景，我们对数据处理的要求是不同的，有些场景下，只需离线处理数据，对实时性要求不高，但要求系统吞吐率高，典型的应用是搜索引擎构建索引；有些场景下，需对数据进行实时分析，要求每条数据处理延迟尽可能低，典型的应用是广告系统及信用卡欺诈检测。为了解决不同场景下数据处理问题，起初有人尝试构建一个大统一的系统解决所有类型的数据计算问题，但最终以失败告终。究其原因，主要是因为不同类型的计算任务，其追求的目标是不同的，批处理计算追求的是高吞吐率，而实时计算追求的是低延迟。在现实系统中，系统吞吐率和处理延迟往往是矛盾的两个优化方向：系统吞吐率非常高时，数据处理延迟往往也非常高，基于此，用一个系统完美解决所有类型的计算任务是不现实的。

针对不同应用场景，单独构建一个计算引擎，每种计算引擎只专注于解决某一类问题，进而形成了多样化的计算引擎。总体上讲，可按照对时间性能的要求，将计算引擎分为三类：

• 批处理：该类计算引擎对时间要求最低，一般处理时间为分钟到小时级别，甚至天级别，它追求的是高吞吐率，即单位时间内处理的数据量尽可能大，典型的应用有搜索引擎构建索引、批量数据分析等。
• 交互式处理：该类计算引擎对时间要求比较高，一般要求处理时间为秒级别，这类系统需要跟人进行交互，因此会提供类SQL的语言便于用户使用，典型的应用有数据查询、参数化报表生成等。
• 实时处理：该类计算引擎对时间要求最高，一般处理延迟在秒级以内，典型的应用有广告系统、舆情监测等。

5、数据分析层

数据分析层直接跟用户应用程序对接，为其提供易用的数据处理工具。为了让用户分析数据更加容易，计算引擎会提供多样化的工具，包括应用程序API、类SQL查询语言、数据挖掘SDK等。

在解决实际问题时，数据科学家往往需根据应用的特点，从数据分析层选择合适的工具，大部分情况下，可能会结合使用多种工具，典型的使用模式是：首先使用批处理框架对原始海量数据进行分析，产生较小规模的数据集，在此基础上，再使用交互式处理工具对该数据集进行快速查询，获取最终结果。

6、数据可视化层

数据可视化技术指的是运用计算机图形学和图像处理技术，将数据转换为图形或图像在屏幕上显示出来，并进行交互处理的理论、方法和技术。它涉及计算机图形学、图像处理、计算机辅助设计、计算机视觉及人机交互技术等多个领域。

数据可视化层是直接面向用户展示结果的一层，由于该层直接对接用户，是展示大数据价值的“门户”，因此数据可视化是极具意义的。考虑到大数据具有容量大、结构复杂和维度多等特点，对大数据进行可视化是极具挑战性的。

大数据技术发展回顾

2012年以前，大多数企业的数据仓库主要还是构建在关系型数据库上，例如Oracle、Mysql等数据库之上。但是随着企业数据量的增长，关系型数据库已经无法支撑大规模数据集的存储和分析，这种情况在一线互联网公司尤为明显，也是当时急需要解决的问题。

随着2012年Hadoop技术框架的成熟和稳定，一线互联网公司纷纷使用Hadoop技术栈来构建企业大数据分析平台，随后两年基于大数据的应用如雨后春笋一样涌现，比如千人千面的推荐系统、精准定向程序化交易的广告系统、互联网征信、大数据风控系统。时间到了2015年，Hadoop技术栈已然成为了建设数据仓库的首选项，对盲目跟风的企业来讲，有条件会上Hadoop集群、没有条件创造条件也要上Hadoop集群，那一年我听说过节点数最少的是一家做奢侈品的互联网公司，它们用3个物理机部署了一套数据仓库。

与此同时，随着Hadoop技术在企业大规模的深入应用，人们对Hadoop MapReduce框架越来越无法容忍，因为MapRecude在运行过程中会大量操作磁盘，对于复杂的计算任务来讲，动不动就是几个小时，甚至更长时间。然而大数据领域并没有革命性的框架来解决MapReduce慢的问题，人们只能一边抱怨一边想办法优化MapReduce的性能，然而效果并不是很理想。

直到2015年Spark技术框架的成熟，人们终于找到了替代MapReduce的新选择，这是一个将数据放到内存中计算的新框架，是一个比MapReduce快100倍的计算框架，对于拥有大数据量的企业来讲，真的是久旱逢甘霖，大家一股脑的冲进了Spark的怀抱，至此，大数据数据处理开了Spark时代。

有必要一提的是，Spark除了替代MapReduce以外，还带来了Spark Streaming，专门用来解决流式（实时）计算的问题。虽然当时市场有Apache Storm/Alibaba Jstorm等成熟的流式计算框架，但很快被Spark Streaming淘汰了，个人觉得打败Storm的主要原因就是Spark Streaming提高了数据处理的吞吐量和Spark on yarn的运行方式（Storm需要单独部署一套集群）。

时间到了2018年，Spark迎来了新的挑战者，那就是Apache Flink。Apache Flink与生俱来的流式计算处理能力，大大提高了数据处理的实效性，除了实效性的提升，Apache Flink还实现了exactly-once语义（一条数据只处理一次）、State管理。

作为计算领域最先进的技术框架，Apache Flink一路攻城拔寨，气势如虹。随着2018年年底阿里巴巴收购Flink的母公司，Flink China在中国开始了大规模的Flink技术推广。唾手可得中文文档、深入浅出公开视频、阿里巴巴的最佳实践，加快了Flink技术在中国市场的迅猛落地。

到了2019年的今天，人们出门必谈Flink，如同2015年，那时人们出门必谈Spark。

面对技术的快速迭代，不禁唏嘘，虽然MapReduce拼命的完善自己的生态，但是面对Spark的到来，依然毫无一战之力。同样，即使Spark生态圈已经如此完善，覆盖了离线计算、实时计算、机器学习、图计算等等诸多领域，面对Flink的到来，也在节节败退。

相对MapReduce基于磁盘的计算模式，Spark基于内存的计算方式是革命性的创新；相对Spark批量/微批的计算模式，Flink使用了流式计算的模式贴近了数据产生的本源；在它们各自的时代里，它们都代表了先进的生产力，都是以摧枯拉朽之势，雷霆万钧之力击垮对手。然而面对新的技术革新，它们都是那么弱小，不禁想起了刘慈欣《三体》中的有一句话，毁灭你，与你何干？