大数据技术发展到今天为止,各种技术组件层出不穷,有的【昙花一现】,有的则【基业长青】,有的【风光一时】,而有的则【日渐衰落】。其根本原因无外乎3点:生态是否健全、功能是否好用、跟其他组件是否适配。
任何一个大数据系统的功能都是紧紧围绕:把原始数据进行分析、挖掘,最后得到我们想要的结果。
我们把这个需求进行关键字拆解,就是:【原始数据】、【分析挖掘】、【计算结果】这3个部分。那需求对应的是3个部分,那我们的系统功能是不是也应该对应3大部分呢?答案是肯定的。
因此,一个完整的大数据系统也必须紧紧围绕:【如何获取原始数据?】、【如何分析挖掘?】、和【如何安置处理结果?】这3个模块来展开。
这是一个大数据系统应该解决的第一步,如何把数据源的数据引入到大数据平台,也叫:【数据接入】。
数据接入需要两个步骤:第一步就是【接】;第二步则是【入】。
一般而言,数据源跟大数据系统分属两个完全不同的系统,有着不同的技术栈和管理方式。数据源一般属于业务系统,比如线上支付、线上购物、日志收集系统等,需要把这些系统中产生的数据给【接】到大数据处理系统中。
如何【接】?考虑到数据源安全、产生频率、接入数据量大小等因素,接入方式又可以分为【推】和【拉】两种。
推:主动权在数据源端,可能处于安全需要,大数据系统不能直接访问数据源,数据源会以对自己业务友好的方式进行数据推送到大数据系统;
拉:主动权在大数据系统端,以大数据系统的数据处理频率、数据处理量为中心,以一种对大数据系统端友好的方式对数据源进行拉取;
既然把数据通过【推】或者【拉】的方式【接】到大数据系统了,那么接下来就是考虑如何【入】这些数据了,即如何把接进来的数据给【存】起来?也叫数据落地。
对于如何【落地】,我们通常的指导思想无外乎3种:1,文件系统;2,消息队列;3,数据库;
什么时候用文件系统?
文件系统是最简单的数据落地手段,特点是:离线、简单、无schema、IO效率高。
因为存储时是以文件为单位,因此在后续数据计算处理时,也必须以文件为单位来进行,数据处理粒度相对受限,并且在每次数据处理时,需要处理程序主动识别当前应该处理哪些文件,以及忽略哪些文件。
一般常用的文件系统有:本地磁盘、分布式文件系统HDFS、S3、NFS等等。
什么时候用消息队列?
既然文件系统代表了【离线】,那消息队列就是【在线、实时】的代名词。如果一个大数据系统相要实现【实时】处理数据,那消息队列绝对是个少不了的工具。
其特点是:实时、相对简单、7x24小时不间断、流式处理、IO效率高。数据可以通过【主题】进行业务归类,并且每一条数据在写入消息队列后会给予编号(offset)。因此在后续数据计算处理时,可以根据业务需要选择特定的【主题】和offset,数据处理粒度很细。
一般常用的消息队列有:kafka、rabbitmq、rocketmq等等。
什么时候用数据库?
相比文件系统和消息队列,数据落地到数据库是最为麻烦的方式。因为任何数据想要存到数据库,就必须要提前建表,确定好数据的schema、key(主键)、索引字段等等。
其特点是:离线、步骤繁琐、含schema、IO效率偏低。数据选择落地到数据库最大的一个原因在于可以提前分配schema,这样最大的好处在于,后续数据计算处理时,只需要提取业务所需的字段,或者利用SQL只筛选业务需要的数据进行处理即可,减少了数据计算过程中无关字段带来的额外内存压力。
一般常用的数据库有:MySQL、PostreSQL、Hive、MongoDB等。
在大数据系统里,有个专门的技术组件叫【计算引擎】,它区别于传统数据库的计算引擎(传统数据库的计算引擎无法独立于数据库单独使用),是一个独立的软件系统,不依赖其他任何的存储系统而存在,可以单独使用。
我认为,【计算引擎】是大数据技术中最为伟大的发明之一,有了它,可以将原本必须杂糅在一起的数据处理步骤进行解耦,大大增强了一个数据系统的可用性。
因为独立,且提供了非常丰富和实用的脚手架方法、接口,可以适配市面上几乎所有的算法和计算模型。并且,因为开源生态的活跃,计算引擎既能兼容市面上主流的数据接入工具,又可以兼容主流的数据存储组件。
常用的计算引擎有:MapReduce、Tez、Storm、Spark、Flink等。
作为计算引擎计算处理后的结果,通常的做法就是给存起来。
说到存储,其实思路跟第1步中如何将数据源【落地】是一样的,只不过目标不太一样。
计算引擎计算处理后的结果数据,一般其用途有2:
最常见的做法就是将其存入到数据库中,因为是展示,因此必须要考虑数据获取的及时性。如果让想看到数据的人等待很长时间,这将是一个非常糟糕的体验。
因此,选择一个适合的数据库就显得尤为重要,数据库之所以区别于一般的文件系统,根本原因在于它可以提供【基于业务需求的数据结构】,能按照业务需要的方式进行数据存储,通过高效的索引机制来满足数据快速被读取的目的。
常用的数据库有:MySQL、HBASE、Elasticsearch、Redis等。
在有些情况下,通过计算引擎计算的结果可能还不能直接作为结果进行展示,它仅仅只是给另一个业务场景的计算提供了数据源。
这个时候,需要将其作为数据源写入到数据接入系统中,这就回到1.2中讨论的内容。
这篇文章讨论了一个大数据系统应该包含的3个核心模块:数据接入、数据计算、结果存储。
这是任何一个大数据系统都应该遵守的规范,也是任何一个大数据系统必须具备的最小功能。之所以说【最小】,因为随着业务的拓展,数据量的激增,系统承载的使命只会越来越重,要处理的数据任务也会越来越多,那么毫无疑问,系统的复杂度也一定会随之增加。
比如,数据源的多样性导致的数据接入方式可能有多种;为了满足业务场景需要,用于数据计算的计算引擎可能采用多个(离线+实时);为了加速计算结果的读取效率,加入中间缓存层,采用数据的冷热分离等手段。
但不管系统的复杂度如何变化,最终都是围绕以上3大模块进行展开和延伸...
(PS:可能有人会说,一个完整的大数据系统不应该包括数据展示吗?确实应该有,但是因为跟大数据技术关系不大,所以这里暂不做讨论)
下一篇:[技术交流] 5G的组网模式