大数据 – 蚂蚁学Python

我为什么从工程转了算法？

一句话总结下：年龄大了，总想让自己做的事情有意义点，所以想让自己写的代码对产品有更多的影响、可衡量的影响。

1、我发现自己的JAVA开发和大数据业务处理对产品影响甚微

我自己工作快7年，工作主要有两个方向：

A – JAVA后台业务开发

来什么需求做什么开发，增删改查，接消息发消息，因为之前做的是公司商业运营部门的需求，面向公司运营市场人员，不直接面向普通用户，系统访问量特别低，往往一天几千个访问量很不错了，这也导致出去面试的时候别人问我系统QPS有多少，我真是不好意思说是不到两位数；

B – 业务大数据处理

现在做业务的都要看数据，毕竟数据能反映业务的状况，一旦涉及数据就不只是mysql里面的那些少量数据，往往需要查一下各个渠道来源的流量之类的，这就要去查公司级别的数据仓库，而他们每天的数据量每天几十上百TB，不用HIVE/SPARK这些大数据技术搞不定，但说到底就是SQL取数做个图表出来，出去面试人家问大数据建模方法论、怎样实现跨业务的统计指标统一我照样是一头懵逼；

虽然我知道JAVA的后台服务开发确实可以往后发展，但是我没有接触到高并发这些难度大的方向；而大数据业务处理虽然只是出了一些报表，但是我自己却没有分析报表的能力，报表也是老大们看他们根据什么数据拍了什么板我也不知道。

这两个方向都让我觉得有种不那么精准发展的感觉，如果我对别人说自己的职业发展方向是JAVA，恐怕别人会觉得你是随着业务走什么都得干，称作"方向"有点虚虚的，同时它俩都是非常间接的影响着业务，或者说影响很微小，缺少了那么点"意义"。

2、对数据相关的学习，让我关注到数据分析和数据智能领域

大数据领域这么的火，它真正的对产品业务有哪些影响呢？

上面我整理的图表是我的理解，数据仓库、数据报表其实都是基础技术，只是工具或者手段，属于公司的基础技术部分，这两层的技术其实就像在打造一把刀，然而刀怎么用却跟这两层没关系。

你跟别人说你是搞大数据的，被人怼你就是个取数的，你能反驳吗？

再往上层走，是数据分析，通过数据分析，能够发现产品的问题、发展的趋势等等，然后影响产品的往后发展，但是我们开发人员其实跟这层也没有关系，因为分析的目标是决策，而我们码农并没有决策权。

最上层数据智能，我指的推荐、搜索、用户增长等各个算法领域，搜索算法造就了百度谷歌、推荐算法造就了头条快手，用户增长领域是所有产品都要核心关注的事情，而这个领域，我们写的代码能真正看到对产品的影响，也能用线上点击率、购买率等真实有效的指标衡量。

所以数据智能这一层才是我想要的，也是我觉得可以定准的方向。

3、说是转了算法，其实是实现了算法在业务的落地

没有足够的耐心，真的读不懂算法论文里面的公式，到现在我也没法手推算法公式，不能算是真正的算法人员。

然而我却发现，我的目标是“让自己的代码给业务带来更多直接的影响”的话，潜伏在业务团队中、能快速运用成熟机器学习算法框架让算法落地上线产生线上价值，反而走对了。

听很多人都说过，现在缺的其实不是研究算法的人，而是将算法结合业务落地的人才，吴恩达在他的视频课程中提到，他讲的算法虽然很基础，但是能搞定80%商业公司的需求；

仍然在业务中做算法，实现在业务中的算法落地让我的代码真正产生对业务的影响才是我的目标，让我去专门的算法团队，一是我写不了算法公式去不了（哈哈），二是去了离业务远了点也违背了我的初衷。

4、其实掌握算法技能，本来就是搞工程将来必备的要求？

人恐惧的经常是对未知的恐惧，接触了算法领域，我才发现并没有那么的高深恐怖不可接触，各种机器学习深度学习框架，比如sciketlearn、tensorflow、paddlepaddle等，完成一个简单的CTR排序模型，只要简单的几十分钟就能参照教程实现训练。并且几乎所有的所谓算法人员，并没有从零实现一个算法发明一个算法，都是直接修改现成的模型代码，做各种的数据获取、数据处理、特征提取等事情。

体现算法能力能力高低的，变成了一是这个人是调参圣手，第二就是这个人能把算法很好的结合业务落地，数据智能这一层因为是顶层，会依赖大量的底层技能，下层的pingback、业务数据、数据仓库、数据分析、JAVA开发与架构能力等都需要涉及，如果团队人少的话（就像我一样）所有的事情你都得干，这一层其实需要极强的工程能力，这方面专门搞算法的恐怕没有工程出身的玩的好。

要将算法在业务中落地，更多的还是得靠工程开发人员，这方面也会越来越侧重，而专门的算法团队做一些基础设施、提供算法平台恐怕是更有可能发展的方向。

人工智能越来越火，算法框架越来越简单，学习成本门槛越来越低，等越来越多的工程都会算法，面试一个JAVA程序员时必问算法落地能力时，懂得算法就是一个程序员的必备技能，而不是加分技能。

关注这个公众号，一起学习吧哈哈！

数据源和Event模型的重要性

数据源很重要。若想把数据平台做好，数据源非常重要。如果我们从源头本身结构化，构化，下游就不需要跟着源头动，数据解析效率也会高很多。
用户行为事件模型很有效。规范并结构化用户行为之后，许多数据分析都会变得更容易。每个Event都是用户发生行为的一个快照，能够尽可能地还原现场。

大数据的概念

大：大数据的“大”强调宏观的“大”，而非一味追求数据量的“大”。
全：强调的“全”是全量，强调多种数据源，包括前端、后端的数据，以及日志、数据库数据等。大数据时代有了更前沿的数据采集手段，让获取全量数据成为可能。
细：“细”强调多维度数据，包括事件、商品的各种维度、属性、字段等。比如我现在问“你所在公司的客户中，不同身高的群体在平均消费额上有什么差异”，你很可能回答不出来，因为你没有记录“身高”这一维度的数据。
时：“时”，它强调实时数据采集和实时数据分析的价值。

“大”“全”“细”“时”让我们对大数据的概念有较为清晰的认识，它们主要强调数据在获取和规模上与传统数据时代的差异。这是企业进行数据采集的“四字法则”，该法则对企业数据采集提出了一定的要求。

大数据的本质

运用大数据首先应该解决“思维”问题，大数据思维指的是企业在数据化运营和管理过程中运用数据的思维和方式。

随着各种前沿技术的发展，我们的思维方式已经从最直接的决策方式——拍脑袋、因果驱动转化为数据驱动。直接向数据要答案，这就是大数据思维。我们获取的数据越全面，就越能消除更多的不确定性。

“大数据的本质是消除不确定性”，我第一次接触这个观点是在吴军的《硅谷之谜》一书中，当时觉得醍醐灌顶，我一直在思考究竟什么是大数据？而吴军的这句话直中要害。之后我在看《暗时间》一书时，尝试搜索信息论和不确定性的关系，发现克劳德·香农（ClaudeShannon）说了这么一句话：“信息是用来消除不确定性的东西。”果然是信息论的鼻祖，一句话解释了“信息”的精髓。

数据驱动理念与现状

数据驱动的价值分为两点：

其一是驱动决策。通过数据来帮助拍板，包括产品改进、运营优化、营销分析和商业决策等。我们有了数据，就能判断哪些渠道转化的效果更好，哪些功能样式更加受用户欢迎。这也就是我们常说的BI（BusinessIntelligence，商业智能），通过数据来支持决策。
其二是驱动产品智能。所谓智能，我把它归结为这么一种模式：我们有了一定的数据基础，然后在上面套一个算法模型，再将得到的数据结果反馈到产品中。这样，产品本身就具有了学习能力，可以不断迭代。比如个性化推荐，通过采集许多用户行为数据，在这个基础上训练用户兴趣模型，然后给用户推荐信息，再将用户的使用数据反馈到模型中，精准广告就是类似的模式。智能是一种学习能力，产品智能就是现在比较火的AI（ArtificialIntelligence，人工智能）概念。

这两点都消除了决策的不确定性，只是前者是人来执行决策，后者是机器来执行决策。事实上，我认为，数据驱动决策只能发挥数据20%的价值，甚至更少。而数据驱动产品智能将会发挥数据更大的价值，我也非常看好AI的发展趋势。

现实和理想中的数据驱动

典型的“需求驱动”，即根据需求去找数据。业务方提出数据需求，工程师满足需求，加上排队等待，整个效率非常低，完成一个需求都要几天甚至几周的时间。那么，理想的数据驱动应该是怎样的？
先把数据源整好，在这个基础上提供强大的分析平台，让业务需求提出者能够自助式（Self-Service）地完成数据分析需求，从串行变成并行，完成需求从几天时间缩短到几分钟甚至几秒钟，这才是理想中的数据驱动，

数据驱动的流

大数据时代到来的条件

数据采集能力的增强：数据采集能力是一个大数据团队必须具备的能力。根据前文提及的“大”、“全”、“细”、“时”，数据采集能力应该是全域数据的采集能力，包括PC互联网、移动互联网、IOT、线下数据等各个方面。
数据处理能力的增强：数据处理能力是对数据的采集、存储、检索、加工、变换和传输的能力。数据处理是实现数据分析和挖掘数据价值的前提，是衡量大数据发展状态的重要指标。摩尔定律及大数据分析和计算技术的发展，赋予了企业很强的数据处理能力。
数据意识的提升：互联网作为新兴行业，在高速发展初期引发诸多流量红利。如今，红利已经消失殆尽，企业认识到，必须通过数据分析去了解用户需求、洞察用户心理，从而提升用户体验，最终构建起自身的核心竞争力。企业发展已进入精细化运营阶段，建立起以用户为中心的设计、数据驱动的产品管理意识。5年前，大家还在讨论数据重不重要的问题，现在问题的焦点已经变成如何让数据发挥更大价值。

数据分析金字塔

数据采集与埋点

在数据分析的整个体系中，数据采集恰恰是最重要的。数据源很重要，这是我在百度做大数据时的最大心得。数据源和数据建模，恰恰是冰山下面的部分，各种分析方法只是冰山一角。我们建设好数据源，就做好了数据的根基。在数据采集上，“埋点”一词非常形象，我是在创业之后才知道这个词的。因为我在百度时的数据采集是基于日志的，而非在业务逻辑上嵌入代码，在正常的业务逻辑中嵌入数据采集代码的过程，就是“埋点”的过程。

对于用户行为分析来说，不但要采集客户端数据，还要采集服务端日志、业务数据库，以及第三方服务器等数据，全面覆盖。

科学的数据采集和埋点方式

可视化/全埋点/无埋点

使用这种方案，必须在产品中嵌入SDK，等于做了一个统一的埋点，因此“无埋点”的叫法实际上是“全埋点”的代名词。

优势：

1.可视化展示宏观指标，满足基本数据分析需求。通过展现PV、UV等网站或APP分析的宏观指标，告诉运营人员每个控件被点击的量有多少，哪些控件值得做更进一步的分析，以助于企业了解用户行为，为进一步数据分析指明方向。
2.技术门槛低，使用与较简单。只需要嵌入SDK，极大程度避免了因需求变更、埋点错误等原因导致重新埋点的复杂工作。
3.用户友好性强。可以直接应用手指或者鼠标进行操作，自动向服务器发送数据，避免手工埋点的失误。

劣势：

1.无埋点只能采集到用户交互数据，且适合标准化的采集，自定义属性的采集需要代码埋点来辅助。
2.无埋点兼容性有限。
3.无埋点是前端数据采集方式之一，因此具有前端埋点的天然缺陷，如数据采集不全面、传输时效性较差、数据可靠性无法保障等问题。无埋点的技术原理依赖网站或者APP后端技术开发的严谨性与规范性、网络状态、网络口径等因素。

代码埋点

代码埋点又分为前端代码埋点和后端代码埋点。前端代码埋点类似于全埋点，都是在前端嵌入SDK的方式，所不同的是，对于每一个关键行为，我们都需要调用SDK代码，将必要的事件名、属性字段等写入代码，然后发送到后台数据服务器。后端代码埋点则将相关的事件、属性等通过后端模块调用SDK的方式，发送到后台服务器。

这种方式相比全埋点来说，更适合精细化分析的场景。我们可以将各种细粒度的数据采集下来，方便做后续的深度分析需求。其中后端代码埋点，相比前端代码埋点，具有更高的数据可靠性，并且可以实现一处埋点，不用从各个APP、Web端进行埋点操作。

全埋点VS代码埋点：

如果仅仅为了看看宏观数据，并没有精细化分析需求，并且是对客户端做的分析，这种时候全埋点是一种比较省事的选择。如阅读类、词典类工具性APP的企业客户，在其发展初期的产品运营阶段，产品功能较为基础，无明确业务数据、交易数据，仅通过UV、PV、点击量等基本指标分析即可满足需求。如果全埋点还采集了渠道来源信息，则可以进行不同的渠道来源对比。图3-4是某广告企业通过全埋点的方式采集数据后了解用户渠道来源，并判断不同渠道和不同推广方式的投放效果。一旦企业有复杂的分析需求，就必须进行代码埋点，否则数据无法进行灵活下钻。

前端埋点VS后端埋点

在产品运营的初期，产品功能比较简单，可以采用前端埋点。或者有些行为没有和后端进行交互操作，比如有些游戏是离线运行，就比较适合前端埋点。为了保证核心数据的准确性，我们更推荐“后端埋点”。当前后端都可以实现数据采集时，应优先考虑后端（代码）埋点，尤其在各行业中有特殊业务需求的数据，更是强烈建议通过后端（代码）埋点方式采集。总的来说，后端（代码）埋点，或者“后端（代码）埋点+全埋点”方案，适合有深度数据分析需求的企业。

需要具有完善的元数据管理和埋点管理

元数据管理可精细化管理每个行为事件的属性类型定义，埋点管理会跟踪每个埋点的数据量、校验通过量等，出现异常要及时发现。系统还应提供Debug模式，以精确跟踪每一条数据是不是按预期的计划进行处理。实时导入监测功能，可以通过用户ID及其他属性，筛选实时采集的数据，精确定位问题。总之，是要把数据采集从“黑盒”变“白盒”。

元数据管理界面：

多维数据模型

数据模型就是对现实世界抽象化的数据展示。数据模型在满足抽象的同时，越简单越好。

数据立方体是多维数据模型的一个通俗叫法，主要由“维度”和“指标”两部分组成，比如地域、操作系统属于“维度”，销售额、注册用户数、成单量是“指标”。我们可以通过维度组合，查看该组合下的指标情况

数据分层的金字塔模型，决定构建UDW（UserDataWarehouse），能够将用户在百度所有产品线的行为统一到一起去。有了这个地基，剩下的数据使用问题，就变得容易了。

多维事件模型

多维事件模型分成Event实体和User实体。

Event实体

Event描述了一个用户在某个时间点、某个地方以某种方式完成某个具体事情。

一个完整的Event，包含如下如下的几个关键因素。

Who：即参与这个事件的用户是谁。
When：即这个事件发生的实际时间。
Where：即事件发生的地点。
How：即用户从事这个事件的方式。
What：描述用户所做的这个事件的具体内容。在数据接口中，首先使用“Event”这个事件名称来对用户所做的内容进行初步分类。Event的划分和设计也有一定的指导原则，我们会在后文详细描述。除了“Event”这个至关重要的字段以外，我们并没有设置太多预置字段，而是请使用者根据每个产品以及每个事件的实际情况和分析的需求

举个例子，记录事件和扩展字段：

User实体

每个User实体对应一个真实的用户，用distinct_id进行标识，描述用户的长期属性（也即Profile），并且通过distinct_id与这个用户所从事的行为，也即Event进行关联。

收集哪些字段作为UserProfile，也完全取决于产品形态及分析需求。简单来说，就是在能够拿到的那些用户属性中，哪些对于分析有帮助，则作为Profile进行收集。

事件分析方法

行为事件分析

行为事件分析法用来研究某行为事件的发生对企业组织价值的影响以及影响程度。企业借此来追踪或记录用户行为或业务过程，如用户注册、浏览产品详情页、成功投资、提现等，通过研究与事件发生关联的所有因素来挖掘用户行为事件背后的原因、交互影响等。

行为事件分析涉及事件、维度和指标三个概念。在分析过程中，一般期望数据是实时采集并能够实时分析的，而事件、维度和指标是可以灵活自定义的。行为事件分析是上节内容讲到的Event实体的可视化展现，其中还将User实体的属性通过UserID贯穿到Event实体中，这样在分析时可以把用户属性作为分组或筛选的条件。

行为事件分析法具有强大的筛选、分组和聚合能力，逻辑清晰且使用简单，已被广泛应用。行为事件分析法一般经过事件定义与选择、多维度下钻分析、解释与结论等环节。

事件定义与选择。事件描述的是一个用户在某个时间点、某个地方、以某种方式完成了某个具体的事情。Who、When、Where、What、How是定义一个事件的关键因素。
多维度下钻分析。高效的行为事件分析要支持任意下钻分析和精细化条件筛选。当行为事件分析合理配置追踪事件和属性，可以激发出事件分析的强大潜能，为企业回答关于变化趋势、维度对比等各种细分问题。同时，还可以通过添加筛选条件，精细化查看符合某些具体条件的事件数据。
解释与结论。此环节要对分析结果进行合理的理论解释，判断数据分析结果是否与预期相符，如判断产品的细节优化是否提升了触发用户数。如果相悖，则应该针对不足的部分进行再分析与实证。

漏斗分析

现代营销观念认为：“营销管理重在过程，控制了过程就控制了结果。”漏斗分析模型是企业实现精细化运营的重要分析模型，其精细化程度影响着营销管理的成败。粗陋的漏斗分析模型因为“过程管理不透明”造成结果失控。

漏斗分析是一套流程分析，它能够科学反映用户的行为状态以及从起点到终点各阶段用户转化率情况的重要分析模型。

对于业务流程相对规范、周期较长、环节较多的流程分析，漏斗分析能够直观地发现和说明问题所在。值得强调的是，漏斗分析模型并非只是简单的转化率呈现，科学的漏斗分析模型能够实现以下价值。

1.企业可以监控用户在各个层级的转化情况。聚焦用户选购全流程中最有效转化路径，同时找到可优化的短板，提升用户体验。降低流失是运营人员的重要目标，通过不同层级的转化情况，迅速定位流失环节，针对性持续分析找到可优化点，以提升用户留存率。
2.多维度切分与呈现用户转化情况，成单瓶颈无处遁形。科学的漏斗分析能够展现转化率趋势的曲线，帮助企业精细地捕捉用户行为变化。提升了转化分析的精度和效率，对选购流程的异常定位和策略调整效果验证有科学指导意义。
3.不同属性的用户群体漏斗比较，从差异角度窥视优化思路。漏斗对比分析是科学漏斗分析的重要一环。运营人员可以通过观察不同属性的用户群体（如新注册用户与老客户、不同渠道来源的客户）各环节转化率，各流程步骤转化率的差异对比，了解转化率最高的用户群体，并针对转化率异常环节进行调整。

留存分析

随着市场饱和度上升，绝大多数企业亟待解决如何增加客户黏性，延长每一个客户的生命周期价值的问题。因此留存分析这一分析模型备受青睐。

留存分析是一种用来分析用户参与情况和活跃程度的分析模型，考察进行初始行为的用户中，有多少人会进行后续行为。这是用来衡量产品对用户价值高低的重要方法。

留存分析模型特点与价值：

1.留存率是判断产品价值最重要的标准，揭示了产品保留用户的能力。留存率反映的是一种转化率，即由初期不稳定的用户转化为活跃用户、稳定用户、忠诚用户的过程。随着统计数字的变化，运营人员可看到不同时期用户的变化情况，从而判断产品对客户的吸引力。
2.宏观把握用户生命周期长度及定位产品可改善之处。通过留存分析，我们可以查看新功能上线之后，对不同群体的留存是否带来不同效果？判断产品新功能或某活动是否提高了用户的留存率？结合版本更新、市场推广等诸多因素，去除使用频率低的功能，实现快速迭代验证，制定相应的策略。

分布分析

分布分析是用户在特定指标下的频次、总额等的归类展现。它可以展现出单用户对产品的依赖程度，分析客户在不同地区、不同时段所购买的不同类型的产品数量、购买频次等，帮助运营人员了解当前的客户状态，以及客户的运转情况。

科学的分布分析模型支持按时间、次数、事件、指标进行用户条件筛选及数据统计。为不同角色的人员统计用户在一天/周/月中，有多少个自然时间段（小时/天）进行了某项操作、进行某项操作的次数、进行事件指标。

分布分析的价值：

1.挖掘用户分布规律，优化产品策略。对同一指标下有关数据的统计与分析，帮助企业从中挖掘用户访问规律，企业可以将规律与实际产品策略相结合，进一步修正和重新制定产品策略。
2.运营并持续产品生命力，增加客户回访率。彻底改变之前依靠随机抽样的回访率调查方式，如电话回访等，分布分析从多角度分析辅助企业，判断单用户对产品的依赖程度，以及产品对用户的价值与黏性。
3.快速识别核心用户群体，资源配置有的放矢。核心用户群体是对企业价值贡献最大的用户群体，是企业最大的利润来源。不同用户群体对产品需求不一样，对用户群体进行差异性辨识，可以了解到用户群体对产品的依赖动力。分布分析通过不同维度筛选出核心用户群体，在此基础上，更好地配置优质资源，以最小成本实现企业利润最大化。

点击分析

点击图是点击分析方法的效果呈现。点击分析具有分析过程高效、灵活、易用和效果直观的特点。点击分析采用可视化的设计思想与架构，以简洁直观的操作方式，呈现访客热衷的区域，帮助运营人员或管理者评估网页设计的科学性。

点击分析的价值：

1.精准评估用户与网站交互背后的深层关系。
2.实现网页内跳转点击分析，抽丝剥茧般完成网页深层次的点击分析。
3.与其他分析模型配合，以全面视角探索数据价值，能够深度感知用户体验，实现科学决策。

用户路径

用户访问APP或网站，如同参观画展，每一位观众根据自身喜好形成特有的参观顺序。为让观众沿着最优访问路径前进，策展者需要结合观众需求进行布局调整。从一定程度上讲，用户路径分析为布局调整提供科学指导。

用户行为路径分析，顾名思义，是用户在APP或网站中的访问行为路径。为了衡量网站优化的效果或营销推广的效果，以及了解用户行为偏好，我们时常要对访问路径的转换数据进行分析。以电商为例，买家从登录到支付成功要经过首页浏览、搜索商品、加入购物车、提交订单、支付订单等过程。而用户真实的选购过程是一个交缠反复的过程，例如提交订单后，用户可能会返回首页继续搜索商品，也可能去取消订单，每一个路径背后都有不同的动机。与其他分析模型配合进行深入分析后，找到快速用户动机，从而引领用户走向最优路径或者期望中的路径。

用户路径分析的价值：

用户路径的分析结果通常以桑基图形式展现，以目标事件为起点或终点，查看后续或前置路径，可以详细查看某个节点事件的流向，总的来说，科学的用户路径分析能够带来以下价值。

1.可视化用户流，全面了解用户整体行为路径。通过用户路径分析，可以将一个事件的上下游进行可视化展示。用户即可查看当前节点事件的相关信息，包括事件名、分组属性值、后续事件统计、流失、后续事件列表等。运营人员可通过用户整体行为路径找到不同行为之间的关系，挖掘规律并找到瓶颈。
2.定位影响转化的主次因素，产品设计的优化与改进有的放矢。路径分析对产品设计的优化与改进有很大的帮助，了解用户从登录到购买整体行为的主路径和次路径，根据用户路径中各个环节的转化率，发现用户的行为规律和偏好，也可以用于监测和定位用户路径走向存在的问题，判断影响转化的主要因素和次要因素，并发现某些冷僻的功能点。

用户分群

因为群体特征不同，行为会有很大差别，因此可以根据历史数据将用户进行划分，进而再次观察该群体的具体行为。这就是用户分群的原理。

用户分群的定义用户分群即用户信息标签化，通过用户的历史行为路径、行为特征、偏好等属性，我们将具有相同属性的用户划分为一个群体，并进行后续分析。

用户分群分析的分类与价值用户分群通常被分为普通分群和预测分群。普通分群根据用户的属性特征和行为特征将用户群体进行分类，预测分群根据用户以往的行为属性特征，运用机器学习算法来预测他们将来会发生某些事件的概率。

用户分群具有以下价值。

1.帮助企业打破数据孤岛并真实了解用户。用户画像是用户分群的前提，对特定属性的用户群体进行持续深入的用户行为的洞察后，该用户群体的画像逐渐清晰。这些都有助于企业了解某个指标数字背后的用户群体具备哪些特征——他们是谁？行为特点有哪些？偏好是什么？潜在需求和行为喜好是什么？这是后续用户群体针对性分析的前提。
2.定位营销目标群体，帮助企业实现精准、高效营销。清晰勾勒某群体在特定研究范围内的行为全貌，并定义目标人群，是运营人员信息推送的前提。运营人员根据需求对特定目标人群完成精准信息推送工作，如召回流失用户、刺激用户复购等。当完成特定人群的精准信息推送工作之后，进一步分析以实时全方位查看营销效果，帮助企业与用户实现精准高效的信息互通。

属性分析

属性分析根据用户自身属性对用户进行分类与统计分析，比如查看用户数量在注册时间上的变化趋势、查看用户按省份的分布情况。用户属性涉及用户信息，如姓名、年龄、家庭、婚姻状况、性别、最高教育程度等自然信息，也有产品相关属性，如用户常驻省市、用户等级、用户首次访问渠道来源等。

属性分析模型的价值属性分析主要价值体现在丰富用户画像维度，让用户行为洞察粒度更细致。科学的属性分析方法，对于所有类型的属性都可以将“去重数”作为分析指标，数值类型的属性可以将“总和”“均值”“最大值”“最小值”作为分析指标，添加多个维度。

实际上以上各分析模型应该是一个综合体，它们之间存在无法割裂的关系。各分析模型实现科学互动和配合，能够科学揭示出用户个人或群体行为的潜在规律，并据此做出理论推导，不断在工作实践中优化商业决策和产品智能。

指标体系的构建

对于不同的产品，所要关注的指标不应该这么千篇一律，还是要根据产品特性来灵活定义。这里要说的是，我们所说的指标，并非企业管理环境的绩效指标，而是和业务运营相关的各种指标。指标体系分散在各个业务流程中，并由不同部门计算和分析。企业如何开展、管理、规划指标体系已成企业掌控数据的关键。

第一关键指标法

在企业发展的每个阶段，都有一个当前阶段高于一切、需要集中全部精力注意的一个数据，这个数据就是“第一关键指标”。当然，随着业务的发展，这个指标会发生变化。

第一关键指标可外延出更多指标，比如一个成熟的电商平台，第一关键指标一定是销售额，而销售额能够衍生访问量、转化率、客单价等多指标。企业运营人员或产品经理需要通过对衍生指标的优化，来促进第一关键指标的增长。因此，企业应该基于第一关键指标及衍生指标来衡量发展情况。让全企业员工明确当前阶段的核心目标，以此来制定与规划清晰任务。第一关键指标法和绩效管理中的KPI的理念比较接近，就是要寻找当前阶段整个公司最需要关注的指标，以此来集中火力向目标前进。

海盗指标法

2007年，500Startups创业孵化器的创始合伙人戴夫·麦克卢尔（DaveMcClure）针对创业公司应该关注的指标，提出了一套模型——PirateMetrics，即海盗指标法。他将创业公司需要关注的指标归结为5个方面，分别是Acquisition（获取）、Activation（激活）、Retention（留存）、Revenue（营收）和Referral（引荐），简称AARRR。

第一关键指标法定位了企业当前发展阶段的最重要问题，它关注全企业层面的运转健康，有利于让全公司形成合力聚焦同一目标。海盗指标法为企业提供了数据分析基础和罗盘，以及指导创业和企业发展的探索方向。

数据驱动商业决策

数据是验证实践的科学依据。数据驱动是最先进的生产力，让数据驱动落地企业，最为有效的方式是从上而下地推动。管理者推动的前提是其自身具备数据意识，能够认识到大数据的意义与价值，意识到数据管理不善可能带来的危害。若某下属费劲整理了一批数据报表，领导却对此无视，仍坚持拍脑袋做决定，这样企业数据发展就会陷入绝境。

数据驱动商业决策实现了以下三大价值。

1.透过现象看本质，提升企业决策的准确性与科学性。大数据时代改变了曾经仅依靠企业内部业务数据优化决策的情况，通过洞察“大”“全”“细”“时”数据背后的价值，赋予企业更加全面和准确的商业洞察力，大幅提升企业的商业决策水平，降低企业经营的风险。
2.用数据说话，降低企业沟通成本。“用数据说话”终止了企业团队之间因某一结果无休止争论的局面，降低了团队的沟通成本，缩短了企业研发时间。就像大家经常所说的，在争论中，如果两个人都没有数据，那么嗓门大的通常获胜。如果一个人有数据而另一个没有，那么有数据的通常会获胜。如果两个人都有数据，那就不需要争论了。
3.赋予企业全面准确的商业洞察力，实现智能商业预测。除了提升企业的商业决策水平之外，数据驱动商业决策还赋予企业商业预测的能力。大数据分析像一架望远镜，企业通过望远镜能够看到未来可能会发生的情况。智能商业预测帮助企业率先进一步挖掘市场，实现产品与服务上的创新，在诡谲多变的市场环境中取得先发优势。

数据驱动产品智能

所谓智能，我把它归结为这么一种模式：首先我们要有数据，然后在数据上套用某种算法模型，最后再将结果数据反馈到产品中，这样的产品就具备了一种“学习”能力，这就是我说的产品智能。

数据驱动决策将分析结果用于人的决策使用，而数据驱动产品智能更加强调数据的处理结果是给机器用的，并且这种数据分析的算法往往更加复杂，本身具有可以自我迭代的特点。

一个典型的数据平台架构

实时订阅：举个例子，一个用户在产品首页搜索了一个关键词“鲜花”，立即会有一条代表此行为的数据被发送到接收层。而后续的一个针对用户近期搜索行为提供推荐服务的模块则可以在1秒钟内拿到这个行为的数据，并且在用户访问下一个页面的时候及时提供“鲜花”相关的内容推荐。

人工智能领域的先驱者，ArthurSamuel在1959年创造“机器学习”这个概念时，这样对它下的定义：“Fieldofstudythatgivescomputerstheabilitytolearnwithoutbeingexplicitlyprogrammed”。简单来说，机器学习是研究通过不显式编程来赋予计算机学习能力的一个领域。从这个概念可以看出，与以往普通的计算机程序有一个最大的不同，就是机器学习并不是一个被完全设计好的程序，而是一种特殊的、能够自我提升的算法，让计算机自己从数据中学习并由此具备解决问题的能力。

回归算法在很多领域得到了普遍应用，在金融方面，可以用它来做股市行情分析和预测，在产品运营方面，可以用它来做产品流量预估；在生物领域，可以用它来做蛋白结合点位预测；在交通领域，可以用它来做道路流量预警。
分类算法也在各个领域都得到了广泛的应用，在金融方面，可以用它来识别作弊用户；在交通领域，车牌识别也是一种分类应用；在产品运营领域，它可以用作流失客户的预警，提前找到那些有可能流失的客户。
聚类算法同样也在很多不同的领域得到广泛应用。例如，在产品运营中，我们可以用聚类算法，自动聚合用户的行为轨迹，并且据此分析用户使用产品的习惯，用于改善产品交互设计；在图形学领域，基于聚类算法进行图像主题筛选也是一种常见的应用；甚至在防火墙领域，对于那些加密流量，也可以通过聚类算法来大概识别这些流量到底是什么类型的流量。

数据案例的实现步骤

需求梳理，区分业务线、业务流程
事件设计，主要区分事件本身和对应事件的扩展字段
数据接入，前端采集、后端采集

企业埋点规范：

最后的书评

书籍的前半部分给我惊喜，解答了很多我在搭建数据平台中的困惑，但是后半部分的信息量明显降低并且是在宣传神策公司，感觉作为一本知识型的数据，后半部分的大幅宣传不合适；

整体上我得到的并且对我有帮助的知识：

数据驱动的数据、信息、知识、智慧理论
数据驱动产品决策，也驱动产品智能
数据驱动的流，包括数据接入、传输、建模/存储、统计分析挖掘、可视化反馈
数据分析金字塔，采集、建模、分析、指标
数据埋点包括前端埋点、后端埋点、业务数据库，之前忽略了后端埋点
埋点方式分为无埋点/全埋点、代码埋点
对于埋点事件，最好引入元数据管理
多维事件模型event模型，引入who/when/where/what/how理论
模型分为行为模型event和用户模型user
几种数据分析方法：漏斗分析、分布分析、留存分析、用户路径、用户分群、点击分析
指标体系的构建：第一关键指标法、海盗指标法
数据的分析和实据的智能，可以连起来形成闭环

书中强调了多次数据驱动产品智能，不过对于智能这部分介绍的很浅显有点不匹配的感觉，可能是因为篇幅也可能是因为我更想看到更多对智能的思考和应用场景，而不是简单的介绍下算法和几个简单案例

当然，总体来说对我帮助很大，推荐4星/5星

本文地址：http://crazyant.net/2194.html，转载请注明来源

数据处理中提升性能的方法-引入并发但是避免同步

背景

只要存在数据库，就会有后台批量处理数据的需求，比如数据表备份、定期清理、数据替换、数据迁移，对于批量处理来说，往往会涉及大量的查询、过滤、归类、聚合计算，在批量脚本中直接查询数据库往往性能太低，甚至会因为一个大型的SQL导致数据库锁表出现线上事故，因此一般采用先导出到文件，在文件上计算然后再导入，比如：

1、使用mysql -e “select * from table” > output.txt的方式，执行SQL，将结果导出到文件中；
2、针对文件，使用各种方式进行聚合、过滤、替换等计算，最后产出成需要使用的格式；
3、发布产出的文件，或者使用load data命令导入到数据库；

由于只是一次性的批量查询数据库导出到文件，然后针对文件进行计算，而不是每次都查询数据库，大量节省了网络的IO耗费，从而提升处理的速度。

然而得到了导出的文件之后，如果文件过大，或者计算逻辑复杂比如大量的调用了耗费CPU的正则匹配、聚合计算，那么单线程的处理会耗费大量的时间，这时候就可以引入并发处理，使得机器的CPU、内存、IO、网络等资源全部充分利用起来，大幅度降低处理时间。

引入多线程，拆分输入文件为多个，每个小文件启动一个处理线程

HADOOP的MAP-REDUCE的做法，是先将文件split成小分片文件，然后针对每个分片做计算，最后将每个分片的结果聚合在一起，然而由于HADOOP的调度、集群稳定性等各种原因，对于MB大小级别的文件处理，会发现速度非常慢，有时候甚至比单机单线程处理速度还慢，将单机单线程改成多线程，往往会发现令人惊讶的效果提升。

直观的做法，是使用主线程读取输入的单个大文件，然后将读取的结果分配给子线程处理，然后主线程做整合，这种方式因为多线程共用了单个文件的IO，需要加入对文件的同步机制，最后会发现性能瓶颈在这单个文件的读取同步之上。

可以将大文件分片成小文件，然后每个文件分配给单个线程单独处理，避免线程间的资源同步，每个线程会享用单独的CPU核、内存单元、文件句柄，处理速度能达到最快。

使用这种方式，可以用以下的步骤进行：

1、使用SHELL，将输入文件拆分成预定线程数目的份数，存放到一个目录中；

2、以输入文件的目录路径作为参数，编程语言JAVA/PYTHON读取该目录的所有文件，对于每个文件启动一个处理线程，进行处理；

3、SHELL将输出目录的所有文件，使用cat file* > output_file的方式，得到最终的计算结果

#
# 将输入文件拆分成多个小文件，启动多线程进行处理，输出结果文件
#
function run_multi_task(){
	# 开启多个异步线程
	SPLITS_COUNT=20
	# 输入文件总数
	source_file_lines_count=`cat ${input_file} | wc -l`
	# 计算出拆分的文件个数
	split_file_lines_count=$(( $source_file_lines_count / $SPLITS_COUNT ))
	# 进行文件拆分
	split -l $split_file_lines_count -a 3 -d ${input_file} ${input_dir}/inputFile_
	
	# 执行JAVA程序
	$JAVA_CMD -classpath $jar_path "net.crazyant.BackTaskMain" "${input_dir}" "${output_dir}" "${output_err_dir}"
	
	# 合并文件
	cat ${output_dir}/* > ${output_file}
}

run_multi_task

这里注意，拆分文件的时候，不能使用split按照大小进行拆分，因为会把输入文件中的行截断；

对应的JAVA程序，则是通过读取文件夹中文件列表的方法，每个文件单独启动一个线程：

public class BackTaskMain {
    public static void main(String[] args) {
        String inputDataDir = args[1];
        String outputDataDir = args[2];
        String errDataDir = args[3];
        
        File inputDir = new File(inputDataDir);
        File[] inputFiles = inputDir.listFiles();
        
        // 记录开启的线程
        List<Thread> threads = new ArrayList<Thread>();
        for (File inputFile : inputFiles) {
            if (inputFile.getName().equals(".") || inputFile.getName().equals("..")) {
                continue;
            }
            
            // 针对每个inputFile，生成对应的outputFile和errFile
            String outputSrcLiceFpath = outputDataDir + "/" + inputFile.getName() + ".out";
            String errorOutputFpath = errDataDir + "/" + inputFile.getName() + ".err";
            
            // 创建Runnable
            BackRzInterface backRzInterface = new BackRzInterface();
            backRzInterface.setInputFilePath(inputFile.getAbsolutePath());
            backRzInterface.setOutputFilePath(outputSrcLiceFpath);
            backRzInterface.setErrorOutputFpath(errorOutputFpath);
            
            // 创建Thread，启动线程
            Thread singleRunThread = new Thread(backRzInterface);
            threads.add(singleRunThread);
            singleRunThread.start();
        }
        
        for (Thread thread : threads) {
            try {
                // 使用thread.join()，等待所有的线程执行完毕
                thread.join();
                System.out.println(thread.getName() + " has over");
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
        System.out.println("proccess all over");
    }
}

通过这种方式，将大文件拆分成小文件，启动多个线程，每个线程处理一个小文件，最终将每个小文件的结果聚合，就得到了最终产出，性能上却大幅提升。

若有依赖的资源，可以按线程先复制、拆分、克隆，防止依赖的资源成为性能瓶颈

在上面的代码中，BackRzInterface是每个线程启动时要使用的Runnable对象，可以看到用的是每次new的方式创建：

// 创建Runnable
BackRzInterface backRzInterface = new BackRzInterface();

这样每个处理线程依赖的BackRzInterface都是独立的，对这个Runnable代码的使用不会存在同步问题。

如果多线程处理中需要使用外部资源，最好想办法使得每个线程单独使用自己独占的资源，相互之间若不会存在冲突，可以实现最大化并发处理。

其他一些例子，比如：

多线程用到了字典文件，那么方法是首先将字典文件复制多份，每个线程使用自己独占的字典，避免并发同步访问字典；
多线程若需要统一ID发号，可以提前计算出每个输入文件的行数，然后依次生成第一个线程需要的ID范围、第二个线程需要的ID范围，这些不同的ID范围也可以分别生成不同的文件，这样每个线程会使用各自独立的ID资源，避免了多个线程单时刻访问单个ID发号服务，使得发号成为性能瓶颈的可能；
多线程如果依赖相同的Service，如果可以每次new对象就每次new，如果Bean都是在Spring中管理，则将Service加上@Scope(“prototype”)，或者将对象每次clone一下得到一个新对象，保证最终每个线程使用自己独占的对象。
尽量使用函数式编程的思想，每个函数都不要产生副作用，不要修改入参，结果只能通过return返回，避免增加代码同步冲突的可能；

通过以上这些类似的方法，每次将可能需要同步访问的共享资源，通过复制、分片等手段得到不同份，每个线程单独访问自己那一份，避免同步访问，最终实现性能最优。

避免同步的终极方法：使用多进程进行实现资源隔离

如果将文件拆分成了多份，依赖的ID、词典等资源也相应提供了多份，但是发现代码中存在无法解决的代码级别同步，该怎么办呢？

相对于想尽办法解决代码中的同步问题来说，多线程和多进程之间的性能差别微乎其微，我们都知道线程会使用进程的资源，所以导致了线程之间存在竞争进程资源，但是对于进程来说，CPU、内存等硬件资源是完全隔离的，这时候将程序运行在多进程而不是多线程，反而能更好的提升性能。

对于一些支持多线程不好的语言，比如PHP，直接用这种多进程计算的方法，速度并不比支持多线程的JAVA、PYTHON语言差：

# 要拆分的文件数，也就是要启动的多进程数
SPLITS_COUNT=20

input_splits_dir="${input_dir}_splits"
output_splits_dir="${output_dir}_splits"
# 输入文件行数
source_file_lines_count=`cat ${input_file} | wc -l`
# 每个文件拆分的行数=总行数除以要拆分的文件个数（也就是对应进程的个数）
split_file_lines_count=$(( $source_file_lines_count / ${SPLITS_COUNT} ))
# 执行拆分，注意这里使用-l进行行级别拆分更好
split -l $split_file_lines_count -a 3 -d ${input_file} ${input_splits_dir}/inputfile_

process_idx=1
for fname in $(ls ${input_splits_dir}); do
	input_fpath=${input_splits_dir}/$fname
	ouput_fpath=${output_splits_dir}/$fname
	# 后台执行所有进程
	php "/php/main.php" "${input_fpath}" "${ouput_fpath}" &
	(( process_idx++ ))	
done

# 等待所有后台进程执行结束
wait

# 合并文件
cat $output_splits_dir/* > ${output_file}

上述代码中，使用shell的&符号，可以在后台同时启动多个进程，使用wait语法，可以实现多线程的Thread.join特性，等待所有的进程执行结束。

总结

对于输入文件的大小、计算的复杂度处于单机和集群计算之间的数据处理，使用并发处理最为合适，但是并发的同步处理却会降低多线程的性能，这时可以借助于输入文件复制拆分、依赖资源复制拆分切片等方法，实现每个线程处理自己的独占资源，从而最大化提升计算速度。而对于一些无法避免的代码同步冲突逻辑，可以退化为多进程处理数据，借助于SHELL的后台进程支持，实现进程级别的资源独占，最终大幅提升处理性能。