大数据技术架构演进

大数据技术体系一二级架构

大数据技术体系一级架构

前文提到过，所有采用分布式理论解决海量数据的采、存、算、查的技术都可以称为大数据技术。所以，大数据技术体系一级架构一般包含以上几个重要模块，可以看出，基本是围绕业务更好的用数来发展的。

企业构建大数据技术体系时，会在一级架构的范围内，结合业务需要和未来规划目标，选择部分技术组件进行落地，下图罗列了各个一级架构下的核心技术组件。构建初期，一般会通过CDH或HDP的产品套件，来完成数据采集（Sqoop、Flume）、数据存储（HDFS）、资源调度（Yarn）、分布式计算引擎（hive、spark）、集群管理（Ambari/CM）、安全能力（Ranger、kerberos、ldap）的快速引入，这时就已经具备基本的大数据服务能力。

大数据技术体系二级架构

接下来，企业需要根据数据需求、完成数据架构的设计，在数据架构落地过程中，会对技术组件进行深度使用（结合组件的特性进行开发、落地），这时，会出现以下几个阶段：

1.0阶段：完全基于离线的数据处理

这个阶段一般以BI离线分析为主，看板的指标也是小时、或天级别。整体流程通常是，通过任务调度，完成数据的离线抽取、基于hive完成数据计算、在将结果调度到RDB中，BI做数据展现。计算时间一般在分钟级到几十分钟不等，这阶段的技术体系，存储以HDFS为主、计算引擎以hive为主，使用过程中，hive的执行引擎也会先由mapreduce、逐步转换到tez，做一部分的性能优化，但整体的技术架构并没有太大的变化。

1.0阶段1.5阶段：引入SparkSql逐步替代hive完成离线计算

hive效率让人诟病，企业引入spark做相应的尝试，spark是一个客户端服务，可以快速集成到yarn上，基于yarn完成资源调度，并且支持sql、可以对接hive的元数据，相当于直接读hive的表，升级成本是最低的。这个时候引入了新技术Spark，同等情况下，可以提升5~8倍的性能。

1.5阶段2.0阶段：lambda架构大数据架构标准，实时处理与离线处理并存

数据同步、计算流程以离线为主，做固化的数据处理加工，但有一些指标需要实时计算，所以会引入实时计算引擎，这时候数据处理就多了一个链路，上游将数据生产到kafka中SparkStreaming/Storm作为消费者进行数据消费，实时计算处理后，将数据写入查询效率较高的存储中，如ClickHouse、Hbase，或MPP数据库中，通过新建数据链路，来满足数据的实时计算需求。这也是人们熟知的lambda架构、这个架构最大的问题是，数据链路维护两份，开发成本较高，同时，两个链路的计算结果需要做指标对账，存在业务逻辑、计算逻辑不一致的风险。

2.0阶段3.0阶段：完全基于实时处理的初级版

这阶段完全是为了解决lambda架构的短板，避免维护两套数据链路所带来的隐患，通过kafka做数据的存储，通过topic的命名来区分数据架构的层级，下游通过Flink/SparkStreaming进行数据消费、处理，再将结果数据写回到kafka中，根据需要可以再将数据写入到查询效率较高的存储中，来满足应用的实时查询需求。这种方式在一定程度上可以避免数据二义性的问题，但是开发成本较高，存在无法精准消费一次的风险，数据迁移、同步都有一定的技术门槛。这些问题让部分公司望而却步。

3.0阶段4.0阶段：完全基于实时处理的高级版

初级版的问题在于数据存储基于kafka来完成，可以尝试引入数据湖的解决方案，如iceberg、hudi、deltalake做数据的存储，通过CDC技术对上游数据库变更日志进行抓取，下游直接连接到数据湖，既解决了hive离线数仓upsert能力较弱的问题，又支持了数据的准实时还原，可以很好的应对企业数据处理的需求。

5.0云原生阶段

前几个阶段，始终无法脱离底层存储是HDFS（iceberg是在hdfs之上做的扩展），在当下云原生环境的背景下，OSS（对象存储）作为底层存储的优势不言而喻，可以做到计算和存储完全分离、计算引擎完全托管到K8S集群上，数据存储完全基于OSS，同时引入数据缓存技术，来加速OSS的数据访问，可以更好的支持企业弹性扩缩容的计算需求。

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!