03 | 数据中台建设三板斧：方法论、组织和技术
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
数据中台建设需要综合考虑方法论、组织和技术三个方面。在方法论方面，阿里巴巴提出了OneData和OneService的核心方法论，强调数据只加工一次，实现数据的统一管理和复用，以及数据通过API接口的方式被访问，实现数据的服务化。在组织方面，数据中台需要统一的组织架构来管理数据，消除跨部门的小数仓，实现数据的复用。技术方面，数据中台需要支撑技术来实现数据的统一管理和服务化，包括数据的规范标准、API接口访问、权限管理、逻辑模型和性能稳定性等方面。整体来看，数据中台建设需要综合考虑方法论、组织和技术三个方面，以实现数据的统一管理和服务化，提高数据的共享能力和资产价值。文章还介绍了数据中台的支撑技术体系、组织架构和建设的三板斧，强调了数据中台的建设需要结合落地场景，具有实际应用的价值。
《数据中台实战课》，新⼈⾸单¥59
全部留言(50)
- 最新
- 精选
Kery在传统企业落地数据中台，面临一个很大的挑战是：领导有强烈诉求要做数字化转型，但是具体的执行业务部门基本没有什么数据运营思维，提不出有价值的业务数据问题？像这种情况如何开始数据中台建设？建设好好初步数据中台产品以后，如何运营数据中台业务价值，如何让数据价值落地传统企业？不知老郭后续如何看待这些问题？是否有相关经验分享。谢谢！作者回复: 我来谈谈我的看法。 依靠业务部门去提数据需求，我觉得你还是想多了，也不太现实，就像你说的，他们根本都没有数据运营的思维，又怎么能给你提数据问题呢？ 这让我想起了我们做数据产品时候的做法， 首先我们的数据产品要深入业务，与业务部门的老大对齐目标。例如在电商业务中，我们跟业务部门的BU老大，对齐，今年的目标主要是两个，一个是要提高爆品产出，一方面降低库存，一方面可以吸粉。另外一个就是要控制毛利。 了解了这个目标以后，我们首先就是要让这个目标可以量化，比如对于爆品的产出，我们需要基于动销率去分析，然后就是持续的跟踪，哪些商品品类动销率比较差，需要提高，哪些商品是0动销，对于0动销的商品，数据产品要进一步分析原因，比如是价格的因素？还是因为商品质量有问题？还是因为商品季节性因素？ 然后给出决策建议，比如下架商品，对商品曝光进行限流，调整商品的价格策略等等，最后，数据产品会自动把这些决策建议推送给业务系统进行执行。 从上面这个案例中，你看到，业务部门不可能给你明确的他们要什么数据，他能给你的是他的业务目标是什么。而数据应用团队，要做的就是对业务目标进行量化，持续跟踪，对于异常要进行诊断分析，给出优化建议，最后一键执行。这个过程最终以数据产品的方式呈现给业务，帮助业务实现数据驱动目标。 在第11节中，我会详细介绍数据应用，相信会对你有帮助。 感谢你的阅读，欢迎你继续跟我交流~
2020-04-06673
Terry郑💫老师您好，我司在探索数据中台的道路上遇到一个问题，就是数据质量不高的问题。 数据质量不高的情况下，很难在数据中挖掘有利价值做数据决策。 在提高数据校验规则以后，各个干系方会想办法做斗争。道高一尺的感觉。 请问如何去从一个角度对数据质量进行切入呢？作者回复: 我们保证数据问题，做到早发现，早恢复，是依赖数据血缘+稽核监控实现的全链路监控机制，话句话说，如果你加的稽核规则不够多，就可能发现不了问题。那如何来保证稽核规则的完备性的呢？ 首先，对于数据中台核心表，数据架构师、主题域的负责人以及对应表的负责人会逐个review 每个表的稽核规则是否完备。 其次，表负责人是表数据质量的第一责任人，我们会对表的数据质量问题进行持续监控，尤其是对下游产生问题的事故进行定责，所以作为第一责任人，他们有动力去完善表的稽核规则。 最后， 稽核规则不可能做到100%的覆盖，只能保证，翻过的错误不要再犯就，所以对于每次事故，我们都会组织复盘，其中重要的一项内容就是补充相关的稽核规则。 通过上述三项措施，可以大幅降低数据质量产生的事故，我可以负责任的说，数据质量不可能说做到100%不出问题，但是可以做到问题不断收敛，犯过的错误不要再犯，这对数据质量来说，已经是极大的改善了。
2020-04-07223- Sandflass老师，课程学完了，我想请问一下业务中台、技术中台、AI中台、财务中台这些概念为什么会被独立提出来呢？他们跟数据中台有什么区别跟关联呢？是数据中台的各个小模块还是独立的中台？他们相互之间的架构又是怎样的呢？各个中台的方法论是通用的吗？非常希望老师能答疑解惑，谢谢。
作者回复: 中台思想的核心，就是复用和共享，目的是提效，打通孤岛。所以我总结的中台，要包括三个内涵，共享、服务和连接。你可以去观察一下，基本上xxx中台，都是满足这三个条件的，这是中台的核。 至于他们之间的区别，他们是在某个领域下，某种共性能力的抽象。数据中台，是数据能力的复用，AI中台，是算法能力的复用，业务中台，是某个服务模块的复用。 他们之间的联系，一般来说，AI中台是建立在数据中台之上的，因为AI离不开数据中台提供的数据服务。
2020-05-2714 
CayChan老师您好，我们公司目前打算搭建一个订单数据仓储，收集诉求时，应用方希望数据仓储能够尽量实时并且与在线数据一致，能够产出准确的财务数据，甚至可以从离线仓储中拉数据到hive中(目前从在线MySQL中拉数据)。请问这种需求是否合理？怎么做才能让离线仓储中的数据实时且准确?作者回复: 你好，你的场景可以通过构建实时数据中台来解决这个问题。 在实时数据中台中，数据会以kafka流的方式存在，计算引擎使用flink。实时数据中台建设的方法论与离线数据中台并没有区别，也是要按照主题域、分层的建设。实时数据中台中的数据，在dwd层会归档一份到hdfs，在hdfs上的数据，可以通过hive进行批量的分析。 kafka中的实时数据，也可以写到kudu中，然后上层接Impala进行实时的olap查询。当然，汇总层kudu中的数据，也可以导出到DB，然后对接数据产品，进行在线数据的查询。 感谢你的留言，期待与你在留言区下次互动~
2020-04-0914
iMARS请请教一下老师，之前的BI系统和现在谈的大数据中台有何联系和区别？两者都是为了经营决策提供数据支撑的产品。是不是BI发展的下一阶段就是数据中台？另外数据中台感觉很难做成一个产品放之四海而皆准，反而是要by项目或客户的方式进行，才能正确落地。作者回复: BI 是数据应用，位于数据中台之上，数据中台构建的目的之一，就是支撑好BI场景。当然还有风控、推荐等其他的场景。 我觉得BI 和数据中台不在同一个层次，所以说数据中台是BI的下一站，不是很准确。数据中台不能说是一个产品，他是企业构建的统一、标准、共享、安全的数据服务，它包含了企业的数据，当然它的支撑技术和方法论是可以通过产品来承载的，但是数据中台本身，不能说是产品。
2020-04-089- Geek_0168a2老师您好， 我从2018年开始从事数据中台的数据服务研发工作，尤其是数据多维分析这里，我们提供统一的指标和维度，业务人员可以自助选择，查询报表数据。目前遇见的最大的问题是数据决策时间长，查询引擎慢，数据缓存命中率低。业务数据查询经常遇到加载慢，同时业务大量查询有造成了生产集群压力大，干扰了正常数据生产。 不知道网易 哪里 在数据服务层面，如何做的呢？ 我们的查询引擎是Presto, clickHouse。
作者回复: 你好，你说的问题，可能是日常数据平台遇到最多的问题之一，经常用户自己搞了一个大查询，然后把队列堵死了，然后影响了其他的任务或者人，一堆人在群里喊。 我的建议： 第一个，尽量避免查询明细数据，要通过分析用户的日常查询，倒逼公共集市层的建设，尽量把查询往汇总层赶。 第二个，当然，有一些查询，确实就要查明细数据，那其实我们可以根据元数据，先预估一下这个查询的成本，如果查询的扫描记录数，消耗内存，大于某个阈值，是需要经过审批流程才能查询的，同时要区分一下大查询和普通查询的队列，避免大查询杜塞普通查询。当然线上任务和查询本身也要分队列，不可能在同一个队列里面。 第三个， MPP 的队列只能隔离计算资源，内存资源，但是很多时候，存储也会存在相互干扰的情况，所以如果IO 负载很高，导致调度任务和adhoc查询相互影响的话，建议存储也独立。 我们的MPP查询引擎走的impala，但是原理上也差不多的。
2020-09-128 
王芳第3讲我反复在2周内看了3遍，结合已有的数据中台建设经历感觉郭老师所说的3要素缺一不可（尤其是组织结构是基础和前提）总结的非常精准。如果上层领导看似支持中台建设，但在组织层面又没有相应的调整支持，该怎么获取上层支持比较好呢？另外，我个人觉得中台建设是一个长期利益和短期利益平衡的问题，当下市场、内部业务需求变化快，相关数据应用部门更专注于自己的应用产品建设，目前就是项目制的建设，怎样才能做到数据中台的建设不脱离业务、并逐步深入业务呢？作者回复: HI，王芳，你好，如果上层领导看似支持中台，但在组织层面又没有相应的调整，这样负责推进中台的部门就会比较费力，但是并不是说完全不行。我们在网易构建电商数据中台时，也不是说，直接把业务部门的数据开发和分析师全部归入中台，而是通过调整职责和建立共同KPI的方式，引导他们，大家一起完成数据中台的建设。 比如，数据中台要接管ODS层的贴源数据，同时要跟业务部门制订数据中台建设的KPI，要确保业务部门使用数据中台产出的公共数据进行加工。 你提的第二个问题，我觉得特别好，确实，这是一个平衡的问题，首先，我们不可能停下来，把中台建设好，然后再建应用，所以一定会存在业务需求和中台建设的平衡问题，这也确实是一个短期利益和长期利益平衡的问题。我觉得，中台建设，要深入业务，就得跟业务的KPI绑定，能够更快的响应业务的需求，把业务的痛点当成自己的KPI来解决，KPI 对齐是很重要的，所以我在第13讲中也重点讲了数据中台的KPI构成问题。 感谢你的提问，我们一起努力把德邦的数据中台做好！
2020-05-1028- Samlam老师你好。请问用户主题域应该如何设计呢？如何整合不同业务来源的用户数据呢？
作者回复: 你这里面有两个问题。 对于第一个问题，主题域的设计，其实与你所在的企业从事的业务过程密切相关的，你可以理解为它就是业务过程的一个抽象。比如，在物流行业中，会有门店、中转、车队等等，在电商行业中，交易、用户、商品、售后等等，在云音乐中，互动、内容、交易、市场、风控等等。要梳理主题域，你可以先把业务过程中，按照行为事件的方式梳理一下，看看包括哪些业务过程。另外也可以参考一下业务相近的行业对于主题域的划分。还要再说明一下，主题域划分并没有对错，尽可能的覆盖更多表，是主题域划分的一个目标。 如何整合不同业务来源的用户数据。用户在业务中，一般是以维度的方式存在，对于单个业务，需要构建一个统一的用户维表。但是如果涉及多个业务，多个业务用户数据的整合，其实核心技术是id-mapping。 ID-Mapping要解决的核心问题是把相同的用户，在不同应用系统上登录识别成同一个实体，即使是在同一个应用内，同一个人也可能有多重身份，比如未登录和登陆后，可能是两个标识。如何整合这些数据呢，我们把账号和设备的关联关系作为基础，每一个账号在某个设备登录一次，就算一个联系，然后对数据按照权重进行聚类，这个权重就是登录次数，时间等。然后就可以把同一个设备不同应用，不同设备的相同账号关联起来，识别为同一个实体，这样就实现了不同业务来源数据的整合。
2020-04-068 
牧海老师好，可以阐述再具体一点吗？数据中台的组织架构里都有哪些角色?比如大数据研发工程师之类的作者回复: 数据中台的组织架构中，包括数据产品PD，数据开发（也就是你所指的大数据开发工程师），平台开发（Java服务端开发）,分析师，四类角色。 数据产品PD，主要职责是负责做数据产品。分析师主要职责是基于数据，帮助业务实现业绩目标，在数据中台建设中，分析师一般会负责指标口径制订。数据开发，主要是做ETL任务。平台开发，主要职责有两个，一个是大数据相关的工具开发，一个是数据应用的开发。
2020-05-2626
技术修行者
问题：如果不考虑业务需求，单纯从技术角度出发，去管理多个异构的数据源，包括结构化数据以及非结构化数据，并按照统一的API接口对外提供数据访问服务（增删改查以及事务处理），有什么推荐的技术实现吗？作者回复: 结构化的数据源，比如DB，非结构化的数据源，比如Redis，HBase，最好的实现方案，就是对非结构化的数据源也需要定义Schema，然后基于数据服务，在数据服务上对外提供Restful API，然后对内访问各种异构的数据源。 当然，如果涉及到不同数据源之间的关联，会有一些限制，比如对于HBase，只能基于rowkey去做关联。 感谢你的提问~
2020-05-175
