1:关于主题与主题域
主题（Subject）是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念，每一个主题基本对应一个宏观的分析领域。 数仓主题域：主题域通常是联系较为紧密的数据主题的集合，根据业务需求分析的视角进行划分抽象归类。 划分方法：主题域划分的方法一般有几种 要么按照业务过程来划分，一个业务过程抽象出一个主题域，比如业务系统中的商品、交易、物流 等 要么按照业务部门来划分，一个业务部门抽象出一个主题域，比如中台部门、业务运营部门、供应链部门 等 要么按照业务系统来划分，一个业务系统抽象出一个主题域，比如搬家系统、erp系统 等 数仓主题：是在较高层次上将企业生产上的各个系统中某一分析对象的数据进行整合、归类并分析的一种范围，属于一个抽象概念，简单点说每一个主题对应一个宏观分析领域。 划分方法：说白了主要就是要识别出分析对象主体，做主题划分和主题域划分，个人建议是要站在全局的视角来看，然后先划分出主题域，再接着在主题域里面划分出各个主题，主题域的划分一般比较谨慎，一旦定下来了避免频繁变动，虽然数仓建设是迭代建设的，不能保证一次性初始化好，但我们的主题域划分和主题划分要尽可能地涵盖企业的所有业务，以及在新业务进来时能够无影响地被包含进来和可扩展主题域。 主题域：面向业务过程，将业务活动事件进行抽象的集合，如下单、支付、退款都是业务过程，针对公共明细层（DWD）进行主题划分。 数据域：面向业务分析，将业务过程或者维度进行抽象的集合，针对公共汇总层（DWS）进行数据域划分。 业务过程：指企业的业务活动事件，如下单、支付、退款都是业务过程，业务过程就是一个不可拆分的行为事件。 其实数据域跟主题域的差别不大，很大情况下两者就等同于一个概念的。
主题边界
主题域是对某个主题进行分析后确定的主题的边界。分析主题域，确定要装载到数据仓库的主题是信息打包技术的第一步。而在进行数据仓库设计时，一般是一次先建立一个主题或企业全部主题中的一部分，因此在大多数数据仓库的设计过程中都有一个主题域的选择过程。主题域的确定必须由最终用户和数据仓库的设计人员共同完成。确定主题边界实际上需要进一步理解业务关系，因此在确定整个分析主题后，还需要对这些主题进行初步的细化才便于获取每一个主题应该具有的边界。
确定主题的内容
主题虽然在信息包图中只占据标题的位置，但是却是信息打包方法中最重要的部分，当主题定义好之后，数据仓库中的逻辑模型也就基本成形了。此时，需要在主题的逻辑关系模式中包含所有的属性及与系统相关的行为。数据仓库中的数据存储结构也需要在逻辑模型的设计阶段完成定义，需要向里面增加所需要的信息和能充分代表主题的属性组。图所示可以分别在“商品”、“销售”和“客户”主题上增加能够进一步说明主题的属性组。
2:总线矩阵
维度总线矩阵： 维度建模的数据总线矩阵，提炼出公共一致性维度。无论是主事实表，还是隶属于主事实表的子事实表都统一在总线矩阵中体现出来，这样我们能够准确提炼真正的公共一致性维度。 所以，总线矩阵和一致性维度、一致性事实共同组成了 Kimball 的多维体系结构基础。
机会/利益型矩阵 可以利用同一个业务过程勾画出不同的矩阵，但需要用维度列替换业务功能。例如，销售计划、市场、店面操作以及金融等。按照不同的功能的需要，包含不同的矩阵元素表明哪些业务过程对哪些业务功能有需求。在以过程为中心的行被确定为项目时，也可以用于识别需要哪些组参与更详细的需求、维度建模和BI的应用需求。
指标维度矩阵：记录指标和维度的关系，各类管理指标主要通过何种维度来观察。从业务上用于了解观察的角度和内容，从技术上用于构建可视化结构以及数据结构。按照指标/维度布局矩阵结构，仔细分析指标维度矩阵，将指标按照业务流程排序，将维度按照通用到专用排序。
3:关于模型
数据模型的核心要点在于数仓建设规范，包含库表命名规范、词根命名规范，码值表管理、一致性维度、横向分层、纵向分域、禁止反向调用、统一指标和维度管理、指标命名、计算口径、统计来源唯一、公共处理逻辑下沉及单一....
建模方法论：
建模调研：
建模流程：
（Ⅰ) 主题域的规范设计 主题域的设计除了需要遵循SDOM中的规范外，还需要考虑以下几点：主题域的划分 主题域的命名规范 主题域的负责人，审批人设置 主题域下的子主题域的设计及命名规范
（Ⅱ) 标准字典集的配置 标准字典集配置：以SDOM已经梳理的行业标准词根为依据，在网易模型设计中心字典集中进行统一配置管理。
（Ⅲ）逻辑分层及表规范设计 数据分层便于我们清晰的了解数据组织结构，方便对数据的定位和理解；同时规范化的数据分层可以大大减少重复开发，可以利用数据分层将一个复杂任务分解成多个步骤来完成，每一层解决特定的问题，使复杂问题简单化。
（Ⅳ) 模型评估 模型的好坏直接影响到数据的准确性，全面性和完整性。通过数据有效对模型的合理性进行监控是模型评估的有效手段之一，网易结合自身多年的模型建设经验从模型复用度，跨层依赖率等多重指标对模型的质量进行监控和有效评估。
4:关于指标
指标定义应全局一致、统一口径，具有唯一性。指标名称一名多义、多名一义的信息混淆，造成大量的无效沟通成本甚至错误。同一个指标应该在企业内部尽量保持唯一，尽量不要出现销售额（A事业部），销售额（B事业部），这些一名多义的方式会从下到上对业务分析造成困扰。若实在由于各事业部间的同一指标的口径难以统一，那就要做好不合并、分开统计分析的准备。这类事项要在两个事业部之上的权力单位确定。 指标计算逻辑应尽量简化。企业中关注的重要指标有时会随着不同部门的要求持续修改定义，或者不断更新计算的数据范围，造成指标计算逻辑、取数范围越来越复杂，最终导致计算成本过高甚至无法计算。比如计算销售额时要排除取消订单，但是某个区域的取消订单还需保留、某种类型的订单需要排除等复杂逻辑，最终将指标计算公式变得异常复杂，极大增加了计算的成本，且导致计算困难和错误。这类局部视角的管理思路放到统一的平台上来落地，会是管理的噩梦，不仅对项目造成影响，更多的是增加了管理的复杂度，降低了管理效率。 指标内容较多，先整体后局部。先梳理指标条目，再梳理指标的详细内容。这里的详细内容可以根据实际情况有所取舍。 指标体系是数据资产的关键组成，是数据目录的信息基础。数据目录核心就是对于数据指标体系的结构化展现，合理化管理，便捷化应用。我们推荐在建设初期就引入数据资产目录，利用此工具来实施和维护BI的指标体系，一来实施时更加高效，二来缩短学习曲线，能够减少维护成本，提高维护效率。 指标体系要关注建设，更要关注维护。指标体系在BI建设初期梳理，且会随着业务发展持续变化。比如随着市场的变化、领导的变更等原因，指标定义、计算逻辑和管理要求会随之变化等。要能够持续维护指标体系，确保指标体系能够及时、准确、完整的反应业务的情况。这也是确保BI能持续发展的关键。 指标体系将指导数据可视化、数据方案的落地。 指标管理需要有相对应的指标字典或者指标平台。 总体来说就四句话： （1）规范化指标命名 （2）规范化统计口径 （3）规范化指标等级 （4）指标配置化生成
5:数据治理
数据治理是一个持续周期长，涉及面非常广的工作，其中包含了数据质量检查，库表元数据管理，数据血缘管理，hdfs小文件治理,数据模型治理，计算引擎性能治理，集群性能监控、数据资产沉淀，指标治理....
1: 报告治理
要持续提升重点报告的稳定性和性能，定期的治理和优化必不可少，因为报告访问量、表的数据量、表结构、表产出时间都存在一些不确定的变化。报告治理主要分为首访缓存命中率治理、报告查询错误率治理、慢查询治理三大块。 要提升重点报告首访缓存命中率，核心是要提高重点报告缓存预加载的完成比例，可以从以下三个方面优化： （1）优化重点报告的表产出时间，重点报告依赖的表产出时间提前，才有更多的时间buffer去做缓存预加载，这个需要数据开发和分析师同学一起从数据产出链路上去优化。 （2）提升重点报告缓存预加载的优先级，这个可以提升重点报告相较于普通报告缓存预加载的先后顺序，从而提升重点报告缓存预加载完成率，同时重点报告也会根据最近访问量等指标再去细分优先级。 （3）对于一些缓存预加载超时或出错次数比较多的报告可以降低优先级。 要降低重点报告查询错误率，要对图表查询错误做分类治理： （1）查询超时的图表要做慢查询优化治理（见图表慢查询优化部分）。 （2）图表查询高峰错误需要诊断出可疑的报告/图表进行优化。 （3）系统错误要通过系统优化来解决，比如元数据错误可以增加元数据刷新重试，服务重启错误可以增加查询重试等等。 （4）业务错误要推进报告作者治理，比如原表被删除、原表变更导致某些字段不存在、数据源连接不上等等。 图表慢查询治理方面，统一的治理有以下几类： （1）耗时耗资源图表治理：top耗资源、top耗时图表往往严重影响集群整体性能和稳定性，多个慢图表并发查询时更容易出现查询高峰，所以这部分治理是重中之重。当然这个治理也要结合图表的访问量去看的，访问量大的图表影响也越大。 （2）小文件治理：小文件过多会导致元数据比较大，增加元数据同步压力，而且也会影响HDFS的性能。 （3）定时刷新治理：耗时耗资源的图表定时刷新频率过快，也会显著增加集群负载，可以降低频率或者关闭定时刷新。 具体到单个慢图表，常见的性能优化思路有： （1）模型强制分区筛选：大表全表扫描对性能影响较大，百万以上大表建议使用分区表，同时在模型上设置强制分区筛选，减少数据扫描范围，也从源头控制全表扫描的可能。 （2）抽取到MPP：自定义SQL如果有筛选或聚合使得结果集减少可以抽取到MPP，通过MPP去查询，减少复杂SQL实时计算；后续产品上也支持抽取宽表模型到MPP，这在CK引擎上会有比较大的性能提升。 （3）物化模型：模型中关联的表过多导致性能差，可以使用数据任务预计算或者使用网易impala物化视图物化模型。 （4）列表筛选器使用独立维表：列表筛选器的数据需要从模型宽表明细对应列上去重计算得到，数据量大时性能较慢。如果列表筛选器成员比较固定的情况，可以列表筛选器走独立维表，通过跨模型关联筛选图表。 （5）刷新表统计信息：Impala是基于代价模型进行执行计划优化，表统计信息缺失会对执行计划的优劣产生重要影响，可以提前刷新表统计信息。 （6）时间/日期转换：将“字符串”类型的字段转换为“日期、日期时间”类型时，使用原始类型（即字符串类型）进行比较则不需要在SQL中进行字段类型转换，可提高查询性能。 （7）表存储格式治理：text存储格式数据过滤能力差，建议尽量使用高性能列式存储格式Parquet。
2: 集群资源治理
建立可观测性监控系统，对于重点任务，优先级较高的任务，排队中/处理中任务的状态进行监控，占用集群资源多少等... 全链路压测 集群任务/进程占用资源topN 冷表下线10W+张，累计下降存储2.8PB，净下降1.9PB（8.49-6.59） 资源费用 12k/day->2k/day 内存memory seconds 下降33% 高耗资源任务运行时间 下降90% 高耗资源任务成本消耗 下降69%
3: 规范治理
跨层依赖任务数 反向依赖任务数 指标统计口径和逻辑是否正确，来源是否正确 数据质量检查
4: 计算资源治理
数据开发治理平台openAPI获取yarn资源消耗明细 内存空闲时间分布聚类取前20%阈值 RAM实际申请大于1TB 利用率小于10% 任务失败数 sla延迟数
5:存储治理
小文件数量 30天打开次数+近30天引用次数+近30天访问次数+近30天写入次数 = 0 近30天打开次数+近30天引用次数+近30天访问次数 = 0
6: 库表治理
梳理库的使用情况，无用的库表走申请下线流程。 临时表治理 生命周期管理的推进 巨型表的治理 abtest专项治理
7:元数据治理
8:数据资产治理
