开源最大的特征就是开放性，云生态则让开源技术更具开放性与创造性，Elastic 与阿里云的合作正是开源与云生态共生共荣的典范。值此合作三周年之际，我们邀请业界资深人士相聚云端，共话云上Elasticsearch生态与技术的未来。
本篇内容是Elastic中文社区副主席吴斌带来的基于流式计算平台搭建实时分析
分享人：Elastic中文社区副主席吴斌
本文将通过三个部分展开分析基于流式计算平台搭建的实时分析应用中Elasticsearch的实战分享：
- 面向开源产品的架构设计
- Elasticsearch在流式平台中的角色功能
- 云原生与k8s集群管理经验分享
众所周知，Elasticsearch本身是一个搜索引擎，随着演变和发展，现在它的数据分析能力也非常强大，但它并不是一个万能的引擎，它也需要借助生态的支撑。然后把整个实时分析应用的平台搭建起来也是非常重要的一点，所以今天我们分析的角度是在于Elasticsearch本身是如何借助生态的，在这个生态当中自己又处于一个什么样的位置，最后我们会聚焦到Elasticsearch本身应该如何去实现快速简单、具备弹性、通用性的一些部署。
一、面向开源产品的架构设计
为什么要面向开源产品去做架构设计？很重要的一点是增加平台的通用性和一致性。如果想让整体的架构变得易于维护，不可避免地要借助云平台的一些能力，但又不能跟这个平台完全绑死，这种情况开源产品在这些平台上的一些实现，就是一个更好的选择。
轻松定制化业务，专注低学习成本
面向开源做架构设计，除了它的开放性和灵活性之外，你还能轻松地定制你的产品，我们的开发和运维人员也可以更多地专注在业务本身上，而不是花更多的成本去学习一些商业产品。开源产品的学习成本本身就比较低，因为在互联网上，很多视频网站上，都能获取到很多有用的资源，在中国针对Elasticsearch我们也有一个自己的中文社区，这上面不管是针对于初学者，还是对于一些非常深入的大咖们，相信都能有你所需要的一些内容。
透明、安全、合规
中国企业逐渐对安全合规的属性变得更加敏感和重视，开源产品能使安全合规这些规则变得更加透明，因为代码都是公开的，能快速地帮助我们通过合规性的一些审核，和安全机制并加固。
高度灵活性，无平台绑定
过去Elasticsearch本身不能完成所有流式平台的搭建，还需要借助生态。生态上，越多的组件引入进来，系统就会变得越复杂，维护成本就会稳健升高，如果能借助云平台的力量，运维和后期灵活的扩展就会变得相对容易，对未来假设去做移植工作也不会有太大的障碍。
【平台组件构成】
我们在搭建流式计算平台时的架构还是非常清晰的，在这里做一个简单的剖析。
首先，数据采集通常来讲是一个分布式的消息队列，它采用的发布或者订阅是一种消息的分发机制，同时还能在后面的计算和存储引擎出现问题时把消息缓存在消息队列里面。这个分布式的消息队列本身也是高可用的，当出现流量峰值，它也能对后面的存储引擎有保护作用。
当数据流进来之后，第二步就是分布式计算引擎。首先需要对进来的数据做校验，判断数据是否合法，格式是否是我期待的，有没有脏数据等等，同时还可以去业务数据库引擎里拉取一些数据，把它变得更加丰富，来辅助后期的分析。另外，现在的流式计算平台能让数据计算更加精确，这一点基于事件时间开窗的计算。而流式的分布式计算引擎本身在云上也具备弹性，且可以做热更新，这对整个平台的稳定性和扩展性来说都是非常友好的。
除了消息队列和分布式计算引擎之外，后面我们还会选择三个比较关键的引擎，其中一个就是我们主要要讨论的引擎Elasticsearch。除此之外可能还会引入高IO的KW列存，最常用的是HBase。这两个引擎在这个组合里面扮演的是对于非常热的数据的一些处理和计算，是实时的一部分。第三个引擎我们引入的通常来讲是线下的比如数据仓库或者一些MPP引擎。大家的选择面是非常广的，比如传统的HIVE，还有开源的Greenplum等等，甚至一些商业产品都可以是在我们选择清单里的一些存储，这些存储的角色更倾向于一些偏线下的计算，或者是比较温的一些数据的计算，比如过去七天的一些数据的计算，基于每天去绘制的报表和计算。在热数据这一部分，Hbase通常来讲不是一个非常必要的引擎，只是在我们有非常高IO的吞吐的场景下不得不引入它，它的核心的实时数据分析这一部分通常来讲我们还是用Elasticsearch去完成的。
基于上面这一套引擎，下面还会有两个非常重要的基础组件，这个在云端实际上也都给大家封装非常好的一些成熟的产品和底座。 如果大家是在on-premise自己的IDC机房里去部署的，还需要维护这两套系统，在本地需要有一个高性能的网络，能够支撑比如消息队列之间的消息传递，还有分布式计算引擎之间worker节点的一些shuffling的操作，也都需要通过高性能网络及交换数据，数据引擎之间的数据交换，节点之间的shuffle也都需要高性能的网络来支撑。
另外就是底层的分布式存储，这个存储的选择当然也非常多，在云端我们通常会借助对象存储来做比如分布式计算引擎的文件输出，或者数据的输出，还有错误数据的一些落地，后面的数据引擎比如Elasticsearch就会做一些数据的备份，比如说snapshots。分布式存储可以作为我们数据的一些archive，比如一些老旧数据的备份，或者在关键时刻需要重塑，可以很快地从这些snapshots里面恢复数据。
这个平台的组建实际上是非常简单的，那么在根据这些组件搭建真正的架构的时候，就可以看到上图这样的一张架构图。中间虚线部分上面是真正的业务引擎，里面有我们的服务器，还有处理业务的关系型数据库。真正的数据就是从我们服务上来的，通常来讲，比如说可能有这些服务器的日志，监控，业务上来讲，从这个业务服务器上我们可能会采集很多用户端的一些行为，比如说用户在你的平台上购买什么样的商品，或者社交类的产品、内容类的产品都点开了哪些内容等等。这些数据就会被实时地发送到刚才介绍的消息队列里面（图中左边信封的图标），在这个队列缓存里进行缓存之后，就会把它放到后面的Streaming引擎里面去。这个引擎用到了Beam这样一个驱动层，分布式计算的一个框架，它也是一个开源的分布式计算引擎的框架，只是一个驱动层。在这一方面，我们想把这个平台打造的通用性好一些，所以在这个关键的分布式计算环节，我们选择了这样一个驱动层。 它所带来的好处是比如我在一次编码之后，可以驱动不同的分布式计算引擎去帮我完成计算任务，而且它是批流一体的引擎，Beam的代码就可以驱动Flink去完成计算任务，也可以驱动很多其他的driver。你可以去做流式的处理，也可以做线下的Bash处理，这是我们选择Beam的一个原因。 当然，Beam也会有它一定的局限性，可能每个引擎之间有不同的非常独立的calculator，没有能很好地移植到Beam里面，它就不支持。所以大家在真正使用的时候，还是要根据自己的业务看Beam是不是一个非常好的选择，目前在我们服务的客户当中Beam基本上是可以满足绝大多数的需求的。
既然Beam是一个批流一体的引擎，并且分布式计算已经会做一些ETL，然后从我们的业务数据里我们可能会拉取一些业务表，来跟我们实时采集的用户行为数据或者日志数据做一些联动，方便我们日后去做分析。这个时候我们会把一些不符合或者有问题的数据输送到对象存储上面去做备份，与此同时还会把明细数据也都打包压缩备份一份放在对象存储上面以备不时之需。
接下来后面接的引擎我们就会把一些实时的数据直接注入到Elasticsearch引擎里面，去支撑我们的业务包括实时分析业务。在非常高吞吐的情况下，我们会引入HBase，就是下面介入的KV型的列存。它的列存表的设计有宽表或高表两种，是完全取决于我们的业务的，但是一旦我们引入Hbase这种KV引擎的话有一点需要注意，就是明细的数据才可能会录到HBase里面去，为了减少Elasticsearch本身的IO，我们会把一部分计算任务放在中间的分布式计算引擎里面去做。举个简单的例子，假设打车这样一个场景，用户或车辆的实时地理位置信息是非常海量的数据注入到系统里面，在这个订单当前没有完成的时候，我们都可以把这些实时高IO的数据放到HBase里面进行查询，或支撑你的业务，当这个session结束之后，把它归拢成一条数据放到ES里面去，我们在Elasticsearch里面就可以做一些实时订单的分析，轨迹，金额，或者官方的一些客服人员去对这个订单做查询和服务我们的客户。这就是ES加HBase在实时的场景是这样配合工作的，并不是同样的数据全部录入到两个引擎里面去。
第三个与此同时我们还会做的事情就是放到Data Warehouse里面去做一些线下的分析。另外，可以看到Beam还会承担一部分BASH的工作，也许我们会有一部分这种批处理的工作，在实时的数据落到对象存储之后，我们也可以定时地让Beam去驱动Flink等引擎完成后面的一系列批处理的工作。
二、Elasticsearch在流式平台中的角色功能
这个平台架构实际上也是非常清晰的，在这个平台里面我们再具体地去看一下Elasticsearch到底承载一个什么样的角色和哪些功能。
1、文本检索
首先它最主要的功能就是文本的检索，他适用的场景主要是日志，运维，开发，还有一些实时业务的客服，客服可以根据这个日志快速地找到一些订单的线索。
2、已知数据的计算
第二个功能是已知数据的计算，是一些实时指标的计算，固定的报表，实时的大屏展示等等。这些数据通常来讲，schema是我们已经设定好的，我们知道后面根据哪些指标维度进行分析，比如把它做成一张报表或者做成一个大屏等。
3、未知线索探索
另外一个非常重要的Elastic的特点，就是对未知线索的一些探索，这也是为什么我们要在实时业务中使用Elastic search的非常重要的原因，因为Elasticsearch非常的快。 当你发现业务当中有些异常的指标出现的时候，你会拿到这个线索，但你并不知道是由于什么原因导致的，可能是完全未知的一种攻击手段，并不能通过规则引擎去发现它。这个时候我们需要拿着这个线索作为一个输入，在实时的数据里面去探索，甚至结合一部分我们的历史数据，快速地进行一些复杂的过滤和筛选，然后找到跟这些数据相关的其他可能的维度和数据，甚至很快能够找到一些归因，这个是搜索引擎在做数据探索过程当中非常重要的一个特点。
所以当你的业务或分析平台需要有这样的需求时，就可以从这三个维度去思考，是不是有些实时要检索的文本，是不是有一些已知的报表的计算要展示，或者说会不会要对一些未知的线索进行快速的探索，这些都是Elasticsearch本身的一些功能和特点。
三、云原生与k8s集群管理经验分享
1、Elastic Stack部署方式
首先我们看一下Elastic Stack的部署方式，基本上是以下三种。
过去我们常用的是最左和最右两种，左边的这种是我们自己去部署，不管是在云平台的虚机上，还是在我们自己的机房里面，它的优点显然是非常通用，一致性非常好，也非常透明，你甚至可以编译自己的Elasticsearch去部署。它的缺点也是显而易见，比如大集群或集群多的时候，它维护和升级会相当困难，包括多集群的升级和数据之间的导入导出等等，并且当它出现错误时，恢复周期会变得非常长且复杂。这个对于大集群来讲不是一个推荐的方案，小集群十个节点以内就还可以。
再看最右的方案，就是以SaaS的部署方案，它的优点也是非常显而易见的，在这个浏览器里轻松地点一下就可以完成集群的一个部署和后期的运维，甚至包括升级和数据之前的导出等等。它的缺点是它的细节不透明，并且网络的一些拓朴结构，甚至自己的网络都会受一些限制，集群的入口网关的性能也是受限的。所以SaaS的好处就是非常简单，但是后面的定制化，甚至灵活性，甚至第一时间能不能得到ES的升级来讲可能都不是最好的一个选择。
根据我们去年一年的经验来看，Kubernetes上的部署会是一个非常好的选择，并且也比较成熟，这个取决于Kubernetes上支持的两个好的技术。
最早期实际上Kubernetes并不是对这种数据层产品非常友好的平台，因为它都是无状态的应用。随着operator概念的引入，它才把整个数据平台放到Kubernetes上，变成一个具有可执行性的方案。再加上ES本身自己的设计，反而让Elasticsearch本身对Kubernetes平台是非常友好的。它的优点也是显而易见的，后面会用一些典型的场景去展示。另外一点是Infrastructure as code的概念，你可以把你集群的描述放到一个压缩文件里，它就变成一个你的集群部署的结构了，后期只需要改变这个样本文件就可以改变你的部署和架构等等。第三点，在Kubernetes上的弹性非常好，只要资源够，你可以瞬间发布出大量Elasticsearch的节点。 而且相对于SaaS的方案来讲它的资源也是独显的，不会出现你不知道你的容器是否跟其他的容器部署在一个物理主机上，他们在共享、竞争着CPU的使用等等场景。
Kubernetes固然好，但是使用率并不高，主要是因为在一般的中小企业里面引入Kubernetes从某种意义上实际上是给自己平添了不少麻烦，因为不管是应用层还是数据层，都需要更多地去维护一套Kubernetes系统。 因此，这个可能简化了ES和上面应用的使用场景，但是对你的运维团队带来了另外一个维度的负担，那就是对于Kubernetes集群的维护，所以我们也是比较推荐大家在云上面去做Kubernetes，使用云端托管的Kubernetes服务来部署Elasticsearch。目前来讲，我们社区维护的Kubernetes这个版本首先还是受限于Kubernetes，因为没有Kubernetes就部署不了。第二，目前还只是一个开源的版本，ES官方在未来应该会逐步推出商业版本，大家可以时刻保持关注，我们也会第一时间来更新社区。
2、ES集群架构的预置
这里我们给出一个场景，在后面给大家预置的项目里面可以看到我们对ES的集群架构做了一个预置。我们提供了三种方案，第一个是单节点的，通常只是对开发人员的，可以让整个开发，测试，还有线上的环境完全保持在同样一个版本。第二个是全角色的节点（左上角第一张图），这里面我们对于每个节点做了一些深度的优化，不同角色的节点都应该有哪些相应的参数的调整。 可以看到，在全角色的部署上面我们把它分布到两个区里面了，如果你是在自己机房里面的Kubernetes上，你可以把它当做两个机架，我们对于数据的分布做了一个高可用，也就是说我们会让你的主分片和replica分别分布在两机架之上。
除此之外，我们还封装了一个分角色节点的部署（右下图），这个通常可能会应对一些比较大规模的集群，就是我们把主节点，数据节点，还有coordinating，Ingest界面全部分离出来，这样做的好处就是当集群遇到高峰数据的时候，你可以相应地去调整Ingest node，Coordinating node或是Data node，所以这个集群的弹性是存在的。另外我们还给大家预置了很多存储的方案，不同平台提供的底层块存储或者磁盘是不一样的，所以说这里需要根据自己所选用的平台做一些灵活的调整。
3、恢复策略
左图是数据在计算平台上的一个有向无环图，数据从上面的节点流进来之后，经过后面的计算节点做一些简单的ETL，最重要的是下面的两个输出，左边的输出是错误数据和明细数据的备份的输出，右边的数据是计算完整理后的一些数据或者是聚合后的一些数据，把它输出到ES。左边这张图就是分布式计算引擎在做的事情。
Elasticsearch本身就是中间这张图，我们会跟存储做一个关联，不管下面是什么样的存储方案，还是云上的对象存储，我们都会定期去做Snapshot。
有些人可能会提出疑问：左边备份了明细数据，中间为什么还要去做Snapshot呢？是否有些多此一举？
实际上是这样的，我们的明细数据备份之后可能不光是给ES去用，由于ES本身的Snapshot也是定时去做的，有些人可能一天做一个增量备份，有些人可能一小时做一个增量备份，假设今天这个时间节点出现问题，我用Snapshot恢复只能恢复到昨天的数据，所以说我在真正重建这个集群快速恢复我的数据的时候，在有必要的前提条件下，是Snapshot加明细这样一个恢复的策略，能让我的数据恢复到刚才集群出问题的状态。这些消息都会缓存或者阻塞在分布式消息队列那一层，所以大家完全不用担心。
右上角代码的截图是我们在Kubernetes引擎给大家做了一个叫Snapshotter的容器，它会定时给Elasticsearch做一个类似快照的URL , endpoint，然后定时地把数据备份到你的目标存储上面去。但是最新版本的Kibana里面我们现在好像也可以通过policy去做这件事了，也就是说现在Kibana或者是ES本身自己的功能确实越来越丰富了。右下角的截图大家可以看到，我们封装好了Elasticsearch的docker，自身部署到Kubernetes上的container可以在初始化容器的时候去装一些相应的插件，比如用来对接交换数据的对象存储或HDRS插件等等。所以如果大家有需要备份到云平台的某个对象储存，你需要去找这样的插件然后把它安装到ES里去，就可以通过Snapshotter做一个定时备份。
4、集群架构调整
除了恢复之外，在SaaS里面另外一个我们经常做的操作就是对集群的架构进行调整。
首先左图是我们在调整节点或规模的时候，比如我想在当前的这个集群里面把我的节点从两个调整到二十个，这个动作如果在Kubernetes集群资源足够的前提条件下，基本上一分钟之内就可以完成，其实跟节点的多少关系并不是很大，当然越多可能会稍微慢一些，总体还是非常快的。你只需要改一个数字，直接apply你的部署，集群的规模立刻就可以增长上来。但是需要注意的是，要缩小这个集群可能会慢一些，不过它至少不是一个手动工作，且是由ES官方的operator帮你逐个把节点拿掉的，这个动作一定要非常小心。首先是要做数据的迁移，把当前的数据移到其他的节点上去，做一系列的check之后再把这个节点拿掉。 但对于我们这些用户来讲，我们只需要简单地改一下数字就可以。
同理，升级也是，左图大家能看到version 7.10.2现在已经是最新的版本了，如果未来有新的版本release的时候我们也只需要改一个版本号，你的集群会通过operator自动升级。所以调整架构规模是非常简单的一件事情，如果在调整过程当中出现了任何问题，你也可以选择去重建整个集群，当然数据越多需要的时间也会相对更多。
右图是架构的调整，上面是数据Ingest的摄入节点，下面是主节点，与左边的节点调整同理。比如从一个全角色的节点引入Ingest node然后把master节点分离出来，实际上你需要做的只是增加更多的node sets。在node sets下面我们定义node set在Kubernetes里面扮演什么样的角色，分别有master节点、热数据节点、冷数据节点等，都可以通过Elasticsearch去做一些标记，然后在node set里面把它分离出来。我们在实际线下的操作过程当中，会根据实际情况进行调整。比如有些用户刚开始给20个集群做了角色分离，后来他发现了集群的性能受限，有太多的节点去扮演master，ingest或者coordinating，他们的压力并不高，数据节点偏少，这时我们就会让这20个节点全部变成数据节点，变成同样一个角色，来提高整个集群的性能和利用率。
还有一种情况，假设随着同等节点的个数调整，比如从20个调整到40个，你发现utilization的不均匀之后又想把它分离出来，同样没有问题，也是通过node set的模式去调整就好了。
5、专用网关
我们为Elasticsearch量身打造了一个专用的网关，因为不管在线下操作还是在SaaS做都会有非常大的限制，但是如果你在Kubernetes里面做，Kubernetes自身有非常好的预定义的ingress，ingress本身自己也会有一些限制。
我们给大家打造的Elasticsearch专用网关具备以下特性：
- 高可用，不停机索引，自动处理后端Elasticsearch的故障，不影响数据的正常摄取
- 写入加速，可自动合并独立的索引请求为批量请求，降低后端压力，提高索引效率
- 查询加速，可配置查询缓存，Kinbana 分析仪表板的无缝智能加速，全面提升搜索体验
- 透明重试，自动处理后端Elasticsearch节点故障和对查询请求进行迁移重试
- 流量克隆，支持复制流量到多个不同的后端Elasticsearch集群，支持流量灰度迁移
- 一键重建，优化过的高速重建和增量数据的自动处理，支持新旧索引的透明无缝切换
- 安全传输，自动支持TLS/HTTPS，可动态生成前证书，也可指定自签可信证书
- 精准路由，多种算法的负载均衡模式，索引和查询可分别配置负载路由策略，动态灵活
- 限速限流，支持索中限速和限流规则，可以实现索引级别的限速，保障后端集群的稳定性
- 并发控制，支持集群和节点级别的TCP并发连接数控制，保障后端集群和节点稳定性
- 无单点故障，内置基于虚拟IP的高可用解决方案，双机热备，故障自动迁移，避免单点故障
- 请求透视，内置日志和指标监控，可以对Elasticsearch请求做全面的数据分析
6、相关资源
关于如何落地，这里给大家提供了三个项目。
1、中文社区里维护的项目Elasticsearch on Kubernetes，如果大家想快速地在Kubernetes上部署Elasticsearch，不管你的平台是什么样的，都可以参考这个项目，或者里面有很多预置的脚本，你可以来实现快速的部署。
2、流式计算平台搭建所在Beam的执行方案，我们在这里写了一个Beam的框架代码，有了这个框架之后，很快就可以把一个非常复杂的流式计算任务或者一个平台搭建起来，真正在做开发的时候只需要填充中间的业务逻辑和一些相关的代码就可以了，这是我们构建这个项目的一个目的。
3、最后一个是还在持续完善中的极限网关，欢迎大家去试用，如果大家想知道更多的信息，欢迎到我们的中文社区里面来留言。
【阿里云Elastic Stack】100%兼容开源ES，独有9大能力，提供免费 X-pack服务（单节点价值$6000）
相关活动
更多折扣活动，请访问阿里云 Elasticsearch 官网
阿里云 Elasticsearch 商业通用版，1核2G ,SSD 20G首月免费
阿里云 Logstash 2核4G首月免费
下载白皮书：Elasticsearch 八大经典场景应用