报告显示，GPT-4的成本不但远比人类分析师低廉，效率也快上不少。不过，GPT-4的图表正确度、部分个案的报告呈现及格式表现不如人类。

部分案例中，GPT-4在数据、分析正确度的表现优于人类分析师，产出的洞见也较深入。 不过，GPT-4的图表正确度、部分个案的报告呈现及格式表现不如人类。 然而，虽有某些图表的数据出错，GPT-4仍可产出正确分析。 报告提醒，仍需进一步研究才能确定GPT-4能完全取代数据分析师。

你没看错，是百分之零点七一，不是百分之七十一。

按新加坡行情，年薪 8.6 万-9 万美元 (60-63 万人民币）的高级数据分析师，换成 GPT-4 就只需要三四百美元（2000 多人民币）了。

这项结论来自阿里达摩院与新加坡南洋理工大学的新论文，被网友评价为对 AI 和数据分析领域感兴趣的必读论文。

具体来说，结论中高级分析师指在金融行业拥有多年工作经验的数据分析师。

而 GPT-4 的表现，在大多数指标上能与一位 6 年工作经验的人类相当，正确性低于人类，但复杂性和一致性指标高于人类。

在与另一位 5 年工作经验的分析师对比中，GPT-4 在信息的正确性、图表的美观性、洞察的复杂性等方面输给人类。

如果与 2 年工作经验的初级分析师对比，GPT-4 在正确性上表现更好，而且能完成更多的工作。

但 GPT-4 完成所有类型的任务都要比人类快得多。

在假设每个月有 21 个工作日，每天 8 小时工作时间，按市场价支付工资的前提下，得出最终结论。

GPT-4 当数据分析师，都能干什么

论文重点考察了 GPT-4 作为数据分析师的以下几种能力：

• 生成 SQL 和 Python 代码
• 执行代码获得数据和图表
• 从数据和外部知识源中分析数据，得出结论

200 个样本的实验表明，对于绘制图表任务，GPT-4 能够理解指令含义，且对图表类型有一定背景知识，从而绘制出正确的图表。

图表大部分清晰可见，没有任何格式错误，图标的美观性指标满分 3 分，GPT-4 平均得分 2.73。

但手工检查还是能发现一些小错误，图表准确性指标满分 1 分，GPT-4 平均得分 0.78。

论文中特别说明他们的评估标准非常严格，只要 x 轴或 y 轴的任何数据或任何标签有错误，都要扣分。

对于数据分析任务，GPT-4 在一致性和流畅性中平均得到满分，验证了生成流畅且语法正确的句子对 GPT-4 来说绝对不是问题。

有意思的是，到了数据分析这一步的准确性要比图表信息的准确性高得多，说明尽管 GPT-4 画了错误的图表但分析出了正确的结论。

在案例分析中，研究团队还总结出三条 GPT-4 与人类数据分析师的主要区别：

• 人类分析师可以用个人思想和情感来表达，比如在分析时写“令人惊讶的是……”；人类读者容易从这样的表述中理解数据是符合预期还是不正常的。
• 人类分析师倾向于结合背景知识得出结论，如写到“…… 常见于……”；GPT-4 通常只关注提取到的数据本身，允许 GPT-4 上网搜索实时在线信息可以改善这一点。
• 当提供见解或建议时，人类分析师倾向于保守，如声明“假如数据没有问题的话……”；GPT-4 会以自信的语气直接给出建议，不会提及假设。

另外团队表示，由于预算有限，主要是雇一个来与 GPT-4 对比的高级分析师太贵了，人工评估和数据标注的数量相对较少。

在最后的结论则是：

实验结果和分析表明，GPT-4 在数据分析上有与人类相当的性能，但是否可以取代数据分析师需要近一步研究才能得出结论。

论文：

https://arxiv.org/abs/2305.15038

本文来自微信公众号：量子位 （ID：QbitAI），作者：梦晨

自

简而言之就是有目的的收集数据、分析数据，使之成为信息的过程。

数据分析过程1、探索性数据分析

初步获取的数据是杂乱无章的，通过图表形式对数据进行整合，找寻数据之间存在的关系。

2、模型选定分析

通过探索性数据分析，归纳出一类甚至是多类数据模型，通过对模型再次整合，进一步分析出一定的模型。

3、推断分析

通常使用数理统计方法对所定模型或估计的可靠程度和精确程度作出推断。

数据分析流程

完整数据分析流程图

1. 识别信息需求

识别信息需求是确保数据分析过程有效性的首要条件，可以为收集数据、分析数据提供清晰的目标。

2.数据采集

了解数据采集的意义在于真正了解数据的原始面貌，包括数据产生的时间、条件、格式、内容、长度、限制条件等。帮助数据分析师更有针对性的控制数据生产和采集过程，避免由于违反数据采集规则导致的数据问题；同时对数据采集逻辑的认识增加了数据分析师对数据的理解程度，尤其是数据中的异常变化。

在数据采集阶段，数据分析师需要更多的了解数据生产和采集过程中的异常情况，能很大程度上避免“垃圾数据进导致垃圾数据出”的问题。

2.数据存储

在数据存储阶段，数据分析师需要了解数据存储内部的工作机制和流程，最核心的因素是在原始数据基础上经过哪些加工处理，最后得到了怎样的数据。由于数据在存储阶段是不断动态变化和迭代更新的，其及时性、完整性、有效性、一致性、准确性很多时候由于软硬件、内外部环境问题无法保证，这些都会导致后期数据应用问题。

3.数据提取

数据提取是将数据取出的过程，数据提取的核心环节是从哪取、何时取、如何取。

在数据提取阶段，数据分析师首先需要具备数据提取能力。常用的Select From语句是SQL查询和提取的必备技能，但即使是简单的取数工作也有不同层次。

第一层是从单张数据库中按条件提取数据的能力，where是基本的条件语句；

第二层是掌握跨库表提取数据的能力，不同的join有不同的用法；

第三层是优化SQL语句，通过优化嵌套、筛选的逻辑层次和遍历次数等，减少个人时间浪费和系统资源消耗。

4.数据挖掘

数据挖掘是面对海量数据时进行数据价值提炼的关键，以下是算法选择的基本原则：

没有最好的算法，只有最适合的算法，算法选择的原则是兼具准确性、可操作性、可理解性、可应用性。

没有一种算法能解决所有问题，但精通一门算法可以解决很多问题。

挖掘算法最难的是算法调优，同一种算法在不同场景下的参数设定相同，实践是获得调优经验的重要途径。

在数据挖掘阶段，数据分析师要掌握数据挖掘相关能力：一是数据挖掘、统计学、数学基本原理和常识；二是熟练使用一门数据挖掘工具，Clementine、SAS或R都是可选项，如果是程序出身也可以选择编程实现；三是需要了解常用的数据挖掘算法以及每种算法的应用场景和优劣差异点。

5.数据分析

分析数据是将收集的数据通过加工、整理和分析、使其转化为信息，通常所用的方法有：

老七种工具，即排列图、因果图、分层法、调查表、散步图、直方图、控制图；

新七种工具，即关联图、系统图、矩阵图、KJ法、计划评审技术、PDPC法、矩阵数据图；

数据分析相对于数据挖掘更多的是偏向业务应用和解读，当数据挖掘算法得出结论后，如何解释算法在结果、可信度、显著程度等方面对于业务的实际意义，如何将挖掘结果反馈到业务操作过程中便于业务理解和实施是关键。

6.数据可视化

数据分析界有一句经典名言，字不如表，表不如图。别说平常人，数据分析师自己看数据也头大。这时就得靠数据可视化的神奇魔力了。除掉数据挖掘这类高级分析，不少数据分析师的平常工作之一就是监控数据观察数据。

7.数据应用

数据应用是数据具有落地价值的直接体现，这个过程需要数据分析师具备数据沟通能力、业务推动能力和项目工作能力。

数据沟通能力。深入浅出的数据报告、言简意赅的数据结论更利于业务理解和接受。

业务推动能力。在业务理解数据的基础上，推动业务落地实现数据建议。

项目工作能力。数据项目工作是循序渐进的过程，无论是一个数据分析项目还是数据产品项目，都需要数据分析师具备计划、领导、组织、控制的项目工作能力。

附：数据分析常用方法

1、描述性统计分析

包括样本基本资料的描述，作各变量的次数分配及百分比分析，以了解样本的分布情况。

此外，以平均数和标准差来描述市场导向、竞争优势、组织绩效等各个构面，以了解样本企业的管理人员对这些相关变量的感知，并利用t检验及相关分析对背景变量所造成的影响做检验。

2、Cronbach’a信度系数分析

信度是指测验结果的一致性、稳定性及可靠性，一般多以内部一致性（consistency）来加以表示该测验信度的高低，信度系数愈高即表示该测验的结果愈一致、稳定与可靠。

针对各研究变量的衡量题项进行Cronbach’a信度分析，以了解衡量构面的内部一致性。一般来说，Cronbach’a仅大于0.7为高信度，低于0.35为低信度（Cuieford，1965），0.5为最低可以接受的信度水准（Nunnally，1978）。

3、探索性因素分析（exploratory factor analysis）和验证性因素分析（confirmatory factor analysis）

用以测试各构面衡量题项的聚合效度（convergent validity）与区别效度（discriminant validity），因为仅有信度是不够的，可信度高的测量，可能是完全无效或是某些程度上无效，所以我们必须对效度进行检验。

效度是指工具是否能测出在设计时想测出的结果，收敛效度的检验根据各个项目和所衡量的概念的因素的负荷量来决定，而区别效度的检验是根据检验性因素分析计算理论上相关概念的相关系数，检定相关系数的95%信赖区间是否包含1.0，若不包含1.0，则可确认为具有区别效度（Anderson，1987）。

4、结构方程模型分析（structural equations modeling）

由于结构方程模型结合了因素分析（factor analysis）和路径分析（path analysis），并纳入计量经济学的联立方程式，可同时处理多个因变量，容许自变量和因变量含测量误差，可同时估计因子结构和因子关系，容许更大弹性的测量模型，可估计整个模型的拟合程度（Bollen和Long，1993），因而适用于整体模型的因果关系。

在模型参数的估计上，采用最大似然估计法（Maximum Likelihood，ML）；在模型的适合度检验上，以基本的拟合标准（preliminary fit criteria）、整体模型拟合优度（overall model fit）以及模型内在结构拟合优度（fit of internal structure of model）（Bagozzi和Yi，1988）三个方面的各项指标作为判定的标准。

在评价整体模式适配标准方面，本研究采用x2（卡方）/df（自由度）值、拟合优度指数（goodness．of．f：iJt．in．dex，GFI）、平均残差平方根（root—mean．square：residual，RMSR）、近似误差均方根（root-mean—square-error-of-approximation，RMSEA）等指标；模型内在结构拟合优度则参考Bagozzi和Yi（1988）的标准，考察所估计的参数是否都到达显著水平。

Benn Stancil认为数据分析工作不可能一蹴而就，分析师在使用数据库的过程中阻碍他们速度的往往不是宏观上的性能，而是编写查询语句时的细节。例如，在Redshift中如何获取当前时间，是NOW()、CURDATE()、CURDATE、SYSDATE 还是WHATDAYISIT。在Mode公司，分析师每天都会使用各种不同的语言编写几千个查询，运行在Mode编辑器里的查询超过百万个，而Benn Stancil就是从这些数据出发，对MySQL、PostgreSQL、Redshift、SQL Server、BigQuery、Vertica、Hive和Impala这八款数据库进行了比较。

首先，Benn Stancil认为查询错误是否容易解决是衡量数据库的一个最基本指标。数据库提供的错误信息（通常是语法错误、函数名错误、逗号错位等）最能表明该系统是否会对数据分析师造成极大的挫败感。通过对8种数据库查询错误频率的比较，Benn Stancil发现Vertica和SQL Server错误率最高，MySQL和Impala最低，如图所示：

但是，对于该结果Benn Stancil认为可能有点不严谨，因为Impala、MySQL和Hive是开源的免费产品，而Vertica、SQL Server和BigQuery不是，后三者的用户通常是有充足分析预算的大型企业，其较高的错误率很有可能是由于使用更深入而不是语言“更难用”。

除了错误率之外，Benn Stancil还讨论了复杂性。虽然不同语言其查询长度、查询复杂性和语言复杂性之间的关系盘根错节，要界定清楚很难，但可以间接使用查询长度作为度量的指标，因为一门语言之所以简单很有可能是因为它简洁。这八种数据库查询 长度的统计结果如下：

如果说单纯地比较最终的长度有失偏颇，那么可以看看随着分析的逐步深入，查询逐渐变复杂的过程中，其修改次数与长度之间的关系：

该图显示，经过20次左右的编辑之后，查询长度通常会变为之前的2倍，而在100次编辑之后，长度会变为之前的3倍。那么在修改的过程中，其编辑次数与出错的比率又是什么样子的呢？

从图中可以看出，PostgreSQL、MySQL和Redshift的错误率较低，Impala、BigQuery和SQL Server的错误率较高。另外，和之前一样，Vertica的错误率依然最高。

此外，Benn Stancil认为分析师的技能也很重要。他对使用多个数据库并且在每个数据库上至少运行了10个查询的分析师进行了统计，计算了这些分析师在每个数据库上的查询错误率，并根据统计结果构建了下面的矩阵：

该矩阵展示的是顶部数据库与左边数据库相比其错误率的差别，数值越高表现就越差。例如，Hive和BigQuery交叉处的“20.2”表示：对使用这两款数据库的分析师，其使用Hive的错误率要比使用BigQuery高20.2。最底部的Total行是结果总计，从中可以看出MySQL和PostgreSQL始终表现较好；Vertica跳跃最大，几乎是从最底部跳到了中游，打败了SQL Server 和Hive，这也暗示了Vertica的高错误率很可能是由于分析师的能力而不是语言本身。

最后，Benn Stancil认为在分析的这8个数据库中，MySQL和PostgreSQL编写SQL最简单，应用也最广泛，但与Vertica和SQL Server相比它们的特性不够丰富，而且速度要慢。综合各方面的因素，Redshift或许才是最好的选择。

1.机器学习已经在 Twitter 多个核心产品中扮演越来越重要的角色，而这之前完全是「机器学习」的禁区。最典型的例子就是「当你离开时」这个功能。当用户离开页面或者电脑，去干别的事情后再次返回页面，电脑会立刻给你推送出来某些由你关注的人所发出，而有可能被你错过的「优质内容」。

2.开发工具越来越优秀了。整个团队摆脱了对 Pig 的依赖，全新的数据管道是在 Scalding 中写出来的。

3.从团队组织上而言，Twitter 已经转向了一个嵌入式的模型中。其中数据分析比以往更加紧密地与产品/工程团队发生着联系。

在 Twitter 的工作确实是令人兴奋的，因为你能站在这个平台上，引领目前世界最前沿的数据科技，打造最具竞争力的优势。而同时，人们对于大数据的渴望也一天比一天高。

Dan Ariely 曾经有一句话说得特别好：

「大数据其实有点儿像青少年的性。每一个人都兴致勃勃地谈论它，但是没有任何一个人真的知道该怎么做。每一个人都觉得身边的人都在尝试，为了不落人后，于是每个人都在外面宣城自己也已经有『伴儿』了」

现 如今，有太多的人在如何成为一名优秀称职的数据分析师上表达着看法，给出自己的建议。Robert Chang 毫无疑问也是受益者。但是他回过头来再想想大家的讨论，会觉得人们往往更加侧重于去谈「技术」、「工具」、「技能组合」，而在 Chang 看来，那些东西确实很重要，但是让新人们知道数据分析师每一天的生活到底是什么样子的，具体的工作内容都是什么，这也非常重要。

于是，Chang 凭借着自己在 Twitter 工作两年的经历，以自己作为例子，首次打开 Twitter 数据分析师这扇神秘的大门。

A 型数据分析师 VS B 型数据分析师

Chang 在没来 Twitter 之前，总觉得数据分析师一定是在任何领域都能看堪称「独角兽」，不管是数据还是数学专业，都是顶尖人才。除了技术上很牛之外，书面写作和口头交流的能力也 会特别强。更重要的是他们能够分清楚当下工作的轻重缓急，领导和管理一个项目团队。是啊，如今本身就是以数据为主导的文化，作为「数据分析师」，当然要给 这个文化注入灵魂与活力啊！

在 Chang 加入 Twitter 的几个月后，他逐渐意识到：符合上述形容的「独角兽」确实存在，但是对于大部分人来说，上述的要求未免有点儿太不切实际了。人们没有办法做到面面俱到。后来，Chang 通过 Quora 中的一篇回答，更深刻地理解了数据分析师的角色。在那篇文章中，数据分析师分成了两种类型：

A 型数据分析师： 他们主要负责「分析」。 他们最关心数据背后的意义，往往使用统计等方式探知真相。其实他们的工作有点儿像「统计学家」，但是不一样的地方是，统计学专业涉及的内容他们统统掌握， 但是他们还会一些统计学课本里面压根不曾出现的内容：比如数据清洗，如何处理超大数据组，数据视觉化，有关数据层面的报告撰写等等。

B 型数据分析师：B 型负责「建造」。他们跟前一种分析师有着相似的统计学背景，但他们同时还是非常牛叉的程序员，又或者是训练有素的软件工程师。B 型数据分析师往往感兴趣于「如何利用数据来生产」。他们建立一些能够与用户互动的模型，往往以「推荐/推送」的形式出现，比如「你也许会认识的人」，「广告」，「电影」，「搜索结果」等等功能。

Chang 看到这样清楚的划分，非常后悔如果早几年有这么清楚的概念认识该多好啊。这样他就能够有选择性的发力，择其一方向来继续发展。这是数据分析师职场规划首先要考虑的标准。

Chang 的个人专业背景是「数学」、「运营研究」、「统计学」。所以他更倾向于把自己定位于 A 型数据分析师，但是与此同时他对 B 型分析师能够涉及那么多的工程开发工作而向往不已。

初创公司早期、快速发展的初创公司、以及实现规模化发展的初创公司中的数据分析师职位区别

在选择投身于科技行业的时候，最经常遇到的一个问题就是到底是加入一个大的科技公司好呢？还是加入一个小的科技公司好。在这个话题上已经有很多争论了，但是在「数据分析」上面的争论并不是很多。所以在本章节要具体谈到的是，不同公司的规模、发展阶段中，数据分析师不同的角色定位。

处于不同发展阶段的科技公司生产数据的量与速度都是不一样的。 一个还在尝试着寻找到「产品市场契合点」的初创公司完全不需要 Hadoop，因为公司本身就不存在多少的数据需要处理；而一个处在快速发展中的初创公司往往会遭遇更频密的数据冲击，也许 PostgreSQL 或者 Vertica 更适合这家公司的需要；而像 Twitter 这样的公司如果不借助 Hadoop 或者 Map-Reduce 框架，就完全无法有效地处理所有数据。

Chang 在 Twitter 学到的最有价值的一点内容就是：数据分析师从数据中提取出价值的能力，往往跟公司本身数据平台的成熟度有着密不可分的关系。如果你想要明白自己从事的是哪种类型的数据分析工作，首先去做做调研，看看你意向中的这家公司的底层系统架构能够在多大程度上支持你的目标，这不仅仅对你好，也对公司好，借此看你个人的职业发展目标是否跟公司的需要契合起来。

在初创公司早期，最主要的分析重点是为了实现 ETL 进程，模块化数据，并且设计基模架构，将数据记录应用到上面。这样数据就能够追踪并存储。此处的目标是打下分析工具的基础，而不是分析本身。，

在快速发展的初创公司的中期，因为公司在快速发展，那么数据也在不断的增长。数据平台需要适应不断发展的新形势，新条件，在已经打好基础的前提下，开始逐渐实现向分析领域的过渡。一般来说，此时的分析工作主要围绕着制定 KPI，推动增长，寻找下一次增长机会等工作展开。

实现了规模增长的公司。当公司实现了规模化增长，数据也开始呈几何倍数的增长。此时公司需要利用数据来创造，或者保持某种竞争性优势，比如更好的搜索结果，更加相关的推荐内容，物流或者运营更加的高效合理。这个时候，诸如 ML 工程师，优化专家，实验设计师都可以参与进来一展拳脚了。

在 Chang 加入 Twitter 的时候，Twitter 已经有了非常成熟的平台以及非常稳定的底层结构。整个数据库内容都是非常干净，可靠的。ETL 进程每天轻松处理着数百个「任务调度」工作。（Map-Reduce）。更重要的是，在数据分析领域的人才都在数据平台、产品分析、用户增长、实验研究等 多个领域，多个重点工作齐头并进一起展开。

关于 Chang 本人的经历

他是在用户增长领域安排的第一名专职数据分析师。事实上，这花了他们好几个月来研究产品、工程、还有数据分析到底该如何融合，才能实现这样一个岗位角色。Chang 的工作与产品团队紧密连接，根据这方面的工作经验，他将自己的工作职责划分成为了下面几类内容：

产品分析

数据传输通道

实验（A/B 测试）

建模

下面将会按照排列次序逐一解释

产品分析

对于一家消费级科技公司来说，产品分析意味着利用数据来更好地理解用户的声音和偏好。不管什么时候用户与产品进行着互动，Twitter 都会记录下来最有用的数据，存储好它们，以待未来某一天分析之用。

这个过程被称之为「记录」（logging）或者「工具化」（instrumentation），而且它还不断地自我演进。通常情况下，数据分析往往很难实现某个具体的分析，因为数据要么是不太对，要么是缺失，要么是格式错误的。在这里，跟工程师保持非常好的关系非常有必要，因为数据分析能够帮助工程师确认 bug 的位置，或者系统中一些非预期的行为。反过来，工程师可以帮助数据分析弥补「数据鸿沟」，使得数据内容变得丰富，彼此相关，更加准确。

下面举出来了 Chang 在 Twitter 展开的几项与产品有关的分析案例：

推送通知分析：有多少用户能用得到「推送通知」？不同类型的推送通知具体的点击率都分别是多少？

SMS 发送率：在不同的数字载体上，Twitter 的 SMS 发送率都是怎么计算的？是不是在发展中国家这个发送率相对比较低？我们该怎样提升这个数字？

多账户：为什么在某些国家，一个人持有多个账户的比例会相对较高？背后是什么动机让一个人持有多个账户？

分析会以多种形式展开。有些时候公司会要求你对一次简单的数据拉取进行最直白的解读，又或者你需要想出一些新的方式方法来机选一个全新，且重要的运营指标。（比如 SMS 发送率），最后你会更加深刻地理解用户的行为。（比如一个人拥有多个账户）

在 产品分析中不断研究，得到真知灼见，这是一个不断迭代演进的过程。它需要不断地提出问题，不断地理解商业情境，找出最正确的数据组来回答相应的问题。随着 时间的累积，你将成为数据领域的专家，你会正确地估计出来执行一次分析大概得花多长时间。更重要的是，你将逐渐从一个被动响应的状态，逐渐过渡到主动采取 行动的状态，这其中会牵连出来很多有趣的分析，这些内容都是产品负责人曾经压根没有考虑过的，因为他们不知道这些数据存在，又或者不同类型的数据以某种特 殊的方式组合到一起竟然会得出如此惊人的结论。

此处需要的技能：

保存和工具化：确认数据鸿沟。与工程部门建立良好的协作关系；

有能力引导和确认相关的数据组，知道正确使用它们的方式；

理解不同形式的分析，能够在不同的分析执行之前就正确地估算出难易程度，所需时间长短；

掌握你的查询语言。一般来说是利用 R 或者 Python 来实现数据再加工；

数据管道

即使 A 型数据分析师不太可能自己编写代码，直接应用到用户那里，但是出乎很多人意料的是，包括 Chang 在内的很多 A 型数据分析师确实在给代码库写东西，目的只有一个：为了数据管道处理。

如果你从 Unix 那里听说过「对一系列命令的执行」，那么一个数据管道就意味着多个系列命令的执行，我们能够不断周而复始地自动捕捉，筛选，集合数据。

在 来到 Twitter 之前，Chang 的分析绝大部分都是点对点的。在 Chang 的本地机器上，代码执行上一次或者几次。这些代码很少得到审查，也不太可能实现版本控制。但是当一个数据通道出现的时候，一系列的功能就浮出水面：比如 「依赖管理」、「调度」、「源头分配」、「监控」、「错误报告」以及「警告」。

下面介绍了创建一个数据管道的标准流程：

你忽然意识到，如果一个数据组能够周而复始地自我重新产出，那么这个世界估计会因此受益；

在确认了需求之后，你开始设计「生产数据组」的「数据架构」；

开始编写你的代码，不管是在 Pig，Scalding，或者 SQL 中。这取决于你的数据环境是什么；

提交代码，进行代码审查（code review），准备后得到回馈，并做相应额外的修改。要么是因为你的设计逻辑不太对，要么是你的代码出于速度和效率的目的并没有优化到位；

应该有一个「测试」和「试运转」的环境，确保所有的运行都在既定的轨道上。

将你的代码融合到主库中

建立「监控」、「错误报告」以及「警告」等功能，以防止未来出现预期之外的状况。

很显然，数据通道比一个点对点的分析工具来说更加复杂，但是优势也非常明显，因为它是自动化运行着的，它所产出的数据能够进一步强化面板，这样更多的用户能够消费你的数据/结果。

另外，更加重要但是往往被人忽略的一点结果是，对于如何打造最优化的工程设计，这是一个非常棒的学习过程。如果你在日后需要开发一个特别定制的数据通道，比如机器学习，之前所做的工作就成为了扎实的基础。

在此处需要用到的技能：

版本控制，目前最流行的就是 Git；

知道如何去做「代码审核」，并且知道如何有效地给予反馈；

知道如何去测试，如何去试运行，当出现错误的时候知道如何「debug」；

「依赖管理，调度，资源分配，错误报告，警告」功能的设置。

来源：Medium 译文由 TECH2IPO/创见 花满楼 编译

数据分析师这个职业现在越来越火爆。本文面向那些准备投身于这个行当的年轻人，在选择怎样的公司上给出了三条参考标准。它们分别是：第一点：去供职于那些利用数据分析来做市场战略定位的公司；第二点：去为一个拥有着伟大想法的公司工作；第三点，去选择给一家即将进入空白市场的公司

现在确实是属于数据分析师的天下了。如果你有能力，有经验，充满好奇心以及永不倦怠的热情，作为数据分析师的你可谓前景广阔，有

一大批公司乖乖站在你家门前挂着牌子等着你的挑选。但是在评估到底去哪家公司的平台上施展你的才华的时候，却是有着很多考量的。即便是一个从业多年的老手也不可能在各种大小规模不一，发展阶段不同，拥有各自的企业文化的公司待过。他们也不可能横跨多个领域，掌握多种技术。但是，在本文中却给出所有有志于从事数据分析师这个职业的年轻人一些经验。大体上总结一下就三点内容，凭借这三点内容，你可以非常理性、客观地分析出来眼前的这家公司到底是否值得去。

第一点：去供职于那些利用数据分析来做市场战略定位的公司

公司想要在市场上拥有特殊的竞争优势，从而实现与众不同的市场地位，其实途径方法都有很多种。有一些利用价格来区分自己，比如靠低价来获取市场竞争优势；还有一些公司愿意通过更加优质的产品来达到鹤立鸡群的效果；更有一些人通过订单处理进程的快慢赢得顾客的认可与忠诚，更快的配送上门服务就是很好的例证。

一个数据分析师应该选的这家公司，应该凭借数据学来做到自己与其他竞争对手之间的「切割」。请注意，有可能数据学可以用来支持更低的价格，更优质的产品，更快的配送速度，但是它绝对不是实现这些优势的主要原因。直接，且主要的原因通常情况下是规模经济造成了更低的价格，专利和品牌带来了更加优质的产品，自动化的技术使得配送速度提升。如果公司核心竞争力是构建在数据和分析工具上，那么它会迅速跟其他竞争者拉开几个身位。

一旦这种优势得以建立，整个公司都会瞄准数据学发力，所有的资源都是围绕着数据分析投入。它会更加愿意投资，获得数据领域最顶尖的人才，打造最优秀的底层系统，不断地将最前沿的算法和计算技术推向极致，开发各种不可思议的工程产品来展现数据学的魔力。

在做市场上战略区分的时候，「足够好」这个词是绝对不能出现的。公司和数据分析师双方都应有着足够强烈的意愿，推动技术再往前发展一点点，永无止境地去摸索极限，并愿意承担更多的风险。你每天早上起床睁眼的时候，你一想到这个公司，就能兴奋的一个鲤鱼打挺立刻翻身下床，精神抖擞，迫不及待的开展全新一天的工作，它是一个能够拉动提升你，让你成为这个世界最优秀人才的平台。

第二点：去为一个拥有着伟大想法的公司工作

在考虑到底哪个公司能成为将来人们口中最伟大的那家公司的时候，也许「利用数据分析实现市场竞争优势」是一个必要条件，但并不是充分条件。这个公司同样必须拥有世界级的数据才可以。

首先得找到一家真正拥有数据的公司。在评估初创公司早期价值的时候，区分「数据拥有者」和「数据向往者」是非常重要的。最理想的状态是，你将找到一家拥有足够数据量，并且已经开始着手做一些有趣事情的公司。几乎所有的公司在成长过程中，数据量都会不断扩大，但是如果你选择了一家已经拥有足够级别数据量的公司，那么它的潜力，可发展性将会提升到另外一个层次。

确定好了公司，接下来我们要看这个公司所拥有的数据都是哪些。它是否足够有趣，并且具有丰富，且待挖掘的深刻意义。作为数据分析师，你接下来每一天的工作中最重要的一部分内容就是不断探知你所打交道的这些数据所蕴含的真实信息量，挖掘出它们的最大价值。刚才说到了两个标准。其一是「有趣」，即能够迫使你去利用创新思维解决问题，测试某些猜测，推动你去开发出全新的算法与应用。其二是「丰富内涵，深刻意义」，即数据应当是充满可挖掘性的，应用应该是优秀的，它们都应该是塑造市场竞争优势的最有利的武器。

最后，不要眼光全部锁定在「大数据」这件事上。数据分析这个领域地位的崛起，刚好凑巧碰上了「大数据」这个概念的崛起。但是它们不是一个东西。超大规模的数据量并不一定带来足够深刻的洞见，也并不一定是必要的。去寻找那些信息密集度大的数据，而不是光从量上着眼判断。

第三点：去选择给一家即将进入空白市场的公司

当评估市场机会的时候，去选择一个还没有将成型的解决方案的公司。几乎所有的公司都已经有了一些成型的应用，当然数据分析师是必要的岗位，但是更值得去选择一些拥有明确研发方向，强有力的数据研究团队，但是仍然还处在研究解决一系列问题过程中的公司。

很多情况下，对于数据分析师而言最具有意义，最具有无限想象空间的职场机会往往没有得到重视，甚至于他们都不曾意识到手头上的某个工作是有史以来最难得的重大机遇。而选择一个公司，就是要让「承担风险」成为一种被鼓励，值得赞许的事情，去挑战某些基础的假设理论，去从数据层面释放更多的可能性。

那么究竟怎样才能筛选出这样一家公司来呢？其实观察一下工程技术部门与数据研究团队之间的合作关系就能搞清楚了。工程人员是否保持着高涨的热情与数据分析团队一共合作？是否不断地将实验，各种想法整合到产品当中？公司是否有一个基本的架构，能够支撑新概念，新技术的灵活整合？实际上，如果一个公司真的符合上面所描述的种种条件，其实「数据分析」和「工程技术」之间的界限已经模糊得消失不见了。

一个白手起家，闯入陌生领域的公司有可能没有非常稳定的公司组织结构，这固然让人觉得有点儿不靠谱，但是作为数据分析师来说，这个地方是充满最多创意性和自由的地方。在从来没有人涉足的领域去构建一些东西，这样性质的工作同样是可以评估测量的。不要光是看重设计中「数学」以及「统计」的地位，而且还要重视「数据通道」，「API」。

当然，渐进性的进步当然会带来渐进性的影响，但是如果你拥抱一次全新的机会，在空白领域，从无到有地开发出一个系统，并不断迭代提升，那么这个版本号为 1 的产品有可能成为这个领域的基础，借此深刻地影响整个行业。

最后的话

当然，还有其他需要考虑的因素：比如公司的品牌影响力，使用的是哪个具体的技术，具体到公司的同事都是怎样的，等等等等。所有这一切都同等重要。之所以摘出上面的三点内容，是因为它们往往不受人重视，不会经常出现在大家的视野中，但它们对于一名数据分析师职业发展，工作的快乐程度来说却具有决定性的作用。

本文来源：stitchfix 译文创见首发 由 TECH2IPO/创见 花满楼 编译

那个研究发现如果数据跟他们的直觉相冲突，57%的商业领袖会重新分析数据，而另外30%的商业领袖会收集更多的数据，只有10%的会基于数据的建议采取行动

研究表明情感，直觉和人性因素继续是决策的重要因素。而事实上，诸多因素也在挑战决策者单纯基于数据做决策，包括数据分析能力不足（37%），过多的数据量（34%），以及各类信息的快速增长（31%）。于是只有38%的人觉得非量化因素应该在严格的数据分析方式中排除

有意思的是，当选择商业伙伴时，决策者更倾向于考虑公司的声誉（70%）而不是产品和服务的质量（63%），以及其财务健康度（50%）。只有1/10的人表示有魅力或有趣的领导层是选择合作伙伴的关键因素

其他结果也支持人性的重要性，超过4/10的受访者同意他们喜欢与雇员拥有优秀的交际技能和情感洞察的人做生意，而非跟分析技能优秀的人做生意

这个研究并非第一份指出情感因素在决策中的重要性的研究，而最近MarketingCharts Debrief针对B2B决策者的研究中指出，B2B购买尤为个人化，因为这往往需要与人打交道。

在多数接受gyro and FORTUNE调研的受访者中，诸如抱负，希望，渴望被崇拜等积极因素是所有商业场所决策的最重要驱动力
via：199IT编译自marketingcharts

几点想法，分享给刚入门的数据分析师，也跟经验丰富的数据分析师做下探讨。

1.数据是有立场的，立场决定解读

数据对于业务来讲，是KPI的衡量标杆，也是行动指南。但一旦涉及到立场和方向性的东西，必然有利益触发点的问题。比如同样的一次活动的网站转化率是1.2%，是好还是坏？这是做数据分析第一步要进行的定位，也就是我们所说的下结论。好坏的区分在于比较，如何比较呢？我们知道比较分析方法有环比、占比、定基比、横向比、纵向比等，其中如环比可以比较昨日、上周今日、上月今日等，不同的时间对比出的结果一定有差异，甚至是迥然不同的结果。那面对这种情况，除了分析师的经验以外，在都符合统计学规律的前提下该如何判断活动效果好坏？

第一步结果总算出来了。

那么假设结果是好的（先不管对比的是什么时间），那确实是好的吗？我们知道做活动效果肯定会好啊。尤其在中国，只要价格低，无论多么差的用户体验，无论网站UI多么垃圾，无论送货多么慢，订单转化率一定会起来。这就意味着，无论你的营销、运营做的怎样（只要不是特别特别差），各个渠道、各个节点转化率都会上来。这时候，你会怎样分析？其中有多少是归于渠道或运营本身的优化因素，而有多少是归于活动影响？

假设我们能找出其中归于活动本身或渠道、运营本身的影响因素，结果出来后可能是——刨去活动影响，渠道、运营做的转化率其实变化不大（事实上通常是这样的，但我们不能否认他们的功劳，毕竟没有流量、没有运营，网站无法正常运行），工作效果不明显啊？你会怎样？直接告诉你的同事他们的工作没效果？可能你不会那样做，那此时你该如何取舍？尽职尽责做好一个数据的本职工作还是考虑下其他因素？怎么做才能既让数据价值最大化又能不打击同事的工作积极性？

2.数据质量永远是数据分析立项后首先要考虑的

做过大型数据分析的同学刚开始或多或少有这样的经历，拿到数据后经过分析发现了一个异常分析点，做了N多预处理、N多牛叉的模型，N多分析和多维钻取，最后把报告呈现出来，跟业务沟通的时候，业务只说了一句话“哦，那个异常数据啊，那是我们的测试数据”，然后我们会不会疯掉？

为什么会出现这种问题，因为拿到数据后没有进行一步必要的步骤——数据质量验证。什么是数据质量验证？我理解的是首先要理解数据来源、数据统计和收集逻辑、数据入库处理逻辑；其次是理解数据在数据仓库中是如何存放的，字段类型、小数点位数、取值范围，规则约束如何定义的；第三是明确数据的取数逻辑，尤其是从数据仓库中如何用SQL取数的，其中特别是对数据有没有经过转换和重新定义；第四是拿到数据后必须要有数据审查的过程，包括数据有效性验证、取值范围、空值和异常值处理等。

当这些工作都做充足之后才是数据分析。但可惜的是大多数数据分析师都不关注数据质量问题，甚至对数据的理解仅限于表现定义。当然做足了底层的工作，你会发现做起数据来事半功倍，并且你的结论和推到是经得起验证和考究的。

3.缺乏落地的数据没价值，除非是市场分析

数据的价格在于对业务的驱动，不管你的业务对象是你的BOSS还是同事。很多情况下，我们的数据分析师是这样工作的：一天到晚闷头做事，出数据写报告。结果出来的数据结论和建议会有这么几种情况：

• 分析过程明显不符合业务操作实际；
• 结论明显是错的；
• 建议方向性很对，但是空洞，具体执行缺乏落地点；
• 建议方向性很明确，也有具体执行建议，但是业务不能执行；
• 上面的问题中，第一二条会偶尔发生，第三四条会经常发生。为什么？从数据的角度来讲没问题，但是落实到业务实际上有问题。问题出现哪？主要是这几方面：
• 数据分析师根本不懂业务操作流程，凭自己的理解去猜测业务流程；
• 数据分析师根本不知道现在业务的困难点在哪，哪些是目前最紧急的，凭自己的感觉认为“我觉得这些对他们最最有用”；
• 数据分析师根本不知道业务能控制哪些，不能控制哪些，即使能控制又是否业务有必要去做，导致建议不是该业务部门能执行的。

4.数据解读能力和业务应用能力永远大于工具应用能力，不要迷信算法和模型

受至于数据的普遍理论影响，很多数据分析师会认为会多少个模型，多少种算法是一件多么牛叉的事情，诚然，数据尤其在面对海量数据时，普通的数据分析方法常常感觉无能为力，但这并不意味着工具和方法就决定了数据分析师的层次。举例来说，通常我们用的数据挖掘模型，业务都很难理解，假如你花很长时间作出一个关联模型，如果你这样告诉你的业务受众：A商品和B商品关联程度较高，从支持度，置信度和提升度来讲效果显著。那我们可以预想到这个挖掘的结果很难落地，并且意义不大。从业务受众实际应用层面来讲，两个商品关联度高意味着什么，意味着用户通常会一起购买这两件商品（也有可能是复购，具体看数据选取规则），那一起购买又怎样？我们是否可以把这两件商品做打包促销？是否可以做关联推荐？是否可以做个性化营销？是否可以引导用户消费倾向？甚至在活动页面设计上，是否可以将相关度高的品类，品牌摆放在一起来促进销售？又或者这是否可以做流失挽回的参照指标，重新审视之前每次的广告＂通发＂？这才是数据价值，无法跟业务结合的数据模型毫无价值。

5.业务需求是数据分析的起点，但之前你需要培养业务的数据意识

很多时候我们希望等待我们的业务自己上门提需求，并且以需求为数据分析的起点，似乎很多教材也是这么说的，基于业务需求的数据分析目的更明确，分析结论和效果落地也会阻力更小，但实际情况是业务通常是数据不敏感的，主要表现在：

• 业务没有数据决策的意识。大多数业务的第一行动引导因素还是业务经验，无论是基于事实的经验还是拍脑袋决策，数据绝对不是行动前必须参考的因素；
• 业务不知道数据在哪些方面能帮到他。业务很多时候只是有个想法，想让数据证明点什么，但说不清楚。通常业务的措辞是“我们想知道这次活动的效果怎么样”、“我们想了解广告效果为什么不好”。至于具体效果指的是什么业务自己也说不清楚，甚至是业务自己也不知道到底想要什么。
• 业务不相信数据。如果数据结果出来时和业务设想的不同，那业务的第一反应是怀疑数据，无论是数据的出处、分析过程还是结论，业务总想找到能证明自己观点对的东西。所以我们会感觉，业务用数据的目的只是为了证明自己当初设想的正确性。
• 作为数据分析师，我们不能要求业务必须要懂数据、理解数据，但是我们需要把数据能解决什么问题，怎么解决的，解决之后会给业务带来哪些改进以及效果上的优化，如果能预测出一个具体数值或最起码有一个范围，业务会更加相信数据的真实性、准确性。如果培养业务的数据意识？
• 数据意识是一个不断积累的过程，需要每周至少2~3次专项沟通，每次沟通至少持续半个小时，大概半年之后业务会形成一定的数据意识，最起码意识到在某些时候，数据会解决一些问题；
• 每次沟通时，明确告诉业务数据能给他们带来哪些好处，能实现什么，在哪些主要业务点上能发挥作用，这样业务会认为数据会是一个能帮到自己的东西；

数据不只是在业务执行之后才会发生作用的，在业务执行前的预测与计划，在业务执行过程中及时预警与恶意数据监控都是数据能发挥作用的场合，并且这些都能在“坏数据”、“坏结果”出来之前通过数据区去改善，这些将比结果出来后再去分析要更有意义。

作为数据分析师，需要不断提高自身能力。能力包括业务理解能力和数据分析能力，既能把业务“粗糙的要求”转换成数据需求，又能将数据结果转化成业务可理解、可执行、有时间限制、能验证结果的数据输出。

我相信数据是一门艺术，良好的数据能力可以处处在业务中展现能力，并且确实可以提高业务价值，这是数据存在根本，也是数据分析师立足的根本。

来自：数据分析与商业应用

我用Google搜索了一下“Big Data”，得到了19，600，000个结果……而使用同样的词语，在两年前你几乎搜索不到什么内容，而现在大数据的内容被大肆炒作，内容多得让人眼花缭乱。而这些内容主要是来自IBM、麦肯锡和O’Reilly ，大多数文章都是基于营销目的的夸夸其谈，对真实的情况并不了解，有些观点甚至是完全错误的。我问自己…… 大数据之于数据分析师，它意味着什么呢？

如下图所示，谷歌趋势显示，与“网站分析”(web analytics)和”商业智能”(business intelligence)较为平稳的搜索曲线相比，“大数据”(big data)的搜索量迎来了火箭式的大幅度增长。

大数据 – 炒作

Gartner把“大数据”的发展阶段定位在“社交电视”和“移动机器人”之间，正向着中部期望的高峰点迈进，而现在是达到较为成熟的阶段前的二至五年。这种定位有着其合理性。各种奏唱着“大数据”颂歌的产品数量正在迅速增长，大众媒体也进入了“大数据”主题的论辩中，比如纽约时报的“大数据的时代“，以及一系列在福布斯上发布的题为” 大数据技术评估检查表“的文章。

进步的一面体现在，大数据的概念正在促使内部组织的文化发生转变，对过时的“商务智能”形成挑战，并促进了“分析”意识的提升。

基于大数据的创新技术可以很容易地被应用到类似数据分析的各种环境中。值得一提的是，企业组织通过应用先进的业务分析，业务将变得更广泛、更复杂，价值也更高，而传统的网站分析受到的关注将会有所减弱。

大数据 – 定义

什么是“大数据”，目前并没有统一的定义。维基百科提供的定义有些拙劣，也不完整：“ 大数据，指的是所涉及的数据量规模巨大到无法通过主流的工具，在合理的时间内撷取、管理、处理、并整理成为人们所能解读的信息 “。

IBM 提供了一个充分的简单易懂的概述：

大数据有以下三个特点：大批量(Volume)、高速度(Velocity)和多样化(Variety) 。

大批量 – 大数据体积庞大。企业里到处充斥着数据，信息动不动就达到了TB级，甚至是PB级。高速度 – 大数据通常对时间敏感。为了最大限度地发挥其业务价值，大数据必须及时使用起来。多样化 – 大数据超越了结构化数据，它包括所有种类的非结构化数据，如文本、音频、视频、点击流、日志文件等等都可以是大数据的组成部分。

MSDN的布莱恩·史密斯在IBM的基础上增加了第四点：

变异性 – 数据可以使用不同的定义方式来进行解释。不同的问题需要不同的阐释。

大数据 – 技术角度

大数据包括了以下几个方面：数据采集、存储、搜索、共享、分析和可视化，而这些步骤在商务智能中也可以找到。在皮特·沃登的“ 大数据词汇表 “中，囊括了60种创新技术，并提供了相关的大数据技术概念的简要概述。

获取 ：数据的获取包括了各种数据源、内部或外部的、结构化或非结构化的数据。“大多数公共数据源的结构都不清晰，充满了噪音，而且还很难获得。” 技术： Google Refine、Needlebase、ScraperWiki、BloomReach 。

序列化 ：“你在努力把你的数据变成有用的东西，而这些数据会在不同的系统间传递，并可能存储在不同节点的文件中。这些操作都需要某种序列化，因为数据处理的不同阶段可能需要不同的语言和API。当你在处理非常大量的记录时，该如何表示和存储数据，你所做的选择对你的存储要求和性能将产生巨大影响。 技术： JSON、BSON、Thrift、Avro、Google Protocol Buffers 。

存储 ：“大规模的数据处理操作使用了全新的方式来访问数据，而传统的文件系统并不适用。它要求数据能即时大批量的读取和写入。效率优先，而那些有助于组织信息的易于用户使用的目录功能可能就显得没那么重要。因为数据的规模巨大，这也意味着它需要被存储在多台分布式计算机上。“ 技术： Amazon S3、Hadoop分布式文件系统 。

服务器 ：“云”是一个非常模糊的术语，我们可能对它所表示的内容并不很了解，但目前在计算资源的可用性方面已有了真正突破性的发展。以前我们都习惯于购买或长期租赁实体机器，而现在更常见的情况是直接租用正运行着虚拟实例的计算机来作为服务器。这样供应商可以以较为经济的价格为用户提供一些短期的灵活的机器租赁服务，这对于很多数据处理应用程序来说这是再理想不过的事情。因为有了能够快速启动的大型集群，这样使用非常小的预算处理非常大的数据问题就可能成为现实。“ 技术： Amazon EC2、Google App Engine、Amazon Elastic Beanstalk、Heroku 。

NoSQL ：在IT行为中，NoSQL(实际上意味着“不只是SQL”)是一类广泛的数据库管理系统，它与关系型数据库管理系统(RDBMS)的传统模型有着一些显著不同，而最重要的是，它们并不使用SQL作为其主要的查询语言。这些数据存储可能并不需要固定的表格模式，通常不支持连接操作，也可能无法提供完整的ACID(原子性—Atomicity、一致性—Consistency、隔离性—Isolation、持久性—Durability)的保证，而且通常从水平方向扩展(即通过添加新的服务器以分摊工作量，而不是升级现有的服务器)。 技术： Apache Hadoop、Apache Casandra、MongoDB、Apache CouchDB、Redis、BigTable、HBase、Hypertable、Voldemort 。

MapReduce的 ：“在传统的关系数据库的世界里，在信息被加载到存储器后，所有的数据处理工作才能开始，使用的是一门专用的基于高度结构化和优化过的数据结构的查询语言。这种方法由Google首创，并已被许多网络公司所采用，创建一个读取和写入任意文件格式的管道，中间的结果横跨多台计算机进行计算，以文件的形式在不同的阶段之间传送。“ 技术： Hadoop和Hive、Pig、Cascading、Cascalog、mrjob、Caffeine、S4、MapR、Acunu、Flume、Kafka、Azkaban、Oozie、Greenplum 。

处理 ：“从数据的海洋中获取你想要的简洁而有价值的信息是一件挑战性的事情，不过现在的数据系统已经有了长足的进步，这可以帮助你把数据集到转变成为清晰而有意义的内容。在数据处理的过程中你会遇上很多不同的障碍，你需要使用到的工具包括了快速统计分析系统以及一些支持性的助手程序。“ 技术： R、Yahoo! Pipes、Mechanical Turk、Solr/ Lucene、ElasticSearch、Datameer、Bigsheets、Tinkerpop 。 初创公司： Continuuity、Wibidata、Platfora 。

自然语言处理 ：“自然语言处理(NLP)……重点是利用好凌乱的、由人类创造的文本并提取有意义的信息。” 技术： 自然语言工具包Natural Language Toolkit、Apache OpenNLP、Boilerpipe、OpenCalais。

机器学习 ：“机器学习系统根据数据作出自动化决策。系统利用训练的信息来处理后续的数据点，自动生成类似于推荐或分组的输出结果。当你想把一次性的数据分析转化成生产服务的行为，而且这些行为在没有监督的情况下也能根据新的数据执行类似的动作，这些系统就显得特别有用。亚马逊的产品推荐功能就是这其中最著名的一项技术应用。“ 技术： WEKA、Mahout、scikits.learn、SkyTree 。

可视化 ：“要把数据的含义表达出来，一个最好的方法是从数据中提取出重要的组成部分，然后以图形的方式呈现出来。这样就可以让大家快速探索其中的规律而不是仅仅笼统的展示原始数值，并以此简洁地向最终用户展示易于理解的结果。随着Web技术的发展，静态图像甚至交互式对象都可以用于数据可视化的工作中，展示和探索之间的界限已经模糊。“ 技术： GraphViz、Processing、Protovis、Google Fusion Tables、Tableau 。

大数据 – 挑战

最近举行的世界经济论坛也在讨论大数据，会议确定了一些大数据应用的机会，但在数据共用的道路上仍有两个主要的问题和障碍。

1.隐私和安全

正如Craig & Ludloff在“隐私和大数据“的专题中所提到的，一个难以避免的危机正在形成，大数据将瓦解并冲击着我们生活的很多方面，这些方面包括私隐权、政府或国际法规、隐私权的安全性和商业化、市场营销和广告……

试想一下欧盟的cookie法规，或是这样的一个简单情景，一个公司可以轻易地在社交网络上收集各种信息并建立完整的资料档案，这其中包括了人们详细的电子邮箱地址、姓名、地理位置、兴趣等等。这真是一件吓人的事情!

2.人力资本

麦肯锡全球研究所的报告显示 ，美国的数据人才的缺口非常大，还将需要140，000到190，000个有着“深度分析”专业技能的工作人员和1.500个精通数据的经理。

寻找熟练的“网站分析”人力资源是一个挑战，另外，要培养自己的真正拥有分析技能的人员，需要学习的内容很多，这无疑是另一个大挑战。

大数据 – 价值创造

很多大数据的内容都提及了价值创造、竞争优势和生产率的提高。要利用大数据创造价值，主要有以下五种方式。

数据分析的机会领域

当“网站分析”发展到“数据智能“，毫无疑问，数据分析人员也工作也应该发生一些转变，过去的工作主要是以网站为中心并制定渠道的具体战术，而在将来则需要负责更具战略性的、面向业务和(大)数据专业知识的工作。

数据分析师的主要关注点不应该是较低层的基础设施和工具开发。以下几点是数据分析的机会领域：

处理 ：掌握正确的工具以便可以在不同条件下(不同的数据集、不同的业务环境等)进行高效的分析。目前网站分析专家们最常用的工具无疑是各类网站分析工具，大多数人并不熟悉商业智能和统计分析工具如Tableau、SAS、Cognos等的使用。拥有这些工具的专业技能将对数据分析人员的发展大有好处。

NLP：学习非结构化数据分析的专业技能，比如社交媒体、呼叫中心日志和邮件的数据多为非结构化数据。从数据处理的角度来看，在这个行业中我们的目标应该是确定和掌握一些最合适的分析方法和工具，无论是社会化媒体情感分析还是一些更复杂的平台。

可视化 ：掌握仪表板的展示技能，或者宽泛点来说，掌握数据可视化的技术是摆在数据分析师面前一个明显的机会(注：不要把数据可视化与现在网络营销中常用的“信息图”infographics相混淆)。

行动计划

在大数时代，其中一个最大的挑战将是满足需求和技术资源的供给。当前的“网站分析”的基础普遍并不足够成熟以支持真正的大数据的使用，填补技能差距，越来越多的“网站分析师”将成长为“数据分析师”。