帮呗 大数据平台设计 吐血粘贴版



  • 0_1508476930048_ffc63549-895f-4f78-af46-b0a87efb1cfe-image.png 修订记录:
    版本
    时间
    修改人
    修改内容说明
    0.1
    2017.9.7

    初始版本
    0.2
    2017.9.9

    标明哪些是本期做
    0.3
    2017.10.7

    增加2.3总体物理架构图及说明

    目 录

    1. 序言 4
      1.1 概述 4
      1.2 名词解释 4
      1.3 参考文档 5

    2. 整体框架 6
      2.1 整体框架总体原则及策略 6
      2.2 总体技术架构 6
      2.3 总体物理架构 8
      2.4 总体功能架构 10
      2.5 系统扩展性考虑 11

    3. 数据存储架构设计 13
      3.1 总体数据存储 13
      3.2 共享层 14
      3.2.1 Hadoop数据仓库 14
      3.3 集市层 14
      3.3.1 MySQL数据 14
      3.3.2 Aerospike数据 15

    4. 服务 16
      4.1 总体原则及策略 16
      4.2 概要 16
      4.3 安全及并发 16

    5. ETL 17
      5.1 ETL原则及策略 17
      5.2 ETL逻辑架构 17
      5.3 调度 18
      5.4 实时计算 18
      5.5 高频ETL 18
      5.6 低频ETL 19
      5.7 接口 19
      5.7.1 接口总体策略及原则 19
      5.7.2 采集接口数据 19
      5.8 数据同步 19
      5.8.1 数据同步原则及策略 19
      5.8.2 MySQL至hadoops 20
      5.8.3 MySQL至Elasticsearch 20
      5.8.4 Hadoops至MySQL 20

    6. 模型设计 21
      6.1 模型总体策略及原则 21
      6.2 模型分类 21
      6.3 模型分类明细 22
      6.3.1 STG 22
      6.3.2 INTE 22
      6.3.3 AGG 22
      6.3.4 DM 22
      6.3.5 SHO 23
      6.3.6 TMP 23
      6.3.7 DIM 23
      6.3.8 PARA 23
      6.4 维护 24
      6.4.1 原则 24
      6.4.2 方法 24

    7. 元数据管理 25
      7.1 元数据概述 25
      7.2 元数据管理策略 25
      7.2.1 元数据导入 25
      7.2.2 元数据存储 26
      7.3 元数据使用 26

    8. 备份和恢复 28
      8.1 备份对象 28
      8.2 备份策略 28
      8.2.1 数据库备份策略 28
      8.2.2 文件备份策略 29
      8.3 恢复策略 29

    9. 序言
      1.1 概述
      该文档主要描述大数据平台-代码大洋的总体设计和模块划分,并作为后期系统升级、开发和维护的主要参照标准。
      1.2 名词解释
      ν Hadoops:hadoop各个组件的统称
      ν OLTP:联机事务处理(On-Line Transaction Processing)
      ν OLAP:联机分析处理(On-Line Analytical Processing)
      ν ETL:数据抽取转换加载(Extract/Transform/Load)
      ν DW:数据仓库(Data Warehouse)
      ν SP:存储过程(Stored Procedure)
      ν FTP:文件传输协议(File Transfer Protocol)
      ν 粒度(Granularity):存储在数据平台中的事实信息的详细程度。
      ν 前端展现(Front-end Presentation):提供数据平台用户浏览和操作数据平台中数据的功能。它处于数据平台体系结构的终端,直接与最终用户交互。
      ν 事实表(Fact table):星型结构中,包含了数据库中存储事实信息的表。
      ν 数据迁移(Data Migration) :数据从一个环境到另一个环境的移动。
      ν 数据清洗( Data Cleansing):在导入数据平台的过程中,去除错误和矛盾数据的过程。
      ν 机器学习(Data Mining):在数据中寻找隐藏的模式和关系的过程。
      ν 数据映射(Data Mapping):将源数据元素映射到目标数据元素的过程。
      ν 维表(Dimension Table):星型结构中,包含Cube的一个维度数据的表。
      ν 星型结构(Star Schema):关系数据库的一种设计方式,它包含一个事实表和多个关联维表。
      ν 元数据(Metadata):描述数据的数据。
      1.3 参考文档
      ν sea数据库模型.pdm

    10. 整体框架
      2.1 整体框架总体原则及策略
      系统框架总体按功能进行模块化划分与搭建,要做到各模块(系统)之间的解耦(建议微服务形式)。
      2.2 总体技术架构
      大数据平台的总体架构示意图如下。

    注:标绿色的为本期要做的。
    整个系统采用分层架构,一共分为4层,从底到顶分别是:
    1、采集层:完成原始数据的采集和数据的结构化工作。为了使得实时、非实时方式都可以用统一的接口方式,故引入Kafka作为消息系统,提供数据交换的平台。存入Kafka的数据都序列化成protobuf,取数时再反序列化。
    2、共享层:共享层的主要工作是存储并分析采集层提供的数据。由于存储的数据量大,共享层在存储和数据分析上都需要经历真正大数据的考验。共享层保存来自采集层的数据,并吐出经过分析加工后的数据。一般来说,共享层向外提供的是统计类数据,即按照一定的维度和周期,汇总出采集层提供的结构化记录数据的结果,为某一类的应用提供基本的统计信息服务。
    共享层分两种集群,一种是批处理,一种是实时处理集群。批处理数据主要来源Kafka,直接将数据gzip压缩,放到HDFS相应目录下,供后面的ETL使用。而对于实时处理的数据来源,从Kafka中取到数据后,发送给Spark Streaming实时计算。
    共享层数据都放在Hadoop中,包括原始数据,数据仓库集成层数据,汇总层数据,数据集市层数据。批处理计算主要用Hive为主,以SQL方式为主。实时处理用流处理方式,用Apache Spark streaming来实现。
    3、集市层:共享层中抽取数据,形成一个更小的数据集合,即数据集市。这是因为集市层总是为特定的应用服务的。集市层和共享层的关系来看,共享层是粗加工数据的全集,而集市层则是某一类别数据的精加工集合。集市层的服务类别可以横向扩展,支撑所服务的应用领域。
    集市层数据大部分放在MySQL中,部分放在Aerospike中,其他放在hadoop中。无论是hadoop、Aerospike,还是MySQL数据库,都可以按照需求划分为多个库或者集群。此层的计算以SQL为主,BI工具、ETL工具通过JDBC、ODBC方式进行数据处理。集市层数据都来源于共享层,与共享层用不同的hadoop节点,通过多个DataNode同时进行文件copy;集市层在MySQL数据库中的,通过hadoop的多个datanode与MySQL数据库的多个节点同时进行文件load。对于性能要求极高的数据访问,需要由Aerospike集群进行支撑,在入Aerospike之前需要对数据加工好。
    4、服务层:服务层主要为数据的使用者(应用层程序)提供访问数据的通道,数据可以来自集市层,也可以来自共享层。接口层提供了数据使用者的封装,以隔离对数据存储形式的直接依赖。
    通过服务层与外部程序进行数据交换。当QPS高时,通过阿里云负载均衡,每个请求路由到不同的应用程序服务器,应用程序对请求进行处理,然后查询Aerospike、hadoop、MySQL数据库,再返回给请求方。应用程序由多个服务组成,服务内部由RPC进行调用。应用程序主要由Go语言实现,以protobuf对数据进行序列化与反序列化。
    部分业务,可能很难提供标准服务,需要用原生API访问数据存储,比如Kafka。
    2.3 总体物理架构
    总体物理架构如下:

    接口机将竞价、赢价请求写入Kafka,dmp接口机从Kafka中读取数据,上传至阿里云OSS;同时,接口机将广告数据等上传至阿里云oss。
    通过API从友盟获取用户群标签、探针数据,进入Hadoop。
    Hadoop每天、小时、十分钟进行计算;Hadoop计算的结果部分同步到DMP的Aerospike,供竞价引擎使用。每天计算的报表数据同步到MySQL数据库;用户属性、回头客等数据,同步到Aerospike;部分数据通过接口机,进入MySQL,然后再计算进入memcache中。

    2.4 总体功能架构
    综合需求及总体技术架构的考虑,功能组件架构设计如下:

    注:标绿色的为本期要做的,蓝色的用阿里云服务。
    ν 采集
    大部分数据都是结构化的数据,这些数据由RTB或者DSP系统按照接口规范生成数据,推送到Kafka。
    ν ETL
    除了传统的批处理式的ETL,实时性要求高的,则需要实时ETL,实时ETL实现的功能与批处理ETL功能一样。
    ETL作业完成具体的ETL任务,包括处理接口数据,数据清洗、转换、加载,数据仓库、数据集市内部数据的迁移,及生成供其他系统使用的数据接口。
    备份/归档作业对数据仓库中的数据、程序等进行备份或者归档处理。
    ν 调度
    调度程序用以调度ETL作业和其他程序,并在执行中监控程序的执行,将执行情况记录日志,并将部分情况通知相关人员。调度作业用以调起系统中所有需要调度的程序;调度监控用以监控调度程序的执行;ETL监控用以监控ETL作业的执行;短信通知用以将监控信息以短信的方式通知相关人员。
    ν 业务应用
    将数据仓库中的数据处理后形成的信息展现给用户。报表是以固定格式将数据展现给用户;BI是使用OLAP工具,从多个维度对数据进行分析;机器学习是对数据进行深层次的分析,提炼出隐晦的信息;即席查询是对明细数据或者汇总数据根据不同的条件进行特定的查询,相对报表来讲查询项比较多,展现的数据格式也不完全是固定的。邮件导出是将报表或者未经报表展现的数据以邮件的形式提供给用户。
    ν 系统功能
    通过统一的方式和用户进行交互,包括数据展现、参数配置等。安全管理是对系统的安全,特别是用户权限进行控制。系统管理是对系统的参数进行配置,对系统运行情况进行监控等。API用与第三方应用进行交互。系统监控由阿里云提供的服务进行监控。
    2.5 系统扩展性考虑
    为适应数据平台业务种类和规模逐渐增长的需要,在系统设计的时候需要充分考虑系统的可扩展性,系统架构和功能应易于扩展,随着业务范围的拓展、业务模式的转变、数据规模的增大,大洋项目应能够相对容易地升级和扩展,并很好地利用已有投入。
    整个数据平台每部分都是集群,都可以实现平滑的水平扩展。Hadoops集群可以扩展至数千台。Aerospike集群也可扩展到数十台。其他相关组件也将是分布式或者是可负载均衡的。MySQL也可以按业务划分成不同的库。
    虽然都可水平扩展,但都有一定的限度,扩展时需特别注意临界点。
    系统的扩展性主要从软硬件平台和应用方面综合考虑:
    ν 软硬件平台

    • hadoops
      增加hadoop服务器,并在其上布署Hadoop及其他组件
    • Aerospike
      增加ECS服务器,部署Aerospike服务。达到一定规模后,需要再部署一套集群。相关应用程序、连接等需要修改。
      ν 服务
    • 应用服务
      增加ECS服务器,部署应用程序
    1. 数据存储架构设计
      3.1 总体数据存储
      整体数据架构如下图所示:

    注:标绿色的为本期要做的
    图 1 数据架构
    数据只在共享层和集市层进行存储,其他最多是临时性存储部分数据。
    所有结构化数据放在Hadoop中供以后使用的,都要在HDFS上建立与表名对应的目录,然后表名目录下再按时间分目录。所有原始明细数据都入hadoop,各种备份数据也放在hadoop中/backup目录下进行备份。
    在实时集群中,明细数据只是临时性的保存一两天,生成的结果也会很快同步到数据仓库或者数据集市中。文件数据块保存两个副本。原始数据过来后,保存在特定目录下,spark从目录中读取数据,进行计算,将结果写入特定目录下。如果需要将其同步到数据仓库中,则保存为parquet格式,如果目表是MySQL,则保存成文本文件。
    在数据仓库中,明细数据保留三五天,集成数据保留2个月左右,汇总数据及展示数据原则上永久保存。Hadoop中除了有业务数据,由于数据量太大,没有其他更好的备份方式,Hadoop同时还兼具备份功能。
    Aerospike做为缓存、内存数据库,需要把数据提前在hadoop或者在MySQL中计算好,然后通过Load方式批量同步至Aerospike。
    3.2 共享层
    3.2.1 Hadoop数据仓库
    数据仓库中的业务数据分为三个层次:交互层、汇总层、集市层。交互层可以实时与外部程序进行交互,完成部分加载、更新等功能。交互层表都是外部表,数据都按表名、时间进行分区即分目录,每个表名级目录都对应hive中的一个表,表名下的目录即hive表的分区,数据格式必须与原始文件格式保持一致,包括字符集、文件格式、行分隔符、列分隔符等,为了最大化存储及性能,最好采用gzip、snappy、lzo压缩格式,优先选择gzip;数据平台最大价值很大部分是基于把不同的数据集成在一起,提供一个统一的数据层。集成层的数据,都是平台级一致,为后面的汇总、报表、即席查询、机器学习等应用提供了最坚实的保障。集成层的表都是内部表,按天进行分区,都是Parquet格式,采用snappy压缩,中间计算结果也用snappy压缩,其他都是hive默认格式;集成层虽然可以满足各种各样的数据需求,但是数据量太大,响应时间是个很大的问题,而且用户的需求很多都是类似的,所以可以根据不同的维度对数据提前汇总。汇总层的数据格式与集成层保持一致;汇总层数据为了满足各种需求,做的比较通用,无法根据不同业务需求进行定制,但是不定制又无法满足用户需求,于是就有了数据集市层。数据集市层的数据大部分都来源于汇总层,少部分来源于集成层。集市层数据格式与集成层保持一致,如果集市层数据需要同步到MySQL中,再导出到hdfs上,通过NFS挂载或者导出到本地文件,供以后使用。
    Hadoop中的hive表结构不以三范式为主,大部分表只满足第一范式,少部分表第一范式也可不满足。
    Hadoop中报表及其依赖表以星型模型为主,雪花模型为辅。
    3.3 集市层
    3.3.1 MySQL数据
    由于MySQL不分schema,表根据前辍区分不同类型的表,MySQL中的表根据业务情况可以不满足三范式,但最好满足第一范式。
    整个平台中的元数据(包括业务元数据,技术元数据,操作元数据)都保留在MySQL中,hadoops计算所需要用到的元数据及其他表,由sqoop同步。MySQL所需的hadoops数据,也由sqoop同步。数据量大的,需要注意在不同的服务器间并行执行。

    3.3.2 Aerospike数据
    Aerospike数据不作为永久存储的主要场所,无论是做为数据库,还是做为缓存。Aerospike作为数据库,其实大部分压力都是来自于查询,暂时不向Aerospike中实时插入或更新数据。
    Aerospike作为缓存,采用主动更新和被动更新两种方式同时使用。对时效性要求不太高的,采用被动更新,每个对应的表都设一个统一的保存时长,查询Aerospike时,有则直接返回结果,没有则从RDBMS或者hadoop中查询。对于时效性要求比较高的,则采用主动同步方式,即由程序捕获变化数据,即时更新Aerospike数据,查询时,在Aerospike中有或者没有,都直接返回。

    1. 服务
      4.1 总体原则及策略
      ν 性能第一,通用性第二
      ν Microservice方式,部分模块宕机不影响其他服务
      ν 每个程序都可分布式
      ν 程序模块化,层次化,参数化,并可热更新参数
      ν 多种安全方式并存
      4.2 概要
      外部对平台的使用基本都是通过调用API的方式,即方便用户使用,又能控制用户的使用。庞大的数据量和复杂的使用方式,决定了需要多种技术相结合,而底层复杂的存储、计算方式,也决定了应用的复杂。开发程序,将所有底层程序进行API封装,同时加入安全控制、流量审计等功能。
      不同的应用方式,也决定了API也需要根据不同的使用方式进行封装。主要通过Google protobuf over http对外提供接口实现。复杂的应用,用一个服务的方式过于复杂,而且修改非常不容易,API通过microService方式,将功能分解成不同的服务,屏蔽了复杂性,同时一部分功能不可用,不至于整个服务都受到影响。
      4.3 安全及并发
      通过负载均衡,达到程序均衡负载和高可用的目的,另外,分布式应用程序,要充分考虑分布式事务,并需要提供很高的并发性能。
      针对外部服务,防火墙应对常规安全,每一个请求都携带token进行验证。用长连接,以减少每次访问时长及保持高性能。外部请求超过服务器处理能力的直接丢弃,不向下层转发。
      针对内部服务,采用无密码验证方式,只是针对特定端口号、IP地址等进行限制。服务内部的连接都采用长连接,并对失败的连接进行多次尝试。

    2. ETL
      5.1 ETL原则及策略
      ν 数据平台批处理调度频率最小为分钟级,轮询方式。其他大粒度按时间调度
      ν ETL程序模块化,层次化,抽象化,将ETL大部分过程配置成参数,通过改变参数改变部分业务逻辑
      ν 监控ETL执行中的重要步骤,并对异常、延迟信息报警
      ν ETL中的大部分操作在hadoop、MySQL中完成,充分利用其存储和计算能力
      ν ETL中的程序支持重做处理
      ν 以调用SQL为主,并配合程序,完成复杂逻辑。
      5.2 ETL逻辑架构

    注:标绿色的为本期要做的
    ETL程序实现具体的业务功能,而ETL程序间的依赖,监控、错误处理则由调度程序实现。
    共享层中的传统数据仓库部分,从交互层到汇总层再到集市层,包括每个层次内部的处理,基本都用Hive或者hive SQL实现。需要查询明细的数据,或者对性能、并发要求很高的数据集市层数据,需要用Elasticsearch(ES)生成索引。实时计算由流式处理框架spark streaming实现实时ETL。
    集市层内部的处理也主要以SQL为主,需要放到缓存中使用的,则调用缓存用到的内存数据库的API实现。
    5.3 调度
    所有调度都由阿里云执行计划、作业完成,执行计划负责调度整个平台所有的调度任务,并监控任务完成情况。作业间的依赖,时间顺序,时间乱序,成功失败触发其他任务等,都在此完成。作业内部只做按顺序完成的小单位功能。
    5.4 实时计算
    实时计算都由流式计算支撑,即用spark实现。在集群中,先部署hadoop,然后在其上部署spark。通过Apache Kafka数据流的方式直接进入spark,而不用再加载到硬盘再缓存内存。使用spark streaming接口,以固定频率,进行计算,将计算结果存储到HDFS上,然后与hadoop同样的方式同步到数据仓库或者MySQL数据集市中。其实时性可以很容易的达到秒级,单服务器可以每秒处理60M以上数据,而且编程接口比较简单。实时计算部分,最好直接从源到结果,尽量减少中间生成结果。
    由于hadoop其他组件没有提供多维度实时查询,将用Elasticsearch实现此功能。获取或计算后的数据,按照需求用Elasticsearch idx实时索引所需字段,加工整理。索引生成后,以Elasticsearch索引格式存储在hdfs中。
    5.5 高频ETL
    高频ETL指小时或高于小时但小于数分钟级的ETL。高频ETL处理的数据量不大,可以在数据仓库平台中用Hive实现。为了尽快完成计算,可以以最简单的方式,允许部分数据不完全正确,跨越数据层次进行计算。高频ETL对系统稳定性的压力比较大,出错时需调度程序能够自动进行重试。
    5.6 低频ETL
    低频ETL指调度频率小于小时的ETL。低频ETL每次处理的数据相对很大,占用的系统资源非常多,逻辑也比较复杂。低频ETL以Hive或者hive完成为主。低频ETL部分完成高频ETL数据的修正。并且绝大多数低频ETL要按照数据层次进行逐层次计算。这部分的计算任务最多、最重,对集群的影响最大,需要注意保证数据的准确、完整、及时。
    低频ETL应避免在OLTP高峰时段进行计算。
    5.7 接口
    5.7.1 接口总体策略及原则
    ν 接口应完整、可靠、及时和准确
    ν 接口定义遵循完整、清晰、准确、可扩展的原则
    ν 最大限度的减轻对源数据提供方的压力
    ν 数据内容不可以包含回车、换行、不可见字符等特殊字符和分隔符
    5.7.2 采集接口数据
    系统都在自己局域网中将adx请求数据、竞价结果数据、结果监控数据、字典数据等以protobuf编码,然后写入自己局域网中的Kafka中。接口程序从各个Kafka中读取数据,反序列化后生成文件,然后cp入库;同时写入spark streaming中。跨外网访问,操作系统防火墙只允许相应的IP、端口有权限,其他安全措施也需要采用。

    5.8 数据同步
    两个平台做为一个整体,数据的一致是最重要的,主要通过同步方式保证访问数据数据的一致。
    5.8.1 数据同步原则及策略
    ν 主要通过sqoop在用户可接受的延迟范围内同步
    ν 软件支持自动触发的则用自动触发,否则定时同步
    ν 小数据量定时全量同步,大数据量定时增量同步
    ν 定时同步分批次间隔开来进行
    5.8.2 MySQL至hadoops
    MySQL同步至hadoops的数据主要是hadoops ETL计算时所需要用到的维表信息;用sqoop同步。
    5.8.3 MySQL至Elasticsearch
    为提高原MySQL中数据的查询时间和并发量,通过Elasticsearch的“Data Import Request Handler”将需要索引的SQL查询数据增量索引至Elasticsearch。
    5.8.4 Hadoops至MySQL
    Hadoops计算结果需要同步至MySQL的,通过sqoop同步过去。通过全量和表分区级增量同步保持数据的最终一致性。

    1. 模型设计
      6.1 模型总体策略及原则
      ν 性能第一,灵活第二,开发难度第三
      ν 表分类,事实表分层,多粒度数据共存
      ν 用“中英文映射文件”控制模型中中文名称与英文简称对应关系
      ν 充分利用PowerDesigner已有功能
      ν 缓慢变化维添加生效时间、失效时间标示其有效范围
      ν 每个表增加upd_time,表示数据生成或者更新的时间

    6.2 模型分类
    事实数据分为五类:
    1、 STG,staging的简称,由接口直接过来的数据表。
    2、 INTE,Integrate的简称,从stg经过清洗转换后的数据表
    3、 AGG,aggregate的简称,从inte经过汇总后的数据表
    4、 DM,data mart的简称,由agg或者inte经过分发的数据表
    5、 SHO,show的简称,DM、AGG或者INTE表加上维表信息,可供前端展示直接使用的表或者视图
    元数据分为四类
    1、 DIM,dimension的简称,维度id-name相关的数据表
    2、 PARA,parameter的简称,维度id-id映射关系的数据表
    数据辅助分为两类
    1、 APP,application的简称,应用程序使用数据库,都用此帐号,通过同义词访问其他schema下的对象
    2、 TMP,temporary的简称,保存ETL处理时,数据计算用到的表
    3、 LOG,ETL计算的日志信息表
    6.3 模型分类明细
    6.3.1 STG
    无论是存储类型,行列分隔符、字段多少,字段顺序、字段类型等都同接口保持一致。这层数据不对抽取过来的数据做任何加工,以原始数据使用方便为主。基本以天分区为主。
    命名规则”S_#源系统名称##源系统业务大类##源系统业务小类##源系统功能#”,##中的没有或者是非常明确的可以省略。
    6.3.2 INTE
    INTE层数据粒度、字段多少等基本跟STG层保持一层。底层存储以Parquet,ORC等高效的存储方式为主,并辅以压缩。需要重点考虑以后各层次的使用,适当冗余。基本以天分区为主。
    命名规则”I
    #业务大类##业务小类##功能#”,##中的没有或者是非常明确的可以省略。
    6.3.3 AGG
    不同的维度组合是不同的表,维度相同的则是同一张表,同一表中不同的业务以SERV_TYPE来区分。AGG层的数据粒度明显大于INTE层,需重点考虑以后层次的灵活使用,并保证指标值唯一。这层分区以time_type, time_id做为分层,对于小时、分钟、秒细粒度时间,在表中添加维度标示。
    命名规则“G_#维度1##维度2#……#维度N#”。
    6.3.4 DM
    首先以业务来分类,然后根据维度的不同分表。如果数据量比较大,也可以再按业务小类分表。这层以方便业务使用为主,大部分来源于AGG表简单加工。这层分区以time_type, time_id做为分层,对于小时、分钟、秒细粒度时间,在表中添加维度标示。需重点考虑使用的性能及方便问题。
    命名规则”M_#业务大类##业务小类##功能#”,##中的没有或者是非常明确的可以省略。
    6.3.5 SHO
    为前端展示而用,可以是视图或者表。这层会在DM层或者AGG层等层的基础上,加上冗余信息,使用时不用再大量关联维表。这层是表的分区以time_type, time_id做为分层,对于小时、分钟、秒细粒度时间,在表中添加维度标示。需重点考虑维值变化时,如何保证SHO的冗余信息与维度一致。
    以”H_”开头,其后跟inte、agg、dm等表表名。
    6.3.6 TMP
    计算时临时用到的表,以方便计算为主,同时需考虑此类表也不能建的太多。
    以”T_”开头,其后跟inte、agg、dm等表表名。
    6.3.7 DIM
    大部分都是层次结构,即每个维值ID都有对应的父维值ID,其父信息也是做为一条记录存储。对于需要以表中不同的字段来表示层次结构时,最好以视图或者物化视图的方式进行组织。存储公共维度,业务部分在数据中体现。由于维度会特别多,需要把维值少而且功能简单的维度放到一两张表中,避免表太多。需重点考虑生效与失效问题。
    命名规则”D_#功能#”。
    6.3.8 PARA
    存储公共参数,业务部分在数据中体现。主要用于各源数据与数据仓库数据的对应关系。PARA表字段数据仓库中的维度ID放在前面,源数据维度ID放在后面。需重点考虑生效与失效问题。
    命名规则”P_#功能#”。
    6.4 维护
    6.4.1 原则
    1、 保持生产与文档同步
    2、 如与生产有冲突,以生产为准
    3、 坚持规范,规范不对的地方待某一时刻统一修改

    6.4.2 方法
    1、 未上线的以红色标记,上线后改成一致
    2、 模型由多人维护时,使用前在SVN上先加锁
    3、 所有用到的表、视图等都要先维护,后使用

    1. 元数据管理
      7.1 元数据概述
      数据平台中,技术元数据包括但不限于ETL映射关系、部分维表数据、部分参数表数据、程序执行日志、数据库对象和体系结构、算法;业务元数据包括但不限于大部分维表、大部分参数表和业务相关的数据。
      数据元数据中的缓慢变化维,需要记录每条数据的生效时间和失效时间,所有的元数据都首先保存在MySQL中,并以其为准,同步至其他数据集群。其他元数据,无论在什么地方生成的,都需要同步至MySQL中,然后再由其同步到其他需要的数据集群中。
      文档型元数据,在SVN的形式进行保存,每个目录下都需要放个readme文件,记录同级目录的作用。
      7.2 元数据管理策略
      ν 元数据管理满足当前需求,并提供一定的前瞻性
      ν 数据元数据存放在前端应用存储服务器上,文档元数据存放在SVN上
      ν 分阶段实现元数据的管理和使用,数据元数据首先在数据库中实现良好的管理,然后以WEB形式实现;文档元数据也最好有统一的管理方式
      7.2.1 元数据导入
      这部分主要是数据元数据,文档元数据不需要导入。
      元数据的导入分为手工导入和自动导入两种模式,通常在项目中会结合使用这两种模式。
      大部分的元数据都应当采用手工导入方式进行,包括业务元数据和技术元数据,这是因为这些元数据并不经常变化,只要在需要的时候以手工的方式将其导入到数据库中就可以了。
      而对于系统执行中产生的元数据,则自动导入数据库中。包括中间生成的日志和参数信息。
      业务元数据和部分技术元数据首先整理后手工导入前端应用存储服务器,然后再调用程序将其导入数据仓库存储中。如果数据仓库存储中有自动生成的元数据,则稍后将其导入前端应用存储服务器。
      7.2.2 元数据存储
      无论是数据元数据,还是文档元数据,存储方式都是分布式存储,但都有描述元数据的用途、类型、存储方式、存储地点等的元数据。特别是在文档元数据中有对总体元数据的描述,作为元数据查找的初始入口。
      7.2.2.1 数据元数据存储
      数据元数据以存储在前端应用存储中为主,存储策略同数据库中的其他表。在前端应用存储中存储的,加上主键、外键、索引等,在数据仓库存储中存储的部分,不加主外键等。同时元数据注意备份,以保证在人为故障和系统故障时的快速恢复。
      7.2.2.2 文档元数据存储
      文档元数据不方便存储在数据库中,在SVN中控制和存储,元数据更新后都要及时同步到SVN,并且定期备份。
      7.3 元数据使用
      元数据的管理,是为了更好的使用元数据。元数据的使用包括供技术人员和业务人员使用技术元数据和业务元数据。
      数据元数据,最好以WEB的方式供用户使用。用户在前端修改元数据,就可以实现部分ETL过程,部分前端展现和部分数据库管理功能。
      文档元数据,最好以WEB方式将目录、概要描述、文档归类等信息展现给用户,用户可以根据目录信息找到相应的文档。


  • 技术很棒,也很用心。点赞。



  • @砖家 没公式 跟架构图...



  • 公式 图表 都没粘上来。



  • @bangbei_ceo 专业杠杠滴!~~~


Log in to reply
 

Looks like your connection to Asch was lost, please wait while we try to reconnect.