时序数据库选型

发布 : 2019-04-29 分类 : db 浏览 :

流计算平台设计

前言

flink已上paas,接下来的事情就是如何打通业务系统与flink。它们之间并不是一个简单的kafka解耦就完事的。比如利用flink的实时计算结果阻塞式地影响业务的控制流。都需要一个数据平台来对接业务系统。那么这个平台就是使用flink的stream和batch的结果来影响业务。

metrics是java版的指标度量工具,在JAVA代码中嵌入Metrics代码,可以方便的对业务代码的各个指标进行监控,同时,Metrics能够很好的跟Ganlia、Graphite等结合,方便的提供图形化接口。只要使用java语言的开发的中间件,如果要做指标度量,基本上都会使用它,如大名鼎鼎的kafka也是用它来做指标的度量,binlog监听中间件duckula也是使用它做指标的度量。

flink stream与metrics虽然风马牛不相及,但仔细观察还是有些共性的。

  • 它们都可以用来计算指标,只不过flink是分布式的,且有完善的checkpoint机制。 而metrics只是内存模式。
  • flink支持时间窗口,窗口也可以部分重叠。metrics也有1分钟、5分钟、15分钟的指标,对于某一个时间点来说,肯定会落在不同的统计周期内。
  • flink的计算由算子支持,也可以自定义算子,非常灵活,可以自动配置,但也带来了学习曲线。metrics则只提供五种类型的指标度量:Gauges、Counters、Meters、Histograms和Timers,只需按照它的标准给它喂数据,它就能跟据不同的类型导出不同的指标。
  • flink的开发只要是集中的算子的使用 ,metrics开发集中在如何按指标度量要求喂数据。
  • flink重点在于实时计算,metrics重点在于指标监控。
  • flink总的看来什么都要自已动手设计,而metrics总的看来就是一套指标计算标准,没有定制的可能。

流计算平台重点就是支持flink stream和metrics两种指标计算模式。

总体结构

1558947715754

这里流计算平台借用了flink的一些概念,整合了flink和metrics两种指标计算框架。

  • 数据来源,主要是通过binlog监听与kafka等MQ来做数据的实时推送渠道。做到后期,可以提供SDK供业务方接入,业务通过SDK主动推送到流计算平台。也可以利用java的Agent机制跟据需求动态拦截业务各接口的输入输出数据(这个要求业务的接口标准化做的较好,但它是无侵入的,业务无感知,效果较好)。
  • Source:对于不同的实时数据来来,我们需要有不同的source模块来对接。
  • opreate:指标计算框架, 所有的source都可以驱动计算模型,前期只要集中在flink stream和metrics这2种计算框架,如果有必要,像spark等计算框架也可以纳入其中。
  • sink:存储中间件,指算框架的结果需要有存储,跟据不同的场景需要,我们可以选择不同的存储中间件。比如:需要主动推送给业务方,那我们可以选择kafka等MQ进行推送。有查询及分析需求,我们可以落Greenplum,redis等。需要grafana来显示监控指求,可以考虑落InfluxDb等。
  • Interface:原则上Sink不允许业务方直接访问,需通过Interfac来交互。这里面可能大部分是阻塞式的接口,接口可以采用轮询或是推送的的方式在存储中间件拿到结果,返回给业务方,业务方跟据实时计算结果影响业务流程。

数据流示意

1558949382249

说明:

  • kafka可以聚合duckula监听的数据(可能有多实例,比如2.0和3.0的数据)

  • Flink的主要数据来源是 自研的binlogSource(单实例)和 kafka。

  • Flink的sink主要是influxDB(指标计算展示)和kafka(主动推送),Greenplum(指标分析,batch操作导入)

  • kettle可以做T+1数据的计算,导入到Greenplum

  • metrics计算的结果可以直接入influxDb供grafana展示,它是以独立java进程的方式启动,利用k8s做ha。

  • Application是我们的主体部分,跟据Greenplum和InfluxDb结果提供同步和异步接口供业务方调用。

  • 配置中心主要使用 zookeeper来完成,还会起分布式锁的作用,metrics的java进程保证一个配置只启一个实例。

  • ops用于界面的方式配置metrics和Application关键配置。也起到管理metrics进程的作用。后面可以考虑把flink的job提交纳入,一站式运维操作。

Application结构设计

application主要是集中在core范围内,

  • Ops:就是application的用到的各参数界面化配置
  • Paas: (没考虑成熟)主要用于如metrics进程的paas发布,新增接口的发布,configmap等配置信息的发布,这些不是标准的项目,不适合猪齿鱼。整个application的项目发布还是走猪齿鱼的。
  • Influxdb。。。是数据存储层
  • Service是接口的服务层
  • 接口层:提供与协议无关的接口服务,如统一输出数据编码、输入数据较验等。
  • 协议层: 有了接口层,协议层要做的就是跟据不同的协议转换接口需要的输入输出数据。

总结

metrics进程这块参照了duckula相关设计。application的总体的定位是一个业务中间件。流计算平台就像一个粘合剂,把一个个中间件粘合在一起供业务驱动。总体来说稍感复杂了些。由于这是初稿,并没有定型,各位同学如果有好的建议及想法可以与我交流。非常感谢。

本文作者 : andy.zhou
原文链接 : https://rjzjh.gitee.io/2019/04/29/other/flink-stream/
版权声明 : 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明出处!

知识 & 情怀 | 二者兼得

微信扫一扫, 向我投食

微信扫一扫, 向我投食

支付宝扫一扫, 向我投食

支付宝扫一扫, 向我投食

留下足迹