Artificial Intelligence 10 min read

Building an Algorithm Platform for Machine Learning Deployment at Qunar

The article describes how a three‑stage algorithm platform was designed and implemented to automate model deployment, unify feature processing, and provide service‑oriented model evaluation, debugging, and monitoring for machine‑learning applications in a large e‑commerce environment.

Qunar Tech Salon
Qunar Tech Salon
Qunar Tech Salon
Building an Algorithm Platform for Machine Learning Deployment at Qunar

Author Zhang Zhongyuan, who joined Qunar in 2011 and worked on transaction systems, hotel data, core platforms, storage and monitoring, shares his experience from the Ctrip Tech Salon “Cloud Sea Machine Learning Meetup”.

In recent years, machine learning has become a hot topic, and companies are shifting from data analysis to data‑driven business development. While abundant learning resources exist, there is a strong demand for a systematic platform that automates repetitive work, reduces cross‑team communication, and provides model tracking and debugging.

Algorithm Platform

The platform construction is divided into three stages: (1) solve algorithm deployment to lower communication barriers; (2) build a comprehensive feature set to avoid duplicate data extraction; (3) create a model training system for rapid evaluation of multiple algorithms. The first stage is completed, the second is in progress, and this article focuses on the first stage.

Deployment Issues

Typical ML workflow includes data collection, feature processing, model training, and model publishing. The first three steps can be done offline, but publishing requires coordination with other teams, leading to scheduling, communication, and version‑control challenges. Specific problems include lack of standards, language mismatches between Python feature conversion and Java‑based production, duplicated work, versioning, and difficulty in monitoring and debugging models in production.

To address these, the team built a system that automates repetitive tasks, provides a unified API, and enables model tracking and debugging.

Algorithm Description

An algorithm consists of a version, a feature resolver, and an evaluator. The following interfaces were defined:

interface Algorithm
{
    String getApp();
    String getVersion();
    FeatureResolver getFeatureResolver();
    Evaluator getEvaluator();
    ListenableFuture
> eval(Request request);
}
interface AlgorithmFactory {
    Algorithm getOrCreate(String app, String version, String filter);
}

Model Definition

Early models used PMML files, but the team later adopted Vowpal Wabbit for better performance, implementing a Java version of the predictor. They also support legacy XML‑based DataProc models and composite models through lightweight code wrappers.

interface Evaluator
{
    ResultValue
eval(F resolved);
}
public class EvaluatorFactory {
    public Evaluator createEvaluator(Config config, String filter, InputStream model) {
        Evaluator e = createInstance(...);
        if (e instanceof AlgorithmFactoryAware) {
            ((AlgorithmFactoryAware) e).setAlgorithmFactory(...);
        }
        if (e instanceof KVStoreSupport) {
            ((KVStoreSupport) e).setStore(...);
        }
        ...
    }
}

Large Vowpal Wabbit model files require off‑heap memory to avoid GC pressure.

Feature Processing

Inspired by Airbnb’s Aerosolve, features are represented as a FeatureVector and each transformation is encapsulated in a Transform implementation. Configurations use a simple DSL; an example of a temperature‑category transform is shown below.

# temperature conversion
category_temperature {
    transform: category
    keys: [temperature]
    output: all
    outputKey: $key
    outputValue: $category
    categories: {
        ''      : 0
        '<10'   : 1
        '<30'   : 2
        '>=30'  : 3
    }
}

Typical transforms include default values, category normalization, external store lookup, and feature crossing. Optimized collections from Koloboke and Trove replace standard Java collections for better performance.

Service Usage

The platform was later turned into a service so that business teams can call algorithms like any other service. A debug switch allows request‑level tracing, and logs from all algorithm servers are aggregated for troubleshooting.

AlgorithmBuilder builder = AlgorithmBuilder.create()
    .setServer(...)
    .setStore(...)
    .setLazyInit(true)
    .setExecutor(...);
Algorithm algorithm = builder.getOrCreate(app, version, filter);
interface AlgorithmService {
ResultValue
eval(Request request);
}

Conclusion

Building an algorithm platform is an evolving effort that integrates feature engineering, model serving, monitoring, and debugging. While specific technologies and designs vary, the core goal remains to increase productivity by treating machine‑learning models as first‑class services.

Javamachine learningfeature engineeringModel DeploymentAlgorithm PlatformAI Services
Qunar Tech Salon
Written by

Qunar Tech Salon

Qunar Tech Salon is a learning and exchange platform for Qunar engineers and industry peers. We share cutting-edge technology trends and topics, providing a free platform for mid-to-senior technical professionals to exchange and learn.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.