者按:以前有个关于编程语言的段子是这么说的:写C的看不起写C++,写C++的看不写java的,写java的看不起写JS的,写JS看不起美工,周末大家都在加班,美工带着女朋友旅游去了。这么看来JavaScript已经落到编程语言鄙视链的最底端去了。但是这门长期位于十大编程语言行列的语言早已经发展到几乎无所不能的地步了,不信可以看看Raphaël Benitte、Sacha Greif与Michael Rambeau所做的2017年JavaScript现状报告。
我最近公布了我们2017年版的JavaScript年度现状调查报告的结果,这是23000位开发者的共同反馈。
从流行趋势到工资明细,结果揭示了很多事情。如果你还没有这么做的话最好自己进来看看。但是在所有这些数据当中,有10件事情是最重要的。
即便你还没有看过这些结果,你可能也想看看我们刚刚增加的新的功能和观点部分。
洞察#1:React站稳脚跟
今年的版本确认了去年的趋势:React目前是占据主导地位的前端库。
React拥有目前为止最快乐的用户(深紫色条块)
对React的早期指责(通常集中在React混合HTML与JS的方式上)现在似乎已成遥远的记忆,Facebook还搁置了开发者今年最后一个主要的烦恼——取消了他们版权协议里面的专利条款。
随着使用数量和开发者满意度达到了有史以来的新高,完全可以说React已经站在了山顶上,至少目前是这样。
洞察#2:Angular正朝着新的角色转变
这并不意味着你就可以将Angular判负了。是,Angular的势头没有像React那么强劲,但是它还有一些非常强的因素支撑。
首先,Angular背后有Google力量的支持。不管你怎么说,那都是业界最好的工程师之一,他们正在投入全职的时间来改进这个框架。
需要指出的重要一点还包括Angular仍然拥有庞大的用户群。对于这股最新的热潮,银行、政府已经其他大型公司没法像你们这些普通的自由职业者接受得那么快,出于这个原因他们往往有庞大的遗留Angular代码库需要维护。
“新”Angular(2+)于“老”Angular(AngularJS)对比:接受度更低,但开发者满意度更高
不过最后一点也许是最关键的:Angular不再尝试跟React硬碰硬了,而是相反把自己的焦点转移到企业市场。只需要看看Angular对TypeScript的采用就知道了:尽管这也许会阻止了一些开发者,但这样决定也带来了企业应用所需的那种可靠性和安全性。
洞察#3:你再也不能忽视Vue.js了
Vue去年好像突然之间就冒了出来,并且在非常短的时间内为自己赢得了React最大威胁者的称号。它也许没有Angular的用户规模或者Ember的长寿,但却有着足以击败这两个的东西:势头。
Vue & React:这两个拥有最高的开发者满意度(浅紫色 vs 深紫色)
尽管Vue击败React似乎仍然不大可能,但毋庸置疑的是,在提供全框架式体验方面,Vue的确拥有更好的故事,而这要得益于由同一支核心团队维护的官方路由和状态管理库。
洞察#4:了解一些库的知识会帮你赚更多(但是原因不像你想的那样)
通过收集和交叉引用工资数据,我们得以找出哪一项技术是最赚钱的。
不同的JavaScript技术,按照薪水从低(左)到高(右)排列
如结果表明那样,往往是像Polymer或者Reason这样的小众技术跟最高薪水相关。
JavaScript前端库,按照薪水从低(左)到高(右)排列
尽管Polymer获得的薪水更高是可能的,但更资深的开发者(这些人往往赚得更多)往往尝试更多不同的库也是有可能的,而经验不足的程序员更愿意把经理集中在一或两种主流技术。
因此按照这份排行榜去学东西可能(只是可能)并不是赚得更多的关键。
洞察#5:2018年将成为GraphQL之年
如果你跟绝大部分的调查受访者一样的话,你应该已经听说过GraphQL并且对它饶有兴趣了,但其实你还没有尝试过。
REST希望自己也有个这么酷的logo
如结果表明那样,这是一个非常常见的情况。在这次调查提到的所有技术里面,GraphQL是引起兴趣最大的一个——尽管目前它的用户数量还很少。
大大的黄色条代表的是14000位对GraphQL感到好奇的开发者
说到当前用户,值得指出的是透明总体上都对GraphQL感到高度满意。有了这里的高度兴趣和高度满意的结合,如果2018年成为GraphQL超越鸿沟进入成为主流技术之年的话不要感到吃惊。
洞察#6:JavaScript != 前端
我们知道JavaScript不仅仅能用在浏览器里面已经不是一天两天的事情了。毕竟,Node就是一种非常流行的后端选择,已经流行了好几年了。
但2017年JavaScript又开始了进一步的扩张:像AWS Lambda这样的平台让你可以在没有后端的情况下编写后端代码,而物联网设备的日益流行意味着不久之后,你的烤面包机也很有可能最终跑的是JavaScript。
这台烤面包机利用运行Slack的桌面应用产生的热量来烤面包
如果这听起来很荒谬,记住今年最热门的文本编辑器,VS Code本身就是用JavaScript编写并且作为Electron应用运行的。
JavaScript从作为展示横幅广告的工具发展成文本编辑器的编写工具,这一切都是在几年之内发生的的事。相信我,JavaScript烤面包机的出现也许比你想象的要早。
洞察#7:微软正在反击
说到VS Code,这绝对是今年的一大惊喜。在Sublime Text和Atom正在为文本编辑器的王座争得不可开交时,新进入者VS Code破窗而入,偷走了它们额午餐。
过去Sublime Text往往有速度上的优势,但却被不直观的UI抵消掉了,而Atom有着很好的UI但是往往给人很慢的感觉。
VS Code编辑器
结果表明VS Code也许已经找到了这两者的适当平衡。尽管还是在类似Atom这样的Electron基础上开发出来的,但微软的工程师在改进性能方面做了很好的工作。就像Sublime一样,它支持范围很广的各种插件和定制化,尽管一个更为用户友好的软件包“刚好能用”。
再加上TypeScript的崛起,看起来微软终于把自己玩的web工具凑到一起了,并且证明了自己可以做出开发者用的东西了,而且开发者用是因为自己想用而不仅仅是因为他们只能用这个。
洞察#8:世界各地的JavaScript都不一样
当我们讨论JavaScript时,我们往往把它当作一个统一的生态体系来讨论。尽管重要趋势不同地区都是一致的,但有趣的是不同的国家往往会给JavaScript添加一些自己的定西进去。
比方说,你知道Vue在中国极其流行吗?这是说得过去的,因为Vue的开发者Evan You就讲中文,而且Vue已经为多家中国的主流技术公司如阿里和百度所采用。
印度另一方面似乎特别钟爱Angular。这也许至少部分是由于印度活跃的外包业所推动,而外包往往盯住那种Angular所应用的大型企业项目。
洞察#9:类型化JavaScript正在崛起
TypeScript、GraphQL、Elm、Reason,这些之间有何共同点?首先,它们都是先进技术,正在迅速发展。其次,它们都依赖于类型。
名字前正好有个“Type”。
尽管JavaScript开发者很久以来一直在享受着不用理会编译器对你的吼叫随心所欲写代码的自由,但是这种自由是一把双刃剑:这也意味着不那么可靠问题更多的开发者体验。
但到了2017年,情况终于开始改变。TypeScript获得更广泛的认同并不仅仅是个巧合,开发者也开始朝着VSCode之类的IDE式文本编辑器迁移,从而更好地利用类型提供的额外功能。
洞察#10:百变JavaScript
再次地,这次的调查表明了JavaScript的生态体系已经变得如何的丰富。
似乎经过多年时而批斗时而无视JavaScript之后,开发者社区终于突然想到了第三个选项:改进它。
这也许是为什么大多数开发者同意尽管有缺陷,但这门语言总体而言正在朝着正确的方向前进的原因:
编译组出品。编辑:郝鹏程。
xcel 中遇到较复杂的运算,数据分析师常会用 add-ins 辅助解决。本文考察了一些常见的 add-ins,从部署难度、开发难度、流畅程度等方面进行深度对比,并着重考察了数据计算能力,esProc 在这些 add-ins 中的表现相对出色。点击辅助 Excel 的数据计算 add-ins了解详情。
对于大多数简单运算,Excel都提供了方便的实现手段,有时是易用的函数,有时是直观的按钮或菜单。但我们还是会遇到的一些较复杂或特殊的运算,依靠Excel本身很难实现。Excel提供了add-in接口,可以通过这个接口执行外部程序,从而借助外部语言或脚本实现这些较复杂或特殊的运算,达到辅助Excel的目的。
下面,让我们深入了解一些Excel的常见数据计算add-ins,并评估它们的计算能力。
Excel DNA是早期出现的一款Excel add-in,它可以把程序员写好的动态库函数放到Excel里使用,动态库可以使用C#/F#/VB.net等语言等编写。
具体用法上,Excel DNA和其他所有add-ins都类似,首先要编写自定义函数。比如下面C#编写的代码中(引自Excel DNA官网),MyFunction是自定义函数名。
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using ExcelDna.Integration;
namespace MyLibrary
{
public class Class1
{
[ExcelFunction(Description="few people use this way!")]
public static string MyFunction(string name)
{
return "Bonjour" + name;
}
}
}
上面的代码须编译成动态库,之后才能在Excel中使用。
接下来,一般要配置自定义函数和add-in的关系。比如下面的DnaSample.dna文件,表明本add-in的名字是"My name",对应的动态库是Mylibrary.dll(含有多个自定义函数)。
<DnaLibrary Name="My name" RuntimeVersion="v4.0">
<ExternalLibrary Path="Mylibrary.dll" />
</DnaLibary>
最后在Excel中配置该add-in,就可以在单元格中调用MyFunction这个函数了,如下:
应该注意到,上述过程有个编译的动作,因为编译过的程序可直接执行,且与Excel集成紧密,因此执行效率非常高。这便带来了Excel DNA最大的优点:顺滑无卡顿。
Excel DNA的其他优点从名字就可以看出来,换句话说,该add-in可以充分利用微软DNA架构提供的便利,比如开发语言、开发工具、Excel集成、联动调试等。
还应该注意到,C#/F#/VB.net等语言的通用性很强,理论上是无所不能的,但官网的代码例子却只是字符串输出,体现不出哪怕丝毫的能力,这到底是为什么呢?
因为理论和实际是有差别的。
C#/F#/VB.net等语言缺乏结构化计算类库,即使最基本的运算都要硬编码实现,代码因此非常繁琐,并不适合做复杂的数据计算。
除了不适合数据计算,还应注意到C#/F#/VB.net是编译型语言,而不是解释型语言,这就要求用户必须维护一套编译环境,以备修改算法后编译所用,而微软的编译环境配置较复杂,桌面数据分析师不易掌握。事实上,C#/F#/VB.net等语言本身的技术门槛就很高,这就导致Excel DNA更适合专业程序员作为接口使用,并不适合大多数桌面数据分析师直接使用。
除了Excel DNA,还有其他一些add-ins同样缺乏结构化计算类库,比如基于JAVA语言的JINX。很容易就能判断出,JINX也不适合数据计算。事实上,Excel自带的VBA在语言能力上和Excel DNA/JINX相当(都不适合数据计算),但VBA免集成免编译,比Excel DNA/JINX更有竞争优势。
显而易见,无论什么add-ins,至少要比VBA方便好用,才值得我们学习研究。微软也发现了这个问题,所以2013年推出了Excel JavaScript,一种比VBA更方便的add-ins专用语言。
Excel JavaScript的用法和其他add-ins类似,这里以及后续都不再赘述。值得强调的是,Excel JavaScript是解释型语言,可以随时修改并立即执行,而无需编译,这一点和Excel DNA区别较大。既然是解释型语言,一般就会存在卡顿问题,但Excel JavaScript是Excel内置的语言,可以在同一个进程中执行,因此实际效果非常顺滑,执行效率仅次于Excel DNA。
内置于Excel还会的带来其他好处,比如无需下载,可直接开发,这便省去了繁琐的部署过程。再比如Excel JavaScript继承了Excel跨平台的能力,只需编写一次,就可以在单机版、网页版、Mac版上无缝迁移。另外,Excel JavaScript可直接访问workbook、sheet、cell等Excel对象,开发效率显著提升。
等一下,上面说的虽然都是Excel JavaScript的优势,但好像VBA也具备同等的优势,所以,说好的“更方便”到底体现在哪里?
比VBA更方便,体现在Excel JavaScript的界面控制能力上。换句话说,Excel JavaScript可以用更简单的语法访问Excel菜单栏、面板按钮、弹出框,可以在JS文件中直接定义add-ins界面,比VBA方便太多了。
唯一的问题是,界面控制并非数据计算add-ins的重点,不值得我们关注……
不错,既然讲的是数据计算add-ins,那数据计算能力才是关注重点,而不是界面控制能力。但遗憾的是,JavaScript依然没有任何结构化计算函数,用于做Excel都难以实现的数据计算也没啥特别的优势,仅仅是让Excel多了一种不同于VBA的脚本语言而已。
显然,只有具备结构化计算类库,才算是合格的数据计算add-ins,比如这里要讲的pyxll。Pyxll是基于Python语言的add-in,而Python拥有结构化计算类库Pandas。
既然是合格的数据计算add-in,pyxll实现简单算法时自然无需硬编码,比如对指定区域分组汇总:选中Excel中的一批员工记录,传给自定义函数groupEmp,由pyxll执行分组汇总算法,并返回计算结果,只需编写如下代码:
import pandas as pd
import numpy as np
from pyxll import xl_func
@xl_func("dataframe<index=False, columns=True>")
def groupEmp(df):
df=df.groupby("deptid")['salary'].agg([len, np.sum, np.mean]) #核心代码:分组汇总
return df
上面核心代码只有一行,其他代码基本都是定式。可以看到,具备结构化库函数的pyxll,可以用非常简洁的代码实现分组汇总等简单算法。
当然,有时也会遇到较复杂或特殊的运算,需要用多个函数组合实现,而不是单独使用排序、过滤之类基本函数。遗憾的是,pyxll实现较复杂或特殊的运算时不太方便。
比如规范化数据并分组汇总的例子:针对Excel中的住户户型明细表(A-E列),自定义函数需按STYLE和BEDROOMS分组,统计SQFEET、BATHS、PRICE的平均值,其中PRICE列原本是字符串,需去掉$符号,转为数值再计算。
处理前数据
处理后的数据在新sheet中。
实现上述算法的自定义函数如下(只保留核心代码):
for i in range(1, len(b)):
b[i][4] = b[i][4].replace(“$”,‘ ‘)
b[i][4] = b[i][4].replace(“,”,‘ ‘)
for i in range(1, len(b)):
for j in [1, 2, 3, 4]:
b[i][j] = eval(b[i][j])
data = pandas.DataFrame(b[1:],columns=b[0])
out = data.groupby([‘STYLE’,‘BEDROOMS’]).mean()
return out
分组还是只有一句,但前面的预处理却要6行,有点麻烦。
再比如一行分多行的例子:A列存储ID,B列存储ID对应的列表List,List有多个成员,以空格为分隔符。自定义函数需将List按空格拆分,使每个ID对应一个成员。
处理前的数据
处理后的数据在新sheet中:
实现上述算法的自定义函数如下:
split_dict = df.set_index('ID').T.to_dict('list')
split_list = []
for key,value in split_dict.items():
anomalies = value[0].split(' ')
key_array = np.tile(key,len(anomalies))
split_df = pd.DataFrame(np.array([key_array,anomalies]).T,columns=['ID','ANOMALIES'])
split_list.append(split_df)
df = pd.concat(split_list,ignore_index=True)
return df
可以看到,即使只保留核心运算功能,pyxll的代码仍然有点复杂。这就是pyxll缺点之一:不擅长实现较复杂或特殊的运算。
pyxll还有一个缺点:Excel要调用外部解释器来解释Python脚本,因此顿挫感较强烈,会严重影响用户体验。当然,顿挫并非pyxll独有的问题,而是所有外部解释型脚本共通的问题,比如XLwings、Bert和RExcel。其中XLwings与pyxll同样是基于Python的add-ins,优缺点基本一样。Bert和RExcel是基于R的add-ins,R专注于科学模型算法,其结构化计算类库不够专业,因此这两款add-ins的计算能力还不如pyxll,顿挫感也会更强。
当然,解释型语言也有优点,最大的优点是无需编译即可执行,维护修改都很方便。
esProc是专业的数据计算引擎,也提供了一个Excel add-in,可以使用esProc的SPL语言编写计算脚本。它与pyxll有很多相似之处,比如两者都有丰富的结构化计算函数,因此可以轻松实现简单算法,比如对指定区域分组汇总,只需编写脚本groupEmp.dfx:
核心代码只有A2一行,非常简洁。之后就可以在Excel单元格中引用自定义函数groupEmp,形如=dfx("groupEmp",A1:D20)。
其他基本算法也可以轻松实现(只留核心代码):
通过了解之前的add-ins,我们已经可以得出结论:是否能方便地实现较复杂或特殊的运算,才是判断一款add-in的数据计算能力的真正指标。
esProc能够方便地实现较复杂或特殊的运算,这是它比pyxll更有优势的地方。
比如规范化数据并分组汇总,前面用pyxll时显得很麻烦,但esProc就简单多了:
再比如一行分多行,esProc代码更简单:
再举个逻辑更复杂的例子:计算分期贷款明细。Excel单元格记录着贷款信息,包括贷款ID,贷款总额、按月分期数、年利率,示意如下:
自定义函数的目的是计算出各期明细,包括:当期还款额、当期利息、当期本金、剩余本金。计算结果在新sheet 中应当如下:
上面的算法用pyxll实现会很麻烦,但esProc就很方便:
看起来esProc的数据计算能力确实很强大,但是,非常遗憾的是,esProc也是基于外部解释器的add-in,还需要JVM来执行,它同样存在卡顿的问题。
有没有办法既能利用esProc强大的计算能力,还能顺滑地操作esProc?
用剪贴板代替自定义函数!
比如求各科前3名的学生:A列是学生姓名,B-D列分别是数学、英语、物理成绩,需要求出每学科成绩前3名的学生,并追加到本科成绩之后。
处理前数据
选中这些单元格,先用ctrl+C复制到剪贴板,再在esProc脚本中执行如下代码:
执行上述脚本后,只需在Excel的B11格用ctrl+V,即可将剪切板中的数据复制到B11-D13,达到和自定义函数相同的效果,如下:
类似的,大多数自定义函数都可以用剪切板简单代替,除非遇到一些特殊情况,比如多片区域参与运算。
应该注意到,上述过程虽然可以到达顺滑操作的目的,也可以利用到esProc强大的计算能力,但并没有使用add-in协议。事实上,如果愿意使用剪切板,就没必要部署复杂的add-ins,这对数据分析师来说,难道不是一件减轻负担的好事吗?
还应该注意到,不仅esProc可以利用剪贴板来解决卡顿的问题,pyxll等add-ins理论上也完全可以,只要它们在将来的版本中提供类似的函数(从剪切板获取数据并转换成内部的结构化数据类型)。
经过前面的比较,我们可以得出这样的结论:流畅的add-ins计算能力差;计算能力强的add-ins存在卡顿现象。配合剪切板使用esProc可以弥补卡顿的缺点,更适合桌面分析师使用。
何解读从数据需求到数仓构建的整体流程?这篇文章里,作者结合实际案例,从需求分析、可视化看板设计、数据采集、数仓规划、维度建模等方面进行了描述和拆解,不妨来看一下,或许会对你有做帮助。
最近发文章,发现在文章中有插入广告功能,假设广告插入为新上线的新功能。
曝光环节:每次刷新,都会有不同的内容。如下图所示:
具体落地页,大家可以自己点击看看。
功能上线一个月后,老板想看看该功能带来了多少营收?
运营人员希望分析广告投放、广告曝光、落地页曝光、支付页、支付成功转化链路的转化情况?
本文以此为背景,从需求分析、可视化看板设计、数据采集、数仓规划、维度建模等几个阶段去描述数据需求到数仓构建的整体流程。
了解清楚业务问题和目标后,搞清楚数据怎么定义和描述这个问题?列出结果指标和过程指标,确定指标的展现形式。
需要整体分析各角色之间存在的各类要素流动关系。
根据业务调研及业务目标,使用不同的数据分析分析方法列出指标体系,最终大致遵循常用指标分类方式。
需求调研可以从以下角度出发:
1)根据与分析师、业务运营人员的沟通获知需求。
2)了解以前的报表,对现有报表系统中的报表进行研究分析,了解关键性指标。
在筛选指标时,需要考虑指标的数据来源、数据质量、数据可靠性等因素。在此过程中,需要补充数据来源系统,来源表,来源字段,计算方式等。
1)卡片展示内容:指标名称、统计口径、指标值、指标单位、统计日期、同比值、环比值、更新时间。
筛选条件:日期、支持选择今日、昨日、本周、上周、本年、去年、最近7天、最近30天等等。不能选择今天及以后。
2)支付情况日变动趋势图
筛选条件:日期范围。支持选择今日、昨日、本周、上周、本年、去年、最近7天、最近30天等等。不能选择今天及以后,支持按日、按月、按年去对比。
3)下单转化漏斗
筛选条件:日期范围,支持选择今日、昨日、本周、上周、本年、去年、最近7天、最近30天等等。不能选择今天及以后。
可选统计方式:次数/人数
数据采集前需要考虑以下两点。
1)熟悉业务数据:明确业务过程与表之间的关系,表与表之间的关系,字段之间的关联关系。
2)调研数据源情况:是否具备采集条件,数据库类型,存储格式,通过什么方式采集。对缺失的用户行为数据进行埋点。
埋点时需根据不同埋点类型以及业务情况选择合适的埋点方案和前后端采集方案。
标准埋点方案一般由 4 张表组成:
公共属性:
自定义事件&属性:
在设计埋点前,可做一些埋点文档和埋点评审的规范定义,方便文档的维护和工作的开展。
比如:事件命名由 4 部分组成:类型_流程_页面_功能。
未了保障数据的准确性,需注意触发时机和规则定义:比如什么样的曝光是有效的?商品停留时间超过2s,卡片至少漏过50%。商品曝光重复:如果之前已经可见且上报了,那么不做二次上报等规则。
在构建数仓前,需要对数仓进行整体规划,包括:
操作数据层:ODS(Operational Data Store):把操作系统数据几乎无处理地存放在数据仓库系统中。
事实明细层:DWD(Data Warehouse Detail):DWD 层是在ODS层基础上,根据业务过程建模出来的事实明细层。
公共汇总层:DWS(Data Warehouse Summary):一般根据维表数据和明细事实数据加工生成,作为通用的数据模型使用。
应用数据层:ADS(Application Data Store):存放数据产品个性化的统计指标,根据明细层、汇总层及维表数据加工生成。
想了解更多数仓分层可查阅上篇文章《带你轻松理解数仓为啥分层?》https://www.woshipm.com/share/5892372.html
我们选择按照业务过程划分主题域:划分的前提,先理清业务过程,根据业务过程去抽象出主题,比如浏览,曝光,点击,都属于用户行为的业务过程,就可以划分成流量主题。
想了解更多主题域规划可查阅《如何理解主题域?》。
在数据仓库领域中,业务总线矩阵是一种用于设计和组织数据仓库的业务模型的工具。它是基于业务需求和业务过程的分析,明确业务过程与维度的关系。它帮助将业务需求转化为数据模型,并指导数据仓库的建模和设计过程。
从该业务矩阵中,我们可以得知需要建设哪些DIM层维度表,DWD层的事实表。
指标的拆分是运算过程的拆分,维度模型里的指标拆分是一种思路,是模型设计很重要的一环。想了解更多可看《原子指标、派生指标、复合指标》。
原子指标:不可再分的指标。
派生指标:派生指标是由原子指标、时间周期、修饰词构成,用于反映企业某一业务活动在指定时间周期及目标范围中的业务状况。
复合指标:由派生指标直接运算而来,通常是比率型指标。比如最近七天广告点击率,他的特点就是产生了新的原子指标。
根据业务总线矩阵,可构建用户维度表、时间维度表、地理位置维度表等等。
日期维度表示例:
此处拓展事实表构建流程。
事实表说明:
事实表包括:事务型事实表、周期快照事实表、累积快照事实表。
1)选择业务过程及确定事实表类型
业务过程定义:业务过程是从企业的经营收益、成本出发,价值链条上有影响力的用户需求事情或者事件。而且,这样的过程非常多,我们要分析当中的核心关键过程,不断细分。
核心内容:企业活动事件、不可拆分原则。
2)声明粒度:定义事实表的每一行所表示的业务含义,尽量选择最细级别的原子粒度,以确保事实表的应用具有最大的灵活性。
3)确定维度:选择能够描述清楚业务过程所处的环境的维度信息。
4)确定事实:事实有可加性、半可加性、非可加性三种类型 需要将不可加性事实分解为可加的组件。
5)冗余维度:考虑更多的是提高下游用户的使用效率,降低数据获取的复杂性,减少关联的表数量。
文章阅读事实表:
页面浏览事实表:
下单累计快照事实表:
交易域每日支付汇总表:
流量域每日曝光汇总表:
根据需求,汇总表还需要统计每月、每年、近7天、近30天等数据汇总情况,此处不做过多表格展示。需要注意命名规范以及事实是否可加。
*请认真填写需求信息,我们会在24小时内与您取得联系。