In ClickHouse it is just `INSERT INTO t FROM INFILE 'data.csv.gz'`. Any supported format, any encryption, autodetected from file name and sample data piece to get column types, delimeters etc.
Separate tools to convert CSV are not necessary if you can just import to db and export as SQL Statements.
echo "name,age,city
John,30,New York
Jane,25,Los Angeles" > example.csv
clickhouse local -q "SELECT * FROM file('example.csv') FORMAT SQLInsert"
INSERT INTO table (`name`, `age`, `city`) VALUES ('John', 30, 'New York'), ('Jane', 25, 'Los Angeles');
Now you rarely use basic MapReduce primitives, you have another layer of abstraction that can run on infrastructure that was running MR jobs before. This infrastructure allows to efficiently allocate some compute resources for "long" running tasks in a large cluster with respect to memory/cpu/network and other constraints. So basically schedulers of MapReduce jobs and cluster management tools became that good, because MR methodology had trivial abstractions, but required efficient implementation to make it work seamlessly.
Abstraction layers on top of this infrastructure now can optimize pipeline as a whole by merging several steps into one when possible, add combiners(partial reduce before shuffle). It requires whole processing pipeline to be defined in more specific operations. Some of them propose to use SQL to formulate task, but it can be done using other primitives. And given this pipeline it is easy to implement optimizations making whole system much more user-friendly and efficient compared to MapReduce, when user has to think about all the optimizations and implement them inside single map/reduce/(combine) operations.
You can even migrate your zookeeper to ClickHouse keeper. It requires small downtime, but you will have all your zookeeper data inside and your clients will just work when your keeper will be back
There is no need to use clickhouse-local for 'local' analysis. It just the same ClickHouse, but it will not store any local data. Just use it as ETL tool. Something like this will work:
INSERT INTO FUNCTION s3('https://storage.googleapis.com/BUCKET/test_data/file.csv', 'XXXXX','XXXXX',CSV) SELECT col1, col2 FROM postgresql(postgres1, schema='schema1', table='table1') WHERE col1 > col2;
I don't know why exactly you need BigQuery in your scenario. If I wanted to have Postgres->ClickHouse it would take single INSERT SELECT from ClickHouse.
If you need just CSV result dumped to GCS you can use clickhouse-local mode that has all the features like integrations with Postgres, GCP, formats.
Only but it is not a service with UI where your data analysts can click and drag what they want to export. But SQL can be simple for them to write and you need nothing more than a trivial cron job analogue to run it.
I think optimizations that you focus on for self-hosted ClickHouse are the same as for Cloud. In self-hosted it helps to improve your throughput/capacity with fixed allocated resources. In cloud it directly affects cost.
For those complex pipelines you may find more useful to run tests during trial. Data distribution, partitioning and so on can change actual cost significantly so estimates can be too pessimistic or optimistic
License states the following. All other modifications are not standardized and you can't just compare systems. Otherwise there would be another standardized benchmark in the list you propose to run and publish.
>c. Public Disclosure: You may not publicly disclose any performance
results produced while using the Software except in the following
circumstances:
(1) as part of a TPC Benchmark Result. For purposes of this Agreement, a
"TPC Benchmark Result" is a performance test submitted to the TPC,
documented by a Full Disclosure Report and Executive Summary, claiming
to meet the requirements of an official TPC Benchmark Standard. You
agree that TPC Benchmark Results may only be published in accordance
with the TPC Policies. viewable at http: //www.tpc.org
(2) as part of an academic or research effort that does not imply or
state a marketing position
(3) any other use of the Software, provided that any performance results
must be clearly identified as not being comparable to TPC Benchmark
Results unless specifically authorized by TPC.
I think ClickHouse Cloud Beta addressed exactly this concern. It separates storage and compute and deals with scaling. There is no sharding so you don't need to deal with scaling.
You can't post results of TPC benchmarks without official audit. So it complicates posting results. You can't find common names that are usually compared with ClickHouse there [1]. So open standardized ClickBench tries to encourage benchmarking for everyone.
There are numerous benchmarks that use similar to TPC queries, but those are not standardized and can be misleading. For example a lot of work was done by Fivetran to get this report [0], but they show only overall geomean for those systems and you can't understand how they actually differ. Anyway their queries are not original TPC - variables are fixed in queries, they run first query when official query is a multiquery.
Contributors from Altinity run SSB with flattened and original schemas [2]. SSB is not well standardized and we see a lot of pairwise comparisons with controversial results - generally you can't just reproduce them and get all the results in single place for the same hardware.