跳转至

Shadow Octopus Operations

Octopus is operated through CLI commands and the source registry scheduler.

It does not run as a public API service. Its durable output is the source-local raw contract under the Octopus lakehouse root.

Configuration

Local example:

data_root = "data/octopus"
sources_dir = "sources"
request_timeout = 30
verify_tls = true

Production convention:

data_root = "/dev/data1/shadow-lakehouse/octopus"
sources_dir = "sources"
request_timeout = 30
verify_tls = true

On the server, use:

export SHADOW_OCTOPUS_CONFIG=/dev/data1/shadow-octopus/config.prod.toml

Scheduler

Run the scheduler locally:

uv run shadow-octopus --config config.example.toml run-scheduler \
  --max-workers 4

Run one due cycle for selected sources:

uv run shadow-octopus --config config.example.toml run-scheduler \
  --source cls_telegraph \
  --source eastmoney_7x24 \
  --max-workers 2 \
  --once

Production wrapper:

scripts/run_scheduler.sh --max-workers 4

The wrapper keeps a scheduler-level lock and writes scheduler/task logs under the ops directory. Each worker writes to only one source workspace.

Status And Verification

Check one source:

uv run shadow-octopus --config config.example.toml source-status \
  --source cninfo_announcements

Check initialized sources:

uv run shadow-octopus --config config.example.toml root-status

Verify a source before Lighthouse ingest:

uv run shadow-octopus --config config.example.toml verify-source \
  --source cninfo_announcements \
  --require-data

Status output includes raw record counts, manifest counts, pending/resolved/failed object counts, object bytes, latest file mtimes, latest checkpoint, and recent run records.

CNInfo Operating Path

Refresh the recent history window:

uv run shadow-octopus --config config.example.toml refresh-cninfo-latest \
  --source cninfo_announcements \
  --stream a_share_all \
  --window-days 14 \
  --pages-per-day 5

Backfill historical announcements:

uv run shadow-octopus --config config.example.toml backfill-cninfo-history \
  --source cninfo_announcements \
  --stream a_share_all \
  --start-date 2000-01-01 \
  --max-pages 10

Rebuild the source-local object queue when needed:

uv run shadow-octopus --config config.example.toml rebuild-object-download-queue \
  --source cninfo_announcements

Download a bounded object batch:

uv run shadow-octopus --config config.example.toml download-objects \
  --source cninfo_announcements \
  --limit 200

The downloader selects ready rows from state.db first. It can fall back to manifest scanning when the queue has not been built.

Live News Operating Path

Latest sync commands:

uv run shadow-octopus --config config.example.toml sync-cls-telegraph --source cls_telegraph --count 20 --pages 1
uv run shadow-octopus --config config.example.toml sync-sina7x24 --source sina7x24 --count 100 --pages 1
uv run shadow-octopus --config config.example.toml sync-eastmoney-7x24 --source eastmoney_7x24 --count 50 --pages 5
uv run shadow-octopus --config config.example.toml sync-stcn-kuaixun --source stcn_kuaixun --count 50 --pages 5
uv run shadow-octopus --config config.example.toml sync-jin10-qh-flash --source jin10_qh_flash --count 50 --pages 2

Backfill commands:

uv run shadow-octopus --config config.example.toml backfill-sina7x24 --source sina7x24 --pages 100
uv run shadow-octopus --config config.example.toml backfill-eastmoney-7x24 --source eastmoney_7x24 --pages 20
uv run shadow-octopus --config config.example.toml backfill-stcn-kuaixun --source stcn_kuaixun --pages 40
uv run shadow-octopus --config config.example.toml backfill-jin10-qh-flash --source jin10_qh_flash --pages 20

When a cursor is omitted, backfill commands derive the oldest local cursor from partitioned raw records where the source supports it.

Gangtise Operating Path

Metadata sync:

export GANGTISE_OPENAPI_TOKEN='...'

uv run shadow-octopus --config config.example.toml sync-gangtise-foreign-reports \
  --source gangtise_foreign_reports \
  --size 50 \
  --pages 1

Materialize one requested PDF:

uv run shadow-octopus --config config.example.toml materialize-gangtise-report-pdf \
  --source gangtise_foreign_reports \
  --source-record-id gangtise_report:454901220168568832

Gangtise can be operated metadata-first. Lighthouse exposes PDF download request/status APIs; Octopus performs the actual object materialization and writes objects-resolved.jsonl.

Upload And Extract Lakehouse Data

Upload local raw data as shard archives:

scripts/upload_lakehouse_to_remote.sh

Extract on the server after checksum verification:

ssh aliyun 'SHADOW_REMOTE_ZSTD_BIN=/dev/data1/bin/zstd \
  /dev/data1/shadow-octopus/scripts/extract_lakehouse_shards_remote.sh \
  /dev/data1/shadow-lakehouse/.staging/<batch>'

The extractor verifies shard checksums and zstd frames before moving source directories into:

/dev/data1/shadow-lakehouse/octopus

Handoff To Lighthouse

After Octopus writes or migrates raw data, Lighthouse ingests from:

/dev/data1/shadow-lakehouse/octopus/<source>

and writes read-side indexes under:

/dev/data1/shadow-lakehouse/lighthouse/<source>

Keep this handoff one-way: Octopus writes raw data, Lighthouse reads raw data and serves queries.