[TiDB 版本]
v5.0
[问题描述]
传统数据仓库中过ETL、多表关联、指标加工、形成新的数据模型、数据集市，如oracle通过存储过程处理，最终建立了多层级的事实表、dm层表。
但在tidb不支持存储过程情况下，如何实现，通过复杂查询、多层级视图吗？如何实现数据集市？谢谢。
这个有点难为TIDB了。
一般 TiDB 不太用来做传统数仓，但是也有一些轻量的用户用 TiDB 做类似工作。这里有几个选择，一方面 TiDB 会更倾向于实时写入，因此一部分用户选择使用 Apache Flink 代替存储过程实时建模；另外也有一部分用户使用 TiSpark 的批量写入进行 ETL 和建模。
刚入门tidb，看到有介绍说可以做数仓，想了解下。
谢谢。Flink和TiSpark不是很熟悉，考虑过同步到pg后再处理，如ticdc+canal to postresql 或 datax，但还需要实验。
欢迎测试输出评测文档。
不好意思，这大概是很久以前的帖子了。
我们不聊具体的技术，所以大部分是个人的感受。
存储过程是不是一个好东西呢？在十年以前，我一直有一个想法，就是能用存储过程做的，坚决不要放在前端程序里面。这样做是出于两个方面考虑的，其一是性能，其二是技术栈更熟悉，管理方便。当时做 etl 还用 kettle，还用 informatica。很多时候，informatica 替代了一部分存储过程的功能。
之后的五年，去 O 的呼声越来越高，越来越多的人将数据流到 MySQL 中。数据迁移是一个非常痛苦的事情，不仅仅要保证数据的正确性，还要更改大量的存储过程。存储过程的正确性验证要比数据来的更痛苦。在这个时候，我就开始思考，到底应不应该用存储过程。
就我个人而言，在转技术栈做 pg 以后就再也没有用过存储过程了。我更倾向于使用标准的 sql 进行数据处理，搭配 scheduler 工具来进行 task 的管理。用这种方式来替代原有的存储过程。这些 scheduler 工具市面上还是挺多的，大部分都是图形化的。比如说 control-M，比如说 airflow。我觉得大部分的需求都可以用 scheduler 搭配标准 sql 来完成。
我觉得这个时代已经是一个数据流的时代了。数据已经不像十年前，就是那么固话在 oracle 里面。它要不停的流动起来，所以才有了 kafka，才有了 flink。当数据流动起来以后，因为标准兼容性的原因，可能使用存储过程已经不是最好的选择了。
回到您的问题上来，如果您想寻求一种解决方案替换存储过程的话，可以考虑尝试用 flink 在流处理中做一些运算，可以考虑通过 scheduler tool + sql 的方式来处理复杂的罗技。
关键TiDB也不支持存储过程呀。。。
另外我觉得存储过程应该更多的实现类似接口的作用，即业务拆分细化，类似微服务那种。每个小存储过程只实现标准化的功能，比如字符拆分成行，阴阳历转换等。具体到业务的话，就是见仁见智了。
是的吧，我个人的感觉是，无论什么库都要去存储过程，数据流动的过程中，存储过程台可怕了。
不过这个也只是我个人的观点，一个人一种习惯吧。
