维度

看到同学们会经常问，数据分析工作是怎么样的呢？怎么才能有业务思维呢？这些东西怎么来学习呢？说实话，这些东西仅仅是拼借着书籍很难理解深刻的。下面我们继续把 数据蛙 当作一个潜力公司，如果要理解深刻，先了解下 数据蛙的业务哈 ，(注意:下面的数据是随机生成) 一:以运营的视角来看数据分析工作 大家来想下，如果你和 数据蛙 的运营同学是搭档，那怎么才能把 数据蛙 这家公司运营的更好呢。运营同学负责用户增长、营业额上升，每天早晨肯定会首先看 交易金额 是否上升、用户是否增长了。但作为运营指标，仅仅考虑这 交易金额、用户增长数量 这两个指标肯定是不够的，需要把这些指标进行拆分，从不同的维度来看这一反应情况，考虑的维度主要有 地区 、 课程类别 、 时间 、 商户类别 等。所以就有下面的考虑指标了 不同地区交易金额、交易笔数 不同课程交易金额占比 不同城市的用户交易增长情况 不同时间交易金额、笔数 … 想想看，如果把不同维度相互组合展示所有的指标，那可不要展示好几十个呢？展示到PPT上也要好几十页了。我们作为 高逼格 的数据分析师，那样做确实不妥，还要手动的制作PPT，不如使用 Dashboard 自然流畅。 二:Dashboard 分块展示 销售Dashboard 大家可以自己观察下展示的内容，其中 Dashboard 可以在 时间、地区、不同客户 维度上相互切换组合

监控微服务调用：监控的对象是什么？具体监控哪些指标？从哪些维度进行监控？ 　　一、监控对象 　　由上至下，分四个层次 　　* 用户监控。业务直接对用户提供的功能的监控。 　　* 接口监控。业务提供的功能所依赖的具体RPC接口的监控。 　　* 资源监控。某个接口依赖的资源监控。比如Redis存储数据，对Redis的监控属于资源监控。 　　* 基础监控。对服务器本身的健康状况的监控。如CPU、内存、I/O读写量、网卡带宽。 　　 　　二、监控指标 　　* 请求量。一个是实时请求量（Query Per Second：每秒查询次数）。一个是统计请求量（Page View：一段时间的访问量）。 　　* 相应时间。 　　* 错误率。一段时间内调用失败的次数占调用总次数的比率来衡量。 　　三、监控维度 　　* 全局维度。从整体角度监控对象的请求量、平均耗时以及错误率。 　　* 分机房维度。 　　* 时间维度。同一监控对象，每天同一时刻的指标通常都会不一样，通常需要与一天前、一周前、一个月前、甚至半年前等。 　　* 核心维度。一般业务会对核心和非核心隔离，分开监控。 　　 来源： https://www.cnblogs.com/gzhcsu/p/11389788.html

本文原载自大数据杂谈微信公众号。 感谢美团点评工程师高大月撰文并授权转载。 高大月，美团点评工程师，Apache Kylin PMC成员，目前主要在美团点评数据平台负责OLAP查询引擎的建设。 背景 美团点评的OLAP需求大体分为两类： 即席查询：指用户通过手写SQL来完成一些临时的数据分析需求。这类需求的SQL形式多变、逻辑复杂，对响应时间没有严格的要求。 固化查询：指对一些固化下来的取数、看数的需求，通过数据产品的形式提供给用户，从而提高数据分析和运营的效率。这类需求的SQL有固定的模式，对响应时间有比较高的要求 。 我们针对即席查询提供了Hive和Presto两个引擎。而固化查询由于需要秒级响应，很长一段时间都是通过先在数仓对数据做预聚合，再将聚合表导入MySQL提供查询实现的。但是随着公司业务数据量和复杂度的不断提升，从2015年开始，这个方案出现了三个比较突出的问题： 随着维度的不断增加，在数仓中维护各种维度组合的聚合表的成本越来越高，数据开发效率明显下降; 数据量超过千万行后，MySQL的导入和查询变得非常慢，经常把MySQL搞崩，DBA的抱怨很大; 由于大数据平台缺乏更高效率的查询引擎，查询需求都跑在Hive/Presto上，导致集群的计算压力大，跟不上业务需求的增长。 为了解决这些痛点，我们在2015年末开始调研更高效率的OLAP引擎，寻找固化查询场景的解决方案。

为了计算各类别中子类别销售额总和的平均值, 用来平均值判断 step1 : 添加一个计算字段 { FIXED [类别]:AVG({FIXED [子类别]:SUM([销售额])})} step2 : 拖拽至度量值 来源： https://www.cnblogs.com/liuyuanq/p/11376771.html

今天，大数据、数据科学、机器学习分析不再只是热词，已经真实地渗透于生活方方面面。根据福布斯，到2025年，全球每年将会有 175 泽字节的数据产生。Kyligence的诞生为企业带来了极速的大数据分析体验 。 当企业要对大规模的数据进一步进行更为复杂的分析如对销售额进行预测时，传统的分析工具就捉襟见肘了 。 这篇文章将以基于Spark的分布式机器学习平台 Databricks为例，为您提供一套从以 Kyligence 为数据源到分布式数据分析平台的高效无缝的解决方案。 对企业未来销量进行预测是一个很普遍的分析需求。分析师需要先以不同的时间粒度如日或月，或者是其他维度粒度如地区，商品等聚合数据，然后按不同的算法预测聚合后的数据。相类似的预测、分析场景还有很多，如运维数据的异常值检测，金融数据的反欺诈识别，销售数据的用户画像等。在数据被深入挖掘之前，都需按维度列或时间戳聚合数据。然而想顺滑地聚合如此海量的数据，并且深入挖掘数据并不简单。 对海量数据进行挖掘的难点 聚合大量数据，复杂度高，所耗时间长 当数据量呈规模式增加时，即使是执行一条简单的筛选查询也会消耗很多时间，并且查询语句复杂度越大，执行语句所花时间就会越长。因此，数据科学家稍调整筛选条件，就会重新陷入等待中。 分析维度的粒度很难随意变动 由于高额的查询成本，数据科学家们会更倾向于聚合有潜在关联的数据维度

当我们建好 立方体 之后，就可以使用 MDX语法 大展拳脚，下面我们以一个简单的例子逐步展开 先介绍一下我们的立方体，通过这个例子来学习filter与iif的使用。 我们首先谈需求 需求一：得到 2009 年 5 月，产品 BM00000001 的各城市年累计处方量 需求分析： 度量值：年累计处方量 [Year_Pres_Quantity] 维度： [cust].[City_Name].[City_Name] 条件： [ 月份 ].&[2009-05-01T00:00:00] ， [material].[Material].&[BM00000001] 因此，构造我们的 MDX 如下： select [Measures] . [Year_Pres_Quantity] on 0 , non empty [cust] . [City_Name] . [City_Name] on 1 from [ 医院销售分析 ] WHERE ( [ 月份 ] .& [2009-05-01T00:00:00] , [material] . [Material] .& [BM00000001]) 需求二：得到 2009 年 5 月，产品 BM00000001 的各城市 目标医生 的年累计处方量 注意：这里多了一个要求，必须是目标医生的 在我们的传统 SQL 中，这是很容易实现的，我们在 where

一、数据仓库的架构 数据仓库（Data Warehouse DW）是为了便于多维分析和多角度展现而将数据按特定的模式进行存储所建立起来的关系型数据库，它的数据基于OLTP源系统。数据仓库中的数据是细节的、集成的、面向主题的，以OLAP系统的分析需求为目的。 数据仓库的架构模型包括了星型架构（图二：pic2.bmp）与雪花型架构（图三：pic3.bmp）两种模式。如图所示，星型架构的中间为事实表，四周为维度表，类似星星；而相比较而言，雪花型架构的中间为事实表，两边的维度表可以再有其关联子表，从而表达了清晰的维度层次关系。 从OLAP系统的分析需求和ETL的处理效率两方面来考虑：星型结构聚合快，分析效率高；而雪花型结构明确，便于与OLTP系统交互。因此，在实际项目中，我们将综合运用星型架构与雪花型架构来设计数据仓库。 那么，下面我们就来看一看，构建企业级数据仓库的流程。 二、构建企业级数据仓库五步法 （一）、确定主题 即确定数据分析或前端展现的主题。例如：我们希望分析某年某月某一地区的啤酒销售情况，这就是一个主题。主题要体现出某一方面的各分析角度（维度）和统计数值型数据（量度）之间的关系，确定主题时要综合考虑。 我们可以形象的将一个主题想象为一颗星星：统计数值型数据（量度）存在于星星中间的事实表；分析角度（维度）是星星的各个角；我们将通过维度的组合，来考察量度。那么，

原文地址： https://zhuanlan.zhihu.com/p/31494491 上次我总结了在PyTorch中 建立随机数Tensor的多种方法 的区别。 这次我把常用的 Tensor的数学运算 总结到这里，以防自己在使用PyTorch做实验时，忘记这些方法应该传什么参数。 总结的方法包括： Tensor求和以及按索引求和： torch.sum() torch.Tensor.indexadd() Tensor元素乘积 ：torch.prod(input) 对Tensor求均值、方差、极值： torch.mean() torch.var() torch.max() torch.min() 最后还有在NLP领域经常用到的： 求Tensor的平方根倒数、线性插值、双曲正切 torch.rsqrt(input) torch.lerp(star,end,weight) torch.tanh(input, out=None) 张量数学运算 元素求和 torch.sum(input) → float 返回输入向量input中所有元素的和。 参数： input (Tensor) - 输入张量 例子： a = torch.randn(1, 3) a 1.5796 0.4102 -0.2885 [torch.FloatTensor of size 1x3] torch.sum(a) 1

转载请标明出处！ 随着机器学习与图像识别技术的发展，第一代、第二代验证码已经失去了安全验证的作用。为了增加识别难度，网站暴力升级图片验证码，严重破坏了用户体验。第三代验证码的诞生解决了这一痛点，第三代验证码已经不再是狭义上的验证码，它通过多场景多维度进行数据收集，为网站提供立体式安全保障。 声明 本文内容仅限于研究，不涉及各安全厂商具体源码与风控策略。维护网络安全，人人有责。 验证码划代 （一）第一代验证码 定义：主要利用简单知识构建验证码。如中文、英文、数字等。 （二）第二代验证码 定义：以第一代验证码为基础，以创新交互方式的思想构建验证码。如看题选字、看图选物等。 （三）第三代验证码 定义：多场景多维度收集数据信息，为网站提供立体式安全防护。 第一第二代验证码退出历史舞台的原因 以下是我总结的两点原因 （1）随着机器学习与图像是被技术的发展，第一代、第二代验证码已经失去了安全验证的作用； （2）为了增加识别难度，网站暴力升级图片验证码，严重破坏用户体验。 举个例子 以上类型验证码我们通过肉眼识别准确率大约为30%，但我们拿到图片打码平台（魔镜）上用训练后发现准确率能超过90%。机器能做得比人好，其实这已经失去的验证码的意义。 第三代验证码“很简单” 最近常常会有人问我，研究的第三代验证码是不是就是滑块验证码？不就是把滑块滑动到指定位置吗？这有什么难的？ 这让我想起

下面内容来自首席增长官年会上，小红书增长技术负责人占雪亮「精细化运营在小红书的实践」的演讲，通过这个内容，我们学习在实际工作面对数据如何去分析。其中，红色字体是我标注的，方便大家对应之前学过的分析问题套路去理解。 1.关于小红书增长之路 在开始分享之前，想先给大家介绍一下小红书，小红书是一个泛品类的生活方式分享平台。 截止到2018年 6 月 6 日，我们的用户数过亿了，昨天我又拉了一下数据，现在是 1 亿 8 千万了，这个增长相对而言还是比较快的了。 回想 2014 年年底、 2015 年年初我刚加入小红书的时候，当时小红书只有 20 人左右的规模，而现在我们用 1644 天完成了用户数过亿。 好，接下来我们进入分享的主题。这是两周前我们公司内部做的一次关于低龄用户留存差的数据分析。 2.为什么低龄用户的留存比较差？（观察数据图表后，提出的问题） 刚刚很多嘉宾都讲到现在获客成本在不断的提高，在 AARRR 的模型里，当 A（获取用户） 越来越贵的时候，我们该如何保证最后的利润 R （增长收入）？如何在利润 R 和越来越贵的A 之间寻找一个平衡点呢？ 就比如说以前 1000 元可以拉来 100 个用户，留存率 10 %，结果有 10 个人留下来了（新增用户100人*留存率10 %=10个人留下来）； 现在 1000 元只能拉来 50 个人了，如果还想留下 10个人，那怎么办