创作

GemFire与Greenplum的最佳集成实践之实施经验谈

[复制链接]
最近的10年之中,很多应用系统、业务系统不断在迭代,不断有新版本在发布,可以看到有很多更创新式的应用来服务于我们的生活,我们的生活方式也因此改变很多。但是如果往后台数据看一下,会发现,虽然应用在前进,但是数据服务实际上还是在原地踏步。 发展到今天,现代系统中会经常面临这三个问题:
1.jpg
1. 应用的发展和延展性,会被数据服务的并发性边界所束缚,这种应用的延展可能会包含几个方面:
随着系统支持的用户量的增加,应用的实例数会显著增加。
随着行业的发展,会开发出或者交付出更多的应用,也就是说,应用的数量也在延展。
随着现在各种设备的发展,整个系统不但要接收从应用过来的请求,也要接收从各种设备上发出的信息对于数据介质的请求。
这三个方面都会导致对后台的数据服务能承载的并发量有一个更高的要求。但实际情况是,数据库是有并发边界的,这是一个障碍,限制了应用系统的发展。
2. 在业务中会发现,很难做到分析数据是可以更贴近于交易数据或者贴近于线上数据,可以提供一个准确的报告。在金融行业大家都会经常讨论的T+1报表的问题。假如我在凌晨12点才能开始计算前一天24小时之内的数据。那么开始计算之后,大概多长时间能拿到前一天24小时的结果呢?这取决于每个客户支持的最终用户的数量或分析的复杂度。有时候这种耗时可能要以小时计,有时候可能需要等到八九点开门之前领导才可能拿到前一天所有的数据分析报告。这对于整个系统来说,是一个很大的限制——我们的分析报告不能贴近于实时的交易数据,降低了分析报表的作用。
3. 随着近几年云计算的发展,微服务改造的发展,对于应用提出了更多的要求,需要进行持续交付、永远在线、可以任意时候进行动态延展的要求。但是反过来看,数据并没有准确好,数据现在不是Cloud ready,可能现在还部署在一个个的数据中心内部。当然,目前也会有很多的厂商在做Cloud Data这样的工作。但是我们目前在各个系统中看到的采用情况,这个比例并不乐观。
Pivotal 解决方案
看到了这三个问题之后,Pivotal的方案是什么呢?
2.jpg
Pivotal在数据方案中有数据套件这样的方案,Pivotal大数据套件包括了三个产品——MPP分析库,Greenplum;内存数据网格GemFire;基于Spring Cloud平台来进行数据抽取、数据转化的软件,叫做Spring Cloud Data Flow。
这三个软件分别做什么用呢?
Greenplum主要进行复杂的场景的分析,基于业务规则的分析,基于机器学习的相关的计算,这都可以用Greenplum来做。
GemFire主要是用来进行实时交易和实时判断的,或者说承载着大并发量的低延迟响应时间的业务上要求,是用GemFire来解决的。
Spring Cloud Data Flow做的是如何把数据从一个介质挪到另一个介质。例如从前端的应用产生的数据,通过Spring Cloud Data Flow 可以流转给GemFire、可以流转给Greenplum,也可以流转给系统中需要的其他的数据介质。
前面说的会遇到的三种问题
第一个是数据并发边界的问题,这种时候可以使用GemFire来解决这样的问题。对于GemFire来说,万级别的TPS才是刚起步,GemFire可以随着计算的资源的增加、随着节点数量的增加,可以线性的提高承载的并发数量。
第二个问题是如何解决在分析数据和交易数据之间时间上的gap。在Pivotal有一个搭建于 GemFire 和 Greenplum 之间的组件—— GGC(GemFire Greenplum Connector)。通过这样的组件,可以把分析极限贴近于交易,甚至可以把分析在GemFire中就可以进行完成。所以这里是可以有很多选择的。
第三个问题,数据是否是Cloud ready的。在之前GemFire、Greenplum都已经有公有云的版本,基于AWS也好,基于Azure也好,Pivotal在数据上已经准备好Cloud ready了。
3.jpg
GemFire可以接收前端的请求。中间 Greenplum做各种分析,包括基于文本的分析,基于地理的分析,对其他操作语言提供接口来进行相关的复杂的机器学习的分析。在后端,我们会对接很多业界产品,无论是 AWS 的 S3、Google 的 GCP、微软的 Azure还是 Hortonworks等等,都是可以在这种数据架构中为我们整体来服务的。
对于GemFire,它在数据温度中是在hot一端,Greenplum是在warm一端。后端是在cold这端。主要是基于两方面来综合考虑的:一方面从数据存储的数量,另一方面从需要的响应时间和承载的并发请求数方面,综合来考虑进行分层的。
那么GGC在哪里呢?GGC就在GemFire和Greenplum之间进行互联,可以进行数据的高速整合,也可以进行分析结果的互相传递。
GemFire和Greenplum进行联合的四种典型的场景
场景1
如果前端有很大量的并发请求,例如到万、到十几万的小颗粒度的写请求的时候,Greenplum的产品因为主要是靠近于分析域,所以对于这样请求的承载度并不如GemFire好,可以把GemFire放在前端来承载这些并发请求,然后GemFire作为一个write buffer,把这些写请求cache下来,然后批量写给Greenplum,来分担整个系统的写的压力。这是第一个场景。
场景2
在Greenplum中可能有大量的分析的结果,这些结果如果是对外开放的,可能会有所有的最终客户都可以访问到的这种结果,这种情况下可以把结果放到GemFire里,由GemFire接收前端所有的查询请求。这时候,GemFire就变成了一个read cache,就是一个读缓存,它可以承载所有前端读的请求。
场景3
如果需要一个事中的处理,在事件发生的过程中对它进行处理,可以做到什么地步呢?在 GemFire 接收前端的写请求的同时,同时展开事件的分析,分析结果完成之后把 GemFire 的分析结果作为反馈,反馈给前端也好,作为结果保存给 Greenplum 也好,都是可以做的。可以把事件从事后分析的级别调整到事中分析的级别,这对于风控系统,对于很多交易系统来说,还有反欺诈来说,都是非常关键的一步。
场景4
假如在一些系统需要根据不同用户提交的数据对它进行分类和级别的判断。而且这种判断是要随着整体数据量的变化进行不断地学习和调整的,这种时候该怎么做呢?首先基于 Greenplum 对历史数据进行分析、进行建模,获得相关的模型。然后把这个模型返身实施到 GemFire 中,由 GemFire 根据这个模型的内容,对于前端的输入请求进行不断地分析、判断。这样就在 GemFire 和 Greenplum 之间形成了一个正向反馈,有更新的数据提交给 GemFire,GemFire 可以迅速判断。GemFire 把这个数据落到Greenplum 中,由 Greenplum 对它进行历史模型的学习,学习完了之后,把结果重新更新给 GemFire,整个循环达成了,这个系统的数据是可以不断向前迈进的。
我们在美国的公共事业行业有一个非常大的客户,它既是 Greenplum 的客户,也是 GemFire 的客户。但是该客户面临了一个困境,它有很多数据分析产品可以做成模型,可是做出来的模型可以有JAVA语言的版本,但是做不出SQL的版本。这是它的第一问题。
第二个问题,客户有很多既有的历史系统是对接SQL的,需要访问Greenplum来获得相关的分析结果。
客户每天需要把大量的数据从 Greenplum 传给 GemFire,也需要把 GemFire 里分析好的数据再传给 Greenplum。就是数据要在两个存储介质之间进行互传。在那个时候是没有GemFire Greenplum Connector的。那么他们是怎么来做这件事呢?
手动写代码,通过 JDBC 从 Greenplum 中拿到数据,然后写给 GemFire,GemFire也把自己的数据通过 JDBC 写给 Greenplum,这样做,开发量很大,并且随着系统数量的增加,这种联系、这种阶乘关系增长速度是非常快的。
他们当时向我们的产品经理、产品管理团队提出了这个需求,表示他们需要一个中间的连接组件。然后我们的产品管理团队评估了这个组件,是有典型性和代表性的,也是可以在整个业界通用的。所以我们的研发团队组织了一个大概五六人的小的团队,快速的把这个组件开发出来,这个组件在2016年随着 GemFire 9.0 的GA正式发布出来,到现在这个组件也在不断向前演进。
参考案例
案例一:反欺诈系统
在反欺诈系统中GemFire能做什么呢?
4.jpg
GemFire 在机器学习的场景,根据 Greenplum 运行出来的模型来判断当前这笔输入是否是正常的,是否是系统允许的,对它进行判断。如果发现这笔操作有可能是欺诈或者是有问题的,那么 GemFire 会把这个操作直接提示出来,返回给调查员,由调查员对这个内容进行分析。这个场景也是事中分析,在交易发生的过程中,GemFire 就已经介入,对请求根据 Greenplum 提供的模型进行判断。
在这里使用 GGC在做什么呢?一个是把 GemFire 那边接收到的交易数据通过 GGC 批量地写到 Greenplum 中。另一个是通过 GGC 把 Greenplum 中更新好的模型返回给GemFire,用做以后交易的判断。所以在这个架构中,GemFire 和 GGC 在这里实现的功能是非常核心的,可以作为以后项目的一个参考。
案例二——某省移动实时区域人流计算分析
分享一个去年国内某用户实施的项目。它实际上是使用 GemFire 做人流的分析,人流的分析并不是无目的性的,目前主要是针对一些旅游的景区来做。旅游业在快速发展,面对快速增长的旅游市场如何快速高效的管理,统计,分析各旅游景区的特色服务,来访游客,同期比对等数据为各景区提供高价值的信息服务是目前急需解决的问题。
5.jpg
如果某一个景区接待的旅游人数是超限的,这时候景区应该启动相关的措施对人员进行限流、分流,而不是等到大家都排队,排到索道上,或者排到登山的阶梯上,然后再关闭园门,这样就太晚了。所以这时候也对计算的及时性有一个比较高的要求。
而且, 大家都知道在旅游的黄金时间或者长假期间,各个景区人流是聚集的,聚集的人流会对移动运营商有很高要求,如何保证信号质量,如何调整基站,如何优化,如何增加。如果没有这样的数据,拿什么作为基础?如何知道哪个景区要加多少基站是正常的,如何知道哪个景区需要临时调配多少通信车辆才可以承担这个景区的通信请求。所以这些非常具体的业务,都是依赖于非常基础的计算数据才可以进行判断的,这也是这个场景中为什么要进行计算的原因。
6.jpg
这是改造之前的一个场景,可以看到业界中都在流行的一些产品,包括Kafka、Storm、Redis,最后是Greenplum作为最后的分析库。
在这个架构中,看起来是非常漂亮的,但是存在着哪些问题呢?第一,Redis只能存储,不能用计算,需要使用其他服务器作为计算服务器。在Redis进行数据的快速存取,这都是没有问题的,但是不能用做计算。这个架构图上横向的箭头,指的就是需要依赖于其他服务器从Redis上取数据,把数据拉回去,计算好了之后,再把计算结果放回来,这样的过程。在这中间涉及到要把大批量数据通过网络传输,这是非常耗时的。在外部服务器进行计算,也会非常耗时,因为它并不是在本地内存计算,然后再把计算结果放回去。如果计算结果比较小还好,如果计算结果是比较大、比较复杂的,那么再把这个计算结果放回去,还要再耗一遍时间。就像把一头大象从冰箱里拉出来,切好、做深加工好了之后,再重新放回到冰箱里一样。
第二,这个整体架构中并不是HA的。Redis Cluster中有一个精确的说明:Redis的Cluster是不保证强一致性的,这意味着在 master 和 slave 之间是会有数据上的差距的。所以这个客户为了保证在整个集群中能达到同样的数据,它在这里使用了单点Redis。这种时候这里就会产生另一个问题,导致整个架构不是HA的。
是不是使用了一个 Cluster 的 Redis,这个架构就是HA的了?这也不是完全HA的。因为数据节点是有差的,这种时候不叫做HA。
第三个问题,再往下看,这个架构中存放数据是非常快的。无论Kafka、Storm,还是Redis,都会很快,Greenplum存放结果也会很快,但是计算耗时非常严重。二三十万的数据可能要耗时达到分钟级,这是一个非常恐怖的数字。
调整之后是什么样呢?
Kafka、GemFire 通过 GGC 连接 Greenplum,这个技术架构的特点是:
7.jpg
首先,整个体系架构是完整HA的架构,没有单点故障。
第二,GemFire既作为数据的存放平台,支持并发计算,也作为数据的计算平台,同时这个计算平台是计算性能非常好的,而且它的计算性能是可以随着节点数量的增加或者CPU数量的调整线性增加,达到进一步提升,满足未来的要求。
第三,使用 GGC 在 GemFire 和 Greenplum 之间是一个非常简单的连接,通过XML这样的文件,把 GemFire 中的对象属性和在 Greenplum 中的 table 中的 field 进行mapping之后,就可以进行相关操作,所以它非常简单。
另外,因为GGC是基于GemFire的数据节点,cache server,和Greenplum里面的segments之间的并行互联传输数据的,所以传输数据的速率是非常高效的。
文章一开始介了GGC的场景中说的四个场景,这个场景属于第三个场景,即在GemFire里计算完结果,把结果写到 GGC 中。再畅想一下未来,如果未来想做一些更复杂的事情的话,甚至可以把 GemFire 在这里面根据手机的信息做一些实时的分析或者实时的告警,这也是可以做到的。
8.jpg
这是优化调整的结果。当测试的数据量和第一期上线的数据量是50万,最终目标是要2700万,计算的频次是5分钟一次,POC的结果是17秒分析50万数据。对比之前Redis调用其他计算服务器这种架构达到分钟级来说,这是大批量的提升的。而且要注意,这里 GemFire 计算的是50万数据,之前Redis计算的是大概二三十万数据。做数据的人知道,随着数据量增加,响应时间是会翘尾的,不是线性的。之前Redis是20万数据2分钟计算完毕,到50万的时候,可能要达到10分钟,一定不是线性的。
在生产环境中,会是13秒。为什么?生产环境的CPU性能比测试环境要好,所以这也验证了,随着计算资源的增加,在 GemFire 上你会获得计算结果或者响应时间上非常好的回报,这也是 GemFire 平台的一个特点。你对 GemFire 平台的投资,它会持续给你回报,它不会到某一个时刻来说,“对不起,我到边界了,你再另建一套吧”。GemFire不会,GemFire可以增加节点,也可以调高节点的配置。只要用户目前有这样的资源,GemFire 就可以承担这样的请求。这样的平台,才可能满足用户目前只有50万,以后可能增加到几百万、增加到上千万,最终变成2700万的目标。这是 GemFire 的平台可以做到的。
在这种场景中,通过GGC这样的组件,GemFire 和 Greenplum 进行联动,通过GemFire计算完结果,Greenplum把这些结果进行保存,同时业务中还可以对这些结果在Greenplum 中进行更详细的分析。这是使用GGC这样的组件带来的一些好处。
结语:2 slogans
第一个,在GemFire的世界中,大家经常说的“Scale your data services on demand to support high-performance,real-time apps”。以前做技术的人经常会有这样的对话,前端的业务人员或者项目经理跟技术人员说“你要把这个业务调整成什么样”。技术人员会直接跟他说不可能,因为数据架构做不到。但是随着近十几年或者近十年的数据方面的发展,使用 GemFire 或者使用 Greenplum 这样的产品,会极大的扩展前端实现新业务的可能性,甚至技术人员会更主动的去跟业务人员说,我们的系统能承载更多的业务,这样可以推动整个公司、整个集团的业务的向前发展,我们有信心来做到这样的事情。
第二个,“Performance is key,Consistency is a MUST”。没有一致性的性能是没有任何意义的,因为这样会导致在运维中造成更多的问题。另外,没有稳定性的性能对于系统来说也没有任何意义。没有稳定性的性能意味着以后要无休无止的踩到同一个坑里,需要不断投入进行修复。
希望大家根据自己的需求,选择适合自己的、性能最佳的,比如Greenplum和GemFire这类产品来为自己的系统保驾护航!

回复

使用道具 举报

已有(1)人评论

跳转到指定楼层
耀磊科技-小丁 发表于 2018-4-24 09:40
江苏省服务器:
镇江电信:双L5630/32G/1T/20M=599元/月
江苏100G高防电信:双L5520/16G/1T/1IP/20M=999元/月  
江苏100G高防双线:双L5520/16G/1T/2IP/20M=1099元/月  
江苏100G高防三线:双L5520/16G/1T/3IP/20M=1499元/月  
江苏100G高防BGP:双L5520/16G/1T/1IP/20M=1599元/月


河南移动BGP线路服务器
双L5630/16G/1T/20M独享/1ip=399元
双L5630/16G/1T/100M独享/1ip=999元

更多服务器配置请联系qq:82159753
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

Copyright © 2001-2019 Comsenz Inc.  Powered by Discuz! X3.4  渝ICP备17007481号-6