【TiDB 使用环境】:生产/测试/POC
【TiDB 版本】 5.0
【出现的问题】 今天发现tispark数据无法写入分区表中，让我产生了tidb适不适合做大数据离线数据仓库搭建一点点怀疑，求大佬指点。或者有没有大佬以及用了tidb做离线数仓的搭建，求分享一些心得或者一些踩的坑。
3 个赞
tidb做离线数仓，
优势：
1.一键部署，实现了spark的catalog扩展，都很方便。
劣势：
1.因为受到两阶段提交的限制，吞吐上效率不高，同等资源条件下，比其他的olap的mpp数据库表现差。
2.受限于pd的region管理能力，总体数据存储量受限制。
适应场景：
1.实时数仓。
2.lambda架构的serving layer。
3.小项目，通过tispark扩展出离线能力。
6 个赞
那我是不是可以认为tidb更适合实时场景，较大型离线数仓不太适合
1 个赞
较大型离线数仓对tidb确实有限制，我给你提供一些数据：
1.8c16G，16个节点的tikv，使用tispark写入，2000万，7分钟，ssd磁盘
2.我印象中，当pd面临10万+的region，心跳会给pd带来较大的负担，基于此计算，整体tidb的存储舒适区间小于10TB
以上的存储与计算数据，能够满足场景要求就可以的
2 个赞
tispark无法将数据写入分区表（离线数仓一般会对表进行分区处理），有什么解决方案吗
1 个赞
查了一下github，写入分区表目前还在feature-request里面，没看到有相关的提交，参考：https://github.com/pingcap/tispark/labels/type%2Ffeature-request
这篇帖子里面https://asktug.com/t/topic/93585/4，能给@qizheng也提到需要补充一些业务场景
我的场景里是从tidb读取数据，写入hive，hive中的数据计算后，写入了tidb非分区表，主要是一些结果数据，量不大。
1 个赞
目前线上集群类似这个功能的，得控制QPS，并发问题，分析历史庞大数据还是很吃力
1 个赞
麻烦说的详细一点
当然有更适合的 但如果你熟悉tidb和mysql 做数仓也适合
表设计不分区会影响查询速度
支持分区表了 还在实验阶段
Exception in thread “main” com.pingcap.tikv.exception.TiBatchWriteException: tispark currently does not support write data to partition table!
1 个赞
好吧 没仔细看 sorry
We will support TiSpark writing into the partition table in the future. Maybe in July
感觉不时候吧，成本比其它方案高
1 个赞
tidb 适合做实时数仓
用tidb做离线数仓成本有点高
加载数据的性能是有点局限我测的性能指标是285秒利用tispark 加载了1亿条数据 20个tikv实例 10台主机 48core 256GB sata磁盘 该表62列
10TB这个数量有点少啊 我们其实打算拿tidb代替hive的角色呢
pd主机的负载一直不重啊！
当然适合了。