按父单 ID 归集成交：子单回填到父单

真实的算法执行系统几乎不会把一个大单直接打到交易所。OMS 会把一个父单（例如"在 16:00 之前买 50,000 股 AAPL"）切成许多子单，路由到不同场所，被分批成交后以一连串 fill 的形式回流。要看清父单的真实进度——平均成交价、已经做了多少、什么时候开始的、最后一笔在何时——就需要遍历这条 fill 流，把子单的成交按父单聚合回去。

实现 solution(fills) -> dict[str, dict]。fills 是一个 dict 列表，每条包含 parent_id、qty、price、ts 四个 key。按 parent_id 分组，返回一个 dict，把每个 parent_id 映射到一个汇总字典，必须包含下列 key：

• total_filled_qty (float)：该父单下所有 fill 的 qty 之和。
• vwap (float)：sum(qty * price) / sum(qty)。当 total_filled_qty == 0 时返回 0.0。
• n_fills (int)：该父单下的 fill 数量（qty == 0 也计数）。
• first_fill_ts (int)：该父单下所有 fill 的 ts 最小值。
• last_fill_ts (int)：该父单下所有 fill 的 ts 最大值。

返回字典的 key 顺序必须与每个 parent_id 在输入中首次出现的顺序一致。

例子

fills = [
    {"parent_id": "P1", "qty": 100, "price": 50.0, "ts": 1000},
    {"parent_id": "P1", "qty": 200, "price": 51.0, "ts": 1100},
    {"parent_id": "P2", "qty": 50,  "price": 99.0, "ts": 1050},
]
solution(fills)
# -> {
#     "P1": {"total_filled_qty": 300.0, "vwap": 50.666666666666664, "n_fills": 2,
#            "first_fill_ts": 1000, "last_fill_ts": 1100},
#     "P2": {"total_filled_qty": 50.0,  "vwap": 99.0,                "n_fills": 1,
#            "first_fill_ts": 1050, "last_fill_ts": 1050},
# }

solution([])
# -> {}

fills = [
    {"parent_id": "P9", "qty": 0, "price": 10.0, "ts": 5},
    {"parent_id": "P9", "qty": 0, "price": 12.0, "ts": 7},
]
solution(fills)
# -> {"P9": {"total_filled_qty": 0.0, "vwap": 0.0, "n_fills": 2,
#            "first_fill_ts": 5, "last_fill_ts": 7}}

注意第三个例子：两条 qty == 0 的 fill 仍然算作 fill（n_fills = 2），仍然会刷新 first_fill_ts / last_fill_ts——只是 VWAP 因为没有可加权的数量而退化为 0.0。

实践背景

父单/子单的拆单路由是算法执行里的常态：交易员面前的一个父单（"按 VWAP 算法，在 16:00 之前买 50,000 股 AAPL"）会被算法切成成百个子单，分散打到不同交易所、暗池和时点上。交易所磁带只看得到子单成交，但所有 TCA 报告、盘后对账、实时进度监控都需要把这些 fill 折回父单视角：进度多少、平均价多少、何时开始成交、最后一笔何时打出。这正是 OMS 内部以及每个执行研究 notebook 在做 slippage 和 impact 分析之前必经的一步簿记。