除了支撑集团的大数据建设,团队还提供To B服务,因此我也有机会接触到一些正在做数字化转型的传统企业。从2018年末开始,原先市场上各种关于大数据平台的招标突然不见了,取而代之的是数据中台项目,建设数据中台俨然成为传统企业数字化转型的首选,甚至不少大数据领域的专家都认为,数据中台是大数据下一站。
为啥数据中台是大数据的下站?与数仓、数据湖、大数据平台啥区别?来深入大数据发展史,先从数仓出现讲起,途径数据湖,再到大数据平台,这样才能理解大数据发展的每阶段的问题,深入理解数据中台在大数据发展中的历史定位。
1 数据仓库
商业智能(Business Intelligence,BI)诞生在1990s,将企业已有数据转化为知识,帮企业经营分析决策。如零售行业门店管理,如何使单门店利润max,就要分析每个商品的销售数据和库存信息,为每个商品制定销售采购计划:
- 有的商品存在滞销,应该降价促销
- 有的商品比较畅销,要根据对未来销售数据的预测,提前采购
都离不开大量数据分析。
而数据分析需聚合多个业务系统的数据,如集成交易系统、仓储系统的数据,同时需保存历史数据,进行大数据量的范围查询。传统DB面向单一业务系统,主要实现面向事务的增删改查,已不满足数分场景,于是催生数据仓库。
1991年出版的《Building the Data Warehouse》中,数据仓库之父比尔·恩门(Bill Inmon)首次给出数据仓库完整定义:
数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的,不可修改的数据集合。
1.1 深入理解数据仓库四要素-电商案例
电商有:
- DB专门存放订单数据
- 另一DB存放会员相关数据
构建数仓
先要把不同业务系统的数据同步到一个统一的数仓,然后按主题域方式组织数据。
1.1.1 主题域
业务过程的一个高层抽象,像商品、交易、用户、流量都能作为一个主题域,可理解为数仓的一个目录。数仓中的数据一般按时间进行分区存放,一般保留5年以上,每个时间分区内的数据追加写,对某条记录不可更新。
1.1.2 设计方法
他和金博尔(Kimball) 共同开创的数仓建模的设计方法,对后来基于数据湖的现代数仓设计有重要意义。
自顶向下
恩门的建模方法,顶指数据来源,在传统数仓就是各业务DB。
基于业务中各实体及实体之间的关系,构建数仓。
如买家购买商品,先要理清业务过程涉及的实体。
买家、商品是一个实体,买家购买商品是一个关系。得到如下模型:
买家表:
商品表:
买家商品交易表:
自底向上
金博尔建模与恩门正相反,从数据分析的需求出发,拆分维度和事实:
- 用户、商品就是维度
- 库存、用户账户余额是事实
对应刚才完全一样的表,分别叫:
- 用户维度表
- 商品维度表
- 账户余额事实表
- 商品库存事实表
对比
-
恩门建模从数据源开始构建,构建成本较高,适用应用场景较固定的业务,如金融领域,冗余数据少是优势
-
金博尔建模从分析场景出发,适用变化速度较快的业务,如互联网业务。现在业务变化都快,更推荐金博尔建模法
传统数仓,第一次明确数分的应用场景应该用单独的解决方案去实现,不再依赖业务DB。模型设计上,提出数仓模型设计的方法论,为后来数分的大规模应用奠定基础。但互联网时代后,传统数仓没落,互联网技术催生大数据时代。
2 从Hadoop到数据湖
进入互联网的
2.1 重大变化
数据规模空前
一个成功的互联网产品日活过亿,抖音每天产生几千亿用户行为。传统数仓难扩展,无法承载如此规模海量数据
数据类型变得异构化
互联网数据来自:
- 业务DB结构化数据
- App、Web前端埋点数据或业务后端埋点日志,这些数据一般是半结构化甚至无结构。传统数仓对数据模型有严格要求,在数据导入数仓前,数据模型须事先定义好,数据须按模型设计存储
所以,数据规模和数据类型的限制,导致传统数仓无法支撑互联网BI。
谷歌互联网巨头率先开始探索,2003年开始,先后发表论文:
- 《The Google File System》
- 《MapReduce:Simplified Data Processing on Large Clusters》
- 《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,别人完成十个需求,你一个需求都完成不了。
大数据平台就是为提高数据研发效率,降低数据研发门槛,让数据在一个设备流水线快速完成加工。
大数据平台面向数据研发场景,覆盖数据研发的完整链路的数据工作台
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 总结
- 数据中台构建于数据湖之上,具备数据湖异构数据统一计算、存储的能力,同时让数据湖中杂乱的数据通过规范化的方式管理起来。
- 数据中台需要依赖大数据平台,大数据平台完成了数据研发的全流程覆盖,数据中台增加了数据治理和数据服务化的内容。
- 数据中台借鉴了传统数据仓库面向主题域的数据组织模式,基于维度建模的理论,构建统一的数据公共层。
数据中台:
- 吸收传统数仓、数据湖、大数据平台优势
- 又解决数据共享的难题,通过数据应用,实现数据价值落地