将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进行初始预聚合可能会很实际,这样可以减少进入(也许是单节点)数据库之前的数据量。