我当下的工作是大数据安全领域。大数据和云计算有些类似,既是技术,也是商业。我想利用十几篇笔记规模,对大数据的技术体系进行一个总结,同时也希望能作为公司内部培训交流所用。
笔记中的不少知识点来自于下面这本书,推荐给大家。
第一章:企业级大数据技术框架
一般情况下,数据进入大数据平台后,需要经历如下几个阶段:
- 数据采集
- 数据存储
- 资源管理与服务协调
- 计算引擎
- 数据分析
- 数据可视化
一、每个阶段都存在特定的要求,也面临着不同的技术挑战。
1. 数据采集
数据采集层直接跟数据源对接,负责将数据源中的数据实时或准实时收集起来。而数据源有如下的特点:
- 分布式:数据源通常分布在不同设备上,通过网络进行连接
- 异构性:任何能够产生数据的系统均可以称为数据源,如Web服务器、数据库、传感器、手环、监控摄像头等
- 多样化:数据格式多种多样,结构化数据,半结构化数据、非结构化数据
- 多方式:有的数据源如同“集装箱”,将数据批量送达;有的数据源如同“水龙头”,以“流水”的方式将数据实时或准实时地将数据送达
由于数据源存在上述特点,良好的数据采集系统需要考虑如下因素:
- 扩展性:能够灵活适配不同类型的数据源,要能提供高并发性
- 可靠性:数据在传输过程中不能丢失
- 安全性:对于一些敏感数据的采集,要考虑数据隐私性保护
- 低延迟:需要能在较低延迟下将数据传输到后端存储系统中
2. 数据存储
在大数据时代,采集到的海量数据既有结构化数据,也有非结构化数据,如果沿用传统的关系型数据库(如MySQL)和文件系统(如Linux文件系统),在存储容量、扩展性及容错性等方面都存在挑战:
- 扩展性:大数据平台海量数据要求存储系统本身具备良好的线性扩展能力
- 容错性:大数据系统天然设构建在廉价机器上,这就要求系统本身就有良好的容错机制,确保在机器出现故障时不会导致数据丢失
- 存储模型:数据的多样性要求数据存储层应支持多种数据模型
3. 资源管理与服务协调
大数据平台为了解决资源利用率低、运维成本高和数据共享困难等问题,将应用集中存储在公共服务器集群中,这样的分布式系统,会面临很多共性问题,如leader选举、服务命名、分布式队列、分布式锁、发布订阅功能等。为了避免重复开发,保证程序质量,通常会构建一个统一的服务协调组件,解决这些分布式系统通用的难题,以便大数据业务提供者能将精力更多的聚焦在业务之上。
4. 计算引擎
实际生产环境中,针对不同的业务场景,对数据处理的要求是不同的。有些场景下,离线、批量的处理数据即可,对实时性要求不高,但要求系统吞吐率高,典型的应用是搜索引擎构建索引;有些场景下,要对数据进行实时分析,要求每条数据处理延迟尽可能低,典型的应用是广告系统及信用卡欺诈检测。不同类型的计算任务,追求的是不同的目标,批处理计算追求的是高吞吐率,而实时计算追求的是低延迟,系统吞吐率和处理延迟的优化往往是两个矛盾的方向。大一统的解决方案已被证明是不现实的。
当前计算引擎的发展方向是“小而美”,即为每种场景设计匹配的计算引擎,专注解决某一类的问题。而计算引擎也是大数据技术发展最活跃的地方。
总体上可按照对处理时间的要求,将计算引擎分为三类:
- 批处理引擎:该类计算引擎对时间要求较低,一般处理时间为分钟到小时级别,甚至天级别。追求的是高吞吐率,即单位时间内处理的数据量尽可能大,典型的应用有搜索引擎索引构建、批量数据分析等。
- 交互式处理引擎:该类计算引擎对时间要求较高,一般要求处理时间为秒级别。这类系统往往需要和人进行交互,因此会提供类SQL的数据交互语言,典型的应用有数据查询、参数化报表生成等。
- 实时处理引擎:该类计算引擎对时间要求最高,一般处理延迟在秒级以内,典型的应用有广告系统、舆情监测等。
5. 数据分析
数据分析层直接跟用户或应用程序对接。为了让数据分析更加容易,计算引擎会提供如应用程序API、类SQL查询语言、数据挖掘SDK等工具。也就是说,数据分析层和计算引擎层往往贴合的较为紧密,有时也可以将它们看成一层。对应到实际应用中,也往往首先使用批处理/流处理框架对原始海量数据进行分析,产生较小规模的数据集后,再使用交互式处理工具对该数据集进行快速查询,获取最终结果。
6. 数据可视化
数据可视化指的是运用计算机图形学和图像处理技术,将数据转换为图像在屏幕上显示出来,并进行交互处理的理论、方法和技术。数据可视化层是直接面向用户展示结果的一层,由于该层直接对接用户,是展示大数据价值的“门户”,因此数据可视化是极具意义的。
理解了企业级大数据架构中主要的几个层次后,再来看看两个著名的大数据技术栈。
二、谷歌大数据技术栈
谷歌的大数据技术栈主要分布在数据存储层、资源管理与服务协调层、计算引擎层、数据分析层中。谷歌大数据技术栈并未开源,但其背后的思想却以一篇篇经典的论文,对业界产生深远的影响。
下图是谷歌技术栈的一些核心组件:
1. GFS
Google File System 是一个分布式文件系统,具有良好的容错性、扩展性和可用性。GFS可构建在大量普通廉价服务器上,能够轻松的进行“Scale out”(横向扩展),相比于传统的“Scale up”(纵向扩展)方案中的大型机或小型机等,大大降低了成本。
2. BigTable
BigTable 是一个构建在 GFS 之上的分布式 NoSQL 数据库,其行数和列数可以无限扩展,弥补了传统关系型数据库在 Schema 设计上的不灵活。
3. Borg
Brog 是一个集群资源管理和调度系统,对应用程序进行接收、启动、停止、重启和监控。Borg 的目的是让开发者不必操心资源管理的问题,专注于应用程序业务逻辑的实现,并辅助应用程序做到资源利用率最大化。
4. MapReduce
MapReduce 是一个批处理离线计算框架,采用“分而治之”的思想,将对大规模数据集的操作,分解成Map和Reduce两个阶段,Map阶段并行处理输入数据集,产生中间结果,Reduce阶段则通过整合各个节点的中间结果,得到最终结果,其本质就是一个“任务的分解与结果的汇总”的框架。MapReduce具有高吞吐率、良好的容错性、扩展性以及易于编程等特点,广泛应用于构建索引、数据挖掘、机器学习等应用中。
5. Dremel
Dremel是一个分布式OLAP(OnLine Analytical Processing)系统,能够帮助数据分析师在秒级处理PB级数据。Dremel在一定程度上弥补了类 MapReduce 系统在交互式查询方面的不足。
6. FlumeJava
FlumeJava 是一个建立在 MapReduce 之上的 Java 编程库,提供了一层高级原语以简化复杂的 MapReduce 应用程序开发,让使用者能更简单构建数据流水线。
7. Tenzing
Tenzing 是建立在 MapReduce 之上的SQL查询执行引擎,它可以将用户编写的SQL语句转化为 MapReduce 程序,提交到分布式集群中并行执行。
三、Hadoop/Spark 开源大数据技术栈
谷歌为业界贡献了思想和方法论,但其的大数据技术栈是闭源的。业界目前主流的大数据基础架构和组件,主要围绕在Hadoop/Spark为核心的开源生态体系:
1. 数据收集层:主要由关系型与非关系型数据收集组件,以及分布式消息队列构成。
- Sqoop/Canal:关系型数据收集和导入组件,是连接关系型数据库和Hadoop(如HDFS)的桥梁。Sqoop可将关系型数据库中的数据全量导入Hadoop,反之亦可。Canal则可用于实现数据的增量导入。
- Flume:非关系型数据收集和导入组件,主要是流式日志数据,几乎可做到实时收集。经过滤、聚集处理后加载到Hadoop HDFS等存储系统。
- Kafka:分布式消息队列,一般作为数据总线使用。它允许多个数据消费者订阅并获取感兴趣的数据。相比于其他消息队列,它采用分布式高容错设计,更适合大数据应用场景。消息总线是数据传输的基础,不仅仅应用在数据收集层中,数据存储,计算,分析等层面,都是 Kafka 的舞台。
2. 数据存储层:主要由分布式文件系统(面向文件的存储)和分布式数据库(面向行/列的存储)构成。
- HDFS:Hadoop DFS,是Google GFS的开源实现,自然继承了GFS在扩展性和容错性上的优点,具有良好的扩展性与容错性等。
- HBase:构建在HDFS之上的分布式数据库,是Google BigTable的开源实现,允许用户存储结构化与半结构化的数据,支持行列无限扩展以及数据随机查找与删除。
- Kudu:分布式列式存储数据库,允许用户存储结构化数据,支持行无限扩展以及数据随机查找与更新。
3. 资源管理与服务协调层
- YARN:统一资源管理与调度系统,它能够管理集群中的各种资源(比如CPU和内存等),并按照一定的策略分配给上层的各类应用。YARN内置了多种多租户资源调度器,允许用户按照队列的方式组织和管理资源,且每个队列的调度机制可独立定制。
- ZooKeeper:基于简化的Paxos协议实现的服务协调系统,允许用户通过简单的API实现leader选举、服务命名、分布式队列与分布式锁等复杂的分布式调度和管理能力。
4. 计算引擎层:包含批处理,交互式处理和流式实时处理三类引擎。
- MapReduce/Tez:Hadoop MapReduce是Google MapReduce的开源实现,具有良好的扩展性与容错性,允许用户通过简单的API编写分布式程序。Tez是基于MapReduce开发的通用DAG(Directed Acyclic Graph的简称,有向无环图)计算引擎,能够更加高效地实现复杂的数据处理逻辑,目前被应用在Hive、Pig等数据分析。
- Spark:通用的DAG计算引擎,允许用户充分利用内存进行快速的数据挖掘和分析。Spark本质上属于批处理计算引擎。
- Storm / Spark Streaming:分布式流式实时计算引擎,具有良好的容错性与扩展性,能够高效地处理流式数据,它允许用户通过简单的API编写分布式实时应用程序。
- Impala / Presto:分别由Cloudera和Facebook开源的MPP(MassivelyParallel Processing)系统,允许用户使用标准SQL处理存储在Hadoop中的数据,是典型的交互式处理计算引擎。它们采用了并行数据库架构,内置了查询优化器,提升大数据平台交互场景下的处理效率。
5. 数据分析层:提供了各种大数据分析工具。
- Hive / Pig / SparkSQL:在计算引擎之上构建的支持SQL或脚本语言的分析系统,大大降低了用户进行大数据分析的门槛。其中,Hive是基于MapReduce/Tez实现的SQL引擎,Pig是基于MapReduce/Tez实现的工作流引擎,SparkSQL是基于Spark实现的SQL引擎。
- Mahout:在计算引擎之上构建的机器学习库,实现常用的机器学习和数据挖掘算法。其中,Mahout最初是基于MapReduce实现的,目前正逐步迁移到Spark引擎上,MLlib是基于Spark实现的。
- Apache Beam/Cascading:针对各类计算框架封装成高级API。Apache Beam统一了批处理和流式处理两类计算框架,提供了更高级的API方便用户编写与具体计算引擎无关的逻辑代码。
四、Lambda Architecture 综合型大数据架构
Lambda Architecture(LA)源于Twitter,是一种大数据软件设计架构,通过结合批处理和实时处理两类计算技术,在延迟、吞吐量和容错之间找到平衡点。LA将数据处理流程分解成三层:批处理层、流式处理层和服务层。
1. 批处理层
利用分布式批处理计算技术,以批为单位处理数据。该层将数据流看成只读的、仅支持追加操作的超大数据集。可以一次性处理大量数据,引入复杂的计算逻辑(如机器学习中的模型迭代计算,历史库匹配等)。优点是吞吐率高,缺点是处理延迟高,从数据产生到最终被处理完成,通常是分钟或小时级别。
2. 流式处理层
利用分布式采流式计算技术,大幅度降低了数据处理延迟,通常是毫秒或秒级别。优点是数据处理延迟低,缺点是吞吐量低,无法进行复杂的逻辑计算,得到的结果往往是近似解。
3. 服务层
为了整合两层的计算结果,LA设计了引一个服务层,对外提供了统一的访问接口,屏蔽内部的批处理和流式处理过程,方便用户使用。
一个经典的LA应用案例是推荐系统。在互联网行业,推荐系统被应用在各个领域,包括电子商务、视频、新闻等。推荐系统的设计目的是根据用户的兴趣特点和购买行为,向用户推荐感兴趣的信息和商品。推荐系统的核心模块是推荐算法。推荐算法通常会根据用户的兴趣特点和历史行为的海量数据构建推荐模型,预测用户可能感兴趣的信息和商品,进而推荐给用户。
基于LA的推荐系统技术架构中,通过不同采集方式获取到的数据统一流入 Kafka,再按照不同时间粒度分发至批处理和流式处理两个系统中。
老用户推荐处理
批处理层拥有所有历史数据(通常保存到HDFS/HBase中),通常用以实现推荐模型,也就是以最近和历史的数据为输入,通过特征工程、模型构建及模型评估等计算环节后(通常是基于MapReduce/Spark实现),最终获得最优的模型,并将推荐结果存储起来(比如使用Redis),这个过程延迟是比较大的,分钟甚至小时级别。
新用户推荐处理
为了解决新用户推荐问题(没有什么历史记数据),则会引入流式处理引擎,实时收集用户有限的实时行为数据,通过简单的推荐算法(通常基于Storm/Spark Streaming实现),快速产生推荐结果并存储起来。
推荐系统访问服务
为了便于其他系统获取推荐结果,推荐系统往往通过服务层对外提供访问接口,比如网站后台在渲染某个页面时,可能从推荐系统中获取对应的结果。
五、关于Hadoop/Spark的发型版
1. Hadoop发行版
- Apache Hadoop:社区原生版本,是其他商业公司发行版的基
- CDH(Cloudera Distributed Hadoop):Cloudera的发行版,社区版开源免费,商业版闭源收费,是使用最广泛的发行版之一。
- HDP(Hortonworks Data Platform):Hortonworks的发行版,社区版开源免费,商业版闭源收费。
2. Spark发行版
- Apache Spark:社区原生版本,是其他商业公司发行版的基础。
- Databricks Spark:Databricks的发行版,在社区版本基础上,增加安全、审计、云等方面的支持。
- Hadoop企业发行版:各大Hadoop企业发行版,比如HDP和CDH,均内置了对Spark的支持。
各个发行版之间同一系统对外使用方式和接口是完全兼容的,均提供了个性化的运维与管理工具等,不同之处在于它们引入了不同子系统或组件解决问题,比如
- 交互分析:CDH选择Impala解决交互式分析问题,而HDP选择Hive On Tez
- 安全方案:CDH引入了Cloudera Navigator和Sentry解决安全问题,而HDP则使用Ranger和Knox
在线上环境部署私有Hadoop与Spark集群时,为了避免各个系统之间兼容性问题(比如HBase与Hadoop之间的兼容性),建议直接选用商业公司发行版。
以上就是第一篇笔记的全部内容,对大数据技术架构有个初步的理解:
- 企业级大数据技术框架的分层模型:数据收集->数据存储层->资源管理与服务协调层->计算引擎层->数据分析层->数据可视化层
- Google大数据技术栈
- Hadoop/Spark开源大数据技术栈
- LA大数据架构
- 关于Hadoop/Spark的发行版
第二篇笔记开始,将走进Hadoop/Spark的世界,通过对核心组件的学习,理解大数据平台的工作机制。
照旧送福利,祝自己一帆风顺,@_@