数据中台

背景与适用场景
数据中台的目标
  • 数据中台的核心,是避免数据的重复计算,通过数据服务化,提高数据的共享能力,赋能数据应用
  • 解决问题:
    • 指标口径不一致
      • 业务口径不一致
      • 计算逻辑不一致
      • 数据来源不一致
    • 数据重复建设
    • 取数据效率低
    • 数据质量差
    • 数据成本线性增长
  • 定义:
    • 数据中台是企业构建的标准的、安全的、统一的、共享的数据组织,通过数据服务化的方式支撑前端数据应用
数据中台架构核心组成
  • 底座是数据基础平台
    • 数据采集平台
    • 数据计算平台
    • 数据存储平台
  • 中间两大块
    • 中台
      • 负责把模型组织成可以对外服务的数据:数据指标,数据标签
    • 公共数据区
      • 数据仓库(数据湖),负责公共数据模型研发,统一指标(标签)平台
  • 上层是数据应用服务层
    • 将公共数据区的数据对外包装并提供服务:
      • 数据接口平台
      • 多维查询平台
      • 数据可视化平台
      • 数据分析平台
  • 垂直贯穿平台:
    • 数据开发平台:数据接入,数据导出,模型设计工具,脚本开发工具,数据调度工具
    • 数据管理平台:元数据管理,数据质量管理,数据生命周期管理。

img

在数据中台的建设中一定不要忽视的是与业务的衔接,因为数据来源于业务并最终应用于业务,在数据中台的建设中需要有一系列的流程制度明确与业务的充分衔接,以保障数据源&数据产出的质量。

数据中台技术选型
  • 数据抽取层
    • sqoop 结构化数据,关系型数据库
    • flume 非结构化,日志数据
  • 数据存储层
    • hadoop 文件系统hdfs
    • kafka流数据总线
  • 计算调度层
    • 离线计算:hive,spark
    • 实施计算:storm,spark-streaming,flink
    • 数据调度:airflow, azkaban,Oozie
  • 数据引擎层 -- OLAP
    • ROLAP(RelationalOLAP) : 将分析用的多维数据存储在关系数据库中并根据应用的需要有选择的定义一批实视图作为表也存储在关系数据库中。
    • MOLAP(MultidimensionalOLAP):
  • 数据可视化
是否需要中台

image-20200519084316862

图中列出了5个条件判断:

1)是否大型复杂生态系统。如果企业的业态不是大型复杂生态型企业,也许企业信息化系统、ERP就可以解决企业IT治理的问题。何为复杂生态型企业?国内如:BATJ、海尔、华为、小米等都属于这类型企业。

2)是否业务具备不确定性。即市场环境变化快,如互联网行业,以及产业互联网相关行业,都属于这类型行业。

3)是否存在低水平重复建设。先决条件是企业体量够大,不管是自建技术团队还是跟外部第三方公司合作,是否存在重复建设,如整个企业光CRM就有5套,还不是一家公司的产品,就属于重复建设。

4)是否存在数据互联互通问题。即由于事业部制的组织架构,形成了部门墙,数据和系统也是烟囱式的,阿里的业务中台、数据中台解决也是这样的问题。

5)是否信息技术制约企业发展。尽管企业的IT建设一直在持续,但是在当今产业互联网时代、人工智能时代,企业的发展已经受到严重阻碍,也许你该引入中台架构进行变革了。

以上5个条件,任意满足3个及以上,就认为这个企业适合做中台战略升级。

img

  • 拉链表 -- 拉链表是针对数据仓库设计中表存储数据的方式而定义的,顾名思义,所谓拉链,就是记录历史。记录一个事物从开始,一直到当前状态的所有变化的信息。
    • https://www.jianshu.com/p/799252156379

    • 实现方式:

      • 记录开始时间,表示新增的时间
      • 记录结束时间,表示该条记录的有效截至时间,新建结束时间默认为一个最大时间9999-12-31
      • 当变更某条id的数据时,更新之前id的结束时间,并且新增一条记录,开始时间为当前时间,结束时间为最大时间9999-12-31
      • 通过给record增加两个字段: 生效日期、失效日期,来记录数据的生命周期变化;好处是既节省存储空间,又保证历史数据变化的完整性,最重要的还能快速访问不同时段的数据快照
建模方式
  • 恩门提出的建模方法自顶向下(这里的顶是指数据的来源,在传统数据仓库中,就是各个业务数据库),基于业务中各个实体以及实体之间的关系,构建数据仓库
    • 模型设计应该有买家表,商品表,和买家商品交易表三个模型
    • 构建成本比较高,适用于应用场景比较固定的业务,比如金融领域,冗余数据少是它的优势
  • 金博尔建模与恩门正好相反,是一种自底向上的模型设计方法,从数据分析的需求出发,拆分维度和事实。那么用户、商品就是维度,库存、用户账户余额是事实。
    • 从分析场景出发,适用于变化速度比较快的业务,比如互联网业务

拉链表的适用场景

在数据仓库的数据模型设计中,常常会遇到下列情况:

  1. 某个表存储某种类型数据多个维度的数据
  2. 某些维度会发生一些变化,但是发生变化的维度不固定,即大部分维度都有可能改变
  3. 变化频率不会特别高,按数据仓库建设的时间粒度来区分即可以感知到这种变化
  4. 业务有需求获取历史上某一个时间点的历史快照信息,例如:对过去某个时间的所有数据做统计
参考
  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值