将Java应用程序迁移到Hadoop：架构/设计障碍？

如何解决将Java应用程序迁移到Hadoop：架构/设计障碍？

| Alrite ..所以..这是一种情况： 我负责架构基于Java的ETL软件（而不是EAI）的迁移。 我将不得不将此迁移到Hadoop（apache版本）。现在，从技术上讲，这更像是重启，而不是迁移-因为我没有要迁移的数据库。这是关于利用Hadoop的，因此（\'ETL \'）的转换阶段是并行进行的。这样可以制作我的ETL软件， 更快-并行化转换。 可扩展-处理更多数据/大数据涉及添加更多节点。 可靠-Hadoop的冗余性和可靠性将增加我产品的功能。 我已经测试了此配置-将转换算法更改为mapreduce模型，在高端Hadoop集群上进行了测试，并对其性能进行了基准测试。现在，我正在尝试理解和记录所有可能妨碍应用程序重新设计/重新架构/迁移的内容。这是我想到的一些： 其他两个阶段：提取和加载-我的ETL工具可以处理各种数据源-因此，我是否重新设计我的数据适配器以从这些数据源读取数据，将其加载到HDFS，然后进行转换并将其加载到目标数据源中？这一步是否会成为整个体系结构的巨大瓶颈？ 反馈：因此，我的转换在一条记录上失败-我如何让最终用户知道ETL在特定记录上遇到了错误？简而言之，我如何在所有地图/缩小/合并/排序发生时跟踪应用程序级别的实际情况-默认Hadoop Web界面不适用于最终用户-管理员可用。那么我应该构建一个从Hadoop Web界面抓取的新Web应用程序吗？ （我知道这是不推荐的） 安全性：如何在Hadoop级别处理授权？谁可以运行作业，谁不能运行\'em-如何支持ACL？ 基于您在Hadoop /问题分析方面的经验，我希望收到您对上述问题的解答，以及我需要考虑的更多问题/事实。 与往常一样，我感谢您的帮助，并在此先感谢您。     

解决方法

         我不希望加载到HDFS会遇到麻烦，因为加载是在数据节点之间分配的，因此网络接口只会成为瓶颈。将数据加载回数据库可能很麻烦，但我认为现在还不算太糟。我会设计作业，使其输入和输出位于HDFS中，然后将某种结果批量运行到数据库中。 反馈是一个有问题的问题，因为实际上MR只有一个结果-它是转换后的数据。所有其他技巧，例如将失败的记录写入HDFS文件，都将缺少MR的“功能”可靠性，因为这是副作用。缓解此问题的方法之一是，您应设计软件以准备处理重复的失败记录。还有scoop =该工具专门用于在SQL数据库和Hadoop之间迁移数据。 http://www.cloudera.com/downloads/sqoop/ 同时，我会考虑使用HIVE-如果您的SQL转换不是那么复杂-创建CSV文件并使用Hive进行初始预聚合可能会很实际，这样可以减少进入（也许是单节点）数据库之前的数据量。