真的有落地的数据中台么？

《数据中台实战课》学习笔记 01，题图来自网络

开篇词  | 数据中台，是陷阱？还是金钥匙？

之前看过极客时间的《说透中台》，可惜没有机会实践；最近在写一篇有关知识图谱+数据中台的稿子，所以发现了这个宝藏课程。

原理篇、实现篇、实践篇，基本上已经可以覆盖我所需要了解的全部内容。

另外，其实在留言回复中也有不少闪光的内容：

数据中台构建企业共享的数据公共层，打通企业的数据孤岛，提高企业数据的研发和使用效率。

数据中台要实现的是公共计算逻辑的下沉。

数据中台只能提供高质量、高效率、低成本的数据……数据必须转化为决策，才能应用于业务。

业务系统的数据，由通过数据中台的数据传输工具，数据汇聚到数据中台，数据中台把各个业务系统的数据汇聚，加工，通过服务化的方式最终提供给数据产品。

企业只有通过数据产品，才能实现从数据到业务的打通；数据产品要实现的是从数据到决策的转化，然后将决策推送给业务系统，由业务系统来执行。

数据产品+数据中台，称之为数据生产力，目的是让业务更智能，运行效率更高！

数据中台继承了数据仓库维度建模的设计方法。

01 | 前因后果：为什么说数据中台是大数据的下一站？

数字化转型必须搭建数据中台么？

这篇专栏文章对于数据仓库、数据湖、大数据平台和数据中台的发展历史讲的非常清楚，我有一点疑惑的地方在于，如果在早期数据仓库和数据湖阶段并没有做好，那么直接做数据中台，会遇到不可跨越的障碍么？

数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的，不可修改的数据集合。

以前没有注意到数据仓库两种不同的建模方法，以前接触比较多的是恩门的自顶向下的方式，基于业务中各个实体以及实体之间的关系建模；而金博尔 Kimball 的自底向上的模型设计方法，一开始看的时候，感觉比较违反直觉，但是仔细考虑一下，数据的耦合性更好，更适合大量数据的分析，也就能理解为什么说是“从数据分析的需求出发，拆分维度和事实”。