大数据技术架构演化

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

大数据技术架构演化_第1张图片
  前文提到过,所有采用分布式理论解决海量数据的采、存、算、查的技术都可以称为大数据技术。所以,大数据技术体系一级架构一般包含以上几个重要模块,可以看出,基本是围绕业务更好的用数来发展的。
  企业构建大数据技术体系时,会在一级架构的范围内,结合业务需要和未来规划目标,选择部分技术组件进行落地,下图罗列了各个一级架构下的核心技术组件。构建初期,一般会通过CDH或HDP的产品套件,来完成数据采集(Sqoop、Flume)、数据存储(HDFS)、资源调度(Yarn)、分布式计算引擎(hive、spark)、集群管理(Ambari/CM)、安全能力(Ranger、kerberos、ldap)的快速引入,这时就已经具备基本的大数据服务能力。
大数据技术架构演化_第2张图片
  接下来,企业需要根据数据需求、完成数据架构的设计,在数据架构落地过程中,会对技术组件进行深度使用(结合组件的特性进行开发、落地),这时,会出现以下几个阶段:

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

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

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

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

2.0阶段:lambda架构,实时处理与离线处理并存

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

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

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

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

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

5.0云原生阶段

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

大数据技术架构演化_第8张图片

我是IT指北,欢迎关注公众号:IT转型指北,定期更新高质量文章,记录所思、所想、所感!
关注公众号IT转型指北,回复【经典书籍】,可获取高质量大数据电子书
大数据技术架构演化_第9张图片

你可能感兴趣的:(big,data,架构,lambda,hadoop)