中的语义层、数仓中的一致性事实；将分析中的指标进行规范化。标准维度：同标准指标，对分析的各维度定义实现规范化、标准化。不断的进行维护且与业务方进行沟通确认。2、技术元数据数据源元数据：例如：数据源的

Store，又称数据基础层）：将原始数据几乎无处理地存放在数据仓库系统中，结构上与源系统基本保持一致，是数据仓库的数据准备区。这一层的主要职责是将基础数据同步、存储。数据公共层（CDM，Common

数据新人的那些困惑大家好，我是云祁！今天刚好在晓阳老师的数据小站上看到了这篇文章，深有感触，想分享给大家！文中提及的几个点无一不是正中下怀，都是我曾经无数个“失眠的夜晚”为之苦恼和焦虑的。当然啦，现在的我很清楚地知道自己想要什么，努力做好“工具人”的角色之余，已经开始不断尝试和突破。从“不知道”——

导读：大数据、数据治理、数据湖、数据中台……连绵不绝的数据技术和热词让企业信息化部门疲于跟踪、构建和维护新的数据管理系统。都说“数据是石油”，是企业核心资产之一，那么有了这些数据管理系统，数据资产就成功实现“价值变现”了吗？显然不是！01

DataXJob启动后，会根据不同的源端切分策略，将Job切分成多个小的Task(子任务)，以便于并发执行。Task便是DataX作业的最小单元，每一个Task都会负责一部分数据的同步工作。

模型设计数据模型的维度设计主要还是以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实。关于维度表和事实表的设计思路，大家可以参考

数据看板的搭建思路|0x00

MID：数据集市层，它是面向主题组织数据的，通常是星状和雪花状数据，从数据粒度来讲，它是轻度汇总级别的数据，已经不存在明细的数据了，从广度来说，它包含了所有业务数量。从分析角度讲，大概就是近几年。

数据仓库建设灵魂10问我是「云祁」，一枚热爱技术、会写诗的大数据开发猿，欢迎大家关注呀！

看这一篇就够了！通透！数据仓库领域常见建模方法及实例演示橙心优选-数据仓库高级工程师面经关于构建与优化数据仓库架构与模型设计架构师

放到DelayedOperationPurgatory（延时管理器）中。假如在30秒之前如果所有follower都写入副本到本地磁盘了，那么这个任务就会被自动触发苏醒，就可以返回响应结果给客户端了，

搭建实时个性化营销平台？如何利用阿里云大数据产品建设数据中台？数据治理已成为数据中台的必争之地我是「云祁」，一枚热爱技术、会写诗的大数据开发猿，欢迎大家关注呀！

3）数据治理需要IT赋能：数据治理不是一堆规范文档的堆砌，而是需要将治理过程中所产生的的规范、流程、标准落地到IT平台上，在数据生产过程中通过前向的方式进行数据治理，避免事后稽核带来运维成本的增加。

ID中的核心技术ID-Mapping究竟是怎么实现的？爱奇艺数据中台建设方案.ppt我是「云祁」，一枚热爱技术、会写诗的大数据开发猿，欢迎大家关注呀！

或其他渠道获取用户的行为数据信息，进而推测用户的意愿，然后系统开始做预查询，把用户的相关信息放到缓存里，这样当用户在前端触发操作时，后端直接从缓存里调用数据开展计算，极大地提升了数据处理速度。在

提出对数据仓库维度建模，我们将数据仓库中的表划分为事实表、维度表两种类型。针对维度建模中事实表和维度表的设计，之前有详细介绍过，感兴趣的同学可以看：维度建模技术实践——深入事实表

大家好，我是云祁！今天给大家分享下爱奇艺数据中台建设时间方案，本文主要内容包含以下几部分：数据中台的产生：数据工作的痛点、数据中台的产生、中台的实质爱奇艺数据中台的定义：理解数据中台、数据中台的发展历程、输出和定位爱奇艺数据中台的建设：中台建设、Pingback体系、数仓体系、数仓平台、离线数仓架构、大数据平台、数据平台架构数据中台的应用场景：统一化、个性化、定制化一、数据中台的产生1、数据工作的痛点使用门槛高：数据工作是一个专业性特别强的一个工作，对于人员的要求比较高。口径不一致：在使用数据过程当中，口径不一致是特别常见的一种问题，这种问题可能会导致一种数据使用和分析的差异，而且会降低业务的数据分析效率。数据可靠性低：在生产过程中，降低业务的数据分析效率，最终会对业务决策造成严重的影响，不仅数据链路过程很长，其中还会引入很多数据质量问题。跨业务难度大：因为缺少一个统一的数据建设的规划、标准和规范，所以难以指导各个业务或者整个生产链路的各个环节，以拥有一个标准化的生产和处理过程，就导致了多个业务的数据难以融合，难以发挥更大的数据价值。接入成本高：如果有新的业务接入或者新的场景需要使用数据，很多工作都需要人工处理。去申请各种资源、权限、找数据并且串联整个数据的采集、生产、计算、同步和展示等各个环节，这是一个耗时长、效率低，最终还是很容易出错的过程。投递质量低：说到数据的话肯定离不开投递，投递是用来记录用户行为的一连串的数据信息。如果投递过程缺少标准化或者流程管控的话，都会导致投递质量比较差。获取数据难：数据的生产到最终使用，中间可能要经历一个比较长的时间周期或者一个比较宽的团队跨度，用户可能无法很快地找到想要的数据，或者数据团队生产出来的数据并没有真正触达到业务，来达到它的数据价值。数据资产模糊：这个点可能和获取数据难有一点点关联，数据资产模糊的话更多的是在说需要对公司的数据资产做一个整体的管理，如果没有这个整体的管理，就会导致对数据资产的级别和拥有什么数据资产都很模糊。最终就是导致数据的优势难以发挥出来，而且虽然耗费了很多计算资源、人力资源、存储资源，但没有带来相应的价值，最终导致资源效率极低。2、数据中台的实质数据中台更像一种企业架构，是一套结合互联网技术和行业特性，在企业发展的不确定性中，寻找确定性，并且持续沉淀和抽象企业核心能力，最终支持企业快速、高效、低成本进行业务创新和增强的企业架构。二、爱奇艺数据中台的定义1、理解数据中台数据后台：大家平时更多用到了大数据集群，也就是说Hadoop、Spark、Flink以及其他OLAP工具。但是这些只是数据后台的一个概念，并没有做成一个标准化、通用化、门槛相对来说比较低的中台化的概念。

前言这两天在脉脉上有一个帖子很火，主题居然是讨论数据建模的，太令我诧异了！这个时候脉脉上不应该都是在炫耀年终奖和新Offer么？这个帖子是一位百度的同学在吐槽，为啥阿里的《大数据之路》讲的好像很牛，但是为什么跟我们实际工作中的情况不一样啊？“你们数据建模真的搞的那么牛*么？”接需求、拉数据、做宽表、对数、跑批、找bug、重跑...这就是大多数大数据工程师的工作日常，说好的建模呢？为什么我每天就是在建宽表？书在说谎？这个哥们的疑问，其实很有意思。脉脉上吵成一团，但都没说到真正的点上。下面有个哥们说，写数据建模的内容，理论来源就是二位老爷子，避免不了要抄一些内容。说的好像有点道理。但是你有没有想过这个问题，就是为什么这位同学会问这个问题？因为他从书上看到的，跟他实际工作不一样。那为什么书上和工作中不一样？是书上说谎了吗？书上不是说要反规范化维度、缓慢变化维、快照维表么？为啥我工作上都没用到呢？那些极限存储的拉链表呢？还有代理键呢？你们阿里就那么牛，建模都建出花儿了，就我在这里天天拉宽表？唉，想知道这个问题的答案，咱还得翻翻旧账，说说数据仓库的超级痛点。数仓的弱点Inmon提出数据仓库构想的前几年，数仓项目建设成功概率有多少呢？80%以上，全部失败！是不是有点像最近两年的“数据中台”？为啥？当时数仓界的几位大佬也在研究。经过Inmon、Kimball一堆大佬的研究，以及对企业失败经验的总结，最后得出这么个结论：就是如果按照Inmon老爷子的逻辑，从上到下去搞全面建设，实施周期往往非常长，往往要1-2年以上。等实施完，很可能当时提需求的人都不知道当时自己想干啥了。因此，Kimball老爷子基于多年咨询项目的经验，提出了缩小建设范围，提高成功率的方法。也就是现在常说的，自下而上的Kimball建设模式。当然，全面建设的方法同样在发展，各大厂商针对不同的行业，输出了N个标准模型，比如Teradata的FSLDM、IBM的BDWM、IAA、IIW、Sybase的IWS等等。都是行业标杆，能直接推到逻辑建模的后半部分。Inmon老爷子后来也跟Kimball一众大佬一起优化，并最终提出了CIF企业信息工厂的概念。顺便八卦一句：Inmon和Kimball两位大佬并不是网上传闻完全割裂的，CIF里还致谢过Kimball，并且Kimball也否认有绝对的自上而下和自下而上的建设方法，都是结合着来的。但即便是这样，数仓建设周期和业务需求即时性之间的GAP，仍然是一个弱点。在以前，这个弱点还好，因为大家的业务变化的还是比较符合预期的，又有Kimball的缩小建设范围的法子，也有行业标准LDM，建设成功率就非常快了。但是！现在！大清都亡了啊~~~！你看看我们现在的市场环境，你用啥能满足那些不给数据就坐在你旁边的运营同学们！！！你用啥办法能搞定一个月变一次的业务方向？？？请Inmon、Kimball大爷过来也做不到啊！我分别为传统企业和互联网企业做过KPI考核体系。在传统企业，基本上是一次设计，然后基本上就不用管了，因为绩效考核政策基本上一年才会换一次。但是在互联网公司，我就炸了！他们的绩效是一个月发布一次！！！所以，数仓建设周期这个曾经让数仓项目大面积失败的弱点，在互联网时代，再次被无限放大，成为致命的弱点。快速变化的业务，让我们根本没时间建模！互联网数仓当运营、产品同学坐在你旁边，看着你干活，你是啥感觉？我不知道你是什么感受。反正有人在背后，我会立刻启动原始的危险生理报警。如果一直在旁，那感觉，如锋芒在背，如鲠在喉！恨不得立刻离开这个地方，还需要压制住一股揍扁他的冲动。所以，为了送走这尊瘟神，我们只能是直接给他拖一张宽表啊！我们再把场景放大一些，我们数仓组，对于数据分析师、运营、产品同学的迫切需求，我们会怎么对待？这边业务推进会上，好一些的，会把数仓的同学叫过去。不好的，直接扔给你一个需求，项目下周上线，数据也要同步上线。更恶劣的，项目都上线了，再过来跟你说需求。你就说怎么弄？？？一方面，新业务根本没有通用的模型。另一方面，根本没足够的时间。你再牛，建模手段再牛，你总得先梳理业务流程吧？但是新业务，业务流程可能都没人能给你说清楚。好，你业务捋顺了，你是不是要看看数据？但是新业务，连数据都没有啊！而且，还有一堆的新功能在设计呢，表都没有，你咋建模？纵使你有72般变化，千般手段，万般才能，也只能见招拆招，还是丢一个宽表给他，赶紧让他走吧！所以导致现在互联网团队招人，比较少的找小半年没产出的数据建模师，而是去选择偏向能立刻出活儿，解决任务、调度、优化等问题的大数据工程师。书到底有没有说谎？是的，不可否认，拉宽表就是现如今数仓、大数据工程师的日常。但是同学，你忘记了一个很重要的因素了。这就是历史。可能有些新入行的人不知道，阿里巴巴当年把Teradata、Oracle、东南融通等国内外做数仓、数据治理的公司都挖了一个遍，组建了全国最牛的数据团队。按照当时对数据的respect

星标或置顶一起成长我是「云祁」，一枚热爱技术、会写诗的大数据开发猿，欢迎大家关注呀！

接口，用户可自由组合搭配一种或若干种嵌套查询条件，可查询若干简单字段或者聚合字段，可分页或者全量取回数据。典型场景包括：用户圈选（组合若干用户标签筛选出一批用户）。Union

同时，面对不同的对象，应该设计不同的数据模型。比如，和业务用户沟通时应该设计比较易于理解的模型（图1）。模型开发工程师真正在系统中实现的应该是更加抽象的模型（图2）。

也是有用的；2、各自抽象和组装成“点”和“边”的数据集，设置边阈值，过滤弱连接；3、构建一个图模型，用连通子图算法求得那些ID标识属于同一个对象；4、得到结果集，分配一个新的

在1月1日这个分区中存储t1和t2两条记录，在1月2日这个分区中存储更新后的t1以及t2、t3记录。对于小数据量的缓慢变化维度数据，例如商品类目，可直接使用全量存储。拉链存储

依业务规则性别只有"0:男"，"1:女"，则性别字段只应出现0或1。例2

第二阶段：lambda架构随着数据处理能力和处理需求的不断变化，越来越多的用户发现，批处理模式无论如何提升性能，也无法满足一些实时性要求高的处理场景，流式计算引擎应运而生，例如Storm、Spark

Rowkey设计和实现全网最通俗易懂的HBase架构及原理HBase入门为什么可以这么简单？🧐分享、点赞、在看，给个三连击呗！👇

大家好，我是云祁！偶然间看到知乎上这篇关于OLAP的深度解读，从技术发展，产品选型，执行优化等方面做了详细的剖析，分享来给大家看看！全文10000字，读完需要30分钟！我也觉得有点长，要不先收藏？文

开发，产品化构建交互式分析场景替代集市主题表建设。数据开发从业者的3个核心能力前面讲了数据开发技术的三个方向：1）流批一体成为主流开发模式，2）代码自动化技术走向成熟，3）OLAP

"3"。”因此我们设计RowKey时，需要充分利用排序存储这个特性，将经常一起读取的行存储放到一起，要避免做全表扫描，因为效率特别低。三、什么是数据热点？3.1

宕机一段时间是可以忍受的。5、HRegiontable在行的方向上分隔为多个Region。Region是HBase中分布式存储和负载均衡的最小单元，即不同的region可以分别在不同的Region

保证，用于数据存储和维护有关问题的解决方案，但是受制于越来越多的业务系统需要能适应不同种类的数据格式和数据源，经常是非结构化的或者半结构化的（如用户访问网站的日志)，并且又是高几个数量级的数据（

大家好，我是云祁！这两天又翻出了《大数据之路：阿里巴巴大数据实践》，重新读了数据建模那部分的内容，依旧感觉受益良多，遂整理了笔记分享给大家。数据建模数据建模在这本书占据了三分之一篇幅，可见其重要性！9.1

生活生活依然平淡，N次搪塞了家里人的相亲，虽然有时会因为头发脱的有点快而隐隐有些焦虑，呵，照镜子果然发现比年初发量少了好多！安慰自己“来日方长”的时候，似乎也没那么心安理得了。偶尔也会心里默念

一、状态一致性当在分布式系统中引入状态时，自然也引入了一致性问题。一致性实际上是"正确性级别"的另一种说法，也就是说在成功处理故障并恢复之后得到的结果，与没有发生任何故障时得到的结果相比，前者到底有多正确？举例来说，假设要对最近一小时登录的用户计数。在系统经历故障之后，计数结果是多少？如果有偏差，是有漏掉的计数还是重复计数？有状态的流处理，内部每个算子任务都可以有自己的状态对于流处理内部来说，所谓的状态一致性，其实就是我们所说的计算结果保证准确。一条数据不应该丢失，也不应该重复计算在遇到故障时可以恢复状态，恢复以后的重新计算，结果应该也是完全正确的。1.1

简介：本次分享介绍客如云如何利用阿里云大数据产品来建设数据中台。客如云是2012年成立的一家公司，覆盖餐饮、零售、美业，还有其他的业态以及服务的一家综合性的SaaS公司。到2020年为止，客如云已经服务了60万商家，帮助60万商家实现了数字化、智能化的改造，接下来我们会覆盖更多的商家。客如云技术总监

数据的重要性和战略意义毋庸置疑，目前业界也都在热火朝天地将大数据战略落地和用于实战。在这个过程中，我们首要的问题就是数据平台的搭建，主要包括物理和逻辑两个方面：物理数据平台的搭建包括

大家好，我是云祁！前面我们聊过了维度建模的灵魂所在——维度表设计，今天就深入学习下维度建模的核心——事实表。聊聊维度建模的灵魂所在——维度表设计事实表是维度建模的核心表和基本表。它存储了业务过程中的各种度量和事实，而这些度量和事实正是下游数据使用人员所要关心和分析的对象。目前事实表主要探讨三种：事务事实表快照事实表累计快照事实表还有一种特殊的事实表——无事实的事实表，最后还将讨论事实表的聚集和汇总。事务事实表事务事实表是维度建模事实表中最为常见、使用最为广泛的事实表。事务事实表通常用于记录业务过程的事件，而且是原子粒度的事件。事务事实表中的数据在事务事件发生之后，数据的粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插入，数据就不再进行更改。我们通过事务事实表存储单次业务事件

关于数据质量，你还想了解什么？欢迎留言区与大家分享觉得不错，请把这篇文章分享给你的朋友哦入群请联系小助手：iom1128『紫霞仙子』更多精彩，请戳"阅读原文"到"数仓之路"查看

大家好，我是云祁！今天和大家分享一篇关于数据中台的文章，作者柯根老师是数据中台交付方面的专家，大家不妨一起看看吧~从整体上看，数据中台体系架构可分为：数据采集层、数据计算层、数据服务层

来过滤条件，这个过滤条件定义事件需要符合的条件，例如:.where(_.eventType.equals("fail"))我们也可以通过

前言大家好，我是云祁！今天和大家聊聊数据仓库中维度表设计的那些事。维度表是维度建模的灵魂所在，在维度表设计中碰到的问题（比如维度变化、维度层次、维度一致性、维度整合和拆分等）都会直接关系到维度建模的好坏，因此良好的维表设计就显得至关重要，今天就让我们就一起来探究下关于维表设计的相关概念和一些技术。维度变化维度表的数据通常来自于前台业务系统，比如商品维度表可能来自于

以手机号为例，手机号的前缀变化比较少（如152、185等），但后半部分变化很多。如果将它反转过来，可以有效地避免热点。不过其缺点就是失去了有序性。反转时间

是限定大小的有始有终的数据集合，即有限数据流，二者的区别在于无限数据流的数据会随时间的推演而持续增加，计算持续进行且不存在结束的状态，相对的有限数据流数据大小固定，计算最终会完成并处于结束的状态。在

dashboard）也正在被越来越多的企业采用，用来及时呈现关键的数据指标。并且在实际操作中，肯定也不会仅仅计算一两个维度。由于Flink的“真·流式计算”这一特点，它比Spark

如果项链上有很多珠子，你显然不想从头再数一遍，尤其是当三人的速度不一样却又试图合作的时候，更是如此(比如想记录前一分钟三人一共数了多少颗珠子，回想一下一分钟滚动窗口)。于是，你想了一个更好的办法:

选取业务过程业务过程即企业和组织的业务活动，它们一般都有相应的源头业务系统支持。对于一个超市来说，其最基本的业务活动就是用户收银台付款；对于一个保险公司来说，最基本的业务活动是理赔和保单等

数据模型如何论好坏|0x00

大家好，我是云祁！今天和大家分享的是阿里云数据中台的一篇文章，全文从几个常见概念入手，介绍模型设计与它们之间的关系，列举了当前企业模型设计的建设方法，并重点介绍“维度建模”。1与几个概念的关系操作型业务系统对于这个概念大家都不陌生。企业业务赖以运转的交易系统就属于操作型业务系统。因此它是为了保障业务正常运转，能够更快的处理事务。但是因为它是针对某一特定的意图（例如满足交易业务），它不需要承诺与其他业务系统共享公共数据。因此就出现了适合于企业中交叉应用的ERP、主数据系统。当然对于有建设业务中台的企业来说，基于微服务架构的各个服务中心，能更好的提供可复用统一的公共数据。不管是面向业务的业务系统、经过数据统一后的主数据系统或者基于微服务架构的服务中心的数据，都是作为数据中台的数据输入源头。我们通过批量同步、归档日志采集等方式，能将数据采集进数据中台，作为ODS层原始数据的一部分。ETL英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。在ODS层的原始数据，需要通过加工处理后，才能进入到构建好的数据模型中。在模型设计时，需要考虑ETL加工流程，根据逻辑判断，做模型的合理设计。同样对于下游使用数据模型的ETL元数据，也是作为模型设计的输入，可基于下游应用方式做模型的横向和纵向的拆分设计，这就是“元数据驱动模型设计”的理论来源。因此，无法理解数据开发的模型设计师是不合格的。数据应用数据中台提供多种数据应用的形式，包括数据报表、智能数据产品等。将统一汇总加工后的数据或者明细原子数据提供给数据应用，为业务提供数据支撑。更加合理的数据模型设计，能够给更宽泛的应用提供数据支撑，也能够让业务方更准确无疑义的使用好数据。2几种企业常见的建设现状烟囱式也许大家都不愿意承认，但是绝大部分的企业当前是没有统一、标准、公共、全局的模型设计的，而仅仅是把数据同步上来，然后基于业务需求做烟囱式的数据开发。这种方式也许从短期来看是效率最高的，但是从长期看，不仅仅造成计算存储资源的极大浪费、没有统一可用的数据、大量的重复性的工作。企业的数据就像一团乱麻，根本无法管理。三范式+数据集市一些传统大型企业，由于历史原因，原子数仓中以三范式的模型设计方式构建，在各个应用的数据集市中以维度建模方式构建。通过这种方式，在原子数据设计过程中，需要投入较大的资源。对于业务来说，三范式模型太复杂，用户难以理解和检索。并且对于业务频繁变化的企业，模型的维护成本极高。企业级维度模型基于企业全局的角度去构建业务总线矩阵，在此基础上完成维度模型的设计，是当前众多企业选择的方向。从众多互联网企业的数据中台实践经验来看，这也是一个绝佳的各因素平衡后的选择。后面，我们将从各个角度来思考如何基于维度模型构建企业级数据中台。3维度建模初探优势在数据中台建设经验中，企业级维度模型设计从理解性、扩展性、高性能上都是更适应当前的技术和业务环境的。首先由于计算和存储成本逐步下降，模型更重要的变成了易于理解，当易用性放在模型设计的重要位置时，维度模型可理解的优势就显现出来了，维度建模一直就是以业务的视角来描述数据。另外，当新的业务出现时，新的模型不会对已有模型形成冲击，可以无影响的产出新的模型数据。维度建模会设计部分数据的冗余，通过冗余换来数据检索的高性能。对于数据量极具膨胀的今天，高性能给用户带来了高价值。事实表所谓的事实表，就是企业的业务过程事件的度量信息。例如对于支付这个业务过程来说，需要度量支付的商品数、金额等度量。因此，企业的业务过程数据以事实表的形式在模型中呈现出来。事实表每行都对应了一个度量事件，每行数据是一个特定级别的细节数据。事实表中每个度量都必须是相同的粒度级别。事实表中的度量的可加性也至关重要，因为业务方往往需要将事实表的数据基于某些维度进行汇总，在度量上需要能够做汇总累加。事实表还是稀疏的，它仅仅会将发生的业务过程数据放入其中。维度表维度表是事实表不可或缺的组成成分，它描述了事实表业务过程度量的环境。用于描述“谁、什么、哪里、何时、如何、为什么”有关的事件。维度属性是作为查询约束、分组、标识的主要来源，因此它的好坏直接决定了数据的可分析性的差异。维度属性需要是可理解的，因此需要尽量避免“0,1”之类的代码，将代码翻译成更易理解的字符避免业务的误解。同样，会有一些数值型的可作为维度属性。例如：也许有人会问商品标价适合在事实表还是维度表中？当用于计算度量时，它应该存在于事实表中；但是当它用于做约束、分组、标识分析时，则需要存在于维度表中。在维度表中，我们往往会把连续的数据换成离散的数值存储，例如：将标价变为价格区间段。这是要根据对业务的理解做进一步设计的。雪花模型与星型模型所谓的雪花模型，是当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。而星型模型则是所有维表都直接连接到事实表上，整个图解就像星星一样，故将该模型称为星型模型。雪花模型是对星型模型的扩展。星型模型是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连，不存在渐变维度，所以数据有一定冗余。因为有冗余，所以很多统计不需要做外部的关联查询，因此一般情况下效率比雪花模型高。但是从可理解性上看，雪花模型是更容易让业务理解的。因为业务可以从模型上看出维度与维度之间的关系。因此如何平衡查询效率和业务理解？我们在后面的文章中再细细道来。总线矩阵总线矩阵，维护的是企业的各个业务过程与一致性维度的关系。是以企业的高度实现的顶层设计。它的存在对于数据中台项目至关重要。如果数据中台的模型设计就是一本书，那么总线矩阵就是这本书的目录，能从整体上对每个模型有统一的定义。从项目协调上看，总线矩阵在大型项目中起到举足轻重的地位，整个项目组都能基于这个目录清晰的明白自己在做什么，别人已经做了什么，极大程度上的避免了信息沟通不畅导致的重复定义。从项目管理上看，也可以基于总线矩阵对模型设计和开发进行有效的优先级排期。最后，总线矩阵是共同业务人员和技术人员的桥梁，通过总线矩阵在项目沟通中达成一致的语言。结语通过这篇文章，初浅的对数据中台模型设计发表了一些观点。在后面的章节中，还会继续围绕模型设计的技术细节、结合行业的模型设计案例，和大家做进一步的分享和交流

Streaming中，如果我们需要修改流程序的代码，在修改代码重新提交任务时，是不能从checkpoint中恢复数据的（程序就跑不起来），是因为spark不认识修改后的程序了。在Structured

。实际上，即使每个节点分配到的数据量大致相同，数据仍可能倾斜，比如考虑统计词频的极端问题，如果某个节点分配到的词都是一个词，那么显此节点需要的耗时将很长，即使其数据量和其他节点的数据量相同。Hive