What the data for this category looks like
Data related to airport aviation revenue yield comes from two categories: public industry data sources and internal airport operational data sources. Public sources include industry operation daily reports released by civil aviation regional administrations, and official operation announcements disclosed by airports. Internal sources come from raw transaction data exported from airport flight scheduling systems and charge settlement systems.
Full data collection for the previous day is completed every early morning, with a maximum delay of 12 hours. Documents use structured CSV or JSON format. Each row corresponds to data for a single airport on a single day. Fields include date, airport ICAO code, daily takeoff and landing count, daily passenger throughput, daily core aviation revenue, daily non-aeronautical revenue, daily total revenue, and more. All fields are non-nested.
The date field uses the YYYY-MM-DD format. Airport codes are letter combinations. The unit for takeoff and landing count is sorties. The unit for passenger throughput is passenger trips. Revenue-related fields use currency units.
What constraints do these characteristics impose during deployment and upgrade
Dual data source access requirements require configuring multiple sets of permission verification rules during deployment. These rules must adapt to public API key verification and internal database connection authorization respectively.
Fixed daily update rhythm requires scheduled task trigger times to match the regular release timeline of daily reports. This avoids triggering too early before data collection is complete, or too late to miss the broadcast window.
Structured fixed fields require configuring strict field mapping rules during parsing. This prevents data misalignment caused by differing field names across data sources.
Data compliance requirements require setting numerical verification rules for core fields. This filters invalid data and ensures the accuracy of broadcast content.
During the upgrade phase, it is necessary to support differences in data source fields across regional airports, and allow dynamic adjustment of field mapping configurations.
How to set the configurations
| Configuration Item | Recommended Value | Rationale |
|---|---|---|
DATA_SOURCE_TYPE | ["public_api", "internal_db"] | Supports dual data source access, covers mixed collection requirements for public industry data verification and internal business data |
SCHEDULE_CRON_EXPR | 0 0 6 * * * | Triggers collection and processing of the previous day's data at 6 AM daily, matches the regular release timeline of daily reports |
PARSE_STRICT_MODE | true | Enables strict parsing mode to ensure no misalignment in field mapping for structured data, prevents incorrect parsing of core business fields |
MAX_RETRY_TIMES | 3 | Retries 3 times when a single data source collection fails, balances data acquisition success rate and system resource usage |
DATA_VALIDATION_RULES | Flight Sorties: int>0, Passenger Throughput: int>0, Total Revenue: float>=0 | Sets numerical verification rules for core fields, filters invalid data and ensures the accuracy of broadcast content |
WORKFLOW_CODE_TIMEOUT | 600 seconds | Sets the code running component timeout to 600 seconds, adapts to the format verification and conversion time requirements for bulk airport data |
UPLOAD_FILE_MAX_SIZE | 1000 MB | Adapts to the upload requirements for bulk structured data files, prevents large file upload failures |
The parameter values provided on this page are common starting points for configuration. Actual values are affected by material format, data volume and business rules. Specific issues require individual analysis. It is recommended to test on your own samples before finalizing settings.
Three common mistakes
- Code running components in the workflow throw errors indicating timeout or execution failure, even if the code logic is simple. Cause: The
WORKFLOW_CODE_TIMEOUTparameter is not adjusted. The default timeout period is too short to complete format verification and conversion for bulk airport data. - Data source collection failure rate is too high. Logs show
403 Forbiddenstatus codes. Cause: API access keys for public data sources are not configured, or internal database connection string permissions are insufficient. This prevents access to airport operation data. - Broadcast content contains empty fields, such as missing unit passenger revenue fields. Cause:
PARSE_STRICT_MODEis not enabled,DATA_VALIDATION_RULESare not set, and invalid data from field mapping misalignment is not filtered.
How to confirm the configuration is correct
- Manually trigger a data collection task. Check if the collected airport data includes preset core fields, and verify that field mapping matches the configured settings.
- Check scheduled task logs. Confirm that the daily trigger time matches the configured
SCHEDULE_CRON_EXPR, and there are no abnormal error records. - Simulate input of invalid data, such as negative takeoff and landing count values. Check if the system triggers data verification alerts, confirming that the verification rules are active.
- Upload a structured data file that meets the format requirements. Confirm that the upload proceeds normally, no size limit alerts appear, and parsed field data is complete and accurate.
Question material comes from public community discussions. Configuration values are common starting points and should be measured against your own samples. Verified on 2026-09-14.