精华内容
下载资源
问答
  • 这种计算在日常数据处理中很常见,我们举一些例子:应对业务部门的取数需求:比如销售部门想获得进行了某项促销活动前后的销售情况变化信息;数据挖掘算法前的清理准备:将来自各个业务系统的数据(甚至一些企业外部...
        

    640?wx_fmt=png&wxfrom=5&wx_lazy=1

    作者:蒋步星

    来源:数据蒋堂

    本文约2000字,建议阅读5分钟
    通过本文带大家评估了一下三种处理临时性计算的优劣。


    640?wx_fmt=png&wxfrom=5&wx_lazy=1


    临时性计算,顾名思义,是指临时发生的一些计算需求。这种计算在日常数据处理中很常见,我们举一些例子:


    • 应对业务部门的取数需求:比如销售部门想获得进行了某项促销活动前后的销售情况变化信息;

    • 数据挖掘算法前的清理准备:将来自各个业务系统的数据(甚至一些企业外部的数据)整理成规则一致的二维表,这些动作常常比挖掘本身耗时还长得多;

    • 有业务规则的测试数据生成:测试数据不能完全随机生成,必须满足一定的业务规则以及分布比例;

    • 大数据计算的优化方案实验:性能优化是个迭代的过程,需要不断尝试各种计算方案;

    • 非日常(外部)数据的清洗和入库:比如有些下级部门提供的Excel表格要写入数据库再进行统计分析;


    可以看出,临时性计算具体相当的普遍性。那么,我们是用什么方法来处理这种具有普遍性的计算需求呢?


    其实也就是编程序了,常用来应对临时性计算的编程方案有三种:以Java为代表的高级语言、以SQL为代表的数据库语言、以Python为代表的脚本语言。


    然后,第二个问题,我们怎么评估这些方法的优劣和适应性呢?


    640?wx_fmt=png


    为了回答这个问题,我们要先分析临时性计算的需求特征:


    • 需求随意,不可预测:这是临时性计算的基本特征,计算需求时临时产生的,不能事先预测到而做进数据分析系统中,只能临时面对;

    • 经常只做一次,缺乏直接可复用性:这也是临时性的特征,做完就完了,没有必要刻意地反复优化,也没必要也不可能事先为计算做准备工作;

    • 大量涉及多样性的原始外部数据:很多计算的涉及数据并不在数据库中,比如收集上来的Excel表格,从网上爬下来的文本等,这些数据还常常以原始形式出现;

    • 常常涉及多步骤的过程计算:本来分析处理类的运算就会步骤比较多,而数据源的杂乱更会加剧这一现象;

    • 必要时可能转变成日常计算:也有些临时性计算可能重复发生,这时就有必要转化成日常计算放进数据分析系统中;

    • 以结构化数据计算为主:这一点并非临时性计算特有的,其实数据分析和处理类的计算都是主要面对结构化或即将被结构化的数据。 


    640?wx_fmt=png


    从需求的特征出发,我们就可以提出应对临时性计算的方案的技术要求了:


    • 开发快捷:临时性计算随时发生,需要快速解决,所以要注重开发效率,相对来讲,对于运算性能要求会低一些;

    • 人员要求低:临时性计算发生场景很普遍,那么应当尽量降低实施开发人员的要求,而不是总是需要专业的程序员才能做;

    • 环境简单:经常只做一次的事情,要让环境搭建足够简单,如果准备计算环境花费时间超过实施计算本身了,那就得不偿失了;

    • 数据适应面广:计算方案要能方便地面对各种各样的数据源,不要总是需要专门的接口和技术体系,特别地要能处理较大的数据量;

    • 易于集成:要转变成日常计算时,临时写出来的代码最好能够只要简单修改甚至不加修改就能集成到数据分析系统中去。


    640?wx_fmt=png


    现在我们按这套技术要求来考查前面提到的三种技术方案,并进行评分。(前四项满分10,第五项重要程度低满分5)


    1. 以Java为代表的高级语言

    开发快捷

    3分

    用于处理结构化数据的语法和类库都不够丰富,代码会写很长,不方便,但处理过程性运算较容易,调试方便度尚可

    人员要求低

    1分

    需要很专业的程序员才能掌握

    环境简单

    1分

    开发环境一点也不简单

    数据适应面广

    3分

    理论上什么都能做,但做起来都很难

    易于集成

    5分

    这方面没有任何问题

    总分:13分


    2. 以SQL为代表的数据库语言


    开发快捷

    5分

    有完整的结构化数据计算能力,简单运算容易写,但复杂SQL很难写,而且存储过程调试很不方便

    人员要求低

    6分

    简单运算易于掌握,复杂多步运算要转换思维习惯,很费劲

    环境简单

    7分

    数据库安装不太简单,但常常已经安装好了

    数据适应面广

    1分

    基本上不能计算数据库外的数据,对外样性数据源和原始数据无能为力;大数据计算能力尚可

    易于集成

    5分

    这方面没有任何问题

    总分:24分


    3. 以Python为代表的脚本语言


    开发快捷

    8分

    开发环境较简单,调试也容易,对过程计算支持较好;不过语法体系不是专为结构化数据计算设计,有些复杂运算还是不好写

    人员要求低

    7分

    经常一些简单培训后基本上都能掌握,不过有些语法规则比较绕

    环境简单

    7分

    环境安装较为方便,但版本兼容上有些问题

    数据适应面广

    7分

    外部数据接口丰富,但开源包安装很麻烦,缺省自有的大数据方案,再配合其它访问显得很麻烦;

    易于集成

    1分

    一般业务系统都是J2EE的,集成脚本语言的难度很大

    总分:30分


    算下来还是脚本语言相对最好。


    专栏作者简介

    640?

    润乾软件创始人、首席科学家


    清华大学计算机硕士,著有《非线性报表模型原理》等,1989年,中国首个国际奥林匹克数学竞赛团体冠军成员,个人金牌;2000年,创立润乾公司;2004年,首次在润乾报表中提出非线性报表模型,完美解决了中国式复杂报表制表难题,目前该模型已经成为报表行业的标准;2014年,经过7年开发,润乾软件发布不依赖关系代数模型的计算引擎——集算器,有效地提高了复杂结构化大数据计算的开发和运算效率;2015年,润乾软件被福布斯中文网站评为“2015福布斯中国非上市潜力企业100强”;2016年,荣获中国电子信息产业发展研究院评选的“2016年中国软件和信息服务业十大领军人物”;2017年, 自主创新研发新一代的数据仓库、云数据库等产品即将面世。


    数据蒋堂

    《数据蒋堂》的作者蒋步星,从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞,虚拟与现实的相互交织,产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点,站在研发人员的角度从浅入深,进行全方位、360度无死角深度剖析;对于一些业内观点,站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展,站在业内专家角度给予预测和推断。静下心来认真研读你会发现,《数据蒋堂》的文章,有的会让用户避免重复前人走过的弯路,有的会让攻城狮面对扎心的难题茅塞顿开,有的会为初入行业的读者提供一把开启数据世界的钥匙,有的甚至会让业内专家大跌眼镜,产生思想交锋。


    往期回顾:

    数据蒋堂 | JOIN延伸 - 维度概念

    数据蒋堂 | JOIN提速 - 有序归并

    数据蒋堂 | JOIN提速 - 外键指针的衍生

    数据蒋堂 | JOIN提速 - 外键指针化

    数据蒋堂 | JOIN简化 - 意义总结

    数据蒋堂 | JOIN简化-消除关联

    数据蒋堂 | JOIN简化 - 维度对齐

    数据蒋堂 | JOIN运算剖析

    数据蒋堂 | 迭代聚合语法

    数据蒋堂 | 非常规聚合

    数据蒋堂 | 再谈有序分组

    数据蒋堂 | 有序分组

    数据蒋堂 | 非等值分组

    数据蒋堂 | 还原分组运算的本意

    数据蒋堂 | 有序遍历语法

    数据蒋堂 | 常规遍历语法

    数据蒋堂 | 从SQL语法看离散性

    数据蒋堂 | 从SQL语法看集合化

    数据蒋堂 | SQL用作大数据计算语法好吗?

    数据蒋堂 | SQL的困难源于关系代数

    数据蒋堂 | SQL像英语是个善意的错误

    数据蒋堂 | 开放的计算能力为数据库瘦身

    数据蒋堂 | 计算封闭性导致臃肿的数据库

    数据蒋堂 | 怎样看待存储过程的移植困难

    数据蒋堂 | 存储过程的利之弊

    数据蒋堂 | 不要对自助BI期望过高

    数据蒋堂 | 报表的数据计算层

    数据蒋堂 | 报表应用的三层结构

    数据蒋堂 | 列式存储的另一面

    数据蒋堂 | 硬盘的性能特征

    数据蒋堂 | 我们需要怎样的OLAP?

    数据蒋堂 | 1T数据到底有多大?

    数据蒋堂 | 索引的本质是排序

    数据蒋堂 | 功夫都在报表外--漫谈报表性能优化

    数据蒋堂 | 非结构化数据分析是忽悠?

    数据蒋堂 | 多维分析的后台性能优化手段

    数据蒋堂 | JOIN延伸 - 维度查询语法

    数据蒋堂 | 文件的性能分析

    数据蒋堂 | RDB与NoSQL的访问性能

    数据蒋堂 | 报表开发的现状


    校对:龚力


    为保证发文质量、树立口碑,数据派现设立“错别字基金”,鼓励读者积极纠错

    若您在阅读文章过程中发现任何错误,请在文末留言,或到后台反馈,经小编确认后,数据派将向检举读者发8.8元红包

    同一位读者指出同一篇文章多处错误,奖金不变。不同读者指出同一处错误,奖励第一位读者。

    感谢一直以来您的关注和支持,希望您能够监督数据派产出更加高质的内容。

    640?wx_fmt=jpeg

    展开全文
  • 如何解决临时取数需求? 如何搞定BAT大厂的数据分析项目? 怎样才更好地转型或成功跳槽? 如何挑选合适项目场景的数据分析工具? 模块二:拓展你的宏观视野 多元思维模型:数据分析需要具备的四大能力? 电商数据...

    第一讲:

    六大模块

    模块一:数据分析的行业需求与要求

    • 如何解决临时取数需求?
    • 如何搞定BAT大厂的数据分析项目?
    • 怎样才更好地转型或成功跳槽?
    • 如何挑选合适项目场景的数据分析工具?

    模块二:拓展你的宏观视野

    • 多元思维模型:数据分析需要具备的四大能力?
    • 电商数据分析:京东app的详细产品分析
    • 互联网金融:芝麻信用分的建模过程是怎样的?
    • 游戏:游戏行业的ROI和付费率是怎么算的?
    • 销售:传统行业如何做好交易额提升?

    模块三:聚焦微观方法论

    • 指标体系搭建:指标体系的经典四步
    • 流量分析:如何分析数据的波动?
    • 路径分析:用户的使用路径网络分析
    • 竞品分析:教你如何做竞品分析
    • 营销活动:日常运营活动的分析模块
    • 用户增长:用户增长的本质是什么?

    模块四:知流程,找不足(专题分析标准化流程)

    • 问题定义和拆解:如何去定义问题、拆解问题?
    • 数据获取与分析:常见的SQL技巧和分析方法
    • 报告撰写:专题报告的完美标准化格式
    • A/B测试:A/B测试的效果监控

    模块五:人人都是数据分析师

    • 行业分析:行业分析及框架分析
    • 数仓:数据仓库的三种类型表
    • 用户研究:用户研究和数据分析的根本联系与区别
    • 时间管理:优秀的数据分析师如何做时间管理?

    常规工作

    01 日/周/月报

    • 了解业务现状
      • 根据日报数据了解公司业务量
      • 及时指出问题
      • 展现自己
    • 培养数据敏感性
      • 每天关注数据的波动
      • 潜移默化的培养一定的敏感性
    • 提供业务发展建议
      • 寻找波动原因
      • 久而久之会发现产品或运营在作出何种调整后数据会出现涨跌

    周报可以看作是一个短期趋势,一周的数据会更加稳定、更具说服力;
    月报周期较长,更能够为后续业务提供更合理的发展建议。

    02 临时数据
    对于高管层的临时提数需求,优先级最高,但不能立马去做,
    而要思考为何需要这个数据,通过这个数据能进行什么决策。

    原则:坚决不做提数机器,针对每一个业务单点问题,先追根溯源,建立该业务类的分析框架,由点及面彻底解决该类问题。

    03 常规工作的优化

    • 如果每天都需要花费很多时间去分析,可以交给机器处理
    • 将需求进行合理的优先级排期
    • 遇到自己不能解决的问题时,及时与领导沟通,不盲目做事

    专题分析

    01 需求解读

    • 原始需求:负责活动的几个事业群同学希望看到活动的效果情况
    • 了解需求:目前活动对日活的帮助以及活动出现的问题有哪些
    • 本质需求:活动的拉新促活怎么样;活动带来的用户后续粘性是否较高;哪些活动做得好,哪些做得不好;如何优化

    02 建立逻辑树
    在这里插入图片描述
    03 SQL提数及分析

    • 提数:SQL三段论;所有想法验证的第一步
    • 分析:组成部分;数量比较;有何变化;各项指标分布;各项相关性;其他深层次挖掘

    04 撰写报告的三个建议

    • 以图为主:报告一定是90%的图加10%的文,图表标题说结论
    • 结论前置:如果报告对象是领导,一定要先写结论,然后报告以附件形式发送,同时在正文中也要结论前置,节省大家时间。
    • 逻辑性一定要非常强,同时演讲的过程中也需要有故事感,站在领导的角度想他要听什么?

    软技能

    01 吹水力

    • 同事之间沟通多
    • 对很多事务发表看法的人很有优势
    • 既要工作更要发生

    02 时间管理力

    • 事情多而杂,最高效时间去做最重要的事情

    03 展示力

    • 汇报特别多
    • PPT展示更多时候比内容更重要

    04 预判力

    • 国企表现机会较多
    • 能提前预判并做好相应准备能更好营销自己
    展开全文
  • 数仓理论知识之杂谈

    2020-09-08 16:57:56
    数仓痛点 数据仓库的三个阶段 第一阶段 使用大量成熟的开源框架,...临时取数需求占用数仓人员大部分时间 数据规范与流程不一致,跨部门合作困难 指标口径不一致导致数据可信度下降 数仓模型 数仓规范 外围系统建设

    数仓痛点

    数据仓库的三个阶段

    • 第一阶段
      使用大量成熟的开源框架,主要以离线批处理为主,外围系统自研能力较弱,数据量和集群资源较少。
    • 第二阶段
      使用开源+自研方式,有自己的方法论与建模体系,有比较完善的元数据管理,数据质量查控,可以满足离线实时需求。
    • 第三阶段
      有自研的一站式大数据处理平台,有完善的数仓理论基础与外围工具,有完善的共享机制与权限管理。

    痛点

    • 临时取数需求占用数仓人员大部分时间
      • 解决方法:自助取数+OLAP引擎
    • 数据规范与流程不一致,跨部门合作困难
      • 解决方法:建模规范和开发规范
    • 指标口径不一致导致数据可信度下降
      • 解决方法:指标字段
    • 烟囱式开发形成的数据孤岛与重复计算
      • 解决方法:指标字典,建模规范和开发规范
    • 数据膨胀导致计算资源紧张,出数时间得不到保障
      • 解决方法:指标字段,数据产品和服务化
    • 异常排查时间和修复时间长
      • 解决方法:元数据与数据质量监控
    • 数据安全与数据共享矛盾不可调和
      • 解决方法:数据分级与权限管理
    • 产出形式单一
      • 解决方法:数据产品和服务化
    • 业务需求响应不及时
      • 解决方法:自助取数+OLAP系统,数据产品和服务化

    数据模型

    • 接入层
      底层,在企业中被称为ODS层,一般与业务源系统数据格式保持一致。
    • 中间层
      过渡层,在企业中耗费精力最多的,也是最复杂的层,在中间层主要有临时表,维度层,明细层,汇总层与集市层组成。
    • 应用层
      最终层,向外提供数据服务。

    分层与功能对比:

    分层 功能
    APP数据应用层 个性化指标加工,基于应用的数据组装
    DWM数据集市层 宽表集市、跨过业务场景、行为数据组装
    DWS数据汇总层 单业务场景、行为数据组装、提升公共指标的复用
    DWD数据明细层 标准化、维度补全、异常处理
    DIM维度层 一致性维度建设
    ODS数据接入层 数据同步,基本与源数据保持一致

    数据流向

    总原则:禁止逆向调用,避免同层调用,优先使用公共层,避免跨层调用。

    在这里插入图片描述
    实际上很难遵守总原则,所以近两年就炒起来了一个新的概念–数据治理。

    在这里插入图片描述

    数仓规范

    表命名规范

    以一张位于dwd层,属于dache(打车)业务,dianji(点击)主题,统计点击数量(click_detail),时间周期为天(day),存储策略为f。
    dwd_daceh_dianji_click_detail_df

    字段命名规范

    • 属性字段:文本字段,使用通用单词即可

    • 指标字段:修饰词+原子词+时间修饰

    • 技术字段:计数主体_cnt

    • 比例字段:计数主体_rate

    • 分区字段:日、周、月、季度、年:ds。小时分区:nn。分钟分区:mm。业务分区:业务描述文本。

    • 费用字段:计数主体_amt

    • 标识字段:is_标识主体

    • 时间字段:业务主体_time

    • 日期字段:业务主体_date

    需求对接规范

    和业务,分析,技术沟通,确保延迟和取数准确可以接受。

    数据开发规范

    • 指定库和队列
      • 声明使用的库与本账号属于的队列
    • 表创建
      • 建立外部表,文件存储格式,分隔符,存储位置指定
    • 分区加载
      • 删除与创建,指定分区存储位置
    • UDF/临时表创建
      • 删除与创建
    • 数据写入
      • 是否通过覆盖写入数据
    • 临时表删除
      • 定时清理临时表,自动清理临时表

    外围系统建设

    调度系统

    为了保证数据处理结果的准确性,就必须要求这些任务按照上下游依赖关系有序、高效的执行。
    一个较为基础的处理方式是,预估出每个任务处理所需时间,根据先后顺序,计算出每个任务的执行的起止时间,通过定时跑任务的方式,让整个系统保持稳定的运行。

    • 开源
      • Azkaban
      • Oozie
      • DolphinScheduler
      • Airflow
    • 自研

    元数据管理系统

    元数据管理系统是外部了解数仓的门户入口,一个好的元数据系统至少要有以下信息:

    • 表信息:包括表英文名,中文注释,表状态
    • 字段信息:包括字段类型,英文名,中文名,字段注释,保密级别,统计逻辑说明
    • 负责人信息:业务/开发负责人名超链接、所在部门
    • 分区信息:分区名、分区大小、分区记录条数、生成分区的时间
    • 血缘信息:表上下游节点信息
    • 代码信息:生成该表对应的代码地址超链接
    • 存储说明:总表大小,波动情况
    • 热度信息:表示被下游依赖的多寡
    • 权限信息:申请访问超链接,权限审批到单人单字段粒度,不同保密级别字段对应不同审批流程

    通用离线与实时计算平台

    开源的有hadoop,spark,flink。

    数据质量监控

    数据质量监控系统主要基于规则判断达到数据监控的目的,系统建设一般分为三个阶段:

    1. 表级别的监控:主要为表的总条数、总大小、分区数据、各分区条数、各分区大小,条数/大小同环比,日增长情况等。
    2. 字段级别监控:枚举值异常判断、特殊值判断、范围判断等。
    3. 全链路数据监控:主要依赖上下游血缘分析,自动判断跟踪故障点。

    发展方向展望

    • 趋势一
      产品化与服务化
    • 趋势二
      单一技能变多项技能

    目前企业招聘总结

    • 建模理论基础扎实,且能熟练运用在工作中
    • 熟悉大数据技术栈中的常用组件,并能熟练使用各类型语言进行离线计算或者实时流计算的开发
    • 熟悉业内常规的开源组件,并能根据不同的场景制定不同的数据仓库实施方案
    • 有很强的业务senese,是某一个或者特定领域的专家
    • 有较好的项目管理能力,能推动项目发展
    • 超大数据量下的代码优化能力,并对原理理解透彻
    • 数据产品规划能力
    • 数据治理能力
    • 数据分析与挖掘能力

    数仓模型好坏标准

    • 节点耗费存储越小越好
    • 节点耗费资源越小越好
    • 节点深度越小越好

    基础

    数据仓库发展历史

    • 萌芽阶段
      20世纪70年代MIT提出将业务处理系统和分析系统分开,针对各自不同特点设计不同的架构。
    • 探索阶段
      20世纪80年代中后期DEC结合MIT理论,建立TA2规范定义分析系统的四个组成部分:数据获取、数据访问、目录和用户服务。
    • 雏形阶段
      1988年IBM第一次提出信息仓库的概念并称之为VIATL规范。
    • 确立阶段
      1991年Bill lnmon出版《Build the Data Warehouse》标志着数据仓库概念的确立。

    什么是数据仓库

    在《数据仓库工具箱》中,对数据仓库的描述是:
    数据仓库是一个面向主题的,集成的,相对稳定的,反应历史变化的数据集合,用于支持管理决策。(官方定义)

    在《数据仓库》中,对数据仓库的描述是:
    数据仓库是一个将源系统数据抽取、清洗、规格化、提交到维度数据存储的系统,为决策的指定提供查询和分析功能的支撑和实现。

    什么情况下去建设数据仓库

    • 当你需要集中化管理你的数据时
    • 当你希望以更高效的方式使用数据时
    • 当你的数据量和复杂度到需要一个团队来维护时
    • 当你希望可以数据驱动业务时
    • 当你想要借助大数据的力量来提升产品竞争力时
    • 当你想时刻知道业务发展情况时

    模型设计的三个阶段

    概念模型

    概念模型主要是指通过分析和归纳,将业务划分为几个主题,并确定主题之间的关系。
    比如电影行业的影院、影片、影人、用户、订单、渠道等等

    逻辑模型

    逻辑模型是指在概念模型的基础上,定义数据仓库各种实体、属性、关系,指导后续的数据存储、组织和数据应用的开发。目前比较流行的建模理论是Inmon提出的自下而上的范式建模理论和Kimball的自上而下的维度建模理论。

    范式建模

    三范式:

    • 原子性:数据不可分割
    • 唯一性:每行数据唯一
    • 独立性:消除传递依赖

    优点:

    • 节约存储
    • 结构清晰
    • 易于理解
    • 适合关系型数据库

    缺点:

    • 构建比较繁琐
    • 查询复杂
    • 不适合构建在大数据分布式环境下

    维度建模

    维度:

    • 星型
      一个事实表对应多个维度表
    • 雪花型
      一个维度表对应多个维度表

    优点:

    • 方便使用
    • 适合大数据下的数据处理
    • 适合进行OLAP操作

    缺点:

    • 维度补全造成的数据存储的浪费
    • 维度变化造成的数据更新量大
    • 典型的反三范式

    物理模型

    物理模型设计是指根据逻辑模型设计的结构为基础,设计数据对象的物理实现,比如表的命名规范、字段的命名规范、字段类型选择、分区设置、存储设置,更新方式等等。

    什么是主题域

    主题域是将业务过程或者维度进行抽象的集合

    特点是:面向分析的(主题域的划分是从业务的分析角度来进行划分的),业务抽象的(在业务流程中将一些行为的点转换为事实度量),通用的(主题域划分后相对稳定),需要长期维护的。

    主题域划分

    一般在数据仓库中业务主题与数据主题两种(大概率前者包容后者),包容会体现在数据表命名中:
    dwd(层)_xx(业务主题域)_yy(数据主题域)_zz(业务描述)_df (存储时间+存储策略)

    进行数据主题与业务主题的联系一般都使用业务数据矩阵:
    拿一个电商app举例
    在这里插入图片描述

    展开全文
  • 这种计算在日常数据处理中很常见,我们举一些例子: 应对业务部门的取数需求:比如销售部门想获得进行了某项促销活动前后的销售情况变化信息;数据挖掘算法前的清理准备:将来自各个业务系统的数据(甚至一些企业...

    原文链接:点击打开链接

    摘要: 临时性计算,顾名思义,是指临时发生的一些计算需求。这种计算在日常数据处理中很常见,我们举一些例子: 应对业务部门的取数需求:比如销售部门想获得进行了某项促销活动前后的销售情况变化信息;数据挖掘算法前的清理准备:将来自各个业务系统的数据(甚至一些企业外部的数据)整理成规则一致的二维表,这些动作常常.

    临时性计算,顾名思义,是指临时发生的一些计算需求。这种计算在日常数据处理中很常见,我们举一些例子:

    • 应对业务部门的取数需求比如销售部门想获得进行了某项促销活动前后的销售情况变化信息;
    • 数据挖掘算法前的清理准备将来自各个业务系统的数据(甚至一些企业外部的数据)整理成规则一致的二维表,这些动作常常比挖掘本身耗时还长得多;
    • 有业务规则的测试数据生成测试数据不能完全随机生成,必须满足一定的业务规则以及分布比例;
    • 大数据计算的优化方案实验性能优化是个迭代的过程,需要不断尝试各种计算方案;
    • 非日常(外部)数据的清洗和入库比如有些下级部门提供的Excel表格要写入数据库再进行统计分析;

    可以看出,临时性计算具体相当的普遍性。那么,我们是用什么方法来处理这种具有普遍性的计算需求呢?

    其实也就是编程序了,常用来对付临时性计算的编程方案有三种:以Java为代表的高级语言、以SQL为代表的数据库语言、以Python为代表的脚本语言。

    然后,第二个问题,我们怎么评估这些方法的优劣和适应性呢?

    为了回答这个问题,我们要先分析临时性计算的需求特征:

    • 需求随意,不可预测这是临时性计算的基本特征,计算需求时临时产生的,不能事先预测到而做进数据分析系统中,只能临时面对;
    • 经常只做一次,缺乏直接可复用性这也是临时性的特征,做完就完了,没有必要刻意地反复优化,也没必要也不可能事先为计算做准备工作;
    • 大量涉及多样性的原始外部数据很多计算的涉及数据并不在数据库中,比如收集上来的Excel表格,从网上爬下来的文本等,这些数据还常常以原始形式出现;
    • 常常涉及多步骤的过程计算本来分析处理类的运算就会步骤比较多,而数据源的杂乱更会加剧这一现象;
    • 必要时可能转变成日常计算也有些临时性计算可能重复发生,这时就有必要转化成日常计算放进数据分析系统中;
    • 以结构化数据计算为主这一点并非临时性计算特有的,其实数据分析和处理类的计算都是主要面对结构化或即将被结构化的数据。 

    从需求的特征出发,我们就可以提出应对临时性计算的方案的技术要求了:

    • 开发快捷:临时性计算随时发生,需要快速解决,所以要注重开发效率,相对来讲,对于运算性能要求会低一些;
    • 人员要求低:临时性计算发生场景很普遍,那么应当尽量降低实施开发人员的要求,而不是总是需要专业的程序员才能做;
    • 环境简单:经常只做一次的事情,要让环境搭建足够简单,如果准备计算环境花费时间超过实施计算本身了,那就得不偿失了;
    • 数据适应面广:计算方案要能方便地面对各种各样的数据源,不要总是需要专门的接口和技术体系,特别地要能处理较大的

    展开全文
  • 应对业务部门的取数需求:比如销售部门想获得进行了某项促销活动前后的销售情况变化信息; 数据挖掘算法前的清理准备:将来自各个业务系统的数据(甚至一些企业外部的数据)整理成规则一致的二维表,这些动作常常比...
  • 需求: 求一段时间内各生产线前3名坏机的原因及坏机. step 1, 从将原始数据中抽取品质数据放于t96临时表 create temp table t96 on commit drop as select * from t96_pd_log where recseq between '791...
  • ![图片说明]...!...!... 把值不是10001的数字出来了,如何都加上28并按原格式把修改完的数据更新回数据库中呢,一直搞前端的,不怎么懂php和sql,临时有个这个需求,求指教
  • Apache Kylin在美团点评的应用

    千次阅读 2018-04-25 15:45:05
    固化查询:指对一些固化下来的取数、看数的需求,通过数据产品的形式提供给用户,从而提高数据分析和运营的效率。这类需求的SQL有固定的模式,对响应时间有比较高的要求 。我们针对即席查询提供了Hive和Presto两个...
  • Spark 生态较为完善,已经被越来越多的互联网公司应用于生产项目,对于 ETL 开发人员而言,日常数据同步任务和临时取数任务如果有基于 Spark 封装的一个小工具,办公效率会有大幅度提升。 本场 Chat 会阐述企业现有...
  • olap和ad-hot/即席查询

    2020-04-03 14:48:27
    olap分为以下两大类: 即席查询:指用户通过手写SQL来完成一些临时...固化查询:指对一些固化下来的取数、看数的需求,通过数据产品的形式提供给用户,从而提高数据分析和运营的效率。这类需求的SQL有固定的模式。 ...
  • 本周总结

    2016-03-25 18:14:30
    本周主要工作还是集团DPI与DDR比对工作、工信部日志... (1)管理方面,大家都很累,工作无效率,办事无规章,尤其是很多临时取数需求,很恶心,都是一些无效率的取数  数据分析人员思维比较固定,不学习新东西
  • 一、kylin介绍

    2019-04-30 16:07:26
    目录 离线OLAP需求 多维立方体(Cube)概念 Kylin中的数据模型 Kylin构建步骤 数据在Hbase存储格式 ...离线OLAP需求 ...1. 即席查询:指用户在BI系统上通过拖拽现有...2. 固化查询:对一些固化下来的取数、看数的需求...
  • 1、即席查询和固化查询 ...固化查询:指对一些固化下来的取数、看数的需求,通过数据产品的形式提供给用户,从而提高数据分析和运营的效率。这类需求的SQL有固定的模式,对响应时间有比较高的要求 。 ...
  • 为什么要学习Excel:应对一些敏捷快速,需要立即相应的需求,属于临时取数的工作。 如何提升Excel技能:培养好的数据表格习惯;主动性的搜索;多练习。 Excel的常见函数: 文本清洗类 格式:ASCII, GBK, Unicode, ...
  • 固化查询:指的是一些固化下来的取数、看数需求,通过数据产品的形式提供给用户,从而提高数据分析和运营的效率。这类的sql固定模式,对响应时间有较高要求。 按照计算引擎主要分为: 1、mapreduce计算模型(hive/...
  • 即席查询:通过手写sql完成一些临时的数据分析需求,这类sql形式多变、逻辑复杂,对查询时间没有严格要求固化查询:指的是一些固化下来的取数、看数需求,通过数据产品的形式提供给用户,从而提高数据分析和运营的效率...
  • 固化查询:指的是一些固化下来的取数、看数需求,通过数据产品的形式提供给用户,从而提高数据分析和运营的效率。这类的sql固定模式,对响应时间有较高要求。 按照架构实现划分,主流的OLAP引擎主要有下面三点:...
  • 背景 数据轨迹在湖北落地,面临查询分析时间过长的问题,并且查询时间与大数据能够分配的资源有直接的线性关系。... 固化查询:指的是一些固化下来的取数、看数需求,通过数据产品的形式提供给用户,从而提高数...
  • 固化查询:指对一些固化下来的取数、看数的需求,通过数据产品的形式提供给用户,从而提高数据分析和运营的效率。这类需求的SQL有固定的模式,对响应时间有比较高的要求 。我们针对即席查询提供了Hive和Presto两个...
  • 固化查询:指对一些固化下来的取数、看数的需求,通过数据产品的形式提供给用户,从而提高数据分析和运营的效率。这类需求的SQL有固定的模式,对响应时间有比较高的要求。我们针对即席查询提供了Hive和Presto两个...
  • 本文的文字及图片来源于网络,仅供学习...每天麻木地更新,发出来也没人看,需要数的时候还是临时取数? 答:因为光有数据,没用配解读数据的方法! 数字要读出含义才有价值。结构分析法,就是解读数据的一种简单、快捷
  • 临时取数分析,比如双11大促活动分析;产品的流量转化情况、产品流程优化分析,等等;  b.报表需求分析--比如企业常见的日报、周报、月报、季报、年报、产品报表、流量转化报表、经营分析报表、KPI报表等等;  c...
  • 临时取数分析,比如双11大促活动分析;产品的流量转化情况、产品流程优化分析,等等; b.报表需求分析–比如企业常见的日报、周报、月报、季报、年报、产品报表、流量转化报表、经营分析报表、KPI报表等等; c.业务...
  • 临时取数分析,比如双11大促活动分析;产品的流量转化情况、产品流程优化分析,等等;b.报表需求分析--比如企业常见的日报、周报、月报、季报、年报、产品报表、流量转化报表、经营分析报表、KPI报表等等;c.业务...
  • 随机数 需求:输出十个随机数,并且比较得出最大值和最小值 ...//这时候不能 min=0,所有的都比min=0大 int num = 0;//用于接收随机数 Double a = 0.0;//用作临时变量,代替 Math.rando...

空空如也

空空如也

1 2 3 4
收藏数 65
精华内容 26
关键字:

临时取数需求