精华内容
下载资源
问答
  • 仓库管理体系架构图
    千次阅读
    2014-01-15 08:34:10

    简介


    数据仓库架构,是IT架构的一个分支,随着数据在企业的核心作用的增强,数据仓库的架构日益重要。数据仓库架构由于其技术选择非常广泛,看上去复杂,不过背后有一套比较稳定的思路,这也是数据仓库架构设计的一个要点,稳定中蕴含变化,变化中蕴含稳定。

    总体来说,数据仓库架构分成两大块,一是硬件架构,二是软件架构。硬软架构又可以分成封闭式和开放式。封闭式硬件架构代表厂商有teradata,其硬件是专属的,必须使用特殊的硬件才能运行。开放式硬件架构的代表有oracle,可以运行在各种硬件上,不过开放和封闭之间的界限也逐步的融合,oracle也开始打包hp的专属硬件来推广其dw的方案,而teradata也开始用基于suse的os可运行的硬件上提供其dw产品。封闭式硬件好处是开箱即用,经过厂商的严格测试,保障性比较高,开放式硬件则需要企业具备很强大的技术实力,能够有一支具备硬件,存储,操作系统综合知识和能力的团队,在组合成一套可以运行dw软件的基础平台,并且在发现问题的时候要能很快速的定位问题的原因并解决。

    数据仓库的软件架构选择更加丰富。从数据库软件,etl软件,展现软件,数据挖掘软件,每一种类型里面都具备非常多的选择。这些软件的选择是架构设计的一部分,架构设计的重要核心一部分是综合这些软件的一套思路,在一套dw架构设计的思路下,软件可以很灵活的进行选择。

    软件物理架构主要特征区别就是行存储和列存储。这个也是曾经很多厂商津津乐道的地方,根据需求的不同,2种方式可以灵活采用。大部分db软件都是采用行存储,而列存储的特征在于高效的单列值压缩,在选择列比较少的时候需要io要求很低,速度很快,不过行存储的db目前在压缩效率上也在迅速提升,大部分需求还是选择行数据进行观察,行存储也更加便于表的按记录拆分进行并行化。

    Yahoo数据仓库


    Yahoo数据仓库在基础架构上由hadoop集群和Oracle集群组成,hadoop集群是一个计算平台,完成所有ETL数据处理过程;Oracle集群只是一个查询环境。 

     数据通过Data highway从源系统加载进入数据仓库的ODS层,ODS层数据保持与源系统数据结构一样。EDW数据层并没有严格意义的数据层次的逻辑细分,它可能有 多层的ETL加工过程;多层的数据存储。这一个层数据主要采用维度建模的方法,根据应用需求建立数据模型。数据采用列式存储的数据结构存储。 数据经过加工处理完成后,数据将会同步到Oracle的集群中用做数据查询。

    Yahoo用Oracle做查询环境,他们的大量采用了基于时间RANGE分区和HASH子分区的方式来提升查询响应性能(类似与Greenplum的方式)。数据采用了压缩技术,同时基于压缩和读取的方式上ORACLE官方为他们定制了一些改进,从而获取更好的读取IO和压缩能力。 MSTR报表工具连接ORALCE完成大部分报表查询功能,同时,如果要查询最明细的数据,工具会连接到HADOOP集群上,通过创建一些临时表来满足查询功能。 同时,Yahoo的仓库配备了一个功能强大的元数据管理系统,他们的元数据是通过SQL解析,直接将ETL mapping的元数据解析进入元数据库,做到了字段级别的MAPPING。同时他们的PM会维护最新的业务元数据(业务规则,指标定义)进入的元数据库系统。

    更多相关内容
  • 商业银行风险管理架构体系.pdf商业银行风险管理架构体系.pdf商业银行风险管理架构体系.pdf商业银行风险管理架构体系.pdf商业银行风险管理架构体系.pdf商业银行风险管理架构体系.pdf商业银行风险管理架构体系.pdf商业...
  • 商业银行风险管理架构体系.docx商业银行风险管理架构体系.docx商业银行风险管理架构体系.docx商业银行风险管理架构体系.docx商业银行风险管理架构体系.docx商业银行风险管理架构体系.docx商业银行风险管理架构体系....
  • Hadoop简介和体系架构

    千次阅读 多人点赞 2022-03-17 19:23:32
    2.2 Hadoop的体系架构 2.2.1 分布式文件系统HDFS 2.2.2 分布式计算框架MapReduce 2.2.3 分布式资源调度系统YARN 2. 2. 4三大发行版本 2.1 Hadoop简介 自从大数据的概念被提出后,出现了很多相关技术,...

    目录

    2.1 Hadoop简介

    2.1.1 Hadoop由来

    2.1.2 Hadoop发展历程

     2.1.3 Hadoop生态系统

     2.2 Hadoop的体系架构

     2.2.1 分布式文件系统HDFS

    2.2.2 分布式计算框架MapReduce 

     2.2.3 分布式资源调度系统YARN

    2.  2.  4 三大发行版本


    2.1 Hadoop简介


    自从大数据的概念被提出后,出现了很多相关技术,其中对大数据发展最有影响力的就是开源分布式计算平台Hadoop,它就像软件发展史上的Window、Linux、Java一样,它的出现给接下来的大数据技术发展带来了巨大的影响。很多知名公司都加入Hadoop相关项目的开发中,如Facebook、Yahoo等,围绕大数据Hadoop技术产生了一系列大数据的相关技术

    如 Spark、Hive、HCatalog、HBase、Zookeeper、Oozie、Pig和Sqoop等,这些项目组成 了大数据技术的开源生态圈,开源的Hadoop项目极大的促进了大数据技术在很多行业的应用发展

    本章将详细介绍hadoop的由来和相关项目,最新的hadoop2.0的体系架构,以及在学习hadoop前,必须掌握的技术基础(Java语言和编程、关系型数据库、Linux操作系统等)

    211 Hadoop由来

    Hadoop起源于Google的三大论文:

    GFS:Google的分布式文件系统Google File System

    MapReduce:Google的MapReduce开源分布式并行计算框架

    BigTable:一个大型的分布式数据库

    演变关系

    GFS—->HDFS

    Google MapReduce—->Hadoop MapReduce

    BigTable—->HBase

    212 Hadoop发展历程

     213 Hadoop生态系统

     图中涉及的技术名词解释如下:

    1、Sqoop:Sqoop是一款开源的工具,主要用于在Hadoop、Hive与传统的数据库(MySql)间进行数据的传递,可以将一个关系型数据库(例如 :MySQL,Oracle 等)中的数据导进到Hadoop的HDFS中,也可以将HDFS的数据导进到关系型数据库中。

    2、Flume:Flume是Cloudera提供的一个高可用的,高可靠的,分布式的海量日志采集、聚合和传输的系统,Flume支持在日志系统中定制各类数据发送方,用于收集数据;同时,Flume提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力。

    3、Kafka:Kafka是一种高吞吐量的分布式发布订阅消息系统,有如下特性:

            (1)通过O(1)的磁盘数据结构提供消息的持久化,这种结构对于即使数以TB的消息存储也能够保持长时间的稳定性能。

            (2)高吞吐量:即使是非常普通的硬件Kafka也可以支持每秒数百万的消息。

            (3)支持通过Kafka服务器和消费机集群来分区消息。

            (4)支持Hadoop并行数据加载。

    4、Storm:Storm用于“连续计算”,对数据流做连续查询,在计算时就将结果以流的形式输出给用户。

    5、Spark:Spark是当前最流行的开源大数据内存计算框架。可以基于Hadoop上存储的大数据进行计算。

    6、Oozie:Oozie是一个管理Hadoop作业(job)的工作流程调度管理系统。

    7、Hbase:HBase是一个分布式的、面向列的开源数据库。HBase不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库。

    8、Hive:Hive是基于Hadoop的一个数据仓库工具,可以将结构化的数据文件映射为一张数据库表,并提供简单的SQL查询功能,可以将SQL语句转换为MapReduce任务进行运行。 其优点是学习成本低,可以通过类SQL语句快速实现简单的MapReduce统计,不必开发专门的MapReduce应用,十分适合数据仓库的统计分析。

    10、R语言:R是用于统计分析、绘图的语言和操作环境。R是属于GNU系统的一个自由、免费、源代码开放的软件,它是一个用于统计计算和统计制图的优秀工具。

    11、Mahout:Apache Mahout是个可扩展的机器学习和数据挖掘库。

    12、ZooKeeper:Zookeeper是Google的Chubby一个开源的实现。它是一个针对大型分布式系统的可靠协调系统,提供的功能包括:配置维护、名字服务、 分布式同步、组服务等。

    ZooKeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。


     2.2 Hadoop的体系架构


     221 分布式文件系统HDFS

     

    HDFS 是一种分布式文件系统,为在商用硬件上运行而设计。HDFS具有高度容错能力,旨在部署在低成本的硬件上。HDFS提供对应用程序数据的高吞吐量访问,适用于具有大型数据集的应用程序

    HDFS采用 Master/Slave 的架构来存储数据,该架构主要由4个部分组成

    1. Client:切片,用来与NameNode交互
    2. NameNOde节点
    3. DataNode节点
    4. SecondaryNameNode节点

    2.2.2 分布式计算框架MapReduce 

    Hadoop MapReduce是一个软件框架,用于轻松编写应用程序,以可靠容错的方式在大型集群的商用硬件上并行处理大量数据。

    MapReduce作业通常将输入数据集拆分为独立的块,这些块由Map任务以完全并行的方式处理。框架对地图的输出进行排序然后输入到Reduce任务中。

    MapReduce将计算过程分为两个阶段:Map和Reduce

    1. Map阶段并行处理输入数据
    2. Reduce阶段对Map结果进行汇总

     

     223 分布式资源调度系统YARN

     

    从YARN的架构图来看,它主要由ResourceManager和ApplicationMaster、NodeManager、 ApplicationMaster和Container等组件组成

    ResourceManager(RM)

    YARN分层结构的本质是ResourceManager。这个实体控制整个集群并管理应用程序向基础计算资源的分配。

    ResourceManager 将各个资源部分(计算、内存、带宽等)精心安排给基础NodeManager(YARN 的每节点代理)。ResourceManager还与 ApplicationMaster 一起分配资源,与NodeManager 一起启动和监视它们的基础应用程序。在此上下文中,ApplicationMaster 承担了以前的 TaskTracker 的一些角色,ResourceManager 承担了 JobTracker 的角色。

    1. 处理客户端请求;
    2. 启动或监控ApplicationMaster;
    3. 监控NodeManager;
    4. 资源的分配与调度。

    NodeManager(NM)

     NodeManager管理一个YARN集群中的每个节点。NodeManager提供针对集群中每个节点的服务,从监督对一个容器的终生管理到监视资源和跟踪节点健康。MRv1通过插槽管理Map和Reduce任务的执行,而NodeManager 管理抽象容器,这些容器代表着可供一个特定应用程序使用的针对每个节点的资源。YARN继续使用HDFS层。它的主要 NameNode用于元数据服务,而DataNode用于分散在一个集群中的复制存储服务。

    1. 单个节点上的资源管理;
    2. 处理来自ResourceManager上的命令;
    3. 处理来自ApplicationMaster上的命令。

    ApplicationMaster(AM)  ApplicationMaster管理一个在YARN内运行的应用程序的每个实例。ApplicationMaster 负责协调来自 ResourceManager 的资源,并通过 NodeManager 监视容器的执行和资源使用(CPU、内存等的资源 分配)。请注意,尽管目前的资源更加传统(CPU 核心、内存),但未来会带来基于手头任务的新资源 类型(比如图形处理单元或专用处理设备)。从 YARN 角度讲,ApplicationMaster 是用户代码,因此 存在潜在的安全问题。YARN 假设 ApplicationMaster 存在错误或者甚至是恶意的,因此将它们当作无特权的代码对待。

    1. 负责数据的切分;
    2. 为应用程序申请资源并分配给内部的任务;
    3. 任务的监控与容错

    Container

    对任务运行环境进行抽象,封装CPU、内存等多维度的资源以及环境变量、启动命令等任务运行相关的信息。比如内存、CPU、磁盘、网络等,当AM向RM申请资源时,RM为AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container,且该任务只能使用该Container中描述的资源。

    2.  2.  4 三大发行版本

    Hadoop三大发行版本:Apache、Cloudera、Hortonworks。

    Apache版本:最原始(最基础)的版本,对于入门学习最好。

    Cloudera:在大型互联网企业中用的较多。

    Hortonworks:文档较好。

    1. Apache Hadoop

    官网地址:http://hadoop.apache.org/releases.html 

    下载地址:https://archive.apache.org/dist/hadoop/common/

    2. Cloudera Hadoop

    官网地址:https://www.cloudera.com/downloads/cdh/5-10-0.html 

    下载地址:http://archive-primary.cloudera.com/cdh5/cdh/5/

    (1)2008年成立的Cloudera是最早将Hadoop商用的公司,为合作伙伴提供Hadoop的商用解决方案,主要是包括支持、咨询服务、培训。

    22009Hadoop的创始人Doug Cutting也加盟Cloudera公司Cloudera产品主要为CDH

    Cloudera Manager,Cloudera Support

    (3CDH是Cloudera的Hadoop发行版,完全开源,比Apache Hadoop在兼容性,安全性,稳定性上有所增强。

    (4Cloudera Manager是集群的软件分发及管理监控平台,可以在几个小时内部署好一个Hadoop集群,并对集群的节点及服务进行实时监控。Cloudera Support即是对Hadoop的技术支持。

    (5Cloudera的标价为每年每个节点4000美元。Cloudera开发并贡献了可实时处理大数据的Impala 项目。

    3. Hortonworks Hadoop

    官网地址:https://hortonworks.com/products/data-center/hdp/ 

    下载地址:Cloudera Enterprise Downloads

    (12011年成立的Hortonworks是雅虎与硅谷风投公司Benchmark Capital合资组建。

    2公司成立之初就吸纳了大约25名至30名专门研究Hadoop的雅虎工程师,上述工程师均在2005年开始协助雅虎开发Hadoop,贡献了Hadoop80%的代码。

    3雅虎工程副总裁、雅虎Hadoop开发团队负责人Eric Baldeschwieler出任Hortonworks的首席执行官。

    4Hortonworks的主打产品是Hortonworks Data Platform(HDP),也同样是100%开源的产品,HDP除常见的项目外还包括了Ambari,一款开源的安装和管理系统。

    5HCatalog,一个元数据管理系统,HCatalog现已集成到Facebook开源的Hive中。Hortonworks 的Stinger开创性的极大的优化了Hive项目。Hortonworks为入门提供了一个非常好的,易于使用的沙盒。

    6Hortonworks开发了很多增强特性并提交至核心主干,这使得Apache Hadoop能够在包括Window Server和Windows Azure在内的Microsoft Windows平台上本地运行。定价以集群为基础,每10个节点每年为12500美元。目前,HDP已被CDH收购。

    展开全文
  • 本课程在前期智慧中台专题《如何进行中台架构设计》、《简析数据中台公共能力要点》、《数据湖与数据仓库之争》、《基于数据湖数据中台解决方案》、《数据集市解决方案》、《如何构建数据质量方案》、《大数据技术...
  • Hadoop体系架构

    2020-12-18 14:45:30
    Hadoop是一个由Apache基金会所开发的分布式系统基础架构。 Hadoop是一个开源框架,可编写和运行分布式应用处理大规模数据。Hadoop的框架最核心的设计就是:HDFS和MapReduce。HDFS为海量的数据提供了存储,而...

    大数据时代所面临的两个问题为,数据的存储和计算
    Hadoop的出现就解决了这两种所面临的问题。
    Hadoop是一个由Apache基金会所开发的分布式系统基础架构。

    Hadoop是一个开源框架,可编写和运行分布式应用处理大规模数据。Hadoop的框架最核心的设计就是:HDFS和MapReduce。HDFS为海量的数据提供了存储,而MapReduce则为海量的数据提供了计算。

    Hadoop起源于谷歌的三篇论文(GFS、MapReduce、BigTable)。

    名字起源:Hadoop这个名字不是一个缩写,而是一个虚构的名字。该项目的创建者,Doug Cutting解释Hadoop的得名 :“这个名字是我孩子给一个棕黄色的大象玩具命名的。我的命名标准就是简短,容易发音和拼写,没有太多的意义,并且不会被用于别处。小孩子恰恰是这方面的高手。”

    hadoop的特点:

    高可靠性。Hadoop按位存储和处理数据的能力值得人们信赖。

    高扩展性。Hadoop是在可用的计算机集簇间分配数据并完成计算任务的,这些集簇可以方便地扩展到数以千计的节点中。

    高效性。Hadoop能够在节点之间动态地移动数据,并保证各个节点的动态平衡,因此处理速度非常快。

    高容错性。Hadoop能够自动保存数据的多个副本,并且能够自动将失败的任务重新分配。

    低成本。与一体机、商用数据仓库以及QlikView、Yonghong Z-Suite等数据集市相比,hadoop是开源的,项目的软件成本因此会大大降低。
    Hadoop生态框架

    大数据的应用场景:

    1:各大电商平台个性化推荐(京东,淘宝);

    2:根据上网轨迹,构建用户画像,实现精准推送(今日头条,淘宝,京东)

    3:海关历年数据分析,决策辅助

    4:医疗(对多年同专业数据进行分析)

    5:农业

    Hadoop技术框架简介:

    HDFS:Hadoop中的重要组件之一,用来做分布式存储,具有高容错,高吞吐等特性,是常用的分布式文件存储

    MR(MapReduce简称):Hadoop中的重要组件之一,作为分布式计算模型,程序人员只需在Mapper、Reducer中编写业务逻辑,然后直接交由框架进行分布式计算即可。

    Yarn:Yarn是Hadoop中的重要组件之一,负责海量数据运算时的资源调度

    Flume: Flume是Cloudera提供的一个高可用的,高可靠的,分布式的海量日志采集、聚合和传输的系统,用来做数据采集。

    Kafka:分布式的消息发布/订阅系统,通过与Spark Streaming整合,完成实时业务计算。由Java+scala开发。

    Hive/Pig:hive是基于Hadoop的一个数据仓库工具,通过将结构化的数据文件(通常为HDFS文件)映射为一张数据表,提供简单的sql查询功能,将sql语句转换为MapReduce任务运行。

    pig可以看做hadoop的客户端软件,可以连接到hadoop集群进行数据分析工作,企业中很少用了。

    Hbase:HBase是建立在Hadoop文件系统之上的面向列的分布式数据库。不同于一般的关系数据库,适合于存储非结构化的数据,HBase基于列而不是基于行。

    Redis:Redis 可基于内存也可以持久化的日志型、Key-Value数据库。往往用来缓存key-value类型的小表数据。

    Sqoop:负责数据在 HIVE—HDFS—DB之间进行导入导出

    Standalone:是Spark提供的资源管理器,

    Mesos:也是Apache下的开源分布式资源管理器。

    Spark:Spark是大规模数据快速处理通用的计算引擎,其提供大量的库:Spark Core、Spark SQL、Spark Streaming、MLlib、GraphX 。(只是计算,不作存储)。
    大数据的数据级别及换算:

    换算基本都是以2的10次方来递增的
    1KiB(Kilobyte)=1024B ,即2的10次方字节,读音“千字节”
    1MiB(Megabyte)=1024KiB,即2的20次方字节,读音“兆字节”
    1GiB(Gigabyte)=1024MiB,即2的30次方字节,读音“吉字节”
    1TiB(Terabyte)=1024GiB,即2的40次方字节,读音“太字节”
    1PiB(Petabyte)=1024TiB,即2的50次方字节,读音“拍字节”
    1EiB(Exabyte) =1024PiB,即2的60次方字节,读音“艾字节”
    1ZiB(Zettabyte)=1024EiB,即2的70次方字节,读音“Z字节”
    1YiB(Yottabyte)=1024ZiB,即2的80次方字节,读音“Y字节”
    传说中还有
    1NiB(NonaByte)=1024YiB,即2的90次方字节
    1DiB(DoggaByte)=1024NiB,即2的100次方字节
    1CiB(Corydonbyte )=1024DiB,即2的110次方字节

    话不多说,下一章解释一下Hadoop是如何解决了存储和计算的问题。

    展开全文
  • 数据仓库架构

    2022-04-19 17:22:09
    1. 大数据架构演变(数仓架构演变) 1.1 传统离线大数据架构 21世纪初随着互联网时代的到来,数据量暴增,大数据时代到来。Hadoop生态群及衍生技术慢慢走向“舞台”,Hadoop是以HDFS为核心存储,以MapReduce(简称MR...

    大数据架构演变(数仓架构演变)

    传统离线大数据架构

    21世纪初随着互联网时代的到来,数据量暴增,大数据时代到来。Hadoop生态群及衍生技术慢慢走向“舞台”,Hadoop是以HDFS为核心存储,以MapReduce(简称MR)为基本计算模型的批量数据处理基础设施,围绕HDFS和MR,产生了一系列的组件,不断完善整个大数据平台的数据处理能力,例如面向KV操作的HBase、面向SQL分析的Hive、面向工作流的PIG等。以Hadoop为核心的数据存储及数据处理技术逐渐成为数据处理中的“中流砥柱”,部分技术栈如下图所示:

    image.png

    这个时期,在企业信息化的过程中,随着信息化工具的升级和新工具的应用,数据量变的越来越大,数据格式越来越多,决策要求越来越苛刻,数据仓库技术在大数据场景中被广泛使用。大数据中的数据仓库构建就是基于经典数仓架构而来,使用大数据中的工具来替代经典数仓中的传统工具,架构建设上没有根本区别。在离线大数据架构中离线数仓结构如下:
    image.png

    随着数据处理能力和处理需求的不断变化,越来越多的用户发现,批处理模式无论如何提升性能,也无法满足一些实时性要求高的处理场景,流式计算引擎应运而生,例如Storm、Spark Streaming、Flink等。

    以上离线大数据架构不能够处理实时性业务,早期,很过公司都是基于Storm来处理处理实时性比较强的业务场景,随着越来越多的应用上线,大家发现,其实批处理和流计算配合使用,才能满足大部分应用需求。而对于用户而言,其实他们并不关心底层的计算模型是什么,用户希望无论是批处理还是流计算,都能基于统一的数据模型来返回处理结果,于是Lambda架构被提出。

    Lambda架构

    在Lambda架构中,为了计算一些实时指标,就在原来的离线数仓基础之上增加了一个实时计算的链路,并对数据源做流式改造:把消息发送到消息队列中(大数据中常用Kafka),实时计算去消费消息队列中的数据,完成实时指标计算,推送到下游的数据服务中去,由数据服务层完成离线与实时结果的合并。

    Lambda架构中数据从底层的数据源开始,经过各种各样的格式进入大数据平台,在大数据平台中经过Kafka、Flume等数据组件进行收集,然后分成两条线进行计算。一条线是进入流式计算平台(例如 Storm、Flink或者Spark Streaming),去计算实时的一些指标,保证数据实时性;另一条线进入批量数据处理离线计算平台(例如Mapreduce、Hive,Spark SQL),去计算T+1的相关业务指标,这些指标需要隔日才能看见,保证数据有效、准确性。

    根据实时业务统计的复杂程度Lambda架构也分为以下两种情况。

    离线数据+实时处理链路(传统实时开发)

    根据实时链路中实时指标计算的复杂程度,开始实时业务不复杂,都是“烟囱(cong)式”开发设计,不需要构建实时数仓,我们可以选择不分层,这种场景下Lambda架构中是由离线数仓和实时业务处理部分组成,这部分实时还达不到叫做实时数仓阶段,只能叫做实时处理链路,其结构如下:image.png

    image.png

    注意:“烟囱式”开发:在一个有一定规模的企业中,通常都会存在各种各样的应用系统,它们分别由企业的各个不同部门、在各种不同历史时期、为满足各种不同业务目的而开发。由于数据格式没有统一规范,相互之间没有联通、数据更没有整合,像一个个烟囱,因此称其为“烟囱式系统”。同样,在数据处理过程中,各个数据处理程序之间不能很好做到数据规范统一、处理数据流程统一、数据复用,各自独立,叫做“烟囱式”开发。

    离线数仓+实时数仓

    随着企业实时业务增多,统计的实时指标越来越多,复杂程度也越来越高,为了在实时链路中更好的复用数据,这是就有必要在实时链路中加入数据分层设计,构建真正的实时数仓。这种场景下Lambda架构中是由离线数仓和实时数仓两部分组成,其结构如下:

    image.png

    以上Lambda架构中“实时处理链路”这种传统实时与“实时数仓”区别在于,传统实时“烟囱式”开发导致代码耦合问题严重,当需求越来越多,有时需要明细数据,有时需要OLAP分析,这种模式难以应付这些需求,缺少完善的规范。“实时数仓”在保证数据实时性的前提下,实现了数据基于数据仓库管理,更加统一规范化,稳定性和业务性更强。

    在Lambda架构中流处理计算的指标批处理依然计算,最终以批处理结果为准,即每次批处理计算后会覆盖流处理的结果,这是由于流处理过程中不完善做的折中办法,由数据服务处理,其功能主要是合并离线计算和实时计算结果。例如:在统计实时交易订单时,可能实时统计的结果需要当日分钟级别向外展示,T+1后才能展示昨日总的交易订单数,显然,后者是T+1每日离线批处理统计结果,那么假设当日有些用户进行了订单取消有可能T+1后统计统计结果与当日实时展示数据出现不一致问题,那么这里就需要使用数据服务来进行处理,统一数据,决定如何使用数据。

    Lambda数据架构成为每一个公司大数据平台必备的架构,它解决了一个公司大数据批量离线处理和实时数据处理的需求。Lambda架构的核心理念是“流批一体”,如上图所示,整个数据流向自左向右流入平台。进入平台后一分为二,一部分走批处理模式,一部分走流式计算模式。无论哪种计算模式,最终的处理结果都通过统一服务层对应用提供,确保访问的一致性,底层到底是批或流对用户透明。经历多年的发展,Lambda架构优点是稳定,对于实时计算部分的计算成本可控,批量处理可以用晚上的时间来整体批量计算,这样把实时计算和离线计算高峰分开,但是它也有一些致命缺点:

    1. 同样的需求需要开发两套一样的代码

    这是Lambda架构最大的问题,针对同一个需求需要开发两套代码,一个在批处理引擎上实现,一个在流处理引擎上实现,在写好代码后还需构造数据测试保证两者结果一致,另外,两套代码对于后期维护也非常麻烦,一旦需求变更,两套代码都需要修改,并且两套代码也需同时上线。

    1. 集群资源使用增多

    同样的逻辑需要计算两次,整体占用资源会增多。虽然离线部分是在凌晨运行,但是有可能任务多,在凌晨时造成集群资源使用暴增,报表产出效率就有可能下降,报表延迟对后续展示也有影响。

    1. 离线结果和实时结果不一致

    在此架构中经常我们看到次日统计的结果比昨晚的结果要少,原因就在于次日统计结果和昨日统计结果走了两条线的计算方式:次日统计结果是按照批处理得到了更为准确的批量处理结果。昨晚看的结果是通过流式运行的结果,依靠实时链路统计出的实时结果(实时结果统计累加),牺牲了部分准确性。对于这种来自批量和实时的数据结果对不上的问题,无解。

    1. 批量计算T+1可能计算不完

    随着物联网时代的到来,一些企业中数据量级越来越大,经常发现夜间运行批量任务已经无法完成白天20多个小时累计的数据,保证早上上班前准时出现数据已成为部分大数据团队头疼的问题。

    1. 服务器存储大

    由于批流两个过程都需要将数据存储在集群中,并且中间也会产生大量临时数据,会造成数据急速膨胀,加大服务器存储压力。

    Kappa架构

    随着Flink等流式处理引擎的不断完善,流处理技术相关的技术成熟发展(例如:Kafka、ClickHouse),针对Lambda架构的需要维护两套程序等以上缺点,LinkedIn的Jay Kreps结合实际经验和个人体会提出了Kappa架构。

    Kappa架构的核心思想是通过改进流计算系统来解决数据全量处理的问题,使得实时计算和批处理过程使用同一套代码。此外Kappa架构认为只有在有必要的时候才会对历史数据进行重复计算,而如果需要重复计算时,Kappa架构下可以启动很多个实例进行重复计算,方式是通过上游重放完成(从数据源拉取数据重新计算)。

    Kappa架构就是基于流来处理所有数据,流计算天然的分布式特征,注定了他的扩展性更好,通过加大流计算的并发性,加大流式数据的“时间窗口”,来统一批处理与流式处理两种计算模式。其架构如下:
    image.png

    Kappa架构构建的数仓当之无愧称为实时数仓,Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理,但这个可以通过增加计算资源来弥补。重新处理数据看似比较麻烦,但在Kappa架构中并不复杂,其步骤如下:
    image.png

    1. 选择一个具有重放功能,能够保存历史数据的消息队列,根据要求设置历史数据保存时长,例如:Kafka,可以设置保存全部历史数据。
    2. 当某个或某些指标有重新处理的需求时,按照新逻辑编写新的作业,然后从上游消息队列最开始地方重新消费数据,把结果写往一个新的下游结果表。
    3. 当新作业赶上进度后,切换数据源,读取新作业产生的结果表。
    4. 停止老的作业,删除老的结果表。

    另外,Kappa 架构并不是中间结果完全不落地,现在很多大数据系统都需要支持机器学习(离线训练),所以实时中间结果需要落地对应的存储引擎供机器学习使用,另外有时候还需要对明细数据查询,这种场景也需要把实时明细层写出到对应的引擎中。

    Kappa架构也有一定的缺点,其缺点例如:Kappa架构由于采集的数据格式不统一,每次都需要开发不同的Streaming程序,导致开发周期长。更多Kappa架构的问题在实时数仓发展趋势中讨论。

    混合架构

    传统离线大数据架构已经不能满足一些公司中实时业务需求,因为随着互联网及物联网发展,越来越多的公司多多少少涉及一些流式业务处理场景。由Lambda离线数仓+实时数仓架构到Kappa实时数仓架构,都涉及到实时数仓开发,那么现实业务开发中到底使用Lambda架构还是Kappa架构?

    我们可以先看下以上三个架构之间的区别:

    对比项传统离线大数据架构Lambda架构Kappa架构
    实时性离线(无法处理实时业务)离线+实时实时(批流一体)
    计算资源只有批处理批和流同时运行,资源消耗大只有流处理,资源开销小
    重新计算时吞吐量批处理全量处理,吞吐量大批处理全量处理,吞吐量大流式全量处理,吞吐较批处理全量要低一些
    开发、测试难度批处理一套代码,开发、测试、上线难度小批处理和流处理相同逻辑两条代码,开发、测试、上线难度大只需实现一套代码,开发、测试、上线难度相对较小
    运维成本维护一套引擎,运维成本小维护两套引擎,运维成本大维护一套引擎,运维成本小

    通过以上对比来看,三者对比结果如下:

    从架构上来看 ,三套架构有比较明显区别,真正的实时数仓以Kappa架构为主,而离线数仓以传统离线大数据架构为主,Lambda架构可以认为是两者的中间态。目前在业界中所说的实时数仓大多是Lambda架构,这是由需求决定的。

    从建设方法上来看 ,实时数仓和离线数仓基本还是沿用传统的数仓主题建模理论,产出事实宽表。另外实时数仓中实时流数据的join有隐藏时间语义,在建设中需注意。

    从数据保障上来看 ,实时数仓因为要保证实时性,所以对数据量的变化较为敏感,在大促等场景下需要提前做好压测和主备保障工作,这是与离线数仓较为明显的一个区别。

    目前在一些没有实时数据处理场景公司中,使用传统离线大数据架构居多,在这些公司中离线大数据架构性价比高,比较实用。

    在一些涉及到实时业务场景的公司,在实际工作中到底选择哪种架构,需要根据具体业务需求来决定。很多时候并不是完全规范的Lambda架构或者Kappa架构,可以是两者的混合,比如大部分实时指标统计使用Kappa架构完成计算,少量关键指标使用Lambda架构用批处理重新计算,增加一次校对过程。为了应对更广泛的场景,大多数公司采用这种混合架构,离线和实时数据链路都存在,根据每个业务需求选择在合适的链路上来实现。注意:这种方式并不是Lambda架构,例如:某企业有多个业务模块,某些业务模块需要运行在Lambda架构中,某些业务模块需要运行在Kappa架构中。

    实时数仓发展趋势

    当前基于Hive的离线数据仓库已经非常成熟,随着实时计算引擎的不断发展以及业务对于实时报表的产出需求不断膨胀,业界最近几年就一直聚焦并探索于实时数仓建设。根据数仓架构演变过程,在Lambda架构中含有离线处理与实时处理两条链路,其架构图如下:
    image.png
    正是由于两条链路处理数据导致数据不一致等一些列问题所以才有了Kappa架构,Kappa架构如下:
    image.png

    Kappa架构可以称为真正的实时数仓,目前在业界最常用实现就是Flink + Kafka,然而基于Kafka+Flink的实时数仓方案也有几个非常明显的缺陷,所以在目前很多企业中实时数仓构建中经常使用混合架构,没有实现所有业务都采用Kappa架构中实时处理实现。Kappa架构缺陷如下:

    1. Kafka无法支持海量数据存储。对于海量数据量的业务线来说,Kafka一般只能存储非常短时间的数据,比如最近一周,甚至最近一天。
    2. Kafka无法支持高效的OLAP查询,大多数业务都希望能在DWD\DWS层支持即席查询的,但是Kafka无法非常友好地支持这样的需求。
    3. 无法复用目前已经非常成熟的基于离线数仓的数据血缘、数据质量管理体系。需要重新实现一套数据血缘、数据质量管理体系。
    4. Kafka不支持update/upsert,目前Kafka仅支持append。实际场景中在DWS轻度汇聚层很多时候是需要更新的,DWD明细层到DWS轻度汇聚层一般会根据时间粒度以及维度进行一定的聚合,用于减少数据量,提升查询性能。假如原始数据是秒级数据,聚合窗口是1分钟,那就有可能产生某些延迟的数据经过时间窗口聚合之后需要更新之前数据的需求。这部分更新需求无法使用Kafka实现。

    所以实时数仓发展到现在的架构,一定程度上解决了数据报表时效性问题,但是这样的架构依然存在不少问题,随着技术的发展,相信基于Kafka+Flink的实时数仓架构也会进一步往前发展,那么到底往哪些方向发展,我们可以结合大公司中技术选型可以推测实时数仓的发展大致会走向“批流一体”。

    最近一两年中和实时数仓一样火的概念是“批流一体”,那么到底什么是“批流一体”?在业界中很多人认为批和流在开发层面上都统一到相同的SQL上处理是批流一体,也有一些人认为在计算引擎层面上批和流可以集成在同一个计算引擎是批流一体,比如:Spark/SparkStreaming/Structured Streaming/Flink框架在计算引擎层面上实现了批处理和流处理集成。

    以上无论是在业务SQL使用上统一还是计算引擎上的统一,都是批流一体的一个方面,除此之外,批流一体还有一个最核心的方面就是存储层面上的统一。这个方面上也有一些流行的技术:delta/hudi/iceberg,存储一旦能够做到统一,例如:一些大型公司使用Iceberg作为存储,那么Kappa架构中很多问题都可以得到解决,Kappa架构将变成个如下模样:
    image.png
    这条架构中无论是流处理还是批处理,数据存储都统一到数据湖Iceberg上,这一套结构将存储统一后,解决了Kappa架构很多痛点,解决方面如下:

    1. 可以解决Kafka存储数据量少的问题。目前所有数据湖基本思路都是基于HDFS之上实现的一个文件管理系统,所以数据体量可以很大。
    2. DW层数据依然可以支持OLAP查询。同样数据湖基于HDFS之上实现,只需要当前的OLAP查询引擎做一些适配就可以进行OLAP查询。
    3. 批流存储都基于Iceberg/HDFS存储之后,就完全可以复用一套相同的数据血缘、数据质量管理体系。
    4. 实时数据的更新。

    上述架构也可以认为是Kappa架构的变种,也有两条数据链路,一条是基于Spark的离线数据链路,一条是基于Flink的实时数据链路,通常数据都是直接走实时链路处理,而离线链路则更多的应用于数据修正等非常规场景。这样的架构要成为一个可以落地的实时数仓方案、可以做到实时报表产生,这得益于Iceberg技术:

    支持流式写入-增量拉取

    流式写入其实现在基于Flink就可以实现,无非是将checkpoint间隔设置的短一点,比如1分钟,就意味每分钟生成的文件就可以写入到HDFS,这就是流式写入。但是这里有两个问题,第一个问题是小文件很多,但这不是最关键的,第二个问题才是最致命的,就是上游每分钟提交了很多文件到HDFS上,下游消费的Flink是不知道哪些文件是最新提交的,因此下游Flink就不知道应该去消费处理哪些文件。这个问题才是离线数仓做不到实时的最关键原因之一,离线数仓的玩法是说上游将数据全部导入完成了,告诉下游说这波数据全部导完了,你可以消费处理了,这样的话就做不到实时处理。

    数据湖就解决了这个问题。实时数据链路处理的时候上游Flink写入的文件进来之后,下游就可以将数据文件一致性地读走。这里强调一致性地读,就是不能多读一个文件也不能少读一个文件。上游这段时间写了多少文件,下游就要读走多少文件。我们称这样的读取叫增量拉取。

    解决小文件多的问题

    数据湖实现了相关合并小文件的接口,Spark/Flink上层引擎可以周期性地调用接口进行小文件合并。

    支持批量以及流式的Upsert(Delete)功能

    批量Upsert/Delete功能主要用于离线数据修正。流式upsert场景上文介绍了,主要是流处理场景下经过窗口时间聚合之后有延迟数据到来的话会有更新的需求。这类需求是需要一个可以支持更新的存储系统的,而离线数仓做更新的话需要全量数据覆盖,这也是离线数仓做不到实时的关键原因之一,数据湖是需要解决掉这个问题的。

    支持比较完整的OLAP生态

    比如支持Hive/Spark/Presto/Impala等OLAP查询引擎,提供高效的多维聚合查询性能。

    话会有更新的需求。这类需求是需要一个可以支持更新的存储系统的,而离线数仓做更新的话需要全量数据覆盖,这也是离线数仓做不到实时的关键原因之一,数据湖是需要解决掉这个问题的。

    支持比较完整的OLAP生态

    比如支持Hive/Spark/Presto/Impala等OLAP查询引擎,提供高效的多维聚合查询性能。

    目前Iceberg部分功能还在开发中,有一些功能还不完善,但是整体实时数仓的发展会大致朝着这个方向行进。目前业界大多数公司还是处于Lambda架构,使用Kappa架构的公司一般都是实时业务居多的公司,随着数据湖技术的发展,这些公司实时数仓的构建慢慢会走向最终的“批流一体”。

    展开全文
  • 对于结构化资源,我们将通过全面的接口管理体系进行相应资源采集模板的搭建,采集后的数据经过有效的资源审核和分析处理后进入到数据交换平台进行有效管理。 3 数据分析与展现 采集完成的数据将通过有效的资源分析...
  • 会员体系架构的设计思路
  • 1.Greenplum 体系架构 Greenplum架构图如下: Greenplum 由三部分组成:Mastert、Segment、Interconnect。 (1)Master 访问系统的入口 数据库侦听进程 (postgres) 处理所有用户连接 建立...
  • Hadoop生态之Hadoop体系架构(一)

    千次阅读 2019-05-23 11:33:56
    Hadoop是一个由Apache基金会所开发的分布式系统基础架构。 Hadoop是一个开源框架,可编写和运行分布式应用处理大规模数据。Hadoop的框架最核心的设计就是:HDFS和MapReduce。HDFS为海量的数据提供了存储,而...
  • 本课程在前期智慧中台专题《如何进行中台架构设计》、《简析数据中台公共能力要点》、《数据湖与数据仓库之争》、《基于数据湖数据中台解决方案》、《数据集市解决方案》、《如何构建数据质量方案》等相关课程基础上...
  • MES系统软件体系架构

    2022-02-20 12:07:05
    MES系统软件体系架构 数字化车间将信息、网络、自动化、现代管理与制造技术相结合,在车间形成数字化制造平台,改善车间的管理和生产等各环节,从而实现了敏捷制造。 MES系统软件是数字化车间的核心。MES通过数字化...
  • oracle数据库体系架构详解

    万次阅读 多人点赞 2018-08-31 19:10:41
    在学习oracle中,体系结构是重中之重,一开始从宏观上掌握它...你首先应该以图纸的方式把整个大楼的体系架构描述出来。然后一点点的往里面填充东西。下面我们先以一个图解的方式对oracle体系结构有一个基本了解   ...
  • 微服务架构体系的深度治理PDF
  • 大数据系统体系架构(含图示)

    千次阅读 2021-01-17 17:03:24
    目录1 大数据体系架构图2 数据采集层3 数据计算层4 数据服务层5 数据应用层 1 大数据体系架构图 2 数据采集层 阿里的的日志采集包括两大体系: Aplus.JS是Web端的日志采集技术方案,UserTrack是APP端的日志采集...
  • 大数据体系架构

    千次阅读 2020-01-01 15:20:54
    接下来先看一张体系架构图: 文件系统层:在这一层里,分布式文件系统需具备存储管理、容错处理、高可扩展性、高可靠性和高可用性等特性。 数据存储层:由于目前采集到的数据,十之有七八为非结构化和半结构...
  • 数据仓库架构

    千次阅读 2021-09-05 23:38:07
    数据仓库的组织管理方式决定了它有别于传统数据库,同时也决定了其对外部数据的表现形式。要决定采用什么产品和技术来建立数据仓库的核心,则需要从数据仓库的技术特点着手分析。针对现有各业务系统的数据.
  • 数据治理很火,在 DAMA 数据管理知识体系指南中,数据治理位于 “数据管理车轮” 的正中央,如下: 而元数据管理,正是十大数据管理领域其中很重要的一环。 数据资产治理的前提是要有数据,并且要求数据类型全...
  • 基于WEB的仓库管理系统的设计与实现设计软件程序源码+数据库+WORD毕业设计论文文档. 基于WEB的仓库管理系统主要用于实现仓库的出入库管理,基本功能包括:入库模块、出库模块、商品查看模块、用户注册模块、个人...
  • BI体系架构及相关技术介绍

    千次阅读 多人点赞 2020-02-24 14:42:42
    较为严谨的定义:“商务智能是企业利用现代信息技术收集、管理和分析结构化和非结构化的商务数据和信息,创造和累计商务知识和见解,改善商务决策水平,采取有效的商务行动,完善各种商务流程,提升各方面商务绩效,...
  • BI的体系架构及相关技术

    千次阅读 2020-03-07 11:50:04
    一个BI系统为了满足企业管理者的要求,从浩如烟海的资料中找出其关心的数据,必须要做到以下几步: 1)为了整合各种格式的数据,清除原有数据中的错误记录——数据预处理的要求。 2)对预处理过数据,应该统一集中...
  • SOA体系架构

    2019-09-28 10:17:18
    面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)进行拆分,并通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、...
  • 面向服务的体系架构(SOA)—架构篇 1、面向服务的体系架构(SOA)         面向服务的架构(service-oriented architecture)是Gartner于2O世纪9O年代中期提出的面向服务...
  • 它以标准化的数据质量规范为基础,运用数据挖掘、数据分析、工作流、评分卡、可视化等技术帮助组织建立数据质量管理体系,提升数据的完整性、规范性、及时性、一致性、逻辑性,降低数据管理成本,减少因数据不可靠...
  • 数据仓库(三)之架构

    万次阅读 多人点赞 2018-09-13 21:54:18
    架构是数据仓库建设的总体规划,从整体视角描述了解决方案的高层模型,描述了各个子系统的功能以及关系,描述了数据从源系统到决策系统的数据流程。业务需求回答了要做什么,架构就是回答怎么做的问题。 架构的...
  • OushuDB 体系架构概览

    千次阅读 2021-11-19 16:07:51
    元数据管理服务和资源管理服务位于OushuDB Master内部。其他节点为Slave节点。每个Slave节点上安装有一个OushuDB Segment。Segment实现OushuDB的计算。OushuDB Segment在执行查询的时候会启动多个QE (Query Executor...
  • 摘要: 当前业界对面向服务体系架构(SOA)和数据仓库(Data Warehouse,DW)都介绍的很多,提出了很多优秀的解决方案,但是一般是把 SOA 和 DW 单独考虑,SOA 和 DW 有着共同的目标——系统整合,由于基于不同的...
  • 经过我和我的团队一年的不懈努力,基本完成了公司信息安全体系的初步建设,我设计的安全体系架构分为六大块:安全开发体系、安全防御体系、数据安全体系、隐私合规体系、资产管理体系、安全管理体系,六大体系共同...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 39,660
精华内容 15,864
热门标签
关键字:

仓库管理体系架构图