至于上面推荐 parquet 的，最简单也要有 hive ，查也要有 impala/kylin 之类的引擎，不太推荐。greenplum 是个好东西，不过是 pg 体系的，若是你们用 pg 必然优选这个，etl 更简单。
上 es 的，属于屠龙刀杀鸡，查询也存在割裂，需要研发成本，不推荐。
hbase 的，体系很大，若没有已存在的基础设施，也是不推荐。

我提议按日 etl ，有个前提，超过 n 天的数据无法修改。
每次 etl ，要把这个范围内的日期都 drop part 然后重新 insert 。
若你这个 n ，它很大，那每次 etl 运动数据量很恐怖，clickhouse 这个方案也不太行，建议走 cdc 路子

理智点讲，分两种工况

1. 业务正常读写，能正常跑就单表顶多分区，不建议扯太多。分表增加很多管理压力，而不分表只是 ddl 压力、备份恢复压力。当然前提管住手欠的直接无索引查全表。
2. 有范围聚合性统计操作，这类按惯例，etl 一份到 olap 库，典型目标库 doris/clickhouse ，但这个不要做实时，建议按日，业务侧保证不查当日，或者查询业务上区分当日和非当日。极少有业务无法妥协，不妥协那是人的事不是业务的。
3. 若不能妥协，上游“劳资非要任意查不能拆分”，那就要考虑 cdc 链路，若业务存在 update 则不能选择 clickhouse(细碎麻烦很多，虽然都有解法但太麻烦不适合快速落地)，若业务数据量大(日 300w 不算多，稍微多给点资源就当小量)，doris 配 cdc 合并上也吃不消。至于 cdc 也是有延迟的，分钟级的程度，努努力能做到秒级(十几二十几的程度)，资源消耗究极猛

按日 etl 难度不高，落地很快，配个定时跑下 sql 就能完成入仓。

clickhouse 单机 8c64g 配几块机械盘，足够支撑你这丁丁点数据量(我这单点 ck 每天手机号量级写入)

至于 mysql 插入慢，问题可能多方面。根据描述只能建议先切出 adhoc 查询流量，优化查询体验，没法给你解决写性能问题。

顺带一提，mysql 单表亿级别，也不是什么大奸大恶，必须分表。理智点做取舍。个人信奉“分库分表为数据治理最后方案”

@shenjinpeng 大概率业务网关、采集、资源下发
高吞吐下 zgc 省心，下限高。g1 上限更高，下限却不怎样

理论应当框架化，实际自研比重相当大
微服务场景，插件化更重要，让各个服务能尽可能便捷接入。
不过公司内技术垃圾，更推荐丢了煞笔的微服务，

给别人打个广告，权限问题可以看一眼 casbin 这个库，功能比较全面，接入尚且算简单。单点登录(第三方登录)还有它家八竿子打不到的 casdoor ，都挺强悍

不考虑实际应用，暴力破解破万法，但实际这玩意得跑到大道都磨灭了

无论什么要求，降噪耳塞只有 3m ，别的基本不用看

按题目数据量级，大概算下来，一年大概 18 万亿行，磁盘空间应该在 1t 到 2t 之间，写入带宽都喂不满一个单点 ck 配几块机械盘
不过列存嘛，整体结构参考上面 @dlmy 兄弟的描述

就这么点数据，想这么多，又这又那的
这点量都摸不到 doris/ck 单机瓶颈

拿 ck 来说，上面给出 ck 表结构的兄弟，@yjhatfdu2 表排序键有问题，排序优先遵循业务必选条件，再根据基数由低到高。建议调整排序顺序为 country,province,city,time 编码方式里，时间去掉 doubledelta ，追求压缩率平衡不用 lz4 ，改用 zstd(1)差不多就这样了。
你这第一个就是高基数，压缩比会很低，速度上不来

对列存来说，整分区 count 都是 O(1)消耗的元数据查询，看不出性能

至于表分区键选用按日还是按月，需要考虑业务平常查询到底按什么的多些。经常跨度大的就改为按月，反之按日。若是业务有按国家为租户的习惯，那分区把国家带上再按月也合理。
若是还有一些大范围时间内区域统计需求，上 projection 来预计算

bps ，timestamp ，时序性数据上时序专用库也可以，总之比这个要好，现在这用法再怎么优化也快不起来的

统计，建议扔了 mysql ，你这场景不适合
考虑 hdfs ，clickhouse ，再来 10 倍量也能秒查