维度

1 前言 在使用Kylin的时候，最重要的一步就是创建cube的模型定义，即指定度量和维度以及一些附加信息，然后对cube进行build，当然我们也可以根据原始表中的某一个string字段（这个字段的格式必须是日期格式，表示日期的含义）设定分区字段，这样一个cube就可以进行多次build，每一次的build会生成一个segment，每一个segment对应着一个时间区间的cube，这些segment的时间区间是连续并且不重合的，对于拥有多个segment的cube可以执行merge，相当于将一个时间区间内部的segment合并成一个。下面开始分析cube的build过程。 2 Cube示例 以手机销售为例，表SALE记录各手机品牌在各个国家，每年的销售情况。表PHONE是手机品牌，表COUNTRY是国家列表，两表通过外键与SALE表相关联。这三张表就构成星型模型，其中SALE是事实表，PHONE、COUNTRY是维度表。 现在需要知道各品牌手机于2010-2012年，在中国的总销量，那么查询sql为： SELECT b.`name`, c.`NAME`, SUM(a.count) FROM SALE AS a LEFT JOIN PHONE AS b ON a.`pId`=b.`id` LEFT JOIN COUNTRY AS c ON a.`cId`=c.`id` WHERE

curse of dimensionality维数灾难 或者翻译成维度的咒语，这个咒语出现在很多方面： sampling采样 如果数据是低维的，所需的采样点相对就比较少；如果数据是高维的，所需的采样点就会指数级增加，而实现中面对高维问题时往往无法获得如此多的样本点（即使获得了也无法处理这么庞大数据量），样本少不具有代表性自然不能获得正确的结果。 combinatorics组合数学 由于每个维度上候选集合是固定的，维度增加后所有组合的总数就会指数级增加。 machine learning机器学习 在机器学习中要求有相当数量的训练数据含有一些样本组合。给定固定数量的训练样本，其预测能力随着维度的增加而减小，这就是所谓的Hughes影响或Hughes现象。 data mining数据挖掘 在组织和搜索数据时有赖于检测对象区域，这些区域中的对象通过相似度属性而形成分组。然而在高维空间中，所有的数据都很稀疏，从很多角度看都不相似，因而平常使用的数据组织策略变得极其低效。 距离在高维环境下失去意义 在某种意义上，几乎所有的高维空间都远离其中心，或者从另一个角度来看，高维单元空间可以说是几乎完全由超立方体的“边角”所组成的，没有“中部”。一维正态分布有68%的值落于正负标准差之间，而在十维空间上只有0.02%。这对于理解卡方分布是很重要的直觉理解。 卡方分布：若N个随机变量服从标准正态分布

1 Kylin是什么 今天，随着移动互联网、物联网、AI等技术的快速兴起，数据成为了所有这些技术背后最重要，也是最有价值的“资产”。如何从数据中获得有价值的信息？这个问题驱动了相关技术的发展，从最初的基于文件的检索、分析程序，到数据仓库理念的诞生，再到基于数据库的商业智能分析。而现在，这一问题已经变成了如何从海量的超大规模数据中快速获 取有价值的信息，新的时代、新的挑战、新的技术必然应运而生。 在大数据处理技术领域，用户最普遍的诉求就是希望以很简易的方式从大数据平台上快速获取查询结果，同时也希望传统的商务智能工具能够直接和大数据平台连接起来，以便使用这些工具做数据分析。目前已经出现了很多优秀的SQL on Hadoop引擎，包括Hive、Impala及 SparkSQL等，这些技术的出现和应用极大地降低了用户使用Hadoop平台的难度。 为了进一步满足“在高并发、大数据量的情况下，使用标准SQL查询聚合结果集能够达到毫秒级”这一应用场景，Apache Kylin应运而生，在 eBay孵化并最终贡献给开源社区。Apache Kylin是2013年由eBay 在上海的一个中国工程师团队发起的、基于Hadoop大数据平台的开源 OLAP引擎，它采用多维立方体预计算技术，利用空间换时间的方法，把很多分钟级别乃至小时级别的大数据查询速度一下子提升到了亚秒级别，极大地提高了数据分析的效率

构建饿了么销售端与商家端的数据分析服务 前介 现状 需求收集 面临问题 解决办法 分析产品重点 技术方案 如何去做 先搭框架 小步迭代 未完成部分 数据看板配置化 数据产品配置化 总结 前介 今年8月，销售侧需要开始进行数据作战，我在支援销售侧业务的时候发现数据分析服务现状比较低效&不准，便和leader谈了我的想法与设计，自动请缨干这个事情，最后和总监过下方案，做一个通用的数据服务出来。这个项目我组了个小团队做到11月份，因为组织架构变更问题与领域拆分，业务移交到其他组。年底总结，写下此文，记下当时做事的思路与历程。 现状 每一个数据分析页面的需求过来，都需要经历开发在数据仓库中聚合各种数据推到mysql，在写接口读mysql数据。然后前后端联调，测试验收。 存在两个问题：1.重复开发；2.数据口径不一致；3.每次都新写代码，代码越多bug越多，数据测试也不过关。 需求收集 销售侧各个层级的经理与销售人员需要看其销售数据，基本需求如下： 查看维度：组织架构、BD、店铺、网格 时间维度：昨天、前天、最近一周、上周、本月、上月、最近30天、前30天 业务筛选聚合维度：店铺的各种标签 面临问题 需求多——数据作战是重点 数据量大，算60天订单，sum类聚合运算需提前算好 标签组合太多 解决办法 分析产品重点 与产品确认好聚合维度，固定住可以不变的 各种标签筛选、排序、算商户数都可以支持

首先做一个补充： 在RCNN中CNN阶段的流程大致如下： SPP创新点 一张图图片会有~2k个候选框，每一个都要单独输入CNN做卷积等操作很费时。SPP-net提出：能否在feature map上提取ROI特征，这样就只需要在整幅图像上做一次卷积。 虽然总体流程还是 Selective Search得到候选区域->CNN提取ROI特征->类别判断->位置精修，但是由于所有ROI的特征直接在feature map上提取，大大减少了卷积操作，提高了效率。 有两个难点要解决： 原始图像的ROI如何映射到特征图（一系列卷积层的最后输出（feature map）） ROI的在特征图上的对应的特征区域的维度不满足全连接层的输入要求怎么办（又不可能像在原始ROI图像上那样进行截取和缩放）？ (这两个问题确实蛮重要的) 空间金字塔池化 对于难点2我们分析一下： 这个问题涉及的流程主要有: 图像输入->卷积层1->池化1->...->卷积层n->池化n->全连接层。 引发问题的原因主要有：全连接层的输入维度是固定死的，导致池化n的输出必须与之匹配，继而导致图像输入的尺寸必须固定。 继而有两种解决办法： 1、想办法让不同尺寸的图像也可以使 池化n 产生固定的 输出维度。（打破图像输入的固定性） 2、想办法让全连接层（罪魁祸首）可以接受非固定的输入维度。（打破全连接层的固定性，继而

一、什么是用户画像？   用户画像可以简单理解成是海量数据的标签，根据用户的属性、行为和观点的差异，将他们区分为不同的类型，然后从每种类型中抽取出典型特征，赋予名字、照片、一些人口统计学要素、场景等描述，形成了一个人物原型 (personas)。 二、为什么要做用户画像？   其意义大体上表现在一下几个方面： 1 精准营销，分析产品潜在用户，针对特定群体利用短信邮件等方式进行营销 2 用户统计，比如中国城市上班族购买书籍类型人数 TOP10； 3 数据挖掘，构建智能推荐系统，利用关联规则计算，喜欢红酒的人通常喜欢什么运 动品牌，利用聚类算法分析，喜欢红酒的人年龄段分布情况 4 进行效果评估，完善运营，提高服务质量 5 对服务或者产品进行私人订制，个性化服务某一类群体甚至每一位用户（未来趋势）。 6 业务经营分析以及竞争分析，制定企业发展战略。 三、用户画像呈现 （一）用户静态画像（以数据分析从业者数据为例） 此部分数据来源于静态信息数据： Ø 用户填写的个人资料，或者由此通过一定的算法，计算出来的数据 Ø 如果有不确定的，可以建立模型来判断，比如用户的性别注册没有填写，可以建立模型，根据用户的行为来判断用户性别是什么，或者它的概率      （二）用户行为画像（以电商用户行为数据为例） 此部分数据来源于动态信息数据： Ø 用户行为产生的数据：注册、游览、点击、购买、签收、评价

数据与特征工程（如何选择与处理数据）   1）在处理数据上，数据并非越多越好，多余的无关特征会因为伪相关、巧合而影响模型。   2）对数据做相关性分析的时候，善用可视化可以一目了然发现问题。   3）对于高度相关的特征，移除或者合并前要三思，可能并不会提高模型能力。   3）如果选用了线性模型，可能需要对特征进行离散化   4）对于大部分模型来说，归一化或者标准化是必不可少的步骤，至少”无害“   5）如果问题较为复杂，尽量选择非线性的鲁棒性强的模型   数据不是越多越好，要根据领域经验挑选相关特征。有一个误区就是信息越多越好。其实不然，无关信息可能与预测值存在某种巧合，导致对检测结果造成负面影响。所以只选择与预测值可能有关联的信息。 相关性分析   做相关性分析，可以发现数据中的问题，发现数据中有意思的部分，评估模型的能力。如果多个特征高度相关，那可能模型预测能力效果有限。   方法：可视化；相关性矩阵；互信息 去相关性   总结来看，如果不存在特别严重的相关性，去相关性不是必要步骤。从理论和实验角度来看，去掉或者合并相关性特征不一定会提高模型的预测能力。   从实践角度来看，树模型对于相关性的鲁棒性强，如果可能，可以先使用未处理的特征在树模型进行尝试。   如果有必要移除相关性，下面是移除相关性的方法：特征选择；设定阈值，去除高线性相关的特征组。 特征提取  

1. 认识桥接模式 1. 定义：将抽象与实现分离，使它们可以独立变化。用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。也就是说，通常我们会首先定义一个抽象化接口，然后再创建一个具体实现类继承该接口，完成具体的功能实现。但是使用桥接后，我们会将这两部分隔离，具体的功能实现类的一套接口以及实现类，以及定义所需功能的抽象类以及抽象实现类。抽象类定义所需功能，抽象实现类继承抽象类，并且将功能实现类对象作为域对象，然后再抽象类定义的所需方法接口中调用功能实现类对象的方法。 2. 模式的组成结构： 抽象化（Abstraction）角色：定义抽象类，并包含一个对具体实现对象的引用。 扩展抽象化（Refined Abstraction）角色：是抽象化角色的子类，实现父类中的业务方法，并通过组合关系调用具体实现角色中的业务方法。 具体实现（Implementor）角色接口：定义具体实现角色的接口，接口中实现的功能是原本应该在扩展抽象化类中实现的，但独立出来通过组合关系供扩展抽象化角色调用。 具体实现（Concrete Implementor）角色：给出具体实现角色接口的具体实现。 3. 参考代码实现： public class BridgeTest { public static void main(String[] args) { Implementor imple

tf.nn.rnn_cell.BasicLSTMCell(n_hidden, forget_bias=1.0, state_is_tuple=True): n_hidden表示神经元的个数，forget_bias就是LSTM们的忘记系数，如果等于1，就是不会忘记任何信息。如果等于0，就都忘记。state_is_tuple默认就是True，官方建议用True，就是表示返回的状态用一个元祖表示。这个里面存在一个状态初始化函数，就是zero_state（batch_size，dtype）两个参数。batch_size就是输入样本批次的数目，dtype就是数据类型。 例如： import tensorflow as tf batch_size = 4 input = tf.random_normal(shape=[3, batch_size, 6], dtype=tf.float32) cell = tf.nn.rnn_cell.BasicLSTMCell(10, forget_bias=1.0, state_is_tuple=True) init_state = cell.zero_state(batch_size, dtype=tf.float32) output, final_state = tf.nn.dynamic_rnn(cell, input, initial_state

（马蜂窝技术原创内容，公众号ID：mfwtech） 一、马蜂窝数据仓库与数据中台 最近几年，数据中台概念的热度一直不减。2018 年起，马蜂窝也开始了自己的数据中台探索之路。 数据中台到底是什么？要不要建？和数据仓库有什么本质的区别？相信很多企业都在关注这些问题。 我认为数据中台的概念非常接近传统数据仓库+大数据平台的结合体。它是在企业的数据建设经历了数据中心、数据仓库等积累之后，借助平台化的思路，将数据更好地进行整合与统一，以组件化的方式实现灵活的数据加工与应用，以更清晰的数据职能组织应对业务的快速变化，以服务的方式更好地释放数据价值的一种方式。 所以，数据中台更多的是体现一种管理思路和架构组织上的变革。在这样的思想下，我们结合自身业务特点建设了马蜂窝的数据中台，核心架构如下： 在中台建设之前，马蜂窝已经建立了自己的大数据平台，并积累了一些通用、组件化的工具，这些可以支撑数据中台的快速搭建。作为中台的另一大核心部分，马蜂窝数据仓库主要承担数据统一化建设的工作，包括统一数据模型，统一指标体系等。下面介绍马蜂窝在数据仓库建设方面的具体实践。 二、数据仓库核心架构 马蜂窝数据仓库遵循标准的三层架构，对数据分层的定位主要采取维度模型设计，不会对数据进行抽象打散处理，更多注重业务过程数据整合。现有数仓主要以离线为主，整体架构如下： 如图所示，共分为 3 层： 业务数据层