Alluxio x Tobiko - ETL Happy Hour April 16, 2024 For more Alluxio events: https://alluxio.io/events/ Speaker: Chen Liang (Staff Software Engineer @ Uber) In this presentation, Chen Liang will share the design and implementation of the Alluxio-Presto local cache to reduce query latency.

1. Speed Up Presto at Uber
with Alluxio Caching
Chen Liang - Software Engineer@Uber

2. Data informs every decision at Uber
Marketplace
Pricing
Community
Operations
Growth Marketing Data Science
Compliance
Eats

3. Presto
* https://prestodb.io/

4. Presto @ Uber
10K
Weekly Active Users
500K
SQL Queries/day
4
Regions
>9K
Nodes
>40
Clusters
74PB
bytes read/day

5. Presto Alluxio Local Cache: Overview
● Data read throughput is crucial for
Presto performance
○ Local cache has great potential
Production Deployment
● Inspired by Meta’s prior work link
● Plugged in as a local library in Presto
worker
https://prestodb.io/blog/2020/06/16/alluxio-datacaching

6. Alluxio@Uber Presto
● Challenges @Uber:
○ Realtime Partition Updates
○ Cluster Membership Change
○ Cache Size Restriction

7. Challenge #1: Realtime Partition Updates
● A lot of tables/partitions are constantly changing
○ Hudi tables
○ Queries constantly performing upserts
● Causing outdated partitions in cache
○ Partition may have changed on HDFS, while Alluxio still
caches the outdated version

8. Challenge #1: Realtime Partition Updates
● Solution: Add Hive latest modification time to caching key
○ hdfs://<path> → hdfs://<path><mod time>
● New partition with latest modification gets cached
○ Each update will create a separate cache copy
● Tradeoff: outdated partition still present in cache, wasting
caching space until evicted

9. Challenge #2: Cluster Membership Change
● A file is pinned to a set of worker nodes for cache efficiency
○ SOFT_AFFINITY in Presto
○ Default use a modulo hash function to map partitions to nodes
● Presto worker nodes may go up/down due to operational activities
○ Node crash/Maintenance
○ Ad-hoc Node restart
● Hash function map to wrong nodes when node changes, e.g.
○ For 3 nodes, key#4 → 4 mod 3 = node#1
○ One node down, then, key#4 → 4 mod 2 = node#0
■ Wrong node, cache miss

10. Challenge #2: Cluster Membership Change
Solution: Consistent Hashing
● All nodes are placed on a virtual
ring
● Relative ordering of nodes on
the ring does not change
● Look up the key (file) on the
ring
● Replication for better
robustness
Node0
Node1
Node2
Partition

11. Challenge #3: Cache Size Limitation
● PBs read by Presto queries >> PBs Disks space available on
Worker nodes
○ 74PB of total data accessed daily v.s ~120TB disk space per
cluster
● Cache inefficiency due to:
○ High eviction rate
○ High cache miss rate

12. Challenge #3: Cache Size Limitation
● Solution: Selective Cache
○ Cache a subset of selected datas
■ table to cache + partitions to cache
■ Based on traffic pattern analysis
● Greatly increased cache hit rate
■ From ~65% to >90%
{
"databases": [{
"name": "database_foo",
"tables": [{
"name" : "table_bar",
"maxCachedPartitions": 100}]}]
}

13. Current Status and Future Work
Current
● 14 clusters / 4600 nodes (half of Presto footprint at Uber)
● Serving ~25% percent of reads
Moving Forward: Presto Local Cache in Cloud
● Operation operation in cloud is $ expensive
○ Every single read call to cloud storage is charged (unlike
onprem)
○ Scaling reads in cloud can be challenging Cloud enforced
throttling policies on different levels
● Caching service in cloud to reduce reads to object store
○ Performance + Cost Reduction Improvement