精华内容
下载资源
问答
  • 银行数据架构体系

    千次阅读 2019-12-22 11:43:49
    数据架构层面通过数据分类、分层部署等手段,从非功能性视角将数据合理布局。通过整体架构管控和设计,支持业务操作类和管理分析类应用(系统),满足业务发展及IT转型对数据的需求,架构的扩展性和适应性能够提升...

    数据架构层面通过数据分类、分层部署等手段,从非功能性视角将数据合理布局。通过整体架构管控和设计,支持业务操作类和管理分析类应用(系统),满足业务发展及IT转型对数据的需求,架构的扩展性和适应性能够提升数据分析应用的及时性、灵活性和准确性。

    那实际情况下各个银行的数据架构体系会有所不同,根据各行的业务发展、客户数据量、交易数据量、功能需求等会有不同的演变路径以及发展方向。一般国有银行、股份制银行等全国性的银行业务较复杂,数据量也较多,数据架构也因此进化较快。常见的数据架构分区如下图所示:

    深度分析|一文读懂银行数据架构体系

     

    1、数据采集层

    数据缓冲区的数据主要是将数据从源系统加载到数据仓库中,作为数据在数据仓库的起点,数据缓存区数据只保留7-10天,以备数据问题处理,数据缓冲区的数据除了标准化的处理,最好直接获取源系统未经加工的数据,以便一次抽取,多次使用。

    标准化处理主要有编码统一转化、异常字符清理等,以便后续处理。数据采集层不仅仅只应用于数据仓库相关,也可以适用于各交易系统的批量数据或文件传输和交换,所以在全行系统层面制定规范。

    2、存储计算层

    (1)主数据区:

    指结构化数据的主数据区,这部分数据包括了所有的基础明细数据以及历史数据,其它区域的结构化数据都是由主数据区数据加工而来。那主数据区主要有两种模型:近源模型层和整合模型层。一般在实践过程中可以两个区域都有,也可以只有任意一个区域。这两个区的数据都通过历史拉链或历史流水的方式保留历史数据,如果有数据标准,这两个区的数据按数据标准进行字段属性如代码值、长度、精度的标准化,那这两个区的数据主要在模型设计方面有所不同:

    ①近源模型区:表结构设计和源系统类似,在源系统表基础上增加标准化字段以及历史数据保存算法的数据日期字段,近源模型层的特点是保留源系统表所有信息,在建模和运行效率上比较高,但数据整合性不高,一些交易系统设计的表结构并不直接适用数据分析和加工。

    ②整合模型区:整合模型区按主题进行数据整合、表设计以三范式为主,模型稳定,数据冗余少,那这里模型稳定是指即使源系统表结构如何变化,只要实体之间关系和属性不变,那整合模型也可以保持基本不变。模型稳定的一个好处就是可以屏蔽源系统变化,避免下游应用系统重复改造。

    举个栗子:个人信贷系统升级,将使用新的系统,那所有表结构都会发生变化,如果直接使用近源模型区数据,那对于后续加工变化很大,同时时间跨度较大的分析(如年报)需要分别考虑新旧个人信贷系统的数据加工规则,如果使用整合模型,那整合模型变动不会太大,对于历史数据也能同时存在于一个模型(一套表)中,对于后续应用加工影响较小。同时整合模型会在客户、账户、签约等各主要维度进行分析梳理,形成整体视图,有利于从全行视角分析。例如客户整合可以区分客户唯一性,获得客户视图;产品和签约的整合可以清楚看到客户在行内的购买的所有产品和签约。方便后续客户分析。

    深度分析|一文读懂银行数据架构体系

     

    (2)指标汇总区:

    由于主数据区的数据并不合适直接提供给数据系统分析使用,因此指标汇总区是整合各数据应用的加工需求,按事实表(宽表)和维度表进行模型设计,对主数据区数据进行关联、公共指标加工,提供给多个数据应用使用,那指标汇总区可按协议(账户)、产品、客户、科目、机构等逐层汇总,指标汇总区可以消除各系统对于同一个指标分别加工导致的口径差异。

    (3)集市区(仓内):

    仓内集市主要指和数据仓库在同一个物理平台中的集市,可以直接访问主数据区,指标汇总区数据、减少数据批量转移的成本,利用数据仓库平台分析性能快速进行数据加工,那数据集市的划分可按业务部门或下游系统关联度进行集市划分,如财务集市面向管理会计等财务分析应用进行专门的数据加工、使用者主要为计划财务部。监管集市主要面向给人行、银监进行监管报送报表的加工,涉及多个业务管理部门。

    (4)批量接口区:

    数据仓库给各下游数据应用系统、仓外集市的数据接口加工区,按双方约定的数据格式提供给数据应用系统,批量接口区按接口协议做简单关联,不做复杂加工,如果平台支持视图,接口区可以只有视图提供给下游接口,减少数据冗余。

    (5)非结构化数据存储计算区:

    主要对非结构化数据进行存储计算,按一定的数据类型、来源、用途进行区域划分,方便实时查看和分析;

    (6)历史数据区:

    面向主数据区和非结构化数据区的历史数据归档和查询。主数据区和非结构化数据区一般只保留1-3年的数据,之前的数据使用率低,可专门归档到历史数据区,提高主数据区的性能;同时历史数据区可以采用成本较低的设备,降低成本。

    (7)实时数据区:

    实时数据区主要面向流式数据的加工和处理,同时对于流处理所需的主数据区数据可以直接访问也可以存储一份在实时数据区。

    (8)在线访问区:

    在线访问区数据是数据加工结果数据,以实时数据接口方式提供给外部使用。改部分数据可以采用HBASE提供在线查询服务。

    3、仓外集市数据区

    仓外数据集市和仓内数据集市区别只是和数据仓库不在同一物理平台,但一样面向特定的数据应用进行加工分析,一般随着数据量的增加,数据仓库的平台负荷过大往往会将集市从仓内移到仓外,或者对于需24小时随时提供数据处理的数据集市,为了不与数据仓库平台竞争资源,也一般选择在仓外建设数据集市。

    深度分析|一文读懂银行数据架构体系

     

    4、报表区

    报表区数据是加工后的报表结果数据,为报表平台提供展示数据,因为报表系统往往是7*24小时提供服务,因此在数据平台外单独建立报表平台,减少耦合性,在行内可以建设统一的报表平台,对报表的开发、整合、维护、下线进行统一管理,减少重复报表开发。

    深度分析|一文读懂银行数据架构体系

     

    5、数据探索区

    数据探索区是提供给各业务部门进行数据探索的区域,该区域的数据根据业务分析需求从数据仓库进行加载,并T+1进行更新,由业务同事对数据进行自由分析和挖掘。该平台一般性能要求也比较高,可以使用MPP数据库或HADOOP平台进行技术实现。由于业务人员使用比较随意,该区域需要注意历史数据的清理,避免过多冗余无用的数据占用大量空间。

    从数据分层来看,存储计算区是最为核心的部分,存储计算区大部分银行是由MPP数据库和HADOOP平台共同来实现,部分互联网银行单独使用HADOOP平台来实现。以下是一种常见的MPP和HADOOP平台协作的存储计算数据区的技术实现:

    深度分析|一文读懂银行数据架构体系

     

    从各数据区域的使用团队来看,如果全行数据进行统一存储管理或者采用数据中台,那存储计算区建议由统一团队进行开发维护,数据集市区、数据采集区、数据实验区、报表区可以统一规范和技术平台,由各数据应用团队负责各自程序维护,通过用户权限管理进行隔离。

    展开全文
  • 微服务数据架构设计

    千次阅读 2018-03-19 12:42:30
    微服务开发中的数据架构设计前言微服务是当前非常流行的技术框架,通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性,可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性。为业务创新和...

    微服务开发中的数据架构设计

    前言

    微服务是当前非常流行的技术框架,通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性,可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性。为业务创新和业务持续提供了一个良好的基础平台。本文分享在这种技术架构下的数据架构的设计思想以及设计要点,本文包括下面若干内容。

    • 微服务技术框架中的多层数据架构设计

    • 数据架构设计中的要点

    • 要点1:数据易用性

    • 要点2:主、副数据及数据解耦

    • 要点3:分库分表

    • 要点4:多源数据适配

    • 要点5:多源数据缓存

    • 要点6:数据集市

    为了容易理解,本文用一个简化的销售模型来阐述,如下图。图1显示了客户、卖家、商品、定价、订单的关系(这里省略支付、物流等其他元素)。

    微服务开发中的数据架构设计

    图1 销售模型

    在这个销售模型中,卖家提供商品、制定价格,客户选择产品购买、形成销售订单。根据微服务的理念设计,可以划分为客户服务、卖家服务、商品服务、定价服务、订单服务,以及公共服务(比如认证、权限、通知等),如图2所示。

    微服务开发中的数据架构设计

    图2 微服务功能

    微服务架构中的多层数据架构设计

    分布式架构一般把系统分为 Saas(Software-as-a-Service)、Paas(Platform-as-a-Service)、Iaas(Infrastructure as a Service )三层。其中 Saas 层负责对外部提供业务服务,Paas 层提供基础应用平台,Iaas 层提供基础设施。微服务垂直嵌入这三层服务之中,相互独立。因此数据架构设计时需要考虑三层服务对数据的关注点,又要考虑微服务的独立性。

    数据架构的分层设计

    微服务开发中的数据架构设计

    图3 微服务技术框架

    如图3所示,Iaas 层提供程序运行的物理基础环境(这边涉及很多硬件·网络内容,在本文中省略)。Pass 层细分为三层,基础服务层,主要负责数据存储处理;事务框架层,主要负责微服务的注册·调度管理、分布式事务处理;应用服务层、主要实现各个微服务的 API,供其它微服务直接调用以及 Saas 层的服务调用。Saas 服务就是公开对外提供的业务服务。全文中架构技术运用到的知识点可以在群619881427免费获取。感兴趣的可以加入进来。

    数据架构自下向上相应的分为 Raw Data 层、Logic Data(inner)层和 Logic Data(outer)层(Iaas 中主要以基础硬件环境为主,在本文中省略)。Raw Data 层是基于数据库、文件或者其他形式数据内容。Logic Data(inner)层是微服务 API 使用的逻辑数据,比如客户数据、订单数据等等。Logic Data(outer)层是对外服务提供数据,比如客户订单数据。因此,我们的数据架构的分层结果如图4所示。

    微服务开发中的数据架构设计

    图4 数据分层架构

    除此之外,很多情报会以画面或报表的形式展现出来。因此在 Logic Data(outer) 之上,可以构建 Information Block(常用的信息块)、通过 View type(显示模式)的设定后,最终 View 展现出来。

    如图4所示,越靠近对外服务层,客户对设计者的影响度越大,越需要从使用性、易用性、适用性等考虑。反之,越远离对外服务层,设计上更关心数据的存储。

    数据三层架构的好处是实现数据从系统实现到业务实现的逐层过渡,实现业务数据和系统数据间的松耦合。同时实现业务的灵活扩展和系统的灵活扩展。

    数据架构设计中的要点

    上面讲述了数据架构的分层设计,下面讲述数据架构设计中的要点。

    要点1:数据易用性

    数据无论用什么方式实现,其最终目的都是为业务(或者是客户)使用的。因此,在对外提供服务的时候,数据的易用性非常关键。

    微服务开发中的数据架构设计

    图5 数据易用性

    如图5所示,客户信息在 Logic Data(inner) 层中为了数据的柔软性和非冗余,把人员信息拆成若干子表来存储。比如,人员地址表可以无限多的存储客户地址信息。这样的好处在于每次人员地址更新时,不用直接更新人员地址,而是生成一个新的地址数据,原有的地址信息作为历史数据得到保存,易于数据快速恢复和历史信息追踪。但在 Logic Data(outer)层提供外部数据的时候,首先考虑的是一次性能提供足够用的信息(毕竟查询的操作大大高于修改的操作),减少业务场景中不需要的信息。比如对一般客户只提供三个常用地址的时候,数据设计中地址1、地址2和地址3放在一张表中。

    要点2:主、副数据及数据解耦

    每个微服务 API 的数据完全独立是不太现实的,比如订单中需要有商品、客户(包括收货者)、卖家以及价格等数据。如果这些数据都在订单服务 API 中管理,那么客户情报的变更、价格调整等信息都要同步给订单 API 中数据,数据的耦合度就会变得非常高。在数据设计的时候,需要考虑降低数据间的相互依赖性。因此,首先需要确定每个微服务 API 的主数据和副数据。主数据指微服务 API 的核心数据,这种数据的增删改主要集中在某个微服务 API 中,比如订单服务 API 中的订单数据。副数据指参照或者映射其他微服务 API 的数据,比如订单服务 API 中的商品数据、价格数据等。其次,为了降低数据之间的耦合度,用数据关联表来表征数据间的关系。如果想去掉数据间的关联关系,直接去掉关联表即可,对数据本身的没有任何影响。具体如图6所示。

    微服务开发中的数据架构设计

    图6 主、副数据及数据解耦

    要点3:分库分表

    随着业务数据量不断增加,单一数据库或单一数据表中会积累大量的数据,比如订单数据,随着时间推移和客户数量的增加,产生的订单数据也会越来越多。当数据累积到一定程度后,数据操作的性能会大幅下降,也就是我们常说的数据库“带不动了”。所以,在数据架构设计阶段就应该考虑数据的分库分表。

    如图7所示,分库,即我们把订单数据分为当前数据应用库、历史数据库、历史归档数据库。当前数据应用库用来支持新订单的生成以及执行中订单的增删改查。历史数据库(这里举例分为最近3个月和最近1年)当客户想看过往订单的时候才使用。历史归档数据(按年间归档)原则上不直接对客户公开,用于备查、统计分析。对于当前数据应用库,可以继续再分库,按客户号范围来分库。这样每个数据库的大小都能得到有效控制。分表,即把一条信息分别存储在两张或多张表中。比如把订单信息按基本信息和详细信息分表,就可以适用于订单的基本信息查询和订单详细信息查询。总之,分库分表的核心就是控制单一数据库的负荷(数据量和数据信息量),通过多表多库来应对业务数据量的增长。

    微服务开发中的数据架构设计

    图7 分表分库

    要点4:多源数据适配

    传统的关系型数据库之外,有多种多样的数据源,比如图像、声音、视频等多媒体数据文件或数据流,CSV、TXT、Doc、Excle、PDF、XML 等各种异构数。这些数据都需要做相应的处理,转换成可管理的数据信息。因此在数据架构设计的时候,需要给不同性质的数据源配置相对应的读写适配器,同时也需要有统一调度的地方,如图8所示。全文中架构技术运用到的知识点可以在群619881427免费获取。感兴趣的可以加入进来。

    微服务开发中的数据架构设计

    图8 多源数据适配

    要点5:多源数据缓存

    数据处理的性能除了处理逻辑的复杂度以外,还有很大一部分是目标数据的操作时长(含对硬件磁盘设备的读写以及网络的传输)。网络速度特别是光纤的使用后已经大幅度提高,但机器磁盘的读写效率并没有显著提高,因此减少磁盘读写是提高效率的一个重要途径。数据缓存就是把常用的数据(不会经常更改的数据)、最近使用数据放到内存中。这样就可以大幅降低系统对硬件磁盘设备的操作开销,提高整个数据系统的性能,如图9所示。

    微服务开发中的数据架构设计

    图9 数据缓存

    要点6:数据集市

    数据集市是一个很大的话题。当现有的数据不能简单地通过几个表数据关联以及简单加工后就可以供业务使用的时候,就需要考虑构建数据集市。数据集市以数据运用的观点来分析加工数据,通过多源数据的导入、清洗、加工、视图做成等一系列的数据操作后,为业务提供可用的、稳定的数据源。例如,对销售分析中、什么样的客户喜欢什么样的商品、价格对销售金额的影响、销售金额跟地区日期的关联关系等多维度分析,就要用数据集市的概念,如图10所示。

    微服务开发中的数据架构设计

    图10 数据集市

    数据承载着信息,好的数据架构设计会使业务系统变得更加流畅、更加容易理解和维护。


    展开全文
  • 微服务架构设计实践 目 次1 序言2 微服务3 软件架构设计思想4 微服务架构设计实践4.1 项目概述4.2 架构准备阶段4.3 概念架构阶段4.4 细化架构阶段4.4.1 业务架构4.4.2 数据架构4.4.3 应用架构4.4.4 技术架构4.4.5 ...

    微服务架构设计实践
     


    目    次

    4.4.2  数据架构

    4.4.2.1  数据架构定义

            数据架构定义了用来支持业务的各种数据,以及他们之间的关系。

            数据架构着重考虑“数据需求”,关注点是持久化数据的组织。

            在数据架构设计过程中,主要涉及三部分内容:数据定义、数据分布与数据管理:

            1.数据定义,是数据架构规划中最重要内容。定义良好的数据模型,包括数据概念模型、数据逻辑模型、数据物理模型,以及更细化的数据标准,可以反映业务模式的本质,确保数据架构为业务需求提供全面、一致、完整的高质量数据,且为划分应用系统边界,明确数据引用关系,定义应用系统间的集成接口,提供分析依据。良好的数据模型与数据标准的制定才是实现数据共享、保证一致性、完整性与准确性的基础。有了这一基础,企事业单位才能通过信息系统应用逐步深入,最终实现基于数据的管理决策。

            2.数据分布,一方面是分析数据的业务,即分析数据在业务各环节的创建、引用、修改或删除的关系;另一方面是分析数据在单一应用系统中的数据结构与应用系统各功能模块间的引用关系,分析数据在多个系统间的引用关系。数据业务分布是数据系统分布的基础。对于一个拥有众多分支机构的大型企事业,数据存储模式也是数据分布中一项重要内容。从地域的角度看,数据分布有数据集中存储和数据分布存储两种模式。数据集中存储是指数据集中存放于企事业总部数据中心,其分支机构不放置和维护数据;数据分布式存储是指数据分布存放于企事业总部和分支机构,分支机构需要维护管理本分支机构的数据。这两种数据分布模式各有其优缺点,企事业应综合考虑自身需求,确定自己的数据分布策略。

            3.数据管理,一方面要制定贯穿企事业数据生命周期的各项管理制度,包括:数据模型与数据标准管理,数据分布管理,数据质量管理,数据安全管理等制度;另一方面应该确定数据管理组织或岗位。

            数据架构规划是进行企事业IT架构规划不能绕开的重要环节,对于完全通过定制化开发进行应用系统实施的企事业单位来说,数据架构设计是完全可以指导应用系统开发的。

            数据架构规划的目的有三个:

            1.分析业务运作模式的本质,为未来核心应用系统的确定以及分析不同应用系统间的集成关系提供依据。

            2.通过分析核心数据与业务之间的应用关系,分析规划应用系统间的集成关系。

            3.数据管理的需要,明确企事业的核心业务数据,这些数据是应用系统实施与运行时IT系统实施人员或管理人员应该重点关注的,要时时考虑保证这些数据在整个企事业层面的一致性、完整性与准确性。

    4.4.2.2  数据架构设计原则

            在数据架构设计过程中,应该考虑如下因素:

             
    4.4.2.3  数据架构实践

    4.4.2.3.1  数据定义

            一、 概念数据模型

            根据业务需求,分析业务过程中涉及到的所有业务实体,抽取出满足用户场景的实体对象,以及它们之间的关联关系。

            在概念建模阶段,主要做三件事:

            1.客户交流。

            2.理解需求。

            3.形成实体。

            这是一个迭代,如果先有需求,尽量去理解需求,明白当前项目需要完成什么,不明白或者不确定的地方和客户及时交流,和客户二次确认过的需求,落实到实体。如果没有,则通过先和客户交流,进而将交流结果落实到需求,之后进一步具体到实体。

            分行特色业务云平台数据概念模型-基本配置管理部分如下:

            

     

            1.系统管理类

            该部分主要包括系统管理类对象。由于采用基于角色的权限管理,所以涉及的对象主要有用户、角色、功能。

            2.基础数据类

            该部分主要是各种参数配置对象和流水的统一基础数据属性信息,包括:服务场景类型,业务领域,业务区域,机构信息等,后续可根据服务类型的扩展增加相应基础数据对象。

            其中,服务场景类型,业务领域和业务区域后续在控制及事后监控中控制风险使用,例如:通过定义不同的服务场景,来形成各服务场景调用内联服务的风险级别,配置不同的风险控制策略,并且在监控时进行区分关注。

            3.特色应用类:

            该部分主要包括特色业务应用组织、特色业务应用,特色业务产品信息、特色业务合作方信息以及使用业务服务的应用服务场景信息。这些对象用来管理各分行实现的特色业务应用,应用上实现的业务产品以及该业务产品归属的合作方信息,并且通过配置这些应用使用服务融合中心上业务服务的场景(服务场景)来差异化的控制调用服务时的数据属性以及业务风险。

            4.业务服务类:

            业务服务:管理服务融合中心对外发布的业务服务信息。

            业务服务原子服务映射规则:对业务服务与平台内部原子服务调用关系进行管理授权。

            5.原子服务类:

            原子服务:管理由服务融合中心封装的原子服务信息,这些原子服务不直接对外调用,供流程服务调用。原子服务可实现本地的原子服务功能以及后台模块的原子服务功能,针对于后台服务的原子服务一对一的进行封装。

            模块信息:管理服务融合中心原子服务的归属模块,对于服务融合中心封装的远程原子服务,在该表中注册远程服务的归属模块(如PE,NPS),对于本地封装的原子服务,在该表中注册本地模块。

            6.通用功能类:

            通用扩展属性:用来存储各个对象(如业务服务,服务场景等)扩展属性,通过对象类型+对象编码+控制规则主键匹配一组规则。

            对象营业时间:用来存储各对象的营业时间属性。如(特色业务应用、特色业务、特色业务合作方、服务场景、业务服务、原子服务)。

        分行特色业务云平台数据概念模型-流水部分如下:

        

     

            流水表主要分成基础类流水表和业务类流水表。

            1.基础类流水表:

                 接入流水表主要负责当外模块调用服务中心业务服务时,统一记录服务流水。

                 接出流水表主要负责当服务中心业务服务调用外部模块时,登记接出流水,记录与外部模块的交互情况。

            2.业务类流水:

                 目前主要先使用账务流水表,登记账务类流水的信息,后续可根据实际业务类型,扩展不同的业务流水表。

            上述概念数据模型定义了特色业务云平台核心部分的实体对象及它们之间的关系。后续随着功能的完善,业务的增加,需要继续完善概念数据模型。 

            二、 逻辑数据模型

            概念数据模型完成以后,需要进一步对实体对象进行细化,细化成具体的表,同时丰富表结构。

            根据需求确定具体需要哪些表,以及每张表的属性。此时会涉及主键的选取,外键的关联,约束的设置等细节。笔者认为只要能把每个实体属性落实下来就是很不错了,因为随着项目的开展,很多表的列都会有相应的改动。

            这个阶段的产物是,可以在数据库中生成的具体表及其他数据库对象,包括主键,外键,属性列,索引,约束甚至是视图以及存储过程。

            以下为服务融合中心部分逻辑数据模型,以供参考。

            1.系统管理部分逻辑数据模型:

            

             2.基本配置部分逻辑数据模型:

                 服务配置部分: 

                

                 业务产品配置部分: 

                

                 其它配置部分:

                

             3.流水部分逻辑数据模型:

     

             三、 物理数据模型

            物理建模可以将在逻辑建模阶段创建的各种数据库对象生成为相应的SQL代码,运行来创建相应具体数据库对象。

            这个阶段我们不仅仅创建数据库对象,针对业务需求,我们也可能做如数据拆分(水平或垂直拆分)、读写分离。

            根据所选数据库管理系统的类型,生成相关的SQL语句,然后创建具体的数据库对象。

            例如:业务区域表在MySQL数据库的创建语句:

            CREATE TABLE `t_busi_area_info` (

              `busi_area` VARCHAR(10) COLLATE utf8_bin NOT NULL COMMENT '区域编码',
              `area_name` VARCHAR(60) COLLATE utf8_bin NOT NULL COMMENT '业务领域名称',
              `area_level` CHAR(1) COLLATE utf8_bin NOT NULL COMMENT '区域层级',
              `parent_area` CHAR(6) COLLATE utf8_bin NOT NULL COMMENT '上级区域编码',
              `branch_no` CHAR(4) COLLATE utf8_bin DEFAULT NULL COMMENT '分行机构号',
              `status` CHAR(1) COLLATE utf8_bin NOT NULL DEFAULT '1' COMMENT '状态',
              `memo` VARCHAR(255) COLLATE utf8_bin DEFAULT NULL COMMENT '备注',
              `dac` CHAR(16) COLLATE utf8_bin DEFAULT NULL COMMENT 'dac校验',
              PRIMARY KEY (`busi_area`),
              KEY `t_busi_area_info_IDX0` (`area_name`)
        ) ENGINE=INNODB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='业务区域表';

            四、 数据字典

            在数据建模过程中,基于对需求的理解,会抽取出部分业务规则,这些信息将会成为数据字典中非常重要的部分,即元数据。

            以下是数据字典的部分内容,以作参考:

            1.服务功能类型

            以服务的业务功能领域来定义数据规则,目的是为了统一规范服务的业务领域编码规范,后续可通过该编码对相同功能的服务进行统一管理、统计。

            两位编码表示一个类型含义,最多能表示15个层次的类型含义。

            功能类型按照从粗到细的原则进行编排,下级功能领域含义需要与上级功能领域含义一致。

            一级功能领域目前定义如下:

            

            各一级功能领域内的二级功能领域编码定义如下:

            


            2.业务领域

         

        

            

    4.4.2.3.2  数据存储

            一、 数据库管理系统

            在总行,数据库管理系统采用DB2,版本建议为10.5及以上。

            在总行,由于数据库管理系统采用DB2,所以数据库高可用性通过DB2 数据库产品所提供的多种高可用性策略的功能来实现,具体如下:

                1. DB2 高可用性功能部件-HA:支持IBM DB2服务器和集群管理软件相集成。

                2. DB2 数据服务器高可用性灾难恢复功能-HADR:一种数据库复制功能,它提供针对部分站点故障和整个站点故障的高可用性解决方案。HADR 通过将数据更改从源数据库(称为主数据库)复制到目标数据库(称为备用数据库)来防止数据丢失。

                3. DB2日志镜像:支持数据库级别的日志镜像。

                4. DB2故障监视器工具:该工具通过监视 DB2 数据库管理器实例并重新启动任何过早退出的实例来使 DB2 数据库正常运行。

            在分行,根据每个分行各自的需求,从DB2 10.5及以上、Oracle11g及以上、MySQL5.5及以上三种数据库管理系统中任选其一。 

            在分行,根据所选的数据库管理系统,采用相应的产品和工具实现数据库高可用性。

    4.4.2.3.3  数据分布

            根据系统数据产生、使用、管理等方面的不同特点,采用不同的数据分布式存储和处理手段。

            数据分布策略的3条应用原则:

            1.合适原则:合适的才是最好的。把握系统特点,确定分布策略。

            2.综合原则:当系统比较复杂时,其数据产生、使用、管理等方面可能很难表现出压倒性的特点,此时,就需要考虑综合运用不同的数据分布策略。

            3.优化原则:当难以“一步到位”地作出数据分布策略的正确选择,以及还存在质疑时,应从“对吗”、“好吗”两个方面进行对比、评估、优化。

            由于项目时间紧,人员紧缺,总行科技其它相关项目组进度方面的影响,以及其它一些行方政策上约束,所以在项目第一、二阶段,服务融合中心支持两种应用部署方式:

            一、 集中模式+复制模式+子表模式

            在项目第一、二阶段,主要进行服务融合中心基础开发框架、公共技术组件、公共业务组件的开发、测试。此时,总行服务融合中心提供的服务以对总行核心系统提供的服务进行服务封装为主,业务数据存储在总行核心系统中,不在服务融合中心存储。

            另外,总行服务融合中心接入的分行业务有限,业务访问量较低,每天产生的流水类数据量较少。

            基于上述原因,建议服务融合中心作为单一应用部署,采用集群部署实现水平扩展,支持大并发访问,实现高可用性。

            在数据库方面,同样采用单一库部署,通过读写分离、一写多读、内存缓存的方式保证读操作的性能和高可靠。

            单一应用集群模式如下图所示:

            

     

            在上述部署模式下,数据分布模式如下:

            1.服务融合中心中系统管理类、基本配置类数据,此类数据属于配置型数据,读写比大(即读多,写少),强依赖读,弱依赖写,不要求严格的读一致性,读可靠性要求高。对于这类数据,采用集中式管理。另外,通过读写分离、一写多读、分布式缓存、内存缓存的方式保证读操作的性能和高可靠。

            2.服务融合中心中流水类数据,属于流水型数据,此类数据读写比小(即读少、写多),不断产生新的数据,各条数据间是独立的。单条数据的更新需要保证强一致性。流水型数据很方便做水平扩展。对于流水类数据,由于处于刚投产阶段,接入的分行特色业务数量有限,所以暂时采用集中模式和子集模式。

            3.为每张流水类数据的表建立一个副本表(数据结构与主表一致),这样流水类数据的主表只存储热点数据,即指定维度内的数据(如按照时间维度:1个月以内、1个季度以内等,或按其它业务维度),而其它数据保存在副本表内。这样针对主表、副本表分别进行优化(如:支持大量写操作的主表减少索引,以读为主的副本表可以根据查询需求设置多个索引)。

            二、 集中模式+复制模式+子表模式+独立Schema 模式

            如果在项目第一、二阶段需要实现的本地业务服务较多,接入的分行业务较多,建议把服务融合中心中的流程服务按照业务域分组,每组单独集群部署。

            分布式应用集群部署模式如下图所示:

            

     

            在这种部署模式下,数据分布模式调整为:

            1.把单一数据库拆分为一个通用的基本配置管理库和多个应用业务库(一个应用对应于一个业务库)。

            2.通用基本配置管理库主要包括系统管理类、基本配置类、流水类数据,数据分布模式同单一应用集群模式。

           3.应用业务库主要包括该应用所需的业务相关数据,数据分布模式采用独立Schema模式,即每个应用采用单独数据库Schema的方式管理每个应用涉及的业务数据。

            4.每个应用涉及的业务数据,大部分属于状态型数据,读写比相当,必须保证可写才有意义,每一次写操作必须基于前一个正确的状态。针对关键业务的状态型数据,应尽量把维度拆细,一是提高并发处理能力,二是方便隔离故障影响。

            5.状态型数据要求严格的数据一致性。对于这类数据,除了阿里自主研发的基于 Paxos 协议的分布式强一致数据库(对于单节点故障,它提供 RPO=0,RTO<30 秒的容灾能力,致力于从数据库层屏蔽容灾细节,为应用层提供简单的使用方式)),暂时没有很好的完整解决方案。所以,这部分数据暂时采用单一数据库存储。

            三、 集中模式+复制模式+分区模式

            随着接入的分行特色业务数量的增加,预计每天1亿笔交易量,导致流水相关表的数据量急剧增加。

            在这种海量业务场景下,上述针对流水型数据的子表模式的数据库设计会遇到单表的容量瓶颈和单库的性能瓶颈。

            针对这种情况,按照分布式的思想,对数据进行拆分,让集中在单点的读写访问分布到多个数据库服务器上,从而获得容量和性能上的弹性延伸能力。

            常用的数据拆分模式:

                 垂直拆分:按业务域进行拆分;

                 水平拆分:按某个业务维度进行拆分,如用户、区间等;

                 读写拆分:读写分离;

            为了支持灵活的数据分区,并且数据分区对应用层透明,分行特色业务云平台引入分布式数据访问组件ZDAL支持数据库拆分模式。在引入ZDAL组件以后,针对不同类型的数据采用不同的处理方式。

            1.配置型数据:涉及系统管理类表、基本配置类表

            此类数据的特征是读多写少,数据量较小,采用群组模式。

            群组(Group)模式,示意图如下:

            

     

            采用该模式,一个主库,多个从库,主库负责写、从库负责读,在事务内的读也使用主库。

            2.流水型数据:涉及流水类表

            对于流水类相关表,进行分库分表设计,采用切片模式。

            切片(Shard)模式,示意图如下:

             

            流水类表采用该模式,按照表中流水号ID进行拆分,根据逻辑切片与物理数据库、表的路由规则分布到据库中。

            在本项目中,考虑到项目后期数据扩容方面的简易性、可维护性,建议采用如下数据库与表的拆分路由规则:

                     

            对按流水号ID进行切分的相关表水平切分为1024个逻辑分片,物理库为4个,逻辑分片按照分库分表规则分布在不同物理库中。1024个逻辑分片,逻辑分片与物理表一一对应,每个库256张表,每个表的顺序号都不相同,该模式下分库分表示意图如下:

            

     

            如果扩容物理库到8台,则只需修改分库分表路由映射规则,之前四个库的后128张表分别迁移到新增的物理库中,同时调整逻辑数据库序号。该模式数据迁移相对方便,每次扩容时,每个库的表数量都在减少,扩容上限1024。

            扩容后数据拆分示意图如下:

             

            迁移过程需要一定时间,由于涉及到表数据的迁移和路由规则的切换,所以会影响一段时间数据服务的访问,迁移流程大致如下:

                 停止对外提供服务,然后开始进行数据备份导出;

                 进行表数据的迁移工作;

                 修改ZDAL数据源配置文件,通过配置中心推送ZDAL动态加载;

                 迁移验证,主要包括迁移数据完整性、数据路由是否正确,交易服务是否正常;

                 验证无误后,删除原数据库中已迁移表;

                 对外开始提供服务;

            3.状态型数据

            针对本地服务业务库中的数据,如果某些业务表的数据量达到或超出特定数据库的单表限制,或单表数据量已经影响数据库读、写性能,则建议参考上述流水型数据,进行分库分表设计。

    4.4.2.3.4  数据管理

            在数据管理方面,主要包括两个部分:

            1.制定贯穿整个数据生命周期的各项管理制度,包括:数据模型与数据标准管理,数据分布管理,数据质量管理,数据安全管理等制度。

            2.确定数据管理组织或岗位。


      微信扫一扫,关注该公众号

      该系列文章已经在微信公众号发布,如果感兴趣,请关注。

       以后更多知识通过该微信公众号分享。


    展开全文
  • 一个运行了20多年的数据架构,必然有其合理性。也正是因为年代久远,存量过多,才导致举步维艰。在Cloud和5G时代,超密度网络集成和大数据洞察需求给电信供应商带来新的挑战,从数据仓库到数...

    转载自https://mp.weixin.qq.com/s/321mkZsuxqXOme5hw_83mQ

    网管产品需要从数据仓库的角度来看,才能获得完整的视图。数据集成真正从大数据的角度来看,才能明白其中的挑战。一个运行了20多年的数据架构,必然有其合理性。也正是因为年代久远,存量过多,才导致举步维艰。在Cloud和5G时代,超密度网络集成和大数据洞察需求给电信供应商带来新的挑战,从数据仓库到数据湖,不仅仅架构的变革,更是思维方式的升级。本文尝试梳理数据架构的演进过程。

     

     

      01

    数据仓库历史沿革

     

    1970年,关系数据库的研究原型System R 和INGRES开始出现,这两个系统的设计目标都是面向on-line transaction processing (OLTP)的应用。关系数据库的真正可用产品直到1980年才出现,分别是DB2 和INGRES。

     

    其他的数据库,包括Sybase, Oracle, 和Informix都遵从了相同的数据库基本模型。关系数据库的特点是按照行存储关系表,使用B树或衍生的树结构作为索引和基于代价的优化器,提供ACID的属性保证。

     

    到1990年,一个新的趋势开始出现:企业为了商业智能的目的,需要把多个操作数据库中数据收集到一个数据仓库中。尽管投资巨大且功能有限,投资数据仓库的企业还是获得了不错的投资回报率。

     

    从此,数据仓库开始支撑各大企业的商业决策过程。数据仓库的关键技术包括数据建模,ETL技术,OLAP技术和报表技术等。

     

    目前主要的数据仓库产品供应商包括Oracle、IBM、Microsoft、SAS、Teradata、Sybase、Business Objects(已被SAP收购)等。

     

    电信行业是最早采用数据仓库技术的行业之一。由于电信公司运行在一个快速变化和高速竞争的环境,拥有大量的客户基础,从而产生和存储海量的高质量数据。

     

    电信公司利用数据挖掘技术降低营销成本,识别欺诈,并更好地管理其电信网络。

     

     02

    数据仓库概念

     

    数据仓库之父Bill Inmon在1991年出版的“Building the Data Warehouse”一书中所提出的定义被广泛接受——数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策(Decision Making Support)。

     

    这是一个偏向学术的定义,却非常准确的界定了数据仓库与其他数据库系统的本质区别。

     

    “A data warehouseis a subject-oriented, integrated, time-variant, and nonvolatile collection ofdata in support of management’s decision-making process.”

    —W. H. Inmon

     

    要理解数据仓库的概念,需要从与数据库的系统的对比来看。

     

    数据库是作为“所有处理的单一数据源”出现和定义的。

     

    数据库的出现有两个驱动因素,第一是70年代以前大量应用程序和主文件的分散存放导致一片混乱和大量冗余数据。第二是直接存取存储设备的出现使得按记录寻址成为可能。基于DBMS的在线事务处理为商业发展开辟全新的视野。

     

    数据库系统的设计目标是事务处理。数据库系统是为记录更新和事务处理而设计,数据的访问的特点是基于主键,大量原子,隔离的小事务,并发和可恢复是关键属性,最大事务吞吐量是关键指标,因此数据库的设计都反映了这些需求。

     

    数据仓库的设计目标是决策支持。历史的,摘要的,聚合的数据比原始的记录重要的多。查询负载主要集中在即席查询和包含连接,聚合等操作的复杂查询。

     

    相对于数据库系统来说,查询吞吐量和响应时间比事务处理吞吐量重要的多。

     

    数据仓库和数据库系统的区别,一言蔽之:OLAP和OLTP的区别。数据库支持是OLTP,数据仓库支持的是OLAP。

     

     

    对 OLTP 和OLAP 的区别还可以有一个维度,就是及时性需求。OLTP对事务的及时性需求较高,而OLAP 则不然。

    ——曹洪伟

     

    数据仓库一般基于数据库实现,但是为部署和维护上是分离的。数据仓库可以是基于关系数据库实现的,这样的数据仓库被称为ROLAP。数据仓库也可以是基于多维数据结构实现的,这样的数据仓库被称为MOLAP。

     

     03

    数据仓库架构

     

    数据仓库是一种体系结构,而不是一种技术。数据仓库最为核心的内容分类两部分:

     

    1. 基于关系数据库的多维建模(RDBMS-based dimensional modeling)

       

    2. 基于数据立方体的OLAP查询(cube-based OLAP)

     

     

    数据仓库体系结构包含了从外部数据源或者数据库抽取数据的ETL工具。ETL还负责数据的转换,清洗,然后加载到数据仓库的存储中。一般来说,数据都会加载到存取速度较慢的存储中,以原始数据的方式保存下来。

     

    为了提高查询效率,原始数据会按主题分类,以聚合的方式存储到数据集市中,称之为聚合数据。

     

    参见下图,原始数据往往有多条聚合路径,时间维度是一个最基本的内置聚合路径,行政级别划分也是一种常见的聚合路径,产品属性也是常见的聚合路径。

     

     

    数据仓库体系结构中还包括前端的查询工具,报表工具和数据挖掘工具,被称为front-end。

     

    最后也是最重要的是,数据仓库体系结构中都会包含一个构建数据仓库的元数据仓库。

     

    元数据仓库包括数据库schema,view,用于ETL的metadata,用于数据聚合的metadata,用于报表呈现的metadata和SQL模板等。数据仓库往往采用meta data driven的架构设计,这个元数据仓库就至关重要。

     

    上文中提到的维度的概念。维度(dimension)是观察事物的角度,也是数据库事实表中用来描述数据分类的层次结构。维度在数据中就是表示为列,在SQL中用作过滤和分组。

     

    像上图这样对数据进行多个维度的抽象并借助于数据库的select,group by等基本操作形成的OLAP多维数据操作(roll up,drill down,slice and dice,pivot)被称为多维数据模型。

     

    为了方便复杂分析和可视化呈现,数据仓库中数据往往以多维模型建模。每一个维度被称为一个层级,三个维度构成一个数据立方体。维度也通常用来过滤和分组,所以数据立方体称之为group by的并。

     

    OLAP也被称为在基于数据仓库多维模型的基础上实现的面向分析的各类操作的集合。

     

    04

    数据立方体

     

    数据立方体只是多维模型的一个形象的说法。立方体其本身只有三维,但多维模型不仅限于三维模型,可以组合更多的维度。

     

    但一方面是出于更方便地解释和描述,同时也是给思维成像和想象的空间;另一方面是为了与传统关系型数据库的二维表区别开来,于是就有了数据立方体的称呼(见下图)。

     

     

    OLAP的操作是以查询——也就是数据库的SELECT操作为主,但是查询可以很复杂,比如基于关系数据库的查询可以多表关联,可以使用COUNT、SUM、AVG等聚合函数。

     

    OLAP的多维分析操作包括:钻取(Drill-down)、上卷(Roll-up)、切片(Slice)、切块(Dice)以及旋转(Pivot),逐一解释如下:

     

    Roll up (drill-up): summarize data by climbing up hierarchy or by dimension reduction
    Drill down (roll down): reverse of roll-up,from higher level summary to lower level summary or detailed data, or introducing new dimensions
    Slice and dice: project and select 
    Pivot (rotate): reorient the cube, visualization, 3D to series of 2D planes

     

    看了上图中数据立方体的各种操作,有人觉得还是很抽象。下面给一个SQL的例子,说明数据立方体的具体操作。

     

    select//公式必须配合group by使用
        tmp.time,
        tmp.id1,
        tmp.id2,
        SUM(counter1) counter1,
        SUM(counter2) counter2
    from//双层SQL,实现聚合路径
        (
            select//trunc实现时间维度的变化
                    trunc( p.time, 'min' ) time,
                    "country".country_id id1,
                    "city".city_id id2,
                    SUM(p.counter1) counter1,
                    SUM(p.counter2) counter2
            from
                 table "country",
                 table "city",

                 table p

            where//选择计算的城市
                    "city".city_id in ( '北京','上海','广州' )
                    and time >= to_date('2016/01/01 00:00:00', 'yyyy/mm/dd hh24:mi:ss')
                    and time < to_date('2017/01/01 00:00:00', 'yyyy/mm/dd hh24:mi:ss')
            group by//改变行政维度
                    trunc( p.period_start_time, 'mi' ),
                    "country".country_id,
                    "city".city_id
        ) tmp
    group by//行政维度可以不变
        tmp.time,
        tmp.id1,
        tmp.id2

     

    OLAP的优势是基于数据仓库面向主题、集成的、保留历史及不可变更的数据存储,以及多维模型多视角多层次的数据组织形式,如果脱离的这两点,OLAP将不复存在,也就没有优势可言。

     

    基于多维模型的数据组织让数据的展示更加直观,它就像是我们平常看待各种事物的方式,可以从多个角度多个层面去发现事物的不同特性,而OLAP正是将这种寻常的思维模型应用到了数据分析上。

     

    05

    数据库建模

     

    如果把多维数据模型映射到关系数据库和SQL查询上(ROLAP),数据库该如何设计呢?

     

    大多数数据仓库都采用“星型模型”来表示多维数据模型。在星型模型中,只有一个事实表,并且每一个维度有一个单独的表。

     

    事实表中的每一个元组都是一个外键指向维度表的主键。每一个维度表的列是组成这个维度的所有属性。如下图所示。

     

     

    另外一个常见的数据库设计方法是“雪花模型”。雪花模型通过定义单独的维度表,改进了星型模型中没有明确提供维度层级的问题。是谓维度表的正则化,如下图。但星型模型更适合浏览维度层级。

     

     

    除了事实表和维度表,数据仓库还需要创建pre-aggregation 表用于存储挑选的摘要数据。

     

    06

    大数据架构

     

    1010data公司高级软件工程师ADAM JACOBS博士在ACM通讯发表的《大数据病理学》指出大数据的病理在于分析而不在于存储——我们期望从成年累月积累的数据中在几分钟或者几秒内获得分析结果!

     

    其实作者指出了关系数据库的在大数据时代的病理,如下图所示一个数据仓库分析操作的SQL在数据量超过100万条记录时的性能表现。

     

    The pathologies of big data are primarily those of analysis.

     

     

    因此,数据仓库被认为是对数据库查询性能问题的一个解决方案。在90年代,人们已经都面临一个数据爆炸的挑战,为了解决那个时代的“大数据”问题,数据仓库应运而生。

     

    在1980s早期,大数据是指数据集超出了磁带机的处理能力。

    在1990s,大数据是指数据集超出了Microsoft Excel或者桌面PC的处理能力。

    今天,大数据是指数据集超出了关系数据库的处理能力。

     

    站在大数据时代回望数据架构的发展历史,然后从技术的角度思考大数据的定义:

     

    当前流行的技术处理不了的数据,都是大数据。

     

    数据仓库的本质是把数据变小,一般有两个方法:

    第一是通过抽取,转换,加载,清洗。

    第二是通过pre-aggregation获得数据的一份单独拷贝。因此数据仓库被定义为:

     

    为了方便查询分析,把数据从关系数据库中单独拷贝一份出来,然后通过ETL或者ELT转换。

     

    对于大数据,仅仅简单构建一个数据仓库是不够的。数据应该如何结构化才能更便于分析?数据库和分析工具应该如何设计才能更高效的处理大数据?

     

    意识到大数据固有的时间属性和空间属性,是我们理解关系数据库处理大数据时存在性能问题的重要前提。

     

    如果说数据是我对世界的观察记录的话,大数据是我们对世界在时间和/或空间维度的重复观察。这就是大数据的时空特点,也是数据仓库多维模型的构建原理。

     

    当今的主流数据库模型是关系数据库,并且该模型显式地忽略表中的行的顺序。这将不可避免导致应用以非顺序的方式查询数据。

     

    在这种情况下,传统的数据架构可以通过引入缓存的方式缓解性能问题,而大数据则会大大放大了次优访问模式对性能的影响。

     

    如下图所示随机访问和顺序访问的差别。

     

     

    因此我们要引入,也是我们要推导的结论:逆正则化(逆规范化)和顺序存储,不可更改数据集(append only,immutable data set)。顺着存储栈往下走,直到数据存储格式。

     

    是时候放弃关系数据库了。

     

    简单解释一下逆正则化(逆规范化)。经典关系数据库介绍的所有范式指导思想都是正则化,减少重复数据,如果重复,则单独创建一个表,使用外键关联,目的是节省存储空间(那个时候存储很昂贵)。

     

    逆正则化则是允许列之间的重复。如下图所示。

     

     

    我有一个看法,NoSQL的键值存储即是用极简的非结构化来实现结构化存储的逆规范化。

     

    键值存储是极简的结构化,也是极简的非结构化。

     

    关于顺序存储,不可更改数据集,可以参考Pat Helland《Immutability Changes Everything》,和我上面的介绍是一致的。

     

    关于传统关系数据库的讨论还有数据库知名专家,2015年图灵奖得主Michael Stonebraker撰写的《One Size Fits All》,分别从数据仓库和流处理两个方面探讨了数据库25年来一招不变的灵丹妙药已经不再适合现在的业务发展。

     

    文章的中心思想和Pat Helland提出lambda架构也有异曲同工之妙。

     

     

    speed layer
    (i) compensates for the high latency of updates to the serving layer 
    (ii) deals with recent data only

     

    serving layer
    (i) indexes the batch views 
    (ii) Can be queried in low-latency, ad-hoc way

     

    batch layer
    (i) managing the master dataset (an immutable, append-only set of raw data),
    (ii) pre-compute the batch views

     

    Lambda架构统一了传统数据仓库时代的半实时在线查询,刚刚兴起的实时流处理(Online ),和批处理数据分析(Offline),给数据架构的设计人员提供了一个全面的参考。

     

    再结合半结构化,结构化数据存储,SQL and No-SQL混合,我们可以得到下面一个典型的数据架构:

     

     

    上面的讨论是架构的微观考虑,让我们回到大数据架构的宏观指导上来。

     

    目前业界对大数据的一个共识的定义是5个V。如下图所示。

     

    从技术的角度需要专注于其中的三个V,通过阅读大量文献,我得到下面一个范型:

    1. 借力开源软件处理数据多样性挑战

    2. 使用分布式技术解决数据容量问题

    3. 使用实时流处理技术解决数据速度问题

     

     

    传统的OLAP 而言,实时性需求不明显,实时分析的强需求是导致大数据技术的一个原因。

    ——曹洪伟

     

    基于此,我个人推荐的大数据架构是BDAS, the Berkeley Data Analytics Stack。这个架构中不仅包含上面提到的三个思考维度,还提供了整个大数据架构blueprint。内容很多,使用时各个击破,在此不赘述。

     

     

    谈了那么多,总结一下大数据架构的几个要点:

    • 分布式计算

    • 实时流处理

    • Online和Offline

    • SQL和No-SQL:混合架构也是演进路径之一

    • 逆正则化(逆规范化)和顺序存储,不可更改数据集

     

    07

    数据湖架构

     

    Pentaho的CTO James Dixon 在2011年提出了“Data Lake”的概念。在面对大数据挑战时,他声称:不要想着数据的“仓库”概念,想想数据 的“湖”概念。数据“仓库”概念和数据湖概念的重大区别是:数据仓库中数据在进入仓库之前需要是事先归类,以便于未来的分析。这在OLAP时代很常见,但是对于离线分析却没有任何意义,不如把大量的原始数据线保存下来,而现在廉价的存储提供了这个可能。

     

    Nearly unlimited potential for operational insight and data discovery. As data volumes, data variety, and metadata richness grow, so does the benefit.

     

    形象的来看,如下图所示,数据湖架构保证了多个数据源的集成,并且不限制schema,保证了数据的精确度。数据湖可以满足实时分析的需要,同时也可以作为数据仓库满足批处理数据挖掘的需要。数据湖还为数据科学家从数据中发现更多的灵感提供了可能。

     

     

    和数据仓库对比来看,数据仓库是高度结构化的架构,数据在转换之前是无法加载到数据仓库的,用户可以直接获得分析数据。而在数据湖中,数据直接加载到数据湖中,然后根据分析的需要再转换数据。

     

     

    下面我整理了数据仓库和数据湖在多个维度的详细对比。

     

     

    总结起来,数据湖架构有一下几个显著的特点:

     

    1. 数据存储:大容量低成本

       

    2. 数据保真度:数据湖以原始的格式保存数据

       

    3. 数据使用:数据湖中的数据可以方便的被使用

       

    4. 延迟绑定:数据湖提供灵活的,面向任务的数据绑定,不需要提前定义数据模型

     

     

    当然,对于数据湖架构的批评也是不绝于耳。有人批评说,汇集各种杂乱的数据,应该就是数据沼泽。Martin Fowler也对数据湖中数据的安全性和私密性提出了质疑。

     

    08

    电信运营大数据特点

     

    电信运营大数据对应于TMN/FCAPS模型中的电信设备管理数据。如下图所示。

     

    • Fault Management

    • Configuration Management

    • Accounting Management

    • Performance Management

    • Security Management

     

    电信运营数据的特点是数据多样化要求不高,大多数数据是结构化数据,数据容量要求不是特别高,数据的实时处理要求最高。

     

     

    电信运行数据架构强调演进。步步为营,向前兼容,不是一蹴而就的。

     

     

    09

    演进路径实践

     

    现在的架构是一个典型的数据仓库架构。如下图所示。现在的架构设计有以下几个要点:

     

    • ROLAP:基于Oracle数据库,但并没有用Oracle的数据仓库,单独构建数据仓库。

       

    • Meta Data Driven的架构设计:Meta Data覆盖整个数据pipe。当新的数据需要集成,只需要编辑新的Meta Data,系统不需要做任何改变。

       

    • Schema设计:主要有两类表:原始数据表和聚合表; 每类表都有三层结构:表,用作聚合的视图,用作报表的视图。不同的应用使用不同的视图来操作数据。当原始的数据表结构变化时,可以根据需要更改不同层次的视图。

       

    • Schema的演化。这是一个比较大的主题,关系数据是schema on write的,任何列的增加都需要alter表结构,这会带来客户系统很长时间的downtime。因此原始表采用1000列的设计(Oracle支持的最大列数),并且列只增加,不减少,避免了数据库schema的变化,降低不同release之间migration的成本。

       

    • 数据存储:定期清除原始数据,只保留聚合数据。

     

     

    为什么现在的架构需要演进呢?

     

    首先当前架构面临扩展性的挑战。数据库扩展性主要依赖于Oracle RAC解决方案,Oracle RAC不是一个线性的扩展方案,同时也增加了很多管理和维护成本。并且由于硬件的限制,垂直性扩展不是一个长期的解决方案。

     

    其次,当前的存储成本太昂贵,因此去IOE成为目标。

     

    第三,实时处理需求也是驱动架构演进的重要因素。

     

    然后,架构变成了这样子:

     

     

    传统 SQL 基于云平台重新定义为 NewSQL,那么 Data Warehouse 也可以重新定义 New Data Warehouse。

    ——曹洪伟

     

    这样的架构是不是New Data Warehouse,我不知道,可能是。在这样的架构下,最大的变化就是更换Oracle数据为HDFS,并使用SQL on Hadoop(比如Hive SQL,Spark SQL)等保持SQL接口,维持了前端分析引擎的不变。Meta Data部分依然保持了原来的数据建模,并没有改变数据集成方式。这样的架构继承了经典的仓库架构,提高系统扩展性,在满足业务需求的同时,最大化的保护已有投资。

     

    在架构演进这个过程中,有一些lesson learned:

     

    • SQL on Hadoop是必须的。客户希望保持SQL接口的连续性。

       

    • 混合数据仓库架构:针对不同的业务采用不同存储方案(Oracle 和 HDFS),数据量大的采用HDFS存储,数据量不够大的(不存在扩展性挑战的)可以依然使用关系型数据库。

       

    • 逆规范化对性能的影响重大。通过对逆规范设计,可以达到关系数据库的查询性能。但是对于逆规范化是否存在其他影响,还需要研究。

       

    • 相对于sequence files 和RC files,ORC文件格式的性能是最好的。

       

    • 实时pipe使用storm和Kafka实现。

     

    就像 NewSQL 那样,可以有 New Data Warehouse 的。就是 Data Warehouse与云计算的融合,即数据仓库的存储层在云平台,采用分布式系统。

     

    对应用侧而言, 原有的方式依旧有效,这样就不会资产浪费,而是有效的继承, 也是通往数据湖的一个较稳妥的步骤。

    ——曹洪伟

     

    老曹这么一说,豁然开朗。我们在谈数据仓库架构向大数据架构演进的时候,其实我们在谈New Data Warehouse架构。

     

    就像当初数据仓库的出现是对数据库系统存在的限制进行补充一样,目前的大数据平台是对数据仓库系统存在的问题进行补充。

     

    他们的技术思路,技术架构,用户需求某种程度上是一致的,或者说核心的思想是一致的。不一致的地方仅仅是为了满足性能而做的技术方案的调整。

     

    首先看数据集成架构。如下图,基于Hadoop的数据集成架构和基于关系数据库的传统数据集成架构是一致的。

     

    不同地方在于由于数据量的增大,左边的架构采用具有逆正则化(逆规范化)和顺序存储,不可更改数据集等特点的Hadoop平台存储数据。

     

     

    其次看数据分析方法。虽然说基于Hadoop的数据集成架构采用了Hadoop数据存储平台(内置MapRdecue数据处理引擎)。

     

    其数据操作,数据分析方法在思想上是一致的——从大量的数据集中获得由价值的信息——如下图所示,数据仓库的操作语句(group-by-aggregation)与MapRdecue的操作函数对应关系。

     

     

    所以MapRdecue的核心思想就是在数据分片的基础上把数据仓库中的group-by-aggregation操作转换成分布式执行,MapRdecue和传统数据仓库的思想是一致的。

     

    The Map-Reduce programming model provides a good abstraction of group-by-aggregation operations over a cluster of machines.


    The programmer provides a map function that performs grouping and a reduce function that performs aggregation. 


    The underlying run-time system achieves parallelism by partitioning the data and processing different partitions concurrently using multiple machines.

     

    所谓创新,继承和发展,大概如此吧。怪不得Michael Stonebraker撰文《MapReduce: A major step backwards》指出MapReduce是一个巨大倒退,并引发了他和DeWitt之间的大论战。

     

    Google在2010年还为MapRdecue申请了专利,但我认为MapReduce不算是重大基础性创新,本质上还是云时代的数据仓库技术(New Data Warehouse)。但其作为Google三架马车的风头让人们大大忽略了传统数据仓库的技术思想,误导了很多年轻学子的技术崇拜。

     

    所以本文尝试提供一个技术脉络:Data Warehouse->New Data Warehouse->Data Lake,阐述大数据技术背后的技术架构演进,抛砖引玉,欢迎批评指正。

     

    A giant step backward in the programming paradigm for large-scale data intensive applications.

     

    Not novel at all -- it represents a specific implementation of well known techniques developed nearly 25 years ago.

     

    To draw an analogy to SQL, map is like the group-by clause of an aggregate query. Reduce is analogous to the aggregate function (e.g., average) that is computed over all the rows with the same group-by attribute. 

     

    在New Data Warehouse架构的基础上,如何向Data Lake演进?对电信行业来说,NFV和SDN正在推动电信网络设备控制平面和数据平面的分离,电信设备数据会走向数据湖架构。

     

    电信设备数据融合,运营数据融合,最终会走向一个大融合。总结起来,电信大数据对于数据湖架构的拥抱,来自于以下四个方面的驱动。我用四个推导公式,如下:

     

    • 5G->BigData (Semi-Structured and Unstructured) -> Modern Data Architecture for Enterprise -> Data Lake Storage Architecture -> Data Lake

    • Cloud -> Network Function Cloudification -> Network Function Virtualization -> stateless VNF -> Distributed Sharing Storage -> Data Lake

    • Distributed analytics -> Data Lake

    • Hierarchy architecture -> Flat operations architecture -> Data Lake

     

    我们尝试过在数据加载过程中自学习的产生数据库schema,证明这个思路是可行的。基于结构化的数据,这个过程非常容易。但对于非结构化的数据,还是存在很大的挑战。

     

    使用机器学习的方式,模型训练成本恐怕和人工抽取schema的工作量是相当大的。但是我也看到在一些CMDB的数据库宣称已经支持数据库schema的自动升级,等我调研一下再说。

     

    来源:data-lake

     

    作者:石头

    展开全文
  • 一、系统架构 1、描述 2、示例图 二、软件架构 1、描述 2、示例图 三、总体架构 ...六、数据架构 1、描述 2、示例图 七、技术架构 1、描述 2、示例图 八、物理架
  • 狭义的数据仓库数据架构用来特指数据分布,广义的数据仓库数据架构还包括数据模型、数据标准和数据治理。即包含相对静态部分如元数据、业务对象数据模型、主数据、共享数据,也包含相对动态部分如数据流转、ETL、...
  • 那么该如何设计元数据管理的架构,才能最大...本次公开课将重点为大家讲解元数据架构设计的相关内容。第一部分:如何理解元数据这个比较抽象的概念?1、 如何理解元数据?2、 传统元数据与广义元数据之间有什么关系?
  • 二、软件架构1、描述2、示例图三、总体架构1、描述2、示例图四、业务架构1、描述2、示例图五、应用架构1、描述2、示例图六、数据架构1、描述2、示例图七、技术架构1、描述2、示例图 八、物理架构 1、描述 2、示例...
  • 回首数据平台建设心路,探索数据架构新方向

    千次阅读 热门讨论 2020-12-16 16:18:32
    回首数据平台建设心路,探索数据架构新方向一、引言二、对平台的简单认识1.关于数据集成2.更好的离线计算3.离线&实时&AI三、平台发展新机遇四、平台建设挑战 一、引言 本人钱包里有几百块一直没有花出去的...
  • 微服务开发中的数据架构设计

    千次阅读 2018-03-18 23:08:04
    原文:微服务开发中的数据架构设计 关注微信公众号:「GitChat 技术杂谈」 一本正经的讲技术 【不要错过文末彩蛋】 前言 微服务是当前非常流行的技术框架,通过服务的小型化、原子化以及分布式架构的弹性...
  • 在实际工作中,我们经常听到“架构”和“架构师”这样的名词,并不新鲜...
  • 你想了解的数据架构都在这

    万次阅读 2019-11-17 10:29:55
    最近领导和团队沟通,想提高数据建模团队的能力。结合自己工作的经验和朋友的交流,来总结下如何去做。 二、我做过什么 很多大数据数据仓库人员都是从事过传统BI业务或者数据库业务的。传统BI一般都是Oracle存储过程...
  • 如何成为真正的数据架构

    千次阅读 2016-03-30 08:37:20
    1、为什么需要构建数据架构 数据标准不一致(列名相同数据类型不同、列明相同数据类型相同长度不一、列名没有统一标准识别困难、列名定义不统一类型不一致长度不相同、中文名称相同英文缩写不同或英文缩写相同...
  • 金蝶K/3 Cloud 开放数据架构模型

    千次阅读 2017-09-01 13:35:10
    金蝶K/3 CLOUD系统是一个开放性很强的ERP,给予了用户足够多的自定义...K/3 Cloud - 数据架构模型 - 基础 http://open.kingdee.com/k3cloud/PDM/BD.htm K/3 Cloud - 数据架构模型 - 财务 http://open.kingdee.
  • 工欲利其器: sqlyog 数据架构同步

    千次阅读 2017-06-09 09:27:02
    荐 工欲利其器: sqlyog 数据架构同步   0成本,玩转华为软件开发云!>>>   摘要: 对于mysql, 我们总是了解得太浅, 繁多的命令, 熟悉谈何容易.sqlyog 是最优秀的mysql管理工具, 数据架构同步可以...
  • 数据架构规划

    千次阅读 2014-05-21 13:37:50
    架构师的角色中,沟通是要求有效果的必备技能与工具。换句话说,沟通是架构师指示别人或群体完成特定行动唯一真正有效的手段。  架构师通常没有对为其项目工作的他人的直接管理权。他们的项目往往是跨部门的,...
  • 《SOD框架“企业级”应用数据架构实战》是框架作者“深蓝医生”10年架构师经验的精华总结,同时又是 国内第一本探讨程序员行业“996”问题现状与解决方案的图书,也是探讨普通程序员生存现状,拜托繁琐的CRUD,如何...
  • 在保障数据层的高性能与高稳定方面,最容易想到的方式就是对数据进行分片、多份、冗余等,很多架构的本质其实也是基于这几点来实现的。 这里先不看细节,即先不管底层数据源是什么数据库,我们先只聊架构方案,因为...
  • 数据架构之多租户

    千次阅读 2018-12-10 02:25:34
    我们按照ADMEMS方法论的理论指导,结合《Pandora数据工厂之多租户项目介绍》进行预架构阶段的架构分析过程实践,多租户功能介绍如下。 一、功能需求 采用“职责协作链”来梳理的如下关键功能 二、功能列表 三...
  • IFTTT的数据架构

    千次阅读 2016-04-11 18:51:29
    最近在调研一款神器——IFTTT,发现这个应用用了不少高端的技术,比如说:Docker、微服务架构、Kafka、Amazon云服务、Elasticsearch、机器学习、数据挖掘等。下面开始介绍。 IFTTT简介 各种各样的互联网服务如社交...
  • 目录:一、航空业数据治理现状二、航空业大数据治理的三个发展趋势三、规划企业数据架构的两种模式四、规划企业数据架构的三个关键技术五、总结一、航空业数据治理现状目前航空行业数据治理已经逐步在开展起来,驱动...
  • 数据架构:数据中心 主备、双活

    千次阅读 2019-02-21 19:23:07
    一个是主数据中心用于承担用户的业务,一个是备份数据中心用于备份主数据中心的数据、配置、业务等。备数据中心之间一般有主备(Active-Standby)热备、冷备,双活(Active-Active)备份方式。  热备的情况下,...
  • 作者介绍刘庆会,主要负责普元大数据治理产品的实施,十年大型企业信息...声明:本文转自EAWorld(eaworld)公众号目录大纲:1、航空业数据治理现状2、航空业大数据治理的三个发展趋势3、规划企业数据架构的两种模式4
  • 100亿数据1万属性数据架构设计

    千次阅读 2017-02-16 09:27:49
    本篇将讲述一下58同城最核心的数据“帖子”的架构实现技术细节,说明不仅不是“不可能这么用”,而是大数据,可变属性,高吞吐场景下的“常用手段”。   一、背景描述及业务介绍 问:什么是数据库扩展的version ...
  • 一张图看明白金融数据架构

    千次阅读 2017-04-23 10:51:08
    金融机构将数据分为第一数据平面和第二数据平面,第一数据平面主要基于原有的金融IT平台,以交易为中心,支撑传统的金融数据处理与分析业务。第二数据平面则是以大数据平台为核心的...该架构除了实现基于Hadoop的基础
  • 在做数据库设计时,往往把数据仓库设计和在线交易库分开考虑,但是如果站在企业级别就要统一考虑,这样在设计时就会规避好多问题,在技术/数据架构设计时,可以控制全局的复杂性,可重用性,可扩展,可管理性,下面...
  • 我们需要什么样的数据架构

    千次阅读 2020-02-22 17:52:10
    作者 |Stephanie shen编译 | 火火酱,责编丨Carol出品 | AI科技大本营(ID:rgznai100)在大数据和数据科学的新时代,对企业而言,一定要有与业务流程保持...
  • Mysql处理海量数据架构优化

    千次阅读 2012-05-26 23:38:54
    前言 Mysql处理海量数据的优化可以从一下四个方面入手。 业务优化: 业务分流,Sql语句优化 ...架构优化: ...分表分库,读写分离,数据缓存 ...本篇文章主要从架构层面讲解Mysql处理海量数据。也是比较基

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 156,666
精华内容 62,666
关键字:

数据架构