⼀张图，详解⼤数据技术架构
来源 | 谈数据
开局⼀张图：
这是某公司使⽤的⼤数据平台架构图，⼤部分公司应该都差不多。
从这张⼤数据的整体架构图上看来，⼤数据的核⼼层应该是：数据采集层、数据存储与分析层、数据共享层、数据应⽤层，可能叫法有所不同，本质上的⾓⾊都⼤同⼩异。
所以我下⾯就按这张架构图上的线索，慢慢来剖析⼀下，⼤数据的核⼼技术都包括什么。
—01—
⼤数据采集
数据采集的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做⼀些简单的清洗。
数据源的种类⽐较多：
1、⽹站⽇志
作为互联⽹⾏业，⽹站⽇志占的份额最⼤，⽹站⽇志存储在多台⽹站⽇志服务器上，⼀般是在每台⽹站⽇志服务器上部署flume agent，实时的收集⽹站⽇志并存储到HDFS上。
2、业务数据库
业务数据库的种类也是多种多样，有Mysql、Oracle、SqlServer等，这时候，我们迫切的需要⼀种能从各种数据库中将数据同步到HDFS 上的⼯具，Sqoop是⼀种，但是Sqoop太过繁重，⽽且不管数据量⼤⼩，都需要启动MapReduce来执⾏，⽽且需要Hadoop集的每台机器都能访问业务数据库；应对此场景，淘宝开源的DataX，是⼀个很好的解决⽅案，有资源的话，可以基于DataX之上做⼆次开发，就能⾮常好的解决。
当然，Flume通过配置与开发，也可以实时的从数据库中同步数据到HDFS。
3、来⾃于Ftp/Http的数据源
有可能⼀些合作伙伴提供的数据，需要通过Ftp/Http等定时获取，DataX也可以满⾜该需求。
4、其他数据源
⽐如⼀些⼿⼯录⼊的数据，只需要提供⼀个接⼝或⼩程序，即可完成。
—02—
⼤数据存储与分析
⽏庸置疑，HDFS是⼤数据环境下数据仓库/数据平台最完美的数据存储解决⽅案。
离线数据分析与计算，也就是对实时性要求不⾼的部分，在笔者看来，Hive还是⾸当其冲的选择，丰富的数据类型、内置函数；压缩⽐⾮常⾼的ORC⽂件存储格式；⾮常⽅便的SQL⽀持，使得Hive在基于结构化数据上的统计分析远远⽐MapReduce要⾼效的多，⼀句SQL可以完成的需求，开发MR可能需要上百⾏代码；
当然，使⽤Hadoop框架⾃然⽽然也提供了MapReduce接⼝，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使⽤MapReduce 来做分析与计算；
Spark是这两年⾮常⽕的，经过实践，它的性能的确⽐MapReduce要好很多，⽽且和Hive、Yarn结合的越来越好，因此，必须⽀持使⽤Spark和SparkSQL来做分析和计算。因为已经有Hadoop Yarn，使⽤Spark其实是⾮常容易的，不⽤单独部署Spark集。
—03—
⼤数据共享
这⾥的数据共享，其实指的是前⾯数据分析与计算后的结果存放的地⽅，其实就是关系型数据库和NOSQL数据库；
前⾯使⽤Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但⼤多业务和应⽤不可能直接从HDFS上获取数据，那么就需要⼀个数据共享的地⽅，使得各业务和产品能⽅便的获取数据；和数据采集层到HDFS刚好相反，这⾥需要⼀个从HDFS将数据同步⾄其他⽬标数据源的⼯具，同样，DataX也可以满⾜。
另外，⼀些实时计算的结果数据可能由实时计算模块直接写⼊数据共享。
—04—
⼤数据应⽤
1、业务产品（CRM、ERP等）
业务产品所使⽤的数据，已经存在于数据共享层，直接从数据共享层访问即可；
2、报表（FineReport、业务报表）
同业务产品，报表所使⽤的数据，⼀般也是已经统计汇总好的，存放于数据共享层；
3、即席查询
即席查询的⽤户有很多，有可能是数据开发⼈员、⽹站和产品运营⼈员、数据分析⼈员、甚⾄是部门⽼⼤，他们都有即席查询数据的需求；
这种即席查询通常是现有的报表和数据共享层的数据并不能满⾜他们的需求，需要从数据存储层直接查询。
即席查询⼀般是通过SQL完成，最⼤的难度在于响应速度上，使⽤Hive有点慢，可以⽤SparkSQL，它的响应速度较Hive快很多，⽽且能很好的与Hive兼容。
当然，你也可以使⽤Impala，如果不在乎平台中再多⼀个框架的话。
redis是nosql数据库吗
4、OLAP
⽬前，很多的OLAP⼯具不能很好的⽀持从HDFS上直接获取数据，都是通过将需要的数据同步到关系型数据库中做OLAP，但如果数据量巨⼤的话，关系型数据库显然不⾏；
这时候，需要做相应的开发，从HDFS或者HBase中获取数据，完成OLAP的功能；⽐如：根据⽤户在界⾯上选择的不定的维度和指标，通过开发接⼝，从HBase中获取数据来展⽰。
5、其它数据接⼝
这种接⼝有通⽤的，有定制的。⽐如：⼀个从Redis中获取⽤户属性的接⼝是通⽤的，所有的业务都可以调⽤这个接⼝来获取⽤户属性。—05—
实时数据计算
现在业务对数据仓库实时性的需求越来越多，⽐如：实时的了解⽹站的整体流量；实时的获取⼀个⼴告的曝光和点击；在海量数据下，依靠传统数据库和传统实现⽅法基本完成不了，需要的是⼀种分布式的、⾼吞吐量的、延时低的、⾼可靠的实时计算框架；Storm在这块是⽐较成熟了，但我选择Spark Streaming，原因很简单，不想多引⼊⼀个框架到平台中，另外，Spark Streaming⽐Storm延时性⾼那么⼀点点，那对于我们的需要可以忽略。
我们⽬前使⽤Spark Streaming实现了实时的⽹站流量统计、实时的⼴告效果统计两块功能。
做法也很简单，由Flume在前端⽇志服务器上收集⽹站⽇志和⼴告⽇志，实时的发送给Spark Streaming，由Spark Streaming完成统计，将数据存储⾄Redis，业务通过访问Redis实时获取。
—06—
任务调度与监控
在数据仓库/数据平台中，有各种各样⾮常多的程序和任务，⽐如：数据采集任务、数据同步任务、数据分析任务等；
这些任务除了定时调度，还存在⾮常复杂的任务依赖关系，⽐如：数据分析任务必须等相应的数据采集任务完成后才能开始；数据同步任务需要等数据分析任务完成后才能开始；
这就需要⼀个⾮常完善的任务调度与监控系统，它作为数据仓库/数据平台的中枢，负责调度和监控所有任务的分配与运⾏。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。