PaperlayerView exact revision on arXiv

Source-linked AI summary

Lambada: Interactive Data Analytics on Cold Data using Serverless Cloud Infrastructure

Ingo Müller, Renato Marroquín, Gustavo Alonso

arXiv:1912.00937v1cs.DBcs.DC

TL;DR

Data analytics lacks consensus on whether serverless computing is technically and economically viable because current offerings impose important limitations. The paper designs Lambada as a purely serverless query-processing system for interactive analytics on cold data, using components that address those limitations. Lambada is reported to be competitive with commercial QaaS systems, reaching about 15 s on more than 1 TB and achieving favorable cost and speed comparisons.

  • Problem

    Current serverless offerings impose limitations that leave the technical and economic viability of serverless data analytics unresolved.

  • Method

    Lambada uses a purely serverless architecture with specialized invocation, scanning, exchange, and shared-storage components for interactive queries over cold data.

  • Results

    Lambada can answer queries on more than 1 TB of data in about 15 s, making it competitive with commercial QaaS systems and an order of magnitude faster than job-scoped VM infrastructure.

  • Takeaways & Limitations

    Interactive analytics on cold data is identified as a viable and attractive use case for serverless computing.

  • Takeaways & Limitations

    For highly selective queries, Amazon Athena can eventually become cheaper than Lambada because its pricing accounts for selected-row selectivity.

Abstract

from arXiv · show

The promise of ultimate elasticity and operational simplicity of serverless computing has recently lead to an explosion of research in this area. In the context of data analytics, the concept sounds appealing, but due to the limitations of current offerings, there is no consensus yet on whether or not this approach is technically and economically viable. In this paper, we identify interactive data analytics on cold data as a use case where serverless computing excels. We design and implement Lambada, a system following a purely serverless architecture, in order to illustrate when and how serverless computing should be employed for data analytics. We propose several system components that overcome the previously known limitations inherent in the serverless paradigm as well as additional ones we identify in this work. We can show that, thanks to careful design, a serverless query processing system can be at the same time one order of magnitude faster and two orders of magnitude cheaper compared to commercial Query-as-a-Service systems, the only alternative with similar operational simplicity.

1 INTRODUCTION

The paper examines whether FaaS can support interactive data analytics and identifies cold-data workloads as its most attractive use case. Lambada addresses serverless limitations with purely serverless components while targeting interactive latency and lower cost.

  • Challenges: Serverless functions impose restricted network connectivity, limited runtime, stateless operation, limited caching, and limited scheduling control.These constraints complicate distributed query processing and worker coordination.
  • Challenges: Additional serverful services can restore communication between functions but reintroduce always-on infrastructure and its associated cost or reduced interactivity.Such components can undermine the operational and economic advantages that motivate FaaS.
  • Motivation: FaaS is most attractive for interactive analytics on cold data, where users run relatively infrequent queries and interactive response matters.The paper contrasts job-scoped and always-on infrastructure, emphasizing startup overhead, think time, and cold-data access.
  • Approach: Lambada uses only serverless components to process gigabytes to terabytes of cold data at interactive query latency.The system is designed to accommodate known and newly identified limitations without relying on always-on infrastructure.
  • Results: One order of magnitude faster and two orders of magnitude cheaper than commercial QaaS offerings in the most favorable cases.The comparison concerns systems with similar operational simplicity for interactive analytics on cold data.
  • Approach: Lambada combines fast worker invocation, bandwidth-aware scanning, and a purely serverless exchange to address serverless query-processing constraints.The contributions include sublinear invocation that can spawn 4k functions in 3 s, efficient cloud-storage scans, and sub-quadratic exchange request complexity.

2 BACKGROUND

The paper models interactive data-analytics usage around sessions, think time, and changing datasets, then defines serverless computing by query-only costs. It distinguishes serverless services from session-scoped or VM-backed infrastructure and introduces Lambada’s architecture.

  • Usage Model: Interactive analytics usage consists of short work sessions in which users explore samples and then query full datasets.Sessions may involve several datasets and are separated by substantial breaks.
  • Usage Model: Think time between queries typically lasts seconds to minutes and includes analyzing results, visualizing, debugging query code, and planning next steps.Breaks between sessions typically range from hours to weeks.
  • Definition: Serverless systems incur costs only for executing sample or full queries, not for installation, idle infrastructure, or switching datasets.This is the paper’s operational definition of serverless computing for data analytics.
  • Examples: Query-as-a-Service systems such as Amazon Athena and Google BigQuery provide serverless query access to datasets in cloud storage.Users pay for individual queries rather than operating database infrastructure.
  • Examples: Lower-level serverless services include AWS Lambda, S3, DynamoDB, SQS, and Step Functions, while VM-backed services and session-running clusters are excluded.AWS Lambda is identified as the lower-level compute option with sufficiently low startup time for interactive analytics.

3 ARCHITECTURE OF LAMBADA

Lambada uses a shared-storage architecture in which a local driver invokes serverless workers that execute query plans in parallel. Queries are translated, optimized, compiled, and assigned across driver and serverless scopes.

  • Overview: The local driver invokes data-parallel AWS Lambda workers that communicate through S3, DynamoDB, and SQS rather than direct connections.The driver also uses shared storage to communicate with workers and collect results.
  • Query processing: Lambada translates frontend queries into common intermediate query plans and applies optimizations including push-downs, join ordering, and data-parallel transformations.Operator pipelines between materialization points are lowered to LLVM IR and just-in-time compiled.
  • Query processing: Query plans are divided into scopes that may execute on different target platforms, with most Lambada operators assigned to serverless scopes.Small scopes may run on the driver.
  • Worker runtime: Serverless workers are preconfigured AWS Lambda functions containing an execution framework, an event-handler wrapper, native dependencies, memory settings, and a timeout.The same execution framework runs on the driver and workers.

4 SYSTEM COMPONENTS FOR SERVERLESS ANALYTICS

Lambada’s purely serverless design must coordinate provider quotas, execution speed, and monetary cost while implementing shared-storage database components.

  • Design constraints: Each serverless component trades off provider quotas, execution speed, and monetary cost under the cloud provider’s service constraints.The design explicitly considers hard limits such as S3 request rates.

4.1 Intra-worker Parallelism

AWS Lambda exposes limited intra-worker parallelism: larger functions can execute threads on multiple CPUs, but the available parallelism is better suited to overlapping pipeline work than data parallelism.

  • Intra-worker Parallelism: 1792 MiB functions provide one vCPU, while larger functions receive proportionally more CPU resources.The allocation is proportional to function memory.
  • Intra-worker Parallelism: 1.67 × baseline throughput is achieved by the largest 3008 MiB workers using two threads.With one thread, larger functions do not exceed the one-vCPU baseline; the second thread enables additional throughput.
  • Design implication: The limited parallelism is insufficient for efficient data parallelism within one worker but can support inter- and intra-pipeline parallelism.Lambada therefore exploits it for overlapping communication and selected pipeline stages.

4.2 Invocation

Naively invoking many Lambda workers is too slow for interactive analytics, so Lambada distributes invocation work across worker generations. This reduces startup time while leaving concurrent-invocation limits as the relevant service constraint.

  • Invocation: 220–290 invocations/s are achieved with 128 threads, but invoking many workers remains challenging because individual requests take about 36 ms to 0.5 s.Concurrent requests overlap network round-trip latency.
  • Two-level invocation: First-generation workers invoke second-generation workers using assigned ID/input lists, distributing the total invocation work across workers.Each first-generation worker receives a share of the worker IDs and inputs.
  • Two-level invocation: 2.5 s was sufficient to initiate the last worker among 4096 cold-started workers, versus an expected 13 s to 18 s for driver-only invocation.The timing includes the two-level invocation process shown in the example run.
  • Service limits: AWS Lambda’s invocation-rate limit is not relevant for this workload, whereas the concurrent-invocation limit remains relevant.Each query requires one invocation per worker, and the expected query rate is far below ten per second.

4.3 S3-based Scan Operator

Lambada’s S3 scan operator is designed around measured bandwidth and request-cost trade-offs, using concurrent requests and Parquet-aware processing to exploit serverless resources efficiently.

  • 4.3.1 Network Characteristics.: 90 MiB/s per worker is a stable large-file bandwidth limit, largely independent of worker size and network-connection count.Workers below 1 GB of memory achieve slightly lower ingress bandwidth.
  • 4.3.1 Network Characteristics.: Small files can reach almost 300 MiB/s only with several concurrent connections, so short scans require parallel requests to exploit burst bandwidth.The authors attribute this behavior to a presumed credit-based traffic-shaping mechanism.
  • 4.3.1 Network Characteristics.: 1 MB chunks reach the prior throughput with four concurrent connections, but smaller chunks raise request costs because every S3 request has a fixed charge.At 1 MiB chunks, requests cost 1.7 × the workers for the same scan; one million read requests cost $0.4.
  • 4.3.2 Scan Operator Design.: The Parquet scan operator reads file paths through open/next/close and returns columnar table chunks to downstream operators.It uses a Parquet library with an S3-backed filesystem and supports selection and projection pushdown over row groups and column chunks.
  • 4.3.2 Scan Operator Design.: Four concurrency levels cover filesystem reads, column chunks, row groups, and files; decompression can also use limited multi-core parallelism when compression is CPU-bound.Decompression parallelism is beneficial only for heavy compression and when remaining query computation cannot fully use the resources.

4.4 Exchange Operator

Lambada uses S3 as the communication layer for serverless exchange, then reduces request pressure and cost through bucket partitioning, multi-level exchange, and write combining.

  • 4.4 Exchange Operator: Serverless workers exchange large data through S3 because they cannot accept incoming network connections.The system provides a family of exchange operators for this purpose.
  • 4.4.1 Basic Ideas and Challenges.: BasicExchange performs P² reads and P² writes, creating request-rate pressure that can throttle executions at large worker counts.With 1k workers, one execution requires 2M requests against AWS limits of 3.5k writes and 5.5k reads per second in July 2018.
  • 4.4.1 Basic Ideas and Challenges.: Encoding sender or receiver information in bucket names increases the aggregate request limit by the number of buckets used.Ten buckets reduce the per-bucket request rate to P/10 and require no ongoing cost after installation.
  • 4.4.4 Serverless Exchange Operator Analysis.: BasicExchange request costs grow quadratically, reaching about $100 for 4k workers processing 4 TiB, while write combining mainly reduces write costs.At 256 workers, S3 request costs already exceed worker costs in most typical configurations.
  • 4.4.2 Multi-Level Exchange.: Two-level exchange restricts each phase to worker subsets, and three levels with write combining make request costs negligible in all evaluated configurations.Two levels with write combining fall below worker costs in almost all configurations.
  • 4.4.4 Serverless Exchange Operator Analysis.: The exchange optimizations provide practical controls for reducing storage-request costs while trading fewer requests against additional data scans.Multi-level exchange reads and writes the input once per level, increasing worker execution cost.

5 EVALUATION

The evaluation measures end-to-end and processing behavior on replicated TPC-H LINEITEM data, examining worker configurations and Parquet pushdowns for interactive queries.

  • 5 EVALUATION: 151 GiB of SF1000 LINEITEM becomes Parquet with standard encoding and GZIP compression, stored in files of about 500 MB.The corresponding uncompressed CSV relation is 705 GiB.
  • 5 EVALUATION: End-to-end latency includes worker invocation, query work, and result fetching, with medians reported from three same-datacenter runs.The evaluation separately measures processing time when isolating pushdown effects from invocation time.
  • 5.2 Effect of Worker Configurations: Increasing worker memory from 512 to 1796 MiB significantly accelerates Q1 because GZIP scanning is CPU-bound, while larger workers increase price without improving speed.The 1796 MiB configuration can be marginally cheaper than 512 MiB because of multithreading overhead, whereas larger memory raises price linearly.
  • 5.2 Effect of Worker Configurations: Both hot and cold Q1 executions finish in less than 10 s, although cold runs incur about a 20% end-to-end latency penalty.The cold-run penalty reflects slower invocation and somewhat slower execution.
  • 5.2 Effect of Worker Configurations: Using more workers speeds execution with diminishing gains and increased costs, as shown by varying files per worker at fixed 1796 MiB memory.The experiment compares F = {4, 2, 1} and W = {80, 160, 320}.
  • 5.3 Effect of Push-downs: Pushdowns create fast workers that prune all row groups using l_shipdate metadata and slower workers that load, decompress, and scan projected columns.If metadata were centrally available before invocation, the prunable workers would not need to start; that optimization is outside the paper’s scope.

5.4 Comparison with QaaS Systems

Lambada is compared with BigQuery and Athena on TPC-H queries over cold data, using the same operationally simple cloud-storage query model. It delivers competitive or superior latency and substantially lower cost, with results shaped by data loading and pricing models.

  • Experiment setup: BigQuery and Athena provide the closest comparison because both query cloud-storage datasets without users starting or maintaining infrastructure.BigQuery may require loading large-scale datasets first, whereas Athena supports in-situ processing.
  • Experiment setup: Lambada, BigQuery, and Athena are evaluated on TPC-H Queries 1 and 6 at scale factors 1 k and 10 k.Lambada uses one worker per file, with 320 and 3200 workers for the two scale factors.
  • Running time: Lambada maintains the most constant end-to-end latencies as data grows by proportionally increasing its worker count.Its latency rises mainly from worker invocation, stragglers, and related effects; Athena grows linearly, while BigQuery grows sublinearly.
  • Running time: At scale factor 10 k, Lambada is about 26 × faster than Athena for Q1 and 15 × faster for Q6.At scale factor 1 k, it is about 4 × faster for Q1 and on par for Q6; BigQuery can be faster without loading time, but loading takes about 40 min and 6.7 h.
  • Monetary cost: For both queries and scale factors, Lambada is cheaper than BigQuery and Athena, usually by about one and two orders of magnitude, respectively.The exception is Q6 at scale factor 1 k; BigQuery’s larger stored format also increases its cost relative to Athena.
  • Monetary cost: Highly selective queries can narrow or reverse Lambada’s cost advantage because Athena charges only for selected rows and can become free when all tuples are filtered.Lambada retains invocation, planning, metadata, and file-pruning costs, and may scan the entire input when min/max filters cannot help.

5.5 Exchange Operator

The exchange operator is evaluated against S3- and VM-storage-based systems on datasets from 100 GB to 3 TB. Lambada is faster while avoiding always-on infrastructure, but straggler tails increasingly dominate at larger scale.

  • Evaluation: Lambada’s S3-based exchange operator is compared with published results for Pocket and Locus using a 100 GB dataset.The configurations use 2048 MiB workers for Lambada, compared with 3008 MiB for Pocket and 1536 MiB for Locus.
  • Performance comparison: Compared with Pocket’s S3 baseline, Lambada is 5 × faster on 250 workers and scales further through sublinear requests and multiple buckets.These design choices enable experiments with 500 and 1000 workers.
  • Performance comparison: Against Pocket’s VM-based storage implementation, Lambada is 2.5 ×, 2 ×, and 1.4 × faster on 250, 500, and 1000 workers, respectively.Lambada is also about 4 × faster than Locus’s fastest configuration with 250 workers and requires no always-on infrastructure.
  • Large-scale evaluation: On 1 TB and 3 TB datasets, the exchange operator takes 56 s with 1250 workers and 159 s with 2500 workers, respectively.For 1 TB, Locus takes 39 s with a dynamic worker count and VM-based fast intermediate storage.
  • Stragglers and limitations: At 3 TB, straggler waiting time dominates execution, especially because slow writes delay subsequent phases and propagate waits across worker groups.The slowest worker is about 30% slower than the median on the small dataset and 4 × slower on the large dataset.
  • Conclusion: Lambada demonstrates that exchange operators can run under a purely serverless paradigm and outperform approaches using always-on infrastructure.The experiments still identify tail-latency reduction as an area requiring further research.

6 RELATED WORK

Related work spans serverless distributed computation, cold-data analytics, serverless data-analysis systems, and intermediate-data storage. Lambada contributes techniques for fast worker invocation, optimized scanning, and serverless exchange without pre-provisioned nodes.

  • Serverless distributed computation: Prior serverless systems address applications including video analytics, edge computing, and data analytics, often emphasizing concurrency or cost optimization.The cited systems include Sprocket, which uses up to 1,000-way concurrency, and techniques based on placement and function fusion.
  • Serverless distributed computation: Lambada uses a propagation tree to start several thousand workers in under 4 s, addressing the interactivity challenge at large worker counts.Concurrent spawning from the driver alone is described as insufficient at the scale needed for interactive analytics.
  • Serverless data-analysis systems: Unlike PyWren, Lambada incorporates operator parallelization and optimizations such as selection and projection push-downs into the system.The approach combines query compilation with a carefully designed scan operator.
  • Intermediate-data storage: Pocket and Locus study serverless shuffle and intermediate-data storage, but their approaches use quadratic request counts or additional non-serverless infrastructure.Lambada’s exchange design targets these constraints while avoiding advance provisioning of all required nodes.
  • Cold-data analytics: Lambada positions serverless workers as a cost-effective possibility for interactive analytics over cold data, while acknowledging that serverless suitability depends on the workload.The paper contrasts this use case with claims that serverless workers are unsuitable for certain machine-learning workloads.

7 CONCLUSIONS

The paper concludes that serverless computing is viable and attractive for interactive analytics on cold data. Lambada combines serverless mechanisms to achieve competitive performance and lower cost, while its resource-utilization pricing also makes bugs and corner cases more expensive.

  • Contributions: Lambada addresses serverless analytics limitations with tree-based worker invocation, cost-performance-aware scanning, and a purely serverless exchange operator.The system is presented as overcoming limitations previously considered inherent to serverless computing.
  • Results: Queries over more than 1 TB can be answered in about 15 s, making Lambada competitive with commercial QaaS systems and an order of magnitude faster than job-scoped VM infrastructure.This result is attributed to the system’s optimizations.
  • Pricing implications: Serverless pricing ties optimization benefits and bug costs to resource utilization rather than only to completed work.Optimizations lower the price of tasks that benefit from them, while bugs and difficult corner cases may be significantly more expensive.
Loading 1912.00937v1…