很多企业正在将Hadoop应用到他们的IT基础设施中去。对于拥有强大工程团队，经验丰富的大数据老手们来说，要设计目标系统，选择技术堆栈，以及启动项目通常并不是什么大问题。即便是那些经验老道的人有时仍会面对诸多复杂纷繁的障碍，而Hadoop初学者会在起始阶段就面临无数的挑战。下面我们列出了一些最为常见的Hadoop问题。

供应商多元化。该选谁呢？

最为常见的反应是从Apache网站上使用原始的Hadoop二进制文件，但是这会导致这样的问题，即为什么只有少数公司在生产环境中投入使用。对于不这样做有着很多的争议。但当来自于Hortonworks，Cloudera，MapR的很多Hadoop发行版可免费下载时，恐慌接踵而至，而又随着大型商业IBMInfoSphere BigInsights以及OracleBig Data Appliance的参与趋于终止。Oracle甚至包含了硬件！当一些行业引入了供应商后事情变得更为复杂。选择正确的版本并非易事，甚至对于经验老道的人亦是如此，因为它们每一个都要嵌入不同的Hadoop组件（如CDH中的ClouderaImpala），配置管理器（Ambari，Cloudera Manager等等）。

SQL on Hadoop非常流行，但并不明确…

Hadoop存储了大量数据。除了根据预定义管道进行处理外，企业还想让数据科学和业务分析人员通过交互访问来获取更多价值。Internet上的口碑营销迫使他们这样去做，虽不是很明确，但暗含的意思就是企业数据仓库的竞争。这里的情况类似于供应商多元化，由于有相当多的框架可以提供“Hadoop上的SQL”，如何选择它们中最好的并非挑战所在。要明白它们目前都还无法完全取代传统OLAP数据库。与此同时，它们有很多策略优势，但在性能，SQL兼容性以及对简化的支持方面都有可商榷的短板。这是另外一个世界，你要么遵守它的规则，要么就不要把它看作是传统方法的替代品。

大数据工程师不好招

一个好的工程人员是任何IT企业的重要组成部分，而这在大数据中尤为关键。在大多数案例中依赖好的Java/Python/C++工程师来设计/实现高质量的数据处理流程便意味着花费大量金钱。经过两年的发展，你所拥有的可能会是不稳定，不被支持的以及过度工程化的混乱脚本和框架。如果关键开发人员离去，那么这种情况就会变得糟糕。与任何其他编程领域一样，经验丰富的大数据开发人员会花费大量时间来思考如何让事情变得简单以及系统在未来将会如何加以评估。由于经验在大数据技术栈中是一个关键因素。因此寻找经验丰富的开发人员才是真正挑战所在。

安全的Hadoop环境让人头痛。

越来越多的公司在Hadoop上存储敏感数据。尽管这些数据不是信用卡号，但是这些数据至少各自有着安全规范方面的要求。因此这一挑战纯粹是技术层面的，但往往会引发问题。如果仅仅是使用HDFS和MapReduce，那么事情就会很简单。动态数据和静态加密数据都是可用的，文件系统权限足以用来进行授权，Kerberos则用来进行身份验证。只需用显式边缘节点添加围墙和主机级的安全性并保持静默即可。但是一旦你决定使用其他框架，尤其是如果它们在自己的系统用户下执行请求，那么你就会陷入麻烦。首先，并不是所有框架都支持Kerberized环境。其次，它们可能没有自身的授权功能。第三，经常性缺乏加密运动数据。最后，如果请求是在集群之外进行提交会引起很多问题。

结论

以上内容远未达到完整的程度，而且有人可能会被吓跑而决定完全不使用Hadoop或是推迟对其的使用。这是不明智的。经验老道的人使用Hadoop可以为企业带来很多好处。与其他大数据框架和技术结合，它可以让面向数据业务的功能提升到一个全新的性能水平。