Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow peerDownload config for minion-tasks #12458

Open
tibrewalpratik17 opened this issue Feb 21, 2024 · 3 comments · May be fixed by #12960
Open

Allow peerDownload config for minion-tasks #12458

tibrewalpratik17 opened this issue Feb 21, 2024 · 3 comments · May be fixed by #12960
Assignees

Comments

@tibrewalpratik17
Copy link
Contributor

tibrewalpratik17 commented Feb 21, 2024

Currently, minion-jobs always use zkMetadata downloadURI to download segments from deepstore.

I want to get community's opinion on adding a new optional task-level config allowPeerDownload to allow minion-task during execution to try downloading segment from a server-peer directly once deepstore-retries fails. Currently, the job fails and does not move forward. This also creates a situation of head-of-line-blocking queue for subsequent task-runs if tableMaxNumTasks is specified.

PS: this issue specifically discusses the situation where the zkMetadata has deepstore URI available and is not "" (empty).
There can be multiple reasons for deepstore URI download failures:

  • Issues with deepstore connection / timeouts
  • The segment-deepstore-copy getting TTL'ed from deepstore due to other non-Pinot frameworks (we are seeing this for some of our clusters).

For example, we have an upsert-compaction task enabled for a table with following configs:

"task": {
      "taskTypeConfigsMap": {
        "UpsertCompactionTask": {
          "invalidRecordsThresholdPercent": "30",
          "bufferTimePeriod": "0d",
          "schedule": "0 */5 * * * ?",
          "tableMaxNumTasks": "5"
        }
      }
    },

The table has data for more than 60days. There was a TTL enforced on the deepstore-path for 7days.

The following graph shows that there was a drop in row-count (in red circle) when UpsertCompaction first kicked off (at that time I had removed "tableMaxNumTasks": "5" config). But once I added that config there is no task getting executed (not even for newer segments) because it is getting blocked by FileNotFoundException while downloading from deep-store for older segments.

Screenshot 2024-02-21 at 3 34 40 PM

The table has huge potential for cost-savings in terms of compaction and it seems we can use peerDownload to unblock the task.

Another parallel discussion:
There is a framework which periodically checks if zkMetadata URI is empty then upload the jar to deepstore but there is no framework which checks if the path pointed out by zkMetadata URI is actually present or not.

@Jackie-Jiang
Copy link
Contributor

I'm good with the proposal. Maybe renaming to allowDownloadFromServer

@tibrewalpratik17
Copy link
Contributor Author

Please assign to me. Thanks!

@Jackie-Jiang
Copy link
Contributor

cc @snleee @swaminathanmanish

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants