基于内存数据库做大数据运算是否靠谱?

2022-11-01 09:09:45 +08:00
 whats
场景:从不同数据源(大数据集群、API 接口、文件等)抽取结构化数据,执行交并差,格式转换、分行分列等运算。数据源和算法可自由组合,过程用 DAG 图表示,是逐步分析的过程,存在多个中间结果。目前的做法是将原始数据及运算过程中间结果抽取到 MPP 库,借助 MPP 库运算。

存在的问题:
1 ) MPP 库入库性能一般,导致整个 DAG 图的执行效率偏低。
2 ) 运算过程产生了大量临时表,需要定期清理。
3 ) MPP 库的部分 SQL 语句运算效率并不理想。

初步优化思路:
1 ) 将中间运算过程放到内存数据库运算,大部分情况不需要持久化中间结果数据。
2 ) 将最终结果持久化 MPP 库,供后续使用

问题:
1 ) 该优化思路是否合理?有没其他更靠谱的方式?
2 ) 有没推荐的内存数据库选型?
3041 次点击
所在节点    程序员
16 条回复
kele1997
2022-11-01 09:22:32 +08:00
spark 临时表
jeesk
2022-11-01 09:40:17 +08:00
flink 试一试
sunmacarenas
2022-11-01 09:55:52 +08:00
SAP HANA 可以尝试一下,不过成本非常高
linfx7
2022-11-01 09:58:53 +08:00
trino 或者 presto 试一试
liprais
2022-11-01 10:03:02 +08:00
内存放不下的咋办
1996wang
2022-11-01 10:03:30 +08:00
1.整个过程不要求实时计算,那么直接原始数据入 mpp 库,整个 dag 在 mpp 里执行.就是数仓那一套.
2.整体要实时计算,可以试试 flink,最后把结果写入 mpp,供后续使用. 至于中间结果,可以就一整套 flink sql(这种中间状态会变大,不可控),或者中间结果打入 redis,flink 实时异步关联
Exception615
2022-11-01 10:10:16 +08:00
计算的过程交给 MPP 感觉不太合适,大数据量的批处理还是 spark 比较合适,支持的数据源种类也多
lookStupiToForce
2022-11-01 11:16:25 +08:00
不说数据量?
你内存要够大到几个 T 的地步,那确实一般情况随便上内存数据库做运算只把最后结果落盘啊?但数据量一大起来,几个 T 也不够看的
w0017
2022-11-01 11:39:08 +08:00
spark-redis 了解下。
whats
2022-11-01 11:57:13 +08:00
@lookStupiToForce 对数据量做了限制,超出内存大小的计算直接拒绝,内存一般可以配置到 1TB 以上
tulumu
2022-11-01 11:58:57 +08:00
如果是简单 etl, 建议实时就 flink sql +udf, 离线就 hive/spark, 想方便就还继续 mpp 数据库吧, 毕竟一把梭
ConfusedBiscuit
2022-11-01 12:03:06 +08:00
内存数据库的方案我玩过,先说结论,玩好了效果很好

用的是 Hive Transform + Python 脚本 + Python 内置的 SQLite 模块做内存数据库。只要控制好每个节点数据量(比如根据某个 id hash 到不同 reducer ,这样就能承载很大的总数据量),效果就非常好,比我那个项目以前的方案强很多。当时这个方案由于效果太好还在公司内有些反响
lookStupiToForce
2022-11-01 12:28:05 +08:00
@whats #9
除了 spark 和 flink ,
补充一个 Apache Ignite (这个才是和 redis 一类的真内存数据库,支持内存数据表 session 持久化,支持 acid )

https://stackoverflow.com/questions/36036910/apache-spark-vs-apache-ignite

不过所有内存的东西不落盘都不靠谱,即便你能用上持久化内存也一样,所以你得切分清楚哪些东西是进了内存库后往里读 /往外写了一半全丢了也不要紧
motecshine
2022-11-01 13:11:40 +08:00
ramdisk 可以试试
fenghao
2022-11-02 06:51:11 +08:00
使用内存数据库肯定是一个好的解决方案,redis 咋样?但我看你的需求在大量计算而非 IO ,不知道具体怎么样,可能 bottleneck 并不在 IO 上。
whats
2022-11-02 08:40:42 +08:00
@fenghao 因为不涉及复杂的计算,目前的方式,时间反而耗在 IO 上比较

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/891636

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX