本文作者:曾就职传统通讯运营商,负责BI项目的开发;目前转型互联网公司,就职于某厂负责相关的大数据仓库建设工作。 随着的几年的架构沉淀,工作上形成了离线以 Hive 为主,Spark 为辅, 实时处理用 Flink 的大数据架构体系及 Impala, Es,Kylin 等应用查询引擎。
随着业务的发展,日常工作中会面试各种各样的人,接触下来发现一个比较奇怪的现象:
学习 Spark 的面试者普遍认为 Spark 必然会替代 Hive 成为新的一代大数据仓库标准。
同时,培训市场也出现了 Hive 已经落后,学习大数据只要学习 Spark 相关言论。
但结合实际工作的情况来看,这类说法和实际情况并不相符,针对数据仓库的几个重要特征做了对比,说明各种利弊,希望对今后各位的面试有一定的帮助。
希望后续的面试者能够去积极了解一些数据仓库需要的配置组件及系统,避免人云亦云,面试的时候引起不必要的争议。
数据仓库特点 | hive | spark |
---|---|---|
数据仓库是面向主题的 | 可以实现 | 可以实现 |
数据仓库是集成的(统一存储) | 天然与 HDFS集成 | 可以将数据存储在 HDFS |
数据仓库是不可更新的 | 满足 | 用 HDFS 可以满足 |
元数据管理 | 拥有自己的 meta 库 | 无 meta 库,需要用 Hive 的 |
数据源同步 | Sqoop Flume 等配套组件 | 无相关配套组件 |
由上图可以看出,Spark 不适合作为数据仓库的点有如下几个方面:
反观 Hive,拥有一套完整的 Hadoop 生态组件
基于上面的条件,以目前社区的发展趋势来说,Spark 替代 Hive 成为数据仓库的首选时间会比较漫长,而且随着 Hive 的 sql 执行引擎逐步优化后,Spark 的优势会越来越低。
就目前来说,SparkSql 作为数据仓库上层做加快查询的定位相对合适点,并不适合作为整套数据仓库的尤其是需要强稳定性的底层数据调度查询。
数据仓库是一套系统性工程,如果单纯以计算性能作为唯一选型标准,难免会陷入后续无尽的维护陷阱中。