网站建设与管理实训总结,江苏城乡建设职业学院网站,网站建设宣传图片,wordpress主题 storefrontal大数据常见应用场景及架构改进大数据典型的离线处理场景1.大数据数据仓库及它的架构改进2.海量数据规模下的搜索与检索3.新兴的图计算领域4.海量数据挖掘潜在价值大数据实时处理场景大数据典型的离线处理场景
1.大数据数据仓库及它的架构改进
对于离线场景#xff0c;最典型…
大数据常见应用场景及架构改进大数据典型的离线处理场景1.大数据数据仓库及它的架构改进2.海量数据规模下的搜索与检索3.新兴的图计算领域4.海量数据挖掘潜在价值大数据实时处理场景大数据典型的离线处理场景
1.大数据数据仓库及它的架构改进
对于离线场景最典型的就是数据仓库。它和传统的数仓不太一样。因为传统数仓它只能解决中小规模的数据存储与分析问题。大数据这一块要能承接海量的数据。
我们来看一下它们的基本架构。首先对于传统数仓的数据分析业务数据产生之后会存在单机数据库里面。比如说mysql、oracle、DB2等等。ETL任务会定期把它们集中抽取到数据仓库中进行一个汇总和管理。 数仓比较早的时候它是单节点的单节点怎么能够存储较多的数据呢大家可能都听过大型机这个概念配置非常豪华的服务器它的容量包括性能是足够ok的。
如果说单节点存不下会使用mpp数据库架构它是多节点架构。可以容纳中等规模的数据集。
但是它的节点数是存在上限的不管是单节点还是mpp它最大的问题在于扩展性能上限导致数据容量是有上限的。
数据存到数仓里基于数仓的数据在做一些分析时候需要编写应用代码。代码在运行的时候需要从数据仓库中进行数据的一个查询。将查询出来的数据做一个抽取把数据抽取到计算程序所在的节点后再进行运算。运算得到结果最后做一个输出。
中间这个过程因为要在网络上进行数据抽取所以数据量一旦达到比较大的规模。比如说这个数据有100tb对于网络的影响就比较高。而且它的抽取效率也是很慢的。当然中小规模数据集是没有问题的。
所以传统数据分析一旦数据量达到某一个规模之后它分析起来其实性能就比较差了会比较吃力一些。
对于大数据分析这一块它是怎么去解决这个问题的
首先数据源这里就比较丰富体现了大数据场景的多样性。它有非结构化、半结构化、结构化数据。 这些数据抽取过来在进行存储的时候就是以完全分布式的方式进行存储。大数据的架构基本都是天然分布式的这样的话它的扩展性能是非常好的。
现在我们有5台节点进行存储如果容量达到了上限我们可以新增一些节点这样它的容量就会线性增加。
那如果我们单个文件比较大比如说我们有一个文件有1tb大小。这样的一个大文件在存的时候大数据这里使用了分而治之的一个思想。它把大的文件拆分成非常多的小块每一个数据块是128M。拆成这些小块以后再均匀的打散到各个服务器节点中进行存储。
这样的话即使你这个文件再大我都能够保存起来。这样的话就解决了数据存储这一块的问题。
接下来在计算的时候因为单个文件就1tb数据量比较大。那如果把这个数据经过网络进行移动在进行分析运算的时候性能会比较差。
这个时候我们换一种思路去解决这个问题。怎么解决
你数据移动开销比较高那你数据就不要动。数据不要动我的计算任务分发到数据节点进行一个运算。
计算任务它本身就是一个代码程序它分发到各个节点效率或者速度是比较快的。计算任务在数据节点 直接进行运算这样的话每个节点得到的结果一定是部分结果。为什么
因为数据打散到各个节点每个节点存储的是部分数据部分数据计算的结果肯定是部分结果。部分结果得到以后我们只需要再新增一个阶段把这个部分结果汇总成最终结果再做一个输出就ok。
那部分结果的汇总大家可想而知它的开销或者代价一定是比较低的。
所以这是大数据的第二个思想叫移动计算而非移动数据。这样的话它就解决了我们海量数据在计算这一块的一个性能瓶颈。
但是这种架构它对于这种中小规模的数据其实是不太友好的。如果你这个数据1G它先要拆分拆分后需要发送到各个节点存储并且要存储多个副本保证容错。并且在计算的时候计算任务要分发到这个节点再运算运算完以后要汇总最终结果最后再进行输出。整个调度流程就比较长。
而1G的文件放在传统数据处理架构里面它就可以直接完成计算效率还高得多。
所以大数据要发挥它的实力一定是数据规模达到一定量级以后当它的调度时间要远远小于它的计算时间。这个时候大数据的力量、威力或者价值才可以发挥出来。这一点大家要留意。
2.海量数据规模下的搜索与检索
除了数仓之外离线场景还有做搜索与检索。这也是一个常见的场景。
搜索与检索的话其实就是把数据先存起来然后对这个数据做一些检索。检索的话一般来说做模糊匹配、正则匹配或者语义匹配服务端能够很快给我返回结果。 大数据这一块搜索检索它首先在存储上数据已经达到了海量规模。再一个在做计算的时候在海量数据规模下要求在非常短的时间里要给到反馈结果。
查询的时候要进行语义、模糊、正则匹配或者是多功能的一些复杂匹配大数据这一块的压力是更重的。所以要求它的性能是更高的。
比如公安场景将多维度的人口信息储存起来需要调用的时候能够快速匹配并返回结果。以便辅助案件的侦破与办理。
3.新兴的图计算领域
对于图计算它主要是展现数据之间的关系。比方说它可以展现公司之间的关系情况在图中我们可以看到a公司与b公司、c公司之间是没有联系的而b公司和c公司之间是有一些联系的。 在金融领域图计算可以挖掘一些比如担保链的异常比如a公司给b公司担保b公司给c公司担保c公司又给a公司担保形成这样的一个链条肯定是非常有风险的。
包括反洗钱它也是洗完以后又洗回来了。包括企业之间互相投资a投资bb投资cc再投资a形成这样的一个链条。
这种情况在金融中如果使用关系型数据库它是很难发现的。及时能够实现运算量也非常庞大。
但是用图计算的话可以很直观的直接做一个展现避免了这些风险。
4.海量数据挖掘潜在价值
当然基于数据我们也可以做数据挖掘。海量的数据它里面潜在的价值是非常高的。比如说我们基于上海市的街头监控数据进行数据挖掘分析最后做一个图展现。
这个图展现出来的就是目前上海市当前这个时间各个地点的人流密集情况。目前看到7这个地方人流是最密集的是人民广场10和6这两个紧随其后。 通过分析展现以后可以辅助我们的治安工作的展开。比如说我们提前去派人力去做人流的疏导。
当然如果它配上人工智能更是如虎添翼人工智能厉害的是它可以做预测它提前预测到某个地方比如说10这个地方。也就是陆家嘴在一个小时之后即将出现人流高峰。我们提前派警力这样的话就可以杜绝一些风险的发生。
大数据实时处理场景
前面讲的都是我们的离线场景对于实时场景的话其实准确来说要实时处理数据并产生结果。它有一个通用的架构与模式。 数据从数据源产生数据源可以是ATM机的、POS机的、智能风机的或者一些传感器。它们会实时产生数据这些数据要先进入到一个分布式的消息队列里面做缓冲而不是直接扔到大数据的分布式流处理集群里面进行运算。
为什么要先进入到分布式消息队列里面它的目的主要是为了抗压因为前面这些数据源它在实时的产生数据。
那就有可能存在没办法预测的并发峰值很典型的可以预测的峰值比如说618购物节、双11购物节、12306逢年过节抢票的时候。
这个时间的并发我们可以预测的基本就是那个时间。
但是你比如说某个明星闹个绯闻突然大量的流量涌上微博这个是没办法预测的。
保不准哪个点流量涌上来以后服务器直接就down掉了。这种没办法预测的峰值如果直接扔到大数据平台对大数据平台是会产生足够大的冲击的。大数据平台挂掉以后大数据平台上面所有的业务都挂了这个是风险很高的。
对于企业来说一定要有抗压的这样的一个消息队列这个消息队列它的抗压性能非常好能够撑住足够的压力。如果说压力过大我们可以通过扩展与新增节点来增加它的抗压性。
它扛住压力以后分布式的大数据流处理集群再从我们的分布式队列里面去取数据取到数据后进行正常的处理最后把结果做一个输出。
有这样的架构以后大量消息涌上来以后无非是在分布式消息队列里面多积压一会儿。但是只要是大数据的流处理集群没有挂在规定时间里都是可以处理完的而且避免了一个风险。
这是大数据常见的应用场景这一节就和大家聊到这里我们下期再会视频内容可以在B站进行观看传送门数舟
