时间:2023-01-19 | 标签: | 作者:Q8 | 来源:网络
小提示:您能找到这篇{岂止于大,一文读懂大数据及其在推荐系统的应}绝对不是偶然,我们能帮您找到潜在客户,解决您的困扰。如果您对本页介绍的岂止于大,一文读懂大数据及其在推荐系统的应内容感兴趣,有相关需求意向欢迎拨打我们的服务热线,或留言咨询,我们将第一时间联系您! |
大数据是数据智能时代的“铁公基”,是一系列计算和存储的基础设施。推荐系统也是建立在大数据的基础之上的,大量的数据挖掘和模型训练都离不开大数据。 大数据这个名词起的很好,对于非技术人员来说也能get到大的含义:数据量大,算力强大。 但是这强大的能力是怎么来的?大数据生态体系架构是怎么分工的? 不具体做过的同学并不清楚。今天就继续站在产品经理的角度深入浅出地来讲述这些问题。其实不一定是产品经理,对大数据感兴趣的同学都可以看看。本文比较长,如果时间不够,建议先Mark下。 01 大数据的诞生与分布式在大数据技术诞生之前,数据的存储和处理大半壁江山都是Oracle和MySql和等数据库软件的。这些传统数据库的文件系统是单机的,也就是说,数据只能在一台机器上跑。它们在处理成TB(1024GB)甚至上PB(1024TB)级别数据时就会特别吃力。 第一个解决了这个问题的公司是谷歌。谷歌解决这个问题的思路就是分布式。谷歌分别于2003-2004年发表了三篇重量级的论文,奠定了大数据的基础。 简单的说,谷歌通过论文公布了以下三个工具如何创造:
这个就是大数据技术的开始。从谷歌的这个原点开始,大数据经过多年发展,形成了今天的全貌。 可以用以下三个分类来去解构整个大数据生态:
大数据整个生态体系非常庞大,相关的产品不胜枚举,让人看着眼花缭乱,有种物种大爆发的感觉。但是也并非无迹可寻。我们理解大数据生态,从这三个方面去理解就会轻松很多。本文也是严格按照这个方式来讲述。 02 本文讲述需要用的数据表鉴于大数据生态过于庞大复杂,为了使得文章更加浅显易懂,本文不对技术概念做过多的描述,而是直接到操作层面,以图示的方式讲解。因为要讲述的是数据系统,我这里建一张数据表USER,用这张数据表在各个系统中处理过程来给大家讲述大数据各个组件的工作原理和机制。 03 Hadoop整个互联网技术生态圈中,谷歌是超级绩优生。每次发表论文,都会引起众多人员前来“抄作业”。Hadoop之父Doug Cutting和他的团队就是其中一个。他花了两年的业余时间,照着谷歌的论文实现了一个分布式数据系统,并用自己儿子的大象毛绒玩具的名字给这个系统命名为Hadoop。Hadoop的Logo也是个头大象。 后来到了2006年,Hadoop被引入Apache基金会,成为一个开源的顶级项目。随着Hadoop的不断发展,在Hadoop项目中,诞生了HBase,Hive,Pig,Zookeeper等子项目,并先后被Apache基金会将其独立升级成为顶级项目。 同时,Apache基金会也不断兼收并蓄其他大数据项目,基本把绝大多数优秀的大数据项目都收入麾下,大有天下武功出少林的味道。大数据各种开源组件中,Apache旗下的才是少林正宗。 闲话不多说,我们来讲Hadoop。 现在的Hadoop主要分三个部分:
04 图解分布式这里先具象的解释下,什么是大数据的分布式长什么样? 我们在安装Hadoop的时候,要把同一个Hadoop的软件安装包,安装在三台以上不同的机器上。安装好后,我们就可以得到一个Hadoop分布式集群。 如下图,我们将Hadoop的三个组件,安装在集群每一台机器上,这个集群有七台机器。每一台机器叫一个节点。这七个节点中,要选出一个做老大,我们有什么事情先找这个老大,这个就是主节点。因为主节点很重要,它要是挂了,整个集群就挂了。所以一般主节点配置两台,一台备份。其他五个节点叫做从节点。在Hadoop中,主节点命名为Master,从节点为Slave。 05 分布式文件系统:HDFS下面将Hadoop的第一个组件HDFS。HDFS作为分布式的文件系统,它是以文本的方式来保存数据的,也就是说,数据一般会跟我们的TXT文件那样。一个文件会被按照设定,切分成不同的数据块,然后每个数据块会被复制成多份,然后分布式地存到不同的节点中。HDFS把集群节点分成两类:NameNode和DataNode。
下面以USER数据表为例,举例说明HDFS的运作过程。实际的系统中,因为NameNode负荷比较重,会设置一个SecondaryNameNode来协助NameNode的工作(注意是协助,而不是备份)。 上图中:
HDFS优点:数据容量大,是大数据最主要的数据存储方式。很多其他组件都是建立在HDFS的基础上,应用非常广泛。 HDFS的缺点:它是个文件系统,而不是数据库系统,不能像关系数据库系统那样建立索引等工具提升处理速度和定位到数据位置。因为数据记录的形式是一行一行的字符串,没办法定位,不支持对数据的直接修改。 06 分布式离线计算引擎:MapReduceMapReduce是专门负责分布式计算的,它是是一个组合词,可以分成两个部分:Map和Reduce。 简单的说,Map就是把要计算的数据分解成多个计算任务,而Reduce则是Map过程得到的结果进行汇总。假设现在我们要计算在USER表中,男女各有多少人。 MapReduce计算详细过程如下: 上图中:
通过这种方式,MapReduce获得了强大的运算能力。 MapReduce优点:计算能力强大,运算耗费成本低廉,在运算能力一般的机器上也能运行。 MapReduce缺点:它诞生的年代,内存还很贵,在计算的过程中,中间结果要不断存入磁盘中,以减少内存的压力,但是这样导致了MapReduce运算速度比较慢。另外就是代码不简洁,学习曲线比较陡,后面在HIVE部分会讲述。 07 资源管理调度系统:YARNYARN的全称是Yet Another Resource Negotiator,直译就是另一种资源协调者。 看名字就知道,他是Hadoop中其中一种资源调度器。它的最重要的组件是ResourceMana成都重型卡车营销策划报价ger,通过这个组件,YARN可以为我们的MapReduce任务进行资源分配,分配的资源就是一个个的计算容器,每个计算的任务就在这个容器中跑。由于优秀,后来YARN进一步被发扬光大,成了Hadoop以外的很多大数据组件的资源调度框架。 08 数据分析和数据仓库工具:HIVE在MapReduce的中,处理数据作业的程序是要通过JAVA来实现的,但是JAVA在写MapReduce的过程并不简洁。像我们前面提到的统计数据表中男女人数这个简单的操作,需要严格按照Input到Reducing这五步来实现,代码一般长达上百行。 但是统计这个数据结果,对于SQL来说,就是一句话的事:SELECT sex,COUNT(1) FROM USER GROUP BY sex。 为了不再写又长又烦的JAVA,Hive应运而生。Hive组件就主要做的事情是,将SQL代码转译成MapReduce,然后放入YARN构建的容器里面跑出结果。 这样,我们要统计USER表中的男女人数的时候,就不用写JAVA实现也能调动MapReduce了,这里我们画图说明一下: 另外,Hive除了转译SQL的功能外,它也可以用来建数据库和数据表。一个数据库拥有的能力它都有,而且还可以处理大量的数据,所以一般还会将Hive用来建数据仓库。数据仓库的主要功能,就是把历史数据都存进去,可以反复地统计计算使用。数据仓库最主要的特征就是数据量特别大。 由于它是构建于HADOOP的基础上,Hive可计算的容量大,运算能力强,但是速度不快。Hive也不能直接修改数据。对Hive进行数据的修改操作非常费时。 最后,介绍一下Hive和MySql的区别:
09 离线计算和流式计算DAG计算引擎:SPARKSpark是分布式计算引擎,是大数据生态体系中的一个速度快,功能强大的一个组件。Spark整个框架非常庞大,提供能非常丰富的离线计算和流式计算能力。 本小节先介绍Spark的离线计算功能。 得益于摩尔定律下的硬件基础设施的升级,内存变得越来越便宜,与MapReduce主要把中间结果不断写入磁盘不同,Spark主要把数据放在内存中计算。这样Spark在速度上比起MapReduce有上千倍的提升。 当内存不足的时候,Spark也会需要将中间结果存入磁盘。但是在这种情况下,Spark在速度上比起MapReduce也有上百倍的提升。因为Spark提供了RDD,DataFrame,DataSet这样的数据表工具,并为这些数据表提供了一系列高效计算的算子,有效提升了速度。多个算子叠加就成了一个DAG(Directed Acyclic Graph),所以Spark也被成为DAG计算引擎。 下面介绍Spark的计算流程。 因为RDD,DataFrame,DataSet都是类似关系数据库的数据表,流程机制都差不多,这里选用DataFrame来解释。当Spark处理USER表的数据时,会经过以下过程: 上图中:
多个算子混合后,就形成了一个DAG,上面的操作,会形成以下的DAG。Spark通过构建DAG,然后下发给从节点计算。 同时这个计算过程也是像MapReduce那样,将计算任务分解成Map和Reduce两个阶段,分布式地在多台机器中计算,这里不再描述。 10 离线计算和流式计算MapReduce和Spark都是离线计算的代表,离线计算就是计算前已经有了所有需要计算的数据,且每次计算都是所有的数据都参与的运算。因为每次都是一整批数据做计算,所以离线计算一般又叫批量计算。但是日常的事务中,有很多场景是需要不断实时的更新数据的。 假设我们的USER表,现在因为有个新用户注册,多了一条用户数据“蔡九,女,27”。离线计算就要把新数据汇总,然后再进行计算: 增加一条用户日志,就要对全部的进行计算,在数据量非常庞大的时候,这根本是不可能的事情。所以我们还要另外一种计算方式,那就是流式计算。流式计算因其实时性,又常被叫做在线计算和实时计算。 以下是流式计算的过程,同样的新增数据,流失计算只要对新增数据进行计算,然后汇总更新: 流式计算引擎有:SPARK streaming,Storm和Flink。它们都可以提供流式计算的服务,但是有些不同。
11 分布式结构化存储系统:HBASE前面说到谷歌三篇关于大数据的论文营销网站成功案例,这里再补充一下它们后来的演变结果:
这就是HBase的诞生。 HBase是一个NoSql数据库。它在整个大数据生态中的定位是对数据进行实时的操作:查询,更新,删除和插入。前面说到HIVE是能处理大量数据,但是速度慢且不能对数据进行修改,而MySql等传统数据库响应快但是运算能力不足。HBase的出现,就是为了解决这些问题。 NoSql数据库的意思就是不支持SQL语句的数据库,HBase有以下特征:
为了方便理解,我们直接画图看HBase怎么工作。如何把我们的USER数据表放入HBase后,它是长成这样子的: 其中:
MySql中,修改数据就会覆盖掉旧数据。但是在HBase中,同个键值对可以保留多个数据版本。这个版本会以时间戳的形式来标记。如张三,有一天改名叫张三丰了,它并不会覆盖掉原有的张三,而是两个版本都保存起来。 如下如所示: HBase有强大的读取和增删改查能力,加上可以保存不同时间的数据版本,在推荐系统中,用户画像的结果数据,离线召回,近线召回等数据,都是保存在HBase中。另外,HBase可以做到快速响应,推荐系统中需要快速读取的数据,都可以存在HBase中。 12 数据采集大数据的诞生,并不是取代掉传统的关系型数据库,而是变成一种补充。传统数据库存不下的数据,大数据来存。传统数据库算不了的数据,大数据来算。大数据系统只是把现有系统的数据采集到大数据中,做存储和计算,对已有的业务流程和系统架构并没有什么影响。 将数据采集到大数据,一般用到两个工具:Sqoop、Flume。其实不同公司使用的数据采集工具不一样,这里只是简单的介绍。 关系型数据是我们最常见的一种数据,Sqoop是关系型数据库和大数据之间数据流动的一个桥梁。它可以用来将MySql和Oracle的数据导入HDFS,HBASE中,或者将大数据中的数据导入MySql或Oracle。 另外一种常见的数据是来自于日志系统的数据,在生产环境中,我们的搜索,推荐,广告服务每时每刻都在产生大量的流式日志。这些日志数据格式不一,形态各异,他们都是非结构数据。 这些数据一般都是以文本的方式保存在各个业务系统中,对于推荐系统而言,最重要用户的埋点行为数据就存在日志中。而对于这些非关系型数据,我们需要采集到大数据的时候,就需要用到Flume。Flume可以采集批量数据也可以采集流数据。 这两个工具知道作用即可,不用深究太多。 13 分布式消息队列:KAFKA采用Sqoop或者Flume做数据采集的时候,可以说是一对一的直采专线服务模式。我们把生产数据的系统叫生产者,消费数据的系统叫消费者。随着系统的发展,一般生产者和消费者都会越来越多,全部一对一直采,连接数就会指数上升,且难以维护。如果生产者的数据没能及时被消费者接收或者丢包,数据就会丢失。 为了解决这些问题,Kafka被创造了出来。 通过Kafka,生产者只要把数据打包好,标记好Topic,扔到Kafka的消息队列上就可以了。而消费者,只要做的事情就是订阅该生产者的Topic。当有新的数据到达时,Kafka就会告知消费者去取。 数据会被暂时保存在Kafka的硬盘中一段时间(一般7天),消费者随时可以来取。被保存的一系列数据块,就是一个个按时间排序的消息队列。同样的,Kakfa也是分布式的,它会被安装在多个节点中,数据也会被保存在多个节点中。 14 Lambda架构能看到这里,你已经很不容易了,前面已经将本文需要介绍的大数据组件讲完了。 大数据实在是太庞大了,而且各司其职,分工得特别细。这么多大数据的框架,有离线计算和流式计算,不同的分布式存储和不同的分布式工具,这些框架是怎么构建成一个大数据系统的呢? 这就要介绍大数据的Lambda架构。 Lambda架构算大数据系统里面举足轻重的架构,数据通道分为两条分支:实时流和离线。 实时流依照流式架构,保障了其实时性,而离线则以批处理方式为主,保障了最终一致性,适用于同时存在实时和离线需求的情况。 抽象掉所有的框架,可以把Lambda架构简化成如下方式: 推荐系统是个存储和算力消耗的大户,它需要离线计算,对时间不敏感的数据进行大批量的计算。也需要实时流式计算,对用户画像,物品画像数据进行实时的更新。 把本章中说到的大数据的各个框架组件按照Lambda架构的方式组建后,我们可以得到下图: 实际的情况比上图还要更复杂些,但是对于本文来说,借用机器学习的术语,再复杂就要“过拟合”了,适当的DropOut可以防止过拟合。扔掉一些,可能是更好的。 总结千言万语,汇总成一句话:大数据是由分布式存储,分布式计算和辅助性组件构成一个庞大的数据技术生态体系。它有几个要知识点:
写在最后的话: 大数据太多知识点了,受篇幅所限,这次只选择性地介绍推荐系统需要用到的大数据开源类组件。这个生态体系还在不断的发展中,我也还在路上。不足之处,还请各路高手不吝指教。 下篇文章将介绍用户画像,敬请期待,谢谢!
作者:菠萝王子;公众号:菠萝王子AI分享 本文由 @菠萝王子 于。, ,基于CC0协议 |
上一篇:初识“数据分析”:用户数据
下一篇:商业分析3步走!解决问题是关键
小提示:您应该对本页介绍的“岂止于大,一文读懂大数据及其在推荐系统的应”相关内容感兴趣,若您有相关需求欢迎拨打我们的服务热线或留言咨询,我们尽快与您联系沟通岂止于大,一文读懂大数据及其在推荐系统的应的相关事宜。
关键词:3年, 中级, 大数据应用, 推