在CloudEdge中,通过ES实践解决ElasticLog产品问题

  • 时间:
  • 浏览:0
  • 来源:uu快3和值_uu快3app_计划师

ES 在 ElasticLog中主要负责三件事情,第一,主要用来放另一个月的热数据,即每分钟有17万条数据进入,都要提供的是秒级查询;第二,ES应建立在AWS上,都要另一个专用主节点与八个数据节点,其中主节点指M4.Load,数据节点指C4.2xBug;第三,它最多都要考虑28个指标参数。

在ES服务中,WAS是首选的服务,因为 WAS也能提供相对可靠的ES服务,否则 是全托管的服务。它也能从否则 集群的维护中解放出来,更多的集中在怎样用ES把业务实现。当ES服务达到一定临界值时,让WAS去管理ES服务。另外,在ES服务中,WAS具有区域意识、易于使用、VPC+安全组、蓝/绿部署以及监视器+自动快照等特点,同类,区域意识指也能在不同的机房将数据进行备份。

首先,通过另一个Spark Streamingtcp连接把数据源源不断地写进ES里去,接着,Spark调用ES-Hadoop库把数据写进ES当中。非怎样快速地将Spark里的数据写到ES里去呢?除了调整否则 ES参数以外,还都要将Spark进行并行计算和ES进行并行写入,使得并行task执行的个数等于集群总共拥有的vCores个数,最终两者对接实现资源的最大利用和快速地写入。

在ES实践中,它是将分钟维度数据聚合成小时维度数据的,这就因为 将数据写进ES时是分钟Index,过一段时间后自动转加带小时维度Index。非要查询时它是怎样将分钟Index切加带小时Index的呢?因为 是Index提供了另一个aliases功能,从前数据一现在开始指向分钟Index,当分钟Index服务周期到了后,自动切换到小时Index,其中整个切换在数据的聚合中间去完成即可。

在上文讲的架构中,因为 Spark在做并行运算不会把任务分到每个task中间去做,因为 另一个task写入ES中失败了,非要Spark在task中间就会重新写入,从而因为 数据一直出现重复。要想将重复进到ES的数据去重,也能从使用自定义唯一ID、使用聚合来发现克隆技术和删除文件以及做明确的查询另一个方面入手。

CloudEdge是一款自注册、自配置、自充值的网关产品,它也能分为两部分,一部分是硬件,另一部分是盒子。CloudEdge通常部署在客户网络的进出口,所有的流量不会经过本身盒子进行安全扫描,并做相应的流量控制。

上图是ES实践中的另一个设计案例,在本身案例的设计中需做否则 考量的性能。第一,ES中间非要放另一个doc,因为 存放另一个同名的doc都要字段类型一致,且多个doc类型因为 不被支持,也不另一个Index仅需存放另一个doc类型即可;第二,因为 客户只在乎查询结果,不考虑数据是哪此,非也也能将source关掉,从不会有效地节约存储空间;第三,all的数据在做Index时也能做到将所有的数据聚合起来,因为 只查找 某一段的数据则可把all关掉,从前不仅也能使空间的利用率得到有效地提升,还能使性能得到优化;第四,也能将dynamic改为strict。

经过以上处里后,理论上处里了大大问题,但实际上还都要进一步的延伸。第一,对ES中间的数据进行聚合,即数据进去是以分钟单位计算的,出来时都要聚合成小时单位;第二,将一直查询的数据装到 ES中间,剩下的数据装到 S3中间;第三,对装到 S3结构的数据进行查询,目前对装到 S3结构的数据进行查询的最好的方法是用AWS提供的Athena服务,并用托管的最好的方法去搜索S3上的数据,最后提供另一个ECS供用户去查询数据。

非要在有了Index的基础上,怎样去合理的分配Shard的个数呢?另外,Shard是落在不同的集群上,又该怎样去确定大概的集群大小呢?具体介绍如下:

在设计好Index时候,进行读取数据量,并估计每周以至每分钟有好多个数据量送进来。估计数据量的大小时候基本就也能确定Index有多大以及都要好多个个Index,接着确定磁盘空间以及都要好多个机器设备。进而算出Shard的个数,其中Shard的个数是数据节点个数的k倍,且建议每个Shard存储不得超过30GB。最后进行相应的测试、调整以及反馈,经过几轮测试后,基本就也能确定业务大概都要哪此样的集群,本身集群都要多大了。

2018 Elastic Meetup南京交流会,由赵伟带来以“ElasticLog with ES in CloudEdge”为题的演讲。本文首先介绍了CloudEdge与ElasticLog是哪此,其次介绍了产品的构架图以及ES的作用,最后介绍了ES在实践过程中都要设计Index、分配Shard、快速将Spark里数据写入ES中和数据去重。本文提出的产品因为 处里了否则 瓶颈大大问题,但还有否则 大大问题仍在路上。

数十款阿里云产品限时折扣中,赶快点击这里,领劵现在开始云上实践吧!

直播视频回顾以下内容根据现场分享埋点而成。

ES的实践包括八个部分,第一部分是怎样去设计另一个Index,使它也能很大程度上影响到class的走向;第二部分是Shard的分配,即在指标中间放好多个个Shard是大概的;第三部分是快速的将Spark里的数据写到ES里去;第四部分是数据的去重。八个部分的完整篇 介绍如下:

设计Index有本身形式,第本身形式是只设计另一个Index,但整个tcp连接建立起来后否则 地方都在能进行修改了,只适用于小型数据;第二种形式是按时间去分割,即分割成每周另一个Index或每月另一个Index,也能有效地处里数据量的大大问题。

CloudEdge对流量进行扫描并进行控制后,会产生少许数据,同类网络访问相关的数据等。Project ElasticLog是负责将不安全的数据进行拦截,接着将所有的数据按照一定的格式写到软件中,让用户也能看一遍我本人所都要关注的信息。最终通过盒子产生数据,Project ElasticLog负责将不安全的数据进行拦截后,做出跟业务相关、数据相关的scalable 系统。

CloudEdge产品主要面临着三方面的大大问题,第一方面是怎样快速处里、快速存储少许数据量的大大问题,以供用户去查询。第二方面是要满足用户时候查某个时间段的数据不需查整段数据的需求,研究人员应当怎样做。第三方面因为 产品面对的是日本客户,日本客户比较谨慎,亲们追求数据第一根非要丢,第一根非要多的精确度,研究人员应当怎样做。

目前此架构因为 基本实现,但在部署上依旧占据 否则 大大问题。在上图的架构中,浅蓝色部分是数据的走向,直到数据落地,绿色部分负责数据落地后用户查询数据。在上图中,首先,Client负责将数据聚合后上传到Log receiververs上,其中Log receiververs是部署在AWS上的。其次,Log receiververs将数据上传到Kinesis stream上,其中Kinesis stream是负责托管服务的。再次,Kinesis stream将数据上传到经典的生产消费者模式区域。最后,数据传输到下游,下游中一部分负责把数据源源不断的写进ES里去,另一部分负责把数据做相应的解析后写进S3里去,其中S3是负责存储服务的。