正式开讲大数据中台之前， 先复习之前学过的各种技术：
1. 各大类常用存储相关技术组件：
HDFS
Kafka
HBase
ElasticSearch
2. 各大类常用计算相关技术组件：
MapReduce
Spark
Flink
3. 新老OLAP生态技术组件
Hive
ClickHouse
4. 集群资源管理调度组件
YARN
Spark Standalone
Flink Standalone
5. 大数据通用协调服务组件
ZooKeeper
但是，其实技术体系和大数据架构生态是不完整的。在大数据生态中，除了存储和计算之外，还有：
1. 数据收集和迁移
常用技术：flume，canal，sqoop，datax，waterdrop等
2. 任务调度
常用技术：azkaban，oozie，dophinscheduler，airflow
3. 部署运维
常用技术：cloudera manager, ambari，SaltStack等
4. 监控告警
常用技术：Alertmanager + Prometheus，Zabbix，openfalcon等
5. 安全和权限
常用技术：Kerberos，ranger等
等。甚至大数据发展到现在，像数据治理，数据地图，元数据管理，数据资产，数据血缘，数据湖等新潮的概念。
数据库阶段 —> 传统数仓 —> 大数据平台 ----> 大数据中台
商业智能（Business Intelligence）诞生在上个世纪90年代，它是将企业已有的数据转化为知识，帮助企业做出经营分析决策。比如在零售行业的门店管理中，如何使得单个门店的利润最大化，我们就需要分析每个商品的销售数据和库存信息，为每个商品制定合理的销售采购计划，有的商品存在滞销，应该降价促销，有的商品比较畅销，需要根据对未来销售数据的预测，进行提前采购，这些都离不开大量的数据分析。
而数据分析需要聚合多个业务系统的数据，比如需要集成交易系统的数据，需要集成仓储系统的数据等等，同时需要保存历史数据，进行大数据量的范围查询。传统数据库面向单一业务系统，主要实现的是面向事务的增删改查，已经不能满足数据分析的场景，这促使数据仓库概念的出现。
在 1991 年出版的《Building the Data Warehouse》中，数据仓库之父比尔·恩门（Bill Inmon）首次给出了数据仓库的完整定义，他认为：数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的，不可修改的数据集合。
构建数据仓库，首先要把不同业务系统的数据同步到一个统一的数据仓库中，然后按照主题域方式组织数据。主题域是业务过程的一个高层次的抽象，像商品、交易、用户、流量都能作为一个主题域，你可以把它理解为数据仓库的一个目录。数据仓库中的数据一般是按照时间进行分区存放，一般会保留3年以上，每个时间分区内的数据都是追加写的方式，对于某条记录是不可更新的。
这两种方法各有优劣，
传统数据仓库，第一次明确了数据分析的应用场景应该用单独的解决方案去实现，不再依赖于业务的数据库。而随着互联网发展，数据呈指数级增长，传统数据仓库逐渐没落，开始进入到大数据时代。
进入互联网时代，有两个最重要的变化。
从 2003 年开始，互联网巨头谷歌先后发表了3篇论文，较为系统完整的阐述了海量数据的处理思路，奠定了现代大数据的技术基础。提出了一种新的、面向数据分析的海量异构数据的统一计算、存储的方法，完全分布式，易于扩展，可以使用价格低廉的机器堆出一个计算、存储能力很强的集群，满足海量数据的处理要求。
数据存储：HDFS，HBase，Kudu等
数据计算：MapReduce, Spark, Flink
交互式查询：Impala, Presto
在线实时分析：ClickHouse，Kylin，Doris，Druid，Kudu等
资源调度：YARN，Mesos，Kubernetes
任务调度：Oozie，Azakaban，AirFlow等
....
数据收集，数据迁移，服务协调，安装部署，数据治理等
基本上，到了 2010 年，Pentaho 创始人兼 CTO James Dixon 在纽约 Hadoop World 大会上提出了数据湖（一个以原始格式存储数据的存储库或系统）的概念，标志着 Hadoop 从开源走向商业化成熟。典型代表：Cloudera 和 Hortonworks 两家公司提供了成熟的商业化大数据平台解决方案CDH 和 HDP。
大数据平台的作用，就是为了提高数据研发的效率，降低数据研发的门槛，让数据能够在一个设备流水线上快速地完成加工。大数据平台按照使用场景，分为数据集成、数据开发、数据测试……任务运维等，大数据平台的使用对象是数据开发。大数据平台的底层是以 Hadoop 为代表的各种基础设施，分为存储、计算、资源调度和运维监控等。
大数据平台像一条设备流水线，经过大数据平台的加工，原始数据变成了指标，出现在各个报表或者数据产品中。互联网高速发展，背后对数据的需求越来越多，数据的应用场景也越来越多，有大量的数据产品进入到了我们运营的日常工作，成为运营工作中不可或缺的一部分。在电商业务中，有供应链系统，供应链系统会根据各个商品的毛利、库存、销售数据以及商品的舆情，产生商品的补货决策，然后推送给采购系统。随着数据需求的快速增长，报表、指标、数据模型越来越多，找不到数据，数据不好用，数据需求响应速度慢等问题日益尖锐，成为阻塞数据产生价值的绊脚石。
业务发展前期，为了快速实现业务的需求，烟囱式的开发导致企业不同业务线，甚至相同业务线的不同应用之间，数据都是割裂的。两个数据应用的相同指标，展示的结果不一致，导致运营对数据的信任度下降。数据割裂的另外一个问题，就是大量的重复计算、开发，导致的研发效率的浪费，计算、存储资源的浪费，大数据的应用成本越来越高。
在国内，阿里最早提出了“数据中台”的概念。2014年，马云率队参观了实力强大的游戏公司supercell，它的成功的游戏产品有很多，其独特优势是能够快速推出新产品，而依靠的就是中台系统。
马云深受启发，回到阿里后，便提出了“大中台、小前台”战略：沉淀共享服务，打破系统壁垒，业务快速创新。其中“大中台”包含两部分，一个是业务中台，另一个是数据中台。
烟囱式开发 数据孤岛 数据割裂
一般来说，数据中台是指通过数据技术对海量数据进行采集、计算、存储和处理，同时统一标准和口径，形成全域级、可复用的数据资产中心和数据存储能力中心，形成大数据资产层，进而为客户提供高效的服务。
形象地讲，数据中台构建的服务考虑了"可复用性"，每项服务都像一个积木，可以随意组合，灵活高效地解决前台的个性化需求。
总之，数据中台的核心理念是"数据取之于业务，用之于业务"，跟传统数据平台相比，数据中台着眼于业务的积累和沉淀，构建了从数据生产到消费、消费后数据返回到生产的闭环过程。
“让一切业务数据化，一切数据业务化” 是对数据中台系统功能的精要概括。
数据中台的核心，是避免数据的重复计算，通过数据服务化，提高数据的共享能力，赋能数据应用。之前，数据是要啥没啥，中间数据难于共享，无法积累。现在建设数据中台之后，要啥有啥，数据应用的研发速度不再受限于数据开发的速度，然后我们就可以根据需求场景，快速孵化出很多数据应用，这些应用让数据产生价值。
总的来说，数据中台吸收了传统数据仓库、数据湖、大数据平台的优势，同时又解决了数据共享的难题，通过数据应用，实现数据价值的落地。
大量数据产品的出现，在不断提高企业运营效率的同时，也暴露出很多尖锐的问题，在我看来，主要有五点。
因此：数据中台是企业构建的标准的、安全的、统一的、共享的数据组织，通过数据服务化的方式支撑前端数据应用。数据中台消除了冗余数据，构建了企业级数据资产，提高了数据的共享能力。
在我看来，要解决烟囱式开发面临的数据存储冗余，数据计算冗余等问题，就只能构筑一个统一的平台，提供统一的出入口：OneData， OneService。
数据中台的构建需要非常大的投入：
所以数据中台的建设，需要结合企业的现状，根据需要进行选择。我认为企业在选择数据中台的时候，应该考虑这样几个因素。
建设数据中台不能盲目跟风，因为它不一定适合你。所以不要迷信中台！一般人玩不起！
方法论 + 技术 + 组织
在 2016 年，阿里巴巴就提出了"大中台，小前台"，倡导数据中台建设，核心方法论：OneData 和 OneService
简而言之：OneData 就是所有数据只加工一次。
数据中台就是要在整个企业中形成一个公共数据层，消灭这些跨部门的小数仓，实现数据的复用，所以强调数据只加工一次，不会因为不同的应用场景，不同的部门数据重复加工。
如何实现：
OneData 体系的目标是构建统一的数据规范标准，让数据成为一种资产，而不是成本。资产和成本的差别在于资产是可以沉淀的，是可以被复用的。成本是消耗性质的、是临时的、无法被复用的。
OneService，数据即服务，强调数据中台中的数据应该是通过 API 接口的方式被访问。记得我最开始在数仓部门工作的时候，因为数据库权限的问题，我们任务的数据只会通过 sqoop 导出到我们的可视化系统中。如果别的数据产品想要使用，只能给我们提需求，通过一些数据同步工具进行同步，慢慢的这个负担越来越重。
现阶段企业数据应用现状：
因此，从不同的系统取数据，应用开发需要定制不同的访问接口。而且如果数据发生异常，还不能查出影响到下游应用的那些应用或者报表。所以当你想下线一张表的时候，就无法实施，造成了上线容易，下线难的囧状。
而 API 接口一方面对应用开发屏蔽了底层数据存储，使用统一标准的 API 接口查询数据，提高了数据接入的速度。另一方面，对于数据开发，提高了数据应用的管理效率，建立了表到应用的链路关系。
如何实现：
OneService 体系的目标是提高数据的共享能力，让数据可以被用得好，用得爽。
以网易数据中台为例：
这个图完整地描述了数据中台支撑技术体系
数据中台的底层是以 Hadoop 为代表的大数据计算、存储基础设施，提供了大数据运行所必须的计算、存储资源。
在 Hadoop 之上，浅绿色的部分是原有大数据平台范畴内的工具产品，覆盖了从数据集成、数据开发、数据测试到任务运维的整套工具链产品。同时还包括基础的监控运维系统、权限访问控制系统和项目用户的管理系统。由于涉及多人协作，所以还有一个流程协作与通知中心。
灰色的部分，是数据中台的核心组成部分：数据治理模块。它对应的方法论就是OneData体系。以元数据中心为基础，在统一了企业所有数据源的元数据基础上，提供了包括数据地图、数仓设计、数据质量、成本优化以及指标管理在内的5个产品，分别对应的就是数据发现、模型、质量、成本和指标的治理。
深绿色的部分是数据服务，它是数据中台的门户，对外提供了统一的数据服务，对应的方法论就是OneService。数据服务向下提供了应用和表的访问关系，使数据血缘可以延申到数据应用，向上支撑了各种数据应用和服务，所有的系统通过统一的 API 接口获取数据。
在数据服务之上，是面向不同场景的数据产品和应用，包括面向非技术人员的自助取数系统；面向数据开发、分析师的自助分析系统；面向敏捷数据分析场景的 BI 产品；活动直播场景下的大屏系统；以及用户画像相关的标签工厂。
关注奈学的 P8 百万大数据架构课程，带你详解：IaaS, PaaS, SaaS & DaaS。
数据中台提供的是一个跨业务部门共享的公共数据能力，所以，承担数据中台建设职责的部门一定是一个独立于业务线的部门。
独立部门的最大风险是与业务脱节，所以我们对数据中台的组织定位是：懂业务，能够深入业务，扎根业务。数据中台要管理所有的指标，而每个业务线之间的指标既有差异，也有交叉，要理解指标的口径定义，就必须要了解业务的过程。同时，当我们要制定一些新的指标时，必须要了解各个业务线新的业务目标，指标的本质还是为业务目标服务的。
综合来讲：
数据中台的组织架构改革涉及原有各个部门的利益，所以这个是数据中台构建最难又不得不做的地方，必须要取得高层领导的支持和重视。所以需要：
数据中台的构建，需要确保全局指标的业务口径一致，要把原先口径不一致的、重复的指标进行梳理，整合成一个统一的指标字典。而这项工作的前提，是要搞清楚这些指标的业务口径、数据来源和计算逻辑。而这些数据都是元数据。
元数据中心应该包括哪些元数据呢？ 什么样的数据是元数据。
元数据划为三类：数据字典、数据血缘和数据特征
根据我的经历和了解，业界比较流行的元数据产品技术主要有：
关于开源的这两款产品，Metacat 擅长管理数据字典，Atlas 擅长管理数据血缘。
Metacat 介绍：https://github.com/Netflix/metacat ，最大的优势：多数据源的可扩展架构
从上面 Metacat 的架构图中，你可以看到，Metacat 的设计非常巧妙，它并没有单独再保存一份元数据，而是采取直连数据源拉的方式，
Apache Atlas 介绍：http://atlas.apache.org/
血缘采集，一般可以通过三种方式：
对于 Hive 计算引擎，Atlas 通过 Hook 方式，实时地捕捉任务执行计划，获取输入表和输出表，推送给Kafka，由一个 Ingest模块负责将血缘写入 JanusGraph 图数据库中。然后通过 API 的方式，基于图查询引擎，获取血缘关系。对于 Spark，Atlas 提供了 Listener 的实现方式。
解释一下，什么叫做数据血缘
insert overwrite table t2 select classid, count(userid) as count_users from t1 group by classid;
t2 表是由 t1 表的数据计算来的，所以 t2 和 t1 是表血缘上下游关系，t2 的 classid 字段是由 t1 的classid 字段产生的，count 字段是由 userid 经过按照 classid 字段聚合计算得到的，所以 t2 表的classid 与 t1 的 classid 存在字段血缘，t2 表的 count 分别与 t1 表的 classid 和 userid 存在血缘关系。
下图按照功能模块分为数据血缘、数据字典和数据特征。
元数据中心统一对外提供了 API 访问接口，数据传输、数据地图、数据服务等其他的子系统都可以通过API 接口获取元数据。另外 Ranger 可以基于元数据中心提供的API接口，获取标签对应的表，然后根据标签更新表对应的权限，实现基于标签的权限控制。
元数据中心是数据中台的基石，它提供了我们做数据治理的必须的数据支撑，数据的指标、模型、质量、成本、安全等的治理，这些都离不开元数据中心的支撑。
指标是一种特定类型的元数据，公司的运营会围绕它进行工作，可以说，它是业务和数据的交汇点。指标数据能不能用，会影响他们的日常工作。而且元数据在指标管理、模型设计、数据质量和成本治理四个领域也都发挥着作用，而这些领域构成了数据中台 OneData 数据体系。
举两个例子：
1. 第一个：新用户
市场部门认定新用户是首次下单并完成支付的用户；
会员中心认定新用户是当日新注册用户。
2. 第二个：7 日 UV
过去 7 日 UV 的平均值
过去 7 日所有 Vistor 的去重数量
定义不一致，口径不一致，计算逻辑就不一致。所以构建数据中台，需要提供全局一致的指标口径，输出完备统一的指标字典。
又是一个 web 管理平台
1. 运营，产品 能查询已有的指标那些
2. 可以指定新的指标的定义
3. 这些指标，一般来说，要按照主题域进行分类管理
一般进行烟囱式开发的企业都多多少少存在以下的指标问题：
大多数公司的分析师会结合业务做一些数据分析（需要用到大量的数据），通过报表的方式服务于业务部门的运营。但是在数据中台构建之前，分析师经常发现自己没有可以复用的数据，不得不使用原始数据进行清洗、加工、计算指标。
烟囱式数据开发：数据模型无法复用，每次遇到新的需求，都从原始数据重新计算
大数据中台的数据模型：
构建可复用模型的标准：数据模型可复用，完善且规范
现有的大数据平台，或者数仓项目，很难做到任务追踪和数据追踪。举一个例子。
运营每天上班的第一件事，都是打开相应的数据运营系统，如果某天突然发现这个数据反常，需要数据开发部门核对，或者经过他们自己核对，发现数据的确算错已经投诉了。
这样的例子中，可以得出几个结论：
这些问题最终导致了数据长时间不可用。这就是数据质量的问题
对于一个做数据开发的人来讲，遇见数据质量的问题（也就是算错了数据的问题）是经常性的。通常进行排查和数据恢复，都需要较长的时间，和较大的代价。在多次问题的复盘中，总结出以下规律：
想提升数据质量，最重要的就是 “早发现，早恢复”：
具体实施：
对于数据治理做到什么程度，很难衡量，最好的办法就是量化。
企业数据中台追求的是：高效，质量和成本。简单来说就是：快，准，省。所以能不能合理控制成本，也是决定数据中台项目成功与否的关键。
如果老板问你：
正常来说，数据中台的成本，是按照人力，物力，按照机器数量和电费来算的，又不是按照数据应用来算的，来自老板的这种灵魂拷问，还真是不好回答。但是一个公司的资源都是有限的，不可能无限增加，所以这些资源肯定都需要确保应用在公司的核心战略上产生价值。所以数据中台刚好又是一个高消耗支撑部门，所以如果想展现自己的价值，至少要做到两方面：
根据经验，可以总结优化的地方还是挺多，如果都做到位，可以节省一半资源。相信很多小伙伴已经基本中招。
数据服务主要解决的问题：
为了保障数据的查询速度，需要引入中间存储
不同中间存储提供的 API 接口不一致，导致使用复杂度提高。维护困难。
解决方案：提供统一的 API 接口，为开发者和应用者屏蔽不同的中间存储和底层数据源
为所有的数据应用提供统一的 API 接口服务
表现在：
数据服务实现了数据中台模型和数据应用的全链路打通，解决了任务异常影响分析和数据下线不知道影响哪些应用的难题；
基于相同主键的物理模型，可以构建逻辑模型，逻辑模型解决了数据复用的难题，提高了接口模型的发布效率；
今天是 数据中台课程的第一次课程，主要讲解的是：
总的来说，就是告诉你，数据中台怎么产生的，什么样的情况适合构建数据中台，如果你真的要构建数据中台，你得明白你需要做哪些工作以及可能遇到的问题。理论指导实践，学习前辈的优秀实践经验，指导我们的生产才能价值最大化。
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有