[FEA] In parquet writer, use column_device_view in EncColumnDesc

[devavret]

EncColumnDesc currently inherits from stats_column_desc which holds pointers to data and validity mask as well as a cuIO specific dtype which basically repeats the list of datatypes supported by cudf.

cudf/cpp/src/io/statistics/column_stats.h

Lines 40 to 48 in 8cc23bd

	struct stats_column_desc {
	statistics_dtype stats_dtype; //!< physical data type of column
	uint32_t num_rows; //!< number of rows in column
	uint32_t num_values; //!< Number of data values in column. Different from num_rows in case of
	//!< nested columns
	const uint32_t *valid_map_base; //!< base of valid bit map for this column (null if not present)
	const void *column_data_base; //!< base ptr to column data
	int32_t ts_scale; //!< timestamp scale (>0: multiply by scale, <0: divide by -scale)
	};

This is the same information stored by cudf::column_device_view and therefore can be replaced by it/contain it.
This gives us a few benefits:

1. Automatic application of offset to data and nullmask ptr. (The latter didn't exist; although, it's being added in Fix nullmask offset handling in parquet and orc writer #6889)
2. Helpful accessors for is_null(i) which de-duplicates functionality.
3. element<T>() accessor, which allows for the following:
   1. On the fly construction of string_view in case of string columns, thus obviating the need to construct a vector of string_views (or, nvstrdesc_s, as it is right now) at the time of construction of parquet_column_view. This limitation exists because string columns contain two data streams (offsets and chars) while stats_column_desc only has pointer to one data stream. This would also automatically resolve [FEA] Replace nvstrdesc with string_view #5682
   2. Automatic construction of decimal32/64 using the scale stored per column.
   3. Automatic construction of dictionary32 using indexalator.
   4. Future proofing any other data type added that needs a custom accessor.
4. Encapsulation of nesting offset data

   cudf/cpp/src/io/parquet/parquet_gpu.hpp

   Lines 225 to 227 in 2ce59fc

   	size_type const *const
   	*nesting_offsets; //!< If column is a nested type, contains offset array of each nesting level
   	size_type nesting_levels; //!< Number of nesting levels in column. 0 means no nesting.

   which currently incurs a memcpy at the time of parquet_column_view construction.

   cudf/cpp/src/io/parquet/writer_impl.cu

   Lines 325 to 330 in 2ce59fc

   	while (curr_col.type().id() == type_id::LIST) {
   	lists_column_view list_col(curr_col);
   	offsets_array.push_back(list_col.offsets().data<size_type>());
   	curr_col = list_col.child();
   	}
   	_offsets_array = offsets_array;

The construction of all these column_device_views might cause many cudaMemcpys if done using column_device_view::create. Since write_parquet and write_chunk are called with a table_view, it'd be better to call table_device_view::create and use a kernel to copy them into EncColumnDesc.

Because of list columns, we'd also want a second column_device_view member in EncColumnDesc so that we can have both the parent column and the leaf column. The leaf column would be the main column for non-list types and the parent column would only be populated for list types.

[vuule]

What about other uses of stats_column_desc? Should we replace it everywhere with column_device_view?

[devavret]

What about other uses of stats_column_desc? Should we replace it everywhere with column_device_view?

As discussed offline, for now we should move away from EncColumnDesc inheriting from stats_column_desc and have a column_device_view member instead. If/when we resolve #6920, stats_column_desc can be removed.

[jrhemstad]

The construction of all these column_device_views might cause many cudaMemcpys if done using column_device_view::create

The functionality added in #6605 should be able to help with this.