在公司主要做API 管理平台的相关产品，最近需要跟数据中台的相关产品做对接，因为好奇，也去简单了解了一下数据中台的相关知识和内容。虽然数据中台比较倾向大数据产品的开发方向，但是作为一名工程师，还是要广涉猎。这本笔记主要是学习了 极客时间 郭忆老师的 《数据中台实战课》的相关内容记录。
为什么要建数据中台，数据中台的核心是什么？
2016 年，阿里巴巴率先提出了“数据中台”的口号。因此很多互联网企业和传统企业都在建设数据中台，那么为什么企业选择建立数据中台呢？我做了以下几点总结。
- 过去的企业数据系统距离用户和业务比较远，在数据方面的投资，大量花费在数据采集、处理和建模部分，而真正利用到业务领域的不多。
- 数据需求的爆发式增长，企业需要在大量的数据中获取想要的东西，但是现在的数据产品指标不一致，数据重复建设，数据质量差等问题层出。
- 企业存在较多的业务数据的孤岛，需要整合各个业务系统的数据，进行关联的分析。
- 面临效率、质量和成本问题，需要借助数据提高企业经营效率。
数据中台的价值，那就是改变原来企业利用数据的形式。数据中台的核心，是避免数据的重复计算，通过数据服务化，提高数据的共享能力，赋能数据应用。
数据中台建设方法论
早在 2016 年，阿里巴巴就提出了数据中台建设的核心方法论：OneData 和OneService。
- OneData:
- 分主题域管理：比如供应链，售后，商品等主题域
- 命名规范定义:表的名称中最好能够携带表的主题域、业务过程、分层以及分区信息。
- 指标一致
- 数据模型复用:实现模型的复用，数据中台适合采用分层的设计方式，常见的分层包括：ODS原始数据层，DWD 明细数据层，DWS 轻度汇总数据层，ADS/DM 应用数据层 / 数据集市层。
- 数据完善:
- OneService:数据即服务，强调数据中台中的数据应该是通过 API 接口的方式被访问。
- 数据网关：要实现包括权限、监控、流控、日志在内的一系列管控能力，哪个应用的哪个页面访问了哪个模型，要做到实时跟踪，如果有一些模型长时间没有被访问，应该予以下线。使用数据的每个应用都应该通过 accesskey 和 secretkey 实现身份认证和接口权限的管理。另外，访问日志可以方便在访问出现问题时，加快排查速度。（这个就比较像API管理平台）
- 逻辑模型:逻辑模型可以类比视图，它可以帮助应用开发者屏蔽底层的数据物理实现，实现相同粒度的数据构造一个逻辑模型，简化了数据接入的复杂度。
- 屏蔽异构数据源：数据服务必须要能够支撑类型丰富的查询引擎，满足不同场景下数据的查
询需求，常见的有 MySQL、HBase、Greenplum、Redis、Elasticsearch 等。 - 性能稳定:由于数据服务侵入到用户的访问链路，所以对服务的可用性和性能都有很高的要求，数据服务必须是无状态的，可以做到横向扩展。
数据中台支撑技术
大数据平台的底层是以 Hadoop 为代表的基础设施，分为计算、资源调度和存储。
Hive、Spark、Flink、Impala 提供了大数据计算引擎：
Hive、Spark 主要解决离线数据清洗、加工的场景，目前，Spark 用得越来越多，性能要比 Hive 高不少；
Flink 主要是解决实时计算的场景；
Impala 主要是解决交互式查询的场景。
计算引擎统一运行在一个称为 Yarn 的资源调度管理框架内，由 Yarn 来分配计算资源。目前最新的研究方向中也有基于 Kubernetes 实现资源调度的
数据存储在 HDFS、Kudu 和 HBase 系统内。HDFS 不可更新，主要存全量数据，HBase提供了一个可更新的 KV，主要存一些维度表Kudu 提供了实时更新的能力，一般用在实时数仓的构建场景中。
大数据平台像一条设备流水线，经过大数据平台的加工，原始数据变成了指标，出现在各个报表或者数据产品中。随着数据需求的快速增长，报表、指标、数据模型越来越多，找不到数据，数据不好用，数据需求响应速度慢等问题日益尖锐，成为阻塞数据产生价值的绊脚石。
数据治理模块。它对应的方法论就是 OneData体系。以元数据中心为基础，在统一了企业所有数据源的元数据基础上，提供了包括数据地图、数仓设计、数据质量、成本优化以及指标管理在内的 5 个产品，分别对应的就是数据发现、模型、质量、成本和指标的治理。
