维度

1GBDT和LR融合 LR模型是线性的，处理能力有限，所以要想处理大规模问题，需要大量人力进行特征工程，组合相似的特征，例如user和Ad维度的特征进行组合。 GDBT天然适合做特征提取，因为GBDT由回归树组成所以， 每棵回归树就是天然的有区分性的特征及组合特征，然后给LR模型训练，提高点击率预估模型（很多公司技术发展应用过，本人认为dnn才是趋势）。 例如，输入样本x，GBDT模型得到两颗树tree1和tree2，遍历两颗树，每个叶子节点都是LR模型的一个维度特征，在求和每个叶子*权重及时LR模型的分类结果。 2广告长尾性 1）gbdt和随机森林rf的对比： rf主要选择对大多数样本有区分度的特征；gbdt的过程，前面树针对大多数样本有区分 ，后面树针对残差依然较大的样本，即针少数的对长尾样本。更适合ctr模型预估。 2）针对广告的长尾性，广告id这个特征就很重要，比如：某少量长尾用户就喜欢点某类广告主的广告。 方案：分别针对ID类和非ID类建树，ID类树：用于发现曝光充分的ID对应的有区分性的特征及组合特征；非ID类树：用于曝光较少的广告。 3gbdt得到的特征维度 维度会降低，总维度是所有叶子节点数之和。 4gdbt模型原理 1）BT回归树 年龄预测：简单起见训练集只有4个人，A,B,C,D，他们的年龄分别是14,16,24,26。其中A、B分别是高一和高三学生；C

源码地址: https://github.com/weilanhanf/PythonDesignPatterns 说明： 有些类在功能设计上要求，自身包含两个或两个以上变化的因素，即该类在二维或者多维上变化。现有一杯咖啡，咖啡杯的大小和是否加奶为两个变化因素，使得这杯咖啡在这两个维度上发生变化，也就是可以产生四个类：小杯不加奶，小杯加奶，大杯不加奶，大杯加奶。这样的话如果说在给咖啡多几个变化因素如：加糖，是否加热等，那么就会有呈指数增长个数的子类产生。但是我们可以从另一个角度考虑。这四个类其实是两个角色的组合，行为和抽象，抽象为大杯小杯，行为为加奶与否。这种分离抽象与行为的方法就是桥接模式。 桥接模式：将抽象部分与它的实现部分解耦，使得两者都能够独立变化适应业务需求，或者说是两个部分中的任何一部分发生变化时都不会影响对方，”井水不犯河水"。桥接模式桥接模式又被称为柄体(Handle and Body)模式或接口(Interface)模式 用抽象关联取代了传统的多层继承 将类之间的静态继承关系转换为动态的对象组合关系 桥接模式的结构 桥接模式包含以下4个角色： Abstraction（抽象类） RefinedAbstraction（扩充抽象类） Implementor（实现类接口） ConcreteImplementor（具体实现类） 实例： 在一个画图程序中，常会见到这样的情况

转载至：http://tech.meituan.com/dianping_order_db_sharding.html 背景 原大众点评的订单单表早就已经突破两百G，由于查询维度较多，即使加了两个从库，优化索引，仍然存在很多查询不理想的情况。去年大量抢购活动的开展，使数据库达到瓶颈，应用只能通过限速、异步队列等对其进行保护；业务需求层出不穷，原有的订单模型很难满足业务需求，但是基于原订单表的DDL又非常吃力，无法达到业务要求。随着这些问题越来越突出，订单数据库的切分就愈发急迫了。 这次切分，我们的目标是未来十年内不需要担心订单容量的问题。 垂直切分 先对订单库进行垂直切分，将原有的订单库分为基础订单库、订单流程库等，本文就不展开讲了。 水平切分 垂直切分缓解了原来单集群的压力，但是在抢购时依然捉襟见肘。原有的订单模型已经无法满足业务需求，于是我们设计了一套新的统一订单模型，为同时满足C端用户、B端商户、客服、运营等的需求，我们分别通过用户ID和商户ID进行切分，并通过PUMA（我们内部开发的MySQL binlog实时解析服务）同步到一个运营库。 切分策略 1. 查询切分 将ID和库的Mapping关系记录在一个单独的库中。 优点：ID和库的Mapping算法可以随意更改。 缺点：引入额外的单点。 2. 范围切分 比如按照时间区间或ID区间来切分。 优点：单表大小可控，天然水平扩展

目录 im2col简介 im2col.cpp源码 小结 参考 @(Caffe源码-im2col操作) im2col简介 caffe的卷积操作中使用im2col来加速，im2col将卷积核中的每个点在图像上的对应点全都提取出来按行排列，得到一个矩阵，这样就将卷积操作转化为矩阵进行操作。 如上图所示的，假设输入图像的形状为 channels=1, height=width=5 ，并且 pad_w=pad_h=1, kernel_h=kernel_w=3, stride_h=stride_w=2, dilation_w=dilation_h=1 。左侧图中蓝色为padding补充的边界，值均为0，绿色为实际图像的数据。其中卷积核中 \(k_{00}\) 位置在整个卷积操作中共计算了 output_h*output_w=9 次，每次的位置在左侧图中用黑色实心圆标注出来。而im2col操作即是将卷积核上的每个点的这些对应位置上的值都提取出来，按照右侧黄色方格的形式存放起来。这样卷积操作可简单地通过将卷积核（中间的红色方格）展成一个向量，然后与右侧的黄色方格矩阵中的每一列点乘来实现。更详细的说明可查看后面列出来的参考博客。 与im2col对应的是col2im操作，即是将矩阵还原成卷积前的图像的形状，不过caffe代码中的 col2im_cpu() 函数还稍微有些改动。 im2col.cpp源码

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一：树节点的结构 class KprDimension{ private String id; //树的当前节点id private String name; //树节点名称 private String parentId;// 树节点父id private Integer level; //树的节点层级，如下图的A即为1，B,C即为2 private List<KprDimension> children;//树的子节点 } 1 获取树的最下级子节点(即子节点为空的节点) 即获取图中树的没有子节点的节点:G、H、I、J、F这几个节点。 1.1 思路 项目中用到了维度的概念，其关系如同树结构一样，现在有个需求要获取最底层的维度，转换为获取树结构没有子节点的节点。 将数据库中的数据读取出来，转换为树结构即可。或者采用SQL语句直接转换为树结构。 1.2 递归调用 /** * 递归调用获取最底层维度 * * @param kprDimension * @param returnList * @return returnList */ private List<KprDimension> getChildrenDimensions(KprDimension kprDimension,List<KprDimension

一、确定主题 即确定数据分析或前端展现的主题。（以汽车行业的KPI管理分析系统为例） 例如：我们希望分析某年某月某区域某门店销售情况，这就是一个主题。 主题要体现出某一方面的各分析角度（维度）和统计数值型数据（量度）之间的关系，确定主题时要综合考虑。统计数值型数据（量度）存在于中间的事实表；分析角度是各个维度；我们将通过维度的组合，来考察量度。 那么，“某年某月某某一地区某一门店的销售情况”这样一个主题，就要求我们通过时间、地区和门店三个维度组合，来考察销售情况这个量度。 从而，不同的主题来源于数据仓库中的不同子集，我们可以称之为数据集市。数据集市体现了数据仓库某一方面的信息，多个数据集市构成了数据仓库。 二、确定量度 在确定了主题以后，我们将考虑要分析的技术指标，诸如：年销售额之类。它们一般为数值型数据。 我们或者将该数据汇总，或者将该数据取次数、独立次数或取最大值最小值等，这样的数据称为量度。量度是要统计的指标，必须事先选择恰当，基于不同的量度可以进行复杂关键性能指标（KPI）等的设计和计算。 三、确定事实数据粒度 在确定了量度之后，我们要考虑到该量度的汇总和不同维度下量度的聚合情况。考虑到量度的聚合程度不同，我们将采用“最小粒度原则”，即将量度的粒度设置到最小。 例如：假设目前的数据最小记录到月，即数据库中记录了每月的交易额。 那么，如果我们可以确认，在将来的分析需求中

维度表示你要对数据进行分析时所用的一个量, 比如你要分析产品销售情况, 你可以选择按类别来进行分析,或按区域来分析. 这样的按..分析就构成一个维度。前面的示例就可以有两个维度：类型和区域。另外每个维度还可以有子维度（称为属性），例如类别可以有子类型，产品名等属性。 下面是两个常见的维度表结构： 产品维度表：Prod_id, Product_Name, Category, Color, Size, Price 时间维度表：TimeKey, Season, Year, Month, Date 而事实表是数据聚合后依据某个维度生成的结果表。它的结构示例如下： 销售事实表：Prod_id(引用产品维度表), TimeKey(引用时间维度表), SalesAmount(销售总量，以货币计), Unit(销售量) 上面的这些表就是存在于数据仓库中的。从这里可以看出它有几个特点： 1. 维度表的冗余很大，主要是因为维度一般不大(相对于事实表来说的)，而维度表的冗余可以使事实表节省很多空间。 2. 事实表一般都很大，如果以普通方式查询的话，得到结果一般发的时间都不是我们可以接受的。所以它一般要进行一些特殊处理。如SQL Server 2005就会对事实表进行如预生成处理等。 3. 维度表的主键一般都取整型值的标志列类型，这样也是为了节省事实表的存储空间。 事实表和维度表的分界线

torch.bmm() torch.matmul() torch.bmm()强制规定维度和大小相同 torch.matmul()没有强制规定维度和大小，可以用利用广播机制进行不同维度的相乘操作 当进行操作的两个tensor都是3D时，两者等同。 torch.bmm() 官网： https://pytorch.org/docs/stable/torch.html#torch.bmm torch. bmm ( input , mat2 , out=None ) → Tensor torch.bmm()是tensor中的一个相乘操作，类似于矩阵中的A*B。 参数： input，mat2：两个要进行相乘的tensor结构，两者必须是3D维度的，每个维度中的大小是相同的。 output：输出结果 并且相乘的两个矩阵，要满足一定的维度要求：input（p,m, n ) * mat2(p, n ,a) ->output(p,m,a)。这个要求，可以类比于矩阵相乘。前一个矩阵的列等于后面矩阵的行才可以相乘。 例子： import torch x = torch.rand(2,3,6) y = torch.rand(2,6,7) print(torch.bmm(x,y).size()) output: torch.Size([2, 3, 7]) ###########################

维度建模简介 维度建模是一种将数据结构化的逻辑设计方法，因此它对业务用户来说很直观，并能提供较快的查询性能。 维度建模将客观世界分为事实和维度。 1、维度建模 VS 范式(3NF)建模 建模方法 开发周期 开发成本 数据冗余 维护成本 维度建模(Kimball) 短 低 有 高 范式建模(Inmon) 长 高 无 低 在数仓模型架构设计中，维度建模以星型模型为主。 dw层通常采用范式建模 ，并可根据实际情况允许存在一些冗余。 dm层通常采用维度建模 ，因维度建模构建出的数据模型更复合普通人的认知，易被理解，从而有利于数据的推广使用。 2、维度建模的好处？ 范式建模是一种 想尽方法消除数据冗余 的设计方法，数据被分成很多离散的实体，每一个实体在关系数据库中都对应一个数据表。即使简单的订单业务过程也会产生好几十个表。这种规范化方式对事务处理来说非常有好处，因这种情况下事务的加载和更新会比较简单和迅速。 维度建模的好处： 1.业务角度—可理解性 最主要原因。因信息都被分组到一致的业务分类（维）中，业务分类可以帮助用户查询模型。 2.技术角度—星型联接数据库的查询优化是简单、可预测、可控制的 大多数数据库优化器都是为星型联结设计的（先对维度表加上约束条件并查找满足查询条件的键，随后通过对相关维度键进行笛卡尔积操作来查询事实表） 注：笛卡尔积 设A,B为集合，用A中元素为第一元素

以下总结纯属个人学习理解，如有不对还望留言改正。参考文章博客地址如下： https://blog.csdn.net/likika2012/article/details/39619687 https://blog.csdn.net/zhjchengfeng5/article/details/7855241 https://www.joinquant.com/view/community/detail/c2c41c79657cebf8cd871b44ce4f5d97 https://zhuanlan.zhihu.com/p/22557068 https://www.cnblogs.com/dirge/p/6091241.html https://leileiluoluo.com/posts/kdtree-algorithm-and-implementation.html 感谢几位大神的详细总结； 首先要学习kdtree就要先理解二叉树，因为实现kdtree的数据结构是基于二叉树思想来实现的。 二叉树顾名思义就是一个根节点有两个子节点；二叉树思想： 二叉查找树（Binary Search Tree，BST），是具有如下性质的二叉树（来自wiki）： 1）若它的左子树不为空，则左子树上所有结点的值均小于它的根结点的值； 2）若它的右子树不为空，则右子树上所有结点的值均大于它的根结点的值；