datastream china

							                             数据流系统建模与分析*
         Brian Babcock   Shivnath Babu     Mayur Datar    Rajeev Motwani   Jennifer Widom
                                    斯坦福大学计算机科学系
                                         Stanford University
                                         Stanford, CA 94305
                    { babcock,shivnath,datar,rajeev,widom }@cs.stanford.edu


摘要：在这篇综述中，我们讨论了对一种新的数据处理模型的需求，研究了这种新模型引发
的一些问题。在这种模型中，数据并不呈现为持久稳定的状态，而是以大量、连续、快速、
时变的数据流形式到达。本文回顾了过去与数据流系统相关的工作，评论了当前与此相关的
一些项目。另外，本文还探讨了流查询语言，查询处理中新的需求和挑战，以及算法问题。



1 引言

     近年来，一类新的数据密集型应用已经得到了广泛的认同，这类应用的特征是：数据不
宜用持久稳定关系建模，而适宜用瞬态数据流（data streams）建模。这些应用的实例包括金
融服务，网络监控，安全，电信数据管理，Web 应用，生产制造，传感检测等等。在这种
数据流模型中，单独的数据单元可能是相关的元组（tuples）          ，例如网络测量，呼叫记录，网
页访问，传感读数等产生的数据。但是，由于这些数据以大量、快速、时变（还可能是不可
预知、极大的）的数据流形式持续到达，由此产生了一些基础性的新的研究问题。
     在上面提到的所有应用中，若把持续到达的数据简单的放到传统的数据库管理系统
（DBMS）中，并在其中进行操作，是不太切实的。传统的 DBMS 并不是为快速连续的存
放单独的数据单元而设计的，             而且也并不支持“连续查询”                   【84】 而
                                       （continuous queries）   ， “连
续查询”是数据流应用的典型特征。另外，现在人们都认识到，                “近似性”     （approximation）
和“自适应性”      （adaptivity）是对数据流进行快速查询和其他处理（如数据分析和数据采集）
的关键要素，而传统 DBMS 的主要目标恰恰与之相反：通过稳定的查询设计，得到精确的
答案。
     在这篇论文中，我们分析了通用数据流管理系统（Data Steam Management System :
DBMS）   的一些基本模型和相关的问题。         我们正在开发一个斯坦福流数据管理系统 Stanford  （
Stream Data Management）    ，因此，本文中还设计到我们自己的一些工作。我们希望提
                        【82】
供一个对此领域概括性的综述，同时阐述当前与之相关的工作。                （文中出现的任何大的疏漏
都是我们的错误。       ）
     从第2部分开始，我们将分析数据流建模和基于流的查询。在这一节，我们作一个简单
的观察：流与瞬时元组只是附加关系（streams are append-only relations with transient
      ，而查询是SQL对这些逻辑关系的操作。在随后的几节中，我们将讨论使模型和查询
tuples）
语言变得复杂的几个问题，如排序、时标以及滑动窗口。在第2节中，我们还将将给出一些
具体的例子作为我们讨论的基础；
     在第 3 节，我们将回顾近年来与数据流处理明确相关的一些项目，同时，我们也看看与
数据流领域相关的过去做过的其他研究，例如：主动数据库、连续查询，过滤系统，视图管

*
                              。Mayur Datar同时受微软研究生奖学金资助。Rajeev
    本文受美国国家科学基金会资助（IIS-0118173）
Motwani受Okawa基础研究基金的部分资助。

                                                -1-
理，时序数据库（sequence databases）等等。很显然，上述各个领域已有了进行数据流处理
的应用软件，但我们将会发现，如果要实现一个完整的 DSMS，将会遇到许多新问题；
  第 4 节将对查询处理领域进行深入研究，揭示如下一些重要问题：
   需要极大的内存来评估查询的精确性，近似查询处理技术能够处理这个问题；
   滑动窗口查询技术（如，只考虑“较新的”数据流）既能当作一种“逼近
      （approximation）技术”也能当作一种查询语言中的可选项，因为很多应用程序都
      采用了滑动窗口查询；
   批处理，抽样，提取大纲结构（synopsis structures to handle）等情况下，输入的数
      据流也许会使查询处理器不堪重负；
   在数据流没有终结的情况下，块操作码（blocking operators）的意义及其实现；
   当数据流的部分数据已经流过的情况下，注册成“持续查询”的查询需要参考数据
      流的历史信息；
  接下来的第5节将给出一种查询语言，并给出一个能解决上述问题的DSMS查询处理器
的体系结构；
  第 6 节我们将分析流处理中的算法结果。我们主要关注梗概技术和建立概要结构（纲
要）。我们还会涉及到滑动窗口计算，给出一些不太理想结果，讨论另外几个算法问题；
  最后在第 7 节，我们给出结论，并对这一新领域做出一些评论，同时对今后的研究方向
作一个概括。



2 数据流模型

      在数据流模型中，  部分或全部需处理的输入数据并不在可随机访问的磁盘或内存中，                但
它们却以一个或多个“连续数据流”（continuous data steams）的形式到达。数据流不同于
传统的存储关系模型，主要区别有如下几个方面：
       流中的数据元素在线到达；
       系统无法控制将要处理的新到达的数据元素的顺序，          无论这些数据元素是在一个数
          据流中还是跨多个数据流；
       数据流的潜在大小也许是无穷无尽的；
       一旦数据流中的某个元素经过处理，要么被丢弃，要么被归档存储。因此，除非该
          数据被直接存储在内存中，否则不容易被检索。相对于数据流的大小，这是一种典
          型的小相关性（small relative）。
      数据流模型中的操作并不排除传统的关系型数据（some data in conventional stored
relations）的存在。通常，数据流查询操作将建立数据流和关系型数据（stored relational data）
的联系。为了达到本文的目的，我们假定，如果使用了存储关系（sotred relation），则它们
的内容保持静态不变。      在数据流处理过程中，        更新存储关系的同时可能会产生传输处理问题，
通过上述假设，我们排除了任何潜在的此类传输处理问题。


2.1 查询

  对连续数据流的查询同对传统的数据库管理系统的查询很类似。 但是，  对数据流模型而
言，它与DBMS有两个重要的区别。第一个区别是一次查询和连续查询     。
                                【84】 一次查询  （包
含了传统DBMS查询的一个类）是对数据集在某个时间点上的的瞬态（snapshot）的一次计


                             -2-
算，再把结果返回给用户。相反，连续查询是在数据流持续到达情况下的连续的计算。连续
查询是数据流查询类（class）中最值得研究（more interesting）的类，我们将把我们的大部
分注意力投向它。    连续查询的答案是基于时间的，它反映了到目前为止已看到的数据流的情
况。当新的数据达到时，连续查询的答案可以被存储或更新。或者也可以被处理成数据流本
身。有时是一种模式适合，有时是另一种模式更适合。例如，集合查询（aggregation queries）
可能包括对答案元组的频繁改变，并指示存储方法（stored approach）；而联合查询（join
queries）往往单调不变但产生快速、极大量的答案，并指示流方法（stream approach）。
     第二个区别是预定查询和特别查询。 预定查询是指在任何相关数据到达前就提交给数据
流管理系统的一种查询。虽然一次性查询也可以被预先定义，但预定查询通常是连续查询。
与此相反，特别查询是指在数据流已经到达后的在线查询。有两个原因，使得特别查询让数
据流管理系统的设计变得很复杂：第一原因是由于不能提前预知，无法优化查询，无法找出
不同查询间的公共子表达式；    第二个更重要的原因是由于特别查询的正确答案也许需要参考
已经到达数据流中数据元素，而这一元素已经被丢弃了。我们将在4.6节中详细讨论特别查
询。


2.2 列举实例

    我们能在许多应用领域找到数据流系统的实例，如金融、Web应用、安全、网络和传感
器网络，等等。
     Traderbot 85】 这是一个基于Web的金融搜索引擎，
              【    ：                       可以对实时的金融数据流   （如
      股票，新闻馈送（news feeds））进行评价查询。Traderbot的web站点【85】给出了
      一些消费者常常提出的一次查询和连续查询的例子。
     现代安全应用通常需要对网络上的数据包流设置复杂的规则。例如，iPolicy
      Networks【52】提供一个集成的安全平台，它能提供诸如防火墙支持、对多个G比
      特级的数据包流进行入侵检测的服务。        这样的一个平台需要进行复杂的流处理，         包
      括基于表查找的URL过滤、多个交叉网络数据流的相关分析。
     大型Web站点日志（点击流）的在线监控使得应用程序能提供个性化服务、性能监
      测和负载平衡。      一些Web站点的服务是通过广泛的分布式web服务            【95】
                                                 （如Yahoo   ）
      来提供的，这就需要协调对许多分布式点击流的分析，例如，作为实时性能监控的
      一部分，需要追踪那些访问起来非常缓慢的网页（heavily accessed web pages）。
     在传感器监测领域也有一些正在浮现的应用：大量的传感器分布在物理世界中各
      处，需要对它们产生数据流进行组合、监控和分析。
    我们将详细分析网络流量管理（network traffic management）这一应用领域，网络流量
管理包括监控网络数据包中的包头信息，包头信息中包含了数据包经过那些路由器的信息，
对包头中这些信息的获取有助于得到网络数据流的传输模式（traffic flow patterns）。基于
Babu和Widom【10】的描述，我们详细研究了这个实例，有助于说明连续查询是在真实应
用中自然出现的，而传统的DBMS技术不足以支持这种类型的查询。
    考查一个大型网络，例如一个因特网服务提供商（ISP）的骨干网络的网络流量管理系
统。这种系统监控着各种连续数据流，包括数据包跟踪、网络性能测量，而这些数据流的特
征也许是不可预知、高速率到达的。典型的，当前数据流管理工具要么依赖于特定目地的系
统， 通过这些系统来支持对简单的手写代码生成的连续查询的在线处理，               要么只是记录流量
数据的日志，再执行周期性的离线查询处理。传统的DBMS命中注定了不适合于提供这种在
线连续查询处理，      而这种需求恰恰是这一领域中最有价值的问题。          一个能够高效的对数据流
进行在线连续查询的数据流系统应该是什么样的呢？它应该允许网络操作者安装、                  修改、 或

                            -3-
者恰当的删除监控查询以支持对ISP的网络资源高效的管理。

    …………（略）



3 数据流项目回顾

     本节中，我们将对过去几年中和当前正在进行的同数据流管理相关的项目作一个概述。
在后面的几节中，           当涉及到我们在斯坦福开发的通用数据流管理系统遇到的问题时，                                 我们也
会重新提及其中的某些项目。
     Tapestry系统【84】采用了连续查询来对数据库进行基于内容的过滤，该数据库是邮件
和电子公告牌系统的增补数据库（append-only）。我们使用了一个SQL的有限子集作为查询
语言，以便能高效处理和得到增补查询结果。
     Alert系统【74】则在传统的SQL数据库基础上，通过使用定义在专门的增补“反应表”
（append-only active tables）上的连续查询，提供了一种实现“事件－情况－反应”
（event-condition-action）触发机制。
     基于内容的XFilter过滤系统【6】则能基于用户角色对XML文档进行高效过滤，用户角
色以XPath语言【94】表达为连续查询。            （based on user profiles expressed as continuous queries
in the XPath language）。
     Xyleme【67】是一个与Xfilter类似的基于内容的过滤系统，它以有限的查询语言实现，
能达到很高的吞吐率。
     Tribeca流数据库管理者【83】则提供对网络中数据包流的有限查询的能力。
     Tangram流查询处理系统【68，69】使用流处理技术来分析大量已存储的数据。
     OpenCQ【57】和NiagaraCQ【24】系统支持连续查询，能支持监视整个广域网络上持
久稳定的数据集，例如，整个Internet上的web站点。OpenCQ使用了一种基于增量视图保持
（incremental view maintenance）技术的查询处理算法，而NiagaraCQ则提出分组连续查询技
术以达到高效计算（efficient evaluation）的目的，在此基础上还引出了查询总数的可测量性
问题。在NiagaraCQ项目中，Shanmugasundaram等人【79】讨论了数据流查询计划中的支持
块操作符的问题，Viglas and Naughton【89】针对数据流查询提出了基于速率的优化
（rate-based optimization），这是一种新的优化方法，它基于流到达和数据处理的速率。
     Chronicle数据模型【55】提出了增补顺序的元组（记录：chronicles）                    ，这是一类数据流。
他们定义了一个受限的视图定义语言和符号（chronicle algebra）                    ，用该语言和符号就能以传
统的关系操作记录集。这项工作的要点是要能确保用记录符号定义的视图能递增维护
（maintained incrementally），而不需要存储任何记录。
     Seshadri，Livny，和Ramakrishnan 【76, 77, 78】提出了一种代数和便于陈述的查询语
言来查询有序的关系（序列）              。
     在许多应用中，连续查询需要参考流的先后顺序，特别是流的滑动窗口的形式。这方面
的相关的工作也包括临时【80】和时间序列数据库【31】                       ，而通过时间指示的元组的顺序能
用于查询、索引和查询优化。
     由于物化视图（materialized views）是高效的查询，无论何时基础数据（base data）改
变了，都需要重新评估或刷新递增，因此与物化视图相关地大部分工作是连续查询。特别重
要的是在自我维护（self-maintenance）      【15，45，71】的情况下工作――确保当基础数据无
法获得时，仍然保存有足够的数据来维护一张视图，与此相关的问题是数据期满（data
expiration）――决定某些基础数据何时能被丢弃，而且丢弃这些数据不影响维护视图的能

                                         -4-
力。然而，数据流文本中的物化视图和连续查询存一些区别：连续查询的结果往往也是流，
并不需存储；       连续查询只处理不断增补的输入数据；        连续查询往往只需提供近似的而不是精
确的结果；连续查询的处理策略往往随着数据流特征的变化而改变。
     Telegraph项目 【8， 58， 与DSMS有一些共同的应用目标和基本技术思想。
                      47， 59】                                Telegraph
使用一个自适应查询引擎（基于Eddy的概念【8】）来处理不稳定和不可预知环境（例如，
Internet上的自治数据资源，或传感器网络）下的查询效率问题。Madden和Franklin【58】则
主要研究了针对传感器产生的数据流的查询执行策略。Madden等人【59】还讨论了针对多
个连续查询的自适应处理技术。               为了实现对自治数据资源的动态数据集成，      Tukwila系统  【53】
也支持自适应查询处理。
     Aurora项目【16】正在专门针对流监控应用（stream monitoring applications）开发一个
新的数据处理系统。Aurora系统的核心是由一个大的触发器（triggers）网络组成。每个触发
器是包含一个节点的数据流图，每个数据节点是七个嵌入操作符中的一个（或者按Aurora
的术语是：boxes）。每一个使用Aurora系统的流监控应用程序，都要产生一个应用管理者
（application administrator），并增添一个或多个触发器到Aurora触发器网络中。Aurora的触
发器网络即进行编译时优化（例如，对操作符重新排序），又进行执行时优化（例如，相同
子表达式共享状态变量）。



4 数据流查询

  数据流模型计算中的查询处理带来了它独有的挑战。在本节中，我们将概要介绍最吸引
人的一些挑战，描述几种可选的解决这些问题的方法。本节中提出的问题将是本文后面讨论
的框架。


4.1 极大的内存需求

  由于数据流潜在的无穷大，因此若要精确的计算出一个数据流查询的答案， 所需的内存
的量可能将漫无边际的增长。为处理超过内存大小的数据集，人们研究过扩展内存算法【91】，
但这些算法并不适用于数据流应用，因为它们不支持连续查询，而且对实时响应而言非常慢。
  …………（略）


4.2 近似查询答案

  正如前面所述，当我们受制于有限的内存时，对数据流的查询通常得不出精确的结果；
但是，作为精确答案的替代，高质量的近似答案通常也可以被接受。针对数据流问题定义的
近似算法研究近年来取得了丰硕的成果，我们将在第6节中详述。
  …………（略）


4.3 滑动窗口

  数据流查询中，产生近似答案的一种技术是，并不计算整个历史数据流，而是计算流中
进来的数据。例如，只有上个星期的数据能够得出查询结果，纳闷上个星期以前的数据都将
被丢弃。

                                 -5-
   …………（略）


4.4 批处理、取样和大纲

  另一类产生近似答案的技术是，  并不处理到达的每个数据元素，        而是借助于某种排序取
样或批处理技术来加速查询的执行。  我们描述了这些技术的一个通用框架。           假设一个数据流
查询能通过使用一个能被递增维护的数据结构来得到答案。       对这种数据结构的最一般的描述
是它支持两个操作：更新元组（update tuple）和计算答案（computeAnswer）。
  …………（略）


4.5 块操作符

  块查询操作符（blocking query operator）是这样一种查询操作符：直到它第一个元组整
个都输入后，它才能产生第一个输出元组。排序是一个典型的块操作符，就像集合操作符一
样，如SUM，COUNT，MIN，MAX和AVG。
  …………（略）


4.6 过去数据查询参考

  在数据流计算模型（the data stream model of computation）中，一旦数据元素流过，就
再也访问不到它。这种限制意味着，在某些数据已经被丢弃的情况下，一些特定查询将不可
能得到精确答案。一种简单的解决方法是规定特定查询只能参考未来数据：                    数据流就像在查
询刚开始时流入，任何已经过去的流元素都将被忽略（为了此查询的目的）。
  …………（略）



5 DSMS 建议

    在斯坦福，我们已经开始设计并实现一个复杂的DSMS原型，叫做STREAM（Stanford
StREam DatA Manager）【82】。在前面几节我们曾经讨论过，在DSMS传统的一次查询被
取代或扩展成连续查询，而滑动窗口技术、大纲结构（synopsis structures）技术、近似答案
技术、自适应查询处理技术成为了DSMS系统的基本特征。一个复杂的DBMS的其它方面也
需要被我们重新认识，包括查询语言，存储和缓存管理、用户和应用程序接口、支持事务等
等。在本节中，我们将主要关注DSMS的查询语言和查询处理组件，另外，在我们的初步经
验基础之上，我们还将设计其它一些问题。


5.1 DSMS 的查询语言

   …………（略）




                            -6-
5.2 流中的时标（timestamps in streams）

    在上一节中，     我们用代表元组到达时间的时标或序列号定义了滑动窗口。                   对于从一个流
中来的元组，这种方法是不会引起混淆的。但是，对于从多个潜在流（underlying streams）
（例如，联合操作符的输出窗口）中产生的组合元组，就无法运用滑动窗口来清楚表达。当
被联合用于产生结果的元组的时标不同时，                这种联合操作符输出结构的元组的时标应该如何
表示？另外，当一组分布流组合成单个逻辑流时，也会产生时标问题，例如2.2节中描述的
Web监控应用，或者在一个真实的分布式流中，例如传感器网络，当交叉的流中的元素是相
关时，比较其时标也会产生问题。
    在前面我们介绍了“内在”（implicit）时标，每来一个元组，系统为增加一个特殊域；
我们还介绍了“外在”（explicit）时标，每个时标都有一个专门的数据属性。外在时标用于
当每个元组对应于一个真实世界的事件的一次（这对于元组的意义而言非常重要）。内在时
标用于当源数据不包括时标信息时，或与元组准确的时间关连不重要时，但一般认为“进来
的”（recent）或“旧的”（old）也可能是重要的。内在时标和外在时标的区别就如同实时
数据库著作（temporal database literature）中事务（transaction）和有效时间（valid time）的
区别。
    外在时标有缺陷，     元组也许不按原来的顺序到达，            即元组中时标时间在后的元组也许比
时标时间在前的元组先到达。        这种缺乏次序保证的缺点使得，               如果元组被定义成与外在时标
相关的话，      滑动窗口的计算难于进行，         同时， 所有建立在次序之上的处理都难于进行。               但是，
只要输入流的时标是       “基本有序”                  的，
                         （almost-sorted） 则除了局部的摄动     （local perturbations）
之外，只需要很小的缓存，就很容易将无序的元组纠正。似乎可以做这样假设，当使用外在
时标时，元组将按粗略增加的时标顺序被传送。
    以联合为例，让我们来看看如何用二元操作符（binary operators）为输出元组设置合适
的时标。可以采用好几种方法，我们讨论其中两种。第一种方法较适用于内在时标，它不保
证从一个联合操作符得到的输出元组的顺序，                 但简单假定早到达的元组易于通过早期的联合
（join）；精确的顺序也许依赖于执行和调度的迅速变化（vagaries）。一个联合操作符产生
的每个元组被分配一个内子时标，时间被设为该元组生成时的时间。这种“尽力而为”
（best-effort）的方法的优点是实现了执行弹性最大化；它的不利之处是，在对结果的子查
询中，几乎不可能精确定义、确定滑动窗口的语义。
    第二中方法较既适用于外在时标，也适用于内在时标，它让用户规定查询的一部分，什
么时标被分配给多个相关流的结果元组。
    ………………（略）


5.3 DSMS 的查询处理体系结构

   ………………（略）



6 算法问题

   ………………（略）




                                   -7-
7 结论和未来工作展望

      在本文中，我们分析了一种新的连续数据流构架中的一系列问题：数据管理、查询处理
和算法问题。我们还提出了一些初始的解决方案，描述了过去和当前与数据流相关的工作，
提出了一个数据流管理系统（DSMS）的通用体系结构。在此，我们再回顾和思考如下一些
“元问题”       （meta-questions），这些问题与一种新的研究方法的动机和需求相关。
      ――是否通过对流的基本要素，如触发器、实时构造（temporal constructs）和数据管理
的增强处理，能使数据流系统能比传统的数据库技术更高效？
      ――数据库的研究者是否有必要为数据流开发基本的和通用的模型、                        算法和系统？也许
有人们能力为每一个特定的应用（如网络管理、Web 监控、安全、金融、传感器等等）开
发一个特定的解决方案。
      ――对数据流系统而言，是否有“最适用的应用程序”                 （killer apps）？
      我们相信所有这三个问题肯定都能被解答，当然，给出答案还需要时间。
      假定对这些问题的答案都是肯定的，那我们可以看到设计数据流系统的几个基本方面，
有一些我们在文中详细讨论过。一个重要的一般的问题是 DSMS 提供的接口。我们在斯坦
福的方法是扩展 SQL 来支持面向流的基本要素，                   它可以提供一个纯说明      （purely declarative）
的接口，      就像传统的数据库系统提供的一样，              虽然我们也允许直接采用查询计划          （submission
                。
of query plans） 与此相反的是，       Aurora 项目【16】则提供一个“盒和箭头”     （boxes and arrows）
程序，作为应用程序开发者的主要接口。
      本文还讨论了其它基本问题，包括时标、排序、如何支持滑动窗口查询、以及如何高效
处理块操作符。但我们基本没有谈一个主要问题：如何处理分布流。将高速流重新定向到一
个中央位置进行查询处理没有意义的，                   因此不可避免的需要在一些分布式流到达的点上进行
一些处理，        由此 DSMS 的每一级上都产生了一系列的问题。           另一个我们只在 4.5 节简要涉及
的问题是对流的限制问题，在查询处理过程中它们如何被使用（exploited）                       。最后，还存在
许多系统问题，如查询优化、概要结构（construction of synopses）           、资源管理、近似查询处
理，以及开发一个适当的并能被广泛接受的数据流系统的基准测试程序。
      从纯理论的视角，也许最吸引人的问题是定义扩展的关系操作（defining extensions of
relational operators）来处理数据流的架构，以及研究这些扩展的“流符号”                （stream algebra）
和其它属性。毫无疑问，这是开发一个通用的、易于理解的数据流查询处理机的关键。

致谢
     我们感谢斯坦福STREAM研究小组所有成员的贡献和回愦！

参考文献

   ………………（略）




                                     -8-