Aside: Hadoop and Hive sources
Structurally an extract–land–load case, with three differences that matter.
Hadoop and Hive sources look like an extract-land-load case, and structurally they are, but three differences matter.
First, the data is already in files, often already in a columnar format, and often already in object storage or trivially movable to it. The extraction problem you would have with a relational source largely disappears. What you get instead is a data quality and schema problem: Hive’s schema-on-read tolerance means the files frequently do not conform to the schema the metastore claims, and nothing has ever forced the issue.
Second, the metastore is the asset. Table definitions, partition layouts and location mappings in the Hive metastore are the map of the estate. Extract and preserve it early — these clusters are often decommissioned faster than the migration completes.
Third, a substantial part of a Hadoop estate is usually not warehouse data at all. It is raw landing data, intermediate processing output and experimental datasets that accumulated because storage was cheap. Do not migrate it by default. Classify it into data that belongs in the database, data that belongs in object storage under governance, and data that should be deleted — and expect the third category to be larger than anyone will initially admit.
The processing layer — Spark, Hive QL, MapReduce jobs — falls under code conversion above, with the additional wrinkle that its logic is often less well documented than a relational platform’s, because it was written by data engineers rather than DBAs and was never subject to the same change control.