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

除了支撑集团的大数据建设，团队还提供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 总结

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

                            数据中台：

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