Extracting data sounds straightforward, but in practice, things don't always go perfectly. You're connecting to systems outside your direct control, dealing with networks, and reading data formats that might change. It's almost inevitable that you'll encounter issues during the extraction phase. Planning for these potential problems is a significant part of building a reliable ETL process.

Think about what could go wrong when you try to grab data from a source like a database, a file server, or an API:

The Source is Unavailable: The database server might be down for maintenance, the network connection could be temporarily lost, or the file server might be offline.
Incorrect Credentials or Permissions: You might be using the wrong username/password, or the account your ETL process uses might not have the necessary permissions to read the specific data you need.
Data Format Unexpectedly Changes: Imagine you expect a CSV file with five columns, but today it arrives with six, or a column name changes. Or perhaps a field in a JSON response is missing or has a different data type than anticipated. This is sometimes called "schema drift."
Data is Missing or Corrupt: The source file might be empty, incomplete, or contain corrupted data that cannot be read correctly.
Timeouts: The source system might be slow to respond, causing your extraction process to give up after waiting too long.
Resource Limits: Some sources, especially APIs, might limit how much data you can request or how frequently you can ask for it (rate limiting). Exceeding these limits can cause errors.

Ignoring these potential issues means your ETL pipeline will be brittle; it might fail unexpectedly, leading to incomplete or outdated data in your target system. Let's look at some basic strategies to handle these situations gracefully.

Logging: Your First Line of Defense

The absolute minimum you should do is log what happens during extraction. Logging means recording information about the process execution into a file or a dedicated logging system.

What to Log: At a minimum, log when an extraction starts, when it finishes successfully, and especially when it fails. If an error occurs, log the details: what went wrong, which source was involved, and any error messages received.
Why Log: Logs provide a history of what happened. When an extraction fails overnight, logs are often the only way to diagnose the problem. They help you understand if errors are temporary glitches or persistent problems needing investigation.

Good logging tells you that something went wrong; the next step is deciding what to do about it.

Retrying Failed Attempts

Some errors are temporary. A brief network hiccup or a database server restarting might cause an extraction to fail, but trying again a few moments later might succeed. This leads to the strategy of retrying the operation.

Simple Retry: The most basic approach is to simply try the extraction again immediately if it fails. This works for very short-lived issues.
Retry with Delay: Often, it's better to wait a short period before retrying. If the source system is temporarily overloaded, retrying immediately might just add to the problem. Waiting gives the system time to recover.
Exponential Backoff (A Smarter Delay): A common technique is to increase the delay between retries. For instance, wait 5 seconds after the first failure, then 10 seconds after the second, then 20 seconds, and so on. This "backs off" gracefully if the source system is struggling. You'd typically set a maximum number of retries to avoid trying forever.

Retries are particularly effective for connection issues and timeouts. They won't help with problems like incorrect permissions or fundamentally broken data formats.

Alerting on Failures

If an extraction fails repeatedly, even after retries, someone needs to know about it so they can investigate. This is where alerting or notifications come in.

How: This could be as simple as sending an email or a message to a chat system (like Slack) when a critical extraction fails and cannot recover automatically.
When: You typically alert after exhausting retries or for errors that retries can't fix (like authentication failures).

Alerts ensure that persistent problems don't go unnoticed.

Deciding What to Do with Bad Data (Skip vs. Fail)

Sometimes, the connection works, but there's an issue with specific records or files. For example, one row in a large CSV file might have badly formatted data. You have a choice:

Fail the Entire Extraction: If data quality is paramount and any error is unacceptable, you might choose to stop the entire process if even one record is bad. This prevents potentially corrupt data from moving downstream.
Skip the Bad Record/File: If occasional bad records are acceptable or expected, you might log the error, skip the problematic record or file, and continue extracting the rest of the data. This keeps the pipeline flowing but requires careful consideration of the impact of missing data.
Quarantine Bad Data: A more advanced approach is to move the problematic data to a separate "quarantine" location for later inspection and potential manual correction.

The right choice depends on the specific requirements of your ETL process and how critical each piece of data is.

Visualizing a Simple Error Handling Flow

Here's a diagram illustrating a basic flow with logging and retries:

This diagram shows a common pattern: try to extract, check if it worked. If yes, great. If no, log the error, see if retries are available. If yes, wait a bit and try again. If no more retries, notify someone and stop.

Handling extraction errors might seem like extra work, but it's fundamental to creating ETL pipelines that are resilient and trustworthy. By anticipating common problems and implementing basic strategies like logging, retries, and alerts, you can significantly improve the reliability of your data extraction process.