spark怎么调用hadoop_Re: Druid背后的Lambda架构，Spark周边的误解etc

在后台大家经常留言问Spark和Druid哪家强，我个人觉得这很能代表许多新手的误解，我特意聊聊，在2018最后的一天，也算是纪念。

Spark和Druid哪家强？

首先，我觉得这个问题提的就不对，因为这两个项目所关注的点不一样。我在以前的文章就提过：Spark不是数据库，是计算引擎，解决数据的处理问题；Druid是预计算存储的时序数据库，解决数据的快速查询问题。前者是处理，后者是查询。两者互补。

Databrick

Databrick可能是Spark商业化中最成功，最有知名度的一个公司。其提供的一站式产品确实能提供一个强大而统一的数据协作平台：workflow，job的调度，多编程语言以及SQL的支持，数据科学家，开发人员，数据分析师，都可以使用其作为工具。尤其是SQL的支持和Spark Stream的加持，使得很大一部分刚接触Spark的人，不经意的认为，Spark就是数据库，可以用SQL一样查询，只不过就是速度慢一些。这个是不对的。

Databrick平台本身是基于Spark构建的能处理实时和批量历史数据，特别是Spark引入流式计算（这个是不是真正的流式计算，还有待争论）后，更是圈粉无数。最典型的架构方式：spark初始化后接入一个数据源，不断地读取数据，每隔一段时间刷新到一个‘表’中，然后就可以在这个‘表’上做SQL查询。

数据处理的痛点

最常见的场景就是如何实现数据的实时查询？比如一个广告系统的投放在前一个小时的投放量，点击量。最典型做法是：有一个cron job，每小时启动一次，导入数据库，建立索引，然后查询。这个做法最大的缺点就是不能实时的监控数据变化。

数据每时每刻都在进来，但是在传统数据库中你是无法实时的导入数据和建立索引的。业界有一个通用的架构：Lambda（注意，这个是数据处理的架构名称，不是java中lambda，也不是亚马逊serverless的lambda）

Lambda架构的指导意义是，如何结合实时(real time)和批处理(batch)两个layers，从而给出一个（近似）准确的结果。这里不去深究背后的实现细节，感兴趣的同学看这里：

λ lambda-architecture.net​lambda-architecture.net

Druid是Lambda的一个实现

Druid的数据处理模块，支持批处理，也支持实时数据。其核心思想就是Lambda架构。在更高的维度来看，Druid是Share Nothing架构的实践。

Druid中使用Spark

这时一个非常先锋的想法，现阶段，Druid在索引batch数据时有两种方式：local本地处理，MiddleManager在本地onheap中索引数据来生成Segment；或者调用hadoop集群来加速数据的索引。正如官方所建议：前者只适用于PoC阶段或小量数据，后者是适合海量数据的可升缩方案。

那就使用Hadoop集群好了，但是使用一个外部的Hadoop集群带来了很多麻烦：配置Druid时，需要特别小心Hadoop依赖的版本冲突和兼容，不同Druid版本对应不同的Hadoop依赖库，github上多次提及的所谓的‘hadoop dependency hell’。为了使用Druid而单独的维护一个Hadoop集群，这个维护成本似乎有点多。还有就是，Hadoop的集群节点node，data node和task node时不时的爆掉，真正用的时候可正是酸爽。Hadoop不擅长处理小文件。hadoop毕竟是上一代的技术了，如果能用spark来帮助Druid建立索引数据，岂不美哉？这个提议也多次在Druid的github上提及。

Druid最初的开发公司已经有了一个初步的原型：

metamx/druid-spark-batch​github.com

不过看看这个repo的星星和维护的力度，似乎还稍欠火候。