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<R> {
    String getApp();
    String getVersion();
    FeatureResolver getFeatureResolver();
    Evaluator getEvaluator();
    ListenableFuture<ResultValue<R>> 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<F, R> {
    ResultValue<R> 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 {
    <R> ResultValue<R> 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.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

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

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.