大数据的前世今生
启蒙时代 数据仓库的出现
商业智能（Business Intelligence）诞生在上个世纪 90 年代，它是将企业已有的数据转化为知识，帮助企业做出经营分析决策。
BI的例子
比如在零售行业的门店管理中，如何使得单个门店的利润最大化，我们就需要分析每个商品的销售数据和库存信息，为每个商品制定合理的销售采购计划，有的商品存在滞销，应该降价促销，有的商品比较畅销，需要根据对未来销售数据的预测，进行提前采购，这些都离不开大量的数据分析。
传统单一数据库的瓶颈
而数据分析需要聚合多个业务系统的数据，比如需要集成交易系统的数据，需要集成仓储系
统的数据等等，同时需要保存历史数据，进行大数据量的范围查询。传统数据库面向单一业
务系统，主要实现的是面向事务的增删改查，已经不能满足数据分析的场景，这促使数据仓
库概念的出现。
数仓的定义
在 1991 年出版的《Building the Data Warehouse》中，数据仓库之父比尔·恩门（Bill Inmon）首次给出了数据仓库的完整定义，他认为：
数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的，不可修改的数据集合。
数仓的四要素
面向主题的，集成的，与时间修改的，不可修改的
比如在电商场景中，我们会把不同业务系统的数据同步到一个统一的数据仓库中，然后按照主题域方式组织数据。比如将交易库，会员库，仓储库的数据都存储数仓，并按照主题域比如用户域，流量域，交易域进行划分。
主题域
主题域是业务过程的一个高层次的抽象，像商品、交易、用户、流量都能作为一个主题域，
你可以把它理解为数据仓库的一个目录。数据仓库中的数据一般是按照时间进行分区存放， 一般会保留 5 年以上，每个时间分区内的数据都是追加写的方式，对于某条记录是不可更新的。
数据建模方法
恩门 - 自顶向下建模法
这里的顶是指数据的来源，在传统数据仓库中，就是各个业务数据库，基于业务中各个实体以及实体之间的关系，构建数据仓库。
比如，在一个最简单的买家购买商品的场景中，按照恩门建模的思维模式，首先你要理清这个业务过程中涉及哪些实体。买家、商品是一个实体，买家购买商品是一个关系。所以，模 型设计应该有买家表，商品表，和买家商品交易表三个模型。
买家表
商品表
买家商品表
金博尔 - 自底向上建模法
金博尔建模与恩门正好相反，是一种自底向上的模型设计方法，从数据分析的需求出发，拆分维度和事实。那么用户、商品就是维度，库存、用户账户余额是事实。
用户维度表
商品维度表
账户余额事实表
商品库存事实表
适用场景
恩门建模因为是从数据源开始构建，构建成本比较高，适用于应用场景比较固定的业务，比如金融领域，冗余数据少是它的优势。金博尔建模由于是从分析场景出发，适用于变化速度比较快的业务，比如互联网业务。由于现在的业务变化都比较快，所 以我更推荐金博尔的建模设计方法
技术革命， 从Hadoop到数据湖
进入互联网时代，有两个重要的变化 一个是数据规模前所未有，另一个是数据类型变得异构化，由于这两种变化的限制，传统数仓不再能满足商业只能的场景。
Hadoop的3个优势
- 完全分布式，易于扩展，可以使用价格低廉的机器堆出一个计算、存储能力很强的集 群，满足海量数据的处理要求；
- 弱化数据格式，数据被集成到 Hadoop 之后，可以不保留任何数据格式，数据模型与数 据存储分离，数据在被使用的时候，可以按照不同的模型读取，满足异构数据灵活分析 的需求
Hadoop 从开源技术走向商业化成熟的标志 - 数据湖
随着 Hadoop 技术日趋成熟，2010 年，Pentaho 创始人兼 CTO James Dixon 在纽约
Hadoop World 大会上提出了数据湖的概念，他提到：
数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统。
数据湖拉开了 Hadoop 商用化的大幕，但是一个商用的 Hadoop 包含 20 多种计算引擎， 数据研发涉及流程非常多，技术门槛限制了 Hadoop 的商用化进程。那么如何让数据的加工像工厂一样，直接在设备流水线上完成呢？
数据工厂时代：大数据平台兴起
数据研发工作流程
数据集成，数据开发，数据测试，数据发布，数据运维
如此繁杂的一个工作流程，如果没有一个高效的平台作为支撑，就跟写代码没有一个好用的 IDE， 用文本编辑器写代码一样，别人完成十个需求，你可能连一个需求都完成不了，效率异常低下，根本无法大规模的应用。提出大数据平台的概念，就是为了提高数据研发的效率，降低数据研发的门槛，让数据能够 在一个设备流水线上快速地完成加工。
大数据平台
大数据平台是面向数据研发场景的，覆盖数据研发的完整链路的数据工作台。
大数据平台底层架构
大数据平台的底层是以 Hadoop 为代表的基础设施，分为计算、资源调度和存储。
Hive、Spark、Flink、Impala 提供了大数据计算引擎：
Hive、Spark 主要解决离线数据清洗、加工的场景，目前，Spark 用得越来越多，性能
要比 Hive 高不少；
Flink 主要是解决实时计算的场景；
Impala 主要是解决交互式查询的场景。
这些计算引擎统一运行在一个称为 Yarn 的资源调度管理框架内，由 Yarn 来分配计算资源。目前最新的研究方向中也有基于 Kubernetes 实现资源调度的，例如在最新的 Spark 版本（2.4.4）中，Spark 已经能够运行在 Kubernetes 管理的集群上，这样的好处是可以实现在线和离线的资源混合部署，节省机器成本。
数据存储在 HDFS、Kudu 和 HBase 系统内。HDFS 不可更新，主要存全量数据，HBase 提供了一个可更新的 KV，主要存一些维度表，Kudu 提供了实时更新的能力，一般用在实时数仓的构建场景中。
大数据平台的瓶颈
大数据平台像一条设备流水线，经过大数据平台的加工，原始数据变成了指标，出现在各个报表或者数据产品中。随着数据需求的快速增长，报表、指标、数据模型越来越多，找不到数据，数据不好用，数据需求响应速度慢等问题日益尖锐，成为阻塞数据产生价值的绊脚石。
数据价值时代：数据中台崛起
时间到了 2016 年前后，互联网高速发展，背后对数据的需求越来越多，数据的应用场景也越来越多，有大量的数据产品进入到了我们运营的日常工作，成为运营工作中不可或缺的一部分。
大规模数据的应用暴露出来的问题
业务发展前期，为了快速实现业务的需求，烟囱式的开发导致企业不同业务线，甚至相同业
务线的不同应用之间，数据都是割裂的。两个数据应用的相同指标，展示的结果不一致，导
致运营对数据的信任度下降。
数据割裂的另外一个问题，就是大量的重复计算、开发，导致的研发效率的浪费，计算、存 储资源的浪费，大数据的应用成本越来越高。
如果你是运营，当你想要一个数据的时候，开发告诉你至少需要一周，你肯定想是不是太慢了，能不能再快一点儿？
如果你是数据开发，当面对大量的需求的时候，你肯定是在抱怨，需求太多，人太少，
活干不完。
如果你是一个企业的老板，当你看到每个月的账单成指数级增长的时候，你肯定觉得这
也太贵了，能不能再省一点，要不吃不消了。
数据中台的核心
这些问题的根源在于，数据无法共享。2016 年，阿里巴巴率先提出了“数据中台”的口号。数据中台的核心，是避免数据的重复计算，通过数据服务化，提高数据的共享能力，赋能数据应用。之前，数据是要啥没啥，中间数据难于共享，无法积累。现在建设数据中台之后，要啥有啥，数据应用的研发速度不再受限于数据开发的速度，一夜之间，我们就可以根据场景，孵化出很多数据应用，这些应用让数据产生价值。
数据中台为什么可以成为数据平台的下一站?
- 数据中台构建于数据湖之上，具备数据湖异构数据统一计算、存储的能力，同时让数据 湖中杂乱的数据通过规范化的方式管理起来。
- 数据中台需要依赖大数据平台，大数据平台完成了数据研发的全流程覆盖，数据中台增 加了数据治理和数据服务化的内容。
- 数据中台借鉴了传统数据仓库面向主题域的数据组织模式，基于维度建模的理论，构建 统一的数据公共层。
总的来说，数据中台吸收了传统数据仓库、数据湖、大数据平台的优势，同时又解决了数据 共享的难题，通过数据应用，实现数据价值的落地。
