一键采集上传常见的细节问题(大数据架构和kappa架构的设计思路及难点)
优采云 发布时间: 2022-03-27 01:01一键采集上传常见的细节问题(大数据架构和kappa架构的设计思路及难点)
近年来,随着IT技术、大数据、机器学习、算法的不断发展,越来越多的企业意识到数据的价值,将数据作为自己的宝贵资产进行管理,利用大数据和机器学习。挖掘、识别和利用数据资产的能力。如果缺乏有效的整体数据架构设计或缺乏某些能力,就会导致业务层难以直接使用大数据和大数据,造成大数据与业务之间的巨大差距。存在数据不可知论、需求实现难、数据共享难等一系列问题。本文介绍了一些数据平台设计思路,帮助企业减少数据开发的痛点和难点。
本文主要包括以下章节:
本文第一部分介绍了大数据的基本组成部分和相关知识。
第二部分将介绍 lambda 架构和 kappa 架构。
第三部分将介绍 lambda 和 kappa 架构模式下的通用大数据架构
第四部分介绍了裸露的数据架构体系下数据端到端的难点和痛点。
第五部分介绍优秀大数据架构的整体设计
从第五部分开始,介绍通过各种数据平台和组件将这些大数据组件组合起来,打造一套高效易用的数据平台,提高业务系统的效率,让业务发展无所畏惧复杂的数据开发组件,无需关注底层实现,只需要会使用SQL即可完成一站式开发,完成数据回流,让大数据不再是技能数据工程师。
一、大数据技术栈
大数据的整个过程涉及到很多模块,每个模块都比较复杂。下图列出了这些模块和组件及其功能特性。将有专题详细介绍相关模块的领域知识,如数据采集、数据传输、实时计算、离线计算、大数据存储等相关模块。
二、lambda 架构和 kappa 架构
目前,基本上所有的大数据架构都是基于lambda和kappa架构,不同的公司都基于这两种架构模式设计了符合公司数据架构的数据架构。lambda 架构使开发人员能够构建*敏*感*词*的分布式数据处理系统。它具有良好的灵活性和可扩展性,对硬件故障和人为错误也具有良好的容错能力。您可以在 Internet 文章 上找到很多关于 lambda 架构的信息。kappa架构解决了lambda架构中存在的两组数据处理系统带来的各种成本问题。这也是当前流批集成的研究方向。许多公司已经开始使用这种更高级的架构。
Lambda 架构
卡帕建筑
三、kappa架构和lambda架构下的大数据架构
目前各大公司基本都采用kappa架构或者lambda架构模式。这两种模式下的大数据整体架构在早期发展阶段可能如下:
四、数据端到端痛点
虽然上面的架构看似连接了各种大数据组件来实现集成化管理,但是接触过数据开发的人会强烈地感觉到,这样的裸架构业务数据开发需要注意很多基础工具的使用。在实际数据开发中存在很多痛点和难点,具体体现在以下几个方面。
没有一套数据开发IDE来管理整个数据开发流程,长期的流程是无法管理的。
没有标准的数据建模体系,导致不同的数据工程师对指标的计算口径有不同的误解。
大数据组件的开发要求很高,普通业务直接使用Hbase、ES等技术组件会导致各种问题。
基本上每个公司的大数据团队都会很复杂,涉及的环节很多,遇到问题很难找到对应的负责人。
数据孤岛难以打破,团队和部门之间难以共享数据,彼此之间也不清楚对方拥有哪些数据。
批计算和流计算两套计算模型需要维护,很难上手开发。需要为流和批处理提供一套统一的SQL。
缺乏公司级元数据系统规划,难以实时和离线复用同一条数据,每个开发任务都需要多方梳理。
基本上,大部分企业在数据平台的治理和开放能力的提供上都存在上述问题和痛点。在复杂的数据架构下,对于数据适用方来说,每个环节的不清晰或者功能的不友好,都会让复杂的环节变化更加复杂。要解决这些痛点,就需要精心打磨每一个环节,无缝对接以上技术组件,让业务端到端的数据使用就像写SQL查询数据库一样简单。
五、优秀的大数据整体架构设计
提供多种平台和工具助力数据平台:data采集多数据源平台、一键数据同步平台、数据质量与建模平台、元数据系统、数据统一接入平台、实时和离线计算平台、资源调度平台、一站式开发IDE。
六、元数据——大数据系统的基石
元数据连接数据源、数据仓库和数据应用,记录数据生成到消费的完整环节。元数据收录静态表、列、分区信息(即 MetaStore)。动态任务与表依赖映射关系;数据仓库模型定义、数据生命周期;ETL任务调度信息、输入输出等元数据是数据管理、数据内容和数据应用的基础。例如,元数据可用于构建任务、表、列和用户之间的数据图;构建任务 DAG 依赖关系,并安排任务执行顺序;建立任务画像以管理任务质量;为个人或BUs概述等提供资产管理和计算资源消耗。
可以认为整个大数据数据流是由元数据管理的。如果没有一套完整的元数据设计,上述数据将难以追踪、权限难以控制、资源难以管理、数据难以共享。
很多公司都依赖hive来管理元数据,但是我个人认为,在发展到一定阶段,还是需要搭建一个元数据平台来匹配相关架构。
元数据可以参考饿了么和一些实战:
七、流批一体化计算
如果维护两套计算引擎,比如离线计算Spark和实时计算Flink,会给用户带来很大的麻烦,需要同时学习流计算知识和批计算领域知识。如果你离线使用 Flink 来实时使用 Spark 或 Hadoop,你可以开发自定义的 DSL 描述语言来匹配不同计算引擎的语法。上层用户无需关注底层的具体执行细节。他们只需要掌握一门 DSL 语言即可完成 Spark。接入Hadoop、Flink等计算引擎。
八、直播和离线ETL平台
ETL 代表 Extract-Transform-Load,用于描述从源到目的地提取、转换和加载数据的过程。ETL 一词在数据仓库中更常用,但它的对象并不限于数据仓库。一般来说,ETL平台在数据清洗、数据格式转换、数据补全、数据质量管理等方面发挥着重要作用。ETL作为重要的数据清洗中间层,一般来说至少要具备以下功能:
支持多种数据源,如消息系统、文件系统等
支持多种算子,过滤、拆分、转换、输出、查询数据源补全等算子能力
支持动态变化逻辑。比如上面的算子可以通过动态jar提交,不停机释放变化。
九、智能统一查询平台
大多数数据查询都是由需求驱动的。每个需求开发一个或多个接口,编写接口文档,开放给业务方调用。这种模型在大数据系统中存在很多问题:
这种架构简单,但是接口粒度很粗,灵活性不高,可扩展性差,复用率低。随着业务需求的增加,接口数量大幅增加,维护成本高。
同时,开发效率不高,对于海量数据系统显然会造成大量重复开发,数据和逻辑难以复用,业务适用方的经验严重降低。
如果没有统一的查询平台直接将Hbase等库暴露给业务,后续对数据权限的运维管理会更加困难。访问大数据组件对于业务适用方来说也是非常痛苦的,一不小心就会出现各种问题。.
通过一组智能查询解决上述大数据查询痛点
十、数据仓库建模规范体系
随着业务复杂度和数据规模的增加,数据调用和复制混乱,重复建设造成的资源浪费,数据指标定义不同造成的模糊,数据使用门槛越来越高。以笔者实际业务跟踪和数据仓库使用的见证为例,同产品名的表字段有的叫good_id,有的叫spu_id,还有很多其他的名字,会给想用的人带来很大的麻烦这些数据。因此,如果没有完整的大数据建模体系,会给数据治理带来很大的困难,表现在以下几个方面:
数据标准不一致,即使命名相同,但定义口径不一致。例如,仅 uv 之类的指标就有十几个定义。问题是:它们都是UV,我用哪一个?都是uv,为什么数据不一样?
研发成本巨大,每个工程师都需要从头到尾了解研发过程的每一个细节,每个人都会再次踩到同一个“坑”,浪费了研发人员的时间和精力成本。这也是目标作者遇到的问题。实际开发和提取数据太难了。
没有统一的标准管理,造成重复计算等资源浪费。数据表的层次和粒度不清晰,也使得重复存储很严重。
所以大数据开发和数仓表设计必须遵循设计原则,数据平台可以开发平台来约束不合理的设计,比如阿里巴巴的OneData body。一般来说,数据开发是根据以下准则进行的:
有兴趣的可以参考阿里巴巴的OneData设计系统。
十大一、一键集成平台
一键采集将各种数据传输到数据平台非常简单,通过数据传输平台将数据无缝连接到ETL平台。ETL与元数据平台对接,标准化Schema定义,然后将数据转换分发到实时和离线计算平台。后续对数据的任何离线实时处理,只需要申请元数据表的权限,即可完成开发任务并完成计算。data采集支持多种数据源,如binlog、log采集、前端埋点、kafka消息队列等。
十个二、数据开发IDE——高效的端到端工具
高效的数据开发一站式解决方案工具。实时计算和离线计算任务开发可以通过IDE完成,以上平台对接,提供一站式解决方案。数据开发IDE提供数据集成、数据开发、数据管理、数据质量和数据服务等全方位的产品服务,一站式开发管理界面。数据的传输、转换和集成都是通过数据IDE完成的。从不同的数据存储导入数据,转换开发,最终将处理后的数据同步到其他数据系统。通过一个高效的大数据开发IDE,大数据工程师可以基本屏蔽各种痛点,结合上述各种平台能力,
数据开发工具请参考阿里云DataWorks。
解决端到端的难题还需要其他几个能力的辅助,这里不再赘述。有兴趣的同学可以自学。
十个三、其他
一个完整的数据系统的开发还包括报警监控中心、资源调度中心、资源计算隔离、数据质量检测、一站式数据处理系统,这里不再赘述。