数据驱动的招聘：通过网络爬虫构建可扩展的人才智能平台

关键要点：

• 人才市场情报是一个企业特征问题，而不是人力问题。 驱动招聘策略、竞争基准和区域规划的信号存在于整体模式中——一家公司的职位发布数量、职能、城市以及速度——而不是在特定个体中。保持分析单位在公司和职位级别，整个流程就能保持合法。
• 公开招聘信号分散于四个表面。 公司职业网站和聚合器上的职位发布、企业网站上的招聘部分、专业目录中的企业特征条目以及雇主评价网站各自携带了部分信息。一个渲染模式汇集了这四者；一个标准化方案将它们连接起来。
• 招聘速度和补位是派生指标，而不是抓取字段。 你并不抓取“流失率”。你抓取职位发布日期和角色身份，随后在数据仓库中推导出速度（每周新需求）和补位压力（同一职位标题在同一家公司重新出现）。DOM提供了观察结果；数学提供了信号。
• 渲染调用是地理定位和会话预热的。 每个公共搜索页面在具有美国住宅出口的云浏览器中渲染，真正的JavaScript执行，以及预热的会话——先加载网站首页，然后加载目标搜索URL。管道发送一个URL加上国家，然后返回一个完全渲染的DOM。
• 个人数据设计上不被收集。 该管道收集职位名称、部门、地点、资历级别和发布数量——而不是姓名、联系方式或个人工作历史。下面的合规部分是使免责声明有效的合同。
• 免费开始。 新的Scrapeless账号包括免费的抓取浏览器运行时——在 app.scrapeless.com 注册。

介绍：从分散的职位发布到招聘市场信号

人才和竞争情报团队有一个反复出现的盲点。他们可以告诉你当前竞争对手雇佣了谁，大致上，但却无法告诉你那个竞争对手在构建什么——答案就明摆着在公共职业页面上。一个季度内发布十五个平台工程职位的公司在告诉市场它在哪里投资。一个在两个月内三次重新发布同一职位的公司在告诉市场它有一个补位问题。这些都是竞争信号，更新速度比任何分析报告都要快。

结构性挑战并非“抓取一个职位板”。而是跨越一篮公司、 hiring surfaces、区域的稳步扩展——以预定的时间表，以每次运行相同的准确性保证。公共职业页面是React和Next.js应用，职位列表在水合后渲染。聚合器按地区和IP声誉本地化结果。每个请求必须通过一个反机器人层，并返回一个全渲染的页面，而不是一个空壳。而且这些页面都离一个不小心的选择器就一小步之遥，触及姓名、电子邮件或个人资料——这些数据管道绝不能接触。

本指南将介绍一个基于 Scrapeless 抓取浏览器的人才市场情报管道的收集层的架构和Python代码。渲染使用经过验证的云浏览器连接：固定美国出口，在首页预热会话，然后加载公共职位搜索页面并提取职位发布。输出是一个归一化的公司和角色观察流馈送到数据仓库；输入是分析师定义的公司和来源数据篮。第一次阅读以了解模式；通过更改每个来源提取器重复使用。

你可以用它做什么

• 招聘速度基准。 跟踪一组竞争对手每周在每个职能和每个地区发布多少职位，并对加速和冻结招聘人数的公司进行排名。
• 职能混合分析。 一个公司将其发布组合从销售转向机器学习工程在传达战略转变。职位发布篮在发布声明之前就表明了这一转变。
• 地区扩展信号。 在新城市或国家首次出现职位发布是竞争对手正在打开市场的先导指标。地区标记使得信号在不同的运行间可比。
• 补位和重新发布检测。 同一职位标题在同一家公司重新出现的过程是角色级别上的补位压力信号——从发布身份和日期推导出来，而不是跟踪任何个体。
• 薪资范围智能。 在发布薪酬范围的帖子中（在美国一些州是强制性的），该工具为一个职能和地区建立了一个公共的角色级薪酬基准。
• 雇主情绪上下文。 来自公共雇主评审网站的汇总匿名评分分布，增加了对竞争对手招聘品牌趋势的需求侧理解。

为什么使用Scrapeless Scraping Browser进行人才情报

Scrapeless Scraping Browser是一个可定制的、反检测的云浏览器，专为网络爬虫和人工智能代理设计。对于专门的人才市场智能管道来说，它带来了：

• 195+个国家的住宅代理，每个会话都带有国家代码—退出地理位置是每个区域测量的一个字段。
• 云端JavaScript渲染。 现代职业页面和聚合器是单页面应用；列表网格在水合后加载。云浏览器返回后绘制的DOM，因此您的选择器可以在真实卡片上解析，而不是空壳。
• 会话预热内置于流程中。 首先在同一会话内加载网站首页可以建立公共搜索页面所期望的cookies和客户端状态，因此后续的目标加载返回一个干净的渲染。
• 反检测指纹信息由服务器处理。 用户代理、时区、WebGL和画布信号在云中按会话随机化—无需本地隐身插件维护，也无需在您的机器上安装浏览器二进制文件。
• 整个管道使用一个API密钥。 渲染和住宅出口的计费使用相同的Scrapeless账户；无需单独接入代理提供商。

在app.scrapeless.com上获得您的免费计划API密钥。

先决条件

• Python 3.10或更新版本
• 一个Scrapeless账户和API密钥—请在app.scrapeless.com注册
• pip install playwright lxml pyyaml cssselect以及一次性的playwright install chromium（本地Chromium仅使用协议；渲染在云中进行）
• 熟悉CSS选择器和基本的数据仓库目标（Snowflake、BigQuery、DuckDB或Postgres）
• 一个公司和来源的籃子文件

管道架构一览

basket.yaml                       (分析师定义：公司 × 来源 × 区域)
       │
       ▼
┌──────────────────┐
│   调度器       │  每个（公司、来源、区域）一个任务；边界泛化
└──────┬───────────┘
       │
       ▼
┌──────────────────┐
│   Scrapeless     │  connect_over_cdp → 预热首页 → 加载搜索URL
│  (云浏览器)      │  美国住宅出口、JS渲染、反检测
└──────┬───────────┘
       │  渲染的HTML
       ▼
┌──────────────────┐
│   标准化器      │  每个来源提取器 → 规范帖子架构
└──────┬───────────┘
       │
       ▼
postings.ndjson           (每行一个公共帖子观察)
       │
       ▼
数据仓库加载 + 产生速度 / 回填 / 职能组合 + 警报

每个阶段都是一个Python模块；下面的七个步骤从下到上构建它。

步骤1 — 连接到Scrapeless Scraping Browser

连接是一个单一的WebSocket URL。根据您的API密钥加上出口国家和会话生存时间来构建，然后交给Playwright的connect_over_cdp。这是经过验证的连接格式—不要替换其他端点：

import os
from urllib.parse import urlencode
from playwright.sync_api import sync_playwright

def scraping_browser_url(proxy_country="US", session_ttl=240):
    params = urlencode({
        "token": os.environ["SCRAPELESS_API_KEY"],
        "sessionTTL": session_ttl,
        "proxyCountry": proxy_country,
    })
    return f"wss://browser.scrapeless.com/api/v2/browser?{params}"

proxyCountry="US"将住宅出口固定在美国，因此每个记录的发布都是从相同的角度测量的—跨运行混合出口区域产生的发布历史没有任何意义。sessionTTL=240使云会话保持活跃四分钟，这足够用于预热首页，然后在同一会话中加载分页搜索页面。

步骤2 — 渲染公共的求职页面（先预热会话）

负载详细信息：首先在同一会话内加载网站的首页**，然后再导航到目标搜索URL**。预热建立了公共搜索页面所期望的客户端状态，因此目标页面完全加载，而不是半水合的壳：

from playwright.sync_api import sync_playwright

def render_search_page(homepage_url: str, search_url: str,
                       proxy_country: str = "US") -> str:
    """预热首页，然后在云端渲染公共求职页面。"""
```python
with sync_playwright() as p:
        browser = p.chromium.connect_over_cdp(
            scraping_browser_url(proxy_country=proxy_country)
        )
        context = browser.contexts[0] if browser.contexts else browser.new_context()
        page = context.pages[0] if context.pages else context.new_page()

        # 1) 首先在主页上预热会话。
        page.goto(homepage_url, wait_until="domcontentloaded", timeout=60_000)
        page.wait_for_timeout(1_500)

        # 2) 现在加载目标公共搜索页面；网格在水合后绘制。
        page.goto(search_url, wait_until="networkidle", timeout=60_000)
        page.wait_for_selector("[data-posting], article, li", timeout=20_000)

        html = page.content()
        browser.close()
        return html

wait_until="networkidle" 让列表网格在 page.content() 快照 DOM 之前完成绘制。 wait_for_selector 会阻止直到至少存在一个发布容器，因此第 4 步中的提取器永远不会在空页面上运行。将您在篮子中定义区域时使用的相同 proxy_country 固定，以便呈现的结果反映本地求职者实际看到的内容。

第 3 步 — 定义公司和来源篮子

情报团队拥有这个文件。保持其无聊 - 公司、每个公司的公共招聘表面以供阅读，以及测量的区域。每个（公司，来源，区域）条目都有一个主页用于预热和一个公共搜索 URL 进行渲染：

# basket.yaml
regions:
  - US

companies:
  - company: target_company_a
    sources:
      - source: company_careers
        homepage: "https://careers.example-company-a.com/"
        search:
          US: "https://careers.example-company-a.com/jobs?country=US"
      - source: public_aggregator
        homepage: "https://jobs.example-aggregator.com/"
        search:
          US: "https://jobs.example-aggregator.com/search?q=engineering&loc=US"
  - company: target_company_b
    sources:
      - source: company_careers
        homepage: "https://careers.example-company-b.com/"
        search:
          US: "https://careers.example-company-b.com/openings"

为每个来源使用公共 HTML 搜索页面，而不是站点在其 robots 文件中保留的内部查询端点。一个跟踪数十家公司的篮子恰好以这种形状存在；仓库在 company 上连接，以对齐跨来源和区域的招聘信号。

第 4 步 — 提取到规范的发布架构中

每个来源的 DOM 是不同的；仓库表不是。提取器将每个来源呈现的内容无论如何转换为相同的形状。该架构明确是公司信息 - 公司、角色、地点、职能、 seniority、发布日期和稳定的发布标识符。没有名称字段，没有联系字段，也没有个人任职字段，且永远不会有：

from dataclasses import dataclass, asdict
from datetime import datetime, timezone
from typing import Optional
from lxml import html as lxml_html

@dataclass
class PostingRecord:
    company: str
    source: str
    region: str
    posting_id: str                 # 每个来源的稳定 ID 或 title+location 的哈希
    role_title: str
    function: Optional[str]          # "engineering" | "sales" | "ops" | ...
    seniority: Optional[str]         # "junior" | "mid" | "senior" | "staff" | None
    location: Optional[str]          # 城市 / 地区 / "remote"
    posted_date: Optional[str]       # 页面渲染的 ISO 日期字符串，或 None
    salary_band: Optional[str]       # 页面发布的公共薪酬范围
    captured_at: str                 # ISO-8601 UTC，读取时写入

每个来源的提取器插入相同的返回类型。这个示例读取一个通用卡片网格；根据来源交换选择器：

def extract_company_careers(html: str, company: str, source: str,
                            region: str) -> list[PostingRecord]:
    doc = lxml_html.fromstring(html)
    records: list[PostingRecord] = []

    for card in doc.cssselect("[data-posting], article.job-card"):
        title_el = card.cssselect(".job-title, h3")
        loc_el = card.cssselect(".job-location, [data-location]")
        date_el = card.cssselect("time, [data-posted]")
        pay_el = card.cssselect(".salary, [data-comp]")

        title = title_el[0].text_content().strip() if title_el else ""
        if not title:
            continue  # 跳过非发布卡片；缺少标题意味着不是一个真实的列表

        location = loc_el[0].text_content().strip() if loc_el else None
        posted = (date_el[0].get("datetime") or date_el[0].text_content().strip()) if date_el else None

        records.append(PostingRecord(
            company=company,
            source=source,
            region=region,
            posting_id=_posting_id(card, title, location),
            role_title=title,
            function=_classify_function(title),
            seniority=_classify_seniority(title),

位置=位置,
发布时间=已发布,
薪资范围=薪酬元素[0].文本内容().剥离() 如果 薪酬元素 否则 None,
捕获时间=现在(时区.utc).iso格式(),
))
返回 记录

分类助手将派生保持在提取器中，而不是 DOM。它们将角色标题映射到粗略功能和资历等级 — 不涉及个别数据：

```python
import hashlib

_FUNCTION_KEYWORDS = {
    "工程": ("工程师", "开发者", "SRE", "平台", "机器学习", "数据"),
    "销售": ("销售", "客户执行", "客户经理", "销售开发代表"),
    "市场营销": ("市场营销", "增长", "品牌", "内容"),
    "运营": ("运营", "供应", "物流", "支持"),
}
_SENIORITY_KEYWORDS = {
    "员工": ("员工", "首席", "杰出"),
    "高级": ("高级", "资深", "领导"),
    "初级": ("初级", "初", "实习生", "入门"),
}

def _classify(title: str, table: dict) -> Optional[str]:
    低 = title.lower()
    对于标签，kws 在表.items()中：
        如果 任何(kw 在 低 对于 kw 在 kws):
            返回 标签
    返回 None

def _classify_function(title: str) -> Optional[str]:
    返回 _classify(title, _FUNCTION_KEYWORDS)

def _classify_seniority(title: str) -> Optional[str]:
    返回 _classify(title, _SENIORITY_KEYWORDS) 或 "中级"

def _posting_id(card, title: str, location: str | None) -> str:
    本地 = card.get("data-posting-id") 或 card.get("id")
    如果 本地:
        返回 本地.strip()
    # 标题 + 位置的稳定哈希标识在多次运行中重新发布的角色。
    基础 = f"{title}|{location or ''}".lower().encode("utf-8")
    返回 hashlib.sha1(基础).hexdigest()[:16]

选择器设计注意事项：

• 优先使用 [data-posting] / data-* 属性当源提供这些属性时。 它们可以在外观类名称旋转中生存；像 .text-lg.font-semibold 这样的类在每次发布时都可能会改变。
• 将缺失字段视为可为空。 发布没有发布的 posted_date 或 salary_band 仍然是一个有效的观察结果 — 存储 None 然后继续。
• 确定性地派生 posting_id。 标题 + 位置的哈希使仓库能够识别同一角色在多次运行中重新出现 — 成为反填检测的基础 — 而无需识别个人。

获取您的免费计划 API 密钥: app.scrapeless.com

第 5 步 — 遍历篮子

每个（公司，来源，地区）条目都是一个独立的呈现。预热然后加载的运行在每个条目内的一个会话中，因此篮子遍历是一个简单的循环（或用于并行的有限线程池，每个主机最多三个工作线程）：

import yaml

def load_basket(path: str = "basket.yaml") -> dict:
    with open(path, encoding="utf-8") as f:
        return yaml.safe_load(f)

def walk_basket(basket: dict):
    """为每个 (公司, 来源, 区域) 条目生成 PostingRecord 列表。"""
    对于篮子中的项目["公司"]：
        对于源中的项目["sources"]：
            对于区域，搜索网址 在 src["search"].items():
                html = render_search_page(
                    homepage_url=src["homepage"],
                    search_url=search_url,
                    proxy_country=区域,
                )
                yield extract_company_careers(
                    html, item["company"], src["source"], 区域
                )

对于较大的篮子，将 render_search_page 包装在 concurrent.futures.ThreadPoolExecutor 中，并将工作线程数保持在每个主机三以下。每个条目预热并加载自己的会话，因此通过添加工作线程来扩大并行性 — 没有共享会话可以争用。

第 6 步 — 流写入 NDJSON 以供仓库加载

流写入 NDJSON，这样管道在运行中断时仍能存活，而不会丢失记录。每一行都是一次公共发布观察；文件是追加式的：

import json
from pathlib import Path

def append_records(records: list[PostingRecord], out_path: str = "postings.ndjson"):
    Path(out_path).parent.mkdir(parents=True, exist_ok=True)
    with open(out_path, "a", encoding="utf-8") as f:
        for r in records:
            f.write(json.dumps(asdict(r)) + "\n")

NDJSON 直接加载到 Snowflake（COPY INTO ... FILE_FORMAT = (TYPE = JSON)）、BigQuery（bq load --source_format=NEWLINE_DELIMITED_JSON）、Redshift、ClickHouse 和 DuckDB。选择 BI 堆栈已使用的任何一个；模式是相同的。

第 7 步 — 在仓库中派生评分模型

情报团队所采取的信号不是原始发布 — 它们是派生指标。招聘速度、功能组合和反填压力都存在于仓库中，从发布时间和身份随时间计算得出，而不是在抓取器中：

-- 招聘速度：过去 7 天与之前 7 天的公司每个功能的新发布
WITH obs AS (
  SELECT company, function, posting_id,

CAST(posted_date AS DATE) AS posted_date,
CAST(captured_at AS DATE) AS captured_date
FROM talent_postings
WHERE posted_date IS NOT NULL
),
windowed AS (
SELECT company, function,
COUNT(DISTINCT CASE WHEN posted_date >= CURRENT_DATE - 7 THEN posting_id END) AS reqs_last_7,
COUNT(DISTINCT CASE WHEN posted_date >= CURRENT_DATE - 14
AND posted_date < CURRENT_DATE - 7 THEN posting_id END) AS reqs_prior_7
FROM obs
GROUP BY company, function
)
SELECT company, function, reqs_last_7, reqs_prior_7,
reqs_last_7 - reqs_prior_7 AS velocity_delta
FROM windowed
ORDER BY velocity_delta DESC;

补充压力是指 `posting_id` 在公司停止显示后再次出现 — 一种基于角色的信号，纯粹来自于职位标识和日期：

```sql
-- 补充信号：一个职位在同一公司消失后再次出现
SELECT company, posting_id, role_title,
       COUNT(*)                       AS times_observed,
       MIN(CAST(captured_at AS DATE)) AS first_seen,
       MAX(CAST(captured_at AS DATE)) AS last_seen
FROM talent_postings
GROUP BY company, posting_id, role_title
HAVING MAX(CAST(captured_at AS DATE)) - MIN(CAST(captured_at AS DATE)) > 21
   AND COUNT(DISTINCT CAST(captured_at AS DATE)) >= 2
ORDER BY company, times_observed DESC;

将衍生行路由到需要它们的消费者：

• 速度差超过阈值 → 竞争招聘警报发送给战略团队。
• 新职能或新城市出现 → 市场扩展通知发送给企业发展部门。
• 单一角色的高补充计数 → 人才获取信号，表明竞争对手存在可以利用的留存差距。

衍生查询是收集和决策之间的契约。只要职位架构保持稳定，下游的评分模型、警报和仪表板在源旋转DOM时不会改变 — 只有步骤4中的每个源提取器会改变。

您将获得的回报

每个公共发布观察的一个NDJSON行，格式如下：

{
  "company": "target_company_a",
  "source": "company_careers",
  "region": "US",
  "posting_id": "a1b2c3d4e5f60718",
  "role_title": "高级平台工程师",
  "function": "工程",
  "seniority": "高级",
  "location": "奥斯丁，德克萨斯州",
  "posted_date": "<源呈现的ISO日期，或null>",
  "salary_band": "$180k–$220k",
  "captured_at": "<读取时间的ISO-8601 UTC时间戳>"
}

从运行模式中得来的真实观察：

• 热身会话使网格解析。 冷加载的目标搜索URL通常返回半hydrated的外壳；在同一会话中首先加载主页，然后加载搜索页面，返回提取器所需的绘制卡片网格。
• 渲染时机比选择器特异性更重要。 在 networkidle 之前运行的选择器返回空列表。在职位容器上使用 wait_for_selector 是使提取器变得可预测的关键。
• posting_id 稳定性是承重字段。 当源暴露本地id时，使用它；如果没有，标题加位置哈希是跨运行连接重新发布角色并驱动补充查询的关键。
• 发布日期在不同源间不一致。 有些呈现ISO datetime属性，有些呈现相对字符串（“3天前”），有些没有。存储页面提供的内容，并在仓库层中规范相对字符串。
• 保持架构为公司特征。 每个源的DOM各异；职位架构保持不变 — 并且构造上不包含任何个人数据。将变异性推入提取器函数；保持架构平坦并无个人身份信息。

合规：这是一个公司特征数据管道，而不是个人数据管道

这是使免责声明真实而非装饰性的部分。人才智能与个人数据相邻，因此必须在设计中划定界限，而不是事后修补。

• 不收集任何个人数据。 架构包含公司、职位名称、职能、资历层级、地点、发布日期和公开薪资范围。它不包含姓名、电子邮件地址、电话号码、个人资料或任何人的工作历史。提取器没有相关字段，因此不会泄漏到仓库中。
• 分析单位是公司和角色，绝不是个人。 “离职信号”在这里意味着基于角色的补充模式 — 同一个职位再次出现于公司 — 而不是跟踪任何人离开工作的情况。“招聘速度”是公共职位的数量随时间变化的计数，而不是名单。
• 合法基础和地区法律。 从公共页面获取的聚合公司招聘数据一般不属于最敏感的个人数据类别，但GDPR、CCPA和同类法律仍然适用于任何可能识别个人的信息。我们保留数据集的公司特征，以确保合法基础简单明了；对于任何扩大范围的情况，首先与法律顾问确认法律基础。
• 尊重网站条款和爬虫指令。 渲染网站为访客发布的公共HTML搜索页面；不要针对网站在其爬虫文件中保留的内部查询端点，并遵循爬虫延迟指导。
• 公共雇主评价数据保持聚合。 当评价网站提供情感背景时，收集分布级别的评分 — 绝不收集个别评论者的身份或与个人关联的评论文本。

对于同样的数据收集原理的代理驱动框架，AI代理使用案例指南 展示了一个基于相同Scraping Browser工具构建的求职代理。

结论：扩大您的人才市场情报管道

该管道简化为六个步骤：定义公司和来源篮子 → 连接到云浏览器并预热会话 → 渲染每个公共搜索页面并固定美国出口 → 提取到公司特征发布架构 → 流式传输到NDJSON → 在数据仓库中推导速度、职能混合和补充。每一步都足够小，可以阅读；该组成部分在单一天的时间表上处理多个招聘表面上的数十家公司。

固定美国出口，在同一会话内在目标搜索页面之前预热主页，按照渲染 → 提取模式操作，将缺失字段视为可为空，并保持每个字段的公司特征 —— 公司和角色，绝不涉及个人。

准备构建您的AI驱动数据管道了吗？

加入我们的社区以索取免费计划，并与构建人才和竞争情报管道的开发者联系：Discord · Telegram。

在 app.scrapeless.com 注册以获取免费的Scraping Browser运行时，并将上述模式调整为管道所需的公司、招聘表面和区域。定价详情请见 scrapeless.com/en/pricing；Scraping Browser产品页面位于 scrapeless.com/en/product/scraping-browser；完整的连接和代理参考请见 docs.scrapeless.com。

常见问题

问：收集人才市场情报合法吗？个人数据呢？

合法性完全取决于您收集的内容。该管道从公共页面收集公司特征和角色级别的数据 — 职位名称、职能、地点、发布数量、公开薪资范围 — 并故意不收集任何个人数据：没有名字，没有联系方式，没有个人就业历史。公开可见的数据通常是可获取的，但GDPR、CCPA和同类法律仍适用于任何可能识别个人的信息，并且在整个过程中都适用网站服务条款。保持架构的公司特征是确保合法基础简单明了的关键；在扩大范围之前请咨询法律顾问。

问：我需要代理吗？我应该固定哪个国家？

是的。聚合器和职业页面通过地区和IP声誉本地化结果，因此将出口国家固定为您通过proxyCountry在连接URL中测量的区域。对区域限制页面的美国出口请求可能会返回回退或地理封锁。Scrapeless在195多个国家的住宅代理覆盖了典型的篮子，而无需将单独的代理提供商引入堆栈。

问：搜索页面渲染为空或显示访问挑战 - 我该如何获得干净的渲染？

固定美国住宅出口并在目标加载之前预热会话：首先在同一云浏览器会话内导航到网站的主页，让其稳定，然后导航到公共搜索 URL，并等待networkidle和发布容器选择器。预热建立了搜索页面预期的客户端状态，因此网格完全绘制，而不是返回半重水合的外壳。

问：当源旋转其DOM时，会发生什么？
只有第4步中的每个源提取器发生了变化。规范的发布模式、仓库表、派生查询和警报规则都没有受到影响。当一个源发布版本时，请重新检查并收紧您的选择器；当可用时，优先使用data-*属性；将提取器视为易变层，将模式视为稳定层。

问：我如何在不跟踪个人的情况下得出招聘速度和补充需求？

这两个指标来自发布日期和稳定的posting_id，而不是来自个人。速度是指每个公司每个职能在一定时间窗口内打开的独立发布数量。补充压力是相同的posting_id在多次运行中为公司重新出现。数学运算在仓库中运行（第7步），基于公司特征观察 - 从未识别或跟踪任何个人。

问：我可以并行运行多个公司和源吗？

可以。每个（公司，源，地区）条目都会暖启动并渲染自己的会话，因此调度器将任务分配到线程池中。每个主机上的工作线程数量保持在三以下，以确保分配保持礼貌；并行性通过增加工作线程来扩展，而不是通过共享会话。

问：管道应该多久运行一次？

每天是招聘速度跟踪的规范节奏，因为发布以多天的节奏变更。对于较慢的功能组合和扩展信号，每周一次是可以的。第7步中的派生窗口假设每日捕获；将调度与决策层实际消费的最快信号对齐。