关于大数据:浅析大数据技术架构

4次阅读

共计 2317 个字符,预计需要花费 6 分钟才能阅读完成。

大数据采集

数据采集的工作就是把数据从各种数据源中采集和存储到数据存储上,大数据培训期间有可能会做一些简略的荡涤。

数据源的品种比拟多:

1、网站日志

作为互联网行业,网站日志占的份额最大,网站日志存储在多台网站日志服务器上,个别是在每台网站日志服务器上部署 flume agent,实时的收集网站日志并存储到 HDFS 上。

2、业务数据库

业务数据库的品种也是多种多样,有 Mysql、Oracle、SqlServer 等,这时候,咱们迫切的须要一种能从各种数据库中将数据同步到 HDFS 上的工具,Sqoop 是一种,然而 Sqoop 太过沉重,而且不论数据量大小,都须要启动 MapReduce 来执行,而且须要 Hadoop 集群的每台机器都能拜访业务数据库;应对此场景,淘宝开源的 DataX,是一个很好的解决方案,有资源的话,能够基于 DataX 之上做二次开发,就能十分好的解决。

当然,Flume 通过配置与开发,也能够实时的从数据库中同步数据到 HDFS。

3、来自于 Ftp/Http 的数据源

有可能一些合作伙伴提供的数据,须要通过 Ftp/Http 等定时获取,DataX 也能够满足该需要。

4、其余数据源

比方一些手工录入的数据,只须要提供一个接口或小程序,即可实现。

大数据存储与剖析

毋庸置疑,HDFS 是大数据环境下数据仓库 / 数据平台最完满的数据存储解决方案。

离线数据分析与计算,也就是对实时性要求不高的局部,在笔者看来,Hive 还是首当其冲的抉择,丰盛的数据类型、内置函数;压缩比十分高的 ORC 文件存储格局;十分不便的 SQL 反对,使得 Hive 在基于结构化数据上的统计分析远远比 MapReduce 要高效的多,一句 SQL 能够实现的需要,开发 MR 可能须要上百行代码;

当然,应用 Hadoop 框架自然而然也提供了 MapReduce 接口,如果真的很乐意开发 Java,或者对 SQL 不熟,那么也能够应用 MapReduce 来做剖析与计算;

Spark 是这两年十分火的,通过实际,它的性能确实比 MapReduce 要好很多,而且和 Hive、Yarn 联合的越来越好,因而,必须反对应用 Spark 和 SparkSQL 来做剖析和计算。因为曾经有 Hadoop Yarn,应用 Spark 其实是非常容易的,不必独自部署 Spark 集群。

大数据共享

这里的数据共享,其实指的是后面数据分析与计算后的后果寄存的中央,其实就是关系型数据库和 NOSQL 数据库;

后面应用 Hive、MR、Spark、SparkSQL 剖析和计算的后果,还是在 HDFS 上,但大多业务和利用不可能间接从 HDFS 上获取数据,那么就须要一个数据共享的中央,使得各业务和产品能不便的获取数据;和数据采集层到 HDFS 刚好相同,这里须要一个从 HDFS 将数据同步至其余指标数据源的工具,同样,DataX 也能够满足。

另外,一些实时计算的后果数据可能由实时计算模块间接写入数据共享。

大数据利用

1、业务产品(CRM、ERP 等)

业务产品所应用的数据,曾经存在于数据共享层,间接从数据共享层拜访即可;

2、报表(FineReport、业务报表)

同业务产品,报表所应用的数据,个别也是曾经统计汇总好的,寄存于数据共享层;

3、即席查问

即席查问的用户有很多,有可能是数据开发人员、网站和产品经营人员、数据分析人员、甚至是部门老大,他们都有即席查问数据的需要;

这种即席查问通常是现有的报表和数据共享层的数据并不能满足他们的需要,须要从数据存储层间接查问。

即席查问个别是通过 SQL 实现,最大的难度在于响应速度上,应用 Hive 有点慢,能够用 SparkSQL,它的响应速度较 Hive 快很多,而且能很好的与 Hive 兼容。

当然,你也能够应用 Impala,如果不在乎平台中再多一个框架的话。

4、OLAP

目前,很多的 OLAP 工具不能很好的反对从 HDFS 上间接获取数据,都是通过将须要的数据同步到关系型数据库中做 OLAP,但如果数据量微小的话,关系型数据库显然不行;

这时候,须要做相应的开发,从 HDFS 或者 HBase 中获取数据,实现 OLAP 的性能;比方:依据用户在界面上抉择的不定的维度和指标,通过开发接口,从 HBase 中获取数据来展现。

5、其它数据接口

这种接口有通用的,有定制的。比方:一个从 Redis 中获取用户属性的接口是通用的,所有的业务都能够调用这个接口来获取用户属性。

实时数据计算

当初业务对数据仓库实时性的需要越来越多,比方:实时的理解网站的整体流量;实时的获取一个广告的曝光和点击;在海量数据下,依附传统数据库和传统实现办法根本实现不了,须要的是一种分布式的、高吞吐量的、延时低的、高牢靠的实时计算框架;Storm 在这块是比拟成熟了,但我抉择 Spark Streaming,起因很简略,不想多引入一个框架到平台中,另外,Spark Streaming 比 Storm 延时性高那么一点点,那对于咱们的须要能够疏忽。

咱们目前应用 Spark Streaming 实现了实时的网站流量统计、实时的广告成果统计两块性能。

做法也很简略,由 Flume 在前端日志服务器上收集网站日志和广告日志,实时的发送给 Spark Streaming,由 Spark Streaming 实现统计,将数据存储至 Redis,业务通过拜访 Redis 实时获取。

任务调度与监控

在数据仓库 / 数据平台中,有各种各样十分多的程序和工作,比方:数据采集工作、数据同步工作、数据分析工作等;

这些工作除了定时调度,还存在非常复杂的工作依赖关系,比方:数据分析工作必须等相应的数据采集工作实现后能力开始;数据同步工作须要等数据分析工作实现后能力开始;

这就须要一个十分欠缺的任务调度与监控零碎,它作为数据仓库 / 数据平台的中枢,负责调度和监控所有工作的调配与运行。

正文完
 0