精华内容
参与话题
问答
  • 一个运行了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、 传统元数据与广义元数据之间有什么关系?
  • 在实际工作中,我们经常听到“架构”和“架构师”这样的名词,并不新鲜...

    在实际工作中,我们经常听到“架构”和“架构师”这样的名词,并不新鲜,但是总让很多刚入门的人感觉很神秘,甚至是高深莫测。很少有人对“架构”有全面的了解和认识能并说清楚架构是什么,更谈不上掌握了。事实上,也只有极少数人能成为或者被冠以“架构师”这样的title。为此,笔者总结了对架构的一些理解,希望能够补充很多初入门的人在这方面认识上的不足,纠正一些误解。高手和老鸟就直接跳过吧。

     

    • 架构的分类

     

    对于“架构”来讲,理论上划分了5种架构视图,分别是:逻辑架构、开发架构、运行架构、物理架构数据架构。根据名字,大家都可能大概能猜到其侧重点和含义。这里先用通俗的文字简单介绍下,便于大家理解,大家可以不必纠结概念和这些理论。

     

    逻辑架构:逻辑架构关注的是功能,包含用户直接可见的功能,还有系统中隐含的功能。或者更加通俗来描述,逻辑架构更偏向我们日常所理解的“分层”,把一个项目分为“表示层、业务逻辑层、数据访问层”这样经典的“三层架构”。

    开发架构:开发架构则更关注程序包,不仅仅是我们自己写的程序,还包括应用程序依赖的SDK、第三方类库、中间价等。尤其是像目前主流的Java、.NET等依靠虚拟机的语言和平台,以及主流的基于数据库的应用,都会比较关注。和逻辑架构有紧密的关联。

    运行架构:顾名思义,更关注的是应用程序运行中可能出现的一些问题。例如并发带来的问题,比较常见的“线程同步”问题、死锁问题、对象创建和销毁(生命周期管理)问题等等。开发架构,更关注的是飞机起飞之前的一些准备工作,在静止状态下就能规划好做好的,而运行架构,更多考虑的是飞机起飞之后可能发生的一些问题。

    物理架构:物理架构,更关注的系统、网络、服务器等基础设施。例如:如何通过服务器部署和配置网络环境,来实现应用程序的“可伸缩性、高可用性”。或者举一个实际的例子,如何通过设计基础设施的架构,来保障网站能支持同时10W人在线、7*24小时提供服务,当超过10W人或者低于10W人在线时,可以很方便的调整部署架构来支撑。

    数据架构:数据架构,更关注的是数据持久化和存储层面的问题,也可能会包括数据的分布、复制、同步等问题。更贴切来讲,如何选择需要的关系型数据库、流行的NOSQL,如何保障数据存储层面的性能、高可用性、灾备等等。很多时候,和物理架构是有紧密联系的,但它更关注数据存储层面的,物理架构更关注整个基础设施部署层面。

    上面讲了那么多,相信国内很少有公司是严格按照这五种视图去分工和设计的。其实在笔者眼中,架构大致分为两种:软件架构、系统架构。前三种视图,可以归纳为软件架构,而后两种架构,则归为系统架构。这也比较符合国内大部分中小型互联网公司的现状。

    根据应用特性的不同,关注侧重点可能不同。例如,某些门户类的互联网应用,读多写少而且业务相对比较简单,则更加关注“高性能、可伸缩性、可用性”等方面。对于更加复杂的应用,例如电商类大规模交易型的应用,对每个层面和每个环节都会比较关注。对于业务型的系统,例如一些生产型企业使用的ERP,或者仅供企业内部使用的一些MIS、OA应用,通常更关注功能和复杂的业务和实现和扩展,而对性能等方面又可能不要太高,这类应用则更关注纯软件架构层面。这里,不展开做具体讨论。所以很多时候,架构师也需要是一个团队,而不是一个人“全栈”。

     

     

    • 架构设计到底是什么

     

    在长期的技术招聘面试中,我发现在很多人眼中,架构就是分层,架构设计就是“三层架构”(或者四层、五层...反正分层越多就说明项目越复杂而且架构就越牛),或许是受到诸如PetShop之类的示例项目的影响,这里暂时不去追究原因了。

    之前已经纠正过很多人的误解-架构不只是软件架构。说一下通俗点的理解:

    软件架构就是实用而且优雅的设计,它不在于分多少层,或者应用了多少种设计模式/架构模式等。它应该是以满足实现用户需求为前提,以开发人员普遍可接受为根本的,而且要符合系统特性和业务发展需要的,从软件设计的角度,能够达到层次清晰、可维护、可重用、可扩展...就非常优秀了,无需刻意去纠结分了多少层,是否使用了什么模式,有多么抽象等。以面向对象设计为例,基本目标是“高内聚、低耦合”,为此我们可能会遵循一些常见的设计原则(例如经典的SOLID设计原则)。最后纠正一点,通常我们所说的模式,其实又分为很多种,并不是仅仅指的是“设计模式”(设计模式也有千千万,并不是只有常见的GOF 23种设计模式)。通常包括:企业架构模式、设计模式、SOA模式、企业集成模式等等。

    强调一下,架构要讲求“实用”,而且开发人员普遍可接受,要符合现状的。否则,再“优雅”的设计,都会沦为高成本的“花架子”,生搬硬套和过度设计只会让项目“流产”。

     

     

    • 关于Tier和Layer

     

    笔者曾多次在一些技术社区和论坛看到一些关于TierLayer的争论,众说纷纭。其实最容易被广泛认可和接受的理解就是:Tier通常指的是物理上的分层,由执行同样功能的一台(或者一组)服务器定义。而Layer通常指的是逻辑上的分层,对于代码的组织,例如:我们通常提到的“业务逻辑层,表现层,数据访问层”等等。

    Tier指代码运行的位置,多个Layer可以运行在同一个Tier上的,不同的Layer也可以运行在不同的Tier上,当然,前提是应用程序本身支持这种架构。以J2EE和.NET平台为例,大多数时候,不同的Layer之间都是直接通过DLL或者JAR包引用来完成调用的(例如:业务逻辑层需要引用数据访问层),这样部署的时候,也只能将多个Layer同时部署在一台服务器上。相反,不同的Layer之间如果是通过RPC的方式来实现通信调用的,部署的时候,便可以将不同的Layer部署在不同的服务器上面,这也是很常见的解耦设计。

    如下图所示:

     

    顺便再纠正一点,很多人问“到底什么是web服务器,什么是应用服务器”。这个恐怕没有标准答案的。有些人可能觉得,处理静态资源的就是web服务器,处理动态请求的就是应用服务器,这其实是不准确的。以互联网领域典型的SOA架构为例,上层Web应用所在的服务器,可以叫web服务器,web应用仅仅负责处理输入/输出,而提供服务宿主的服务器可以称为应用服务器(也包含对业务逻辑和数据访问的处理)。当然,服务的宿主方式可以有很多中,可以是系统服务,是可执行程序,是web应用,是Socket网络服务...

     

     

    • 逻辑分层和物理分层的好处

     

    逻辑分层的好处:

     

    1. 代码组织更清晰
    2. 更易于维护
    3. 更好的代码重用性
    4. 更好的团队开发体验性
    5. 更高的代码清晰度

    物理分层的好处:

     

    1. 性能
    2. 可伸缩性
    3. 容错性
    4. 安全性
    • 架构师的分类

     

    架构师往往是很多开发人员向往的职业,也不是像很多人想象中的那样(画一下PPT或者UML草图,然后交给程序员们去实现,然后自己就自由玩耍了)。国内很多公司,是没有架构师这种岗位定义的,通常是由技术优秀和经验比较丰富的开发人员担任,身兼多职的情况也并不少见(我见过很多小公司的骨干人员是身兼技术主管、系统分析师、项目经理、架构师、核心开发人员...)。值得纠正的就是,架构师和系统分析师不同,系统分析师更侧重在项目早期的需求分析。而架构师,一般贯穿整个软件开发周期,与项目经理也是相辅相成的。微软对于架构师,又分为:软件架构师、系统架构师、解决方案架构师、企业架构师等。而其它一些厂商,可能又会划分:技术架构师、业务架构师、网络架构师、安全架构师、SOA架构师......

    大家不必对这些概念太纠结。按照笔者的理解,国内大互联网公司里,架构师一般只会分2-3个方向:软件架构师和系统架构师(有些企业叫运维架构师),有些企业对于比较资深DBA而且懂整个系统架构的,还会分出所谓的“数据架构师”。至于具体Title,大可不必纠结,只需了解自己的兴趣,知晓了大致发展和定位,然后朝该方向努力即可。对于程序员而言,最基本的还是先写出高质量的代码,在实战中逐步提升自己设计思维。

     

    限于笔者水平和理解有限,文中全部文字和描述等全凭笔者记忆和理解写出,难免出现错误,请热心的读者及时批评和指正。

    由于时间有限,部分图片笔者画的比较粗糙,也请读者谅解。

    转载于:https://my.oschina.net/wmy596/blog/1623459

    展开全文
  • 你想了解的数据架构都在这

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

    一、背景

    最近领导和团队沟通,想提高数据建模团队的能力。结合自己工作的经验和朋友的交流,来总结下如何去做。

    二、我做过什么

    很多大数据数据仓库人员都是从事过传统BI业务或者数据库业务的。传统BI一般都是Oracle存储过程,O是真的牛,很多银行和电力业务目前还是存储过程写的业务代码。自己曾经亲身经历过,两千行的业务package,写起来和改起来特别有“成就感”!后来听说了Hadoop,网上自己自己找资料,Win环境搭建了起来,现在去百度还能搜到那篇文章。后来再也不推荐别人去碰Win搭建Hadoop!

    后来机遇,进了大数据行业,参与主导了一些大数据从无到有的建设过程。真的很感谢那段晚上十点后回家的岁月,还有工作中的伙伴,这段工作算是自己的一个能力的很大提升。从没有接触过Linux到写过近1000行的数据处理脚本,现在公司应该还在用吧。接触运维了百亿级别数据聚合秒出的Vertica (商业软件真好用),建了一个100多人的技术交流群,虽然不活跃,但确实帮到很多人。(还专门申请了一个Vertica的域名,部署了自己博客 http://vertica.club/ ,又该续费了……)

    了解了zeppelin,参与了早期的一些功能建议和验证,虽然后来工作中没用到,自己也没有再跟社区,但这个工具真好用,这是专门给数据人的工具,非常好,可以写出很漂亮的数据报告。(下面找我名字吧…)

    三、数据人应该做什么

    还是说说我熟悉的数据仓库建设。个人认为数据人员可以走两个大方向提升自己(当然数仓理论知识必须得掌握),一、精通业务,熟练SQL,加强工程能力。记住工程能力很重要!二、了解算法,掌握PYTHON,熟练做分析。我是那种什么都想做的人……

    1)、精通业务,就要做到业务指标的标准由你说了算,努力成为业务专家,参与一些重要指标的定义。比如去看公司的Wiki,通过在公司熟悉的同事找到业务架构负责人,了解相关资料。

    2)、熟练SQL,并不仅仅是熟练写。要做到了解SQL的执行计划,掌握执行数据库环境的调优。当然很多人会说这是DBA做的工作,但是数据人应该比DBA写的SQL多吧,当你发现你写的一段逻辑能从1个小时优化到5分钟,你就会发现这是多有成就感。掌握数据库,要从数据库的存储架构出发,掌握数据库的简单管理,熟练应用场景。最终你掌握几种数据库使用后,你会发现你能够帮助公司或部门做数据库选型了。

    算法这个笔者自己现在还没真正入门,学习中……,欢迎大神带进门!

    四、如何做

    1),既然是做大数据的数据仓库,对大数据各个组件要有了解,对大数据整个处理架构要有了解,从数据采集,到处理,再到数据展示,数据运营等,都需要了解。推荐一本书《大数据之路》,很感谢上家公司选购了这本书,给员工看。

    2),SQL 熟能生巧,其实可以尝试用SQL写一些小工具,记得自己15年的时候闲暇写了一个身份证解析的包,大家用着很不错。附上代码 :https://blog.csdn.net/windyqcf/article/details/46048657

    3),养成笔记的习惯,记得刚开始接触Vertica数据库的时候,自己上网百度,很少有资料,没办法,只能自己看英文版的官方文档,在自己的环境和工作中尝试总结,形成博客,慢慢发现自己积累了很多。

    五、数据中台的理解

    • 什么是数据中台

      数据中台的概念最是阿里提出来的是为了实现数据的分层和水平解耦,提供数据服务能力。看了那么多中台的概念,对中台也有些自己的理解。笔者认为中台主要是为了提供全域的数据服务。主要包括以下4部分:数据资产、数据治理、数据模型、数据服务。 image

      打通数据建模对全域数据进行沉淀形成数据资产,从而提供统一的数据服务功能。

    • 如何建立数据中台

    建设数据中台主要就是从数据模型、数据资产、数据治理、数据服务四部分出发。

    首先需要做整体规划,哪些数据需要纳入到数据中台中,根据数据接入的情况,进行技术选型,评估集群的配置,规划至少3年的计算和存储资源。

    • 数据模型

      数据模型,就是我们熟悉的数据仓库中的模型,按照数据仓库规范分层开发模型,实现数据的标准化,多采用维度建模。还有一些挖掘模型,如果用的多了,也可以沉淀到数据中台中。我们可以看出数据中台中的模型具有通用性。

    数据建模一般分为2个步骤:

    1. 确认事实表,分析业务的生命周期,明确业务的关键步骤。在进行指标定义的时候是否覆盖了本主题语中的全部指标,判断哪些指标可以通过加减乘除计算得到等。
    2. 确定维度,粒度是模型设计的关键,太细的粒度不利于上层数据分析汇总,太粗的粒度又不能满足前段多维度个性化查询需求。基于此,模型设计时候一般考虑分层,层级越往后,粒度越粗。冗余维度也是需要考虑的,设计冗余的维度可以避免统计中过多的关联导致复杂的计算逻辑,影响性能。
    • 数据资产

    在数据仓库中我们已经建立了一些模型,但是只有打通数据孤岛后才可以称为资产。需要规范指标库,这些指标可以组合处理满足外部人员个性化的指标需求。资产管理的基础是做好元数据管理,元数据包括采集的接口信息,模型信息、指标定义,作业的血缘关系、数据存储以及访问情况等。

    • 数据治理

    很多数据仓库人员曾沦为“表哥”,天天忙着提取数据核对指标,时间长了,业务人员容易对你的数据不信任。数据治理主要是为了保障数据资产的完整性、准确性、一致性、及时性。根据指定的规范开发模型、校验模型、管理模型,为业务提供统一的、准确的指标保驾护航。

    • 数据服务

    数据中台最重要的就是要对外提供统一的服务能力。数据服务需要包含以下几个能力:

    • 数据接口标准化:提供统一的数据服务在线查询视图,让开发者能够快速、简单的访问数据服务;

    • 数据开发可视化:提供服务接口的可视化配置,开发者只需要配置SQL就可以生产API,减低接口开发技术要求,便于维护和接口管理。对于业务分析人员可以让他们轻松的进行算法分析,包括模型管理、可视化编排流程,算法模型发布等功能。

    • 数据中台和数据仓库有什么不同

    很多人对数据中台和数据仓库两个概念可能不是很清楚,其实最主要的是思维理念不同,数据仓库是“管理数据”,数据中台是“经营数据”,数据中台是为了提供服务而生(也有说是为了前台而生)。

    参考资料:《数据中台-阿里巴巴的数据整合、价值发掘、社会赋能之道

    [1] https://img-blog.csdnimg.cn/20190226204152675.jpg

    [2] https://yq.aliyun.com/articles/297782

    欢迎关注公众号:数据社

    回复关键字,下载数据相关资料

    在这里插入图片描述

    展开全文
  • 数据架构规划

    千次阅读 2014-05-21 13:37:50
    架构师的角色中,沟通是要求有效果的必备技能与工具。换句话说,沟通是架构师指示别人或群体完成特定行动唯一真正有效的手段。  架构师通常没有对为其项目工作的他人的直接管理权。他们的项目往往是跨部门的,...

    一.当前架构

        结合研发二部数据量最大的校讯通产品来描述,其他的产品在性能上出现瓶颈,可以向校讯通靠拢。

    数 据库整体架构:目前校讯通产品根据用户量的多少以及数据库服务资源的繁忙程度,横向采用了历史库+当前库的分库架构或者单一的当前库架构,其中历史库只作 为web平台读数据库,纵向结合了applications的memcache+Sybase ASE12.5传统永久磁盘化数据库架构。

    数据模型架构:原则上采用了一事一地的数据模型(3NF范式),为了性能考虑,一些大数据量表适当的引用了数据冗余,根据业务再结合采用了当前表+历史表的数据模型。

    以下就用图表来进行当前数据架构的说明:

    横向分库数据库架构图:

     数据架构规划


    纵向app layer+memcache layler+disk db layer图:

    数据架构规划

    其中web层指的是客户端浏览器层,逻辑上:app层指的是应用服务层,mc层指的是memcache的客户端层,ms层指的是memcache的服务层,db层指的是目前永久磁盘化的数据库层,当然在物理机器上可能app层跟mc层,ms层是重叠的部署在相同服务器上。


    数据模型架构图:

    数据架构规划

        其中以上数据模型中除了少数几张表外其他的都有历史表存在,当然有很多表是没在这个模型图中的,这部分是核心数据模型。这部分模型对象中也包括了一些冗余 性的设计,比如用户中有真实姓名,特别是不在这个模型内,由模型核心表产生的一些统计报表,为了查询的性能冗余了合理一些学校名称,地区名称等方面的设 计。

     

    二.劣势现象

    1.流水表性能瓶颈

        当前架构的性能瓶颈集中在流水表的访问上,最大流水表的记录量达到了超5亿级别,这是由于目前外网在用的sybase数据库系统版本,没有采取很好的关于 分区的技术。曾经有过把流水表进行物理水平分割,把不同月份的数据分割放在不同的物理表上的模型改造设想,碍于产生的应用程序修改工作量大,老旧数据迁移 的麻烦,再加上进行了从单库架构改造到分库架构后,数据库性能瓶颈就不是特别突出。所以模型改造这部分工作没展开。

    无 论是单库或是分库的模式,出现平台访问数据库的性能瓶颈依然集中在大流水表上,在访问高峰高并发量情况下,短信的流水表进程堵塞,数据库服务I/O ,CPU的资源耗费达到顶点,在服务器硬件环境不是特别理想情况下,出现了一定概率造成用户访问缓慢甚至觉得页面无法响应现象,造成了用户体念不良影响。

     

    2. 运营维护难点

        1)历史数据清理运维工作

        为了存储充分利用,为了性能的提升,需要定期进行不再使用的历史数据清理,

    由 于清理的数据量庞大,传统的数据清理方法根本不可能保证一个晚上有效清理完毕,确保平台第二天正常的运行。虽然目前已经实行了比较高效且可行的数据清理方 法,但是每次实行都需要晚上到通宵进行处理,使得数据清理的运维工作特别劳累,影响到运维人员第二天的正常出勤,间接就有可能影响到数据库的正常运维监 控,导致数据库问题出现。

        2)防止索引失效而进行的统计量更新运维工作

        由于流水表数据变动量大,容易导致流水表的索引失效,从而需要定期的进行索引甚至整表的统计量更新工作,统计量更新时间跟流水表的数据总量成正比关系,所 以导致统计量更新速度比较慢,不能确保在计划时间内,统计量更新的完全成功,而且目前外网安装的sybase12.5版本是最低一个的EBF版本,存在较 多BUG,在索引统计量更新过程中可能导致数据库出现病态,进而影响第二天数据库的正常运行。

     

    3.运维监控纰漏(此部分非架构原因引起)

        当前的数据库监控以及运维维护还存在一些纰漏,出现了多次数据库设备空间使用完毕,没有及时添加数据库设备空间导致数据库挂起问题,也多次出现了数据库日 志空间占满导致数据库挂起问题。此类问题还是比较明显,还有一类问题,不是整库挂起,而是部分业务表访问异常,运维可能监控不到,等用户访问到了这部分业 务功能不正常,由用户反馈到运维这边。

     

    4.运营统计报表在当前数据模型架构下重用性较低

        由于用户需求的渐进性,导致数据库统计报表在数据模型设计时没有站在至高点,随着用户需求的不断积累,数据库统计报表对象也跟着不断积累,发现目前存在比较大一部分的统计报表数据在不同数据库对象之间重复统计,没有充分发挥统计数据的重用性。

     

    5.没利用集群技术

        当前的数据库架构还没采用成熟的集群技术,集群技术并不单单指单一数据库系统的集群,可以混合集群,比如内存数据库跟传统永久磁盘化数据库系统集群。

     

    6.分库架构还可完善

        当前的分库架构还可以继续完善,引用成熟的数据库主从分离,读写分离技术。

     

    7.内存数据库技术还没充分利用

        当前的数据库架构虽然在前端使用了memcache技术,但是还可以继续完善使用内存数据库技术再结合异步写技术,使得架构相得益彰。

     

    8.适合海量数据高并发读写,高效率存储的非关系型数据库没充分利用

        当前的数据库架构还没采用正在兴起的NoSql,NewSql技术(目前部分外围系统采用了mongodb来做试验品,而这部分系统的数据量并不大,非关 系型数据库海量数据高并发访问的高效性优势没有体现出来,从而也没掌握真正的使用经验),当然这种数据库也有缺点,就是数据库事务一致性,数据库的写实时 性和读实时性,复杂的SQL查询,特别是多表关联查询是无法满足的。

     

    三.改进思路

        在第二部分的劣势现象中,总结了当前数据库架构以及数据模型架构的缺陷,缺陷还比较多,从另外一个角度也反映了公司产品数据库架构改进和提升的空间还比较大,将来随着不断的迭代改进,可以承受的业务量提升的空间也相应的比较大。

    下面就根据劣势现象进行针对性的阐述改进思路:

    1.流水表性能瓶颈改进

        Sybase12.5没有很好的解决大数据量表的性能问题,但是通过数据库转到Oracle后,充分利用Oracle分区表,分区索引的特性来提升流水表 的访问性能,逻辑上表仍然是一张完整的表,只是将表中的数据在物理上存放到多个表空间(物理文件上,这样查询数据时,不至于每次都扫描整张表。由于逻辑上 仍旧一表,使得应用程序不需要修改,也避免了这个劣势点描述的带来额外许多开发工作量的问题,但是效果几乎等同水平分割数据模型。

     

    2.大流水表运维难的改进

        1)历史数据清理运维工作

        在Oracel数库系统中,针对对大流水表每个月的数据进行分区,这样运维人员在清理历史月份的数据时候,只要通过TRUNCATE PARTITION、 DROP PARTITION的Oracle本身的分区维护命令轻松快速清理掉分区的数据(既指定月份的流水数据)

        2)防止索引失效而进行的统计量更新运维工作

        同样Oracle也有等同于sybase的统计量更新工作,在Oracle中通过对大流水表的分区工作后,进行统计量的更新工作同样就快捷简易,可以通过ANALYZE PARTITION的统计量分析维护命令可以轻松快速对指定分区的统计量进行更新。

     

    3.运维监控纰漏的改进

        主要分两个方面:a)数据库剩余空间方面的监控;b)数据库出错日志的监控。这两个监控虽然通过人为主动性的查看数据库相关信息可以监控到,但是总归还是 会有疏忽遗漏的时候,只是出问题几率高低之分。所以这里再加一道监控,就是通过数据库服务器端的监控程序主动发回有问题或者告警的信息给运维人员。这道监 控程序可以通过shell程序以及数据库程序,结合数据库日志以及剩余空间信息以短信或者邮件的方式发回给运维人员。在数据库剩余空间方面甚至可以通过数 据库本身阀值的设置,做到自动截取日志,自动添加设备。

     

    4.运营统计报表数据模型的改进

        由于原先一些报表模型存在着数据统计的重复性,在晚上定时task中既占用了任务列表的总时间,也对其他并行的task运行造成了一定的资源争用,影响了 数据库性能。所以在这里提出了一种类似蒲公英性质的模型,数据通过发散模式,即插即用到不同的运营统计报表中,势必需要改进当前接近一事一地的3范式模 型,把原先的数据模型拆散,从纵向和横向都接近最小粒度需求的数据模型。使得统计数据可以重复使用,不同的统计报表通过这些原子性的统计数据再组合成报表 所需要的数据,当然这里需要一个平衡,并不完全等同蒲公英模型的统计粒度越细越好,因为越细也代表着原始的统计数据量越大,一会影响原始统计的性能,二会 影响组合成报表的性能,三会占用更多的存储空间。这个平衡度需要掌控好。

     

    5.利用集群技术

        当然通过了前面4点的改进之后,数据库性能会比目前的架构提升一定的性能,至于集群技术就可以作为前面4点改进后的补充和扩展,如果在改进后,依然还存在 较大性能瓶颈情况下可以采用Oracle RAC技术。甚至采用基于内存数据库的分布式数据库架构的混合集群技术。比如在Oracle数据库及Web服务之间加一层 Ameoba 分布式数据库代 理结合内存数据库的架构,

     

    6.分库架构完善改进

        目前的数据库架构采用了分库方式,但是主库(当前库)的读写却是没有分离的,纵观淘宝的数据库架构演进历程,确是在某个历程碑点做到了很好的读写分离,应 用到DB的数据写入与查询从双向通行变成了单向通行,通行效率更高,大大避免了相互影响。“借道行驶”的情况不再出现。淘宝那个碑点做到了以下几点:

    1)写库为集中式的oracle环境,提供数据安全性保障。

    2)读库使用mysql, 采用数据分片,分库分表,每台mysql放少量的数据,单个数据分片内部采用mysql复制机制。

    3)读库的超大memory容量,起到了很好的cache作用,在内存中的数据查询性能远远高于在硬盘上的性能

    4)oracle到多台mysql按规则复制

    结合淘宝架构的思考,校讯通大流水也可以做到垂直分割到不同的服务器,也可以做到水品分割到不同的服务器,通过不同的服务器访问不同的流水表或者是不同范围数据的流水表,那提升性能是肯定的。不过也要平衡考虑到应用程序开发的简便性。

     

    7.内存数据库技术利用

        常见的内存数据库产品包括商业版和免费版两类。商业版如:Altibase,Timesten,Berkley DB等。他们在电信,金融,证券等高性能计算应用中运用较为广泛。商业版功能强大,然而,价格比较昂贵,不适合目前“廉价PC+免费软件”的架构搭建思 想。

    开源领域产品主要有H2,HsqlDB,Derby,BerkeleyDB 等。在混合集群架构中,内存数据库将承担OLTP的职责,因此除了读写性能外,功能的完备,事务等都需要作为优先评估的因素。

    盛传H2是一个开源的高性能内存数据库,可以通过整合 Ameoba 与 H2,夹在applications和传统db层之间来达到内存数据库层的架构部署。

    Ameoba 是分布式数据库代理,它与 MySQL 整合已经在阿里巴巴核心业务中成功运用。如果仅将数据库节点看作一个存储,MySQL Node 和 H2 Node 并无本质区别。JDBC驱动,DB切分,路由,皆由Ameoba 统一负责。

     

    8.非关系型数据库的使用

        外围的非核心数据,但是数据量又是比较大的的业务系统数据库可以采用非关系型数据库,这是由非关系型数据库的一些基本特性决定的。

    非关系型数据库有满足如下需求的优点特性:

    1)High performance - 对数据库高并发读写的需求 

    2)Huge Storage - 对海量数据的高效率存储和访问的需求

    3)High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求

    但同时伴随不能满足以下需求的缺点:

    1)数据库事务一致性需求 

    2)数据库的写实时性和读实时性需求

    3)对复杂的SQL查询,特别是多表关联查询的需求

    正 是由于以上的优缺点也决定了,核心的需要保持一致性的数据,需要复杂关联的数据,需要实时访问的数据不要采用关系型数据库,如果通过ETL把关系型数据库 的流水数据冗余基本信息,组成可以直接查询的业务信息数据,导入到非关系型数据库后,那对海量流水数据的查询速度提升空间是很大的。其中代表型的非关系型 数据有Redis,Tokyo Cabinet,Cassandra,Voldemort,MongoDB,Dynomite,HBase,CouchDB,Hypertable, Riak,Tin, Flare, Lightcloud, KiokuDB,Scalaris, Kai,ThruDB等等非常之多。

     

    四.架构计划

        通过以上当前架构劣势以及改进思路的总结,改善的架构计划就比较清晰了,以下还是通过横向的整体数据库架构,纵向的整体数据库架构,以及数据模型的架构改进来做为新的架构计划。

    风险最小,改动工作量最小的架构就是改进思路中以第4点和第5点之间为分割线。这条分割线前的数据架构基本不需要变动,主要变动的就是数据模型架构中的流水表对象,以及数据库服务器后台添加监控以及智能处理的运维程序工具。

    主要改进的数据模型流水表对象如下图:

    数据架构规划

    同样进行分区的还有其他的一些大流水表,这里不一一详述,这些流水表从sybase进入oracle的分区表,在数据库转型升级过程中完成。

    还有一点就是关于数据库监控工具在架构中的部署,如下图所示:

    数据架构规划

    以上架构改进计划可以在一期中先完成。看运行效果状态,第5点之后的改进计划几乎就是架构的重构了,所以涉及的工作量更大,如果在第1,2,3,4点改进后数据库运行稳定,后续的改进,可以通过实验和应用结合逐步实施起来,作为应付更大型的业务应用技术储备。

        下面结合5,6,7,8点的改进思路做个架构规划,也就是分布式的内存与传统数据库结合的混合集群架构模式,再加上外围产品的非关系型数据库,如下图所示(服务器和db合为同个节点说明,否则图片篇幅占用过大):

     数据架构规划

        上面的架构图中,application(应用服务层),data cache层,disk db layer层已经实现,但是disk db Layer层的多数据库集群技术还没不能说正式实现,虽然分库技术有类似集群嫌疑,async write(异步写)听开发人员也已经涉及使用。那么此新架构图针对原架构的改进就是Memory DB Layer层以及类似Ameoba (可以使用其他的代理)分布式数据库代理还没实现。Memory DB Layer集群加上每个逻辑分区有两个内存库是为了其中一个内存数据库一旦崩溃,同一逻辑分区中的替补节点立即顶替工作,做到健壮的容错和 Failover机制。这个架构明显比校讯通当前在使用的架构要复杂很多,稳定性以及性能的提升都有待实际验证,虽然单单从架构上来讲融合了目前很多的技 术优点(集群,内存数据库等)。

    转自:http://blog.csdn.net/xujinyang/article/details/7103421

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

    千次阅读 2018-03-18 23:08:04
    原文:微服务开发中的数据架构设计 关注微信公众号:「GitChat 技术杂谈」 一本正经的讲技术 【不要错过文末彩蛋】 前言 微服务是当前非常流行的技术框架,通过服务的小型化、原子化以及分布式架构的弹性...
  • 一、系统架构 1、描述 2、示例图 二、软件架构 1、描述 2、示例图 三、总体架构 ...六、数据架构 1、描述 2、示例图 七、技术架构 1、描述 2、示例图 八、物理架
  • IFTTT的数据架构

    千次阅读 2016-04-11 18:51:29
    最近在调研一款神器——IFTTT,发现这个应用用了不少高端的技术,比如说:Docker、微服务架构、Kafka、Amazon云服务、Elasticsearch、机器学习、数据挖掘等。下面开始介绍。 IFTTT简介 各种各样的互联网服务如社交...
  • 银行数据架构体系

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

    千次阅读 2018-03-19 12:42:30
    微服务开发中的数据架构设计前言微服务是当前非常流行的技术框架,通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性,可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性。为业务创新和...
  • 二、软件架构1、描述2、示例图三、总体架构1、描述2、示例图四、业务架构1、描述2、示例图五、应用架构1、描述2、示例图六、数据架构1、描述2、示例图七、技术架构1、描述2、示例图 八、物理架构 1、描述 2、示例...
  • 微服务架构设计实践 目 次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 ...
  • 数据架构之多租户

    千次阅读 2018-12-10 02:25:34
    我们按照ADMEMS方法论的理论指导,结合《Pandora数据工厂之多租户项目介绍》进行预架构阶段的架构分析过程实践,多租户功能介绍如下。 一、功能需求 采用“职责协作链”来梳理的如下关键功能 二、功能列表 三...
  • 在经历了长达25年的统治地位后,关系型数据库正面临越来越火的“NoSQL”挑战,而挑战者是以Hadoop为代表的分布式计算开源架构。可以看到,越来越多的消息表明,不管NoSQL是被解释为“No SQL”还是“Not Only SQL”,...
  • 100亿数据1万属性数据架构设计

    千次阅读 2017-02-16 09:27:49
    本篇将讲述一下58同城最核心的数据“帖子”的架构实现技术细节,说明不仅不是“不可能这么用”,而是大数据,可变属性,高吞吐场景下的“常用手段”。   一、背景描述及业务介绍 问:什么是数据库扩展的version ...
  • 数据层面的架构来说,基本上分成了多租户共享单一数据库、单一租户独享单一数据库以及介于两者之间的单一数库下的单一租户独享单一schema三种方案。这篇文章 ...
  • 如何成为真正的数据架构

    千次阅读 2018-07-03 14:14:38
    本PPT来自韩国EN-CORE高级技术顾问、EN-CORE中国分公司恩核(北京)信息技术有限公司总经理郑保卫博士。文章末尾附下载。 下面是内容概要: 1、为什么需要构建数据结构?...7)相对复杂的数据处理能力...
  • Mysql处理海量数据架构优化

    千次阅读 2012-05-26 23:38:54
    前言 Mysql处理海量数据的优化可以从一下四个方面入手。 业务优化: 业务分流,Sql语句优化 ...架构优化: ...分表分库,读写分离,数据缓存 ...本篇文章主要从架构层面讲解Mysql处理海量数据。也是比较基
  • 狭义的数据仓库数据架构用来特指数据分布,广义的数据仓库数据架构还包括数据模型、数据标准和数据治理。即包含相对静态部分如元数据、业务对象数据模型、主数据、共享数据,也包含相对动态部分如数据流转、ETL、...
  • 一张图看明白金融数据架构

    千次阅读 2017-04-23 10:51:08
    金融机构将数据分为第一数据平面和第二数据平面,第一数据平面主要基于原有的金融IT平台,以交易为中心,支撑传统的金融数据处理与分析业务。第二数据平面则是以大数据平台为核心的...该架构除了实现基于Hadoop的基础
  • 基于Oracle的海量数据架构设计

    千次阅读 2013-06-24 10:46:51
    第2课关系型数据库下的大数据解决方案之架构篇--中间件和分布式数据库 第3课 关系型数据库下的大数据解决方案之索引篇 第4课 关系型数据库下的大数据解决方案之分区篇 第5课 关系型数据库下的大数据解决方案之并行篇...
  • 我们需要什么样的数据架构

    千次阅读 2020-02-22 17:52:10
    作者 |Stephanie shen编译 | 火火酱,责编丨Carol出品 | AI科技大本营(ID:rgznai100)在大数据和数据科学的新时代,对企业而言,一定要有与业务流程保持...
  • 首先看一下这一系列文章的标题,“数据-企业最重要的资产”。 当然如果非要从逻辑上来抠的话,这句话一点儿也不严谨。 我们想表达的一个观点是,数据对一个企业来说,真的很重要,重要到会决定一个企业的生死存亡...
  • 金蝶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.
  • 多个Android客户端同步服务器端表中数据架构分析

    万次阅读 多人点赞 2012-09-19 19:42:53
    需求:Android客户端有N个,服务器端只有一个,客户端会不定时的到服务器端同步数据。 思路分析:  由于客户端的个数不确定,而且是不定时的到服务器端同步数据,所以应该由客户端来维护何时发起请求.  客户端...
  • 如何成为一个合格的数据架构师?

    千次阅读 2020-06-19 09:33:28
    早在1980年,未来学家阿尔文·托夫勒就在《第三次‍‍‍‍‍浪潮》中,将大数据比喻为“第三次浪潮的华彩乐章”。二十一世纪以来,数据量进入每两年翻一番的增长期,越来越多人意识到了数据的价值...

空空如也

1 2 3 4 5 ... 20
收藏数 123,288
精华内容 49,315
关键字:

数据架构