分布式计算的独立数据访问层

Question

概述

当前，我的产品维护一个DAL，该DAL与业务逻辑分离并通过一组服务公开，其中每个服务通常对应于一个元素，即Car对象是通过CarService访问的。这些服务通过Spring Data Repositories提供支持，并访问存储在PostgreSQL和Elasticsearch中的数据（模型）。

我们现在正在处理越来越多的数据（文档输入，模型输出或文档输入，聚类，模型输出），并且已经意识到计算已成为瓶颈。为了克服这个问题，我们正在评估Spark或Apache Beam来水平分布计算，从而解决该问题。

问题

在研究了Spark（和Beam）框架之后，我发现它们通常提供自己的集成（或插件），用于从/向数据源读取/写入数据，这本身就很棒。对我来说，问题是无论如何我都找不到这些框架通过我们当前的服务集来支持分布式读写。 Spark需要RDD，Beam需要PCollection，我宁愿不支持从我们的数据存储中进行读取/写入的2种方法。

我的问题

以前有人遇到过吗？你的策略是什么？

您是否继续支持两种DAL？如果是这样，是否有任何警告，特别是在代码的持续维护方面？

Answer 1

在软件工程中，多层体系结构是一种客户端-服务器体系结构，其中，表示，应用程序处理和数据管理在逻辑上是独立的过程，横切关注点或逻辑上的分离有助于提高性能，可伸缩性和维护性。

请记住，层处于逻辑级别，这意味着可能有也可能没有很多物理层。

如果要使用图像1，则不需要新的DAO层，但在图像2中，我建议创建一个单独的项目并使用EAI模式来交流这两个项目

图片1：

在图1中，您可以处理数据并保存到数据库中，并使用同一DAO层获取数据

图片2：

在图2中，您可以创建单独的图层，在该图层中您必须提交作业并将结果直接收集到spring代码中。

• https://docs.spring.io/spring-hadoop/docs/current/reference/html/springandhadoop-spark.html

Apacge Spark或Bigdata具有不同的架构风格，请阅读以下链接。

1. http://lambda-architecture.net/
2. http://milinda.pathirage.org/kappa-architecture.com/
3. https://mapr.com/solutions/zeta-enterprise-architecture/
4. What are the differences between kappa-architecture and lambda-architecture