除了支撑集团的大数据建设，团队还提供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 总结
- 数据中台构建于数据湖之上，具备数据湖异构数据统一计算、存储的能力，同时让数据湖中杂乱的数据通过规范化的方式管理起来。
- 数据中台需要依赖大数据平台，大数据平台完成了数据研发的全流程覆盖，数据中台增加了数据治理和数据服务化的内容。
- 数据中台借鉴了传统数据仓库面向主题域的数据组织模式，基于维度建模的理论，构建统一的数据公共层。
数据中台：
- 吸收传统数仓、数据湖、大数据平台优势
- 又解决数据共享的难题，通过数据应用，实现数据价值落地
