Design and Implementation of a Multi‑Platform DSL Translator for Omega Real‑Time Reach System

In the Omega real‑time reach system series, three subsystems—Behavior Collection Center, CEP Rule Center, and User Reach Center—were introduced. Xianyu defined a domain‑specific language (DSL) that converts complex code into a concise SQL‑like expression and can be compiled to various high‑level languages such as Python, C++, JavaScript, and Java. This raises the challenge of translating the custom DSL into multiple target languages.

Omega implements complex event processing (CEP) engines on cloud, edge, and front‑end. The cloud engine handles cross‑user events, while edge and front‑end engines focus on single‑user events, offering higher real‑time performance and security. Because each platform has its own CEP implementation, developers face a high technical barrier for cross‑platform development. A custom DSL is proposed to hide these differences so developers can concentrate on business logic.

The main differences among the CEP engines lie in input data formats, CEP APIs, execution containers, and result output. To bridge the gap, four core aspects are addressed:

Unified input‑data protocol

Standardized CEP API

Translation framework selection and implementation

Execution‑container abstraction

Unified Input Data – A generic data‑template layer masks platform‑specific input differences. Each platform registers its own data instance, allowing the DSL to use a common schema. Example JSON schema:

{
    "eventAlias":"事件别名",
    "eventCode":"PUBLISH_ITEM",
    "eventDesc":"卖家的详情被浏览",
    "eventTime":"事件发生时间",
    "updateTime":"事件更新时间",
    "partitionId":"分区id",
    "userId":"用户id",
    "extraInfo":{
        "itemId":"商品id",
        "buyerId":"买家id",
        "sellerId":"卖家id",
        "itemType":"商品类型",
        "itemStatus":"商品状态",
        "categoryId":"类目id",
        "latitude":"经度",
        "longitude":"纬度",
        "...":"..."
    },
    "scene":"场景",
    "fromScene":"上一个场景",
    "toScene":"下一个场景",
    "isFirstEnter":"是否首次进入",
    "bizId":"唯一Id",
    "sessionId":"会话id",
    "actionType":"行为类型",
    "actionName":"行为标识",
    "ownerName":"骆彬"
}

Unified CEP API – Based on the Flink CEP specification, a common set of Java method signatures is defined, e.g.:

public static
Pattern
begin(final String name);
public Pattern
where(IterativeCondition
condition);
public Pattern
or(IterativeCondition
condition);
public Pattern
until(IterativeCondition
untilCondition);
public Pattern
within(Time windowTime);
public Pattern
next(final String name);
public Pattern
notNext(final String name);
public Pattern
followedBy(final String name);
public Pattern
notFollowedBy(final String name);
public Pattern
followedByAny(final String name);
public Pattern
times(int times);
public Pattern
allowCombinations();
public Pattern
consecutive();
public static
GroupPattern
begin(Pattern
group);
public GroupPattern
next(Pattern
group);

Translation Framework – After evaluating Antlr V4, parboiled, and Apache Calcite, Antlr V4 was chosen for its friendliness to multi‑language translation. The DSL grammar is parsed into an AST, which is then traversed to generate code in the target language.

Execution‑Container Shielding – A DSL rule‑type concept maps rules to the appropriate execution container (edge, front‑end, or cloud), hiding container details from developers. A DSL editor provides syntax hints, audit flow, resource management, and result query features.

Practical Impact – During the Double‑11 shopping festival, the DSL reduced development time dramatically: a rule that previously required a week of work could be built in 1–2 hours, with an average creation time of about 10 minutes per rule, greatly improving efficiency.

Future Plans – The Omega ecosystem will integrate front‑end support, deepen DSL capabilities, publish protocol standards, and release mature translator products.