大数据技术架构学习笔记(一)
笔记中
我当下的工作是大数据安全领域。大数据和云计算有些类似,既是技术,也是商业。我想利用十几篇笔记规模,对大数据的技术体系进行一个总结,同时也希望能作为公司内部培训交流所用。 笔记中的不少知识点来自于下面这本书,推荐给大家。 大数据技术体系详解 第一章:企业级大数据技术框架 一般情况下,数据进入大数据平台后,需要经历如下几个阶段: 大数据平台层次模型 一、每个阶段都存在特定的要求,也面临着不同的技术挑战。1. 数据采集 数据采集层直接跟数据源对接,负责将数据源中的数据实时或准实时收集起来。而数据源有如下的特点: 由于数据源存在上述特点,良好的数据采集系统需要考虑如下因素: 2. 数据存储 在大数据时代,采集到的海量数据既有结构化数据,也有非结构化数据,如果沿用传统的关系型数据库(如MySQL)和文件系统(如Linux文件系统),在存储容量、扩展性及容错性等方面都存在挑战: 3. 资源管理与服务协调 大数据平台为了解决资源利用率低、运维成本高和数据共享困难等问题,将应用集中存储在公共服务器集群中,这样的分布式系统,会面临很多共性问题,如leader选举、服务命名、分布式队列、分布式锁、发布订阅功能等。为了避免重复开发,保证程序质量,通常会构建一个统一的服务协调组件,解决这些分布式系统通用的难题,以便大数据业务提供者能将精力更多的聚焦在业务之上。 4. 计算引擎 实际生产环境中,针对不同的业务场景,对数据处理的要求是不同的。有些场景下,离线、批量的处理数据即可,对实时性要求不高,但要求系统吞吐率高,典型的应用是搜索引擎构建索引;有些场景下,要对数据进行实时分析,要求每条数据处理延迟尽可能低,典型的应用是广告系统及信用卡欺诈检测。不同类型的计算任务,追求的是不同的目标,批处理计算追求的是高吞吐率,而实时计算追求的是低延迟,系统吞吐率和处理延迟的优化往往是两个矛盾的方向。大一统的解决方案已被证明是不现实的。 当前计算引擎的发展方向是“小而美”,即为每种场景设计匹配的计算引擎,专注解决某一类的问题。而计算引擎也是大数据技术发展最活跃的地方。 总体上可按照对处理时间的要求,将计算引擎分为三类: 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为核心的开源生态体系: Hadoop/Spark大数据技术栈 1. 数据收集层:主要由关系型与非关系型数据收集组件,以及分布式消息队列构成。2. 数据存储层:主要由分布式文件系统(面向文件的存储)和分布式数据库(面向行/列的存储)构成。3. 资源管理与服务协调层4. 计算引擎层:包含批处理,交互式处理和流式实时处理三类引擎。5. 数据分析层:提供了各种大数据分析工具。四、Lambda Architecture 综合型大数据架构 Lambda Architecture(LA)源于Twitter,是一种大数据软件设计架构,通过结合批处理和实时处理两类计算技术大数据技术架构,在延迟、吞吐量和容错之间找到平衡点。LA将数据处理流程分解成三层:批处理层、流式处理层和服务层。 1. 批处理层 利用分布式批处理计算技术,以批为单位处理数据。该层将数据流看成只读的、仅支持追加操作的超大数据集。可以一次性处理大量数据,引入复杂的计算逻辑(如机器学习中的模型迭代计算,历史库匹配等)。优点是吞吐率高,缺点是处理延迟高,从数据产生到最终被处理完成,通常是分钟或小时级别。 2. 流式处理层 利用分布式采流式计算技术,大幅度降低了数据处理延迟,通常是毫秒或秒级别。优点是数据处理延迟低,缺点是吞吐量低,无法进行复杂的逻辑计算,得到的结果往往是近似解。 3. 服务层 为了整合两层的计算结果,LA设计了引一个服务层,对外提供了统一的访问接口,屏蔽内部的批处理和流式处理过程,方便用户使用。 Lamdba Architecture 一个经典的LA应用案例是推荐系统。在互联网行业,推荐系统被应用在各个领域,包括电子商务、视频、新闻等。推荐系统的设计目的是根据用户的兴趣特点和购买行为,向用户推荐感兴趣的信息和商品。推荐系统的核心模块是推荐算法。推荐算法通常会根据用户的兴趣特点和历史行为的海量数据构建推荐模型,预测用户可能感兴趣的信息和商品,进而推荐给用户。 基于LA的推荐系统技术架构中,通过不同采集方式获取到的数据统一流入 Kafka,再按照不同时间粒度分发至批处理和流式处理两个系统中。 老用户推荐处理 批处理层拥有所有历史数据(通常保存到HDFS/HBase中),通常用以实现推荐模型,也就是以最近和历史的数据为输入,通过特征工程、模型构建及模型评估等计算环节后(通常是基于MapReduce/Spark实现),最终获得最优的模型,并将推荐结果存储起来(比如使用Redis),这个过程延迟是比较大的,分钟甚至小时级别。 新用户推荐处理 为了解决新用户推荐问题(没有什么历史记数据),则会引入流式处理引擎,实时收集用户有限的实时行为数据,通过简单的推荐算法(通常基于Storm/Spark Streaming实现),快速产生推荐结果并存储起来。 推荐系统访问服务 为了便于其他系统获取推荐结果,推荐系统往往通过服务层对外提供访问接口,比如网站后台在渲染某个页面时,可能从推荐系统中获取对应的结果。 五、关于Hadoop/Spark的发型版1. Hadoop发行版2. Spark发行版 各个发行版之间同一系统对外使用方式和接口是完全兼容的,均提供了个性化的运维与管理工具等,不同之处在于它们引入了不同子系统或组件解决问题,比如 在线上环境部署私有Hadoop与Spark集群时,为了避免各个系统之间兼容性问题(比如HBase与Hadoop之间的兼容性),建议直接选用商业公司发行版。 (编辑:湘西站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |