精华内容
下载资源
问答
  • Spark2.1.0之模型设计与基本架构

    千次阅读 2018-06-12 09:41:32
    Spark编程模型 正如Hadoop在介绍MapReduce编程模型时选择word count的例子,并且使用图形来说明一样,笔者对于Spark编程模型也选择用图形展现。 Spark 应用程序从编写到提交、执行、输出的整个过程如图2-5所示。图...

    提示:在阅读本文前,最好先阅读《Spark2.1.0之初识Spark》、《Spark2.1.0之基础知识》及《Spark2.1.0之模块设计

    Spark编程模型

          正如Hadoop在介绍MapReduce编程模型时选择word count的例子,并且使用图形来说明一样,笔者对于Spark编程模型也选择用图形展现。

          Spark 应用程序从编写到提交、执行、输出的整个过程如图2-5所示。

    图2-5   代码执行过程

    图2-5中描述了Spark编程模型的关键环节的步骤如下:

    1. 用户使用SparkContext提供的API(常用的有textFile、sequenceFile、runJob、stop等)编写Driverapplication程序。此外,SparkSession、DataFrame、SQLContext、HiveContext及StreamingContext都对SparkContext进行了封装,并提供了DataFrame、SQL、Hive及流式计算相关的API。
    2. 使用SparkContext提交的用户应用程序,首先会通过RpcEnv向集群管理器(ClusterManager)注册应用(Application)并且告知集群管理器需要的资源数量。集群管理器根据Application的需求,给Application分配Executor资源,并在Worker上启动CoarseGrainedExecutorBackend进程(CoarseGrainedExecutorBackend进程内部将创建Executor)。Executor所在的CoarseGrainedExecutorBackend进程在启动的过程中将通过RpcEnv直接向Driver注册Executor的资源信息,TaskScheduler将保存已经分配给应用的Executor资源的地址、大小等相关信息。然后,SparkContext根据各种转换API,构建RDD之间的血缘关系(lineage)和DAG,RDD构成的DAG将最终提交给DAGScheduler。DAGScheduler给提交的DAG创建Job并根据RDD的依赖性质将DAG划分为不同的Stage。DAGScheduler根据Stage内RDD的Partition数量创建多个Task并批量提交给TaskScheduler。TaskScheduler对批量的Task按照FIFO或FAIR调度算法进行调度,然后给Task分配Executor资源,最后将Task发送给Executor由Executor执行。此外,SparkContext还会在RDD转换开始之前使用BlockManager和BroadcastManager将任务的Hadoop配置进行广播。
    3. 集群管理器(ClusterManager)会根据应用的需求,给应用分配资源,即将具体任务分配到不同Worker节点上的多个Executor来处理任务的运行。Standalone、YARN、Mesos、EC2等都可以作为Spark的集群管理器。
    4. Task在运行的过程中需要对一些数据(例如中间结果、检查点等)进行持久化,Spark支持选择HDFS 、Amazon S3、Alluxio(原名叫Tachyon)等作为存储。

    RDD计算模型

          RDD可以看做是对各种数据计算模型的统一抽象,Spark的计算过程主要是RDD的迭代计算过程,如图2-6所示。RDD的迭代计算过程非常类似于管道。分区数量取决于Partition数量的设定,每个分区的数据只会在一个Task中计算。所有分区可以在多个机器节点的Executor上并行执行。


    图2-6   RDD计算模型

    图2-6只是简单的从分区的角度将RDD的计算看作是管道,如果从RDD的血缘关系、Stage划分的角度来看,由RDD构成的DAG经过DAGScheduler调度后,将变成图2-7所示的样子。


    图2-7   DAGScheduler对由RDD构成的DAG进行调度

    图2-7中共展示了A、B、C、D、E、F、G一共七个RDD。每个RDD中的小方块代表一个分区,将会有一个Task处理此分区的数据。RDD A经过groupByKey转换后得到RDD B。RDD C经过map转换后得到RDD D。RDD D和RDD E经过union转换后得到RDD F。RDD B和RDD F经过join转换后得到RDD G。从图中可以看到map和union生成的RDD与其上游RDD之间的依赖是NarrowDependency,而groupByKey和join生成的RDD与其上游的RDD之间的依赖是ShuffleDependency。由于DAGScheduler按照ShuffleDependency作为Stage的划分的依据,因此A被划入了ShuffleMapStage 1CDEF被划入了ShuffleMapStage 2BG被划入了ResultStage 3

     

    Spark基本架构

        从集群部署的角度来看,Spark集群由以下部分组成:

    • Cluster Manager:Spark的集群管理器,主要负责资源的分配与管理。Cluster ManagerYarn部署模式下为ResourceManager;在Mesos部署模式下为Mesos master;在Standalone部署模式下为MasterResourceManager分配的资源属于一级分配,它将各个Worker上的内存、CPU等资源分配给应用程序,但是并不负责对Executor的资源分配。Standalone部署模式下为Master会直接给应用程序分配内存、CPU以及Executor等资源。目前,Standalone、YARN、Mesos、EC2等都可以作为Spark的集群管理器。
    • WorkerSpark的工作节点。在Yarn部署模式下实际由NodeManager替代。Worker节点主要负责以下工作:创建Executor,将资源和任务进一步分配给Executor,同步资源信息给Cluster Manager。Standalone部署模式下,MasterWorker上的内存、CPU以及Executor等资源分配给应用程序后,将命令Worker启动CoarseGrainedExecutorBackend进程(此进程会创建Executor实例)。
    • Executor:执行计算任务的一线组件。主要负责任务的执行以及与Worker、Driver的信息同步。
    • Driver App:客户端驱动程序,也可以理解为客户端应用程序,用于将任务程序转换为RDD和DAG,并与Cluster Manager进行通信与调度。Driver可以运行在客户端,也可以由客户端提交给Cluster Manager并由ClusterManager安排Worker运行。

    这些组成部分之间的整体关系如图2-8所示。

    2-8   Spark基本架构图

    每项技术的诞生都会由某种社会需求所驱动,Spark正是在实时计算的大量需求下诞生的。Spark借助其优秀的处理能力,可用性高,丰富的数据源支持等特点,在当前大数据领域变得火热,参与的开发者也越来越多。Spark经过几年的迭代发展,如今已经提供了丰富的功能。笔者相信,Spark在未来必将产生更耀眼的火花。

    关于《Spark内核设计的艺术 架构设计与实现

    经过近一年的准备,基于Spark2.1.0版本的《Spark内核设计的艺术 架构设计与实现》一书现已出版发行,图书如图:


    纸质版售卖链接如下:

    展开全文
  • 问题1:navicat的模型设计里面的标签有啥作用啊? 问题2:设计完表模型后如何把模型插入数据库里面啊? 问题3:模型设计能不能直接连数据库也一起自动生成啊? ![图片说明]...
  • 领域模型设计(20190407)

    千次阅读 2019-04-07 15:50:41
    业务模型的设计无定式,领域模型设计也不是适应任何业务,对于复杂业务逻辑可考虑使用。 领域模型实践心得 领域模型与传统业务分层区别 使用Spring框架的项目,业务模型通常是: Bean-Service-Dao 其...

    说明

    业务模型的设计无定式,领域模型设计也不是适应任何业务,对于复杂业务逻辑可考虑使用。

    领域模型实践心得

    领域模型与传统业务分层区别

    使用Spring框架的项目,业务模型通常是:
    Bean-Service-Dao
    其中Bean只有数据(其实什么也没有),Service只有行为,Dao持久化。项目经过长久的发展最终Bean几乎什么也没有,Dao还是持久化,而Service则急剧膨胀,几乎不可维护。Service经常沦为过程式编码。
    领域业务模型:
    Domain-dao
    其中Domain包含数据(Bean)与行为(Service)。一般是真正的面向对象编程。

    应用场景

    当业务模型符合以下特征时,领域模型更合适:

    1. service方法(数据行为)具有清晰的范围,可以归于某一对象的行为。
    2. 调用service方法时传递的参数非常多
    3. 经常多次调用service方法
    4. 业务逻辑复杂

    逐一解释:

    1. 通常在创建领域模型对象的时候,传入能够表征该对象的数据(id),如果不能归于某一对象,那么领域模型就不适合了。
    2. 如果数据同属于一个对象,通过id查询出数据,就不需要传递很多的外部参数。
    3. 这是指对该数据某一次处理时,会有多个数据行为。如果是使用MVC贫血模型,那么就会有多次的参数传递.
    4. 当业务逻辑复杂时,更应当划分清楚领域,否则业务修改起来难度很大。这一条是根本原因。简单业务逻辑不需要领域模型,否则得不偿失。

    实践心得(简要)

    领域模型的代码风格类似于JavaApi类。例如Calendar类。
    只要尝试把数据(bean)同数据行为(service)结合到一起,领域自然就形成了,它迫使你在写代码时优先考虑bean中已有的数据。因为Bean没有数据的只能依赖于外部参数传递,这相当于显式地分割了本领域数据与其他数据。
    领域模型在创建时通常有两步:

    1. init(id)create(id)。创建该领域模型对象,必须传入该领域数据或者数据id
    2. config() 配置项。配置项与id不同之处在于,配置项是可选的。例如操作用户账户的对象,对于该用户是不是黑名单用户,是不是会员等都可以通过设置来进行。因为如果不涉及这些行为,是不必设置的。

    领域模型缺点

    领域模型的缺点:

    1. 领域对象是有状态的.例如Canlendar类,在多线程中使用同一个Canlendar对象将是一场灾难。
    2. 业务逻辑散落在整个领域对象内,初看不易阅读。

    《领域驱动设计》笔记

    不知是翻译还是我水平有限,这本书很难懂。摘几处能看明白又有益处的。

    分层

    • 用户界面(表示层)
    • 应用层:定义软件要完成的任务,指挥领域模型完成任务,但几乎不包含领域细节知识。
    • 领域层:领域模型层
    • 基础设施层:基础服务层,如持久化,发送电子邮件,获取外部资源等。

    领域模型内常用元素

    三种元素:Entity,ValueObject,Service.
    Entity是带有标示的ValueObject,如用户存款100元。100元是Value,这次交易是Entity。
    Service数据操作数据行为。
    通常在业务开发完以后,将valueObject转变为Entity非常困难,然后就是有很多这样的需求。

    领域模型内关联问题

    对于领域模型内部元素之间的“关联”问题,不要使用"多对多"模式,不要使用逆向的一对多(要规定业务模型的“方向”)。例如用户的地址信息,可以设计为专门的地址表,存放的是某一个地址id,多个用户都可以对应到这个地址id上。这就是典型的逆向1对多,因为查询方向是从userid开始到地址id。现在要删除某个用户的信息,地址id就无法删除了。

    领域模型安全问题

    由于模型含有状态,状态的安全就是一个值得注意的问题,也是jdk源码当中经常出现不可变对象/对象副本的原因。如一个领域内含有某用户所有的订单列表,当外部需要返回这个订单列表的时候,需要注意 直接返回这个列表对象的 安全问题,如果存在安全问题,那么应当返回这个列表的一个副本。几乎很少有人会注意到这点。 直接将对象抛给外部是脱离了领域控制的对象,是十分危险的。
    如果要使用共享的ValueObject,就要保证ValueObject是不可变对象。例如String类就是一个不可变对象。

    好例子

    此处以细胞为例,恰到好处地说明了领域驱动设计。再延伸一点,人体就是一个超大型系统,可供参考的系统设计。血管:service,器官:领域,细胞:最底层。
    以手指为例:指纹是entity,手指甲只是valueobject。
    以手机app下单为例:眼睛只负责看,手指只负责操作,大脑负责决策。这三个动作发生在不同的位置,传输的都是神经电信号(?)。这四个领域模型的功能非常强大,智能程度超过了任何计算机。

    代码重用

    这里有一个代码重用的不同观点。代码级别的重用是低级的,模型重用才是更高级的重用。例如持久化代码重用是非常不利于修改的,等于将两个领域不同的模型建立了关联,为了一个业务领域修改该持久化代码时,通常另一个业务模型也需要一定的修改。

    展开全文
  • 数据仓库多维数据模型设计

    万次阅读 2017-11-09 18:14:59
    建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分,那么,怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。 数据仓库建模方法 大千世界,...

    建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分,那么,怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。


    数据仓库建模方法

    大千世界,表面看五彩缤纷,实质上,万物都遵循其自有的法则。

    数据仓库的建模方法同样也有很多种,每一种建模方法其实代表了哲学上的一个观点,代表了一种归纳,概括世界的一种方法。

    目前业界较为流行的数据仓库的建模方法非常多,这里主要介绍范式建模法,维度建模法,实体建模法等几种方法,每种方法其实从本质上讲就是从不同的角度看我们业务中的问题,不管从技术层面还是业务层面,其实代表的是哲学上的一种世界观。

    我们下面给大家详细介绍一下这些建模方法。


    范式建模法(Third Normal Form,3NF)

    范式建模法其实是我们在构建数据模型常用的一个方法,该方法的主要由 Inmon 所提倡,主要解决关系型数据库得数据存储,利用的一种技术层面上的方法。
    目前,我们在关系型数据库中的建模方法,大部分采用的是三范式建模法。
    范式是数据库逻辑模型设计的基本理论,一个关系模型可以从第一范式到第五范式进行无损分解,这个过程也可称为规范化。
    在数据仓库的模型设计中目前一般采用第三范式,它有着严格的数学定义。从其表达的含义来看,一个符合第三范式的关系必须具有以下三个条件 :
    每个属性值唯一,不具有多义性 ;
    每个非主属性必须完全依赖于整个主键,而非主键的一部分 ;
    每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去。
    由于范式是基于整个关系型数据库的理论基础之上发展而来的,因此,本人在这里不多做介绍,有兴趣的读者可以通过阅读相应的材料来获得这方面的知识。
    根据 Inmon 的观点,数据仓库模型得建设方法和业务系统的企业数据模型类似。在业务系统中,企业数据模型决定了数据的来源,而企业数据模型也分为两个层次,即主题域模型和逻辑模型。同样,主题域模型可以看成是业务模型的概念模型,而逻辑模型则是域模型在关系型数据库上的实例。

    从业务数据模型转向数据仓库模型时,同样也需要有数据仓库的域模型,即概念模型,同时也存在域模型的逻辑模型。
    这里,业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于:
    数据仓库的域模型应该包含企业数据模型的域模型之间的关系,以及各主题域定义。
    数据仓库的域模型的概念应该比业务系统的主题域模型范围更加广。
    在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体,实体的属性,实体的子类,以及实体的关系等。
    以笔者的观点来看,Inmon 的范式建模法的最大优点就是从关系型数据库的角度出发,结合了业务系统的数据模型,能够比较方便的实现数据仓库的建模。
    但其缺点也是明显的,由于建模方法限定在关系型数据库之上,在某些时候反而限制了整个数据仓库模型的灵活性,性能等,特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时,需要进行一定的变通才能满足相应的需求。


    维度建模法

    维度建模法,Kimball 最先提出这一概念。其最简单的描述就是,按照事实表,维表来构建数据仓库,数据集市。

    事实表是用来记录具体事件的,包含了每个事件的具体要素,以及具体发生的事情;维表则是对事实表中事件的要素的描述信息。

    比如一个事件会包含时间、地点、人物、事件,事实表记录了整个事件的信息,但对时间、地点和人物等要素只记录了一些关键标记,比如事件的主角叫“Michael”,那么Michael到底“长什么样”,就需要到相应的维表里面去查询“Michael”的具体描述信息了。

    基于事实表和维表就可以构建出多种多维模型,包括星形模型、雪花模型和星座模型。

    维度建模法最被人广泛知晓的名字就是星型模式(Star-schema)。

    [1345621614_4017.JPG]

    上图的这个架构中是典型的星型架构。星型模式之所以广泛被使用,在于针对各个维作了大量的预处理,如按照维进行预先的统计、分类、排序等。
    通过这些预处理,能够极大的提升数据仓库的处理能力。
    特别是针对 3NF 的建模方法,星型模式在性能上占据明显的优势。
    同时,维度建模法的另外一个优点是,维度建模非常直观,紧紧围绕着业务模型,可以直观的反映出业务模型中的业务问题。
    不需要经过特别的抽象处理,即可以完成维度建模。这一点也是维度建模的优势。
    但是,维度建模法的缺点也是非常明显的,由于在构建星型模式之前需要进行大量的数据预处理,因此会导致大量的数据处理工作。
    而且,当业务发生变化,需要重新进行维度的定义时,往往需要重新进行维度数据的预处理。
    而在这些与处理过程中,往往会导致大量的数据冗余。
    另外一个维度建模法的缺点就是,如果只是依靠单纯的维度建模,不能保证数据来源的一致性和准确性,而且在数据仓库的底层,不是特别适用于维度建模的方法。
    因此以笔者的观点看,维度建模的领域主要适用与数据集市层,它的最大的作用其实是为了解决数据仓库建模中的性能问题。
    维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。


    实体建模法

    实体建模法并不是数据仓库建模中常见的一个方法,它来源于哲学的一个流派。
    从哲学的意义上说,客观世界应该是可以细分的,客观世界应该可以分成由一个个实体,以及实体与实体之间的关系组成。
    那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法,将整个业务也可以划分成一个个的实体,而每个实体之间的关系,以及针对这些关系的说明就是我们数据建模需要做的工作。
    虽然实体法粗看起来好像有一些抽象,其实理解起来很容易。
    即我们可以将任何一个业务过程划分成 3 个部分,实体,事件和说明。
    例如我们描述一个简单的事实:“小明开车去学校上学”。以这个业务事实为例,我们可以把“小明”,“学校”看成是一个实体,“上学”描述的是一个业务过程,我们在这里可以抽象为一个具体“事件”,而“开车去”则可以看成是事件“上学”的一个说明。
    从上面的举例我们可以了解,我们使用的抽象归纳方法其实很简单,任何业务可以看成 3 个部分:
    实体,主要指领域模型中特定的概念主体,指发生业务关系的对象。
    事件,主要指概念主体之间完成一次业务流程的过程,特指特定的业务过程。
    说明,主要是针对实体和事件的特殊说明。
    由于实体建模法,能够很轻松的实现业务模型的划分,因此,在业务建模阶段和领域概念建模阶段,实体建模法有着广泛的应用。从笔者的经验来看,再没有现成的行业模型的情况下,我们可以采用实体建模的方法,和客户一起理清整个业务的模型,进行领域概念模型的划分,抽象出具体的业务概念,结合客户的使用特点,完全可以创建出一个符合自己需要的数据仓库模型来。
    但是,实体建模法也有着自己先天的缺陷,由于实体说明法只是一种抽象客观世界的方法,因此,注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此,到了逻辑建模阶段和物理建模阶段,则是范式建模和维度建模发挥长处的阶段。
    因此,笔者建议读者在创建自己的数据仓库模型的时候,可以参考使用上述的三种数据仓库得建模方法,在各个不同阶段采用不同的方法,从而能够保证整个数据仓库建模的质量。


    维度建模法数据模型的区别

    多维数据模型是最流行的数据仓库的数据模型,多维数据模型最典型的数据模式包括星型模式、雪花模式和事实星座模式,本文以实例方式展示三者的模式和区别。


    星型模式(star schema)

    星型模式的核心是一个大的中心表(事实表),一组小的附属表(维表)。星型模式示例如下所示:

    [903014-20160324180338683-1916113766.jpg]

    [200916184066377.jpg]

    可以看出,星形模式的维度建模由一个事实表和一组维表成,且具有以下特点:

    a. 维表只和事实表关联,维表之间没有关联;

    b. 每个维表的主码为单列,且该主码放置在事实表中,作为两边连接的外码;

    c. 以事实表为核心,维表围绕核心呈星形分布;


    雪花模式(snowflake schema)

    雪花模式是星型模式的扩展,其中某些维表被规范化,进一步分解到附加表(维表)中。雪花模式示例如下图所示:

    [903014-20160324180236104-1134926519.jpg]

    [200918380319666.jpg]

    从图中我们可以看到地址表被进一步细分出了城市(city)维。supplier_type表被进一步细分出来supplier维。

    星形模式中的维表相对雪花模式来说要大,而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表,满足了规范化设计。然而这种模式在实际应用中很少见,因为这样做会导致开发难度增大,而数据冗余问题在数据仓库里并不严重。


    事实星座模式(Fact Constellation)或星系模式(galaxy schema)

    数据仓库由多个主题构成,包含多个事实表,而维表是公共的,可以共享,这种模式可以看做星型模式的汇集,因而称作星系模式或者事实星座模式。本模式示例如下图所示:

    [903014-20160324175828948-2089267269.jpg]

    [200924338912918.jpg]

    如上图所示,事实星座模式包含两个事实表:sales和shipping,二者共享维表。

    事实星座模式是数据仓库最常使用的数据模式,尤其是企业级数据仓库(EDW)。

    前面介绍的两种维度建模方法都是多维表对应单事实表,但在很多时候维度空间内的事实表不止一个,而一个维表也可能被多个事实表用到。在业务发展后期,绝大部分维度建模都采用的是星座模式。

    这也是数据仓库区别于数据集市的一个典型的特征,从根本上而言,数据仓库数据模型的模式更多是为了避免冗余和数据复用,套用现成的模式,是设计数据仓库最合理的选择。


    三种模式对比

    归纳一下,星形模式/雪花模式/星座模式的关系如下图所示:

    [903014-20160324103125073-1838397443.jpg]


    实例

    在进行维度建模前,首先要了解用户需求。而笔者在数据库系列的第一篇就讲过,ER建模是当前收集和可视化需求的最佳技术。因此假定和某零售公司进行多次需求PK后,得到以下ER图:
    [903014-20160324160704776-1647702727.png]

    随后可利用建模工具将ER图直接映射到关系图:
    [903014-20160324160724151-2139740081.png]

    需求搜集完毕后,便可进行维度建模了。本例采用星形模型维度建模。但不论采取何种模式,维度建模的关键在于明确下面四个问题:

    1.哪些维度对主题分析有用?

    本例中,根据产品(PRODUCT)、顾客(CUSTOMER)、商店(STORE)、日期(DATE)对销售额进行分析是非常有帮助的;

    2.如何使用现有数据生成维表?

    a. 维度PRODUCT可由关系PRODUCT,关系VENDOR,关系CATEGORY连接得到;

    b. 维度CUSTOMER和关系CUSTOMER相同;

    c. 维度STORE可由关系STROE和关系REGION连接得到;

    d. 维度CALENDAR由关系SALESTRANSACTION中的TDate列分离得到;

    3.用什么指标来”度量”主题?

    本例的主题是销售,而销量和销售额这两个指标最能直观反映销售情况;

    4.如何使用现有数据生成事实表?

    销量和销售额信息可以由关系SALESTRANSACTION和关系SOLDVIA,关系PRODUCT连接得到;

    明确这四个问题后,便能轻松完成维度建模:

    [903014-20160324160936308-1545323262.png]

    细心的读者会发现三个问题:1. 维表不满足规范化设计(不满足3NF);2. 事实表也不满足规范化设计(1NF都不满足); 3. 维度建模中各维度的主码由***ID变成***Key;

    对于前两个问题,由于当前建模环境是数据仓库,而没有更新操作,所以不需要严格做规范化设计来消除冗余避免更新异常。

    因此虽然可以以雪花模型进行维度建模,如下所示:

    [903014-20160324162335339-887948324.png]

    但这样会加大查询人员负担:每次查询都涉及到太多表了。因此在实际应用中,雪花模型仅是一种理论上的模型。星座模型则出现在”维度建模数据仓库”中,本文后面将会讲到。

    对于第三个问题,***Key这样的字段被称为代理码(surrogate key),它是一个通过自动分配整数生成的主码,没有任何其他意义。使用它主要是为了能够处理”缓慢变化的维度”。


    经典星座模型

    前文已经讲过,有多个事实表的维度模型被称为星座模型。星座模型主要有以下两大作用:共享维度和设置细节/聚集事实表。下面分别对这两种情况进行分析:

    1. 共享维度

    以前文提到的零售公司为例,假如该公司质量监管部门希望用分析销售主题同样的方法分析劣质产品,那么此时不需要重新维度建模,只需往模型里加入一个新的劣质产品事实表。之后新的数据仓库维度建模结果如下:

    [903014-20160324163010683-2065536046.png]

    1. 细节/聚集事实表

    细节事实表(detailed fact tables)中每条记录表示单一事实,而聚集事实表(aggregated fact tables)中每条记录则聚合了多条事实。从表的字段上看,细节事实表通常有设置TID属性,而聚集事实表则无。

    两种事实表各有优缺点,细节事实表查询灵活但是响应速度相对慢,而聚集事实表虽然提高了查询速度,但使查询功能受到一定限制。一个常见的做法是使用星座模型同时设置两种事实表(可含多个聚集事实表)。这种设计方法中,聚集事实表使用和细节事实表细节事实表的维度。如下维度建模方法采用星座模型综合了细节事实表和两种聚集事实表:

    [903014-20160324163348964-833179105.png]

    展开全文
  • 浅谈12306核心模型设计思路和架构设计

    万次阅读 多人点赞 2017-11-17 09:36:15
    浅谈12306核心模型设计思路和架构设计 出处:观察者网站+cnblogs 网址:http://m.guancha.cn/Science + http://www.cnblogs.com/netfocus 1月11日起,12306网站开始销售除夕当日火车票。每到此时,铁路...

                                  浅谈12306核心模型设计思路和架构设计


    出处:观察者网站+cnblogs

    网址:http://m.guancha.cn/Science + http://www.cnblogs.com/netfocus


    1月11日起,12306网站开始销售除夕当日火车票。每到此时,铁路系统唯一的官方购票网站12306就会成为众矢之的。知乎网站曾有问答,辨析如果将12306 外包给阿里巴巴、IBM 等大企业做是否可行,网站如下:http://www.zhihu.com/topic/19793213/top-answers;下面摘录了两篇相关文章,讨论了12306的核心设计思路及架构设计。




    第一篇:前淘宝工程师发帖谈12306:曾嗤之以鼻 现在认为几乎是奇迹


    本人淘宝技术专家,2012年在一家百强民企做电商副总,当时在极为艰苦的条件下带队开发了一个B2C(企业针对个人开展的电子商务活动——观察者网注)网站,走支付宝和银联支付通道,年营业额千万级(作者注:当然实在太少了,我只是说这个网站投入了实际的运营)。


    也就在那个时候,我对12306嗤之以鼻,觉得他们做得太烂了,认为自己能带队花几百万半年时间做个好的出来。于是我狂妄地想做一个开源的订票系统给他们。我花了一个星期时间思考建立数据模型,思考到库存这一步的时候,我才发现,12306的库存复杂性比淘宝、京东高很多倍,运算量也大很多倍。传统的分布式数据库、缓存、负载均衡技术并不能恰好满足12306的需求。 


    在平时,12306也就是个正常的电商网站。但一到黄金周,12306就是一个全站所有商品都秒杀,所有SKU都是动态库存的变态。即使不考虑线下既有的电话、代售点等渠道,要实现一个12306,最少最少也是千万级别的硬件投入(作者注:这是当时的估算,没有精算,可能与实际相差较大,总之,我说得不一定对,12306的业务也许没我说的那么复杂,但也绝不是某些人喷的那么简单),软件和人力另算。那些叫嚣只要40台服务器、只要2个架构师4个程序员、大谈分库分表和前端CDN的人们,只是纸上谈兵罢了。所谓初生牛犊不怕虎,做了三年CMS和BBS,就以这个经验来喷12306,未免太天真了。


    媒体人喷12306,是他们不懂技术,没有能力和耐心来分析背后的难度。技术人员喷,则是因为大部分的技术人员在短时间思考时,容易陷入过于乐观的误区,经典的例子就是估算工作量,程序员们往往容易估算出一个超短的工期,把写程序的工作乐观地想象成了打字员照稿敲键盘的工作。


    知乎那篇文章,我觉得不是洗地。排名第一和第二的答案都说得很客观。淘宝技术是比12306强大很多倍,淘宝现在的系统也是花了10倍于12306的钱、时间和人才做起来的。根本原因还是铁路运力不能满足春运需求,淘宝也解决不了这个问题。


    12306这一年来进步非常大。从前段动画验证码、分时段抢票,到后端去小型机、虚拟化、内存数据库的运用。可以说,12306是中国政府机关做的最强大的网站(电商系统),能在短短一两年内做出这样的改变,几乎是个奇迹,就连一些市场化的民企都望尘莫及,甚至一些上市公司都比不上它!(比如51job和ctrip)。


    事非经过不知难,在网上批判12306的人,大部分还是形成了【国企=垄断+腐败+低效】的思维定势。小部分是真的轻视了它的难度。


    至于12306一期工程3个亿(含硬件)贵不贵我不评价,我只提供一个数字供参考,百度一年的研发费用(不含硬件)是10亿,这个数字来自百度财报。网上能查到。3亿看起来好大一个数字,真用到超大型的电商系统、搜索引擎系统里面,其实也不算什么天文数字了。


    再解释一下,为什么秒杀压力大,以及为什么12306的动态库存很复杂。


    先说秒杀。2013年12月25日前后,天猫搞了一个圣诞季积分兑换活动,持续几天。25号上午10点12分,放出了15000个天猫魔盒(淘宝集市有人卖,大概190-230块),从成交记录上看,是19秒内全部抢完。


    实际上,我也参加秒杀了,那天的题目特别简单(请输入xxx汉字的拼音首字母),我应该是5秒内答题完成并提交订单,结果告诉我排队的人太多,挤不进去,并提示14秒以后重试。人太多就是因为题目太简单了,门槛越低,5秒内挤进去的人也越多嘛,如果题目换成【2克浓度为3%的U235在大亚湾核电站能发多少KW的电】,5分钟之内也不会有1万5千人跟我竞争。


    我想,14秒以后哪还有我的事情呀,于是重新答题秒杀,结果出现了服务器错误的页面。反复刷新几次,就告诉秒杀结束了。在群里问了一下同事,有不到10个人回答我,都说没秒到(也可能秒到的人闷声发大财,不回复我)。


    淘宝是什么技术水平呢,淘宝有至少4000技术人员,至少4万台服务器(这都是两年前的公开数据了,按规定可以谈论),2013年11月11日成交额351亿,2012年全年成交额超过1万亿。淘宝拥有各种自主研发团队:服务器、交换机(网上可以搜索到淘宝公开的绿色服务器开放标准);操作系统(LinuxKerneltaobao版,yunos手机操作系统是阿里云的,暂时不计入)、Web服务器(Tengine)、Java语言虚拟机(JVMtaobao版)、数据库(MySQL内核taobao版,google和facebook也有自己的版本,HBase淘宝版、还有自己全部从头 开发的OceanBase)、负载均衡器(LVS,LVS始创人就在淘宝,担任研究员)、Java运行容器(Jboss,其创始人之一,王文彬,也在淘宝,担任副总裁)。淘宝还有数不清的开源项目和中间件,如高性能Java通信中间件HSF、分布式数据库中间件TDDL、异步消息系统notify等等等等。


    以淘宝这样的技术水平,也不能做到秒杀时让每个用户都没有拥挤感,为什么呢?一是要尊重物理原理,一台服务器一秒钟能承受的计算量是有极限的,任你怎么优化,采用多高效的算法和编程语言,都突破不了某个极限,比方说汽车发动机驱动的F1赛车至今也不能突破400公里的时速(超音速推进号那个1千多公里的时速不能算,那是飞机引擎驱动的)。再往深了说,就不容易懂了。感兴趣的可以从著名的C10K问题开始看起。


    二是要考虑经济效益,十一黄金周的时候,北京主城区到八达岭长城的路堵得严严实实,但不能因为黄金周的高峰,就把这段路修成长安街那样10车道的高速公路。否则的话,花费天文数字(真的是天文数字,12306那3个亿大概只够修1-3公里)。修了一段路,黄金周是可以飙到80公里/小时了,可平时呢,拿来给两边的居民晒谷子?


    淘宝目前的硬件和带宽数量,已经超出日常运营的需求了,就是留了相当大的余量给大促销(众所周知的是双十一,双十二,其实基本每个季度都有大促销,每个月都有促销,甚至天天都在促销——聚划算)。amazon当年就是为了应对黑色星期五的大促销购置了大量的服务器,平时订单量没那么大了,amazon就把富余的服务器拿来搞云计算了。顺便说一下,阿里云是当今中国第一世界数一数二的云计算服务商,和amazon走的路也有点像。


    再说动态库存。


    淘宝秒杀天猫魔盒的时候,只有一个商品(行话叫做SKU),它的库存是15000个。有一个人秒杀到了,库存就减1,19秒卖完的,一秒要成功产生789个订单(下订单的请求可能是8万个,只是可能啊,非实际数字,也可能是1万个,用于说明一下壮观程度)。想象一下,你在广场上卖火车票,一秒钟有8万人举着钱对你喊:卖给我!


    上过大学的人都知道,比秒小的时间单位还有毫秒、皮秒、飞秒。但交易系统登记一个交易可不像原子绕着原子核跑一圈那么简单,它要做这些事:检查是否恶意访问、取到系统时间、取到顾客默认收货地址、核对顾客秒杀资格(当时的规定是天猫T2.T3达人)、生成订单号、把顾客ID系统时间订单号收货地址写入订单系统、扣除顾客天猫积分、商品库存减一、给顾客打标记(每人只能秒一个,下次不能秒了)等等,这每一件事都要花费毫秒级别的时间,这些操作加起来的时间可能是接近1秒级别的,但由于淘宝的服务器比较强悍,而且采用了分布式和集群技术,结果比1秒理想一点。但即使有1万台服务器,也不能把这个时间稀释成万分之一秒,因为,商品只有一种,它有15000个库存,对应的数据库记录只有一行,所有的交易请求都要到这里来处理。


    能不能把这15000个拆分成5000个商品并分配到5000台服务器上呢?那样不就可以5000台服务器同时处理了吗?答案是不能,首先,5000个商品,意味着有5000个商品详情页,5000个购买按钮,这对前期的营销、引流是个灾难。基本上就没法做引流入口了,显然这违背了商业管理原则,人为增加了信息混乱程度。其次,天猫魔盒秒杀也不是啥大事,即使按官方标价399元来计算,也就6百万的交易。如果6百万的交易要花费那么大的配套成本,那就太不划算了。再次,淘宝有十几亿商品,这十几亿商品的展示交易和管理,本来就是分布到上万台服务器上去了。没有必要再把每个商品按库存拆成多个商品了。


    这789人抢到了,还不一定会付款(99积分换天猫魔盒还好一点,不需要去网银,成本也极低,大部分是会付款的,3999秒杀iPhone5S就不一定,有人可能网银有问题,有人可能改变主意不想要了),所以就又带来订单取消重新恢复库存的问题。还有想要的消费者们,会认为还有机会,继续在前台刷一会儿,最终这个秒杀会被热情的消费者们猛刷30秒到1分钟。


    一分钟过去了,服务器终于可以喘口气了吧?等等,还有超卖,原来,某两台服务器在同一毫秒都拿到了锁,都去减了库存,15000个库存,被下了15500个订单,又得取消一部分订单。。。如果采用单线程独占锁,是可以做到同时只有一个服务器线程减库存的,但那样就对并发高峰的能力就差了好多了。8万人举着钱,可能只有8个人能下单成功,这个拥挤狂热的抢购就要持续10分钟以上。平时秒个天猫魔盒,10分钟也就10分钟吧,双十一就惨了,收银台一下子减少了90%,还想做到350亿,要么做梦,要么再加10倍服务器和带宽。所以,商业是不完美的,要在绝对正确和绝对的快速之间做个取舍,保证相对快速又极为正确,允许一定的库存错误和超卖(具体允许多少我也不知道)。


    好了,讲了这半天淘宝,可以说12306了吧?我以北京西到深圳北的G71次高铁为例(这里只考虑南下的方向,不考虑深圳北到北京西的,那是另外一个车次,叫G72),它有17个站(北京西是01号站,深圳北是17号站),3种座位(商务、一等、二等)。表面看起来,这不就是3个商品吗?G71商务座、G71一等座、G71二等座。大部分轻易喷12306的技术人员(包括某些中等规模公司的专家、CTO)就是在这里栽第一个跟头的。


    实际上,G71有136*3=408种商品(408个SKU),怎么算来的?请看:

    如果卖北京西始发的,有16种卖法(因为后面有16个站),北京西到:保定、石家庄、郑州、武汉、长沙、广州、虎门、深圳。。。。都是一个独立的商品;同理,石家庄上车的,有15种下车的可能,以此类推,单以上下车的站来计算,有136种票:16+15+14....+2+1=136。每种票都有3种座位,一共是408个商品。


    好了,再看出票时怎么减库存,由于商务、一等、二等三种座位数是独立的,库存操作也是一样的,下文我就不再提座位的差别的,只讨论出发与到达站。另外,下文说的是理论世界的模型,不是说12306的数据库就是这么设计的。


    旅客A买了一张北京西(01号站)到保定东(02号站)的,那【北京西到保定东】这个商品的库存就要减一,同时,北京西到石家庄、郑州、武汉、长沙、广州、虎门、深圳等15个站台的商品库存也要减一,也就是说,出一张北京到保定东的票,实际上要减16个商品的库存!


    这还不是最复杂的,如果旅客B买了一张北京西(01号站)到深圳北(17号站)的票,除了【北京西到深圳北】这个商品的库存要减一,北京西到保定东、石家庄、郑州、武汉、长沙、广州、虎门等15个站台的商品库存也要减1,保定东到石家庄、郑州、武汉、长沙、广州、虎门、深圳北等15个站台的商品库存要减1。。。总计要减库存的商品数是16+15+14+……+1=120个。


    当然,也不是每一张票都的库存都完全这样实时计算,可以根据往年的运营情况,在黄金周这样的高峰时段,预先对票做一些分配,比如北京到武汉的长途多一点,保定到石家庄的短途少一点。我没有证据证实铁道部这样做了,但我相信,在还没有12306网站的时候,铁道部就有这种人工预分配的策略了。


    想象一下,8万人举着钱对你高喊:卖给我。你好不容易在钱堆里找到一只手,拿了他的钱,转身找120个同事,告诉他们减库存,而这 120个同事也和你一样被8万人围着;也和你一样,每卖出一个商品要找几十个人减库存……这就是12306动态库存的变态之处。比你平时买东西的任何网站的库存机制都复杂几十上百倍。 


    再说一下抢票插件,机器永远比人快,当你好不容易从8万人里突出重围,来到了柜台前,你发现,我操,来了10万根绑着钱的竹竿,而且当有退票出来的时候,你要闯过3层人肉才能接近柜台,竹竿在8个人身后一伸,钱就到了柜台前。你低头看了一眼手机,票就没了,竹竿却永远在那里伸着,永不低头,永不眨眼。如果没有这10万根竹竿,虽然你很可能还是抢不到票,但不至于沮丧成这样:我TM为什么总是手最慢的一个?!!


    防机器人抢票,也不是加个图片验证码那么简单。我写过文章系统性分析过,图片验证码有6种机器暴力破解的办法,抢票插件用的是我说的第三种,OCR识别。Google采用的Wave波形字母已经能比较好地防住机器OCR了,ems.com.cn上的验证码就是反面教材,机器OCR成功率接近100%,12306的比ems的图片验证码强一点。不过,验证码设置得复杂一点吧,人们要喷:这只是便宜大学生和办公室白领,农民工连26个字母都认不齐,怎么搞?搞动画验证码吧,也有人喷,视力不好的人怎么办?最后验证码搞得太简单了,皆大欢喜了,其实最高兴的是开发抢票插件的公司。


    就算采用了机器完全不可能识别的验证码,也防不住社会工程学的破解办法。招募一堆网吧打游戏的青少年朋友,每成功输入50个验证码给1块钱,或者等值的虚拟货币、游戏装备,我保证想赚这个钱的人数不胜数。这点钱对转卖车票的利润而言,是可以接受的成本。有没有什么技术可以防住社会工程学的破解办法呢?能防住网吧青少年的验证码只有【2克浓度为3%的U235在大亚湾核电站能发多少KW的电】。


    以上讨论只是把12306当成和淘宝一样没有历史包袱从零起步的交易系统,实际上,它不是,它后面的票池,还有电话售票、火车站售票、代售点售票等多个传统渠道要服务。除了客运服务,12306还有全国最大(很可能也是全球最大)的大宗物资货运系统。


    架空政策(包括定价政策、警方打击黄牛政策、身份验证政策)谈技术,是不可能解决春运抢票困局的,要想让春运的时候每个人在12306抢票都毫无拥挤感(但不一定能抢到票,铁路运力摆在那),那就是逼着12306买一大堆服务器对付春运,春运过去后,成为跟amazon一样牛逼的云计算服务商。和逼北京修一条10车道的高速公路去八达岭长城一个道理。


    目前的12306技术上是还有问题,比如,抢票高峰,输入个身份证号和图片验证码都卡得要死(本人亲测),服务器端繁忙,你浏览器端卡什么呀。


    但人家在进步。相信2014年春运的时候,技术已经不再是一票难求的主要问题。在铁路运力不可能神速增加的情况下,要做到春运更公平地买票,需要停靠政策调整。


    下文针对的是春节国庆这种非常暑期。其它时期,大部分线路保持现状就行了,问题不大,极少部分票源紧张的线路可以按春运处理:


    1、拍卖法,价高者得之

    当硬座票拍出飞机票价格的时候,相信票就不难买了(可惜就是贵了),也没有那么多黄牛了。要说淘宝有什么能帮12306一下子搞定技术问题的,淘宝的拍卖系统可以帮忙,浙江省高院在淘宝拍卖一年多,成交26亿。


    可惜这个方法不可能实行。现在的高铁票价都被媒体和意见领袖喷成啥样了,何况是拍卖。再说,火车票毕竟是生存之刚需,票价20年来不涨本来就有照顾补贴的成分在里面,全拍卖可能也是不妥当。


    2、抽签法,运气好者得之

    开车前2个月开放报名,开车前7天抽签,中途可取消。预存票款,抽不中退款。上传身份证和正脸自拍照,机器核对。这样的话,拦截黄牛的成功率就高很多了,黄牛可以预存票款,可以找到大量真实身份证号,你黄牛再让每个给你身份证号的人把身份证照片和脸部自拍也给你试试?即使有人真想找黄牛,给身份证照片还是会犹豫一下吧。而且中间手工操作多了很多,黄牛成本提高,还不一定搞得到票。反正都是碰运气,我想真正的消费者还是会选择自己先去碰运气吧。


    这个方法实施难度也大,无论怎么设计抽签规则,必然有人大叫“有黑幕,不要相信政府”。

    开车前7天出抽签结果,改变行程的人应该在7天前就能决定改还是不改了。没抽到的也还有时间想别的办法。当然不一定是7天,15天,10天也可以,具体几天要有数据模型来算。


    3、拍卖+抽签

    软卧、高铁商务座等高价位的,拍卖,反正买这个的是经济能力相对较强的。那就拼谁经济能力更强吧。


    4、凭身份证进站,车票跟发票一样,是报销凭证,不是进站凭证;退票后钱进入12306账户,不可提现,只可该乘客下次乘车用;黄金周期间,个人账号最多订购10张票。这个办法可以打击黄牛囤票再转卖;运行一段时间后,按账户余额弄个排行榜就知道谁是黄牛,可惜这个需要车站设备改造配合。


    第二篇:浅谈12306核心模型设计思路和架构设计

    春节期间,无意中看到一篇文章, 文中讲到12306的业务复杂度远远比淘宝天猫这种电商网站要复杂。后来自己想想,也确实如此。所以,很想挑战一下12306这个系统的核心领域模型的设计。一般的电商网站,购买都是基于商品的概念,每个商品有一定量的库存,用户的购买行为是针对商品的。当用户发起购买行为时,系统只需要生成订单并对用户要购买的商品减库存即可。但是,12306就不是那么简单了,具体复杂在哪里,我下面会进一步分析。


    另外一个让我写这篇文章的原因,是我发现也许是否是因为目前12306的核心领域模型设计的不够好,导致用户购票时要处理的业务逻辑异常复杂,维护数据一致性的难度也几百倍的上升,同时面对高并发的订票也难以支持很高的TPS。我觉得,越是复杂的业务,就越要重视业务分析,重视领域模型的抽象和设计。如果不假思索,凭以往经验行事,则很可能会被以往的设计经验先入为主,陷入死胡同。我发现技术人员往往更注重技术层面的解决方案,比如一上来就分析如何集群、如何负载均衡、如何排队、如何分库分表、如何用锁,如何用缓存等技术问题,而忽略了最根本的业务层面的思考,如分析业务、领域建模。我认为越是复杂的业务系统,则越要设计一个健壮的领域模型。如果一个系统的架构我们设计错了,还有补救的余地,因为架构最终沉淀的只是代码,调整架构即可(一个系统的架构本身就是不断演进的);而如果领域模型设计错了,那要补救的代价是非常大的,因为领域模型沉淀的是数据结构及其对应的大量数据,对任何一个大型系统,要改核心领域模型都是成本非常高的。


    本文的重点不是在如何解决高并发的问题,而是希望从业务角度去分析,12306的理想模型应该是怎么样的。网上目前谈12306的文章貌似都是千篇一律的只谈技术,不谈业务分析和如何建模的。所以我想写一下自己的设计和大家交流学习。


    需求概述

    12306这个系统,核心要解决的问题是网上售票。涉及到2个角色使用该系统:用户、铁道部。用户的核心诉求是查询余票、购票;铁道部的核心诉求是售票。购票和售票其实是一个场景,对用户来说是购票,对铁道部来说是售票。因此,我们要设计一个在线的网站系统,解决用户的查询余票、购票,以及铁道部的售票这3个核心诉求。看起来,这3个场景都是围绕火车票展开的。


    查询余票:用户输入出发地、目的地、出发日三个条件,查询可能存在的车次,用户可以看到每个车次经过的站点名称,以及每种座位的余票数量。

    购票:购票分为订票和付款两个阶段,本文重点分析订票的模型设计和实现思路。


    其实还有很多其他的需求,比如给不同的车次设定销售座位数配额,以及不同的区段设置不同的限额。但相比前面两个需求来说,我觉得这个需求相对次要一些。


    需求分析

    确实,12306也是一个电商系统,而且看起来商品就是票了。因为如果把一张票看成是一个商品,那购票就类似于购买商品,然后每张票都有库存,商品也有库存的概念。但是如果我们仔细想想,会发现12306要复杂很多,因为我们无法预先确定好所有的票,如果非要确定,那只能通过穷举法了。


    我们以北京西到深圳北的G71车次高铁为例(这里只考虑南下的方向,不考虑深圳北到北京西的,那是另外一个车次,叫G72),它有17个站(北京西是01号站,深圳北是17号站),3种座位(商务、一等、二等)。表面看起来,这不就是3个商品吗?G71商务座、G71一等座、G71二等座。大部分轻易喷12306的技术人员(包括某些中等规模公司的专家、CTO)就是在这里栽第一个跟头的。实际上,G71有136*3=408种商品(408个 SKU),怎么算来的?如下:


    如果卖北京西始发的,有16种卖法(因为后面有16个站),北京西到:保定、石家庄、郑州、武汉、长沙、广州、虎门、深圳。。。。都是一个独立的商品,同理,石家庄上车的,有15种下车的可能,以此类推,单以上下车的站来计算,有136种票:16+15+14....+2+1=136。每种票都有3种座位,一共是408个商品。


    为了方便后面的讨论,我们先明确一下票是什么?一张票的核心信息包括:出发时间、出发地、目的地、车次、座位号。持有票的人就拥有了一个凭证,该凭证表示持有它的人可以坐某个车次的某个座位号,从某地到某地。所以,一张票,对用户来说是一个凭证,对铁道部来说是一个承诺;那对系统来说是什么呢?不知道。这就是我们要分析业务,领域建模的原因,我们再继续思考吧。


    明白了票的核心信息后,我们再看看G71这个车次的高铁,可以卖多少张票?讨论前先说明一下,一辆火车的物理座位数(站票也可以看成是一种座位,因为站票也有数量配额)不等于可用的最大配合。所有的物理座位不可能都通过12306网站来销售,而是只会销售一部分,比如40%。其余的还是会通过线下的方式销售。不仅如此,可能有些站点上车的人会比较多,有些比较少,所以我们还会给不同的区间配置不同的限额。比如D31北京南至上海共有765张,北京南有260张,杨柳青有80张,泰安有76张。如果杨柳青的80张票售完就会显示无票,就算其他站有票也会显示无票的。每个车次肯定会有各种座位的配额和限额的配置的,这种配置我目前无法预料,但我已经把这些规则都封装近车次聚合根里了,所有的配置策略都是基于座位类型、站点、区间配置的。关于票的配置抽象出来,我觉得主要有3种:1)某个区段最多允许出多少张;2)某个区段最少允许出多少张;3)某个站点上车的最多多少张;当用户订票时,把用户指定的区段和这3种配置条件进行比较,3个条件都满足,则可以出票。不满足,则认为无票了。下面举个例子:


    ABCDEFG,这是所有站点。座位总配额是100,假设B站点上车,E站下车的人比较少,那我们就可以设定BE这个区段最多只能出10张票。所以,只要是用户的订票是在这个区段内的,就最多出10张。再比如,一列车次,总共100个座位配额,希望全程票最少满足80张,那我们只要给AG这个区段设定最少80张。那任何订票请求,如果是子区间的,就不能超过100-80,即20张。这两种条件必须同时满足,才允许出票。


    但是,不管如何做配额和限额,我们总是针对某个车次进行配置,这些配置只是车次内部售票时的一些额外的判断条件(业务规则),不影响车次模型的核心地位和对外暴露的功能。所以,为了本文讨论的清楚起见,我后续的讨论都不涉及配额和限额的问题,而是认为任何区段都可以享受火车最大的物理座位数。


    并且,为了讨论问题方便,我们减少一些站点来讨论。假设某个车次有A,B,C,D四个站点。那001这个人购买了A,B这个区间,系统会分配给 001一个座位x;但是因为001坐到B站点后会下车,所以相当于x这个座位又空出来了,也就是说,从B站点开始,系统又可以认为x这个座位是可用的。所以,我们得出结论:同一个座位,其实可以同时出售AB,BC这两张票。通过这个简单的分析,我们知道,一列火车虽然只有有限的座位数,比如1000个座位。但可以卖出的票远远不止1000个。还是以A,B,C,D四个站点为例,假如火车总共有1000个座位,那AB可以卖1000张,BC也可以卖1000张,同样,CD也可以卖1000张。也就是说,理论上最多可以卖出3000张票。但是如果换一种卖法,所有人都是买ABCD的票,也就是说所有的票都是经过所有站点的,那就是最多只能卖出1000张票了。而实际的场景,一定是介于1000到3000之间。然后实际的G71这个车次,有17个站,那到底可以卖出多少个票,大家应该可以算了吧。理论上这17个站中的任意两个站点之间所形成的线段,都可以出售为一张票。我数学不好,算不太清楚,麻烦有数学好的人帮我算算,呵呵。


    通过上面的分析,我们知道一张票的本质是某个车次的某一段区间(一条线段),这个区间包含了若干个站点。然后我们还发现,只要区间不重叠,那座位就不会发生竞争,可以被回收利用,也就是说,可以同时预先出售。


    另外,经过更深入的分析,我们还发现区间有4种关系:1)不重叠;2)部分重叠;3)完全重叠;4)覆盖;不重叠的情况我们已经讨论过了,而覆盖也是重叠的一种。所以我们发现如果重叠,比如有两个区间发生重叠,那重叠部分的区间(可能夸一个或多个站点)是在争抢座位的。因为假设一列火车有100个座位,那每个原子区间(两个相邻站点的连线),最多允许重叠99次。


    所以,经过上面的分析,我们知道了一个车次能够出售一张车票的核心业务规则是什么?就是:这张车票所包含的每个原子区间的重叠次数加1都不能超过车次的总座位数,实际上重叠次数+1也可以理解为线段的厚度。


    模型设计

    上面我分析了一下票的本质是什么。那接下来我们再来看看怎么设计模型,来快速实现购票的需求,重点是怎么设计商品聚合以及减库存的逻辑。


    传统电商的思路

    如果按照普通电商的思路,把票(站点区间)设计为商品(聚合根),然后为票设计库存数量。我个人觉得是很糟糕的。因为一方面这种聚合根非常多(上面的G71就有408个);另一方面,即便枚举出来了,一次购票也一定会影响非常多其他聚合根的库存数量(只要被部分或全部重叠的区间都受影响)。这样的一次订单处理的复杂度是难以评估的。而且这么多聚合根的更新要在一个事务里,这不是为难数据库吗?而且,这种设计必然带来大量的事务的并发冲突,很可能导致数据库死锁。总之,我认为这种是典型的由于领域模型的设计错误,导致并发冲突高、数据持久化落地困难。或者如果要解决并发问题,只能排队单线程处理,但是仍然解决不了要在一个事务里修改大量聚合根的尴尬局面。听说12306是采用了Pivotal Gemfire这种高大上的内存数据库,我对这个不太了解。我不可想象要是不使用内存数据库,他们要怎么实现车次内的票之间的数据强一致性(就是保证所有出售的票都是符合上面讨论的业务规则的)?


    所以,这种设计,我个人认为是思维定势了,把火车票看成是普通电商的商品来看待。所以,我们有时做设计又要依赖于经验,又要不能被以往经验所束缚,真的不容易,关键还是要根据具体的业务场景多多深入分析,尽量分析抽象出问题的本质出来,这样才能对症下药。那是否有其他的设计思路呢?


    我的思路


    聚合设计

    通过上面的分析我们知道,其实任何一次购票都是针对某个车次的,我认为车次是负责处理订票的聚合根。我们看看一个车次包含了哪些信息?一个车次包括了:1)车次名称,如G71;2)座位数,实际座位数会分类型,比如商务座20个,一等座200个;二等座500个;我们这里为了简化问题,可以暂时忽略类型,我认为这个类型不影响核心的模型的设计决策。需要格外注意的是:这里的座位数不要理解为真实的物理座位数,很有可能比真实的座位数要少。因为我们不可能把一个车次的所有座位都在网上通过12306来出售,而是只出售一部分,具体出售多少,要由工作人员人工指定。3)经过的站点信息(包括站点的ID、站点名称等),注意:车次还会记录这些站点之间的顺序关系;4)出发时间;看过GRASP九大模式中的信息专家模式的同学应该知道,将职责分配给拥有执行该职责所需信息的类。我们这个场景,车次具有一次出票的所有信息,所以我们应该把出票的职责交给车次。另外学过DDD的同学应该知道,聚合设计有一个原则,就是:聚合内强一致性,聚合之间最终一致性。


    经过上面的分析,我们知道要产生一张票,其实要影响很多和这个票对应的线段相交的其他票的可用数量。因为所有的站点信息都在车次聚合内部,所以车次聚合内部自然可以维护所有的原子区间,以及每个原子区间的可用票数(相当于是库存数)。当一个原子区间的可用票数为0的时候,意味着火车针对这个区间的票已经卖完了。所以,我们完全可以让车次这个聚合根来保证出票时对所有原子区间的可用票数的更新的强一致性。对于车次聚合根来说,这很简单,因为只是几次简单的内存操作而已,耗时可以忽略。一列火车假如有ABCD四个站点,那原子区间就是3个。对于G71,则是16个。


    怎么判断是否能出票

    基于上面的聚合设计,出票时扣减库存的逻辑是:根据订单信息,拿到出发地和目的地,然后获取这段区间里的所有的原子区间。然后尝试将每个原子区间的可用票数减1,如果所有的原子区间都够减,则购票成功;否则购票失败,提示用户该票已经卖完了。是不是很简单呢?知道了出票的逻辑,那退票的逻辑也就很简单了,就是把这个票的所有原子区间的可用票数加1就OK了。如果我们从线段的厚度的角度去考虑,那出票时,每个原子区间的厚度就是+1,退票时就是减一。就是相反的操作,但本质是一样的。


    所以,通过这样的思路,我们将一次订票的处理控制在了一个聚合根里,用聚合根内的强一致性的特性保证了订票处理的强一致性,同时也保证了性能,免去了并发冲突的可能性。传统电商那种把票单做类似商品的核心聚合根的设计,我当时第一眼看到就觉得不妥。因为这违背了DDD强调的强一致性应该由聚合根来保证、聚合根之间的最终一致性通过Saga来保证的原则。


    还有一个很重要的概念我想说一下我的看法,就是座位和区间的关系。因为有些朋友和我讲,考虑座位号的问题,虽然都能减1,座位号也必须是同一个。我觉得座位是全局共享的,和区段无关(也许我的理解完全有误,请大家指正)。座位是一个物理概念,一个用户成功购买了一张票后,座位就会少一个,一张票唯一对应一个座位,但是一个座位有可能会对应多张票;而区间是一个逻辑上的概念,区间的作用有两个:1)表示票的出发地和目的地;2)记录票的可用数额。如果区间能连通(即该区间内的每个原子区间的可用数额都大于0),则表示允许拥有一个座位。所以,我觉得座位和票(区间)是两个维度的概念。


    如何为票分配座位

    我觉得车次聚合根内部应该维护所有该车次已经售出的票,已经出售的票的的本质是区间和座位的对应关系。系统处理订票时,用户提交过来的是一段区间。所以,系统应该做两个事情:

    1. 先根据区间去判断是否有可用的座位;

    2. 如果有可用座位,则再通过算法去选择一个可用的座位;

    当得到一个可用座位后,就可以生成一张票了,然后保存这个票到车次聚合根内部即可。


    下面举个例子:

    假设现在的情况是座位有3个,站点有4个
    座位:1,2,3
    站点:abcd


    票的卖法1:
    票1:ab,1
    票2:bc,2
    票3:cd,3
    票4:ac,3
    票5:bd,1
    这种选座位的方式应该比较高效,因为总是优先从座位池里去拿座位,只有在万不得已的时候才会去回收可重复利用的票。上面的4,5两个票,就是考虑回收利用的结果。


    票的卖法2:
    票1:ab,1
    票2:bc,1
    票3:cd,1
    票4:ac,2
    票5:bd,3
    这种选座位的方式应该相对低效,因为总是优先会去扫描是否有可回收的座位,而扫描相对直接从座位池里去拿票总是成本相对要高的。上面的2,3两个票,就是考虑回收利用的结果。


    但是,优先从座位池里拿票的算法有缺陷,就是会出现虽然第一步判断认为有可用的座位,但是这个座位可能不是全程都是同一个座位。举例:
    假设现在的情况是座位有3个,站点有4个
    座位:1,2,3
    站点:abcd

    票的卖法3:
    票1:ab,1
    票2:bc,2
    票3:cd,3

    现在如果有人要买ad的票,那可用的座位有2,或者3。但是无论是2还是3,都要这个乘客中途换车位。比如卖给他座位2,那他ab是坐的座位2,但是bc的时候要坐座位1的。否则拿票2的那个人上车时,发现座位2已经有人了。而通过优先回收利用的算法,是没这个问题的。


    所以,从上面的分析我们也知道选座位的算法该怎么写了,就是采用优先回收利用座位的算法。我认为不管我们这里怎么设计算法,都不影响大局,因为这一切都只发生在车次聚合根内部,这就是预先设计好聚合根,明确出票职责在哪个对象上的好处。


    模型分析总结

    1. 我认为票不是核心聚合根,票只是一次出票的结果,一个凭证而已。

    2. 12306真正的核心聚合根应该是车次,车次具有出票的职责,一次出票具体做的事情有:

      • 判断是否可出票;

      • 选择可用的座位;

      • 更新一次出票时所有原子区间的可用票数,用于判断下次是否能出票;

      • 维护所有已售出的票,用于为选择可用座位提供依据;


    通过这样的模型设计,我们可以确保一次出票处理只会在一个车次聚合根内进行。这样的好处是:

    1. 不需要依赖数据库事务就能实现数据修改的强一致性,因为所有修改只在一个聚合根内发生;

    2. 在保证数据强一致性的同时还能提供很高的并发处理能力,具体设计见下面的架构设计;


    架构设计(非本文重点,没兴趣的朋友可以略过)

    我觉得12306这样的业务场景,非常适合使用CQRS架构;因为首先它是一个查多写少、但是写的业务逻辑非常复杂的系统。所以,非常适合做架构层面的读写分离,即采用CQRS架构。而且应该使用数据存储也分离的CQRS。这样CQ两端才可以完全不需要顾及对方的问题,各自优化自己的问题即可。我们可以在C端使用DDD领域模型的思路,用良好设计的领域模型实现复杂的业务规则和业务逻辑。而Q端则使用分布式缓存方案,实现可伸缩的查询能力。


    订票的实现思路

    同时借助像ENode这样的框架,我们可以实现in-memory + Event Sourcing的架构。Event Sourcing技术,可以让领域模型的所有状态修改的持久化统一起来,本来要用ORM的方式保存聚合根最新状态的,现在只需要简单的通用的方式保存一个事件即可(一次订票只涉及一个车次聚合根的修改,修改只产生一个事件,只需要持久化一个事件(一个JSON串)即可,保证了高性能,无须依赖事务,而且通过ENode可以解决并发问题)。我们只要保存了聚合根每次变化的事件(事件的结构怎么设计,本文不做多的介绍了,大家可以思考下),就相当于保存了聚合根的最新状态。而正是由于Event Sourcing技术的引入,让我们的模型可以一直存活在内存中,即可以使用in-memory技术。不要小看in-memory技术,in-memory技术在某些方面对提高命令的处理性能非常有帮助。比如就以我们车次聚合根处理出票的逻辑,假设某个车次有大量的命令发送到分布式消息队列,然后有一台机器订阅了这个队列的消息,然后这台机器处理这个车次的订票命令时,由于这个车次聚合根一直在内存,所以就省去了每次要去数据库取出聚合根的步骤,相当于少了一次数据库IO。这样的好处是,因为一个车次能够真正出售的票是有限的,因为座位就那么几个,比如就1000个座位,估计一般正常情况也就出个2000个左右的票吧(具体能出多少张票要取决于区间的相交程度,上面分析过)。也就是说,这个聚合根只会产生2000个事件,也就是说只会有2000个订票命令的处理是会产生事件,并持久化事件;而其余的大量命令,因为车次在内存计算后发现没有余票了,就不会做任何修改,也不会产生领域事件,这样就可以直接处理下一个订票命令了。这样就可以大大提高处理订票命令的性能。


    另外一个问题我觉得还需要提一下,因为用户订票成功后,还需要付款。但用户有可能不去付款或者没有在规定的时间内完成付款。那这种情况下,系统会自动释放该用户之前订购的票。所以基于这样的需求,我们在业务上需要支持业务级别的2pc。即先预扣库存,也就是先占住这张票一定时间(比如15分钟),然后付款成功后再真实给你这张票,系统做真正的库存修改。通过这样的预扣处理,可以保证不会出现超卖的情况。这个思路其实和传统电商比如淘宝这样的系统类似,我就不多展开了,我之前写的Conference案例也是这样的思路,大家有兴趣的可以去看一下我之前录制的视频。


    查询余票的实现思路

    我觉得余票的查询的实现相对简单。虽然对于12306来说,查询的请求占了80%,提交订单的请求只占20%。但查询由于对数据没有修改,所以我们完全可以使用分布式缓存来实现。我们只需要精心设计好缓存的key即可;缓存key的多少要看成本,如果所有可能的查询都设计对应的key,那时间复杂度为1,查询性能自然高;但代价也大,因为key多了。如果想key少一点,那查询的复杂度自然要上去一点。所以缓存设计无非就是空间换时间的思路。然后,缓存的更新无非就是:自动失效、定时更新、主动通知3种。通过CQRS架构,由于CQ两端是事件驱动的,当C端有任何状态变化,都会产生对应的事件去通知Q端,所以我们几乎可以做到Q端的准实时更新。


    同时由于CQ两端的完全解耦,Q端我们可以设计多种存储,如数据库和缓存(Redis等);数据库用于线下维护关系型数据,缓存用户实时查询。数据库和缓存的更新速度相互不受影响,因为是并行的。对同一个事件,可以10台机器负责更新缓存,100台机器负责更新数据库。即便数据库的更新很慢,也不会影响缓存的更新进度。这就是CQRS架构的好处,CQ的架构完全不同,且我们随时可以重建一种新的Q端存储。不知道大家体会到了没有?


    关于缓存key的设计,我觉得主要从查询余票时传递的信息来考虑。12306的关键查询是:出发地、目的地、出发日期三个信息。我觉得有两种key的设计思路:1)直接设计了该查询条件的key,然后快速拿到车次信息,直接返回;这种方式就是要求我们系统已经枚举了所有车次的所有可能出现的票(区间)的缓存key,相信你一定知道这样的key是非常多的。2)不是枚举所有区间,而是把每个车次的每个原子区间(相邻的两个站点所连成的直线)的可用票 数作为key。这样,key就非常少了,因为车次假如有10000个,然后每个车次平均15个区间,那也就15W个key而已。当我们要查询时,只需要把用户输入的出发地和目的地之间的所有原子区间的可用票数都查出来,然后比较出最小可用票数的那个原子区间。则这个原子区间的可用票数就是用户输入的区间的可用票数了。当然,到这里我提到考虑出发日期。我认为出发日期是用来决定具体是哪个车次聚合根的。同一个车次,不同的日期,对应的聚合根实例是不同的,即便是同一天,也可能有多个车次聚合根,因为有些车次一天有几班的,比如上午9点发车的一班,下午3点发车的一般。所以,我们也只要把日期也作为缓存key的一部分即可。


    版权申明:内容来源网络,版权归原创者所有。除非无法确认,我们都会标明作者及出处,如有侵权烦请告知,我们会立即删除并表示歉意。谢谢。


    -END-


    展开全文
  • 本文是Cassandra数据模型设计第一篇(全两篇),该系列文章包含了eBay使用Cassandra数据模型设计的一些实践。其中一些最佳实践我们是通过社区学到的,有些对我们来说也是新知识,还有一些仍然具有争议性,可能在要...
  • 详细设计说明

    万次阅读 多人点赞 2019-06-22 23:08:06
    本详细设计说明书是针对电子科大校园地图(UESTC Campus Map)小程序的项目编写。目的是对该项目进行详细设计,在概要设计的基础上进一步明确系统结构,详细地介绍系统的各个模块,为进行后面的实现和测试做准备。...
  • 采用漏斗模型的概念去统计用户行为,规划设计产品的热度和可行性。
  • 五种IO模型设计模式

    千次阅读 2019-06-10 16:30:01
    在《Unix网络编程》一书中提到了五种IO模型,分别是:阻塞IO、非阻塞IO、多路复用IO、信号驱动IO以及异步IO。 下面就分别来介绍一下这5种IO模型的异同。 1.阻塞IO模型  最传统的一种IO模型,即在读写数据过程中...
  • 目录0引言1、课本介绍1.1理论的书1.2 R语言的书2、构造数据3、相关性分析4、多元回归模型的建立4.1建立模型5.2模型分析5.3方差分析表5、变量选择5.1 逐步回归5.2所有子集法5.3套索法6、回归模型常用函数总结7、参考...
  • 这个模型结合MC9S12XS128中的周期中断定时器PIT、脉冲宽度调制器PWM、A-D转换器、串行通信接口SCI等基本模块,精确控制步进电机正转、反转来完成开窗、关窗动作。以此来巩固所学的知识,并应用于日常生活中。 当然这...
  • 全面理解Java内存模型

    万次阅读 多人点赞 2016-09-21 18:39:21
    Java内存模型即Java Memory Model,简称JMM。JMM定义了Java 虚拟机(JVM)在计算机内存(RAM)中的工作方式。JVM是整个计算机虚拟模型,所以JMM是隶属于JVM的。如果我们要想深入了解Java并发编程,就要先理解好Java内存...
  • 网页前端的Tribon三维模型展示技术分析 By Eattonton 前端技术也就是网页程序的开发技术统称,通过前端的插件可以开发报表,图纸,三维模型等种种功能。并且这些功能可以利用网页的跨平台和实时性的技术优势,从而让...
  • 隐马尔科夫模型matlab工具箱说明

    千次阅读 2016-12-05 12:07:24
    隐马尔可夫模型(HiddenMarkov Model,HMM)是统计模型,它用来描述一个含有隐含未知参数的马尔可夫过程;是序列数据处理和统计学习的重要模型。其难点是从可观察的参数中确定该过程的隐含参数,然后利用这些参数来...
  • 基于RBAC模型的权限管理系统的设计和实现裴辉东 梁云风 (1. 山东省烟台海颐软件股份有限公司;2山东省烟台东方电子信息产业股份有限公司) 摘要:提出了基于RBAC模型的权限管理系统的设计和实现方案。介绍了采用的...
  • 领域驱动设计之领域模型

    千次阅读 2015-09-18 14:20:46
    加一个导航,关于如何设计聚合的详细思考,见这篇文章。 2004年Eric Evans 发表Domain-Driven Design –Tackling Complexity in the Heart of Software (领域驱动设计),简称Evans DDD。领域驱动设计分为两个...
  • 架构设计之如何写架构设计说明

    千次阅读 2015-06-04 13:55:09
    在架构师整个的成长过程中,必定会经历编制架构设计说明书、评审架构设计说明书以及根据业务需求分析设计系统架构的三个过程。作为一个架构师,我想尝试一下根据这三个过程对不同能力需要,写一次系列文章,包括...
  • 前言 在电商系统中,商品模型至关重要,是整个电商的核心,下面通过一个简单的分析,设计一个基础的商品模型。商品模型的演化 在以前,那时CMS很流行,最常见的模型是栏目-文章模型。于是做电商的时候,自然就继承...
  • V模型:需求分析-概要设计-详细设计-编码-单元测试-集成测试-系统测试-验收测试 V模型的优缺点 优点 1. 包含了底层测试(单元测试)和高层测试(系统测试);2. 清楚地标识了开发和测试的各个阶段;3. 每个阶段...
  • 数据库设计说明书的编写

    万次阅读 2019-06-17 19:46:34
    G.1 引言 G.1.1 编写目的 数据库的表结构设计是整个项目开发中一个非常重要的环节,一个良好的数据库设计,可以提高开发效率,方便系统维护,并且为...我们也希望通过写数据设计说明书,规范数据名称、数据范围...
  • 架构设计 例子和实践 系统设计说明书(架构、概要、详细)目录结构演进架构中的领域驱动设计Web架构设计经验分享软件架构设计从MVC框架看MVC架构的设计领域驱动设计(Domain Driven Design)参考架构详解关于垂直切分...
  • 全面理解Java内存模型(JMM)及volatile关键字

    万次阅读 多人点赞 2017-06-12 11:25:05
    这里之所以简要说明这部分内容,注意是为了区别Java内存模型与Java内存区域的划分,毕竟这两种划分是属于不同层次的概念。 Java内存模型概述 Java内存模型(即Java Memory Model,简称JMM)本身是一种抽象的...
  • 一、瀑布模型 1.1什么是瀑布模型 1.2特点 1.3优缺点 1.4客户需求 二、快速原型模型 2.1什么是快速原型模型 2.2优缺点 2.3快速原型模型的思想产生、原理及运用方式 2.4类型 2.5开发步骤 三、增量模型 3.1...
  • 概要设计说明

    千次阅读 2016-04-22 15:20:17
    一、概要设计的目的  将软件系统需求转换为未来系统的设计;  逐步开发强壮的系统构架;  使设计适合于实施环境,为提高性能而进行设计;  结构应该被分解为模块和库。 二、概要设计的任务  制定规范: ...
  • Android GUI编程模型(MVC设计模式)

    千次阅读 2011-12-08 15:36:17
    )的设计模式,见下图所示:   MVC 模式下,系统框架的类库被划分为 3 种:模型( Model )、视图( View )、控制器( Controller )。模型对象负责建立数据结构和相应的行为操作处理。视图( ...
  •  多维数据模型是最流行的数据仓库的数据模型,多维数据模型最典型的数据模式包括星型模式、雪花模式和事实星座模式,本文以实例方式展示三者的模式和区别。 二、星型模式(star schema)  星型模式的核心是...
  • 软件设计说明书模版(申请软件著作权可供参考)

    万次阅读 多人点赞 2019-06-20 14:59:22
    1.引言 1.1 编写目的 1.2 项目背景 ...3.2.1 软件概要设计说明 3.2.3 基本设计概念和处理流程 3.3 软件的详细设计 3.3.1 系统结构 3.3.2 模块设计说明 3.3.3 爬虫模块 3.3.4 日志模块 3.3.5 数...
  •  多维数据模型是最流行的数据仓库的数据模型,多维数据模型最典型的数据模式包括星型模式、雪花模式和事实星座模式,本文以实例方式展示三者的模式和区别。 二、星型模式(star schema)  星型模式的核心是一个...
  • 业务模型;UML类图

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 100,625
精华内容 40,250
关键字:

展示模型设计说明