实时计算数据平台建设的思考

爱数据精选
爱数据精选
爱数据精选
380
文章
0
评论
2021-03-0310:34:56 评论 85 4372字
摘要

为了尽量能比其他领域的开发者维持相当的发量,实时计算平台的建设,就势在必行。本文将从需求与风险、试试计算平台组建分析由上至下地阐述对平台建设的一些思考。

随着信息技术的不断发展,各行各业产生的数据,在指数增长。面对各种不同的业务需求,对数据的敏感度、敏捷度要求都越来越高,因此,实时计算框架较传统的计算框架之上,异军突起,不断被应用与各行各业的各种场景。也因此,大数据领域的实时计算开发者,不断地被要求实现各种场景下以前可能是用离线调度等方案完成的形形色色的需求。也因此,如果没有完善的实时计算数据开发平台,实时计算的开发者,每做完一个指标,面对的风险和压力都在升级。

为了尽量能比其他领域的开发者维持相当的发量,实时计算平台的建设,就势在必行。本文将从以下几个方面由上至下地阐述对平台建设的一些思考。

一、需求与风险

从最近的社区团购大战可以看到,互联网创新的风口已经少之又少了,只要被资本嗅探到气息,就毫不犹豫冲进去,所以,已经冲进风口的互联网企业,对商业的运营就需要有更敏捷的方式,更及时的数据支撑。业务上,面对平台已注册的用户,都要想尽办法留住用户,和激发新用户。因此,非常实时和能快速迭代的开发方式,就需要不断被满足。同时,数据的正确性,以及平台的稳定性,都会被第一时间被老板所察觉。而一旦关键的数据,未被及时察觉,带来的后果可能就是对运营侧决策的失利,以及公司收益的损失(例如某东被薅羊毛事件)。

二、实时计算平台组件分析

1、需求

当前,实时计算平台开发需求的流程简单来说一般为产品或运营端提出需求,实时计算数据开发者分析需求,实时计算开发者向业务端索要埋点数据文档,实时计算开发者接入数据并写一个作业扔进大数据集群中,实时计算开发者将数据写入业务端或BI端,业务端或者BI端使用实时开发者生产的数据。这个过程看起来是没有问题的,随着业务的不断增多,计算任务数量的不断增长,计算过程中使用的数据源和维表以及其他接入的组件越来越多,当数据源或者维表等进行迁移,亦或者集群资源不够时,到底是下线哪些已经不需要关注的作业还是扩容集群队列?

都将是令人头痛的问题。因为繁多的实时需求,你可能已经忘了两周前你做的一个指标中使用了哪些东西,更何况更早或者你接手了别人的东西,或是需求方人员变动频繁。所以数据平台在需求端,能把控的东西可能是需求清单的创建。那么大致流程是这样的:

实时计算数据平台建设的思考

这样,我们对每个需求产生的数据,以及数据结构和数据的应用场景进行了登记。同时对需求所涉及的数据表和数据源信息也进行了登记,又对数据的业务方进行了登记,这样就解决了上述提到的问题。即便如此,我们的数据平台仍是不完善的。

2、埋点

上面说到,业务端通过编辑登记了当前的数据源,亦或者登记后,我们也获得了当前数据源的文档格式,我们的实时计算平台开发者拿到了这些信息后,即可进行指标开发了。但由于客户端的环境不同,版本不同,同样的埋点事件,可能采集上来的埋点日志格式,就千奇百怪,可能开发时完好的作业,在集群上跑半个月后,突然就由于空指针异常或其他异常,导致作业异常finished。所以,埋点日志版本的管理,就非常重要。

因此要保障作业的可维护性高,上线后运行稳定,就需要有一套埋点日志发布系统。通常来说,我们的埋点日志都是标准的json形式,因此,我们设想,如果前端能够描述埋点日志中每个字段的具体位置,以及具体类型,和该字段应该有的值,那么,我们就可以生成这样一套规范,来验证我们需要上线的埋点日志,是否满足当前规范,如果不满足,则说明埋点日志打错了。这样,只有通过验证的日志,才能被发到线上环境,就解决了这个问题。所以,当前的解决方案就是,通过前端编辑的每个字段的一个描述器信息,后端将描述器信息,翻译成一个简单的json-demo,并生成相应的json-schema,这样json-demo面向开发者一目了然的感知埋点日志的格式,而json-schema则用来校验客户端上报的埋点。

这个问题就解决了。通过我们定义的描述信息生成json和json-schema的功能已经实现,而网上暂时未看到有相关案例,所以后续代码会分享出来,供有需要的试试计算开发者借鉴。

3、校验

数据质量的持续验证,其实算是数据治理中的内容之一。当我们埋点日志是正确的,我们的整个链路也是登记过的,我们的作业编写完成就可以上线了。那如何能证明我们的输出输出结果也是正确的呢?把标准定的更高点说,如何能保证我们的作业运行的结果永远是正确的呢。最好的答案目前或许没有,但我们可以通过一些规则,来对产生的结果进行验证,如果验证结果和预期一直是一致的,那我们就认为作业的输出一直是符合预期的。

所以,大致的方案应该是这样的,比如我们的作业要再平台发布线上,那我们采集一些测试数据,放入到测试环境,同时通过SQL或者其他查询手段,在业务库或其他数据源把预期的结果检索出来,然后我们把检索使用的条件,在实时计算产生的结果库中,把实时计算的结果检索出来,根据根据两侧检索结果,进行比较,如果多次验证结果一致,那么我们的作业可以发布到线上环境。同时,再为这样的校验规则,配置上定时调度,那么我们的作业就相当于有了一个持续验证的过程,对于我们的业务正确性,有了一定的保障。

当然,我们的作业类型可能有很多种,比如ETL、或者纬度生产作业等,我们的结果输出位置也有很多种,比如Redis、mysql、hbase、elasticSearch甚至kafka等,所以对于数据的持续验证,也是一项挑战。当前已经实现了可配置的Redis、mysql、hbase、elasticSearch之间数据的互相验证。由于不涉及具体业务,后续会将这部分代码开发出来。

4、 异常检测告警

说到异常检测告警,大家可能都不会陌生。不管是业务系统,还是实时计算领域,还是服务器运维工作,都需要在环境异常时,能够第一时间进行告警,让管理员来处理这些问题。目前通用的告警方式有很多种,常见的有钉钉告警、短信告警、电话语音告警、微信告警、邮件告警等通知手段。但是仅仅完成了这些,也是远远不够的。因为当一个系统组件越来越多,监控项目越来越多,需要通知的人越来越多时,我们对告警的配置过程,也是相当的繁琐,当告警需要下线时需要下线时,告警需要更换通知人时,都需要进行操作。所以,一套可以自动上下线告警任务的系统,并且能够通知到告警的人的系统,是非常重要的。而说到异常检测告警,那么这部分就可以分成两个部分,异常情况的检测部分,我们称之为告警的前端,和告警消息发出部分,我们称之为告警的服务端。我们上面说到过,假设我们的实时计算作业的需求提出,作业数据源的消费状态,作业创建和提交,作业产出结果的输出,作业输出结果的正确性等,都可以作为异常检测的内容,进行自动告警处理。

那如何实现这种告警机制呢?我们可以结合zookeeper的临时节点来进行实现。说明一下:zookeeper的临时节点即客户端在和服务器保持会话状态时,节点将一直存在,当客户端销毁时,临时节点则自动销毁。所以,但我们开始运行我们的作业时,flink的jobManager则可以创建一个会话,与服务器一直保持链接。

当作业异常finished或者被kill掉时,则临时节点自动被销毁,我们告警检测端则可以监听创建和销毁动作,来加入和移除监控作业。但是由于临时节点下不能再创建临时节点,所以需要在zk上按照不同的监控项创建永久节点,在永久节点下去创建临时节点,不好的一点是,当某个主题不在使用时,需要手动删除该节点。但是从zookeeper3.5后,新上线了一个容器节点,而容器节点则会在自己的节点下所有的节点移除后一分钟,容器节点也自动销毁。所以我们可以采用容器节点实现这项功能。

而告警的发出端,也即服务端,需要对告警采取很多特殊的处理,比如按照特定的配置,将告警发给不同的人,亦或者当告警没有被标记处理时,告警手段进行增强,比如由钉钉升级到短信或电话方式。再或者,比如告警的增强,当服务器挂掉时或者grafana的告警一直没有恢复时,可能会只发出一次告警,而这类告警信息,通常又是非常重要的,所以当告警服务收到告警时,需要托管此类告警,并继续发送,直到有人处理,解除告警。告警的抑制,比如,某类告警通过定时轮训发出,如果一直未被处理,不希望告警按照同样的频次发送,则需要对此类告警在告警发出端进行收敛,所以我们就需要告警抑制的功能。

目前作业自动注册加入告警监控队列和销毁移除告警监控队列,以及告警发出端的通过模板配置告警内容和告警增强告警抑制,以及抑制策略,和支持不同告警方式的功能均已实现。由于该部分代码不涉及具体核心业务内容,后续将会分享出来,供大家借鉴。

5、自动化作业

如果以上所以的流程都已经实现到了大数据平台中,是不是就已经代表了数据平台较为完善了呢?我个人认为,答案是否定的。因为,随着数据平台作业的不断开发,会发现大部分作业的在使用flink做计算时,代码几乎是一样的,而不一样的部分,基本在数据的拉平和组装上,所以我们经常会copy一份代码过来。copy其实并没有错,但是经常copy过来的代码,会有些遗漏忘记修改的地方,这就造成了数据输出结果健康度的不稳定。所以,我们可以猜想,是不是可以通过一种构建描述器的方式,去生成这样的作业,并输出结果呢?有人肯定第一个想到的就是flink-sql。

这里要说的是,sql作业是对flinkstreaming作业的高阶封装,其中状态过期部分的管理,是不太灵活的,这就导致了即便有的作业,设置了state的TTL,但是作业的state仍然在每天一点的网上累加,直到有一天状态无限大,cp超时失败或者严重FGC的情况。而有的作业是跑了很久的作业,又无法杀掉重新跑,只能不停的加内存解决。

所以我们自己的作业在很多开始使用了sql,后面又改成了streming作业,状态从无法控制的几十个G,到每天稳定的只有几个M。那如何实现这种自动化作业呢?我们可以参考一下ElasticSearch,对于ES来说,我们插入进去的都只是json-doc,即便是嵌套多层的json,或json中又有数组,但ES仍然可以按照自己的语法去分析去聚合或去重等。

所以,我们通过前端界面去生成自动化作业的第一步,就是解析出json,通过点选,选出纬度,选出指标,选出计算方法,选出窗口大小等,那就相当于一个作业生成的部分就完成了。所以自动化的去生成任务,也并不是不可行。由于这部分功能目前处于构想阶段,后续实现后会开房出来,供大家借鉴。

以上各个部分的描述,基本上为大家展示了,实时计算平台最基本需要哪些组件构成,以及这些组件的实现思路。可能有些地方描述的不对,或者没有描述的足够清晰,希望大家能够谅解。

End.

作者:曹操

来源:小鹿吃小草(微信公号)

本文为转载分享,如果涉及作品、版权和其他问题,请联系我们第一时间删除(微信号:lovedata0520)

  • 我的微信公众号
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
匿名

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: