Ctrip's Presto Engine: Challenges, Improvements, and Upgrade Roadmap

Background : Ctrip, a leading online travel service in China, processes massive amounts of data for hotels, flights, and vacations, requiring a fast, unified query engine capable of handling data from gigabytes to petabytes. After evaluating MPP databases such as Presto, Spark, and Impala, Presto was selected for its performance and community activity.

Presto Architecture : Presto follows a master‑slave model consisting of a Coordinator, a Discovery Server (often embedded in the Coordinator), and multiple Worker nodes that execute queries and interact with HDFS.

Challenges Faced : Stability problems: frequent OOM crashes and strict partition/table type checks caused query failures. Authentication inconsistencies: an internal MySQL‑based credential store conflicted with the Kerberos‑based security model used elsewhere. Performance waste: default broadcast joins, lack of data compression during transfer, and long‑running queries consuming excessive resources. Insufficient monitoring: no historical query analysis or user behavior insights.

Improvements Implemented : Performance : leverage Hive statistics for join strategy selection, enable page compression, optimize Datanode storage access, and tune Presto parameters. Security : enable Kerberos for HTTPS access, add Hive Metastore Kerberos impersonation, integrate Ctrip's scheduling system (Zhou Ze) authorization, and implement Kerberos cache for clients. Resource Management : limit maximum partition count per query, cap split generation, and automatically kill long‑running queries. Compatibility : fix Avro field loss, support Hive‑created views, relax strict type matching, and resolve concurrent modification issues during column drops.

Upgrade Roadmap : Phase 1 – Version Upgrade: moved to Presto 0.190, addressing memory leaks, Avro field loss, and integer multiplication bugs. Phase 2 – Authentication & Performance: replaced MySQL with Kerberos, introduced automatic join mode detection, and added query result size throttling. Phase 3 – Resource Control & Monitoring: intercepted split‑heavy queries, built an initial monitoring platform, and limited partition access. Phase 4 – Future Directions: plan to enable resource queues, real‑time alerting, and a unified query engine that can route between Presto, Kylin, Hive, and Spark‑SQL.

Monitoring Platform : a data collector polls the Presto Coordinator every minute, distributes metrics to listeners, and stores them in MySQL tables (Basic query, Query stats, Query info, Query stage info, Query task info). The platform generates real‑time health reports and historical trend analyses for capacity planning and error diagnosis.

Future Outlook : Presto will continue to evolve with tighter integration into Ctrip's internal OLAP reporting system (Art Nova) and potential use in real‑time data processing (VDP). The upcoming architecture diagram shows a more robust, queue‑driven, and alert‑enabled ecosystem.