维度

转自： https://www.jianshu.com/p/8378b80e4b21 从业务数据模型转向数据仓库模型时，同样也需要有数据仓库的域模型，即概念模型，同时也存在域模型的逻辑模型。这里，业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于：数据仓库的域模型应该包含企业数据模型得域模型之间的关系，以及各主题域定义。数据仓库的域模型的概念应该比业务系统的主题域模型范围更加广。在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体，实体的属性，实体的子类，以及实体的关系等。Inmon 的范式建模法的最大优点就是从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模。但其缺点也是明显的，由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足相应的需求。维度建模法（Dimensional Modeling）维度模型是数据仓库领域另一位大师Ralph Kimall所倡导，他的《The Data Warehouse Toolkit-The Complete Guide to Dimensonal Modeling，中文名《数据仓库工具箱》，是数据仓库工程领域最流行的数仓建模经典。维度建模以分析决策的需求出发构建模型

作者：易观数字营销经理 赵岩 易观方舟预定义指标，指的是易观方舟在开始使用之后，不用进行埋点，初始化就可以得到的数据，这样的一系列指标就形成了方舟独特的指标体系。易观方舟预定义维度指的是初始化默认的细分维度。 预定义指标： 访问级指标，事件级指标，用户级指标。 预定义维度： 设备维度，地域维度，用户来源。 下面我们将分别介绍上述预定义指标体系和预定义维度的具体含义以及应用场景。 12个访问级指标（仅限Web）： 实际应用举例： （一）通过访问级指标，进行应用状态监测 在易观方舟为客户预置的指标体系中，访问级指标是非常重要的。 网站、APP、小程序的运营过程中避免不了出现突发情况，比如突然有一天我们的UV（APP下载量）突然增加了几倍，或者突然有一天，我们的数据衰减了很严重，运营者需要知道原因，此时访问级指标会帮助我们进行及时的预警。 某日：网站的任意事件触发数量突然剧增，经调查发现，出现大量不明攻击事件，技术部紧急做了安全防护，次日攻击事件被拦截。 （二）访问级指标是分析的重要部分 访问级指标是事件分析和漏斗分析里的重要指标，比如想通过了解页面访问到提交订单的转化率来判断页面的引导效率是否足够？ 在拥有这样的指标体系后，我们可以通过漏斗分析进行用户留存率的统计。浏览商品详情页的用户和提交订单的用户，发现有将近50%的流失率，接下来我们可以通过分析流失原因来进行转化率优化。

本文总结了ElasticSearch中用于性能优化所用到的几种数据结构，如用于压缩倒排索引内存存储空间的FST，用于查询条件合并的SkipList以及用于提高范围查找效率的BKDTree，对这几种数据结构在Lucene中的使用进行了详细分析。 倒排索引（Inverted Index）存储 很多数据结构均能完成字典功能，总结如下。 数据结构 优缺点 排序列表Array/List 使用二分法查找，不平衡 HashMap/TreeMap 性能高，内存消耗大，几乎是原始数据的三倍 Skip List 跳跃表，可快速查找词语，在lucene、redis、Hbase等均有实现。相对于TreeMap等结构，特别适合高并发场景（ Skip List介绍 ） Trie 适合英文词典，如果系统中存在大量字符串且这些字符串基本没有公共前缀，则相应的trie树将非常消耗内存（ 数据结构之trie树 ） Double Array Trie 适合做中文词典，内存占用小，很多分词工具均采用此种算法（ 深入双数组Trie ） Ternary Search Tree 三叉树，每一个node有3个节点，兼具省空间和查询快的优点（ Ternary Search Tree ） Finite State Transducers (FST) 一种有限状态转移机，Lucene 4有开源实现，并大量使用

理解维度数据仓库――事实表、维度表、聚合表 一、事实表 Sate Product Mouth Units Dollars WA Mountain-100 January 3 7.95 WA Cable Lock January 4 7.32 OR Mountain-100 January 3 7.95 OR Cable Lock January 4 7.32 WA Mountain-100 February 16 42.40 在这些事实表的示例数据行中，前3个列――州、产品和月份――为键值列。剩下的两个列――销售额和销售量――为度量值。事实表中的每个列通常要么是键值列，要么是度量值列，但也可能包含其他参考目的的列――例如采购订单号或者发票号。 事实表中，每个度量值都有一个列。不同事实表将有不同的度量值。一个销售数据仓库可能含有这两个度量值列：销售额和销售量。一个现场信息数据仓库可能包含3个度量值列：总量、分钟数和瑕疵数。创建报表时，可以认为度量值形成了一个额外的维度。即可以把销售额和销售量作为并列的列标题，或者也可以把它们作为行标题。然而在事实表中，每个度量值都作为一个单独的列显示。 事实表数据行中包含了您想从中获取度量值信息的最底层级别的明细。换句话说，事实表中对每个维度的最详细的项目成员都有数据行。如果有使用其他维度的度量，只要为那些度量和维度创建另一个事实表即可

版权声明：联系邮箱：Originum@126.com 请注明出处： https://blog.csdn.net/Originum/article/details/90318910 成本函数： 单样本时，假设成本函数为: 那么多样本时，假设样本数为 m, 成本函数为： 就是把每个样本分别算出成本函数再相加。大概的思路是把m个样本的每次实验当作独立同分布的，所以总共m次实验在概率上应该全部乘起来。对累乘的结果取对数，增减性不变。把对数符号里的累乘符号提出，就变成累加的了。 为了方便后续计算，使 m 不同时，成本函数依然在一个数量级（保持和单样本时一样的尺度），故要对成本函数进行缩放 在前面加一个尺度因子（scale factor），公式变为： 其实全局的成本函数，就是对局部的成本函数求平均值 然后在反向传播的求偏导时， 向量化 因为要求均值，所以要计算每个样本的各种值。 拿这个网络举例子： 其中，x 是 x1, x2, x3组成的列向量，上标 i 表示其是第 i 个训练样本，[] 里表示的是位于哪一层 这里用的是显式的循环，依次求出每个样本的各种值，这样效率很低 向量化的方法实现： 就是把 m 个训练样本的值并起来，形成矩阵 横向表示的是不同的样本，纵向表示的是同一层中不同的神经元 公式变成了： 可以得出，只需进行一次矩阵乘法，就可以得到 m 个样本各自的值了 刚刚列举的是前向传播

1． 维度建模基本概念 维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。数据集市可以理解为是一种"小型数据仓库"。 维度表(dimension) 维度表示你要对数据进行分析时所用的一个量,比如你要分析产品销售情况, 你可以选择按类别来进行分析,或按区域来分析。这样的按..分析就构成一个维度。再比如"昨天下午我在星巴克花费200元喝了一杯卡布奇诺"。那么以消费为主题进行分析，可从这段信息中提取三个维度：时间维度(昨天下午)，地点维度(星巴克), 商品维度(卡布奇诺)。通常来说维度表信息比较固定，且数据量小。 事实表(fact table) 表示对分析主题的度量。事实表包含了与各维度表相关联的外键，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。比如上面的消费例子，它的消费事实表结构示例如下： 消费事实表：Prod_id(引用商品维度表), TimeKey(引用时间维度表), Place_id(引用地点维度表), Unit(销售量)。 总的说来，在数据仓库中不需要严格遵守规范化设计原则。因为数据仓库的主导功能就是面向分析，以查询为主，不涉及数据更新操作。事实表的设计是以能够正确记录历史信息为准则，维度表的设计是以能够以合适的角度来聚合主题内容为准则。 2． 维度建模三种模式2.1．

作者 | 曹胜利 Apache Dubbo PMC 导读 ：Dubbo 作为高性能 Java RPC 框架的刻板印象早已深入人心，在 Cloud Native 的架构选型上，Spring Cloud 或许才是业界的优先选择。实际上，Dubbo 已经悄然地衍进为 Cloud Native 基础设施，不仅承袭过去 RPC 时代的荣耀，而且也完善了现有基础设施的缺失。自从容器和 K8s 登上舞台之后，给原有的 RPC 领域带来了很大的挑战，本文主要讲述 RPC 领域遇到的问题，以及 RPC 怎么去拥抱 K8s 的一些思考。 K8s 介绍 Kubernetes 是一个开源的，用于管理云平台中多个主机上的容器化的应用， Kubernetes 的目标是让部署容器化的应用简单并且高效, Kubernetes 提供了应用部署、规划、更新、维护的一种机制。Kubernetes 简称 K8s。 在 Kubernetes 中，最小的管理元素不是一个个独立的容器，而是 Pod 。Pod 的生命周期需要注意以下几点： 容器和应用可能随时被杀死； Pod Ip 和主机名可能变化 (除非使用 StatefulSet 进行定制)； 写到本地的磁盘的文件可能消失，如果想不失效，需要用存储卷。 应用 & 容器 & Pod 的关系 应用部署在容器中，一般情况下一个应用只部署在一个容器中； 一个 Pod

序言 Dubbo 在 2011 开源之后，一直是国内最受欢迎的 RPC 框架，之后 Spring Boot 和 Spring Cloud 的面世，助推了微服务的火热程度。计算机的世界变化很快，自从容器和 K8s 登上舞台之后，给原有的 RPC 领域带来了很大的挑战。这个文章主要讲述 RPC 领域遇到的问题，以及 RPC怎么去拥抱 K8s 怀抱的一些思考。 K8s介绍 Kubernetes 是一个开源的，用于管理云平台中多个主机上的容器化的应用， Kubernetes 的目标是让部署容器化的应用简单并且高效, Kubernetes 提供了应用部署，规划，更新，维护的一种机制。Kubernetes 简称 K8s。 在 Kubernetes 中，最小的管理元素不是一个个独立的容器，而是 Pod 。pod 的生命周期需要注意以下几点： 容器和应用可能随时被杀死 Pod Ip 和主机名可能变化 (除非使用 StatefulSet 进行定制) 写到本地的磁盘的文件可能消失，如果想不失效，需要用存储卷 应用，容器，Pod 的关系 应用部署在容器中，一般情况下一个应用只部署在一个容器中 一个 Pod 下可以包含一个或多个容器，一般情况下一个 Pod 只建议部署一个容器。下列场景除外： side car 一个容器的运行以来与本地另外一个容器。如一个容器下应用负责下载数据

这篇文章从另一个角度来解决Zeng 2015的问题，并且考虑了实体对的多关系的问题。 动机 Zeng 2015里面仅仅取置信度最高的instance，丢失信息。 在数据集中，有约18.3%的entity pair有多种relation, 其他方法均未考虑。 模型 针对以上的两个问题提出了两个解决方法: 对bag内部的所有sentence embeding做instance-max-pooling的操作，具体细节后面介绍 对于多标签，使用多个二分类函数来做多标签分类，即： 使用sigmod计算每一个类别的概率, 然后判断该bag是否可能有这种关系。 模型的结构如图: 输入也是一个bag，然后利用CNN/PCNN来计算每个sentence的embedding，之后的融合方式很直接，直接对embedding的每一维度取所有sentence的对应维度的最大值。 其中k表示embedding的某一维度， j j表示bag中的第j个句子。 这样就可以融合所有sentence的信息了。后面加一个全连接层计算每一个类别的score: 之后不再是加softmax多分类了，而是使用sigmod函数计算每个relation的概率，然后超过某个阈值，就认为该relation是准确的: 其中 l l就是类别的总数。 文中设计了两种损失函数来做对比, Sigmod Loss Vs Squared Loss：

1、建立维度模型的时候不一定要求维度模型满足3范式，维度表存储空间的权衡往往需要关注简单性和 可关注简单性和可访问性 2、维度模型 星型和OLAP多维数据库 3、粒度 每行中的数据是一个特定级别的细节数据，称为粒度 4、维度建模的核心 事实表中的所有度量必须具有相同的粒度 5、事实表的粒度划分为三类 事务、周期性快照和累计快照 6、展现区数据特点 维度化的、原子的、以业务过程为中心的 # 在整个项目的过程中，都要关注数据的质量、一致性和完整性A 系统框架主要有三部分组成：源事务、后端、前端 Kimball的DW／BI架构 Kimball DW/BI 架构的核心元素 Kimball 分工明确，资源占用更加合理，调用链路少，整个DW／BI系统更加稳定、高效、有保障。 ETL系统高度关注数据质量、完整性、一致性。输入数据在进入时要检查其质量。一致的获取增值度量和属性的业务规则由ETL系统中的有技能的专业人员开发，这样会给客户发布更好的、保持一致性的产品。 展现区根据客户要求使用统一维度组织数据。方便，高效为BI应用提供数据服务。 来源： https://blog.csdn.net/Jmayday/article/details/102778207