你的问题有许多不同的部分，我将试着分别回答。
我逐渐意识到dynamodb可能会在某个特定的点上完成所有这些读/写操作
有两种方法可以解释这一点：你担心它会在规模（无法处理负载）或成本方面“封顶”。
在规模方面，亚马逊自己使用dynamodb为大部分服务提供动力，一些公司使用dynamodb解决绝对巨大的问题。在2019年的黄金时段，亚马逊服务的dynamodb表达到了每秒4540万个请求的峰值。这是非常，非常不可能的，你会在任何地方接近达到什么dynamodb可以处理的极限。
当然，您必须对数据进行良好的建模，以免在较低的范围内遇到麻烦。好好阅读文档中的最佳实践部分会让你大开眼界。
关于成本，这绝对是你必须处理的一个因素。如果你处理的是twitter的firehose数据，那么它很快就会变得非常昂贵。我建议你做一个成本估算，不管你选择哪种技术。
我打算每小时删除一次表中的内容以节省空间，但我想知道dynamodb多久就会结束
无论是在性能还是成本上，空间都不太可能是最相关的因素。如果您正确地设计了主键（再次检查best practices doc），那么查询中整个表大小的影响几乎为零，即使您有数十亿条tweet。
就成本而言，过期较旧的记录将节省一些钱，但与最初编写和读取这些记录的成本相比，节省不了多少钱。
如果您决定让旧项目过期仍然是一个好主意，那么dynamodb可以通过ttl（time to live）特性为您管理它。
也许可以将分析过的tweet流式传输到本地机器，而不是dynamodb，比如sqllite
这听起来是个非常非常糟糕的主意。另外，如果您计划在云中（heroku或其他地方）托管应用服务器（“display.py”），它将如何与您机器上的本地数据库通信？即使你解决了这个问题，你仍然需要在本地机器上管理一个大型数据库。
我打算通过heroku托管dispaly.py，因为它将使用dash/plotly，并且类似于flask
大多数平台即服务解决方案（heroku、appengine等）都可以。
有没有比现在更好的方法来处理这个应用程序？
你目前的方法，基本上是由twitter>kinesis>spark>dynamodb>web可视化组成，听起来不太对劲。现在，要说这是“更好”的方法，就需要更多的信息（你的预算是多少？我们在说多少条微博？我们说的是多少通道？）。