02 | 关键抉择： 到底什么样的企业应该建数据中台？

作者回复: 说到点子上了。 我就网易来举个例子，大家都知道，网易的业务涉及的领域非常的多，云音乐属于在线娱乐，有道是教育，严选、考拉（已经脱离网易）是电商，新闻属于传媒，我们有没有必要构建一个属于网易的数据中台？ 在我看来，没有这个必要，因为业务之间相差很大，重叠很少，需要跨业务进行分析的场景很少。毕竟跨业务线的中台构建，需要更大的投入和成本，这样收益和投入不成比例，也没这个必要。 我非常认可这位同学的观点， 不管是组织，还是数据中台，都是为了更好的支撑业务，如果业务线比较独立，那确实会存在多个面向不同业务线的多个数据中台。

作者回复: 你好，你这个问题问的很好，其实涉及到批流一体这个话题上了。 我先来回到你的第一个问题。实时数据因为聚合是基于一定的窗口计算的，所以数据会与离线批跑的数据结果有差异，一般一天前的，我们使用离线数据，当天的使用实时数据，离线数据修正实时数据。 第二个问题，离线数据和实时数据，如何做到数据只加工一次。 这就回到lamda和kappa架构之争上来了。Lamda 是批流分开的一种架构，也就是说，批算一遍，流在算一遍，批算的是T+1的，流算的是当日的。这个问题，最大的在于离线和实时的计算逻辑不一致，很容易出现问题。Kappa的架构是用流统一批，但是其实也存在问题，大数据量回跑和补数据，目前flink根本支撑不了，成本太高了。所以，对于绝大多数的企业，目前还是以lamda架构为准。 但是，最近我们也在探索这方面的东西，我们首先希望以流为主，但是同时流会导一份数据到HDFS上，方便进行回跑和补数据，在ods，dwd都以Kafka来存储，然后dws以 iceberg来存，因为iceberg支持upsert，不需要merge，所以可以直接提供实时的查询能力。 当然，目前不管是iceberg，还是同类的hudi，delta，都还不成熟，但是相信这个未来是一个趋势。后面如果我们这块有成熟的经验，我也可以分享给你。 感谢你的阅读，下次留言区再会~

作者回复: 你好，不是这么理解数据中台和数仓的关系的。 首先必须要明确的，你说的数仓，是指传统数据仓库，还是指基于Hadoop（一种数据湖实现）之上构建的数据仓库。 数据中台，首先是构建于数据湖（例如Hadoop）之上的，数据和Schema是可以分离的，数据不需要按照指定的Schema存储，而是在读取的时候，动态的映射的。这是数据中台跟传统数据仓库的最主要的区别。 那数据中台和基于Hadoop之上构建的数据仓库有什么区别呢？ 主要在于OneData和OneService。 数据仓库，并没有强制数据模型必须是复用的，在数据仓库的定义中，我们并没有发现数据仓库一定是要模型复用，指标口径统一的。此所谓OneData。另外，数据仓库并没有提数据必须通过服务化的方式提供给外部，此所谓OneService。这是数据中台和后者的本质区别。 不知道你理解了没有。希望我的回到对你有所帮助~

作者回复: 如果存在大量交集，业务中经常需要进行关联的分析，那建议还是考虑构建一个统一的中台。 在网易，云音乐、严选、传媒、有道因为业务相差很大，所以数据分析绝大多数的场景都在业务线内部，每个业务线构建一个数据中台，可以确保业务线内的数据高效运作。只有涉及到用户画像的部分，可能存在业务线之间的数据局部打通，此时，我们的做法是基于“小黑屋”的联邦学习模式，数据在小黑屋内是出不去的，可以确保数据的安全性，同时可以基于对方的数据加工一些标签，这些标签可以应用于本业务。这样在确保业务之间数据的安全前提下，可以基于其他业务的局部数据，加工一些人群标签属性，从而完善本业务的数据。

作者回复: 我觉得，你可能有个误区，就是认为数据中台可能一下就要建的很大，所以既认为数据中台确实很有必要，但是又担心投入太多。 其实呢，我认为数据中台不见得一下子要搞得很大，可以先从1-2个数据应用场景入手，从需求出发，然后随着接入的数据应用越来越多，中台越来越完善，我反对在脱离应用场景下，单独去构建中台，这样你的模型实际与业务是脱节的。这样既可以保障你是按照一个中台的模式去构建的，又可以避免一下搞得太大，存在比较大的风险，把落地风险降到最低。

作者回复: 我来谈谈我的看法哈。 说实话，我不是很认可“公司没有3-5年数据应用经验可以不考虑中台” 这个观点，或者说这个观点不是很准确。 我觉得判断要不要构建一个数据中台，本质上是有没有数据应用的场景，其实中台刚开始不需要构建的很大，但是你只要秉持中台数据共享和复用的理念，像滚雪球式的建设，随着应用不断壮大，中台覆盖的业务数据也越来越完善，所以我觉得不存在说3-5年这样一个数据应用的经验。 3-5年对很多公司来说，数据建设已经走了很多弯路了。如果直接按照中台的理念和方法论，秉着数据复用的目标去构建数据体系，可以少走很多弯路。在实践篇中，我也会重点来谈谈，如何实现数据中台的落地，欢迎你继续阅读，期待与你在留言区再次交流~

作者回复: 数据中台不见得一开始就要铺开一个很大的规模，可以像滚雪球式的，从小变大，先从一两个数据应用场景入手，然后数据覆盖更多的业务线，有更多的应用。 以我的经验，数据中台的投入分为两部分，一部分是人，一部分是系统以及物理机器。 机器加系统，我觉得在百万左右可以落地，一般开始也就8台机器的规模。人员的话，我认为有1-2个有经验的，再加上2个数据开发，可以完成1-2个数据应用场景的构建。时间周期上，大概半年左右时间。 获得的效果，从决策者来说，大部分还是从应用的角度，比如刚开始，我们可能会以报表作为切入点，做一些报表，然后能够有效的解决一些业务的问题，提高业务的运营效率。比如在零售行业中，我们可以做一些门店管理的报表，呈现出一些商品、用户相关的数据。哪些商品比较受到客户的青睐，应该推荐客户购买。一般可以看数据被多少人看，有没有解决业务问题作为落地效果。 对于已经存在大量的数据应用，想解决研发效能、质量和成本问题的企业，这部分企业大部分都已经构建了自己的Hadoop集群，已经有了一些数据应用场景，甚至还很多，主要是当前遇到了实际问题。此时，需要借助中台解决这些问题，这时因为已经有较多的数据和应用，所以往往需要花费几百万的投入。效果的话，以效率、质量和成本来作为考核目标。比如，有的企业，会拿数据复用作为衡量指标，每复用一次，就认为节省了多少研发效能，多少资源。这些都可以作为衡量效果的一些指标。

作者回复: 数据安全我认为是数据中台构建的基础，没有安全做保证，中台的复用无从谈起，所以我会在第10节内容中讲数据安全保障的五大机制： - 数据备份与恢复 - 回收站设计 - 精细化权限管理 - 操作审计 - 生产和测试集群隔离 到时候呢，你就可以深入了解数据中台数据是如何实现安全保障的啦！感谢你的阅读，欢迎继续交流~

作者回复: 指标管理部分，我会在第五节中详细的介绍，我们会有一个供使用数据的人和数据开发查阅的指标系统，可以满足你指标展示的需求。 维度部分，我会在第六节模型设计中具体介绍。公共维度的设计，可以帮助我们更好的分析指标，建立指标统一的可分析维度，对于拆分派生指标和原子指标有很大的帮助。

作者回复: 关于数据服务的具体细节，我们会在第九节中详细讲解。 1. 数据服务，我们采用的是云原生的设计，首先API 节点会进行弹性的伸缩。其次会不会导致后端数据库受影响，这个要配合限流的功能。 2. 数据服务主要还是面向在线查询访问的，至于大的文件，我建议还是用数据传输的方式，往外导数据吧。 3. 这个管控涉及的点很多，比如权限、流控、全链路打通，具体细节，欢迎关注第九节，我们再好好讲。