目前有一个OLAP场景，每小时总的数据量约为80亿，但实际入库字段可能就20-30个。
场景中需要T+1的分析这批数据，原始数据分析完即可删除。
约有2-5个聚合语句会作用在全部80亿数据上（共15个维度字段，6个指标字段）。
还有10个聚合语句，作用在部分数据上（10亿左右，2-4个维度字段，3个指标字段）。
上述聚合后，还会进行第二次聚合生成最终的应用数据，最终总的指标应该是100个左右。
我看TiDB更多还是OLTP场景，OLAP需要从TiKV 复制数据到TiFlash，无法单独TiFlash部署。不知道能否适用这种场景？如何设计组件分布为佳？
PS1：想用数据库的方案，主要还是感觉大数据那套维护有点麻烦。
PS2：调研TiDB主要是有国产化需求。之前选的Doris、Clickhouse都已经被否了。
如果是国产化需求的话，目前就是tidb的企业版本。 大数据那套也满足不了国产化的需求
你这个场景starrocks满足最合适
国产化要求严格的话，就使用tidb吧。
3个tikv必须，
3pd 必须
Tiflash 2-3个，配置高点，1副本就可以，（出问题可以在从tikv同步）
tidbserver 至少2个 ，其中一个可以配置强制走tiflash。一个用于数据写入。
我们现在是从starrocks 切换到tidb的，统一架构，我很期待tidb后续的物化视图。有了物化视图后，很多关联查询就会更便捷。
以上是个人见解。
Doris和Starrocks差不多吧。最开始选型的就是+CH这三。因为国产化问题被否。
主要TiDB没用过，性能上没底儿。
另外你提到的：其中一个可以配置强制走tiflash。一个用于数据写入。
是什么意思，我看官方文档里，说是无法直接写入TiFlash。
是无法直接写入tiflash，是从tikv复制到tiflash中的
tidbserver 是 一个用于查询强制走tiflash引擎，olap，一个是用来oltp
每小时总的数据量约为80亿，这么大的数据量并发入库，不知道几个tikv能抗住，预计的服务器资源大概能给到多少啊。
如果不用oltp功能，只用olap，其实tidb的tikv都浪费掉了，同时还得tikv和tiflash重复占用存储。。。。
场景中需要T+1的分析这批数据，原始数据分析完即可删除，这个倒是可以通过分区表或者TTL功能来实现
我看错了以为一天80亿呢，确实一小时80亿，这个并发大。
每小时80亿，没见过这么大规模数据，建议联系下企业版找厂商出解决方案。
感觉tikv只是用来复制数据给tiflash的话，资源上是否有点浪费啊
尝试用下 flink 看能解决你的问题不
场景中需要 T+1 的分析数据，原始数据分析完即可删除。这可以通过分区表或者 TTL 功能来实现。
每小时 80 亿的数据量并发入库，TIDB本来就是顺序写入 ，写入性能比mysql块很多
可以联系下表妹和论坛博主考虑一下商业的。让他们给个方案
每分钟1.3亿多数据库入库，我感觉这要存算分离了，估计只有支持对象存储的数据湖才可以搞定了。这种不差钱的公司要是自己没团队就太难搞了，建议找数据服务商出解决方案吧
一般企业几年的数据行数能达到80亿，很牛叉了。你这个一小时80亿。如果还是是宽表难以想象。tidb tiflash满足不了的话，其他国产产品。也悬。
没有概念，这么大的写入，或者删除操作。
可以适应这个场景。80亿数据是按行算的吧？拆到列，可能没这么多。这部分聚合用tiflash应该是个不错的选择。
问题的关键如上面所说，这一小时80亿行的写入，tikv能不能接的下，只要tikv能接的下，tiflash做聚合计算我到觉得不是问题的核心。
而且我看你的方案还有2次聚合，那就说明是可以分批聚合的。如果80亿行处理不了，无非是拆到15分钟聚合一次，再算1小时的就可以了。粒度拆细一点也完全能做。多聚合几次也是肯定能做的。
至于整个架构的方案，强烈推荐 @Jellybean 下面这个文章。
这么大的量建议你先实时进去Hadoop，分析处理完之后看看还有多少；不多的话可以反向再进去TiDB，否则这个体量数据库很难扛得住
那就直接上 TiDB 企业版
tiflash用来做olap，这样就既有oltp，又有olap的功能了，如果有这个需求，那资源就没有浪费，如果没有这个需求，那可以不部署tiflash节点
这数据量真够大的