Tempura: A General Cost Based Optimizer Framework for Incremental Data Processing (Extended Version)
Zuozhi Wang, Kai Zeng, Botong Huang, Wei Chen, Xiaozong Cui, Bo Wang, Ji Liu, Liya Fan, Dachuan Qu, Zhenyu Hou, Tao Guan, Chen Li, Jingren Zhou
TTempura: A General Cost-Based Optimizer Framework forIncremental Data Processing (Extended Version)
Zuozhi Wang † , Kai Zeng ‡ , Botong Huang ‡ , Wei Chen ‡ , Xiaozong Cui ‡ , Bo Wang ‡ ,Ji Liu ‡ , Liya Fan ‡ , Dachuan Qu ‡ , Zhenyu Hou ‡ , Tao Guan ‡ , Chen Li † , Jingren Zhou ‡† University of California, Irvine ‡ Alibaba Group † { zuozhiw, chenli } @ics.uci.edu, ‡ { zengkai.zk, botong.huang, wickeychen.cw,xiaozong.cxz, yanyu.wb, niki.lj, liya.fly, dachuan.qdc, zhenyuhou.hzy, tony.guan,jingren.zhou } @alibaba-inc.com ABSTRACT
Incremental processing is widely-adopted in many applica-tions, ranging from incremental view maintenance, streamcomputing, to recently emerging progressive data warehouseand intermittent query processing. Despite many algorithmsdeveloped on this topic, none of them can produce an in-cremental plan that always achieves the best performance,since the optimal plan is data dependent. In this paper,we develop a novel cost-based optimizer framework, called
Tempura , for optimizing incremental data processing. Wepropose an incremental query planning model called TIPbased on the concept of time-varying relations, which canformally model incremental processing in its most generalform. We give a full specification of
Tempura , which can notonly unify various existing techniques to generate an opti-mal incremental plan, but also allow the developer to addtheir rewrite rules. We study how to explore the plan spaceand search for an optimal incremental plan. We conduct athorough experimental evaluation of
Tempura in various in-cremental processing scenarios to show its effectiveness andefficiency.
PVLDB Reference Format:
Zuozhi Wang, Kai Zeng, Botong Huang, Wei Chen, XiaozongCui, Bo Wang, Ji Liu, Liya Fan, Dachuan Qu, Zhenyu Ho, TaoGuan, Chen Li, Jingren Zhou. Tempura: A General Cost-BasedOptimizer Framework for Incremental Data Processing.
PVLDB ,12(xxx): xxxx-yyyy, 2019.DOI: https://doi.org/10.14778/xxxxxxx.xxxxxxx
1. INTRODUCTION
Incremental processing is widely used in data computa-tion, where the input data to a query is available gradually,and the query computation is triggered multiple times eachprocessing a delta of the input data. Incremental processingis central to database views with incremental view main-tenance (IVM) [21, 27, 33, 9] and stream processing [11,7, 22, 37, 46]. It has been adopted in various application
This work is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License. To view a copyof this license, visit http://creativecommons.org/licenses/by-nc-nd/4.0/. Forany use beyond those covered by this license, obtain permission by [email protected]. Copyright is held by the owner/author(s). Publication rightslicensed to the VLDB Endowment.
Proceedings of the VLDB Endowment,
Vol. 12, No. xxxISSN 2150-8097.DOI: https://doi.org/10.14778/xxxxxxx.xxxxxxx domains such as active databases [10], resumable query ex-ecution [18], approximate query processing [19, 52, 29], etc.New advancements in big data systems make data inges-tion more real-time and analysis increasingly time sensitive,which further boost the adoption of the incremental pro-cessing model. Here are a few examples of emerging appli-cations.
Progressive Data Warehouse [48].
Enterprise datawarehouses usually have a large amount of automated rou-tine analysis jobs, which usually have a stringent scheduleand deadline determined by various business logic. For ex-ample, at Alibaba, there is a need to schedule a daily re-port query after 12 am when the previous day’s data hasbeen fully collected and deliver the results by 6 am sharpbefore the bill-settlement time. Till now, its automatedroutine analysis jobs are still predominately handled usingbatch processing, causing dreadful “rush hour” schedulingpatterns. This approach puts pressure on resources dur-ing traffic hours, and leaves the resources over-provisionedand wasted during the off-traffic hours. Incremental pro-cessing can answer routine analysis queries progressively asdata gets ingested, resulting in a more flexible resource usagepattern, which can effectively smoothen the resource skew.
Intermittent Query Processing [44].
Many modernapplications require querying an incomplete dataset with theremaining data arriving in an intermittent yet predictableway. Intermittent query processing can leverage incremen-tal processing to balance latency for maintaining standingqueries and resource consumption by exploiting knowledgeof data-arrival patterns. For instance, when querying dirtydata, the data is usually first cleaned and then fed into adatabase. The data cleaning step can quickly spill the cleanpart of the data but needs to conduct a time-consumingcleaning processing on the dirty part. Intermittent queryprocessing can use incremental processing to quickly de-liver informative but partial results on the clean data tothe user, before delivering the full results after processingall the cleaned data.A key problem behind these applications is that given aquery, how to generate an efficient incremental-computationplan. Previous studies focused on various aspects of theproblem, e.g., incremental computation algorithms for a spe-cific setting such as [21, 9, 33], or algorithms to determinewhich intermediate states to materialize given an incremen-tal plan [39, 53, 44]. The following example based on twocommonly used algorithms shows that none of them can gen-1 a r X i v : . [ c s . D B ] S e p rate an incremental-computation plan that is always opti-mal, since the optimal plan is data dependent . Example 1 (Reporting consolidated revenue). summary =with sales _ status as (SELECT sales . o_id , category , price , cost FROM sales
LEFT OUTER JOIN returns ON sales . o_id = returns . o_id )SELECT category ,SUM(IF( cost IS NULL, price , - cost )) AS gross
FROM sales _ status GROUP BY category
In the aforementioned progressive data warehouse sce-nario, consider a routine analysis job in Example 1 thatreports the gross revenue after consolidating the sales orderswith the returned ones. We want to incrementally computethe job as data gets ingested, to utilize the cheaper free re-sources occasionally available in the cluster. Thus, we wantto find an incremental plan with the optimal resource usagepattern, i.e., carrying out as much early computation as pos-sible using cheaper free resources to keep the overall resourcebill low. This query can be incrementally computed in dif-ferent ways as the data in tables sales and returns becomesavailable gradually. For instance, consider two basic meth-ods used in IVM and stream computing. (1) A typical viewmaintenance approach (denoted as
IM-1 ) treats summary asviews [21, 26, 27, 52]. It always maintains summary as if itis directly computed from the data of sales and returns seenso far. Therefore, even if a sales order will be returned inthe future, its revenue is counted into the gross revenue tem-porarily. (2) A typical stream-computing method (denotedas
IM-2 ) avoids such retraction [5, 34, 36, 45]. It holds back sales orders that do not join with any returns orders until alldata is available. Clearly, if returned orders are rare,
IM-1 can maximize the amount of early computation and thusdeliver better resource-usage plans. Otherwise, if returnedorders are often,
IM-2 can avoid unnecessary re-computationcaused by retraction and thus be better. (See § § • We propose a new theory called the
TIP model on top oftime-varying relation (TVR) that formulates incrementalprocessing using TVR, and defines a formal algebra forTVRs ( § § • We build a Cascade-style optimizer named
Tempura . Itsupports cost-based optimization for incremental queryplanning based on the TIP model. We discuss how toexplore the plan space ( §
5) and search for an optimal in-cremental plan in
Tempura ( § • We conduct a thorough experimental evaluation of the
Tempura optimizer in various application scenarios. Theresults show the effectiveness and efficiency of
Tempura ( §
2. PROBLEM FORMULATION
In this section we formally define the problem of cost-based optimization for incremental computation. We elab-orate on the running example to show that execution plansgenerated by different algorithms have different costs. Wethen illustrate the challenges to solve the problem.
Despite the different requirements in various applications,a key problem of cost-based incremental query planning(IQP) can be modeled uniformly as a quadruple ( (cid:126)T , (cid:126)D, (cid:126)Q, ˜ c ) , where: • (cid:126)T = [ t , . . . , t k ] is a vector of time points when we cancarry out incremental computation. Each t i can be eithera concrete physical time, or a discretized logical time. • (cid:126)D = [ D , · · · , D k ] is a vector of data, where D i representsthe input data available at time t i , e.g., the delta datanewly available at t i , and/or all the data accumulated upto t i . For a future time point t i , D i can be expected datato be available at that time. • (cid:126)Q = [ Q , . . . , Q k ] is a vector of queries. Q i defines theexpected results that are supposed to be delivered by theincremental computation carried out at t i . If there is norequired output at t i , then Q i is a special empty query ∅ . • ˜ c is a cost function that we want to minimize.The goal is to generate an incremental plan P = [ P , . . . , P k ]where P i defines the task (a physical plan) to execute attime t i , such that (1) ∀ ≤ i ≤ k , P i can deliver the resultsdefined by Q i , and (2) the cost ˜ c ( P ) is minimized. Next weuse a few example IQP scenarios to demonstrate how theycan be modeled using the above definition. Incremental View Maintenance ( IVM-PD ). Consider theproblem of incrementally maintaining a view defined by query Q . Instead of using any concrete physical time, we can usetwo logical time points (cid:126)T = [ t i , t i +1 ] to represent a gen-eral incremental update at t i +1 of the result computed at t i . We assume that the data available at t i is the dataaccumulated up to t i , whereas at t i +1 the new delta data(insertions/deletions/updates) between t i and t i +1 is avail-able, denoted by (cid:126)D = [ D, ∆ D ]. At both t i and t i +1 wewant to keep the view up to date, i.e., (cid:126)Q is defined as2 i = Q ( D ) , Q i +1 = Q ( D + ∆ D ). As the main goal is tofind the most efficient incremental plan, we set ˜ c to be thecost of P i +1 , i.e., the execution cost at t i +1 . (For a formaldefinition see ˜ c v in § Q involves multipletables and we want to use different incremental plans forupdates on different tables, we can optimize multiple IQPproblems by setting ∆ D to the delta data on only one of thetables at a time. Progressive Data Warehouse ( PDW-PD ). We model thisscenario by choosing (cid:126)T as physical time points of the plannedincremental runs. Note that we only require the incrementalplan to deliver the results defined by the original analysis job Q at the last run, that is, at the scheduled deadline of thejob, without requiring output during the early runs. Thus, (cid:126)Q = [ ∅ , · · · , ∅ , Q ]. We set ˜ c as a weighted sum of the costsof all plans in P (see ˜ c w ( O ) in § (cid:126)D is decided for logicaltimes or physical times in the future, and what if the chosen (cid:126)T is subject to change, will be presented in § sales o id cat price o c t o c t o c t o c t o c t o c t o c t returns o id cost o t o t o t (a) sales status o id cat price cost o c o c o c o c o c o c o c summary cat gross c c (b) sale status at t o id cat price cost o c o c o c o c sale status at t o id cat price cost o c − o c o c o c o c (c) sale status at t o id cat price cost o c sale status at t o id cat price cost o c o c o c o c o c o c (d) Figure 1: (a) Data arrival patterns of sales and re-turns , (b) results of query sales status and summary at t , (c) incremental results of sales status produced byview maintenance at t and t , and (d) incrementalresults of sales status produced by stream computingat t , t . We elaborate different plans to answer the query in Exam-ple 1 using the
PDW-PD definition above. Suppose the query summary is originally scheduled at t , but the progressivedata warehouse decides to schedule an early execution at t on partial inputs. Assume the records visible at t and t in sales and returns are those in Fig. 1(a). In this IQP problem,we have (cid:126)T = [ t , t ] and (cid:126)Q = [ ∅ , q ], where q is the summary query, (cid:126)D is shown in Fig. 1(a), and ˜ c is the cost functionthat takes the weighted sum of the resources used at t and t . Many existing incremental techniques (e.g., view main-tenance, stream computing, mini-batch execution, and soon [21, 27, 9, 11]) can be applied to generate a plan. Con-sider two commonly used methods IM-1 and
IM-2 . Method
IM-1 treats sales status and summary as views,and uses incremental computation to keep the views alwaysup to date with respect to the data seen so far. The incre-mental computation is done on the delta input. For exam-ple, the delta input to sales at t includes tuples { o , o , o } .Fig. 1(c) depicts sales status ’s incremental outputs at t and t , respectively, where / − returns record (e.g., o at t )can arrive much later than its corresponding sales record(e.g., the shaded o at t ). Therefore, a sales record may beoutput early as it cannot join with a returns record at t , butretracted later at t when the returns record arrives, such asthe shaded tuple o in Fig. 1(c). Method
IM-2 can avoid such retraction during incremen-tal computation. Specifically, in the outer join of sales status ,tuples in sales that do not join with tuples from returns fornow (e.g., o , o , and o ) may join in the future, and thuswill be held back at t . Essentially the outer join is com-puted as an inner join at t . The incremental outputs of sales status are shown in Fig. 1(d).In addition to these two, there are many other methods aswell. Generating one plan with a high performance is non-trivial due to the following reasons. (1) The optimal incre-mental plan is data dependent, and should be determined ina cost-based way. In the running example,
IM-1 computes 9tuples (5 tuples in the outer join and 4 tuples in the aggre-gate) at t , and 10 tuples at t . Suppose the cost per unit at t is 0.2 (due to fewer queries at that time), and the cost perunit at t is 1. Then its total cost is 9 × . × . IM-2 computes 6 tuples at t , and 11 tuples at t , with atotal cost of 6 × . × . IM-1 is more effi-cient, since it can do more early computation in the outerjoin, and more early outputs further enable summary to domore early computation. On the contrary, if retraction isoften, say, with one more tuple o at t , then IM-2 will be-come more efficient, as it costs 12 . . IM-1 . The reason is that retraction wastes early computa-tion and causes more re-computation overhead. Notice thatthe performance difference of these two approaches can bearbitrarily large. (2) The entire space of possible plan alternatives is verylarge.
Different parts within a query can choose differentincremental methods. Even if early computing the entirequery does not pay off, we can still incrementally execute asubpart of the query. For instance, for the left outer join in sales status , we can incrementally shuffle the input data onceit is ingested without waiting for the last time. IQP needsto search the entire plan space ranging from the traditionalbatch plan at one end to a fully-incrementalized plan at theother. (3) Complex temporal dependencies between different in-cremental runs can also impact the plan decision.
For in-stance, during the continuous ingestion of data, query sales status may prefer a broadcast join at t when the returns table issmall, but a shuffled hash join at t when the returns ta-ble gets bigger. But such a decision may not be optimal,as shuffled hash join needs data to be distributed accord-ing to the join key, which broadcast join does not provide.Thus, different join implementations between t and t in-cur reshuffling overhead. IQP needs to jointly consider allincremental runs across the entire timeline.Such complex reasoning is challenging, if not impossible,even for very experienced experts. To solve this problem,3e offer a cost-based solution to systematically search theentire plan space to generate an optimal plan. Our solutioncan unify different incremental computation techniques in asingle plan.
3. THE TIP MODEL
The core of incremental computation is to deal with re-lations changing over time, and understand how the com-putation on these relations can be expanded along the timedimension. In this section, we introduce a formal theorybased on the concept of time-varying relation (TVR) [11,14, 41], called the
TVR-based Incremental query Planning(TIP) Model . The model naturally extends the relationalmodel by considering the temporal aspect to formally de-scribe incremental execution. It also includes various data-manipulation operations on TVR’s, as well as rewrite rulesof TVR’s in order for a query optimizer to define and ex-plore a search space to generate an efficient incrementalquery plan. To the best of our knowledge, the proposedTIP model is the first one that not only unifies differentincremental computation methods, but also can be used todevelop a principled cost-based optimization framework forincremental execution. We focus on definitions and algebraof TVR’s in this section, and dwell on TVR rewrite rules in § Definition A time-varying relation (TVR) R is a map-ping from a time domain T to a bag of tuples belonging to aschema. A snapshot of R at a time t , denoted R t , is the instance of R at time t . For example, due to continuous ingestion, table sales ( S ) in Example 1 is a TVR, depicted as the blue linein Fig. 2. On the line, tables 1 (cid:13) and 2 (cid:13) show the snapshotsof S at t and t , i.e., S t and S t , respectively. Traditionaldata warehouses run queries on relations at a specific time,while incremental execution runs queries on TVR’s. Definition 3 (Querying TVR).
Given a TVR R ontime domain T , applying a query Q on R defines anotherTVR Q ( R ) on T , where [ Q ( R )] t = Q ( R t ) , ∀ t ∈ T . In other words, the snapshot of Q ( R ) at t is the sameas applying Q as a query on the snapshot of R at t . Forinstance, in Fig. 2, joining two TVR’s sales ( S ) and returns ( R ) yields a TVR ( S (cid:46)(cid:47) lo R ), depicted as the green line.Snapshot ( S (cid:46)(cid:47) lo R ) t is shown as table 3 (cid:13) , which is equalto joining S t and R t . We denote left outer-join as (cid:46)(cid:47) lo , leftanti-join as (cid:46)(cid:47) la , left semi-join as (cid:46)(cid:47) ls , and aggregate as γ .For brevity, we use “ Q ” to refer to the TVR “ Q ( R )” whenthere is no ambiguity. Besides as a sequence of snapshots, a TVR can be en-coded from a delta perspective using the changes betweentwo snapshots. We denote the difference between two snap-shots of TVR R at t, t (cid:48) ∈ T ( t < t (cid:48) ) as the delta of R from t to t (cid:48) , denoted ∆ R t (cid:48) t , which defines a second-order TVR. Definition 4 (TVR difference). ∆ R t (cid:48) t defines a map-ping from a time interval to a bag of tuples belonging to thesame schema, such that there is a merge operator “ + ” sat-isfying R t + ∆ R t (cid:48) t = R t (cid:48) . Table 4 (cid:13) in Fig. 2 shows ∆(
S (cid:46)(cid:47) lo R ) t t , which is the deltaof snapshots ( S (cid:46)(cid:47) lo R ) t and ( S (cid:46)(cid:47) lo R ) t . Here multiplic-ities / − γ ( S (cid:46)(cid:47) lo R ) t t can be de-fined differently as Table 5 (cid:13) in Fig. 2. Here the merge op-erator + directly sums up the partial SUM values (the gross attribute) per category . For category c , summing up thepartial SUM ’s in γ ( S (cid:46)(cid:47) lo R ) t and ∆ γ ( S (cid:46)(cid:47) lo R ) t t yields thevalue in γ ( S (cid:46)(cid:47) lo R ) t , i.e., 280 + ( −
15) = 265. To differenti-ate these two merge operators, we denote the merge operatorfor
S (cid:46)(cid:47) lo R as + , and the merge operator for γ ( S (cid:46)(cid:47) lo R )as + sum .This observation shows that the way to define TVR deltasand the merge operator + is not unique. In general, asstudied in previous research [32, 52], the difference betweentwo snapshots R t and R t (cid:48) can have two types:(1) Multiplicity Perspective . R t and R t (cid:48) may have differentmultiplicities of tuples. R t may have less or more tuples than R t (cid:48) . In this case, the merge operator (e.g., + ) combinesthe same tuples by adding up their multiplicities.(2) Attribute Perspective . R t may have different attributevalues in some tuples compared to R t (cid:48) . In this case, themerge operator (e.g., + sum ) groups tuples with the sameprimary key, and combines the delta updates on the changedattributes into one value. Aggregation operators usuallyproduce this type of snapshots and deltas. Formally, dis-tributed aggregation in data-parallel computing platformsis often modeled using four methods [51]:1. Initialize : It is called once before any data is suppliedwith a given key to initialize the aggregate state.2.
Iterate : It is called every time a tuple is provided witha matching key to combine the tuple into the aggregatestate.3.
Merge : It is called every time when combining two ag-gregate states with the same key into a single aggregatestate.4.
Final : It is called at the end on the final aggregate stateto produce a result.For an aggregate function γ , the snapshots/deltas are theaggregate states computed using Initialize and
Iterate on partial data; the merge operator + γ is defined using Merge ; and at this end, the attribute-perspective snapshot isconverted by
Final to produce the multiplicity-perspectivesnapshot, i.e., the final result. For instance, for the aggre-gate function
AVG , its snapshot/delta is an aggregate stateconsisting of a running
SUM and
COUNT on the partial data;the merge operator +
AVG sums up the running
SUM and
COUNT ,and at the end, the running
SUM is divided by the running
COUNT to get the final average. Note that for aggregatessuch as
MEDIAN whose state needs to be the full set of tu-ples,
Iterate and
Merge degenerate to no-op.Furthermore, for some merge operator +, there is an in-verse operator − , such that R t (cid:48) − R t = ∆ R t (cid:48) t . For instance,the inverse operator − sum for + sum is defined as taking Note that
Final also needs to filter out empty groups withzero contributing tuples. We omit this detail due to thelimited space.4 igure 2: Example TVR’s and their relationships. the difference of
SUM values per category between two snap-shots.
4. TVR REWRITE RULES
Rewrite rules expressing relational algebra equivalence arethe key mechanism that enables traditional query optimizersto explore the entire plan space. As TVR snapshots anddeltas are simply static relations, traditional rewrite rulesstill hold within a single snapshot/delta. However, theserewrite rules are not enough for incremental query planning,due to their inability to express algebra equivalence betweenTVR concepts.To capture this more general form of equivalence, in thissection, we introduce
TVR rewrite rules in the TIP model,focusing on logical plans. We propose a trichotomy of TVRrewrite rules, namely
TVR-generating rules , intra-TVR rules ,and inter-TVR rules , and show how to model existing in-cremental techniques using these three types of rules. Thismodeling enables us to unify existing incremental techniquesand leverage them uniformly when exploring the plan space;it also allows IQP to evolve by adding new TVR rewriterules. Most existing work on incremental computation revolvesaround the notion of delta query that can be described asEq. 1 below. Q ( R t (cid:48) ) = Q ( R t + ∆ R t (cid:48) t ) = Q ( R t ) + d Q ( R t , ∆ R t (cid:48) t ) . (1)The idea is intuitive: when an input delta ∆ R t (cid:48) t arrives,instead of recomputing the query on the new input snapshot R t (cid:48) , one can directly compute a delta update to the previousquery result Q ( R t ) using a new delta query d Q . Essentially,Eq. 1 contains two key parts—the delta query d Q and themerge operator +, which correspond to the first two types ofTVR rewrite rules, namely TVR-generating rules and intra-TVR rules , respectively.
TVR-Generating Rules . Formally, TVR-generating rulesdefine for each relational operator on a TVR, how to com-pute its deltas from the snapshots and deltas of its inputTVRs. In other words, TVR-generating rules define d Q foreach relational operator Q such that ∆ Q t (cid:48) t = d Q ( R t , ∆ R t (cid:48) t ).Many previous studies on deriving delta queries under differ-ent semantics [16, 17, 21, 26, 27] fall into this category. Asan example, Fig. 3(a) shows the TVR-generating rules usedby IM-1 in Example 1. The rules for left outer-join (Rule (1)) and aggregate (Rule (2)) are from [26] and [27], re-spectively. For simplicity, we separate the inserted/deletedpart in a TVR delta, and denote them by superscripting ∆with + / − . The blue lines in Fig. 3(a) demonstrate theseTVR-generating rules in a plan space. Intra-TVR Rules . Intra-TVR rules define the conversionbetween the snapshots and deltas of a single TVR. As inEq. 1, the merge operator + defines how to merge Q ’s snap-shot Q t and delta ∆ Q t (cid:48) t into a new snapshot Q t (cid:48) . Otherexamples of intra-TVR rules include rules that merge deltasinto a new delta, e.g., for a TVR R , ∆ R t (cid:48) t + ∆ R t (cid:48)(cid:48) t (cid:48) = ∆ R t (cid:48)(cid:48) t ,or rules that take the difference between snapshots/deltasif the merge operator + has an inverse operator − , e.g., R t (cid:48) − R t = ∆ R t (cid:48) t . The red lines in Fig. 3(a) demonstrate theintra-TVR rules used by IM-1 in Example 1. Note thatwhen merging the snapshot/delta of
S (cid:46)(cid:47) lo R (subquery sales status ), we use + (Rule (3)), whereas when merg-ing the snapshot/delta of γ ( S (cid:46)(cid:47) lo R ) (query summary ), weuse + sum ((Rule (4)). There are incremental techniques that cannot be modeledusing the two aforementioned types rules alone. The
IM-2 approach in Example 1 is such an example. Different from
IM-1 , approach
IM-2 does not directly deliver the snapshotof
S (cid:46)(cid:47) lo R at t . Instead, it delivers only the subset of S (cid:46)(cid:47) lo R that is guaranteed not to be retracted in the future,essentially the results of S (cid:46)(cid:47) R . At t when the data isknown to be complete, IM-2 computes the rest part of
S (cid:46)(cid:47) lo R , essentially S (cid:46)(cid:47) la R , then pads with nulls to match theoutput schema.This observation shows another family of incremental tech-niques: without computing Q directly, one can incremen-tally compute a set of different queries { Q (cid:48) , · · · , Q (cid:48) k } , andthen apply another query P on their results to get thatof Q , formally described as Eq. 2. The intuition is that { Q (cid:48) , · · · , Q (cid:48) k } may be more amenable to incremental com-putation and thus may be more efficient than directly incre-mentally computing Q : Q ( R ) = P ( Q (cid:48) ( R ) , · · · , Q (cid:48) k ( R )) . (2)The family of techniques that Eq. 2 can describe are verygeneral. They all rely on certain rewrite rules describingthe equivalence between snapshots/deltas of multiple TVRs.We summarize this family of techniques into a third type ofrules namely inter-TVR rules . Below we demonstrate using For brevity, some padding of null to match outer join’sschema is omitted in Fig. 3(a) and Fig. 3(c). This paddingcan simply be implemented using a project operator.5
𝑆 𝑅 𝑡 𝑡 Δ 𝛾𝛾 ⋈ 𝑙𝑜 Δ + 𝑠𝑢𝑚 ⋈ 𝑙𝑜 + ⋈ 𝑙𝑜 𝑆 𝑅 ⋈ 𝑙𝑜 𝛾 ( 𝑆 𝑅 )⋈ 𝑙𝑜 Δ 𝑡 ′ 𝑡 ( 𝑆 𝑅 = (
𝑆 𝑅 Δ( 𝑆 𝑅 ⋈ 𝑙𝑜 ) 𝑡 ⋈ 𝑙𝑜 ) 𝑡 + ⋈ 𝑙𝑜 ) 𝑡 𝑡 𝛾 ( 𝑆 𝑅 = 𝛾 ( 𝑆 𝑅 Δ 𝛾 ( 𝑆 𝑅 ⋈ 𝑙𝑜 ) 𝑡 ⋈ 𝑙𝑜 ) 𝑡 + 𝑠𝑢𝑚 ⋈ 𝑙𝑜 ) 𝑡 𝑡 ( )( )( ) ( ) ( )( ) ( )( ) Δ 𝛾 ( 𝑆 𝑅 = 𝛾 (Δ( 𝑆 𝑅 )⋈ 𝑙𝑜 ) 𝑡 𝑡 ⋈ 𝑙𝑜 ) 𝑡 𝑡 𝐴𝑡 𝑑𝑒𝑙𝑒𝑡𝑖𝑛𝑔
Δ ,Δ 𝑎𝑛𝑑 𝑖𝑛𝑠𝑒𝑟𝑡𝑖𝑛𝑔
Δ ,Δ : 𝑆 − 𝑅 − 𝑆 + 𝑅 + Δ( 𝑆 𝑅 =⋈ 𝑙𝑜 ) 𝑡 𝑡 Δ + ⋈ Δ +( −Δ ) (Δ ) 𝑆 + ⋈ 𝑙𝑜 𝑅 𝑡 𝑆 𝑡 𝑅 + 𝑆 𝑡 𝑆 − ⋈ 𝑙𝑠 𝑅 − ⋈ 𝑙𝑎 𝑅 𝑡 −Δ − ⋈ Δ −( −Δ ) (Δ ) 𝑆 − ⋈ 𝑙𝑜 𝑅 𝑡 𝑆 𝑡 𝑅 − 𝑆 𝑡 𝑆 − ⋈ 𝑙𝑠 𝑅 + ⋈ 𝑙𝑎 𝑅 𝑡 (a) { } { } (b) 𝑃 + 𝑡 𝑡 𝑆 ⋈ 𝑅 𝑆 𝑅 ⋈ 𝑙𝑎 𝑄 𝐷 𝑄 𝐼 𝑄𝑆 𝑅 ⋈ 𝑙𝑜 𝑆 𝑅 𝑡 ′ ⋈ + ⋈ 𝑙𝑜 𝑄 ( ) 𝑄 𝐷 Δ 𝑡 ′ 𝑡 Δ 𝑡 𝑡 ′ { }{ } 𝐴𝑡 , = ⋈ , = 𝑡 ′ 𝑄 𝐷𝑡 ′ 𝑆 𝑡 ′ 𝑅 𝑡 ′ 𝑄 𝐼𝑡 ′ 𝑆 𝑡 ′ ⋈ 𝑙𝑎 𝑅 𝑡 ′ 𝐴𝑡 , = , = ∅ 𝑡 𝑄 𝐷𝑡 𝑆 𝑡 ⋈ 𝑙𝑜 𝑅 𝑡 𝑄 𝐼𝑡 𝐴𝑡 ,Δ = ⋈ Δ = {( , ,150,20)} 𝑡 ′ 𝑄 𝐷𝑡 ′ 𝑡 𝑆 𝑡 𝑅 𝑡 ′ 𝑡 𝑜 𝑐 Δ = −[ ( ) Δ ] = −{( , ,150, 𝑛𝑢𝑙𝑙 )} 𝑄 𝐼𝑡 ′ 𝑡 𝜎 𝑐𝑜𝑠𝑡 = 𝑛𝑢𝑙𝑙 𝑄 𝑡 ⋈ 𝑙𝑠 𝑄 𝐷𝑡 ′ 𝑡 𝑜 𝑐 𝐴𝑡 ,Δ = Δ ⋈ = {( ,...),( ,...),( ,...)} 𝑡 𝑄 𝐷𝑡 𝑡 ′ 𝑆 𝑡 𝑡 ′ 𝑅 𝑡 ′ 𝑜 𝑜 𝑜 ( )( )( ) ( ) ( ) ( )( ) (c) { } { } (d) Figure 3: (a) Examples of TVR-generating and intra-TVR rules, (b) examples of inter-TVR equivalence rulesin stream computing, (c) examples of inter-TVR equivalence rules in outer-join view maintenance, and (d)the incremental plan space of Example 1. a couple of existing incremental techniques how they can bemodeled by inter-TVR rules. (1) The
IM-2 approach : Let us revisit
IM-2 using the ter-minology of inter-TVR rules. Formally,
IM-2 decomposes Q = S (cid:46)(cid:47) lo R into two parts, Q P and Q N , defined below: Q P t = S t (cid:46)(cid:47) R t , Q N t = S t (cid:46)(cid:47) la R t , Q t = Q P t + Q N t (3)where Q P is a positive part that will not retract any tuple ifboth S and R are append-only, whereas Q N represents a partthat could cause retractions at insertions to S and R . Theinter-TVR rule in Eq. 3 states that any snapshot of Q can bedecomposed into snapshots of Q P and Q N at the same time.Similar decomposition holds for the aggregate γ in summary too, just with a different merge operator + sum . Fig. 3(b)depicts these rules in a plan space. As it is much easierto incrementally compute inner join than left outer join, Q P can be incrementally computed using the TVR rewriterules in § Q , whereas Q N cannot be easily incrementalized, and is not computed untilthe completion time. (2) Outer-join view maintenance : [33] proposed a methodto incrementally maintain outer-join views. Its main ideacan be summarized using two types of inter-TVR rules: Q t = Q Dt + Q It + Q U t (4a) ∆ Q It (cid:48) t = P (∆ Q Dt (cid:48) t , Q t )(4b)The first type of rules described by Eq. 4a decompose aquery into three parts given an update to a single inputtable: a directly affected part Q D , an indirectly affectedpart Q I , and an unaffected part Q U , where Q D , Q I , and Q U are defined formally using the join-disjunctive normalform of Q . Due to space limitation we refer the readers to [33] for formal details. Intuitively, an insertion (deletion)into the input table will cause insertions (deletions) to Q D and deletions (insertions) to Q I , but leave Q U unaffected.Eq. 4b describes the second type of rules that give a wayto directly compute the deltas of Q I from the delta of Q D and the previous snapshot of Q . At updates, one can usethe TVR-generating rules to compute the delta of Q D , andthe inter-TVR rules in Eq. 4b to get delta of Q I , and thesetwo deltas can be merged to incrementally compute Q , i.e.,∆ Q t (cid:48) t = ∆ Q Dt (cid:48) t + ∆ Q It (cid:48) t .Take query sales status as an example. Fig. 3(c) showsthe corresponding inter-TVR rules. As the algorithm in [33]considers updating one input table at a time, we insert avirtual time point t (cid:48) between t and t , assuming R and S are updated separately at t (cid:48) and t . Rule (0) shows thedecomposition of sales status at t (cid:48) and t following the inter-TVR rule in Eq. 4a. By applying the TVR-generating rules, Q D can be incrementally computed as rules (1) and (3);whereas Q I can be incrementally computed following theinter-TVR rule in Eq. 4b, as shown in rule (2). Combiningthem yields the delta of Q as in Table 4 (cid:13) in Fig. 2. (3) Higher-order view maintenance : [9, 38] proposed ahigher-order view-maintenance algorithm, which can also beexpressed by inter-TVR rules. The main idea is to treat thedeltas of a query Q as another TVR, and continue applyingTVR rewrite rules to incrementally compute it. Formally,considering a query Q and updates to one of its inputs R ,the algorithm can be summarized as the following inter-TVRrule. ∆ Q t (cid:48) t = d Q ( R t , ∆ R t (cid:48) t ) = P ( M t , ∆ R t (cid:48) t ) (5)The rule decomposes the delta query into two parts: thedelta update ∆ R t (cid:48) t , and an update-independent subquery M that does not involve ∆ R t (cid:48) t . The two parts are combined6sing a query P to get the delta of Q . If M is a queryinvolving input relations other than R , it can be further de-composed again with respect to updates to each of its inputrelations according to Eq. 5, until it becomes a constant.We refer the readers to [9] for a detailed algorithm. Takethe summary query and updates to sales ( S ) as an example(we denote returns as R). Applying Eq. 5, we can decomposeit as ∆ Q t (cid:48) t = γ category ; SUM ( r ) (∆ S t (cid:48) t (cid:46)(cid:47) lo M t ) , where M t = γ o id ; total = SUM ( cost ) ( R t ) ,r = IF ( total IS NULL , price , − total ) .M essentially preprocesses returns by computing the totalcost per o id , and P computes the gross revenue per cate-gory by summing up the precomputed total cost in M or theprices of the new orders added to S . Then M is material-ized as a higher-order view and can be further incrementallymaintained with respect to updates to returns by repeatedlyapplying the inter-TVR rule to generate higher-order views. The above concepts and observations lay a theoreticalfoundation for our IQP framework. Different TVR rulescan be extended individually and can work with each otherautomatically. For example, TVR-generating rules can beapplied on any TVR created by inter-TVR rules. By jointlyapplying TVR rewrite rules and traditional rewrite rules,we can explore a plan space much larger than that of anyindividual existing incremental method. For instance, if weoverlay Fig. 3(a) and 3(b), we can achieve the plan spaceas shown in Fig. 3(d). Any tree rooted at γ ( S (cid:46)(cid:47) lo R ) t isa valid incremental plan for Example 1, e.g., the red linesindicate the plan used by IM-2 .In the next two sections, we discuss how to build an op-timizer framework based on the TIP model, including plan-space exploration ( §
5) and selecting an optimal incrementalplan ( §
5. PLAN-SPACE EXPLORATION
In this section we study how
Tempura explores the spaceof incremental plans. Existing query optimizers do the ex-ploration only for a specific time. To support query opti-mization in incremental processing, we need to explore amuch bigger plan space by considering not only relations atdifferent times, but also transformations between them. Westudy how to extend existing query optimizers to supportcost-based optimization for incremental processing based onthe TIP model. As an example, we consider one of thestate-of-the-art solutions, the Cascades-style cost-based op-timizer [23, 25]. We illustrate how to incorporate the TIPmodel into such an optimization framework to develop thecorresponding optimizer framework called
Tempura . Tempura consists of two main modules. (1)
Memo : itkeeps track of the explored plan space, i.e., all plan alter-natives generated, in a succinct data structure, typicallyrepresented as an AND/OR tree, for detecting redundantderivations and fast retrieval. (2)
Rule engine : it manages Here we do not assume o id as the primary key of returns .Say returns could contain multiple records for a returnedorder due to different costs such as shipping cost, productdamage, inventory carrying cost, etc. all the transformation rules, which specify algebraic equiva-lence laws and suitable physical implementations of logicaloperators, and monitors new plan alternatives generated inthe memo. Whenever there are changes, the rule enginefires applicable transformation rules on the newly-generatedplans to add more plan alternatives to the memo. The memoand rule engine of a traditional Cascades optimizer lack thecapability to support IQP. We will focus on the key adapta-tions we made on the two modules to incorporate the TIPmodel.
The memo in the traditional Cascades-style optimizer onlycaptures two levels of equivalence relationship: logical equiv-alence and physical equivalence . A logical equivalence classgroups operators that generate the same result set; withineach logical equivalence class, operators are further groupedinto physical equivalence classes by their physical proper-ties such as sort order, distribution, etc. The “TraditionalMemo” part in Fig. 4(a) depicts the traditional memo of the sales status query. For brevity, we omit the physical equiv-alence classes. For instance,
LeftOuterJoin [0,1] has GroupsG0 and G1 as children, and it corresponds to the plan treerooted at (cid:46)(cid:47) lo . G2 represents all plans logically equivalentto LeftOuterJoin [0,1].However, the above two equivalences are not enough tocapture the rich relationships along the time dimension andbetween different incremental computation methods in theTIP model. For example, the relationship between snap-shots and deltas of a TVR cannot be modeled using thelogical equivalence due to the following reasons. Two snap-shots at different times produce different relations, and thesnapshots and deltas do not even have the same schema(deltas have an extra
Tempura
Memo” partin Fig. 4(a). • Intra-TVR relationship specifies the snapshot/deltarelationship between logical equivalence classes of oper-ators and the corresponding TVR’s. For example, thetraditional memo only models scanning the full content of S , i.e., S t , represented by G0, while the Tempura memomodels two more scans: scanning the partial content of S available at t ( S t ), and scanning the delta input of S newly available at t (∆ S t t ). These two new scans arerepresented by G3 and G5, and the memo uses an explicitTVR-0 to keep track of these intra-TVR relationships. • Inter-TVR relationship specifies the user-defined rela-tionship between TVR’s introduced by inter-TVR equiv-alence rules. For example, the
IM-2 approach decomposesTVR-2 (
S (cid:46)(cid:47) lo R ) into two parts Q P and Q N as discussedin §
3, represented by TVR-3 and TVR-4, respectively. Itis worth noting that the above relationships are transitive.For instance, as G7 is the snapshot at t of TVR-3 andTVR-3 is the Q P part of TVR-2, it is the snapshot at t of the Q P part of TVR-2. As the memo of
Tempura strictly subsumes a traditionalCascades memo, traditional rewrite rules can be adoptedand work without modifications. Besides, the rule engine of
Tempura supports TVR rewrite rules.
Tempura allows op-7 eftOuterJoin[0, 1]G2
S R
Scan(returns@t )[]G1Scan(sales@t )[]G0 LeftOuterJoin[0, 1]G2 LeftAntiJoin[0, 1]G10InnerJoin[0, 1]G7 InnerJoin[3, 4]G8DeltaInnerJoin[3,4,5,6]G9G1 G4 G6Union[7,10]AdditiveUnion[8, 9]Scan(returns@t )[] Scan(returns@t )[] Scan(returns@(t t ])[]G0 G3 G5Scan(sales@t )[] Scan(sales@t )[] Scan(sales@(t t ])[]TVR-4t : G10Q P : N/A Q N : TVR-4 TVR-1 t : G4Q N : N/AQ P : TVR-1Δt ,t : G6t : G1 TVR-0 t : G3Q N : N/AQ P : TVR-0Δt ,t : G5t : G0TVR-2t : G2 Q N : TVR-4Q P : TVR-3TVR-3 t : G8Q N : N/AQ P : TVR-3Δt ,t : G9t : G7 Traditional Memo Beanstalk Memo (a) An example memo of subquery sales status
G3 G5Scan(sales@t )[] Scan(sales@(t t ])[]G4 G6Scan(returns@t )[] Scan(returns@(t t ])[] TVR-1 t : G4Q N : N/AQ P : TVR-1Δt ,t : G6t : G1TVR-2t : G2LeftOuterJoin[0, 1]G2Scan(returns@t )[]G1Scan(sales@t )[]G0 TVR-1t : G1 Q N : N/AQ P : TVR-1 InnerJoin[0,1]G7 TVR-2t : G2 Q P : TVR-3 TVR-3t : G7 Q P : TVR-3 Q N : N/ATVR-0 t : G3Q N : N/AQ P : TVR-0Δt ,t : G5t : G0InnerJoin[3, 4]G8 G9 TVR-3 t : G8Δt ,t : G9t : G7 Q N : N/AQ P : TVR-3TVR-0t : G0 Q N : N/AQ P : TVR-0 Initial Step 3Step 2
DeltaInnerJoin[3,4,5,6]
Step 1 (b) A step-wise illustration of the growth of the memo
𝐿 𝑅 ⋈ 𝐿 ′ 𝑅 ′ Δ ⋈ 𝑡 Δ( 𝑡 , ) 𝑡 ′ Rule 1 𝑡 𝑡 operator operandTVR operandoperator edgeintra-TVR edgeinter-TVR edge=G8=G3 =G4=TVR-0 =G5 =G6=TVR-1=TVR-3 =G9 = 𝑡 = Δ( , ) 𝑡 𝑡 = 𝑡 = 𝑡 Δ( 𝑡 , ) 𝑡 ′ = Δ( , ) 𝑡 𝑡 Δ( 𝑡 , ) 𝑡 ′ = Δ( , ) 𝑡 𝑡 (c) A TVR-generating rule pattern Rule 2
𝐿 𝑅 ⋈ 𝑙𝑜 𝐿 ′ 𝑅 ′ ⋈ 𝑄 𝑃 ′ ′ 𝑡𝑡 𝑡 ′ 𝑄 𝑃 =G2 =G8=TVR-2 =TVR-3=G0 =G1=TVR-0 =TVR-0 =G3 =G4 𝑄 𝑃 ′ 𝑡 =TVR-1 =TVR-1 𝑡 ′ 𝑡 ′ = 𝑡 = 𝑡 = 𝑡 = 𝑡 = 𝑡 = 𝑡 (d) An inter-TVR rule pattern Figure 4: Examples of the memo and TVR rewrite-rule patterns in
Tempura . timizer developers to define TVR rewrite rules by specify-ing a graph pattern on both relational operators and TVRnodes in the memo. A TVR rewrite rule pattern consistsof two types of nodes and three types of edges: (1) operatoroperands that match relational operators; (2) TVR operands that match TVR nodes; (3) operator edges between operatoroperands that specify traditional parent-child relationship ofoperators; (4) intra-TVR edges between operator operandsand TVR operands that specify intra-TVR relationships;and (5) inter-TVR edges between TVR operands that spec-ify inter-TVR relationships. All nodes and intra/inter-TVRedges can have predicates. Once fired, TVR rewrite rulescan register new TVR nodes and intra/inter-TVR relation-ships.Fig. 4(c)-4(d) depict two TVR rewrite rules, where solidnodes and edges specify the patterns to match, and dottedones are newly registered by the rules. In the figures, wealso show an example match of these rules when applied onthe memo in Fig. 4(a): • Rule 1 is the TVR-generating rule for computing thedelta of an inner join. It matches a snapshot of an
Inner-Join , whose children L ( R ) have a delta sibling L (cid:48) ( R (cid:48) )respectively. The rule will generate a DeltaInnerJoin tak-ing L , R , L (cid:48) , and R (cid:48) as inputs, and register it as a deltasibling of the original InnerJoin . • Rule 2 is an inter-TVR rule of
IM-2 . The rule matchesa snapshot of a
LeftOuterJoin , whose children L , R eachhave a Q P snapshot sibling L (cid:48) , R (cid:48) . The rule will gener-ate an InnerJoin of L (cid:48) and R (cid:48) , and register it as the Q P snapshot sibling of the original LeftOuterJoin .Fig. 4(b) demonstrates the growth of a memo in
Tempura .For each step, we only draw the updated part due to spacelimitation. The memo starts with G0 to G2 and their cor-responding TVR-0 to TVR-2. In step 1, we first populatethe snapshots and deltas of the scan operators, e.g., G3 toG6, and register the intra-TVR relationship in TVR-0 andTVR-1. We also populate their Q P and Q N inter-TVR rela-tionships as in IM-2 (for base tables these relationships aretrivial). In step 2, rule 2 fires on the tree rooted at
Left- OuterJoin[0,1] in G2 as in Fig. 4(d). In step 3, rule 1 fireson the tree rooted at
InnerJoin[0,1] in G7 as in Fig. 4(c).Similarly by applying other TVR rewrite rules, we can even-tually populate the memo in Fig. 4(a).
Next we explain the implementation details of
Tempura ,based on the terminology of Apache Calcite 1.17.0 [3].Apache Calcite uses
RelSet and
RelSubset to representthe logical and physical equivalence classes, respectively,and
Trait to represent the physical properties of a phys-ical equivalence class. On top of that,
Tempura introduces
TvrMetaSet to represent the TVRs, as well as
IntraTvrTrait and
InterTvrTrait to represent the intra-TVR and inter-TVR relationship respectively. Each intra-TVR/inter-TVRrelationship is recorded in the involved TVRs and opera-tors. E.g., an intra-TVR relationship is modeled as a triple (cid:104)
TvrMetaSet , IntraTvrTrait , RelSet (cid:105) and stored in the cor-responding
TvrMetaSet and
RelSet . We allow users to de-fine their own
IntraTvrTrait ’s and
InterTvrTrait ’s, andalso implement several commonly-used ones as in §
3. Forinstance, the attribute-perspective
IntraTvrTrait for thegroup-by aggregate operator consists of the group-by keys(the primary keys of the aggregate results), and the mergeoperator + γ for each aggregate column γ . The InterTvrTrait for the
IM-2 approach comprises of an indicator whether itis the Q P or Q N part.To facilitate fast rule triggering, Tempura indexes the rulepatterns by their containing operator operands and intra/inter-TVR edges. Similar to Calcite,
Tempura monitors new struc-tural changes in the memo. Whenever new operators orintra/inter-TVR relationships are registered in the memo,
Tempura only fires the rule patterns that contain operatoroperands or intra/inter-TVR edges that match the changes.Note that we do not index the TVR operands and the op-erator edges, as they do not have predicates to facilitatefiltering.Initially, the rule engine starts with registering the origi-nal logical plan, and associates each
RelSet to a
TvrMetaSet with a default
IntraTvrTrait . When a traditional rule is8red on a set of operators, if the
RelSet of every matchedoperator is already connected to a
TvrMetaSet via the de-fault
IntraTvrTrait , then besides registering the new op-erators generated by the rule,
Tempura also creates a new
TvrMetaSet for each new operator and connects them withthe default
IntraTvrTrait . In general, all structural changesin the memo will cause rules to match and fire, and furthergenerate new nodes and edges.
Tempura does not distinguishTVR rules from traditional rules in terms of rule firing. Allrule matches are stored in the same queue, and the firingorder is determined by the customizable scoring function.We used the default Calcite scoring function, which takesinto consideration the rule importance and the location ofthe matched relation operators in the memo. We adjustedthe scoring function for TVR rules by giving them a boost-ing factor, because TVR rules are transformations on logicalplans and we want them to be fired with higher priorities.Similar to Calcite,
Tempura deduplicates the TVRs besidesthe operators when registering them in the memo. TwoTVRs are considered equivalent if they are both connectedto a
RelSet with the same default
IntraTvrTrait . In this section, we discuss optimizations to speed up theexploration process, which is needed since IQP explores amuch bigger plan space than traditional query planning.
Translational symmetry of TVR’s.
The structures inthe
Tempura memo usually have translation symmetry alongthe timeline, because the same rule generates similar pat-terns when applied on snapshots or deltas of the same setof TVR’s. For instance, in Fig. 4(d), if we let t (cid:48) = t in-stead, L (cid:48) ( R (cid:48) ) will match G0 (G1) instead of G3 (G4), andwe will generate the InnerJoin in G7 instead of G8. In otherwords,
InnerJoin [0,1] in G7 and
InnerJoin [3,4] are transla-tion symmetric, modulo the fact that G0, G1, and G7 (G3,G4, and G8) are all snapshot t ( t ) of the correspondingTVR’s respectively.By leveraging this symmetry, instead of repeatedly firingTVR rewrite rules on snapshots/deltas of the same set ofTVR’s, we can apply the rules on just one snapshot/delta,and copy the structures to other snapshots/deltas. Thishelps eliminate the expensive repetitive matching process ofthe same rule patterns on the memo. The improved processis as follows:1. We seed the TVR’s of the leaf operators (usually Scan )with only one snapshot plus a consecutive delta, and fireall the rewrite rules to populate the memo.2. We seed the TVR’s leaf operators with all snapshots anddeltas, and copy the memo from step 1 by substitutingits leaf operators with their snapshot/delta siblings in thecorresponding TVR’s.3. We continue optimizing the copied memo, as we can fur-ther apply time-specific optimization, e.g., pruning emptyrelations if a delta at a specific time is empty.
Pruning non-promising alternatives.
There are mul-tiple ways to compute a TVR’s snapshot or delta, withinwhich certain ways are usually more costly than others. Wecan prune the non-promising alternatives. For instance, tocompute a delta, one can take the difference of two snap-shots, or use TVR-generating rules to directly compute fromdeltas of the inputs. Based on the experience of previous re-search on incremental computation [31], we know that theplans generated by TVR-generating rules are usually more ...... (a) ...... P P (b) Figure 5: Examples of (a) the temporal plan space,and (b) an temporal assignment of the physical planfor subquery sales status . efficient. Therefore, for operators that are known to be eas-ily incrementally maintained, such as filter and project, weassign a lower importance to intra-TVR rules for generat-ing deltas to defer their firing. Once we find a delta thatcan be generated through TVR-generating rules, we skipthe corresponding intra-TVR rules altogether. To imple-ment this optimization, we can give this subset of intra-TVR rules a lower priority than all other rules, and thusother TVR rewrite rules and traditional rewrite rules willalways be ranked higher. Each intra-TVR rule also has anextra skipping condition, which is tested to see whether thetarget delta is already generated before firing the rule. If so,the rule is skipped. Guided exploration.
Inside a TVR, snapshots and deltasconsecutive in time can be merged together, leading to com-binatorial explosion of rule applications. However, the mergeorder of these snapshots and deltas usually do not affectthe cost of the final plan. Thus, we limit the explorationto a left-deep merge order. Specifically, we disable merg-ing of consecutive deltas, but instead only let rules matchpatterns that merge a snapshot with its immediately con-secutive delta. In this way, we always use a left-deep mergeorder.
6. SELECTING AN OPTIMAL PLAN
In this section we discuss how
Tempura selects an optimalincremental plan in the explored space. The problem hastwo distinctions from existing query optimization: (1) cost-ing the plan space and searching through the space needto consider the temporal execution of a plan; and (2) theoptimal plan needs to decide which states to materialize tomaximize the sharing opportunities between different timepoints within a query.
Costing the plan alternatives properly is crucial for cor-rect optimization. However, as the temporal dimension is9nvolved in query planning, costing is not trivial. Fig. 5(a)depicts one physical plan alternative derived from the planrooted at (
S (cid:46)(cid:47) lo R ) t shown in red in Fig. 3(d). This planonly specifies the concrete physical operations taken on thedata, but does not specify when these physical operationsare executed. Actually, each operator in the plan usuallyhas multiple choices of execution time. In Fig. 5(a), the timepoints annotated alongside each operator shows the possibletemporal domain in which each operator can be executed.For instance, snapshots S t and R t are available at t , andthus can execute at any time after that, i.e., t or t . Deltas∆ R t t and ∆ S t t are not available until t , and thus any op-erators taking it as input, including the IncrHashInnerJoin ,can only be executed at t . The temporal domain of eachoperator O , denoted t-dom( O ), can be defined inductively: • For a base relation R , t-dom( R ) is the set of executiontimes that are no earlier than the time point when R isavailable. • For an operator O with inputs I , . . . , I k , t-dom( R ) is theintersection of its inputs’ temporal domains: t-dom( R ) = ∩ ≤ j ≤ k t-dom( I j ).To fully describe a physical plan, one has to assign eachoperator in the plan an execution time from the correspond-ing temporal domain. We denote a specific execution timeof an operator O as τ ( O ). We have the following definitionof a valid temporal assignment. Definition 5 (Valid Temporal Assignment).
An as-signment of execution times to a physical plan is valid if andonly if for each operator O , its execution time τ ( O ) satisfies τ ( O ) ∈ t-dom ( O ) and τ ( O ) ≥ τ ( O (cid:48) ) for all operators O (cid:48) inthe subtree rooted at O . Fig. 5(b) demonstrates a valid temporal assignment of thephysical plan in Fig. 5(a). As S t and R t are already avail-able at t , the plan chooses to compute HashInnerJoin of S t and R t at t , as well as shuffling S t and R t in order toprepare for IncrHashInnerJoin . At t , the plan shuffles thenew deltas ∆ S t t and ∆ R t t , finishes IncrHashInnerJoin , andunions the results with that of
HashInnerJoin computed at t . Note that if an operator O and its input I have differ-ent execution times, then the output of I needs to be savedfirst at τ ( I ), and later loaded and fed into O at τ ( O ), e.g., Union at t and HashInnerJoin at t . The cost of Save and
Load needs to be properly included in the plan cost. It isworth noting that some operators save and load the outputas a by-product, for which we can spare
Save and
Load , e.g.,
Exchange of S t , R t at t for IncrHashInnerJoin . The cost of an incremental plan is defined under a specificassignment of execution times. Therefore, the optimizationproblem of searching for the optimal incremental plan isformulated as: given a plan space, find a physical plan andtemporal assignment that achieve the lowest cost. In thissection, we discuss the cost model and optimization algo-rithm for this problem without considering sharing commonsub-plans. We will discuss the problem of how to decide theoptimal sharable sub-plans to materialize in § c in an IQP problem (as in § c . We denotetraditional cost functions as c , and c i is the cost at time t i . As before, c can be a number, e.g., estimated monetizedresource cost, or a structure, e.g., a vector of CPU time andI/O.1. ˜ c w ( O ) = (cid:80) i =1 ..T w i · c i ( O ). That is, the extended costof an operator is a weighted sum of its cost at each time t i . For the example setting in § w = 0 . t and w = 1 for t .2. ˜ c v ( O ) = [ c ( O ) , . . . , c T ( O )]. That is, the extended costis a vector combining costs at different times. ˜ c v can becompared entry-wise in a reverse lexical order. Formally,˜ c v ( O ) > ˜ c v ( O ) iff ∃ j s.t. c j ( O ) > c j ( O ) and c i ( O ) = c i ( O ) for all i, j < i ≤ T .Consider the plan in Fig. 5(a) as an example. To get theresult of HashInnerJoin at t , we have two options: (i) com-pute the join at t ; or (ii) as in Fig. 5(b), compute the joinat t , save the result, and load it back at t . Assume thecost of computing HashInnerJoin , saving the result, andloading it are 10, 5, 4, respectively. Then for option (i)( c , c ) = (0 , c , c ) = (15 , c w as the cost function. If w = 0 . w = 1 thenoption (i) is better, whereas if w = 0 . w = 1, option(ii) becomes better. Dynamic programming used predominantly in exist-ing query optimizers [42, 35, 25] also need to be adapted tohandle the cost model extensions. In these existing queryoptimizers, the state space of the dynamic programming isthe set of all operators in the plan space, represented as { O } . Each operator O records the best cost of all the sub-trees rooted at O . We extend the state space by consideringall combinations of operators and their execution times, i.e., { O } × t-dom( { O } ). Also instead of recording a single opti-mum, each operator O records multiple optimums, one foreach execution time τ ( O ), which represents the best cost ofall the subtrees rooted at O if O is generated at τ . Dur-ing optimization, the state-transition function is as Eq. 6.That is, the best cost of O if executed at τ is the best costof all possible plans of computing O with all possible validtemporal assignments compatible with τ .˜ c [ O, τ ] = min ∀ valid τ j (cid:0)(cid:88) j ˜ c [ I j , τ j ] + c τ ( O ) (cid:1) . (6)In general, we can apply dynamic programming to the opti-mization problem for any cost function satisfying the prop-erty of optimal substructure. We have the following correct-ness result of the above dynamic programming algorithm. Theorem The optimization problem under cost func-tions ˜ c w and ˜ c v without sharing common sub-plans satisfiesthe property of optimal substructure, and dynamic program-ming is applicable. The problem of deciding the states to materialize can bemodeled as finding the sharing opportunities in the planspace. In other words, a shared sub-plan between P i and P j in an incremental plan is essentially an intermediate statethat can be saved by P i and reused by P j . For example,in Fig. 5(a), since both HashInnerJoin and
IncrHashInner-Join require shuffling S t and R t , the two relations can be10huffled only once and reused for both joins. The parts 1 (cid:13) and 2 (cid:13) circled in dashed lines depict the sharable sub-plans.Finding the optimal common sub-plans to share is a multi-query optimization (MQO) problem, which has been exten-sively studied [40, 54, 30]. In this paper, we extend theMQO algorithm in [30], which proposes a greedy frameworkon top of Cascade-style optimizers for MQO. For the sakeof completeness, we list the algorithm in Algo. 1, by high-lighting the extensions for progressive planning. The al-gorithm runs in an iterative fashion. In each iteration, itpicks one more candidate from all possible shareable can-didates, which if materialized can minimize the plan cost(line 4), where bestP lan ( S ) means the best plan with S materialized and shared. The algorithm terminates whenall candidates are considered or adding candidates can nolonger improve the plan cost. As IQP needs to considerthe temporal dimension, the shareable candidates are nolonger solely the set of shareable sub-plans, but pairs of ashareable sub-plan s and a choice of its execution time τ ( s ).Pair (cid:104) s, τ ( s ) (cid:105) means computing and materializing the sub-plan s at time τ ( s ), which can only benefit the computa-tion that happens after τ ( s ). For instance, considering thephysical plan space in Fig. 5(a), the sharable candidates are {(cid:104) (cid:13) , t (cid:105) , (cid:104) (cid:13) , t (cid:105) , (cid:104) (cid:13) , t (cid:105) , (cid:104) (cid:13) , t (cid:105)} . The optimizations in [30]are still applicable to Algo. 1. Algorithm 1
Greedy Algorithm for MQO1: S = ∅ C = shareable candidate set consiting of all share-able nodes and their potential execution times {(cid:104) s, τ ( s ) (cid:105)} while C (cid:54) = ∅ do
4: Pick (cid:104) s, τ ( s ) (cid:105) ∈ C that minimizes ˜ c ( bestP lan ( S (cid:48) ))where S (cid:48) = {(cid:104) s, τ ( s ) (cid:105)} ∪ S if ˜ c ( bestP lan ( S (cid:48) )) < ˜ c ( bestP lan ( S (cid:48) )) then C = C − {(cid:104) s, τ ( s ) (cid:105)} S = S (cid:48) else C = ∅ return S As expanded with execution time options, the enumer-ation space of the shareable candidate set becomes muchlarger than the original algorithm in [30]. Interestingly, wefind that under certain cost models we can reduce the enu-meration space down to a size comparable to the originalalgorithm, formally summarized in Theorem 7. This theo-rem relies on the fact that materializing a shareable sub-planat its earliest possible time subsumes other materializationchoices. Due to space limit, we omit the proof.
Theorem For a cost function ˜ c w satisfying w i < w j if i < j , or a cost function ˜ c v satisfying the property thatan entry i has a lower priority than an entry j if i < j inthe lexical order, we only need to consider the earliest validexecution time for each shareable sub-plan. That is, for eachshareable sub-plan s , we only need to consider the shareablecandidate (cid:104) s, min ( t-dom ( s )) (cid:105) in Algorithm 1.
7. BEANSTALK IN ACTION
In this section, we discuss a few important considerationswhen applying
Tempura in practice.
Dynamic Re-optimization of incremental plans.
Wehave studied the IQP problem assuming a static setting, i.e., in ( (cid:126)T , (cid:126)D, (cid:126)Q, ˜ c ) where (cid:126)T and (cid:126)D are given and fixed. Inmany cases, the setting can be much more dynamic where (cid:126)T and (cid:126)D are subject to change. Fortunately, Tempura can beadapted to a dynamic setting using re-optimization. Gen-erally, an incremental plan P = [ P , · · · , P i − , P i , · · · , P k ]for (cid:126)T = [ t , · · · , t i − , t i , · · · , t k ] is only executed up to t i − ,after which (cid:126)T and (cid:126)D change to (cid:126)T (cid:48) = [ t i (cid:48) , · · · , t k (cid:48) ] and (cid:126)D (cid:48) =[ D i (cid:48) , · · · , D k (cid:48) ]. Tempura can adapt to this change by re-optimizing the plan under (cid:126)T (cid:48) and (cid:126)D (cid:48) . We want to remarkthat during re-optimization,
Tempura can incorporate thematerialized states generated by P , · · · , P i − as material-ized views. In this way Tempura can choose to reuse the ma-terialized states instead of blindly recomputing everything.Take the progressive data warehouse scenario as an ex-ample. Since we may not know the exact schedule and datastatistics in the future, we do not optimize for a large num-ber of time points at once. Instead, one can plan adaptivelyusing re-optimization. Consider a query originally scheduledat t ∗ . Say, initially at t we decide to have one incrementalrun. At this planning stage, we only need to consider a sim-ple schedule [ t , t ∗ ]. In the resulting plan [ P , P ∗ ], only P isexecuted, but co-planing P , P ∗ makes P robust for futureruns. At a future time t i , if we decide to have another run,we can always re-optimize for [ t i , t ∗ ] with accurate statis-tics for t i (as data is already available). We can also takeinto consideration the materialized states from previous runsbefore t i . Note that at each planning, we only optimize asmall IQP problem with a limited number of time points.This way, we avoid planning many time points with uncer-tain schedule and statistics. The above methods are usedin [48]. Data statistics estimation.
Incremental processing sce-narios usually involve planning for logical times or physicaltimes in the future, for which estimating the data statisticsbecomes very challenging. IQP scenarios, including bothplanning for logical times (e.g.,
IVM-PD ) and physical times(e.g.,
PWD-PD ) as described in §
8. EXPERIMENTS
In this section, we report our experimental study on theeffectiveness and efficiency of
Tempura in IQP.
We used the query optimizer of Alibaba Cloud MaxCom-pute [1], which was built on Apache Calcite 1.17.0 [3], asa traditional optimizer baseline. We implemented
Tempura on the optimizer of MaxCompute. We integrated four com-monly used incremental methods into
Tempura by expressingthem as TVR-rewrite rules: (1)
IM-1 : as described in § IM-2 : as described in § § OJV : theouter-join view maintenance algorithm in § HOV :the higher-order view maintenance algorithm in §
10 q35 q40 q78 q800.00.40.81.21.6 R e l a t i v e C o s t IM-1 IM-2 OJV HOV Beanstalk (a) delta-big delta-small delta-R delta-RS0.00.30.60.91.2 R e l a t i v e C o s t IM-1 IM-2 OJV HOV Beanstalk (b) q10 q35 q40 q78 q800.00.40.81.21.6 R e l a t i v e C o s t IM-1 IM-2 OJV HOV Beanstalk (c) d e l t a - b i g - . d e l t a - b i g - . d e l t a - s m a l l - . d e l t a - s m a l l - . d e l t a - R - . d e l t a - R - . d e l t a - R S - . d e l t a - R S - . R e l a t i v e C o s t IM-1 IM-2 OJV HOV Beanstalk (d) (e) (f)
Figure 6: (a)(b) The optimal estimated costs of different incremental plans in
IVM-PD for different queries anddata-arrival patterns. (c)(d) The optimal estimated costs of different incremental plans in
PDW-PD for differentqueries, data-arrival patterns and cost weights. (e)(f ) The PDW-to-TDW ratio of the real total CPU costand CPU cost at : for the data warehouse workloads respectively. default, Tempura jointly considered all four methods to gen-erate an optimal plan. In the experiments, we used
Tempura to simulate each method by turning off the inter-TVR rulesof the other methods.
Incremental Processing Scenarios.
We used two incre-mental processing scenarios to demonstrate
Tempura . Beloware the incremental planning problem definitions for thesetwo scenarios. • Progressive data warehouse.
We use the
PDW-PD defi-nition as in § c w ( O ) (in § c i was a lin-ear combination of the estimated usage of CPU, IO, mem-ory, and network transfer, and the weight w i ∈ [0 . , . w i = 1 for the last run. Note that ithelped us achieve a balance between re-computation andthe size of materialized states by jointly considering CPUand memory in the cost function. We chose w i ≤ . • Incremental view Maintenance.
We use the
IVM-PD definition as defined in § Query Workloads.
We used the TPC-DS benchmark [6](1
T B ) to study the effectiveness ( § § Tempura . To further demonstrate the effectivenessof the incremental plans produced by
Tempura , in § W-A and
W-B . Table 1 shows statisticsof the two workloads.
Table 1: Statistics of two workloads at Alibaba ≥ ≥ W-A
274 1 .
14 167 83
W-B
554 1 .
18 357 144
Running Environment.
In the experiments, query opti-mization was carried out single-threaded on a machine with an Intel Xeon Platinum 8163 CPU @ 2 . We first evaluated the effectiveness of IQP by compar-ing
Tempura with four individual incremental methods
IM-1 , IM-2 , OJV , and
HOV , in both the
PDW-PD and
IVM-PD scenar-ios. We controlled and varied two factors in the experiments:(1) Queries. We chose five representative queries coveringcomplex joins (inner-, left-outer-, and left-semi-joins) andaggregates. (2) Data-arrival patterns. We controlled theamount of input data available in the 1st and 2nd incremen-tal runs ( D , D ) and whether there are retractions in the in-put data. Correspondingly, we chose the following four data-arrival patterns, namely delta-big ( | D | / | D | = 1 : 1), delta-small ( | D | / | D | = 4 : 1), delta-R ( | D | / | D | = 2 : 1 with re-tractions in the sales tables), and delta-RS ( | D | / | D | = 2 : 1with retractions in both sales and returns tables). As the ac-curacy of cost estimation is orthogonal to Tempura , to isolateits interference, we mainly compared the estimated costs ofplans produced by the optimizer, and reported them in rela-tive scale (dividing them by the corresponding costs of
IM-1 )for easy comparison. We reported the real execution costsas a reference later. Due to space limit, we only report themost significant entries in the cost vector of ˜ c v for IVM-PD . IVM-PD . We first fixed the data-arrival pattern to delta-big and varied the queries. The optimal-plan costs are re-ported in Fig. 6(a). As shown, different queries prefer differ-ent incremental methods. For example,
IM-1 outperformedboth
OJV and
HOV for complex queries such as q35. This isbecause
OJV computed Q I by left-semi joining the delta of Q D with the previous snapshot ( § Q I . Whereas for sim-pler queries such as q80, OJV degenerated to a similar planas
IM-1 , and thus had similar costs. Note that
HOV costmuch less than both
OJV and
IM-1 . This is because
HOV catalog sales innerjoining with warehouse , item and date dim ) and thus avoidedrepeated recomputation of these views as in OJV and
IM-1 . Tempura outperformed the individual incremental methodson all queries. The reason is that
Tempura was able to com-bine the benefits of different incremental methods.Next we chose query q10 as a complex query with mul-tiple left outer joins, and varied the data-arrival patterns.The results are plotted in Fig. 6(b). Again, the data-arrivalpatterns affected the preference of incremental methods. Forexample,
IM-2 could not handle input data with retractions.Compared to delta-big,
HOV started to outperform
IM-1 bya large margin in delta-small, as both of them could use dif-ferent join orders when applying updates to different inputrelations, and a smaller delta help significantly reduce thecost of incrementally computing M in HOV and Q D , Q I in OJV .For both experiments,
Tempura consistently delivered thebest plans among all the methods. For example, for q40 inFig. 6(a) and the delta-small case in Fig. 6(b),
Tempura de-livered a plan 5-10X better than others.
Tempura leveragedall three of
HOV , IM-2 and
IM-1 to generate a mixed optimalplan:
Tempura chose different join orders when applying up-dates to different input relations, which was similar to
HOV .It leveraged the fact that joining the smaller delta earlier canquickly reduce the output sizes. Interestingly, when it cameto combining higher-order views M and ∆ R as required by HOV , Tempura used the
IM-2 approach, and applied
IM-1 toincrementally compute the Q N part in IM-2 . PDW-PD . For the
PDW-PD scenario, we conducted the sameexperiments by varying the queries and the data-arrival pat-terns as in
IVM-PD , and in addition tried different weightsused in the cost functions ( w = 0 . w = 0 . IVM-PD . We make two remarks.(1) Since the
PDW-PD setting did not require any outputsat earlier runs,
Tempura automatically avoided unnecessarycomputation, e.g., computing the Q N part in an IM-2 ap-proach, which usually cannot be efficiently incrementallymaintained. This result is also shown in the figures, as the
IM-2 approach was more preferred uniformly in
PDW-PD thanin
IVM-PD . (2) The weights in the cost function can also af-fect the choice of the optimizer. For instance, in Fig. 6(d),q10 preferred
HOV to OJV when w = 0 .
3, but the otherway when w = 0 .
7. This result was because as the cost ofearly execution became higher, it was less preferable to storemany intermediate states as in
HOV . Tempura automaticallyexploited this fact and adjusted the amount of computationin each incremental run. When w increased from 0 . . Tempura moved some early computation from the firstincremental run to the second.
Real CPU Costs . We reported the real CPU costs (in theunit of CPU · minute) in Fig. 7(a)-7(d) for the experimentsin Fig. 6(a)-6(d). In the PDW-PD experiments (Fig. 7(c)and 7(d)), the CPU costs were weighted according to thecost function in
PWD-PD . Note that Fig. 7(a) and 7(c) areplotted in log scale due to the huge differences in CPU costsfor different queries. As we can see, the real CPU costswere agreed with the planner’s estimation (Fig. 6(a)-6(d))pretty well. Some of the real costs were different from theestimated ones because of the inaccuracy of the cost model.But note that
Tempura consistently delivered the best planswith the lowest CPU consumption across all experiments.
State Sizes . In this set of experiments, we study the stor-age costs of materialized states between
Tempura and eachindividual incremental methods. We first fixed the data-arrival pattern to delta-big and tested different queries un-der
IVM-PD settings respectively. The results are reportedin Fig. 7(e). As shown, for most queries, the sizes of statesmaterialized by
Tempura were smaller than or comparable toeach individual incremental algorithms. This is due to thefact that
Tempura is able to reuse the shuffled data as thestates without incurring additional storage overheads (see § Tempura in the figures. Next we chose queryq10 and varied the data-arrival patterns. The results arereported in Fig. 7(f). Again, the storage costs of
Tempura were lower than or comparable to that of each individualincremental algorithms.
Sensitivity to Inaccurate Estimates . Next, we eval-uated the sensitivity of
Tempura to inaccurate cardinalityestimation. To set up the experiment, we used q10 in the
IVM-PD scenario. We gave
Tempura the estimation of delta-small when running q10 with input delta-big, and gave theestimation of delta-big when running q10 with input delta-small. Fig. 7(g) reported the real CPU costs. For delta-big,
Tempura with the inaccurate estimation ran slower comparedto
Tempura with accurate estimation. This is expected be-cause
Tempura chose a plan that is optimal to the inaccuratecost model. Nevertheless,
Tempura was still faster than
IM-1 , OJV , HOV , and comparable to
IM-2 . For delta-small, inaccu-rate estimation had a small impact on execution time, and
Tempura was still faster than each individual incrementalmethod.
Remarks . In conclusion, the optimal incremental plan isaffected by different factors and does need to be searched ina principled cost-based way, and
Tempura can consistentlyfind better plans than each incremental method alone.
To validate the effectiveness of
Tempura in a real appli-cation, we conducted a case study of the
PDW-PD scenariousing two real-world analysis workloads
W-A and
W-B at Al-ibaba. We compared the resource usage of executing theseworkloads in a traditional data warehouse and a progressiveone: (1)
Traditional (TDW), where we ran the analysisworkloads at 24:00 according to a schedule using the plansgenerated by a traditional optimizer; and (2)
Progressive (PDW), where besides 24:00, we also early executed theanalysis workloads at 14:00 and 19:00 with only partial datausing the incremental plans generated by
Tempura . The twoearly-execution time points were chosen to simulate the ob-served cluster usage pattern (the cluster was often under-utilized at these times), for which we set the weights of re-source cost to 0 .
25 and 0 .
3, respectively.Fig. 6(e) shows the real CPU cost of executing the work-loads (scored using the cost function in the
PDW-PD setting),where we plotted the cumulative distribution of the ratiobetween the CPU cost in PDW versus that in TDW. Wecan see that PDW delivered better CPU cost for 80% of thequeries. For about 60% of the queries, PDW was able tocut the CPU cost by more than 35%. Remarkably, PDWdelivered a total cost reduction of 56 .
2% and 55 .
5% for
W-A and
W-B , respectively. Note that
Tempura searched plansbased on the estimated costs which could be different fromthe real execution cost. As a consequence, for some of the13
10 q35 q40 q78 q80110 C P U ( C o r e * M i n ) IM-1 IM-2 OJV HOV Beanstalk (a) delta-big delta-small delta-R delta-RS051015202530 C P U ( C o r e * M i n ) IM-1 IM-2 OJV HOV Beanstalk (b) q10 q35 q40 q78 q80110 C P U ( C o r e * M i n ) IM-1 IM-2 OJV HOV Beanstalk (c) d e l t a - b i g - . d e l t a - b i g - . d e l t a - s m a l l - . d e l t a - s m a l l - . d e l t a - R - . d e l t a - R - . d e l t a - R S - . d e l t a - R S - . C P U ( C o r e * M i n ) IM-1 IM-2 OJV HOV Beanstalk (d) q10 q35 q40 q78 q8010 S t a t e S i z e ( M B ) IM-1IM-2 OJVHOV BeanstalkReused Shuffle Data in Beanstalk (e) delta-big delta-small delta-R delta-RS110 S t a t e S i z e ( M B ) IM-1IM-2 OJVHOV BeanstalkReused Shuffle Data in Beanstalk (f) delta-big delta-small05101520 C P U C o s t ( C o r e * M i n ) IM-1IM-2 OJVHOV Beanstalk (accurate estimates)Beanstalk (inaccurate estimates) (g)
W-A W-B0250005000075000100000125000150000175000 C P U C o s t ( C o r e * M i n ) CPU cost of TDWCPU cost of PDW at 14:00 (absolute value)CPU cost of PDW at 19:00 (absolute value)CPU cost of PDW at 24:00 (absolute value)total CPU cost of PDW (weighted) (h)
Query110 C p u C o s t ( C o r e * M i n ) W-A (TDW)W-A (PDW)W-B (TDW)W-B (PDW) (i)
Figure 7: (a)(b) The optimal real CPU costs of different incremental plans in
IVM-PD for different queries anddata-arrival patterns. (c)(d) The optimal real CPU costs of different incremental plans in
PDW-PD for differentqueries, data-arrival patterns and cost weights. (e)(f ) The state sizes of different incremental plans in
IVM-PD for different queries and data-arrival patterns. (g) The plan quality of
Tempura under inaccurate cardinalityestimation. (h) The comparison between TDW and PDW on the CPU cost breakdowns of all queries in
W-A and
W-B , and (i) a detailed comparison of randomly sampled queries in W-A and
W-B . queries (less than 10%) we see more than 50% cost increase.Accuracy of cost estimation is not within the scope of thepaper. We further reported the PDW-to-TDW ratio of theCPU cost at 24:00 in Fig. 6(f), as this ratio indicated theresource reduction during the “rush hours.” As shown, forboth workloads, PDW reduced the resource usage at peakhours for over 85% of the queries, and for over 70% of thequeries we can see significant reduction of more than 25%.We also reported the absolute values of CPU costs of W-A and
W-B . However, as
W-A and
W-B have 274 and 554 querieseach, it is not realistic to show all of them. Instead we re-ported the total CPU cost breakdowns for TDW and PDWin Fig. 7(h). Specifically for PDW, we reported the absolutevalues of CPU costs at each time, and the total CPU costsweighted according to the cost function in
PDW-PD . As we cansee,
Tempura indeed picked better plans with less resourceconsumption: PDW saved 38 .
7% and 32 .
6% CPU costs com-pared to TDW for
W-A and
W-B respectively. On the otherhand, with incremental computation, PDW brought rela-tively low overheads compared to TDW, 19 .
6% and 37 . W-A and
W-B respectively. The PDW overheads are com-puted by summing up the absolute values of CPU costs ateach time, minus the CPU costs of TDW. We further ran-domly selected 15 queries from
W-A and
W-B respectively, andreported their CPU costs in TDW and PDW in Fig. 7(i).Again, for most queries PDW reduced the CPU costs by a significant amount.
Next, we evaluated the time performance of
Tempura inIQP. Compared to traditional query planning, IQP has twosalient characteristics: (1) In plan-space exploration, IQPexplores a larger plan space. (2) Besides, IQP needs to de-cide the intermediate states to share, which are not consid-ered by traditional query planning. We will present perfor-mance results on these two phases:
Plan-Space Exploration (PSE) and
State Materialization Optimization (SMO).We used PDW-PD as the IQP problem definition. Un-less otherwise specified, in the problem definition we set | (cid:126)T | = 3. To help readers better understand how Tempura performs on different types of queries, we use the TPC-DSqueries, and present the optimization time of
Tempura onthem. Besides the overall performance study, we also presenta detailed study on four aspects of
Tempura ’s optimizationperformance:
Table 2: Statistics of selected representative queries
Query Q22 Q20 Q43 Q67 Q27 Q99 Q85 Q91 Q5 Q33
Query complexity : How does
Tempura perform whenqueries become increasingly complex, e.g., with more joinsor subqueries?2.
Size of IQP : How does
Tempura perform when the num-ber of incremental runs (i.e., | (cid:126)T | ) in the IQP problemdefinition changes?3. Number of incremental methods : How does
Tempura perform when users integrate more incremental methodsinto it?4.
Optimization breakdown : How effective are the speed-up optimizations discussed in § Overall Planning Performance . We first studied theoverall query planning performance by comparing IQP withtraditional planning. Fig. 8(a) shows the end-to-end plan-ning time on all TPC-DS queries. As shown, although IQPplanned a much bigger plan space than traditional planning,
Tempura still delivered high planning performance: IQP fin-ished within 3 seconds for 80% queries, and for all queriesfinished within 14 seconds. For over 80% queries, the IQPoptimization time was less than 24X of the traditional plan-ning time. Even though slower than traditional planningat optimization time on a single machine, IQP generatedmuch better incremental plans that brought significant ben-efit in resource usage and query latency on a cluster. We canfurther reduce the planning time by adopting a parallel op-timizer [43]. As a reference, we also reported the real CPUcost used by TDW, the CPU costs saved by PDW comparedto TDW, and the planning time in Fig. 9. We can see thatfor most queries, the CPU time on planning was 2-3 ordersof magnitude smaller than the saved CPU costs. This showsthat the planning cost is negligible compared to the execu-tion cost. Thus the benefit of a better plan outweighs theextra time spent on planning.
Query Complexity.
To study the impact of query com-plexity on performance, we tested on the selected TPC-DSqueriesin Table 2, and reported the broken-down optimiza-tion times in Fig. 8(b). As one can see, the planning timeincreased slowly when the query complexity increased, be-cause the plan space grew larger for complex queries. Thetime spent on PSE was less than that spent on SMO in gen-eral, and also grew with a slower pace. This result showsthat query complexity has a smaller impact on PSE.
Size of IQP . To study the impact of the size of the plan-ning problem on the planning time, we gradually increasedthe number of incremental runs planned from 3 to 9, andreported the time on PSE and SMO in Fig. 8(c) and 8(d).As depicted, the time on PSE stayed almost constant as thesize of IQP changed. E.g., when the number of incrementalruns grew 3X, the time for q33 only slightly increased by20%. This was mainly due to the effective speed-up opti-mization techniques introduced in § Number of Incremental Methods . Next, we evaluatedhow the performance scales when more incremental methodsare added into the optimizer by gradually adding methods
IM-1 , IM-2 , HOV and
OJV into
Tempura . Fig. 8(f) and 8(g)show the time on PSE and SMO, respectively. As illus- trated, the time on both PSE and SMO increased when moreincremental methods were added, because more incrementalmethods increased the plan space. There are two interestingfindings. (1) The PSE time did not grow linearly with thenumber of incremental methods, but rather the size of theplan space that each method newly introduces. For exam-ple, the difference of PSE time introduced by adding
HOV was bigger than that introduced by adding
OJV . This wasbecause
HOV and
OJV use similar methods that update a sin-gle relation at a time, which are very different from
IM-1 and
IM-2 that update all relations each time. (2) The number ofincremental methods had less impact on the planning timethan the size of the IQP problem, which can be observedon the SMO time. This is mainly because the plan spaceexplored by different incremental methods often have over-laps, e.g., most incremental methods fundamentally sharesimilar delta update rules as
IM-1 , whereas the plan spacesof different incremental runs do not have overlaps.
Optimization Breakdown . In the end, we evaluated theeffectiveness of the speed-up optimizations by breaking downthe optimization techniques discussed in § Tempura ). As shown, the optimizationstogether brought an order of magnitude performance im-provements. The most effective optimizations were PNAand TS. PNA generally improved the PSE time by 5-12X,while TS improved the PSE time by 1 . .
9. RELATED WORK
Incremental Processing.
There is a rich body of researchon various forms of incremental processing, ranging from in-cremental view maintenance, stream computing, to approx-imate query answering and so on. Incremental view mainte-nance has been intensively studied before. It has been con-sidered under both the set [16, 17] and bag [21, 27] seman-tics, for queries with outer joins [26, 33], and using higher-order maintenance methods [9]. Previous studies mainlyfocused on delta propagation rules for relational operators.Stream computing [7, 22, 37, 46] adopts incremental pro-cessing and sublinear-space algorithms to process updatesand deltas. Many approximate query answering studies [8,12, 20] focused on constructing optimal samples to improvequery accuracy. Proactive or trigger-based incremental com-putation techniques [52, 19] were used to achieve low querylatency. Zeng et al. [52] proposed a probability-based prun-ing technique for incrementally computing complex queriesincluding those with nested queries. These studies proposedincremental computation techniques in isolation, and do nothave a general cost-based optimization framework, whichis the focus of this paper. In addition, they can be inte-grated into
Tempura , and contribute to a unified plan spacefor searching the optimal incremental plan.
Query Planning for Incremental Processing.
Previ-ous work studied some optimization problems in incrementalcomputation. Viglas et al. [47] proposed a rate-based costmodel for stream processing. The cost model is orthogonalto
Tempura and can be integrated. DBToaster [9] discusseda cost-based approach to deciding the views to materialize15 T i m e ( s ) Traditional Planning State Materialization Optimization (Incremental Query Planning) Plan-Space Exploration (Incremental Query Planning) (a) q22 q20 q43 q67 q27 q99 q85 q91 q5 q33Query02468 T i m e ( s ) Time of State Materialization OptimizationTime of Plan-Space Exploration (b) q22 q20 q43 q67 q27 q99 q85 q91 q5 q33Query0.00.51.01.52.02.53.03.5 T i m e o f P l a n Sp a c e E x p l o r a t i o n ( s ) (c) q22 q20 q43 q67 q27 q99 q85 q91 q5 q33Query10 T i m e o f S t a t e M a t e r i a li z a t i o n O p t i m i z a t i o n ( s ) (d) q22 q20 q43 q67 q27 q99 q85 q91 q5 q33Query0.00.51.01.52.02.53.0 T i m e o f P l a n Sp a c e E x p l o r a t i o n ( s ) IM-1 + IM-2 + HOV + OJVIM-1 + IM-2 + HOVIM-1 + IM-2IM-1 (e) q22 q20 q43 q67 q27 q99 q85 q91 q5 q33Query10 T i m e o f S t a t e M a t e r i a li z a t i o n O p t i m i z a t i o n ( s ) IM-1 + IM-2 + HOV + OJVIM-1 + IM-2 + HOVIM-1 + IM-2IM-1 (f) q22 q20 q43 q67 q27 q99 q85 q91 q5 q33Query0153045607590105120135150 T i m e ( s ) BaselineBaseline + TSBaseline + PNABaseline + GEBeanstalk (g)
Figure 8: (a) Overall planning performance comparison on the TPC-DS benchmark between traditionaland incremental query planning. (b) Impact of the query complexity on the planning performance. (c) (d)Impact of the planning problem size on the planning performance. (e)(f ) Impact of the number of incrementalmethods on the planning performance. (g) Effectiveness of the speed-up optimization techniques. Note thatthe selected queries are ordered by their query complexity(as listed in Table 2). q1 q10 q20 q30 q40 q50 q60 q70 q80 q90 q99Query10 C P U C o s t ( C o r e * S e c ) TDW TDW - PDW Incremental Query Planning
Figure 9: Real resource consumption of
Tempura ’s plan as in Fig. 8(a) on 1T TPC-DS benchmark. under a higher-order view maintenance algorithm. Tang etal. [44] focused on selecting optimal states to materialize forscenarios with intermittent data arrival. They proposed adynamic programming algorithm for selecting intermediatestates to materialize given a fixed physical incremental planand a memory budget, by considering future data-arrivalpatterns. These optimization techniques all focus on theoptimal materialization problem for a specific incrementalplan or incremental method, and thus are not general IQP solutions.Flink [4] uses Calcite [15] as the optimizer and supportstream queries, which only provides traditional optimiza-tions on the logical plan generated by a fixed incrementalmethod, but cannot explore the plan space of multiple in-cremental methods, nor consider correlations between incre-mental runs. On the contrary,
Tempura provides a generalframework for users to integrate various incremental meth-ods, and searches the plan space in a cost-based approach.16 emantic Models for Incremental Processing.
CQL[11]exploited the relational model to provide strong query se-mantics for stream processing. Sax et al. [41] introduced theDual Streaming Model to reason about ordering in streamprocessing. The key idea behind [11, 41] is the duality of re-lations and streams, i.e., time-varying relations can be mod-eled as a sequence of static relations, or a sequence of changelogs consisting of INSERT and DELETE operations. Therecent work [14] proposed to integrate streaming into theSQL standard, and briefly mentioned that TVR’s can serveas a unified basis of both relations and streams. However,their models do not include a formal algebra and rewriterules on TVR’s, and thus cannot fully model incrementalcomputation. To the best of our knowledge, our TIP modelfor the first time formally defines an algebra on TVR’s, espe-cially it provides a principled way to model different types ofsnapshot/deltas in multiplicity/attribute perspectives and+ / − operators between them. Furthermore, the TIP modelprovides a trichotomy of all TVR rewrite rules and showsthat the three types of rewrite rules can subsume many ex-isting incremental algorithms, which provides a theoreticalfoundation for Tempura , so that
Tempura can implement allincremental algorithms that can be described using the threetypes of TVR rewrite rules.
10. CONCLUSION
In this paper, we developed a novel, principled cost-basedoptimizer framework, called
Tempura , for optimizing incre-mental data processing. We first proposed a theory calledTIP model as its foundation, which can formally model in-cremental processing in its most general form. We gave afull specification of
Tempura , which can not only unify vari-ous existing techniques to generate an optimal incrementalplan, but also allow the developer to add their rewrite rules.We studied how to explore the plan space and search for anoptimal incremental plan. We conducted thorough experi-mental evaluation of
Tempura in various incremental-queryscenarios to show its effectiveness and efficiency.
11. REFERENCES [1] Alibaba Cloud MaxCompute. .[2] Amazon spot instance pricing history. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances-history.html .[3] Apache Calcite. https://calcite.apache.org .[4] Apache Flink. https://flink.apache.org .[5] Introducing Stream-Stream Joins in Apache Spark2.3. https://databricks.com/blog/2018/03/13/introducing-stream-stream-joins-in-apache-spark-2-3.html .[6] The TPC-DS Benchmark. .[7] D. J. Abadi, Y. Ahmad, M. Balazinska,U. Cetintemel, M. Cherniack, J.-H. Hwang,W. Lindner, A. Maskey, A. Rasin, E. Ryvkina, et al.The design of the borealis stream processing engine.In
Cidr , volume 5, pages 277–289, 2005.[8] S. Acharya, P. B. Gibbons, V. Poosala, andS. Ramaswamy. The aqua approximate queryanswering system. In
ACM Sigmod Record , volume 28,pages 574–576. ACM, 1999. [9] Y. Ahmad, O. Kennedy, C. Koch, and M. Nikolic.Dbtoaster: Higher-order delta processing for dynamic,frequently fresh views.
PVLDB , 5(10):968–979, 2012.[10] A. Aiken, J. M. Hellerstein, and J. Widom. Staticanalysis techniques for predicting the behavior ofactive database rules.
ACM Transactions on DatabaseSystems (TODS) , 20(1):3–41, 1995.[11] A. Arasu, S. Babu, and J. Widom. The cql continuousquery language: semantic foundations and queryexecution.
The VLDB Journal , 15(2):121–142, 2006.[12] B. Babcock, S. Chaudhuri, and G. Das. Dynamicsample selection for approximate query processing. In
Proceedings of the 2003 ACM SIGMOD internationalconference on Management of data , pages 539–550.ACM, 2003.[13] S. Babu, P. Bizarro, and D. DeWitt. Proactivere-optimization. In
Proceedings of the 2005 ACMSIGMOD international conference on Management ofdata , pages 107–118, 2005.[14] E. Begoli, T. Akidau, F. Hueske, J. Hyde, K. Knight,and K. Knowles. One SQL to rule them all.
CoRR ,abs/1905.12133, 2019.[15] E. Begoli, J. Camacho-Rodr´ıguez, J. Hyde, M. J.Mior, and D. Lemire. Apache calcite: A foundationalframework for optimized query processing overheterogeneous data sources. In
Proceedings of the 2018International Conference on Management of Data ,SIGMOD ’18, pages 221–230, New York, NY, USA,2018. ACM.[16] J. A. Blakeley, P.-A. Larson, and F. W. Tompa.Efficiently updating materialized views. In
Proceedingsof the 1986 ACM SIGMOD International Conferenceon Management of Data , SIGMOD ’86, pages 61–71,New York, NY, USA, 1986. ACM.[17] O. P. Buneman and E. K. Clemons. Efficientlymonitoring relational databases.
ACM Trans.Database Syst. , 4(3):368–382, Sept. 1979.[18] B. Chandramouli, C. N. Bond, S. Babu, and J. Yang.Query suspend and resume. In
Proceedings of the 2007ACM SIGMOD international conference onManagement of data , pages 557–568, 2007.[19] B. Chandramouli, J. Goldstein, and A. Quamar.Scalable progressive analytics on big data in the cloud.
Proc. VLDB Endow. , 6(14):17261737, Sept. 2013.[20] S. Chaudhuri, G. Das, and V. Narasayya. Optimizedstratified sampling for approximate query processing.
ACM Transactions on Database Systems (TODS) ,32(2):9, 2007.[21] S. Chaudhuri, R. Krishnamurthy, S. Potamianos, andK. Shim. Optimizing queries with materialized views.In
Proceedings of the Eleventh InternationalConference on Data Engineering , ICDE ’95, pages190–200, Washington, DC, USA, 1995. IEEEComputer Society.[22] T. M. Ghanem, A. K. Elmagarmid, P.-˚A. Larson, andW. G. Aref. Supporting views in data streammanagement systems.
ACM Transactions on DatabaseSystems (TODS) , 35(1):1, 2010.[23] G. Graefe. The cascades framework for queryoptimization.
Data Engineering Bulletin , 18, 1995.[24] G. Graefe, W. Guy, H. A. Kuno, and G. Paullley.Robust query processing (dagstuhl seminar 12321). In17 agstuhl Reports , volume 2. SchlossDagstuhl-Leibniz-Zentrum fuer Informatik, 2012.[25] G. Graefe and W. J. McKenna. The volcano optimizergenerator: Extensibility and efficient search. In
Proceedings of IEEE 9th International Conference onData Engineering , pages 209–218. IEEE.[26] T. Griffin and B. Kumar. Algebraic changepropagation for semijoin and outerjoin queries.
SIGMOD Rec. , 27(3):22–27, Sept. 1998.[27] T. Griffin and L. Libkin. Incremental maintenance ofviews with duplicates. In
Proceedings of the 1995ACM SIGMOD International Conference onManagement of Data , SIGMOD ’95, pages 328–339,New York, NY, USA, 1995. ACM.[28] Y. E. Ioannidis, R. T. Ng, K. Shim, and T. K. Sellis.Parametric query optimization.
The VLDB Journal ,6(2):132–151, 1997.[29] J. Jia, C. Li, and M. J. Carey. Drum: A rhythmicapproach to interactive analytics on large data. In , pages 636–645. IEEE, 2017.[30] T. Kathuria and S. Sudarshan. Efficient and provablemulti-query optimization. In
Proceedings of the 36thACM SIGMOD-SIGACT-SIGAI Symposium onPrinciples of Database Systems , PODS ’17, pages53–67, New York, NY, USA, 2017. ACM.[31] C. Koch. Incremental query evaluation in a ring ofdatabases. In
Proceedings of the twenty-ninth ACMSIGMOD-SIGACT-SIGART symposium on Principlesof database systems , pages 87–98, 2010.[32] W. Lang, R. V. Nehme, E. Robinson, and J. F.Naughton. Partial results in database systems. In
Proceedings of the 2014 ACM SIGMOD InternationalConference on Management of Data , SIGMOD ’14,pages 1275–1286, New York, NY, USA, 2014. ACM.[33] P. Larson and J. Zhou. Efficient maintenance ofmaterialized outer-join views. In
Proceedings of the23rd International Conference on Data Engineering,ICDE 2007, The Marmara Hotel, Istanbul, Turkey,April 15-20, 2007 , pages 56–65, 2007.[34] Y.-N. Law, H. Wang, and C. Zaniolo. Query languagesand data models for database sequences and datastreams. In
Proceedings of the Thirtieth InternationalConference on Very Large Data Bases - Volume 30 ,VLDB 04, page 492503. VLDB Endowment, 2004.[35] M. K. Lee. Implementing an interpreter for functionalrules in a query optimizer. 1988.[36] D. Maier, J. Li, P. Tucker, K. Tufte, andV. Papadimos. Semantics of data streams andoperators. In T. Eiter and L. Libkin, editors,
DatabaseTheory - ICDT 2005 , pages 37–52, Berlin, Heidelberg,2005. Springer Berlin Heidelberg.[37] R. Motwani, J. Widom, A. Arasu, B. Babcock,S. Babu, M. Datar, G. Manku, C. Olston,J. Rosenstein, and R. Varma. Query processing,resource management, and approximation in a datastream management system. CIDR, 2003.[38] M. Nikolic, M. Dashti, and C. Koch. How to win a hotdog eating contest: Distributed incremental viewmaintenance with batch updates. In
Proceedings of the2016 International Conference on Management ofData , SIGMOD ’16, pages 511–526, New York, NY, USA, 2016. ACM.[39] V. Raman and J. M. Hellerstein. Partial results foronline query processing. In
Proceedings of the 2002ACM SIGMOD international conference onManagement of data , pages 275–286, 2002.[40] P. Roy, S. Seshadri, S. Sudarshan, and S. Bhobe.Efficient and extensible algorithms for multi queryoptimization. In
Proceedings of the 2000 ACMSIGMOD International Conference on Management ofData , SIGMOD ’00, pages 249–260, New York, NY,USA, 2000. ACM.[41] M. J. Sax, G. Wang, M. Weidlich, and J.-C. Freytag.Streams and tables: Two sides of the same coin. In
Proceedings of the International Workshop onReal-Time Business Intelligence and Analytics ,BIRTE 18, New York, NY, USA, 2018. Association forComputing Machinery.[42] P. G. Selinger, M. M. Astrahan, D. D. Chamberlin,R. A. Lorie, and T. G. Price. Access path selection ina relational database management system. In
Proceedings of the 1979 ACM SIGMOD internationalconference on Management of data , pages 23–34, 1979.[43] M. A. Soliman, L. Antova, V. Raghavan, A. El-Helw,Z. Gu, E. Shen, G. C. Caragea, C. Garcia-Alvarado,F. Rahman, M. Petropoulos, F. Waas, S. Narayanan,K. Krikellas, and R. Baldwin. Orca: A modular queryoptimizer architecture for big data. In
Proceedings ofthe 2014 ACM SIGMOD International Conference onManagement of Data , SIGMOD ’14, pages 337–348,New York, NY, USA, 2014. ACM.[44] D. Tang, Z. Shang, A. J. Elmore, S. Krishnan, andM. J. Franklin. Intermittent query processing.
Proc.VLDB Endow. , 12(11):1427–1441, July 2019.[45] D. Terry, D. Goldberg, D. Nichols, and B. Oki.Continuous queries over append-only databases. In
Proceedings of the 1992 ACM SIGMOD InternationalConference on Management of Data , SIGMOD 92,page 321330, New York, NY, USA, 1992. Associationfor Computing Machinery.[46] H. Thakkar, N. Laptev, H. Mousavi, B. Mozafari,V. Russo, and C. Zaniolo. Smm: A data streammanagement system for knowledge discovery. In , pages 757–768. IEEE, 2011.[47] S. D. Viglas and J. F. Naughton. Rate-based queryoptimization for streaming information sources. In
Proceedings of the 2002 ACM SIGMOD internationalconference on Management of data , pages 37–48, 2002.[48] Z. Wang, K. Zeng, B. Huang, W. Chen, X. Cui,B. Wang, J. Liu, L. Fan, D. Qu, Z. Ho, T. Guan,C. Li, and J. Zhou. Grosbeak: A data warehousesupporting resource-aware incremental computing. In
Proceedings of the 2020 ACM SIGMOD InternationalConference on Management of Data , SIGMOD ’20,Portland, Oregon, USA, 2020. ACM.[49] F. Wolf, N. May, P. R. Willems, and K.-U. Sattler. Onthe calculation of optimality ranges for relationalquery execution plans. In
Proceedings of the 2018International Conference on Management of Data ,SIGMOD 18, page 663675, New York, NY, USA,2018. Association for Computing Machinery.[50] S. Yin, A. Hameurlain, and F. Morvan. Robust query18ptimization methods with respect to estimationerrors: A survey.
ACM Sigmod Record , 44(3):25–36,2015.[51] Y. Yu, P. K. Gunda, and M. Isard. Distributedaggregation for data-parallel computing: interfacesand implementations. In
Proceedings of the ACMSIGOPS 22nd symposium on Operating systemsprinciples , pages 247–260, 2009.[52] K. Zeng, S. Agarwal, and I. Stoica. iolap: Managinguncertainty for efficient incremental olap. In
Proceedings of the 2016 International Conference onManagement of Data , SIGMOD ’16, pages 1347–1361, New York, NY, USA, 2016. ACM.[53] Y. Zhang, B. Hull, H. Balakrishnan, and S. Madden.Icedb: Intermittently-connected continuous queryprocessing. In , pages 166–175.IEEE, 2007.[54] J. Zhou, P.-A. Larson, P.-A. Larson, J.-C. Freytag,and W. Lehner. Efficient exploitation of similarsubexpressions for query processing. In