传统数仓和大数据数仓的区别,传统数仓数据中台

1、效率低
传统的数仓大多构建在Hadoop之上 。这位传统的数仓带来了近乎无限的横向扩展能力 , 同时也造成了传统的数仓技术效率低的缺陷 。效率低主要体现在以下几个方面 。
部署效率低:在部署Hive/HBase/Kylin之前 , 必须部署好Hadoop集群 。和传统数据库相比 , 这个部署效率是非常低效的 。
运维效率低:Hive/HBase/Kylin基于Hadoop , Hadoop生态会带来一个非常严重的单点故障问题 , 即Hadoop体系中任何一个组件出现问题 , 都可能引起整个系统的不可用 。使用传统的数仓对运维的要求非常高 。
计算效率低:主要体现在Hive和Kylin上 , 这两个数仓没有自己的存储引擎和计算引擎 , 这导致Hive和Kylin只能依靠堆机器实现复杂查询 , 而无法从数据本身下手 。在大数据后期 , 一些以数据快速查询为目标而特殊设计的数据存储格式成为标准 , 这个现象才有所改观 。而HBase的优化核心就是重新设计的存储引擎 , 使得HBase可以对数据本身进行查询速度的优化 。
2、延迟高
构建在Hadoop之上的数仓引擎 , 除了效率低的缺点之外 , 还面临着高延迟的挑战 。高延迟主要体现在以下几个方面 。
查询延迟高:使用Hive作为数仓 , 受限于HDFS的性能瓶颈 , Hive的查询速度比较慢 , 难以支撑低延迟场景 , 无法应用在实时计算的场景中 。
写入数据延迟高:同样受限于HDFS , Hive的数据写入延迟也很高 , 这意味着数据无法实时写入Hive , 从而无法支撑实时分析场景 。
3、成本高
传统的数仓数仓引擎还会带来成本高的挑战 , 主要体现在以下几个方面.
部署成本高:由于Hadoop的计算逻辑是通过堆计算资源的方式来摊销复杂查询的时间 , 因此如果需要达到一个比较理想的性能 , 必须要求集群中节点的数量达到一定的规模 , 否则因为计算效率低的特点 , 单机很容易成为性能瓶颈 。这导致了Hive等基于Hadoop的数仓部署成本高的缺陷 。
运维成本高:集群服务器达到一定规模后 , 运维成本会指数级上升 。同时 , 由于Hadoop中组件太多 , 任何一个组件的失效都有可能导致整个服务的不可用 , 因此运维团队必须包含所有组件的运维人员 , 否则运维团队有可能很好地执行任务 。这也极大地提高了运维团队的人力成本 。
存储成本高:Hadoop的HDFS为了避免集群中服务器故障从而导致的不可用的情况 , 默认使用三副本策略存储数据 , 即数据会保存三份 。这会极大地提高存储成本 。即使是新一代的Hadoop采用了EC纠删码技术降低了副本数量 , 但使用场景有限只适合在冷数据存储中使用 , 对于经常需要查询的热数据 , 并不适合采用该方案 。
决策成本高:传统的大数据由于部署成本高 , 导致企业在做决策时面临比较大的决策成本 , 一方面是前期投入太大 , 短期内看不到效果 , 长期以来效果如何也很难说清楚 。另一方面是即使企业下定决心来建设数仓 , 昂贵的基础设施和专业技术人员的缺乏也会造成很长的建设周期 , 长的建设周期又会带来很多不可预知的变数 , 最终影响企业的决策 。
本文摘编自《ClickHouse性能之巅:从架构设计解读性能之谜》 , 经出版方授权发布 。(书号:9787111716587)转载请保留文章出处 。

推荐阅读