大数据技术框架有哪些类型？大数据技术栈包括哪些框架？
写在前面
本文隶属于专栏《100个问题搞定大数据理论体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！
本专栏目录结构和文献引用请见100个问题搞定大数据理论体系
解答
从数据在信息系统中的生命周期看，大数据从数据源开始，经过分析、挖掘到最终获得价值一般需要经过6个主要环节，包括数据收集、数据存储、资源管理与服务协调、计算引擎、数据分析和数据可视化，技术体系如图所示。
补充
大数据处理的不同环节都将面临不同程度的挑战
数据收集层
数据收集层由直接跟数据源对接的模块构成，负责将数据源中的数据近实时或实时收集到一起。
数据源具有分布式、异构性、多样化及流式产生等特点:
- 分布式:数据源通常分布在不同机器或设备上，并通过网络连接在一起。
- 异构性:任何能够产生数据的系统均可以称为数据源，比如Web服务器、数据库、传感器、手环、视频摄像头等。
- 多样化:数据的格式是多种多种多样的，既有像用户基本信息这样的关系型数据， 也有如图片、音频和视频等非关系型数据。
- 流式产生:数据源如同“水龙头”一样，会源源不断地产生“流水”(数据)，而数据收集系统应实时或近实时地将数据发送到后端，以便及时对数据进行分析。
由于数据源具有以上特点，将分散的数据源中的数据收集到一起通常是一件十分困难的事情。一个适用于大数据领域的收集系统，一般具备以下几个特点:
- 扩展性:能够灵活适配不同的数据源，并能接入大量数据源而不会产生系统瓶颈口可靠性:数据在传输过程中不能够丢失(有些应用可容忍少量数据丢失)。
- 安全性:对于一些敏感数据，应有机制保证数据收集过程中不会产生安全隐患。
- 低延迟:数据源产生的数据量往往非常庞大，收集系统应该能够在较低延迟的前提下将数据传输到后端存储系统中。
为了让后端获取全面的数据，以便进行关联分析和挖掘，通常我们建议将数据收集到个中央化的存储系统中。
数据存储层
数据存储层主要负责海量结构化与非结构化数据的存储。传统的关系型数据库(比如MYSQL)和文件系统(比如Linux文件系统)因在存储容量、扩展性及容错性等方面的限制，很难适应大数据应用场景。
在大数据时代，由于数据收集系统会将各类数据源源不断地发到中央化存储系统中这对数据存储层的扩展性、容错性及存储模型等有较高要求，总结如下:
- 扩展性:在实际应用中，数据量会不断增加，现有集群的存储能力很快将达到上限， 此时需要增加新的机器扩充存储能力，这要求存储系统本身具备非常好的线性扩展能力。
- 容错性:考虑到成本等因素，大数据系统从最初就假设构建在廉价机器上，这就要求系统本身就有良好的容错机制确保在机器出现故障时不会导致数据丢失。
- 存储模型:由于数据具有多样性，数据存储层应支持多种数据模型，确保结构化和非结构化的数据能够很容易保存下来。
资源管理与服务协调层
随着互联网的高速发展，各类新型应用和服务不断出现。在一个公司内部，既存在运行时间较短的批处理作业，也存在运行时间很长的服务，为了防止不同应用之间相互干扰传统做法是将每类应用单独部署到独立的服务器上。
该方案简单易操作，但存在资源利用率低、运维成本高和数据共享困难等问题。
为了解决这些问题，公司开始尝试将所有这些应用部署到一个公共的集群中，让它们共享集群的资源，并对资源进行统一使用，同时采用轻量级隔离方案对各个应用进行隔离，因此便诞生了轻量级弹性资源管理平台，相比于“一种应用一个集群”的模式，引入资源统一管理层可以带来众多好处
- 资源利用率高:如果每个应用一个集群，则往往由于应用程序数量和资源需求的不均衡，使得在某段时间内有些应用的集群资源紧张，而另外一些集群资源空闲。共享集群模式通过多种应用共享资源，使得集群中的资源得到充分利用。
- 运维成本低:如果采用“一个应用一个集群”的模式，则可能需要多个管理员管理这些集群，进而增加运维成本。而共享模式通常需要少数管理员即可完成多个框架的统一管理。
- 数据共享:随着数据量的暴增，跨集群间的数据移动不仅需花费更长的时间，且硬件成本也会大大增加，而共享集群模式可让多种应用共享数据和硬件资源，这将大大减小数据移动带来的成本。
在构建分布式大数据系统时，会面临很多共同的问题，包括leader选举、服务命名、分布式队列、分布式锁、发布订阅功能等，
为了避免重复开发这些功能，通常会构建一个统一的服务协调组件，包含了开发分布式系统过程中通用的功能。
计算引擎层
在实际生产环境中，针对不同的应用场景，我们对数据处理的要求是不同的，有些场景下，只需离线处理数据，对实时性要求不高，但要求系统吞吐率高，典型的应用是搜索引擎构建索引;有些场景下，需对数据进行实时分析，要求每条数据处理延迟尽可能低， 典型的应用是广告系统及信用卡欺诈检测。
为了解决不同场景下数据处理问题，起初有人尝试构建一个大统一的系统解决所有类型的数据计算问题，但最终以失败告终。
究其原因， 主要是因为不同类型的计算任务，其追求的目标是不同的，批处理计算追求的是高吞吐率， 而实时计算追求的是低延迟。
在现实系统中，系统吞吐率和处理延迟往往是矛盾的两个优化方向:系统吞吐率非常高时，数据处理延迟往往也非常高，基于此，用一个系统完美解决所有类型的计算任务是不现实的。
计算引擎发展到今天，已经朝着“小而美”的方向前进，即针对不同应用场景，单独构建一个计算引擎，每种计算引擎只专注于解决某一类问题，进而形成了多样化的计算引擎。
计算引擎层是大数据技术中最实时处理交互式处理批处理活跃的一层，直到今天，仍不断有新的计算引擎被提出。
总体上讲，可按照对时间性能的要求，将计算引擎分为三类:
- 批处理:该类计算引擎对时间要求最低，一般处理时间为分钟到小时级别，甚至天级别，它追求的是高吞吐率，即单位时间内处理的数据量尽可能大，典型的应用有搜索引擎构建索引、批量数据分析等。
- 交互式处理:该类计算引擎对时间要求比较高，一般要求处理时间为秒级别，这类系统需要跟人进行交互，因此会提供类SQL的语言便于用户使用，典型的应用有数据查询、参数化报表生成等。
- 实时处理:该类计算引擎对时间要求最高，一般处理延迟在秒级以内，典型的应用有广告系统、舆情监测等。
数据分析层
数据分析层直接跟用户应用程序对接，为其提供易用的数据处理工具。为了让用户分析数据更加容易，计算引擎会提供多样化的工具，包括应用程序API、类SQL査询语言数据挖掘SDK等。
在解决实际问题时，数据科学家往往需根据应用的特点，从数据分析层选择合适的工具，大部分情况下，可能会结合使用多种工具。
典型的使用模式是:首先使用批处理框架对原始海量数据进行分析，产生较小规模的数据集，在此基础上，再使用交互式处理工具对该数据集进行快速查询，获取最终结果。
数据可视化层
数据可视化技术指的是运用计算机图形学和图像处理技术，将数据转换为图形或图像在屏幕上显示出来，并进行交互处理的理论、方法和技术。
它涉及计算机图形学、图像处理、计算机辅助设计、计算机视觉及人机交互技术等多个领域。
数据可视化层是直接面向用户展示结果的一层，由于该层直接对接用户，是展示大数据价值的“门户”，因此数据可视化是极具意义的。
考虑到大数据具有容量大、结构复杂和维度多等特点，对大数据进行可视化是极具挑战性的。
大数据技术栈
随着大数据开源技术的快速发展，目前开源社区已经积累了比较完整的大数据技术栈， 应用最广泛的是以Hadoop与Spark为核心的生态系统，具体如图所示，整个大数据技术栈涉及数据收集、数据存储、资源管理与服务协调、计算引擎和数据分析这五个层级。
详情请见我的另一篇专栏——1000个问题搞定大数据技术体系