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