数据中台实战(00)-大数据的尽头是数据中台吗？

青旅半醒 2024-02-29 02:51 67阅读 0赞

除了支撑集团的大数据建设，团队还提供To B服务，因此我也有机会接触到一些正在做数字化转型的传统企业。从2018年末开始，原先市场上各种关于大数据平台的招标突然不见了，取而代之的是数据中台项目，建设数据中台俨然成为传统企业数字化转型的首选，甚至不少大数据领域的专家都认为，数据中台是大数据下一站。

为啥数据中台是大数据的下站？与数仓、数据湖、大数据平台啥区别？来深入大数据发展史，先从数仓出现讲起，途径数据湖，再到大数据平台，这样才能理解大数据发展的每阶段的问题，深入理解数据中台在大数据发展中的历史定位。

### 1 数据仓库 ###

商业智能（Business Intelligence，BI）诞生在1990s，将企业已有数据转化为知识，帮企业经营分析决策。如零售行业门店管理，如何使单门店利润max，就要分析每个商品的销售数据和库存信息，为每个商品制定销售采购计划：

*  有的商品存在滞销，应该降价促销
 *  有的商品比较畅销，要根据对未来销售数据的预测，提前采购

都离不开大量数据分析。

而数据分析需聚合多个业务系统的数据，如集成交易系统、仓储系统的数据，同时需保存历史数据，进行大数据量的范围查询。传统DB面向单一业务系统，主要实现面向事务的增删改查，已不满足数分场景，于是催生数据仓库。

1991年出版的《Building the Data Warehouse》中，数据仓库之父比尔·恩门（Bill Inmon）首次给出数据仓库完整定义：

> 数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的，不可修改的数据集合。

#### 1.1 深入理解数据仓库四要素-电商案例 ####

电商有：

*  DB专门存放订单数据
 *  另一DB存放会员相关数据

###### 构建数仓 ######

先要把不同业务系统的数据同步到一个统一的数仓，然后按主题域方式组织数据。

![image-20230926171735601][]

##### 1.1.1 主题域 #####

业务过程的一个高层抽象，像商品、交易、用户、流量都能作为一个主题域，可理解为数仓的一个目录。数仓中的数据一般按时间进行分区存放，一般保留5年以上，每个时间分区内的数据追加写，对某条记录不可更新。

##### 1.1.2 设计方法 #####

他和金博尔（Kimball） 共同开创的数仓建模的设计方法，对后来基于数据湖的现代数仓设计有重要意义。

###### 自顶向下 ######

恩门的建模方法，顶指数据来源，在传统数仓就是各业务DB。

基于业务中各实体及实体之间的关系，构建数仓。

如买家购买商品，先要理清业务过程涉及的实体。

买家、商品是一个实体，买家购买商品是一个关系。得到如下模型：

买家表：

![0a9b62fb33da5a5571a401f70f132620.png][]

商品表：

![image-20230927093453021][]

买家商品交易表：

![image-20230927093627617][]

###### 自底向上 ######

金博尔建模与恩门正相反，从数据分析的需求出发，拆分维度和事实：

*  用户、商品就是维度
 *  库存、用户账户余额是事实

对应刚才完全一样的表，分别叫：

*  用户维度表
 *  商品维度表
 *  账户余额事实表
 *  商品库存事实表

###### 对比 ######

*  恩门建模从数据源开始构建，构建成本较高，适用应用场景较固定的业务，如金融领域，冗余数据少是优势
 *  金博尔建模从分析场景出发，适用变化速度较快的业务，如互联网业务。现在业务变化都快，更推荐金博尔建模法

传统数仓，第一次明确数分的应用场景应该用单独的解决方案去实现，不再依赖业务DB。模型设计上，提出数仓模型设计的方法论，为后来数分的大规模应用奠定基础。但互联网时代后，传统数仓没落，互联网技术催生大数据时代。

### 2 从Hadoop到数据湖 ###

进入互联网的

#### 2.1 重大变化 ####

##### 数据规模空前 #####

一个成功的互联网产品日活过亿，抖音每天产生几千亿用户行为。传统数仓难扩展，无法承载如此规模海量数据

##### 数据类型变得异构化 #####

互联网数据来自：

*  业务DB结构化数据
 *  App、Web前端埋点数据或业务后端埋点日志，这些数据一般是半结构化甚至无结构。传统数仓对数据模型有严格要求，在数据导入数仓前，数据模型须事先定义好，数据须按模型设计存储

所以，数据规模和数据类型的限制，导致传统数仓无法支撑互联网BI。

谷歌互联网巨头率先开始探索，2003年开始，先后发表论文：

*  [《The Google File System》][The Google File System]
 *  [《MapReduce：Simplified Data Processing on Large Clusters》][MapReduce_Simplified Data Processing on Large Clusters]
 *  [《Bigtable：A Distributed Storage System for Structed Data》][Bigtable_A Distributed Storage System for Structed Data]

奠定现代大数据技术基础。提出新的，面向数分的海量异构数据的统一计算、存储方法。

2005年Hadoop出现，大数据技术才普及。Hadoop是论文的开源实现

#### 2.2 Hadoop V.S 传统数仓 ####

*  完全分布式，易扩展，可用价格低廉机器堆出计算、存储能力强的集群，满足海量数据处理要求
 *  弱化数据格式，数据被集成到Hadoop后，可不保留任何数据格式，数据模型与数据存储分离，数据在被使用的时候，可按不同模型读取，满足异构数据灵活分析需求

随Hadoop成熟，2010年，Pentaho创始人兼CTO James Dixon在Hadoop World大会提出

#### 2.3 数据湖（Data Lake） ####

以原始格式存储数据的存储库或系统。数据湖是Hadoop从开源走向商业化成熟的标志。企业可基于Hadoop构建数据湖，将数据作为企业核心资产。

但一个商用Hadoop包含20多种计算引擎， 数据研发流程多，技术门槛限制Hadoop商用化。如何让数据加工像工厂，直接在设备流水线完成？

### 3 数据工厂：大数据平台 ###

#### 3.1 数据开发流程 ####

*  先将数据导入大数据平台
 *  再按需求进行数据开发
 *  开发完成后，数据验证比对，确认是否符合预期
 *  把数据发布上线，提交调度
 *  日常任务运维，确保任务每日能够正常产出数据

若无高效平台，就跟写代码没有IDE，别人完成十个需求，你一个需求都完成不了。

大数据平台就是为提高数据研发效率，降低数据研发门槛，让数据在一个设备流水线快速完成加工。

> 大数据平台面向数据研发场景，覆盖数据研发的完整链路的数据工作台

![6ccc6cefb7b0bd1dda817464918ed0f3.png][]

#### 3.2 大数据平台使用场景 ####

*  数据集成
 *  数据开发
 *  数据测试
 *  发布上线
 *  任务运维

大数据平台使用对象是数据开发。大数据平台底层以Hadoop为代表的基础设施，分为计算、资源调度和存储。

#### 3.3 大数据计算引擎 ####

*  Hive、Spark 解决离线数据清洗、加工，Spark用得越来越多，性能要比Hive 高不少
 *  Flink解决实时计算
 *  Impala解决交互式查询

这些计算引擎统一运行在Yarn，Yarn来分配计算资源。也有基于k8s实现资源调度，如Spark版本（2.4.4）能运行在k8s管理的集群，可实现在线和离线的资源混合部署，节省机器成本。

#### 3.4 数据存储 ####

*  HDFS 不可更新，主要存全量数据
 *  HBase提供了一个可更新的KV，主要存一些维度表
 *  ck/Kudu 提供实时更新，一般用在实时数仓的构建场景中

大数据平台像一条设备流水线，经过大数据平台的加工，原始数据变成了指标，出现在各个报表或者数据产品中。随着数据需求的快速增长，报表、指标、数据模型越来越多，找不到数据，数据不好用，数据需求响应速度慢等问题日益尖锐，成为阻塞数据产生价值的绊脚石。

### 4 数据中台（数据价值） ###

2016年前后，互联网高速发展，对数据需求越来越多，数据应用场景也越来越多，大量数据产品进入运营日常工作，成为运营工作。电商业务有供应链系统，会根据各个商品的毛利、库存、销售数据以及商品的舆情，产生商品的补货决策，然后推送给采购系统。

#### 4.1 大规模数据的应用暴露问题 - 数据割裂 ####

##### 不敢用数据 #####

业务发展前期，为快速实现业务，烟囱式开发导致企业不同业务线，甚至相同业务线不同应用数据都割裂。两个数据应用的相同指标，展示结果不一致，导致运营对数据信任度下降。如你是运营，当你想看一下商品的销售额，发现两个报表都叫销售额的指标出现两值，第一反应数据算错，不敢用这数据。

##### 大量重复计算、开发 #####

导致的研发效率的浪费，计算、存储资源的浪费，大数据的应用成本越来越高。

*  运营想要一个数据时，开发说至少一周，能不能快？
 *  数据开发面对大量需求，抱怨需求太多，干不完
 *  老板看到每月账单成指数级增长，觉得这也太贵，能不能再省

这些问题根源是

#### 4.2 数据无法共享 ####

2016年，阿里巴巴提“数据中台”。**数据中台的核心，是避免数据的重复计算，通过数据服务化，提高数据的共享能力，赋能数据应用。**

*  之前，数据是要啥没啥，中间数据难于共享，无法积累
 *  建设数据中台之后，要啥有啥，数据应用的研发速度不再受限于数据开发的速度，一夜就可根据场景，孵化出很多数据应用，这些应用让数据产生价值

### 5 总结 ###

1.  数据中台构建于数据湖之上，具备数据湖异构数据统一计算、存储的能力，同时让数据湖中杂乱的数据通过规范化的方式管理起来。
2.  数据中台需要依赖大数据平台，大数据平台完成了数据研发的全流程覆盖，数据中台增加了数据治理和数据服务化的内容。
3.  数据中台借鉴了传统数据仓库面向主题域的数据组织模式，基于维度建模的理论，构建统一的数据公共层。

数据中台：

*  吸收传统数仓、数据湖、大数据平台优势
 *  又解决数据共享的难题，通过数据应用，实现数据价值落地

[image-20230926171735601]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/ff25f62189724183bfa59ce0ce189b01.png
[0a9b62fb33da5a5571a401f70f132620.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/9ce10f4dcc264d8882de83b26909f37a.png
[image-20230927093453021]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/aaf3ac5eb82240f0b1623ea48f772e8e.png
[image-20230927093627617]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/abf9777f051d43ebbcd1b568f29c3566.png
[The Google File System]: https://dl.acm.org/doi/abs/10.1145/945445.945450
[MapReduce_Simplified Data Processing on Large Clusters]: https://dl.acm.org/doi/abs/10.1145/1327452.1327492
[Bigtable_A Distributed Storage System for Structed Data]: https://dl.acm.org/doi/abs/10.1145/1365815.1365816
[6ccc6cefb7b0bd1dda817464918ed0f3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/02/29/89a234499cea4e2ead4d58de879ff840.png