数据中台知识体系（上）：原理篇
2021-07-14 13:11:51 3 举报AI智能生成
数据中台是一套可持续“让企业的数据用起来”的机制，一种战略选择和组织形式，是依据企业特有的业务模式和组织架构，通过有形的产品和实施方法论支撑，构建一套持续不断把数据变成资产并服务于业务的机制。数据中台建设是一个系统工程，需要从上到下进行推动，涉及组织架构、人员配备、流程优化、技术支持等多个方面。在实施过程中，需要明确目标、制定计划、分阶段推进，并注重与业务部门的沟通协作，以确保数据中台能够真正为企业创造价值。总之，数据中台是一个复杂而又重要的课题，值得我们深入研究和探讨。
作者其他创作
大纲/内容
开篇词
背景
负责网易大数据平台团队
对内服务于网易各个业务线，为业务提供大数据建设需要的产品和技术
对外帮助传统企业实现数字化转型，提高运营效率，涉及零售、教育、农业、金融、物流等行业
成果
多个业务线数据中台项目落地，业务高度认可
一套数据中台建设的方法论
实践验证的数据中台支撑技术体系
数据中台是充满诱惑的陷阱？
客观原因：数据中台的建设是一项系统性工程，从组织架构、支撑技术到流程规范，既要有宏观的顶层设计，又要有强有力的落地执行，团队要求较高
主观原因：企业本身数据建设经验不足，不清楚数据建设中的痛点，更不知道用什么样的技术手段和管理机制去解决问题
切入点
结合网易数据中台的实践经验，一线的案例
从原理到实现，最后到实践
原理篇
回答三个问题
什么是数据中台？
数据中台解决了什么问题？
如何来规划数据中台的建设？
实现篇
数据中台支撑技术的整体架构
元数据
指标管理
模型设计
数据质量
成本控制
数据服务
数据安全
流程协作
数据应用
解决数据建设痛点
指标口径不一致
数据无法按时产出
......
原理篇
前因后果
启蒙时代：数仓仓库的出现
商业智能（Business Intelligence）诞生在上个世纪90年代
数据分析需要聚合多个业务系统的数据，传统数据库已经不能满足数据分析场景
Bill Inmon 1991年 给出数仓定义：
数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的，不可修改的数据集合。
Bill Inmon 提出的建模方法：
自顶向下（这里的顶指数据来源）
基于业务中各个实体以及实体之间的关系构建数据仓库
Kimball 的建模方法与 Bill Inmon 正好相反，是一种自底向上的模型设计方法
从数据分析的需求出发
拆分维度和事实
两种方法各有优劣
Bill Inmon
从数据源开始构建，构建成本高，适用于比较固定的业务，如金融领域
冗余数据少是它的优势
Kimball
从分析场景出发，适用于变化速度较快的业务，比如互联网业务
现在业务变化较快，更适合用kimball维度建模
技术变革：从Hadoop到数据湖
互联网时代的变革
数据规模前所未有
数据类型异构化
谷歌的三驾马车
《The Google File System》
《MapReduce：Simplified Data Processing on Large Clusters》
《Bigtable：A Distributed Storage System for Structed Data》
Hadoop相比于传统数仓的优势
完全分布式，易于扩展，价格低廉能满足海量数据的处理需求
弱化数据格式
Data Lake
随着Hadoop技术日趋成熟
2010年 数据湖的概念在 Hadoop World 大会上提出
数据湖拉开了Hadoop商业化的大幕
数据工厂时代：大数据平台兴起
数据开发的繁杂流程
1.数据集成
2.数据开发
3.数据测试
4.数据发布
5.任务运维
大数据平台概念的提出，就是为了提高数据研发的效率，降低门槛
大数据平台的底层是以Hadoop为代表的基础设施，分为计算、资源调度和存储
Hive、Spark、Flink、Impala提供了大数据计算引擎
Hive\Spark 主要解决离线数据清洗、加工的场景
Flink主要解决实时计算的场景
Impala主要是解决交互式查询的场景
上述计算引擎统一运行在Yarn资源调度管理框架
最新的研究方向中，也有基于Kubernetes实现资源调度
可以实现在线和离线的资源混合部署，节省机器成本
数据存储在HDFS、Kudu和HBase系统内
HDFS不可更新，主要存全量数据
HBase提供了一个可更新的KV，主要存一些维度表
Kudu提供了实时更新的能力，一般用于实时数仓构建的场景中
大数据平台像一条设备流水线，经过大数据平台的加工，原始数据变成了指标，出现在各个报表或者数据产品中。
但随着需求不断的膨胀，响应速度慢、数据不好用..越来越多的问题成了阻塞数据产生价值的绊脚石。
数据价值的时代：数据中台的崛起
背景：大规模数据的应用，逐渐暴露出现一些问题
烟囱式的开发导致企业的数据互相割裂，业务对数据的信任度下降
大量重复的计算、开发，导致研发效率的浪费，大数据应用成本越来越高
数据中台的核心
避免数据的重复计算，通过数据服务化，提高数据的共享能力，赋能数据应用
中台思想的核心
共享、连接和服务，这是中台思想的根
为什么说数据中台是大数据的下一站？
数据中台构建于数据湖之上，具备数据湖异构数据统一计算、存储的能力，同时让数据湖中杂乱的数据通过规范化的方式管理起来
数据中台需要依赖大数据平台，大数据平台完成了数据研发的全流程覆盖，数据中台增加了数据治理和数据服务化的内容
数据中台借鉴了传统数据仓库面向主题域的数据组织模式，基于维度建模的理论，构建统一的数据公共层
数据中台吸收了传统数据仓库、数据湖、大数据平台的优势，同时又解决了数据共享的难题，通过数据应用，实现数据价值的落地
数据中台的下一站是什么？
实时数据中台，实现流批一体
云上数据中台，全面拥抱K8S，实现在线、离线混合部署，进一步提高资源利用率
智能元数据管理+增强分析，降低数据分析的门槛，进一步释放数据智能
自动化代码构建，进一步释放数据研发的效能
数据产品的时代，面向各行业的数据产品全面涌现，并和数据中台实现联动
关键抉择
面临的挑战
线上流量枯竭，业绩增长乏力，企业成本高筑，利润飞速下滑
原先粗放的企业管理模式和经营模式没办法继续支撑企业的高速增长
暴露的问题
指标口径不一致
数据重复建设，需求响应时间长
取数效率低
数据质量差
数据成本线性增长
为什么数据中台可以解决这些问题？
解决指标口径不一致
原因：业务口径不一致、计算逻辑不一致、数据来源不一致
要实现一致，就务必确保对同一个指标，只有一个业务口径，只加工一次，数据来源必须相同。
解决数据需求响应慢
原因：一方面是找不到数据，另一方面原因可能是取不到数据
构建一个全局的企业数据资产目录，实现数据地图功能
解决数据质量差
具备及时发现然后快速恢复数据问题的能力
数据中台的理念
数据中台是企业构建的标准的、安全的、统一的、共享的数据组织，通过数据服务化的方式支撑前端数据应用。
数据中台如何解决这些问题？
指标是数据加工的结果，要确保数据需求高质量的交付，首先是要管好指标。
原先的指标管理非常分散，没有全局统一的管理。数据中台中，必须要有一个团队统一负责指标口径的管控。
要实现指标体系化的管理，提高指标管理的效率。
确保所有的数据产品、报表都引用指标系统的口径定义。
什么样的企业适合建数据中台？
构建投入
数据中台的建设离不开系统的支撑
面对大量的数据需求，要花费额外的人力去做数据模型的重构，也需要下定决心
考虑因素
企业是否有大量的数据应用场景
经过了快速的信息化建设，企业存在较多的业务数据的孤岛
面临效率、质量和成本的苦恼
企业面临经营困难，需要通过数据实现精益运营，提高企业的运营效率
数据中台建设的三板斧：方法论、组织和技术
方法论
OneData
分主题域管理
命名规范定义
指标一致
数据模型复用
数据完善
OneService
屏蔽异构数据源
MySQL:数据量小
HBase:数据量大（超过500W Row）
Greeplum:多维分析场景
Redis:实时要求高
ES:全文本检索
数据网关
权限
监控
流控
熔断
逻辑模型
屏蔽底层物理模型设计
性能和稳定性
无状态设计
支撑技术
大数据基础设施
大数据平台
数据治理
元数据中心
数据地图
数仓设计
数据质量
成本优化
指标管理
数据服务
数据应用
组织架构
独立于业务线的中台组织部门
中台团队必须深入业务，懂业务
中台团队的组织架构
数据产品
数据开发
数据平台
数据应用
中台团队的组织绩效必须与业务绑定
收藏
收藏
0 条评论
下一页
