分布式实时Hadoop数据安全平台ApachEagle实践

Posted 2021-04-13 七牛云

分布式系统是目前整个互联网行业百谈不厌的话题，无论是已经拥有海量用户的巨头公司，或是需要应用未来用户快速增长的初创团队，以及要靠高性能、可伸缩的系统特性来为广大开发者提供第三方服务的解决方案提供商，在进行服务端架构设计时，都无疑会使用分布式的部署方案。11月28日，七牛架构师实践日来到上海，首席架构师李道兵携手沪江副总裁李骏、携程高级经理顾庆、eBay高级软件工程师陈浩，共同带来大型分布式系统架构实践的分享。以下是陈浩的演讲《分布式实时Hadoop数据安全方案分析与实践》的文字记录。

陈浩：首先简单介绍一下Apache Eagle的由来。Apache Eagle是一个分布式平台，特点是分布式、多节点计算、实时，我们是为了解决Hadoop的监控和预警的问题开发的，今年10月26号正式开源，成为孵化器项目。

数据安全是我们要解决的问题，2007年我们的节点是作为一个测试节点，1到10，目前接近两万多台，单对Hadoop、大数据处理这一层。然后遇到的问题是Hadoop分布式系统有很多角色，对eBay这样大的电子商务公司，数据安全是非常重要的。将数据放上去之前必须考虑数据一旦被人黑，会出现什么样的后果。而在Hadoop的生态中，Security相关的solution并不是很完善，当然这个问题也不是那么好解决。同时我们有7个集群，每年eBay在上面投入的资源是几百万美金的维护费用。我们要保证整个平台的稳定性和可用性，传统的做法，是Master和Slave，但是任何分布式系统一旦出现单Master和多Slave这种架构，肯定有人会说你，你master的HA怎么做。这也是一些问题。

问题的挑战在于节点很复杂，去做它我们要监控用户行为、监控这个集群的Metric、监控这个job的日志等工作。放上去170个PB，同时产生的日志也有很多，两千多个Hadoop的用户，全球的业务分析人员，最好的架构当然是无状态的，但是一旦要监控一个用户的行为，它的行为序列必然是session－base的，必然有状态。这是我们在这样的情况下如何做到它。作为一个预警，特别是当别人可能有一些异常行为、黑客行为、非法行为或者非授权行为时，你必须在秒级别甚至是毫秒级别阻挡掉它，这对分析处理能力和整合的能力有很高的要求。Hadoop项目我们如何监控它，并且出了问题我们让Hadoop去做这件事情，把它block掉。这也涉及到我们做事的方式，开源。我们虽然是一个eBay公司，但是我们和世界上所有的开源项目一起工作。

以eBay现在大概的数量，每年eagle处理的数量在100亿，各种events、Metric等。我们做monitor系统可能不是作为一个business driven的系统，你要处理各种类型的东西，比如log、Metric等等。

Apach Eagle的架构设计

接下来是今天主要的内容，架构设计。我们有7个集群，一个集群两千多个节点，加起来有一万多个节点。HBase也接近一千多个节点，也有4个HBase，还有Hive，同样是跑在HBase上。它把用户层简化了，但是底层自身造成这个逻辑，在对用户行为进行监控的时候，如果直接操作，你很容易监控出来你想做什么，但是Hive去做的时候，你一个人访问了一张表，但是你产生的date activity的events可能是指数级的增长。我们的系统要求有延展性，最重要的是，不论是做安全性的监控，还是整个的performence相关的监控，出现任何异常，节点当然必须要保证你能监测到，实时的监测到然后发alert。

机器学习，很多时候，传统的监控系统是预定一个policy或者是一个rule，也就是规则，你触犯了这个规则，告诉你出现了什么事情。在现实情况下你的规则并不能覆盖所有的东西，我们希望这个机器通过你的历史行为，比如你一直是在做正常的事，突然有一天做了异常的事，这个机器自动生成这样的规则。

图1是我们现在开源的架构，我们的数据源来自于刚才说的Hadoop、Hive、HBase，来自它们的日志、事件等等。收集层，当数据量非常巨大，收集层并不是简单的用一个单机或者用一个TomCat，或者是微服务去处理，这个地方是很重的一部分，也是非常重要的一部分。KAFKA的集群也许就需要几十台，只做收集。它只是一个Queue，是很简单的数据结构，put然后take，但是本身必须做到分布式，吞吐量必须非常的大，做到毫秒级别。

图1

在数据处理方面，我们的规则很复杂，但是首先应该允许我们预定义规则，对用户来说我们希望简单预定规则，但是系统必须很powerful。80%的rule基本上很难做到无状态。因为监控的是某个人或者某台机器或者某个service，必然带状态的。所以我们的policy引擎必须能够支持这样的一个东西。然后它一旦宕了，必然涉及到partition，一旦涉及到partition，明显对于session net，partition用Hash肯定是很难做到的。一旦用了Hash，每个用户的行为数据量并不一样，你用了简单的Hash导致机器的主成分分析模型没法做到。假设我们这个集群，我们有一百台节点，如果某个人非常大，其他人都很小，比如这个人造成了50%的数据，50%进入到一台，剩下99台，这是一个很大的瓶颈。然后机器学习，我们要知道用户行为在日常进来，或者基于历史行为去建模的时候，我们希望能够产生一个模型。比如我们会对他的行为模型，界定一下正常的行为空间和异常的行为空间。当时的行为偏离正常的行为空间的时候，我们也许有理由发出一个警告，这个人到底是不是他。

然后作为一个复杂架构，我们希望整个架构非常简单，我们知道storm有一个很大的缺陷是它本身逻辑定义完。按照以往，这种分布式stream逻辑定义完，想再修改系统，必须要把topology重启，我们不希望这样，所以我们整个的结构是元数据驱动（Metadata Driven）。

存储层，我们的数据量很大，我们的case相对于传统的business来说可能有一个特殊点，我们不需要它的transaction，而是需要存得很大查得很快。UI，我们希望对用户非常友好，我们定义UI。还有一点，最下面的，基于机器学习，我们希望它实时的可建立它的模型，也希望可以基于历史的。比如我们已经存了几百PB的数据，希望能基于它建一个模型，不需要再等一个月才知道它正常的模型。数据量更大这个模型会更精准。然后我们需要处理这么大的数据量，我们如何计算这个东西？这个地方我们会依赖于核密度模型或者主成分分析模型，基于这种历史的建模。这是整个的结构。

首先是数据层怎么做到实时，然后规则引擎做到分布式实施，非常易用又很强大，可以进行数据的并行处理。我们提供了一个framework，我们现在开源的叫skillty，但是eBay除了Hadoop还有cloud，它的节点数据是十万级别。还有database，eBay的site database。我们希望我们的系统非常容易扩展，希望框架层面提供的编程人员，就是develop层面的，我们的DSL也非常的高度抽象易用，存储就是刚才说的HBase，HBase本身是NoSQL，现在业界对NoSQL也存在争议，也有它的benifit，它的争议在于它没有元数据（metadata），你必须自己去维护，这对于你自己的元数据（metadata）控制得非常好。

数据收集层，首先数据进来最重要的一层，在我们这里虽然目前为止是依赖于KAFKA提供一个高吞吐的分布式message系统，它的基本逻辑结构是这样子，producer，对于我们的produce可能是一百，比如说对于Hadoop一万台节点，然后KAFKA，是一个分布式的message queue，数据进来，处理不完也可以hold几天或者几个小时。然后你后面consumer，我们刚才说stream process engine，去拿到你的事件，去产生预警或者是存起来或者聚合。

它的基本实现吞吐量是通过它的partition level的一个划分，它的partition数量决定了它可以并发的被Consume的数量，你可以基于你的业务逻辑，最简单的，你如果不考虑session的话你可以完全balance到partition上，但是你要考虑到时间的有序性。分布式系统其实很多东西不好保证，比如HBase的transaction不好保证，KAFKA的消息的有序性，就是先进先出（FIFO）没有办法保证。但它可以保证在partition level是first in first out。所以你可以，比如我们的Security这个case，用户行为监控，你可以保证每个用户的行为，见到相同的partition就够了，它就可以保证用户行为的有序性，同时保证多个partition同时进同时出，实现并行的消息吞吐。

所有分布式系统，都会遇到平衡的问题，分布式架构任何时候都会遇到这个问题。最简单的是一个状态的，然后我们的（GL）是基于KAFKA，然后我们提供了一个跨平台用的客户端集成，我们并不知道我们的客户端，可能是database，可能是Hadoop集群，可能是cloud集群，甚至可能是用户的payment的信息，可以做一个实时的反欺诈，这对金融而言反欺诈是非常重要的，基本上决定一个金融的，像apple pay，他们赚不赚钱，影响50%以上。

KAFKA，我们整个的工作方式就是开源，所以我们对KAFKA，虽然不是我们自己创造的一个项目，但是是Apache的一个重要的项目，我们对它提供了很多的定制。

此外，数据收集的话，作为Agent客户端，我们现在使用的是filebeat和logstash，filebeat本身是放在客户端上作为Agent，多个logstash实例作为一个集群，它本身可以做到balance和容错，其中任何一台宕掉消息都可以过来。这里还有一个考虑，你在Agent端其实不希望被监控的系统的资源被影响得太多，所以我们这里采取filebeat，提供一个轻量级的，把数据进到logstash，再去基于业务逻辑做field grouping。这就是整个都会自始至终的提到如何在真正的大数据处理下，分布式必须处理好partition的balance。

分布式扒取，比如你有一万台节点，Hadoop节点，十多万台cloud节点，并不是要在上面侵入式的让它吐出来，你可以分布式的处理，可以通过改变扒取节点的数量保证你的吞吐量。

下一个就是核心的，分布式的实时策略引擎，我们要做到实时，非常易用，高延展性、扩展性，元数据驱动。基本结构是我们会抽象成任何用户的任何行为进来都是一个stream，stream会进行（processing），然后进行alert的evaluation，就是policyengine。对于用户来说你可以定义所有的policy在一个非常漂亮简单的UI上，然后元数据会动态部署到整个分布式执行环境下，我们的分布式执行环境下是平台独立，默认支持storm。

这是我们保证实时，在前面的数据收集层我们采用KAFKA，在中间层我们默认采用Storm-based的realtime streaming的执行环境，保证整个的处理，alert的产生和处理都是非常实时的。

可用性，和很多系统一样，包括Hadoop上面为什么出现Hive，Database上为什么出现SQL，SQL这个语言在整个技术发展史上一直是起到非常重要的作用，而且大家非常熟悉它，但是streaming上没有很好的SQL的接口，所以我们做了这样一件事情，流式处理上的SQL我们称之为CQL (Continuous Query Languages)，不用非常懂streaming这个分布式怎么用，只需要定义这样一个，SQL是一次进一次出，CQL是持续进持续出，它是流式处理。这对于用户层面，虽然我们的集群很复杂，但是对用户其实非常简单。而且为了让这个事情更简单，我们提供了一个很简单的UI，同样动态部署整个policy。

这是对我们的CQL的更详细的介绍，它和大家非常熟悉的SQL是非常像的。你处理一个事件，比如我们要detect一个用户行为，验证密码失败三次，如果是基于当前session base的，比如一个存储系统去取它对比它，其实很多时候这个不是非常好的，它会造成一定锁的问题。用streaming系统的话，可以让它整个事件的这些detect，放到后面更强大的分布式引擎上去做，而且做法也很简单，比如在这里，我们在某一段的window内出现的次数大于五，就是这样一个case，这样一个语法进去，它会动态部署，不论业务增长多快都可以实时检测出行为上的异常。同时也支持更强大的Group by，还有它的条件等等。

可扩展性，刚才说整个storm支持可扩展性，支持分布式处理，用Spout去抽取数据处理数据，希望policy也可以去处理，但是policy大部分都是基于会话（带状态）的，所以我们希望我们的policy能做到非常的可扩展，我们可以通过stream，以一个policy它所接受的数据源去做partition，而不只是基于Stream中的数据去做分流，所以你这样你的一个policy的定义数据源不同，就可以有理由被平行切分开进入不同的节点处理，原理其实很简单。

问题其实也很严重，这是我们一开始说的，任何分布式系统一旦出现session会话，尽可能，前端的架构尽可能应该做到无状态的，但是有时候像我们这种case，用无状态的话你的逻辑就错了。所以问题就是像这种，我进来一个stream，采用了分布式，最上面的是处理了绝大部分的事件，最下面的就处理了那么一点。这个问题是分布式流式处理的一个经典的问题，解决方法也很多。这里简单介绍一下我们在Eagle层面的做法。传统的做法，主要key的切分和key的聚合，如果Hash没有状态，不基于某一个key去做group的话，hash完全是balance的。但是一旦基于某个key去grouping的话，Hash很容易出现刚才我们所说的Data skew (数据倾斜)的状态。其他的算法基本上就是说，一个key的切分，它会基于下游节点的负载的情况，也就是说会记录下它分发给那个节点的时候的基本信息的统计值，给那个节点最低的那个去分发这个event。这个是我们的做法，其实是最高效的一个做法，就是greedy，online或者offline的做法，我们会基于历史或者基于实时去做key的分布情况做一个分布统计 (Distribution)，然后在系统启动的时候，我们因为知道基于相当长历史的统计，其实它的key的分配是固定的，我们可以让多的和少的结合，中间的来保证整个下游的处理层都是相对平衡的。然后语法，调用语法也非常简单，group by某一个key，这是面向应用层的一个语法，就是我们定义的DSL，我们可以基于用户，比如说Application开发者去自由的定义，然后key会存在一个cache中，它是存在于各个节点之上，同时它会异地同步到HBase。

扩展性，我们希望我们的分布式引擎很强大很简单，就是提供策略定义引擎，它也可以同时作为流式处理引擎，提供机器学习策略引擎。我们不想绑定到任何东西上，我们要保证它的可扩展性。

Metadata driven，分布系统很复杂，我们希望我们的逻辑能动态部署，比如我有一百台节点，希望它对用户是非常透明，随便可以在UI上指定一下它可以到对应的地方。另外在存储层，我们为什么metadata driven，我们是Hbase是NoSQL的，它也是Schemaless的，它就是Key-Value结构，允许你自由组合。虽然它允许你采用这么强大的存储和query机制，但是你必须非常好的处理好它的metadata。所以对用户层我们提供一个面向HBase的ORM，同时它本身是针对我们的这个case，监控系统优化的。然后UI上也希望用户可以通过UI来定义metadata，这个metadata保证它是动态部署，永远不会有宕机的行为。

刚才说框架层面是为了做到延展性 （Scalable），做到实时。但是对应用程序开发，比如提供了这样的执行环境，我想做一个安全监监控（Security）这样一个项目，这是我想做这样一个机器学习，我写的代码如下：

from metricStream[(name == 'ReplLag')

and (value > 1000)] select * insert into

outputStream;

我们希望我们的DSL，面向应用开发者它的DSL非常的高度抽象，就像我们的架构图是这样的，但是其实它抽象成一个代码，它是完全一一匹配的。所以这样能保证你的框架非常强大，但是对最上层永远是experience最高的，开发的experience、用户的experience。

DAG，你可以按你的任意行为去定义。但是不是你想做什么就会最终变成什么，就像map-reduce，map-reduce有一个很大的缺陷，就是你自己进来的话，你每次结果落地，落地完，比如你要迭代式的，迭代一百遍它就落一百遍地，其实中间完全有些环节可以直接内存传过去的，需要做到优化。在我们这里，我们可以认为一个事件就用一个bot，比如storm的一个Processing(处理单元)，处理单位去处理，但是有时候可以优化成两个节点完全对业务层也是分开的，但是对架构层处理层，其实可以放在一个GBM里面处理，省去了中间网络的传输。

对于用户层，定义DAG，在框架层面会基于各种节点进行进一步的优化。这是我们的interface，最终会编译成的原生的storm的应用去执行。刚才提到的存储层，作为HBase，作为传统数据库而言，大家需要很强到经验去做好很强的分库分表。对于HBase来说，对用户只需要做一次，所有的分库分表分节点它自己去做。由于它的NoSQL机制没有Schema，所以它的整个机制，它Scalability (延展性)是非常之高的，但是作为一个框架，特别是想做成这样一个框架，让客户非常易用的话，必须自己去管理这个metadata。同时HBase查询非常简单，插入语句只有put，查询语句只有scan和get。但是对于用户逻辑而言，他希望还能够有SQL这样的语言，大家最熟悉的这种语言，而且更希望甚至不需要做任何事情，直接是API就可以去扩。所以我们的执行层是定义了一个Metadata，然后在query层定义了一个高度抽象的REST Query语言。而且我们的监控系统，整个系统是基于Time Series (时间序列)，也就是监控需要的特定的Schema进行优化。同时为了实现更快的聚合，目前为止更快的聚合，其实很多时候你都必须做Node level (节点分布式计算)的computation，你必须让它的节点去分布式做各自的结算，然后把少量结果回来，这样可以将节点计算分离，也将数据量分离。

HBase本身不支持元数据管理，但是我们在应用层做了这样的事情，而且整个架构是out of box的，你不用对HBase做任何影响，你就可以直接在上面用。当然Coprocessor 支持是一个例外，因为你必须要嵌入到它的节点中去。然后我们整个架构虽然是用了HBase，但是其实我们希望监控系统可以用到一个小的监控也可以用到一个非常大的监控，我们需要依赖HBase，但是如果你数量不大的话，完全有理由去换成一个关系型数据库的，比如mysql。

这是我们在HBase上的优化。 最本质的我们会采用一个通用的Rowkey 设计。比如Metric，我们希望它的不同的Metric采取不同的分区，所以我们将Metric name直接放到rowkey前面。然后对entity它就是一个默认前缀的，对于log，就是不同的日志（time），来实现第一层逻辑上的partition。然后partition是基于你的逻辑的，你想怎么去查它，整个HBase你可以认为它是一个Hash的分布式，你如何有效的处理好你的Hash分布是对你的（query）影响非常重要的。然后对于监控，我们将时间序列（timestamp）也放到rowkey里面，保证你有序的去query，它可以避免存储块过于分散，从而加速查询数据。

最后机器学习这一块，我们的机器学习包括online的detection和offline的training。online的detection我们目前为止基于storm，它会依赖offline生成的模型，offline采用的是Spark，它会将数据，我们数据收集都是进入到KAFKA，然后进入到HDFS，比如你存一个月的数据或者存多久的数据，然后一直存在那儿，可以非常大数据量的存储，历史数据的存储，基于Spark迭代式的递归计算，建立它的模型，运行它的算法，将模型存在HBase中。然后在（storm）的阶段会从HBase中将模型读取出来，在memory中缓存一个模型，这个模型，分布式的时候你希望能并行，永远要做到partition，你的模型也是会partition的。你对部分的处理节点只需要载入Policy 依赖的模型，你进来的partition key对应的那个模型就够了，这样可以很大的节约你在memorycache中消耗掉的内存，同时也可以也让它很容易的扩展开。

在storm这一层，会结合当前进来的实时的stream和历史的模型去evaluate，去判断它是否是属于异常的行为。这是我们在user profiling，就是我们做Security这个case上的一个大致的算法。offline的时候，我们会基于用户的行为特征，比如他日常会做什么，日常会做open、delete或者是rename等，它的一些特征，然后建立出它的核密度，或者是主成份。最终online的部分就会看它当前的行为和正常的行为的偏差，超过一定的程度我们认为他是异常的。很多时候只要定义这个指标，绝对值多少取决于它自身的行为，所以这样可以做到很智能的detect到一个用户是否是异常的。一个未授权的用户，以前从来没有做过一件事情，突然做了一件事情，我们就可以认为是异常的。

另外一个case，我们有很多节点，Hadoop有一万多个节点，每个有五千多种matrics。Hadoop虽然，它现在很火，但是它job有时候会非常慢，但是慢的原因，通过节点数量乘以matric的数量，可能性是非常多的。怎么过滤出和异常事件相关的matric的类型，一旦知道主要的影响因子，到下次这些因子发生异常的时候，造成整个集群的问题之前把它预判出来，最终产生这样一个alert。这是我们在其实user profile，Security和Hadoop监控上利用机器学习的两个方面。

Ecosystem，整个Eagle的架构，我们最核心的是Eagle的framework，然后会在上面develop各种的application，我们希望开发这个开发application的定义语法，也就是DSL，也非常的简单。它的集成，我们Eagle为什么要进Apache，我们是采用一个开放的方式去做这样的事情，其实和今天的主题也有一些符合，分布式，除了技术层面，整个如何去开发它，人力资源的使用方面也可以做到分布式。就像我们集成，我们专注在做Security，会和其他的组件集成，我们并不是所有对我们有利的我们都放到我们自己里面做，比如Eagle希望和ranger集成，我们会往ranger这个社区发Patch。Dataguise，它作为一个商业公司，它想和我们集成，他们做完我们去做contribution。包括Amabri，就是Hadoop开源的集群管理工具，我们作为eagle想去监控Hadoop，我们和它集成可以成为整个Hadoop组件中默认的一员，这个是现在Hadoop的发行当中最大的是两个，一个是Cloudera一个是hotworks，amabri就是hotworks主推的一个集群管理工具。

所以eagle作为一个监控系统成为它的一部分，有理由甚至以后可以跟hotworks的HDB做很好的集成。整个这是我们的开源，我们的开发都是community driven的，同时我们希望能和各种community，跨community社群合作，实现整个系统的增长。这也是apache希望我们能用开放的方式开源的方式，将分享出来的东西，在技术上大家一起驱动技术往前发展。

我们现在开源的组件，Secure Hadoop in realtime，eagle，这里讲一下（use case），就是Security，作为Hadoop这样一个非常复杂的分布式集群，它本身的安全监控是非常不可控的，至少是不成熟的，而且很难去完整的把它控制好。所以在任何公司，特别是商业公司，特别是数据非常重要的公司，第一步必须定义好安全策略，因为你没法保证Hadoop会在哪个方面出问题，如果你是非常业务敏感的data，被一些比如不应该知道它的人看到，这都是非常危险的一件事情。如果你是上市公司，这种东西就非常严重。ranger这个项目是Hadoop里面提供它的权限管理的，所以第一步必然要做策略的定义，所以这里是eagle作为Security产生的背景，我们和ranger集成，ranger嵌入到Hadoop里面做安全监控的。Knox是做访问层安全监控的，Dataguise是做敏感数据的。所以Dataguise它能识别到敏感数据，对于商业公司，它最需要监控的就是它的敏感数据在哪里、大数据里面存不存在敏感数据。Hadoop想处理一个非常大的数据集上的处理问题，但是你要知道里面的敏感数据是有哪些或者哪个文件里包含敏感数据，其实这个问题是很难的。比如普通业务只是处理部分数据，但是Dataguise的需求是必须实时监控全部的数据，这是它要做的，但是eagle不会和它做同样的事情，它拿到实时敏感数据的时候，无法去和当前用户的行为，把它融合到一起，它就和eagle进行集成。所以我们就希望通过这些开源的组件，同样Eagle虽然来自一个商业公司，我们也是开源，希望通过这样一个生态打造一个全栈式的Hadoop Security的solution。

Amabri。Amabri是作为一个Hadoop集群，所以我们eagle想监控Hadoop，可以很native的be part of Hadoop eagle system，就是你作为它的组件的一员，其实你完全不是一个外围系统。虽然我们完全是out of box的构架，我们完全不会影响Hadoop本身的运行，但是我们也可以和它集成，然后作为它的一员，所以你安装Hadoop发行版的时候，你完全可以安装eagle，而且非常简单，简单的在管理页面上点几下install就可以了。然后eagle的管理页面也非常简单。刚才我们说Eagle使用了Storm、KAFKA、HBase，但是其实这些东西，在用户层提供了非常强的处理能力，非常简单的使用程度，但是它本身的基础架构是非常复杂的，这里有一个15+1=1，我本来要装15个service，比如storm，它有Nimbus 和Supervisor，然后像阿里最近也有一个Apache项目，叫JStorm。它的Nimbus 和Supervisor这些组件，它搞了一个Nimbus的HA，也就是你可以有两个Nimbus，也就是两个marster，这个组件又复杂了。然后KAFKA，你需要有broker，KAFKA这个还简单一点，你可以有很多broker。ZOOKEEPER，HBase，Hadoop，虽然这看起来很简单的几个，但是本身的service是超过15种的。我们希望我们集成到docker，虽然docker现在不是很成熟。但是我们一旦形成docker，比如我们搭eagle的用户的开发环境，对于我们的开发者，你搭一个开发环境其实很简单，你克隆一下eagle的代码，eagle docker跑一下，一键所有的环境都装好了，虽然有15种服务，但是对你的系统影响也不是非常大，因为你不会知道。

对于eagle的production，也可以用eagle的镜像，虽然现在还没有。因为apache这个基金会，它的docker的帐号有点问题。我们为什么要采取开源，ebay作为一个商业公司，这是一句名言，一个人可以走得很快，我们也希望我们能走得更远，希望能够成为一个很成熟的solution，和整个生态系统产生非常好的融合，同时也希望能福利于更多的，不只是国外，不只是英文社区，也希望中文社区也能够更多的做好这个事情。

基本上对Eagle的介绍就这么些，如果你希望了解eagle更多，我们机器学习模块有一个IEEE的论文，特别是Security这一块，有兴趣的可以去搜一下。同时eagle作为一个实时的监控（framework），现在我们也在写另外一篇论文，这篇论文也会很快面市。Eagle还有几个专利，当然这是美国那边的，所以这个比较慢。然后eagle会频繁出现在这几个地方，特别是Hadoop 全球峰会里面，深荷赛，加州的，还有北京的、上海的，有兴趣的或者方便，今天没有来到七牛的这个分享的，有兴趣可以去看一下。