QueryDatabaseTable is meant to run on the Primary Node only as it is a single-source for fetching. This means it will not scale to a distributed/parallel solution such as Sqoop. Also if you hypothetically have 3 nodes in a NiFi cluster but 10 in a Hadoop cluster with Sqoop, naturally you'll get more parallelism in the latter.
However, NiFi has the GenerateTableFetch -> ExecuteSQL
pattern for this. Instead of a single processor on a single node doing the full fetch, GenerateTableFetch will instead generate a number of flow files that each contain a SQL statement to fetch a "page" of data from the table. You can then use ExecuteSQL to actually fetch the rows.
GenerateTableFetch still runs only on the primary node, but it does not fetch the rows itself; instead you'd distribute the flow files among the cluster nodes using either a Remote Process Group -> Input Port
on the same cluster, or in recent versions of NiFi you can use a Load-Balanced Connection between GenerateTableFetch and ExecuteSQL.
Once the flow files are distributed among the cluster, each node can run ExecuteSQL on them in parallel and fetch a page of data at a time for downstream processing.
For the output format, as of NiFi 1.8.0 there is ExecuteSQLRecord which allows you to output the rows in any format that has a RecordSetWriter, which includes Avro, JSON, CSV, XML, Free-text (for custom textual formats), and you can even script your own for more complex, proprietary, or currently unsupported formats. For completeness there is also a QueryDatabaseTableRecord processor, but for this answer I'd like to discourage you from using it to solve your use case :)