Palantir Contour 深度解析：Ontology 驱动的企业级数据分析平台

#TL;DR

Palantir Contour 不是 Tableau 的竞品——它是Ontology-aware 的分析工具，分析的不是表和列，而是业务对象和关系，用户可以直接从分析结果触发 Action（下订单、发审批、调资源）。
Contour 支持实时协作分析：多人可以在同一个分析画布上工作，共享过滤器、交叉引用彼此的分析板，像 Google Docs 一样协作式地探索数据。
如果你对这种 Ontology 驱动的分析能力感兴趣，但希望拥有开源、可私有化部署的方案，可以关注 Coomia DIP 的 AnalyticsQueryService，它实现了 14 种聚合函数、智能时间分桶、TopN（带"其他"行）、4 种空值填充策略。

#引言：为什么数据分析工具还是不好用？

每个企业都买了 BI 工具。Tableau、PowerBI、Qlik、Looker——市面上不缺选择。然而一个尴尬的现实是：

Code

企业花了 200 万买 Tableau
→ 数据工程师花 3 个月建好数据模型
→ 培训了 50 个业务用户
→ 6 个月后，真正在用的只有 8 个人
→ 其中 5 个人只看固定的几张仪表盘
→ 剩下 3 个人天天让数据团队改报表

问题出在哪里？不是工具不好看，也不是功能不够多。问题的根源在于：

语义鸿沟：用户看到的是"表名"和"列名"，不是"客户"和"订单"
只能看不能做：分析完发现供应商有风险，然后呢？退出 BI，开邮件，写审批...
上下文断裂：从一张图钻取到另一张图时，过滤条件丢失了
协作为零：每个人各自建自己的报表，分析过程不共享

Palantir Contour 的设计理念完全不同——它不是一个"看数据"的工具，而是一个"在数据上工作"的平台。

#一、Contour 的核心差异：Ontology-Aware 分析

#1.1 传统 BI vs Contour 的数据模型

Code

传统 BI 的工作方式：
┌────────────┐    ┌──────────────┐    ┌─────────────┐
│ 数据仓库    │───→│ 数据模型      │───→│ 可视化图表   │
│ （表和列）    │    │ （星型Schema)  │    │ （柱状/折线）  │
└────────────┘    └──────────────┘    └─────────────┘
                       ↑
                  需要数据工程师
                  建模和维护

Contour 的工作方式：
┌────────────┐    ┌──────────────┐    ┌─────────────┐
│ Ontology    │───→│ 对象和关系    │───→│ 交互式分析   │
│ （业务对象）  │    │ （直接使用）    │    │ + Actions    │
└────────────┘    └──────────────┘    └─────────────┘
                       ↑
                  业务用户直接
                  选择对象类型

在 Contour 中，用户不需要知道"数据在哪张表里"。他们只需要知道"我要分析什么业务对象"：

Code

用户视角（Contour）：
"我要分析【供应商】的【交付准时率】，按【区域】分组，过滤【活跃供应商】"

用户视角（传统 BI）：
"我需要关联 vendor_master 和 po_delivery 表，
 用 vendor_id 做 JOIN，计算 actual_date > due_date 的比例，
 按 vendor_region 分组，WHERE status = 'ACTIVE'"

#1.2 对象导航：沿着关系探索

Contour 的杀手级功能之一是对象导航——你可以沿着 Ontology 中的关系链，从一个对象类型自然地导航到另一个：

Code

┌──────────┐  places_order  ┌──────────┐  contains  ┌──────────┐
│ Supplier │───────────────→│  Order   │───────────→│ OrderItem│
└──────────┘                └──────────┘            └──────────┘
     │                           │                       │
     │ located_in                │ shipped_by             │ product_of
     ▼                           ▼                       ▼
┌──────────┐                ┌──────────┐            ┌──────────┐
│ Region   │                │ Shipment │            │ Product  │
└──────────┘                └──────────┘            └──────────┘

分析操作示例：

Code

1. 从【供应商】开始分析
2. "按交付准时率排序，找到最差的 10 个"
3. 点击某个供应商 → 自动展开其【订单】列表
4. 选择这些订单 → 导航到【物流】数据
5. 发现物流延迟集中在某个【区域】
6. 点击 Action → 触发"更换物流供应商"审批流

整个过程在一个分析画布上完成，没有"退出分析 → 打开另一个系统"的中断。

#二、交叉过滤与钻取

#2.1 联动过滤（Cross-Filtering）

Contour 中的所有分析板可以联动：

Code

┌─────────────────────────────────────────────────────────┐
│                    Contour 分析画布                       │
│                                                          │
│  ┌──────────────────┐    ┌──────────────────────────┐   │
│  │ 板 A: 区域地图     │    │ 板 B: 月度趋势图          │   │
│  │                   │    │                           │   │
│  │  [华东] ← 选中     │───→│  ← 自动只显示华东数据     │   │
│  │   华南             │    │                           │   │
│  │   华北             │    │  █ █ █ █ █ █ █ █ █ █     │   │
│  │   西南             │    │  1 2 3 4 5 6 7 8 9 10    │   │
│  └──────────────────┘    └──────────────────────────┘   │
│          │                                               │
│          │ 联动                                          │
│          ▼                                               │
│  ┌──────────────────┐    ┌──────────────────────────┐   │
│  │ 板 C: 供应商列表   │    │ 板 D: 风险评分分布        │   │
│  │                   │    │                           │   │
│  │  ← 只显示华东供应商│    │  ← 只显示华东供应商       │   │
│  │                   │    │                           │   │
│  │  供应商A  95%     │    │  高风险 ██ 2               │   │
│  │  供应商B  87%     │    │  中风险 ████ 5             │   │
│  │  供应商C  72%     │    │  低风险 ████████ 12        │   │
│  └──────────────────┘    └──────────────────────────┘   │
│                                                          │
│  全局过滤器： [时间： 2024Q3] [状态： 活跃] [- 添加过滤]     │
└─────────────────────────────────────────────────────────┘

关键点：当用户在板 A 中选择"华东"时，板 B、C、D 自动联动——不需要配置关联关系，因为 Ontology 中已经定义了对象之间的关系。

#2.2 多层钻取（Drill-Down）

Code

Level 1: 全国 → 各区域汇总
                    │
         点击"华东" │
                    ▼
Level 2: 华东 → 各省汇总
                    │
         点击"上海" │
                    ▼
Level 3: 上海 → 各仓库汇总
                    │
         点击"浦东仓"│
                    ▼
Level 4: 浦东仓 → 具体订单列表
                    │
         点击某订单  │
                    ▼
Level 5: 订单详情 → 关联的供应商、物流、产品
                    │
         [触发 Action: 催单/换供应商/调库存]

每一层钻取都保留上层的过滤上下文，并且可以随时回到任何一层。

#三、协作式分析

#3.1 实时多人协作

Contour 支持类似 Google Docs 的实时协作：

Code

┌──────────────────────────────────────────┐
│          共享分析画布                      │
│                                           │
│  张三（正在编辑板 A）                      │
│  李四（正在编辑板 C）                      │
│  王五（只读模式，跟随张三的视角）           │
│                                           │
│  活动记录：                               │
│  [10:03] 张三 添加了"区域地图"板           │
│  [10:05] 李四 修改了全局过滤器为 Q3        │
│  [10:07] 张三 @李四： "华东数据异常，看下"   │
│  [10:08] 李四 添加了"华东异常分析"板        │
│  [10:12] 李四 @张三： "是供应商C的问题"      │
│  [10:15] 张三 触发 Action: 暂停供应商C订单  │
└──────────────────────────────────────────┘

#3.2 分析即文档

Contour 分析不仅是临时探索——它可以被保存为可复现的分析文档：

版本历史：每次修改都有版本记录，可以回退
参数化：分析中的关键过滤器可以参数化，变成可复用的模板
嵌入叙事：在分析板之间可以插入文字说明，解释发现和结论
发布与订阅：分析可以发布为报告，订阅者定时收到更新

#四、实时 vs 批量分析模式

#4.1 批量模式

基于预计算的数据集，适合大规模历史分析：

Code

数据管道（每日凌晨运行）
    │
    ▼
预计算数据集（Iceberg 表）
    │
    ▼
Contour 查询（亚秒级响应）
    │
    ▼
仪表盘展示

#4.2 实时模式

直接查询实时数据源，适合运营监控：

Code

Flink CDC（实时同步）
    │
    ▼
实时物化视图
    │
    ▼
Contour 查询（秒级延迟）
    │
    ▼
实时仪表盘（自动刷新）

#4.3 混合模式

实际场景中，大多数分析需要同时使用两种模式：

Code

┌─────────────────────────────────────────┐
│           混合分析画布                    │
│                                          │
│  ┌──────────────────┐  实时数据          │
│  │ 当前在途订单数    │  ← Flink 实时      │
│  │     1,247        │                    │
│  └──────────────────┘                    │
│                                          │
│  ┌──────────────────┐  历史数据          │
│  │ 月度趋势对比      │  ← Iceberg 批量   │
│  │  █ █ █ █ █ █     │                    │
│  └──────────────────┘                    │
│                                          │
│  ┌──────────────────┐  混合             │
│  │ 异常检测          │  ← 实时值 vs      │
│  │ 当前： 1,247      │     历史均值       │
│  │ 均值： 980 +27%   │  ← Iceberg        │
│  └──────────────────┘                    │
└─────────────────────────────────────────┘

#五、Contour vs Tableau / PowerBI

对比维度	Palantir Contour	Tableau	Power BI
数据模型	Ontology（对象+关系）	表+关联	表+关联
用户门槛	选择对象即可分析	需理解数据模型	需理解数据模型
交叉过滤	基于 Ontology 关系自动联动	需手动配置	需手动配置
实时数据	原生支持	需额外配置	需额外配置
协作分析	实时多人协作	有限（服务器版）	有限（Power BI Service）
触发操作	分析中直接触发 Action	无	Power Automate（独立工具）
安全模型	行/列级 Ontology 权限	行级安全	行级安全
版本控制	内置	无	有限
数据血缘	完整（到数据源）	有限	有限
嵌入应用	Workshop 原生嵌入	Tableau Embedded	Power BI Embedded
价格	企业定制（很贵）	$70/用户/月起	$10/用户/月起

核心差异总结：

Code

Tableau/PowerBI：数据 → 可视化 → 人看 → 人做决定 → 人去别的系统操作
Contour：       数据 → Ontology → 分析 → 发现 → 直接触发 Action
                                              └─→ 闭环！

当然，Palantir Contour 的能力令人印象深刻，但企业定制的高昂价格让大多数组织望而却步。对于希望获得类似 Ontology 驱动分析能力的团队，开源方案（如 Coomia DIP）提供了一条更经济的路径。

#六、真实案例：制造业质量分析

#6.1 场景描述

某汽车零部件制造商需要实时监控产品质量，快速定位问题根因并采取措施。

#6.2 Contour 分析流程

Code

Step 1: 选择 Ontology 对象类型 → [QualityInspection]
Step 2: 添加分析板

┌──────────────────────────────────────────────────────┐
│ 分析画布： "Q3 产品质量分析"                            │
│                                                       │
│ 全局过滤： [日期： 2024-Q3] [工厂： 全部] [产品线： 全部]   │
│                                                       │
│ ┌────────────────┐  ┌──────────────────────────────┐ │
│ │ 不良率趋势      │  │ 不良类型分布                    │ │
│ │                 │  │                               │ │
│ │ 3.2%           │  │ 尺寸超差  ████████ 45%        │ │
│ │   ╲  2.8%      │  │ 表面缺陷  ████ 23%            │ │
│ │     ╲    3.1%  │  │ 材料异常  ███ 18%              │ │
│ │       ╲ /      │  │ 其他      ██ 14%               │ │
│ │    2.5%        │  │                               │ │
│ │  7  8  9  月   │  │                               │ │
│ └────────────────┘  └──────────────────────────────┘ │
│         │                        │                    │
│         │ 点击 9 月               │ 点击"尺寸超差"      │
│         ▼                        ▼                    │
│ ┌────────────────┐  ┌──────────────────────────────┐ │
│ │ 9月各产线不良率  │  │ 尺寸超差 → 关联设备分析         │ │
│ │                 │  │                               │ │
│ │ A线 1.2%       │  │ CNC-007  ████████ 12次        │ │
│ │ B线 4.8%       │  │ CNC-003  ██ 3次               │ │
│ │ C线 2.1%       │  │ CNC-012  █ 1次                │ │
│ │ D线 1.5%       │  │                               │ │
│ │                 │  │ → CNC-007 需要检修！            │ │
│ └────────────────┘  └──────────────────────────────┘ │
│                              │                        │
│                    ┌─────────▼──────────┐             │
│                    │ [Action] 创建维修工单│             │
│                    │ 设备： CNC-007       │             │
│                    │ 优先级： 高           │             │
│                    │ 指派： 设备科张工      │             │
│                    │ [提交]              │             │
│                    └────────────────────┘             │
└──────────────────────────────────────────────────────┘

从发现问题到创建维修工单，全程在 Contour 中完成。

#七、分析引擎的技术实现

#7.1 AnalyticsQueryService 架构

Code

┌──────────────────────────────────────────────────────┐
│              分析引擎架构                              │
│                                                       │
│  ┌─────────────┐  ┌──────────────┐  ┌──────────────┐ │
│  │前端分析组件  │  │API Gateway   │  │SDK Client    │ │
│  │(React)      │  │(REST)        │  │(Python)      │ │
│  └──────┬──────┘  └──────┬───────┘  └──────┬───────┘ │
│         │                │                  │         │
│         ▼                ▼                  ▼         │
│  ┌──────────────────────────────────────────────────┐ │
│  │         AnalyticsQueryService (gRPC)              │ │
│  │                                                   │ │
│  │  ┌────────────┐ ┌───────────┐ ┌───────────────┐  │ │
│  │  │聚合引擎     │ │时间分桶   │ │结果处理器      │  │ │
│  │  │(14 functions)│ │(Smart)   │ │(TopN, NullFill)│  │ │
│  │  └────────────┘ └───────────┘ └───────────────┘  │ │
│  │                                                   │ │
│  │  ┌────────────┐ ┌───────────┐ ┌───────────────┐  │ │
│  │  │查询优化器   │ │缓存层     │ │权限过滤器      │  │ │
│  │  │(Predicate  │ │(Redis)    │ │(Ontology-aware)│  │ │
│  │  │ Pushdown)  │ │           │ │                │  │ │
│  │  └────────────┘ └───────────┘ └───────────────┘  │ │
│  └──────────────────────┬───────────────────────────┘ │
│                         │                             │
│         ┌───────────────┼───────────────┐             │
│         ▼               ▼               ▼             │
│  ┌────────────┐ ┌──────────────┐ ┌──────────────┐    │
│  │Iceberg     │ │Doris         │ │实时数据源     │    │
│  │（历史数据）   │ │(OLAP加速）    │ │(Flink)       │    │
│  └────────────┘ └──────────────┘ └──────────────┘    │
└──────────────────────────────────────────────────────┘

#7.2 14 种聚合函数

Python

from ontology_sdk.analytics import AnalyticsQuery, AggregationType

# 支持的 14 种聚合函数
aggregation_types = {
    # 基础统计
    "COUNT":           "计数",
    "COUNT_DISTINCT":  "去重计数",
    "SUM":             "求和",
    "AVG":             "平均值",
    "MIN":             "最小值",
    "MAX":             "最大值",

    # 高级统计
    "MEDIAN":          "中位数",
    "PERCENTILE":      "百分位数（P50/P90/P99）",
    "STDDEV":          "标准差",
    "VARIANCE":        "方差",

    # 特殊聚合
    "FIRST":           "第一个值（按排序）",
    "LAST":            "最后一个值（按排序）",
    "LIST":            "收集为列表",
    "WEIGHTED_AVG":    "加权平均",
}

# 使用示例
query = (
    AnalyticsQuery("QualityInspection")
    .group_by("productLine")
    .aggregate("defectRate", AggregationType.AVG)
    .aggregate("defectRate", AggregationType.PERCENTILE, percentile=0.95)
    .aggregate("inspectionId", AggregationType.COUNT)
    .filter("inspectionDate >= '2024-07-01'")
    .order_by("AVG(defectRate)", descending=True)
    .limit(20)
)

result = analytics_client.execute(query)

#7.3 智能时间分桶（Smart Time Bucketing）

时间分桶不需要用户手动选择粒度——系统根据查询的时间范围自动选择最合适的粒度：

Python

# 智能分桶逻辑
time_range_to_bucket = {
    "< 1 天":     "5 分钟",    # 实时监控
    "1-7 天":     "1 小时",    # 近期趋势
    "1-4 周":     "1 天",      # 周报级别
    "1-6 月":     "1 周",      # 月报级别
    "6-24 月":    "1 月",      # 季报/年报
    "> 24 月":    "1 季度",    # 长期趋势
}

# 用户只需指定时间范围，系统自动选择分桶粒度
query = (
    AnalyticsQuery("SalesOrder")
    .time_series(
        field="orderDate",
        start="2024-01-01",
        end="2024-12-31",
        # 不需要指定 bucket_size，系统自动选择 "1 周"
        auto_bucket=True,
    )
    .aggregate("amount", AggregationType.SUM)
)

当然，用户也可以手动覆盖：

Python

query = (
    AnalyticsQuery("SalesOrder")
    .time_series(
        field="orderDate",
        start="2024-01-01",
        end="2024-12-31",
        bucket_size="1d",  # 手动指定每天
    )
    .aggregate("amount", AggregationType.SUM)
)

#7.4 TopN 与"其他"行

分析中经常需要"显示前 N 个，其余合并为其他"：

Python

query = (
    AnalyticsQuery("SalesOrder")
    .group_by("productCategory")
    .aggregate("amount", AggregationType.SUM)
    .top_n(
        n=5,
        by="SUM(amount)",
        others_label="其他",  # 第 6 名及以后合并为"其他"
    )
)

# 结果示例：
# ┌────────────────┬──────────────┐
# │ productCategory│ SUM(amount)  │
# ├────────────────┼──────────────┤
# │ 电子产品        │ 12,500,000  │
# │ 汽车零部件      │  8,700,000  │
# │ 工业设备        │  6,300,000  │
# │ 化工原料        │  4,100,000  │
# │ 包装材料        │  3,200,000  │
# │ 其他           │  9,800,000  │  ← 自动汇总
# └────────────────┴──────────────┘

#7.5 四种空值填充策略

时间序列数据中常有缺失值，提供 4 种填充策略：

Python

from ontology_sdk.analytics import NullFillStrategy

# 策略 1: 零值填充（适合计数和金额）
query.null_fill(NullFillStrategy.ZERO)

# 策略 2: 前值填充（适合库存量等状态值）
query.null_fill(NullFillStrategy.FORWARD_FILL)

# 策略 3: 线性插值（适合传感器数据等连续值）
query.null_fill(NullFillStrategy.LINEAR_INTERPOLATION)

# 策略 4: 保留空值（适合需要识别数据缺失的场景）
query.null_fill(NullFillStrategy.KEEP_NULL)

可视化效果对比：

Code

原始数据：     1  2  _  _  5  6  _  8

零值填充：     1  2  0  0  5  6  0  8
前值填充：     1  2  2  2  5  6  6  8
线性插值：     1  2  3  4  5  6  7  8
保留空值：     1  2  ·  ·  5  6  ·  8  （图表中断线）

#八、从分析到行动：Action-Enabled Analytics

这是 Contour 与所有传统 BI 工具的根本性差异。

#8.1 分析中的 Action 触发

Python

# 在分析结果上绑定 Action
from ontology_sdk.analytics import AnalyticsPanel
from ontology_sdk.actions import ActionBinding

panel = AnalyticsPanel(
    query=AnalyticsQuery("Supplier")
        .group_by("supplierId", "supplierName")
        .aggregate("lateDeliveryRate", AggregationType.AVG)
        .filter("AVG(lateDeliveryRate) > 0.2")
        .order_by("AVG(lateDeliveryRate)", descending=True),

    # 在分析结果的每一行上绑定 Action
    row_actions=[
        ActionBinding(
            action_type="SuspendSupplier",
            label="暂停供应商",
            parameter_mapping={
                "supplierId": "$row.supplierId",
                "reason": "交付准时率低于 80%",
            },
            precondition="$row.AVG(lateDeliveryRate) > 0.3",
        ),
        ActionBinding(
            action_type="CreateInvestigation",
            label="创建调查工单",
            parameter_mapping={
                "targetType": "Supplier",
                "targetId": "$row.supplierId",
                "category": "DELIVERY_PERFORMANCE",
            },
        ),
    ],

    # 在分析结果的选中集上绑定批量 Action
    batch_actions=[
        ActionBinding(
            action_type="BatchNotifySuppliers",
            label="批量发送警告邮件",
            parameter_mapping={
                "supplierIds": "$selected.supplierId",
                "template": "delivery_warning",
            },
        ),
    ],
)

#8.2 闭环分析流

Code

┌─────────┐    ┌─────────┐    ┌─────────┐    ┌─────────┐
│ 发现问题 │───→│ 分析根因 │───→│ 触发行动 │───→│ 验证效果 │
│ (Contour)│    │ （钻取）  │    │ (Action) │    │ (Contour)│
└─────────┘    └─────────┘    └─────────┘    └────┬────┘
                                                   │
     ┌─────────────────────────────────────────────┘
     │ 下一个分析周期
     ▼
┌─────────┐
│ 持续监控 │
│ （自动刷新）│
└─────────┘

#九、最佳实践

#9.1 分析设计原则

从业务问题出发：不要先想"用什么图"，先想"要回答什么问题"
渐进式深入：第一层给概览，第二层给分组，第三层给明细——让用户按需钻取
Action 前置：设计分析时就要想好"发现问题后要做什么"，把 Action 绑定上去
性能预算：每个分析板的查询时间控制在 3 秒以内，超过则预计算

#9.2 常见陷阱

陷阱	说明	解决方案
指标歧义	"收入"是含税还是不含税？	在 Ontology 中定义明确的语义
过度聚合	平均值掩盖了分布差异	同时展示中位数和 P90
时区混乱	UTC vs 本地时间不一致	在 Ontology 属性上标注时区
性能退化	全量扫描导致查询超时	用分区裁剪和预聚合

#Key Takeaways

Contour 不是另一个 BI 工具——它是 Ontology-aware 的分析平台。分析的起点是业务对象而非表，终点是 Action 而非报表。这使得"从数据到决策到行动"的闭环成为可能。
交叉过滤、对象导航、协作分析是 Contour 的三大体验差异。它们之所以成立，是因为底层有 Ontology 提供统一的语义层——没有 Ontology，这些功能无法实现。
核心分析能力可以通过开源技术栈实现——14 种聚合函数覆盖从基础统计到高级分析的需求，智能时间分桶减少用户决策负担，TopN + 空值填充处理了分析中最常见的两个痛点。

#想要 Palantir 级别的能力？试试 AIP

Palantir 的技术理念令人赞叹，但其高昂的价格和封闭的生态让大多数企业望而却步。Coomia DIP 基于相同的 Ontology 驱动理念，提供开源、透明、可私有化部署的数据智能平台。

AI 管线构建器：用自然语言描述，自动生成生产级数据管线
业务本体：像 Palantir 一样建模你的业务世界，但完全开放
决策智能：内置规则引擎和假设分析，数据驱动每一个决策
开放架构：基于 Flink、Doris、Kafka 等开源技术栈，零锁定

👉 立即免费试用 Coomia DIP↗ | 查看产品文档↗

Palantir Contour 深度解析：Ontology 驱动的企业级数据分析平台

#TL;DR

#引言：为什么数据分析工具还是不好用？

#一、Contour 的核心差异：Ontology-Aware 分析

#1.1 传统 BI vs Contour 的数据模型

#1.2 对象导航：沿着关系探索

#二、交叉过滤与钻取

#2.1 联动过滤（Cross-Filtering）

#2.2 多层钻取（Drill-Down）

#三、协作式分析

#3.1 实时多人协作

#3.2 分析即文档

#四、实时 vs 批量分析模式

#4.1 批量模式

#4.2 实时模式

#4.3 混合模式

#五、Contour vs Tableau / PowerBI

#六、真实案例：制造业质量分析

#6.1 场景描述

#6.2 Contour 分析流程

#七、分析引擎的技术实现

#7.1 AnalyticsQueryService 架构

#7.2 14 种聚合函数

#7.3 智能时间分桶（Smart Time Bucketing）

#7.4 TopN 与"其他"行

#7.5 四种空值填充策略

#八、从分析到行动：Action-Enabled Analytics

#8.1 分析中的 Action 触发

#8.2 闭环分析流

#九、最佳实践

#9.1 分析设计原则

#9.2 常见陷阱

#Key Takeaways

#想要 Palantir 级别的能力？试试 AIP

相关文章

为什么我们要做开源版 Palantir？Coomia DIP 的愿景与路线图

Palantir OSDK 深度解析：Ontology-first 开发范式如何重塑企业软件

Palantir 股价从 $6 到 $80：资本市场读懂了什么？