大数据平台架构及主流技术栈
互联网和移动互联网技术开启了大规模生产、分享和应用数据的大数据时代。面对如此庞大规模的数据,如何存储?如何计算?各大互联网巨头都进行了探索。Google的三篇论文 GFS(2003),MapReduce(2004),Bigtable(2006)为大数据技术奠定了理论基础。随后,基于这三篇论文的开源实现Hadoop被各个互联网公司广泛使用。在此过程中,无数互联网工程师基于自己的实践,不断完善和丰富Hadoop技术生态。经过十几年的发展,如今的大数据技术生态已相对成熟,围绕大数据应用搭建的平台架构和技术选型也逐渐趋向统一。
上图是目前国内各大互联网公司普遍采用的大数据平台架构和技术选型。康威定律指出,技术架构与组织架构是相匹配的(延伸阅读《从康威定律看技术管理》)。许多互联网公司的大数据平台部门的组织架构也会长成这样。大型互联网公司中,上图中的每个组件甚至都会对应一个团队。当然对于大部分公司而言,技术主要是为了解决业务问题,构建庞大的大数据平台成本太高,还是需要根据实际情况灵活设计。下面对各个组件做一个简单介绍,希望能对实际场景的技术取舍提供帮助。
数据采集
“巧妇难为无米之炊”,没有数据也就没有后面的一切,数据采集作为基础至关重要。采集的数据主要由业务系统产生,包括存储在关系型DB中的结构化数据和记录在日志文件中的半结构化数据。Sqoop用于从关系型DB中采集数据,Flume用于日志采集。实时计算由于对时效性要求比较高,它一般采用Kafka和业务系统建立实时数据通道,完成数据传输。
Sqoop是Apache的一个独立项目,始于2009年。Sqoop是一个用来将Hadoop和关系型数据库中的数据相互转移的工具,可以将一个关系型数据库(例如 :MySQL ,Oracle ,Postgres等)中的数据导进到Hadoop的HDFS中,也可以将HDFS的数据导进到关系型数据库中。其官方地址是 http://sqoop.apache.org/。官网介绍如下:
Flume最早是Cloudera提供的日志收集系统,是Apache下的一个孵化项目。Flume是一个高可用的,高可靠的,分布式的海量日志采集、聚合和传输的系统,Flume支持在日志系统中定制各类数据发送方,用于收集数据;同时,Flume提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力。其官方地址是 http://flume.apache.org/。官网介绍如下:
离线计算
离线计算是指在计算开始前已知所有输入数据,输入数据不会产生变化,且在解决一个问题后就要立即得出结果的前提下进行的计算。离线计算处理的数据是静态不变的,但是数据量非常大。因此如何存储和计算海量数据是离线计算最大的技术挑战。这也是Hadoop技术生态核心解决的问题。
HDFS是基于谷歌GFS论文实现的开源分布式文件系统,主要解决海量数据的存储问题。系统架构上,HDFS是一个典型的主从分布式架构。主节点叫NameNode,从节点叫DataNode。NameNode负责集群的全局管理,处理来自客户端的读写请求。DataNode是实际存储文件的数据块,执行来自主节点的读写命令。HDFS保证了CAP中的CP,追求强一致高吞吐设计,不适合低延迟的应用场景。此外,HDFS采用流数据模式访问和处理文件,只支持追加(append-only)的方式写入数据,不支持文件任意offset的修改。它的主要使用场景是作为数仓的底层存储系统。
离线计算的核心计算模型基于MapReduce实现。Hive用类SQL的方式,简化了MapReduce的脚本实现过程,目前已成为搭建数仓的首选工具。Spark将MapReduce对磁盘的多点I/O改为内存中的多线程实现,将中间处理数据存于内存来减少磁盘IO操作,速度比传统MapReduce快10倍。此外,Spark还支持流式计算,使它在实时计算中也占有一席之地。Presto也是完全基于内存的并行计算模型,查询性能好,但是受内存大小限制,更多用于OLAP查询。由于离线计算对时延要求不高,完全基于内存的计算支撑不起数仓大量的ETL过程,在实际场景中,ETL过程大部分还是基于Hive的HSQL实现。
实时计算
实时计算与离线计算相对应。离线计算在计算开始前已经知道所有的输入数据。实时计算在计算开始前并不知道所有的输入数据,输入数据以序列化的方式一个个输入并进行处理。实时计算过程处理的数据量不大,但是要求数据处理的速度非常快。如果说离线计算看重的是高吞吐能力,那么实时计算看重的就是快响应能力。为了实现快响应,实时计算通常会采用流计算(Stream Computing)方式。
流计算与批计算(Batch Computing)相对应,两者区别在于处理的数据粒度不同。批计算以数据块为单位进行数据处理,流计算以单条数据记录为单位进行数据处理。批处理的吞吐效率高于流处理,但是由于数据到达不会立即处理,所以延迟比流处理要高。批处理主要用于离线计算,流处理主要用于实时计算。但这不是绝对的,实时计算有时为了提高吞吐率,也会牺牲一些延时,比如Spark Streaming采用微批量(micro-batch,spark中称为Discretized Stream)的方式进行实时计算。除Spark外,Storm和Flink也是主流的实时计算框架,它们都是基于Native Streaming实现,延迟(latency)非常低,Storm在几十毫秒级别,Flink在百毫秒级别。
Flink计算的主流方向被定位成流计算,但它和Spark一样是流批一体的。Spark用批模拟流实现流计算,Flink用流模拟批来支持批处理。与Storm和Spark相比,Flink最大的优势在于它实现了有状态(Stateful)的计算,这个能力让它可以提供Exactly-Once语义保证,大大提高了程序员的编程效率。在众多的流计算框架中,Flink是最接近 Dataflow 模型的流计算框架,业内评价它是继Spark之后的第四代大数据计算引擎。现在国内互联网公司,包括BAT和TMD都选择了Flink。
除了计算问题外,对于实时计算还有一个很重要的问题:如何建立实时输入的数据流通道。
Kafka就是解决这个问题的最佳利器技术选型上,经常会拿Kafka跟MQ中间件(比如RabbitMQ、RocketMQ)进行比较。但Kafka设计的初衷是做日志统计分析,不是以可靠消息传输为设计目标。比如Kafka中消息可能会重复或乱序,它也不支持事务消息等。另外,Kafka采用批处理的方式传递消息,吞吐量高,但会有延迟,时效性不如MQ中间件,这也是为什么不建议用Kafka替代MQ中间件的原因。
OLAP
大数据的主要应用之一就是做数据分析,更专业的表述叫OLAP。OLAP是On Line Analytical Processing(联机分析处理)的缩写,与OLTP(On Line Transaction Processing, 联机事务处理)相对应。OLTP是传统的关系型数据库的主要应用,是一种操作型数据处理。OLAP是数据仓库的主要应用,是一种分析型数据处理。
OLAP分析处理的数据一般采用维度建模(延伸阅读:《数仓架构设计方法论》),基于“维度”的分析操作包括:钻取(上钻roll up和下钻drill down)、切片(slice)和切块(dice)、以及旋转(pivot)等。按数据存储方式不同,OLAP引擎分为ROLAP、MOLAP和HOLAP三种(如下图所示)。按实现架构不同,OLAP引擎可分为:MPP(Massively Parallel Processor, 大规模并行处理)架构、预处理架构和搜索引擎架构。
基于MPP架构的ROLAP引擎:Presto
利用关系模型来处理OLAP查询,通过并发来提高查询性能。Presto是Facebook于2012年开发,2013年开源的,完全基于内存的并⾏计算,分布式SQL交互式查询引擎。其官网地址是:https://prestodb.io/ 。
基于预计算架构的MOLAP引擎:Druid、Kylin
Kylin是完全的预计算引擎,通过枚举所有维度的组合,建立各种Cube进行提前聚合,以HBase为基础的OLAP引擎。其官网地址是:http://kylin.apache.org/ 。
Druid则是轻量级的提前聚合(roll-up),同时根据倒排索引以及bitmap提高查询效率的时间序列数据和存储引擎。其官网地址是:https://druid.apache.org/ 。
基于搜索引擎架构的OLAP:ES
ES是典型的搜索引擎类的架构系统,在入库时将数据转换为倒排索引,采用Scatter-Gather计算模型提高查询性能。- 对于搜索类的查询效果较好,但当数据量较大时,对于Scan类和聚合类为主的查询性能较低。
看数:敏捷BI工具
看数解决数据可视化问题,帮助BI进行数据分析,支持企业决策,实现商业价值。这个领域,国内外已经有很多成熟的软件,比如QlikView、TableAU、FineBI、PowerBI、QuickBI等。大部分BI软件都是商业软件,不支持私有化部署或者私有化部署成本很高。并且,BI工具的用户定位偏专业数据分析师,对普通人来说有一定的学习使用门槛。随着前端数据可视化组件的不断完善(比如Highcharts、百度的Echats、阿里的antV(G2)等),许多互联网公司会选择定制的数据可视化方案。一些大公司也会自研BI工具,比如滴滴的数易。
延伸阅读
《数仓架构设计方法论》
《从康威定律看技术管理》
大数据平台架构及主流技术栈相关推荐
- 大数据平台架构技术选型与场景运用
内容来源:2017年5月6日,大眼科技CTO张逸在"魅族技术开放日第八期--数据洞察"进行<大数据平台架构技术选型与场景运用>演讲分享.视频地址:https://mp. ...
- 《程序员》11月精彩内容:大数据平台架构与技术实践
本期<程序员>呈现大数据平台架构与技术实践精彩内容,汇聚来自去哪儿.游族网络.链家网.万达金融等公司的技术专家,将带领读者共同探讨热门技术应用和实践优化,深入解析蕴藏的数据价值,展现时下大 ...
- 多图技术贴:深入浅出解析大数据平台架构
目录: 什么是大数据 Hadoop介绍-HDFS.MR.Hbase 大数据平台应用举例-腾讯 公司的大数据平台架构 "就像望远镜让我们能够感受宇宙,显微镜让我们能够观测微生物一样,大数据正在 ...
- 硅谷企业的大数据平台架构什么样?看看Twitter、Airbnb、Uber的实践
导读:本文分析一下典型硅谷互联网企业的大数据平台架构. 作者:彭锋 宋文欣 孙浩峰 来源:大数据DT(ID:hzdashuju) 01 Twitter的大数据平台架构 Twitter是最早一批推进数字 ...
- 大数据平台架构的层次划分
1. 数据源层:包括传统的数据库,数据仓库,分布式数据库,NOSQL数据库,半结构化数据,无结构化数据,爬虫,日志系统等,是大数据平台的数据产生机构. 2. 数据整理层:包括数据清洗.数据转换.数据加 ...
- 大数据平台架构:数据平台建设的几种方案
随着大数据在越来越多的企业当中落地,企业要开展大数据相关的业务,那么首先要搭建起自身的数据平台.而企业搭建大数据平台,往往需要结合成本.业务.人员等各方面的因素,来规划数据平台建设方案.今天我们就来聊 ...
- 大数据平台架构浅析——以讯飞大数据平台Odeon为例
文章目录 大数据平台架构解析--以讯飞大数据平台Odeon为例 定义 功能 数据采集 数据开发 数据分析 数据编程 补充 大数据平台架构解析--以讯飞大数据平台Odeon为例 定义 Odeon大数据平 ...
- 金融机构大数据平台架构设计的 10 个考量点
1.金融企业大数据平台架构设计的关键点有哪些? 架构设计的关键首要是要满足业务需求,提炼业务需求的非功能特性,提出针对性的架构设计方案.作业自主研发能力有限的企业,在大数据系统建设中首要是合理的选择技 ...
- hadoop大数据平台架构之DKhadoop详解
hadoop大数据平台架构之DKhadoop详解 大数据的时代已经来了,信息的爆炸式增长使得越来越多的行业面临这大量数据需要存储和分析的挑战.Hadoop作为一个开源的分布式并行处理平台,以其高拓展. ...
最新文章
- 华硕飞行堡垒开启虚拟化
- 学长毕业日记 :本科毕业论文写成博士论文的神操作20160317
- python zen_Python的宗旨(Zen of Python)
- FLV Extract 1.2.1
- java重载与重写的区别你懂了吗
- SpringBoot学习笔记2
- 原创内容的17PK飞鸽传书
- 【ES6(2015)】Class (类)
- FPGA内部硬件结构简介
- 微信月活9亿的高效运维之路
- redis并发锁 thinkphp5_资深架构师经典总结:Redis分布式锁实现理解
- 在git上面找开源项目遇到的坑
- js ---- 对象去重
- Hibernate 查询
- 密码库LibTomCrypt学习记录——(2)分组密码算法的工作模式
- 《App后台开发运维和架构实践》资源汇总
- Cypress总结回顾
- 新联盟呼吁结束种族主义人工智能研究,声称将面Kong与犯罪行为相匹配
- Android开发框架大全
- 3个月学习成功上岗软件测试,我一个文科女也能吃IT饭了
热门文章
- 通过Socket套接字向施耐德PLC写数据
- 数据分析统计学基础之数据的趋势
- 微软服务器加速,通过 Azure CDN 进行动态站点加速
- zeromq v.s. erlang
- [渝粤教育] 南阳医学高等专科学校 医学计算机与信息素养 参考 资料
- 【数据库课设】学生成绩管理系统 (JAVA+ swing + JDBC)
- CSS伪类选择器nth-child 选择3的倍数个元素写法
- 拜罗伊特大学计算机,2018拜罗伊特大学世界排名及历年排名
- 全国计算机用代码作弊,魔兽争霸3重制版秘籍代码大全 war3作弊指令大全
- Day3-Mybatis基本框架搭建(添加用户)