MariaDB Column Store Suitability for Data Warehouse
This is what I say about MySQL/MariaDB without columnstore:
Not good:  &quot;sum up to 1 TB&quot; versus &quot;1,25 TB of SSD storage&quot;.  As a Rule of Thumb, you should have half your disk free for maintenance and growth.  As a minimum, there should be enough room for an extra copy of the largest table -- data+indexes.  This allows any ALTER to run without running out of disk space.
Let's discuss the largest table.  Please show us SHOW CREATE TABLE and the main queries -- for inserting, for updating and deleting (if needed), and for selecting.  With that we can discuss shrinking the disk footprint, indexing, and partitioning (or not).
Here's my discussion of DW: http://mysql.rjweb.org/doc.php/datawarehouse See also its link to a Summary table discussion.
Please elaborate on &quot;simply no common keys&quot;.
With &quot;overnight batch loading&quot;, I highly recommend:

load into a temp table;
normalize (tips on that in another link);
augment the summary table(s) from the temp table;
copy the data into the main Fact table;
drop the temp table.

If you are &quot;purging&quot; &quot;old&quot; data, then PARTITION the table so as to replace the big, slow, DELETE with a fast DROP PARTITION.  More details: http://mysql.rjweb.org/doc.php/partitionmaint
Your other numeric specs are not scary but could be problematic.  Need to get into the actual analytic queries to see.
Note: if your team grows and the system fails to provide adequate concurrent queries, you can build a Replication system, wherein the Primary copies to read-only Replicas.  Each Replica can independently handle several big analysis queries.
The amount of RAM will be determined by the table sizes, query complexity, etc.  More ram is better -- but there is a point of &quot;diminishing returns&quot; that cannot be predicted.  Start with your 64GB, try to optimize the &quot;worst queries&quot;; then decide whether to add Replicas.
The layout of the SSDs won't matter much.  (Aside from needing more room.)  With multiple small drives, you could use RAID striping and/or parity.  I would want a raid controller with battery-backed-write-cache (costly, good, but probably overkill since you write only nightly, and possibly don't care if it takes 2 hours instead of 1?)  That would allow for `RAID-5 deployment of 4x500g or 7x250G drives,  Either would give you effectively 1.5TB plus parity.
(Years ago, I did a similar project (0.5TB data; HHD; RAID-5; hourly load; 7 summary tables loaded in about 7 minutes.  Primary-Replica was implemented, but was overkill in my case.  The Summary tables turned hour-long queries into minute-long queries; YMMV.)
columnstore
Columnstore shrinks typical data by 10x.  (I suspect that a well designed schema on InnoDB can't be shrunk by that much.)  Some of the performance characteristics come from this compression; some from parallel operations.
What does your 1TB come from?  Does it mean that you would need only 0.1TB of disk for Columnstore?  Or that InnoDB would need 10TB?  (My discussions above may need adjusting accordingly.)
Columnstore is excellent at querying on an arbitrary column because every column is indexed.  But when you filter on more than one column, it will efficiently filter on one, then (perhaps) have to brute force on the others.
Without more insight into your queries, I can't judge between

Columnstore
MySQL/MariaDB with regular indexing
MySQL/MariaDB with Partitioning / FULLTEXT / Spatial

It is likely that CS will outperform or underperform an equivalent database without CS -- depending on the query.