如何理解？
对于资源对象的编辑和管理权限，存在上游资源的权限依赖，所以需要回溯上游对象确认是否具备至少查看权限，如：
用户 A 是数据集X的管理者，以及数据集 X 上游依赖的数据连接 XLink 的管理者。此时当A将数据集授权给用户 B 可进行数据集X的“管理”或“编辑”权限，则需要同时将数据连接Xlink的至少查看权限授予给用户 B， 否则用户 B 在进行数据集的编辑时，是无法获取和引入 Xlink 进行数据集的调整工作的；
用户 A 是仪表盘中图表 P 和 M 的所有者，且同时是图表 P 和 M 所依赖的数据集 X 的管理者。当用户 A 需要将仪表盘不仅授予用户 B 查看，且允许用户 B 编辑该图表 P 和 M 时，则需要同时将数据集 X 的至少查看权限也授予给用户 A；
即，需要当前资源对象的管理或编辑权限，则需要回溯依赖该资源对象的上游对象的至少查看权限；
解决思路
一般存在权限不足的报错，根据上述原理，倒推获取授权一般就可解决；
另一种权限问题是： 有时会在可视化查询的界面看到某些图表里存在灰色胶囊字段，这种是因为图表中使用了他人在数据集上保存为个人数据集字段。

针对权限问题，可见权限体系操作手册

如何理解？
数据集实际上就是一个存储上游业务数据源有关需求数据的业务仓库，它既是一个同步数据到 DataWind 的中间转化+存储工具，也是一个基于业务自定义的数据仓库；
数据集的底表存储是 DataWind 的存储计算引擎，用于对接多种数据源，以屏蔽不同源头库的数据格式和规范的特异性，实现一定程度的数据清洗，且使得下游的可视化查询功能忽略数据源的 SQL 异构，以统一的数据格式以及函数库来实现上游所有图表制作和分析；

数据集解耦数据 BI 对业务源库的直接依赖，支持离线的负责分析查询以及直连的快速单表即席查询能力；

它是BI图表的上游依赖对象，也同时作为可视化建模工程的输出节点(数据仓库)

2.1 模型逻辑：

数据集最关键的维护在于模型的管理和编辑，模型决定了抽取的数据范围、数据清洗逻辑

2.2 关联（Join）

数据量较大情况下，在查询的时候出现数据重复统计，业务往往困惑也不理解；
排查逻辑，有限数量行所评价的那个字段(维度/指标)是否在模型中是作为(左/内/完全)连接的主表，且在被 join 连接的表中，根据连接关系，主表与被连接表的关系是1：N, 此时生成的数据集底表中，会按照笛卡尔积，将主表的一行复制成N行，用以连接后续表的字段：


此时，若对拼接后的数据集的底表直接统计主表(如上图的Name字段)，会得到10行，而大于原A-角色表的name的数据量7行； 或者当你筛选属性为“太乙金仙”的角色有几个时，你会得到2而不是1，但实际只有孙悟空这一个角色；
此类问题的处理方式：

• 改count(X)为uniq(X); 如上图中，X 可为 ID or Name or Role_ID；
• 检查模型关系，将被连接表的字段多拉几个出来，然后改图表类型为【明细表】，从而摒弃聚合字段或者聚合指标对真实行数据的干扰，从而便于排查主表字段是因为关联了什么字段而被拆分重复；

关于左连接，右连接，内连接，完全(外)连接的用法区别见： 数据模型

2.3 数据集同步失败

数据集经常同步失败，但模型配置上并没有报错；
主要有这么几个场景原因，根据实际来排查：

• 初次建立数据集模型或者做了模型修改后，出现极端的小表套大表的逻辑模型，导致笛卡尔积呈几何倍数增长，从而引起数据膨胀检测触发了阈值而系统中止；

小表套大表即：左表和右表根据连接字段关系，数据呈现1：N的映射关系，且N>=50;
如常见的 Prudoct Type join SKU；或者 Type join ProductInstance；

• 初次建立数据集模型或者做了模型修改后，出现极端的数据倾斜的逻辑模型，导致建模后的底表数据宽表里，数据值分布过于极端，数据同步时触发阈值而系统中止； 如A表中X字段有0到99号共100个枚举值，但对应数据中，X=1或者2的有10万行，而其他枚举值只有1行或2行；

• 上游数据源的业务表发生了结构变化，当前数据集过去运行成功，但没有重新相应编辑数据集模型，导致现在运行不成功；主要检查原数据集中的字段，是否受到了源头表的改动影响，如字段类型，是否存在，字段名等； 此时查看前台任务的【日志】，往往显示字段解析类的错误，会显示SQL xxxx error的日志内容；
     4. 源头上做了迁库，数据源的库类型或者连接的IP+port或JDBC发生了变更；导致数据集同步失败，此时查看前台任务的【日志】，往往显示DataX...Schame..或Access Deniled等字样的，表示获取数据库连接错误或超时之类；

2.4 数据源字段与数据集字段

数据源字段 不等于 数据集字段
数据源字段的name一定是源头表的名字，是不可修改的，出现同名字段后，会自动带上源表名，格式为：源字段名[源表名]; ---模型的每个节点里所保留的数据源字段，即约等于存储在CK底表的模型字段；
数据集字段来自于数据源字段，在第一次生成数据集时，会按照模型自动生成，名字=源字段名，但同时允许用户在【字段配置】里，自定义地新增或修改字段的名字以及字段的表达式(即取xx源字段做YY转换)；
数据集字段的目的是为了从业务层使用灵活封装及加载必要的字段到图表分析过程，是让用户从下游业务BI的数据仓库/数据集市角度重新定义数据的字段意义或统一整合更符合业务BI意义的字段集合；
也正因为上述原理，所以会出现：
A. 上游可视化建模任务的结构改变后，用户发现为什么我的数据集字段没有自动更新，这是因为可视化建模输出是关联到下游直连数据集的Clickhouse的表结构，而不会直接去修改下游该数据集的【数据集字段】，即业务层面解耦封装的字段；
B. 在数据集模型更新后，而未重新同步数据前，原有基于数据集的BI查询依旧有一致的数据可查询，而不是立即受模型更新后出现无数据问题；
建议：

• 在BI可视化查询分析里，尽可能都使用数据集字段；且尽可能让数据集字段更符合业务意义来命名；

• 新增加自定义字段时，在表达式里引用已有字段的【数据集字段】，便于逻辑上统一和便于修改维护；这样当根节点的数据集字段因源表的数据源字段变化时，只需要修改第一层引用关系里的数据源字段即可；

2.5 特殊数据格式处理

某些特殊格式的字段，需要做一定的字段格式的转化，否则不能正确显示，常见如：

• Unix16/32的长整数格式记录的 Date-time，本地查看是日期时间，同步到DataWind后字段显示long型数字； ---采用字段编辑里的日期函数toDate，或toDateTime，或FromUnix等函数处理即可；

• 飞书表格上的时间类型的字段，需要在DataWind里使用专门的格式处理：

  toDate((lark_time * 86400000 - 2209161600000)/1000

• 数据集字段的数据类型在直接从数据源识别过来后，存在一定误差，需要在数据集的【字段配置】里经过手工确认和调整，否则可能导致图表分析时，无法采用正确的聚合表达式或统计分析：

• Hive 的 struct 类型字段无法直接按照CK字段获取和存储：

直接引入具有 struct 类型字段的表，通常出现的问题是，该字段类型识别为 unspported，无法作为 CK 的字段存储生成数据集; 解决办法如下，改用自定义 SQL 方式，使用select单独struct元素方式引入成不同字段；
如下图的示例说明，这样，对于需要引用的源表中的struct里的元素对象，就可转化为独立的字段列，保存在CK数据集里；

• 相比于 DataWind 使用的数据集模型，很多不同源头数据库所支持的函数是有差异的，需要尽可能现在标准的CK函数集里搜索确认下，不然可能会报错，如：

  • 计数不同(唯一值统计)， Uniq()， 而非Count Distinct ；

  • 对于日期函数，现在/今天，推荐优先使用now()；ClickHouse语法支持today()函数，但有的源头数据库可能只支持now()，而非today()，建议优先使用now()

  • dateDiff()函数取日期，对于结果是向上取整；区别于MySQL的timestampDiff，是向下取整；

如何理解？
可视化建模，可以理解为是一个更高级的更复杂处理能力的数据集，提供在数据集中无法实现的多维度、更灵活的数据预处理以及清洗或聚合能力，它是一个数据预处理的工程，工程建设完毕后，就成为了一个生产数据的管道；当该建模任务完成数据同步后，原始数据就会按照工程的各个环节被加工成最终想要的【数据集】，也就是一个更符合BI业务需要的大宽表； 输出的数据集支持CK和Hive两种类型；
更简单来说，可视化建模的输出，可以视作一个轻型的数仓，这个数据，可以被直接用于BI，也可以被再次用作下游的建模工程的输入数据。

3.1 单元测试法

单元测试法的本质是，将庞大的建模拆解为单元测试，每一个新的处理节点都是基于前一阶段正确的情况下再叠加进行。尽可能避免一次性完成所有节点的构建后，再进行数据同步的校验，避免浪费时间过长以及排查问题无从下手，单元测试法两种模式：

• 执行完当前节点后，利用预览探查，针对建模工程的每个环节的数据样本分析，判断是否满足自己的数据预处理的预期，以及是否在该环节出现问题。
  
• 基于每一个【连接_xx】处的节点，校验完后，直接链接到输出节点构建输出数据集，并快速完成同步，通过数据集的可视化查询校验数据建模逻辑；以此类推，逐步增加后续节点步骤，每一步测试完毕后再新增后续节点，直至建模逻辑全部完成。 （Tricks：为了避免单步建模输出测试的数据同步时间过长，可以在相关的源头输入节点里，加入一定的筛选条件，如地区，业务日期或者品类，限定仅抽取该条件下某些枚举值的样本数据，以确保采用1000以内的小数据量实现快速的重复单元测试，使所需要的数据集同步数据时间较短。）
  
  

3.2 如何避免数据倾斜或数据膨胀

通常来说建模工程的连接节点越多，数据倾斜或者数据膨胀的系数就会越大，这是因为检测机制是基于源头的节点与末尾的节点的数据比例进行测算,超过一定的膨胀系数后，系统会强制终止进程；
两种优化逻辑：

• 参考【数据集管理】章节的【逻辑问题二】的数据处理方法，尽可能先规避有特异性明显的数据表或者数据连接逻辑；

• 拆解复杂工程为多个基础的独立建模工程输出，先分别输出中间数据集后，再用新的建模工程把中间数据集作为输入节点再合成为最终的数据集输出；

3.3 上游依赖问题

可视化建模允许使用已有的某个已有的数据集作为输入节点，从而两个数据同步任务之间形成了业务关系的依赖。若执行时出现该数据集一直等待，到达同步开始时间后，发现状态为等待上游就绪，一般来说，检查该可视化建模是否存在上述依赖。
存在依赖导致不执行，最通常情况是当前业务所配置的被依赖上游任务的业务日期范围内，上游任务没有完成数据同步；比如当前任务依赖上游的前一天，那就打开上游任务看看前一天的分区数据是否同步完成；
如果想要使得当前建模数据是按照T+0天(也即当天)的模式依赖上游数据，一个可行的办法是，所依赖的上游数据集或建模设为小时级任务，当前建模也设置为小时级更新任务；否则，对于天级的任务之间，最小是按照T-1天(即前一天)来依赖数据；

3.4 自定义 SQL 执行报错或者很慢

某些场景下，在输入节点使用了复杂聚合逻辑的自定义 SQL，从而引发数据错误或者同步很慢；
这是因为输入节点，往往都是数据同步时通过【数据连接】指定的源库表进行数据本地查询的计算过程，比如一个 MySQL 的输入节点，实际是引擎转义后的 MySQL 语句在远端源库执行查询然后返回数据结果给 DataWind，然后再送给下游节点处理，直至产生输出数据集。
这一过程，一是受制于远端的通信流量的限制，二是受制于源头业务库的执行效率；越复杂的处理放在同步的交互过程里，处理速度就越慢。（想象一下：是付钱后直接交货两斤生牛肉快速，还是付钱后交付4盘红烧牛肉快速？）
明白了这点，就可以：

• 对于输入节点要使用自定义 SQL 时，尽可能简单高效，只做明确的字段的查询，不做聚合或清洗等处理，确保源头执行的 SQL 尽可能高效简单；
• 在建模的第二层或非输入节点层做复杂的聚合或者数据清洗动作；
  
  

3.5 Presto 数据源的建模获取或执行失败

数据存储在企业的数仓，然后利用了Presto这种查询引擎集成，在连接到DataWind时配置了presto类型的数据连接。 在有的时候用户会遇到如下问题：

DataX schema文件不存在或格式不正确: 获取DataX sample失败: DataX schema文件不存在或格式不正确: 请求DataX Service失败: {"code":20003,"msg":"[ERROR-SQL预编译异常] Access Denied: Cannot select from columns [banfn] in table or view eban_1d_a","advice":null,"data":null}

一般来说是当前这个数据连接里所配置的用户的权限不够，需要替换为有可执行SQL的权限用户。修改数据连接的用户和密码即可。

如何理解？
按照【维度】的组合条件的结果，去聚合计算在不同条件结果下所有满足【指标】公式的统计值，并输出；

4.1 维度与指标

影响到统计分类或计算分类的，是【维度】字段，也即对应常说的"统计维度是什么"这一概念; 【指标】是标量，永远是按照符合维度/维度组合的结果枚举值的范围，来进行数据指标字段的计算，如sum，count等，
如：COLOR = 红|黄|蓝，SIZE= 大|小，若维度组合=COLOR+SIZE, 计算指标 CarName的总数，即sum(CarName), 则会按照如下6种维度结果分布，来给出不同分布下的sum(CarName),即：

所以，通常核对数据统计是否准确或者是否存在重复统计时，往往从下面几点着手：

• 数据抽样，利用业务字段里比较关键的分类字段，选取一两个枚举值，用来抽样数据验证；

• 用来作为不同条件下被观测的字段，一定要设为【指标】，系统对指标和维度的聚合方法是有差异的；数值计算只针对指标；

• 维度对指标存在直接数据分布影响，指标按照维度的枚举值结果来分组计算，类似于groupby；指标对指标分布没有直接影响；

• 维度过多时，数据出错或不符合预期，一般两种方法排查：

  • 结合方法a，切换图表为明细表，看是否存在主表指标字段被次表join后导致重复计算的问题，若有，可利用key字段做去重；

  • 按照维度从上到下，从大到小的原则，逐步拉入维度分步分析指标的结果，从而观察数据在哪一步进来后发生异变。

3.2 函数应用错误怎么办

当使用某种函数公式聚合了指标字段进行计算，功能没有使用的不对报错，但查询出来的数据结果不符合预期，一定是数学上的逻辑设计错误，而不是函数错误或者功能错误。
此时最快速的校验办法，是把相同的处理逻辑，用Excel的同类逻辑公式写出来，在Excel里验证一下。大多数情况下，如果Excel同等的逻辑表达式是与CK函数一样的逻辑的话，那么Excel里出来的结果也会等同于可视化上图表指标出来的结果。 这种方式的本质是在于，让用户回归到数据的分析逻辑上先校验或者排除数据逻辑的理解错误或者公式使用错误；
同理，寻找解决方案也可以反过来，先在Excel里找到可以得到正确结果的公式方法，然后把这套逻辑转化为对等的DataWind的CK函数写出来，运用在对应的字段上。

3.3 空值处理

对于特殊空值的处理，有的时候因为源头库的机制原因，有些字段里允许空值，在本地库查询视觉上确实为空，但同步到DataWind后，查询出来这些空值有时候显示为“null”，有时候显示为空值。这是因为由于不同的字段格式，不同入库处理机制带来的差异。
简单检测和预处理方法： 使用isNull(X)或者empty(Y)来测试判断； isNull主要针对NULL值判断，结果返回1，常可作为对null行的量统计； 而empty主要是检测空字符串值，空字符串返回1，非空为0，常可配合if使用，用来对空值做转义处理。

3.4 透视表

透视表主要是用来做有限维度的分层/分类数据的统计，从而看清大数据指标在不同层级归类下的占比或者数量。而不是用来呈现行列组合维度的明细。
往往很多用户看到透视表能实现行维度和列维度的矩阵式分布展示，就会觉得更好看或更有层次，从而把类似于明细表的排列很多个维度或指标字段的图表展示采用了【透视表】；但反而造成数据查询很慢。这是因为透视表的底层就是进行类似于Order by+Group By的聚合透视计算，从而在大数据量的明细数据展示误用了透视表时，会计算卡死或超时。
类似于Excel的透视逻辑一样，少于4层维度的统计计算或者分布计算，才适合用透视表。如，统计每个省份下不同城市以及针对不同品牌维度的产品销售值统计，就可以采用透视表。

3.5 明细表

明细表反应的是存储在CK底表里的真实大宽表的具体每一行数据，消除了统计公式或指标聚合带来的数据行的合并。所以在大多数场景下，能够帮助我们回归到原始数据形态上审视同步上来的数据集数据的形态和特征，发现我们主观的误解或漏解；
主要是便于反推由于【Join】带来的“笛卡尔积”效果的分析，导致对于原表数据行的拆分。
如：COLOR = 红|黄|蓝，SIZE= 大|小，若维度组合=COLOR+SIZE, 计算指标 CarName的总数，即sum(CarName), 则会按照如下6种维度结果分布，来给出不同分布下的sum(CarName),即：

此时如果简单按照A列去统计总共有多少颜色，会得到count数=6，而实际应该用Unique统计=3才符合实际； 又或者，有时候受笛卡尔积拆分的字段包括某些数值指标类型字段，如date，money，score，那在处理时，就可以用明细表+多列字段分析法，排查因为“乘”了什么字段导致表数据行拆分(重复)了，进而可以在指标聚合时，选择取平均值、最大值、最小值等方式规避重复数的干扰；

3.6 数据结果空值过多

出现很多数据字段空值的行的问题，一般而言：

• 采用外连接的情况下，往往会产生很多空字段的数据行；
• 表源头是表格，有看不见的数据空行，尤其是经过多表聚合后，问题会放大；

3.7 筛选与求和逻辑

为什么改变筛选条件时，某些聚合指标或者汇总统计指标值会变？或者某些【分析】的结果会变，不符合预期？如：单产品占比，销售占比
举个例子：
这是因为此时的逻辑并不是基于维度和指标的表达逻辑先计算查询后，再做结果的过滤，而是先按照筛选条件的字段，过滤出数据集里符合条件的数据行，然后再按照页面上维度/指标所表达的计算逻辑开始计算，因此这种分析类型的计算值结果会变；
同理，采用了行权限的数据集也是一样的逻辑，所以需要格外注意你的聚合或者分析字段的处理方式；
其中一种处理方式，是结合LOD计算，新增一个存放目标计算结果的指标字段，利用如Fixed，Exclude这样的基于表数据的计算函数，生成固定值，从而该指标字段在查询时，能在指定的字段层级下不受筛选的干扰。

这一部分基本都是图形化的设计或者排版工作，这部分更多是反复的美观调整或者设计思路的经验积累；
需要单独明确的是三块：

4.1 公共筛选器的理解和运用

公共筛选的定位即是为了方便多个图表需要统一按照xx字段进行筛选变化时，用一个筛选器实现全局过滤；所以此处常见的问题是：
不同图表具有相同意义或者名称的字段，但其来源的数据集模型却并不是同一个，此时全局的筛选也许会针对不同数据集的图表产生的结果意义并不一致；所以建议同一数据集的图表组合在一起时，更适合套用同一个公共筛选器；
不同数据集的图表组合，进行分块，采用不同筛选器控制。

4.2 图表联动的运用和配置逻辑

在看板里，特别重要且独一无二的功能就是图表联动，常见的问题有：

a. 上下两表联动的数据从视觉上看起来不相关，尤其是两个图表来源于不同数据集的时候，此时需要非常细心分析两表之间用于关联的字段，在数据上是否有问题(如格式一致，数据范围可匹配模式);
  b. 需要分析联动之间的数据筛选逻辑是否合理(这个逻辑等同于Excel里的公式逻辑)，如是否需要组合字段才能得到正确结果，而当前图表里是否引入必须的字段；主表字段的值，在次表里是作为索引键还是业务键；
  c.对于同一数据集(特别是复杂的宽表数据集)，在此基础上需要生成不同维度的图表，且图表间需要有因果关联，是适合使用图表联动来表达的； 来源于不同数据集的图表，由于其底层数据模型以及数据内容往往不一致，形成图表联动意义不大，非特殊不推荐；
  d. 大部分场景下，对于同一数据集内部的 下钻分析场景，都可以用图表联动来实现；且从数据的表达以及存在反复分析的情景下，图表联动比下钻的表达更清晰明确。

4.3 动态参数的使用

参数一般在项目层面定义，分为公共参数和个人参数，经常会遇到的问题是：
参数在设置时，是要配置所应用的数据集的，起作用的原理还是作用在所应用的数据集的上层图表结果里；
所以当在仪表盘里引用参数时，发现某些图表有问题，可以先看看该图表所属的数据集是否应用了该参数。

搭建方法参考：仪表盘应用搭建最佳实践