• 整体架构
• 数据采集
• 数据存储与分析
• 数据共享
• 数据应用
• 实时计算
• 任务调度与监控
• 元数据管理
• 总结

一直想整理一下这块内容，既然是漫谈，就想起什么说什么吧。我一直是在互联网行业，就以互联网行业来说。
先大概列一下互联网行业数据仓库、数据平台的用途：

1. 整合公司所有业务数据，建立统一的数据中心；
2. 提供各种报表，有给高层的，有给各个业务的；
3. 为网站运营提供运营上的数据支持，就是通过数据，让运营及时了解网站和产品的运营效果；
4. 为各个业务提供线上或线下的数据支持，成为公司统一的数据交换与提供平台；
5. 分析用户行为数据，通过数据挖掘来降低投入成本，提高投入效果；比如广告定向精准投放、用户个性化推荐等；
6. 开发数据产品，直接或间接为公司盈利；
7. 建设开放数据平台，开放公司数据；

上面列出的内容看上去和传统行业数据仓库用途差不多，并且都要求数据仓库/数据平台有很好的稳定性、可靠性；但在互联网行业，除了数据量大之外，越来越多的业务要求时效性，甚至很多是要求实时的 ，另外，互联网行业的业务变化非常快，不可能像传统行业一样，可以使用自顶向下的方法建立数据仓库，一劳永逸，它要求新的业务很快能融入数据仓库中来，老的下线的业务，能很方便的从现有的数据仓库中下线；

其实，互联网行业的数据仓库就是所谓的敏捷数据仓库，不但要求能快速的响应数据，也要求能快速的响应业务；

建设敏捷数据仓库，除了对架构技术上的要求之外，还有一个很重要的方面，就是数据建模，如果一上来就想着建立一套能兼容所有数据和业务的数据模型，那就又回到传统数据仓库的建设上了，很难满足对业务变化的快速响应。应对这种情况，一般是先将核心的持久化的业务进行深度建模（比如：基于网站日志建立的网站统计分析模型和用户浏览轨迹模型；基于公司核心用户数据建立的用户模型），其它的业务一般都采用维度+宽表的方式来建立数据模型。这块是后话。

整体架构

下面的图是我们目前使用的数据平台架构图，其实大多公司应该都差不多：

逻辑上，一般都有数据采集层、数据存储与分析层、数据共享层、数据应用层。可能叫法有所不同，本质上的角色都大同小异。
我们从下往上看：

数据采集

数据采集层的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。
数据源的种类比较多：

• 网站日志：

作为互联网行业，网站日志占的份额最大，网站日志存储在多台网站日志服务器上，
一般是在每台网站日志服务器上部署flume agent，实时的收集网站日志并存储到HDFS上；

• 业务数据库：

业务数据库的种类也是多种多样，有Mysql、Oracle、SqlServer等，这时候，我们迫切的需要一种能从各种数据库中将数据同步到HDFS上的工具，Sqoop是一种，但是Sqoop太过繁重，而且不管数据量大小，都需要启动MapReduce来执行，而且需要Hadoop集群的每台机器都能访问业务数据库；

应对此场景，淘宝开源的DataX，是一个很好的解决方案（可参考文章 《异构数据源海量数据交换工具-Taobao DataX 下载和使用》），有资源的话，可以基于DataX之上做二次开发，就能非常好的解决，我们目前使用的DataHub也是。当然，Flume通过配置与开发，也可以实时的从数据库中同步数据到HDFS。

• 来自于Ftp/Http的数据源：

有可能一些合作伙伴提供的数据，需要通过Ftp/Http等定时获取，DataX也可以满足该需求；

• 其他数据源：

比如一些手工录入的数据，只需要提供一个接口或小程序，即可完成；

数据存储与分析

毋庸置疑，HDFS是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。

离线数据分析与计算，也就是对实时性要求不高的部分，在我看来，Hive还是首当其冲的选择，丰富的数据类型、内置函数；压缩比非常高的ORC文件存储格式；非常方便的SQL支持，使得Hive在基于结构化数据上的统计分析远远比MapReduce要高效的多，一句SQL可以完成的需求，开发MR可能需要上百行代码；

当然，使用Hadoop框架自然而然也提供了MapReduce接口，如果真的很乐意开发Java，或者对SQL不熟，那么也可以使用MapReduce来做分析与计算；

Spark是这两年非常火的，经过实践，它的性能的确比MapReduce要好很多，而且和Hive、Yarn结合的越来越好，因此，必须支持使用Spark和SparkSQL来做分析和计算。因为已经有Hadoop Yarn，使用Spark其实是非常容易的，不用单独部署Spark集群，关于Spark On Yarn的相关文章，可参考：《Spark On Yarn系列文章》
实时计算部分，后面单独说。

数据共享

这里的数据共享，其实指的是前面数据分析与计算后的结果存放的地方，其实就是关系型数据库和NOSQL数据库；

前面使用Hive、MR、Spark、SparkSQL分析和计算的结果，还是在HDFS上，但大多业务和应用不可能直接从HDFS上获取数据，那么就需要一个数据共享的地方，使得各业务和产品能方便的获取数据；

和数据采集层到HDFS刚好相反，这里需要一个从HDFS将数据同步至其他目标数据源的工具，同样，DataX也可以满足。

另外，一些实时计算的结果数据可能由实时计算模块直接写入数据共享。

数据应用

• 业务产品

业务产品所使用的数据，已经存在于数据共享层，他们直接从数据共享层访问即可；

• 报表

同业务产品，报表所使用的数据，一般也是已经统计汇总好的，存放于数据共享层；

• 即席查询

即席查询的用户有很多，有可能是数据开发人员、网站和产品运营人员、数据分析人员、甚至是部门老大，他们都有即席查询数据的需求；

这种即席查询通常是现有的报表和数据共享层的数据并不能满足他们的需求，需要从数据存储层直接查询。

即席查询一般是通过SQL完成，最大的难度在于响应速度上，使用Hive有点慢，目前我的解决方案是SparkSQL，它的响应速度较Hive快很多，而且能很好的与Hive兼容。

当然，你也可以使用Impala，如果不在乎平台中再多一个框架的话。

• OLAP

目前，很多的OLAP工具不能很好的支持从HDFS上直接获取数据，都是通过将需要的数据同步到关系型数据库中做OLAP，但如果数据量巨大的话，关系型数据库显然不行；

这时候，需要做相应的开发，从HDFS或者HBase中获取数据，完成OLAP的功能；

比如：根据用户在界面上选择的不定的维度和指标，通过开发接口，从HBase中获取数据来展示。

• 其它数据接口

这种接口有通用的，有定制的。比如：一个从Redis中获取用户属性的接口是通用的，所有的业务都可以调用这个接口来获取用户属性。

实时计算

现在业务对数据仓库实时性的需求越来越多，比如：实时的了解网站的整体流量；实时的获取一个广告的曝光和点击；

在海量数据下，依靠传统数据库和传统实现方法基本完成不了，需要的是一种分布式的、高吞吐量的、延时低的、高可靠的实时计算框架；

Storm在这块是比较成熟了，但我选择Spark Streaming，原因很简单，不想多引入一个框架到平台中，另外，Spark Streaming比Storm延时性高那么一点点，那对于我们的需要可以忽略。

我们目前使用Spark Streaming实现了实时的网站流量统计、实时的广告效果统计两块功能。

做法也很简单，由Flume在前端日志服务器上收集网站日志和广告日志，实时的发送给Spark Streaming，由Spark Streaming完成统计，将数据存储至Redis，业务通过访问Redis实时获取。

任务调度与监控

在数据仓库/数据平台中，有各种各样非常多的程序和任务，比如：数据采集任务、数据同步任务、数据分析任务等；

这些任务除了定时调度，还存在非常复杂的任务依赖关系，比如：数据分析任务必须等相应的数据采集任务完成后才能开始；数据同步任务需要等数据分析任务完成后才能开始；

这就需要一个非常完善的任务调度与监控系统，它作为数据仓库/数据平台的中枢，负责调度和监控所有任务的分配与运行。

前面有写过文章，《大数据平台中的任务调度与监控》,这里不再累赘。

元数据管理

这块想要做好，非常复杂，我觉得是且价值小于成本，因此我们暂不考虑这块。目前只有每天任务运行的元数据。

总结

在我看来，架构，并不是技术越多越新越好，而是在可以满足需求的情况下，越简单越稳定越好。目前在我们的数据平台中，开发更多的是关注业务，而不是技术，他们把业务和需求搞清楚了，基本上只需要做简单的SQL开发，然后配置到调度系统就可以了，如果任务异常，会收到告警。这样，可以使更多的资源专注于业务之上。

相关阅读：
大数据平台任务调度与监控系统
Spark On Yarn系列文章
异构数据源海量数据交换工具-Taobao DataX 下载和使用

好了，就这些吧，后面想到了再漫谈吧。码字很累的，希望多多支持我的博客。
转载请注明：lxw的大数据田地 » 大数据环境下互联网行业数据仓库/数据平台的架构之漫谈

【李楠的回答(119票)】:

我可能比较“老派”。。

1 github

一个付费的 github 我认为是最必要的。它可以一下子解决代码托管， issues ， wiki 三个小团队最需要的东西。

2 testflight

团队管理中最容易忽视的，却最重要的东西是。。。

“发布”

无论一切多么井井有条，不能频繁发布的团队也是危险的。

所以，可控制灰度的空中测试工具也很重要。移动项目导入 testflight 是必要的。

3 invision

另外， github 不适合设计的交流，和 basecamp 比较，个人更喜欢 invision 。

4 微信群

相信我，你们需要一个微信群 － 他非常有利于实时的消息共享。

5 最后的话

github + invision + testflight ＋ 微信群基本可以解决：

需求文档（ github wiki ） －> 课题跟踪( github issues ) -> 设计讨论( invision ) -> 代码托管( github ) -> 灰度发布( testflight ) 的整个的流程。

6 工具之外的话

但是，工具之外，更重要的是你的团队组织和管理方法。

团队都有什么角色？如何分工？需要那些规定和流程（会议安排，迭代周期等等）？

个人的推荐是 SCRUM 。

其实，只要组织和管理方法定了，工具反而不重要了，Low-tech 也可以很高效：

7 广告

有没有把“方法”和“工具”更好的结合在一起的团队协作工具？目前真的没有看到很好的。

不过，也许过一段我们会拿出一个。。。敬请期待。

【马力的回答(36票)】:

小团队协作，首先要明确的是协作的目的是为了提高效率，辅助沟通，帮助记录，而不是为了流程而流程，为了看起来理想的套路，盲目的希望通过工具来标准化大家的行为，这样往往会适得其反，最终难以推行下去。

这里的关键点在于，根据团队和工作的特点，把握好人机分工的度，哪些是需要通过流程解决，用计算机来辅助解决，哪些是留给人的空间，给人足够的自由度，避免工具反过来成为制约。常犯的错误是对后者的忽视。

我们在选择工具时，伙伴做了很多探索（感谢我们的 Geek伙伴），几乎主流的工具都品味了一下，最终选择了 Trello。我自己现在的体会是，Trello 好在你以什么样的程度去用都可以，简单当看板用也可以，再复杂点支持更多项目管理内容也能用，没有一个高学习成本和固化的套路，这很好。

我们非常注意何时将其用作流程工具、何时用作沟通工具、何时用作记录工具。例如，昨天我们还进行了一个小的讨论，某件工作本身是流程化的，我们在探讨是否应该使用工具来固化下来流程，在每一个步骤大家应该在工具里做什么样的操作、标记等等。但是后来发现，在这里其实有好几个主要环节，由人直接去线下实施，而不是先让信息在计算机里绕一圈，会更有效率，只需要将结果记录在工具中即可，过程可以非常有弹性。最终我们的结论是，只需要明确流程（哪怕是以邮件或口头通知的形式），在线下流程已经有效率的情况下，无需再使用工具来看起来「很规范」。

对于小团队，中国的团队，工具越简单越好，越轻量级越好，越灵活越好，越能够根据团队和实际工作选择性使用越好，而不是盲目追求强大，追求自动化。

Trello:

其他工具，例如 Github 等，也非常有帮助。

【李会军的回答(28票)】:

以前回答过类似的问题 http://www.zhihu.com/question/20114578/answer/21067452，我觉的答案非常适合这个问题，等有机会再写一篇文章专门讨论。

大部分朋友都推荐一堆的工具，我个人认为对于创业团队未必适合使用这么多的沟通交流以及团队协作工具：

1. 工具比团队人数多

简单统计一下，有邮件Email、即时通讯IM、日程管理 Google Calendar、文档协作Google Docs、项目管理Basecamp、群组聊天 Campfire 、文件共享Dropbox、缺陷跟踪 Lighthouse，这就已经有八个工具了，试想对于小创业公司来说，团队成员人数都不一定能有这么多，少则两三人、多则七八人。每个成员还要分别注册不同的系统帐号，才能跟大家一起工作，这是在提高效率，还是在降低效率？

2. 各个工具的数据无法共享

使用太多的工具造成的另外一个问题就是各个系统之间的数据无法共享，邮件分散的各自的邮箱里，IM聊天记录在各个成员的电脑里，Dropbox里的文件怎么跟Basecamp结合，怎么跟缺陷跟踪工具结合？经常想起一件事的时候，不知道应该去Dropbox里找文件还是去Email里面查找附件，又或者去Basecamp里找。工具应该是为人服务，人不应该被工具所牵绊。

3. 简单够用就好

结合以上两点，我认为在创业团队中，不需要太多的工具，下面是我们团队的使用情况：

1）Email：Email的地位始终无法取代，Email是必须的，我们使用的是 腾讯企业邮箱，Gmail由于众所周知的原因，无奈放弃。

2）GitHub ：源码管理，放弃自己搭建git、svn服务器的想法吧，在Github每月支付几美元就够用了，一年也花不了几个钱。我们所有的源代码都放在Github。

3）Worktile ：我们团队自己的产品，自产自销。用它做项目管理、缺陷跟踪、文件共享、群组聊天和文档协作，各个元素之间可以很好的互相配合。有朋友会问，Worktile做了这么多，估计哪个都做不专。这点我承认，文件共享我们不如Dropbox，文档协作不如Google Docs，但是仔细想想，我们真的用了Google Docs的全部功能了吗，还是那么句话，够用就好。再补充一点，Worktile可以很好的跟Email结合，通过Email创建任务、发起讨论，这样不就把把团队的资源连接起来了吗？

总结，我们内心始终在追求强大的工具，却忽略了寻找工具是为了解决团队问题。选择适合你的团队、满足需要的少数几个工具足以，用好工具才是关键，对于创业团队尤为重要。切记，别让你的团队使用的工具数比团队人数还多！

和其他互联网产品团队交流的过程中，许多朋友都提到过一个问题，怎么为自己的产品选择一个适合的设计方案？在有道云笔记iPhone新版的产品设计中，我们遇到的就是上述问题的一个典型情况。经过近4个月的探索和实践，我们找到了一些适合有道的解决方案。在知乎上分享出来，希望和有类似问题的朋友一起探讨。

文章比较长，为了让大家觉得这个分享可能真的有用，先列一些效果数据，吹吹牛皮。有道云笔记iPhone新版推出后，日活上升25%，人均每日新建笔记数量上升100%。用户对产品的评价方面，产品NPS达到55，到达历史最高峰，App Store五星好评达91%。初步数据显示改版还是比较成功的。

那么，下面就来说说我们的思考过程。

改版时机选择：产品需要跨越“早期尝鲜者”和“早期大众”的鸿沟

有道云笔记第一次和大家见面是在2011年6月。经过两年多的发展，云笔记的用户量从0飞速增长到2000多万。在这个过程中我们深切地感受到整个云笔记品类在中国用户的快速发展。从最开始还需要和周围的朋友介绍“云笔记”是什么，到现在许多人已经可以列举出几个尝试过的云笔记品牌。这也意味着云笔记已经从早期的GEEK型的“创新者”和“早期尝鲜者”，向更加广泛、主流的“早期大众”转化。我们有幸站在了这个鸿沟面前，如果能成功跨越，则可以把云笔记带入更加庞大的主流市场。

通过我们的用户调研，有道云笔记的主流大众用户已经越来越多，云笔记的初级/中级用户已占到总用户量的70%。因此，我们觉得是时候想想，对于初级和中级云笔记用户来说，有道云笔记的iPhone端应该是个什么样子。

改版目标：为主流用户提升基础功能使用效率

根据我们的调研发现，有道云笔记iPhone版最频繁使用的两大功能是：浏览笔记和快速的碎片化记录。数据显示，每天超过6成的iPhone端用户在浏览笔记内容，而大约3成的用户在做碎片化记录。而在我们的调研中，初级/中级用户表示，他们认同产品的高级功能（白板纠偏、笔记分享、待办事项、附件中心、笔记标签、微信收藏、阅读密码等），因为这些功能让他们确保这个产品是值得信赖和有潜力的。但他们觉得在当下自己并不需要知道如何使用这些高级功能。

于是摆在我们面前有两条路：

1.为GEEK开发更多、更酷的高级功能，让他们形成口碑带动主流大众用户；

2.为大众用户设计更简单实用的操作界面，核心功能被放在应用中垂手可得的位置，不用记也不用找，真正做到“Don't Make Me Think”。

前面说过，我们目前最重要的目标就是跨越鸿沟。因此对于现在的云笔记，我们缺的不是酷炫、亮眼的高级功能，而是如何让小白用户，在接触这个产品的前三分钟就能快速上手，并被打动。

因此，最终我们选择了后者。

因此，此次改版的目标就十分清晰：为主流大众用户提升基础功能使用效率——也就是，让用户非常直观地进行笔记内容浏览和随手记录。

实施改版的三个阶段：定义基础交互、定义视觉方案、优化关键路径

• 1.定义基础交互

确定了目标后，我们需要确定云笔记的基础交互模式。我们又面临了一个选择：标签栏or抽屉式交互。

从发布以来，我们一直采用标签栏（Tab Bar）的交互模式来引导用户在不同的功能中切换，这也是应用市场上最常见的交互模式。标签栏具有可直接展示内容，同时支持快速切换分类的优点，适合有5个以内核心分类且各分类都有较高使用率的应用。对于有道云笔记来说，这种交互模式会很适合极客用户去探索各种高级功能，同时保障对基础功能的便捷操作。2013年Google讲解了抽屉式交互（Navigation Drawer）的理念后，这种交互模式也开始被广泛使用。相比标签栏，抽屉式更少占用宝贵的屏幕空间，可以最大化地展示内容。同时，由于没有其他因素的干扰，可以让用户聚焦于当前内容。此外，抽屉内层级设计的灵活性可以很好地支持不同分类及层级间的切换，适合对导航的灵活性需求高的应用。

新版设计的目标是让用户非常直观地进行笔记内容浏览和随手记录。浏览行为需要最大化的、没有干扰的展示空间，而随手记录追求更快和更轻的体验。基于这两个核心目标，我们选择了抽屉式的交互模式。在这个模式下，用户一打开笔记就可以直接浏览最近修改过的笔记内容， 展示空间更大，干扰因素也被最小化。通过在主界面支持一键新建笔记，记录过程做到又轻又快。此外，通过抽屉内的功能入口，用户也保留了快速访问高级功能的便利。下面一张图比较直观的展示了新旧两版交互方式的对比。

• 2.定义视觉方案

这次全面改版中，我们也重新定义了云笔记的视觉方案。根据云笔记用户的特点，视觉方案的三个关键词被定义为个性化、年轻化、扁平化。

个性化的落脚点是增强用户对笔记账号的认知。作为跨同平台同步的云笔记，用户的笔记账号是整个过程的核心枢纽。在我们的视觉方案中，用户账号不再是一个邮箱号，而被添加了用户头像、昵称、性别等元素，并被放在了一个非常醒目的位置——侧滑抽屉界面的顶部。我们希望通过这样的设计来向用户传递“有道云笔记是伴随你个人的笔记”这一理念。

作为一款效率应用，有道云笔记的主色调一直是代表稳重、高效的深蓝色。越来越多的年轻白领和高校在校生成为了云笔记的用户，他们充满活力、对时尚敏感、敢于尝试新鲜事物。为了增加云笔记对更加年轻化的用户群的吸引，我们的新视觉方案采用了更加有趣和活泼的视觉元素，在色彩比例上以浅色为主、点缀活泼的几种颜色。此外，在这次改版中，我们也顺应了扁平化设计趋势，配合交互，让用户可以体会到简洁的风格。

• 3.优化关键路径

除了重新定义了主交互模式和主视觉方案，这次改版还针对用户使用云笔记的关键路径进行了优化。这里举几个例子。

1)提高首页浏览的效率

有道云笔记的特点之一是能够让用户以多种多样的形式来记录笔记：文字、图片、声音、手写、附件等等。

我们的调研发现，当用户对笔记进行快速浏览、定位时，笔记内容和笔记标题一样重要。因此在新版中，笔记核心内容要素被放置到和笔记标题一样重要的位置——在首页的笔记列表中展示出来。这样用户在浏览笔记列表时，可以通过笔记标题、正文摘要、图片摘要、附件摘要等元素快速定位笔记。

伴随这个设计浮现的一个难点，是视觉上比文字更“重”的图片和文件元素打破了笔记列表的节奏感，使列表略显凌乱。期间我们进行了多次尝试，最后聚焦在卡片和内容分割两种样式上。

通过对两种样式原型的反复试用和比较，我们意识到卡片虽然可以强制的对内容进行分割，但是以内容元素的组织进行分割更符合我们的设计原则——以最简约的形式让用户专注于笔记内容本身。我们通过对标题文字的颜色、摘要、图片、附件等元素间距的细微调整，使之更合理优雅的出现页面中。

2)快速的碎片化记录

新版中，我们将新建笔记按钮从首页的底部中间移至右下角。点击醒目的绿色加号按钮，用户一键即可新建笔记。类似的加号设计在很多应用上也可以看到。与其他应用不同，点击加号按钮后，笔记应用不会展示出让用户选择新建笔记类型的选项，而是直接进入了编辑界面的文字编辑状态。

这个设计基于的原则是"为用户的主要场景优化"。通过用户数据，我们发现用户在新建笔记时，文字类型笔记的比例远高于其他几类笔记。因此对于初中级用户而言，让TA不用思考和选择，直接开始记录文字类型笔记是最合适的。更加复杂的图片、音频、附件等其他内容类型，可以通过长按或进入编辑界面进行添加。

实施改版项目的敏捷管理

说完了设计思路的选择，最后再说说我们团队在这个改版项目上的敏捷管理方式。

我们从比较早就开始使用敏捷开发进行项目管理（相关内容可以参考：有道云笔记的Scrum敏捷开发实践）。在这次的改版项目上，我们在原有的敏捷项目管理的基础上做了进一步的优化。iPhone端改版项目开始于2013年底。项目共经历三个阶段：基础交互和主视觉定稿阶段、主体界面与功能开发阶段、面向体验的极速迭代开发阶段。重点分享下在第三阶段的改变和优化。

第一个阶段：基础交互和主视觉定稿阶段

产品经理和设计师一起反复比稿，最终确定了改版项目的主方向：以抽屉式交互为基础交互和主视觉方案的三个关键词是个性化、年轻化、扁平化，以及新版90%的交互设计图和视觉设计图。这个阶段耗时1个月。

第二个阶段：主体界面与功能开发阶段

研发团队参与到这个项目中。在这个阶段中，我们团队采用敏捷迭代的开发方式，通过3个迭代周期（每个迭代周期2周，共1.5个月）完成了新版85%的主体界面和功能。随着这个阶段接近尾声，我们意识到这个阶段的新版云笔记的完成度虽然高，但是还远不能让我们自己满意。

这其中部分的原因是由于剩余15%的界面和功能没有完成，而更主要的原因是设计与体验之间的差距。换句话说，只有当工程师按照设计实现了产品后，我们才发现原来的设计的真实体验并不是完全和我们想象的一样。这时候，常规的敏捷迭代方式不再适合解决我们面临的问题。因为常规的敏捷迭代的原则之一是"在迭代周期内尽量不要修改产品设计需求"，而这中工作方式需要产品设计相对稳定。因此我们在第二个阶段后改换了工作模式，进入了第三个阶段。

第三个阶段：面向体验的极速迭代开发阶段

这个阶段可以说是这次改版项目中最关键的一个环节。在这个阶段里面我们不再有明确的迭代周期，而是围绕一处处影响用户体验的关键点进行极速迭代。研发团队针对这一个个关键点以天为周期进行迭代修改；核心用户群（由产品经理、设计师、资深用户）同样以天为周期安装最新安装包并在真实的环境中用自己真实的笔记账号体验，向研发团队提出对这些关键点的反馈和进一步修改意见。对于一些无法判断的关键点，研发团队甚至会打多个安装包让核心用户群作对比。例如说，围绕"提高首页浏览的效率"这个关键路径，核心用户群围绕加载流畅度、图片滑动体验、图片缩略图视觉体验、笔记列表分割体验等多个维度提出了几十个反馈意见。与之对应，研发团队先后迭代开发了近20个版本，最终在这个体验关键点上与核心用户的预期达成一致。这次改版的第三个阶段耗时1.5个月。

此次有道云笔记iPhone改版对有道云笔记团队来说是一次自我学习、自我突破的过程。接下来我们也会把相关经验和体会应用在其他平台上，希望通过每一步的努力让有道云笔记变得更加符合中国人的使用习惯，为改变国人的记录方式出一份力量。也希望能借此机会和业内同行学习和探讨。

本文作者为大众点评网的产品经理小石头，作者在入职的半年来在产品经理的工作上取得了长足的进步，为此雷锋网特意约稿一篇，让石头兄分享过去一年里在产品经理领域学习的经验。

半年多，竞品分析不多，十来个吧，长期跟踪的就一两个，一点点经验总结，写出来啰嗦一长串，竞品分析，主要用于熟悉用户、了解业界动态、跟踪竞争对手、跟自身产品做对比，更好地改进产品及适应市场。

1. 广义的和狭义的竞品

一般的竞品，都是狭义的竞品，比如相同行业或模式，都是O2O；或者就是直接的竞争业务，比如找餐馆，比如基于LBS的个性化推荐；

广义的竞品，就是所有你所能见到，所能看到；从国外最新的App动态，甚至到路边设计比较好的广告牌，再甚至loft办公环境下的楼梯；可能现在木有用，但是多思考一层，他为啥要这么设计，slogan是否吸引你，目标定位是谁？比如：地铁上是一个快速学习，快读迭代的地方，各大互联网公司都喜欢在地铁做广告，因为地铁用户跟互联网用户match程度灰常高。

2. 竞品的跟踪

哪些竞品需要长期跟踪：直接竞争对手、行业老大、或者新兴追赶者或创业者；曾经在团购的时候，天天盯着Groupon、美团；国内所有团购网站都订阅一遍，看每天的EDM，观察是否改版，以及尝试从第三方获取一些数据；值得研究的竞品，国内外很多很多，判断是否值得跟踪，一做减法，二是不浪费时间在没必要的事情上。毕竟PM有很多事情要做，竞品在日常工作中，所占比重并不大。

3. 竞品都关注啥

竞品分析因为所在部门不同，所关注点也不一样，跟UED童鞋在一起讨论，更多的注重用户体验和设计；跟市场童鞋在一起，更多的关注用户覆盖、市场占有、以及商业等；运营同学更多的是关注运营活动，比如参与人数，是带来品牌效应，提高曝光还是导入流量，以及流量的转化率等。作为一个产品，可能以下这些关注点都需要：用户体验、创意设计、产品定位、运营规则、商业模式等。

4. 竞品分析及报告

工作半年，长期跟踪的竞品有一两个，做过短期调研的国内外竞品十来个，有些形成了报告，有些只是停留在尝试使用，甚至直接放弃。我在做竞品分析时，一般套路是：

5. 用户群体

因为是O2O行业，所以用户细分会比较厉害，同样用户群也比较好抓取，比如某个App他只针对某地区的某类人，如为商圈附近的白领午饭服务；这样切分好用户类型，在使用过程中，就可以把自己放到那个情境下

6. 市场定位

综合考虑此应用或网站的定位；如果一个新产品无法考量，可以从注册用户数，活跃用户数、增长速度、同类产品等等去分析，或者把几个类似产品拿到一起去比较；拿不到数据？等会下面相关数据会告诉你怎么取数据。

7. 核心功能

就是此应用或网站，能够满足用户某种最核心的需求；是找美食，还是叫外卖；可能都兼有，但是核心内容就是方便用户，而且不能多。在尝试使用产品或写报告时，一定要体验完主流程，再去考虑辅助流程或者功能；若在体验过程中，被某分支流程所吸引过去，需要反思，这里的设计是否合理？其他用户在使用时，是否也会“误入歧途”？有时候真的不是主流程不够好，而是给用户选择太多，导致迷失。

同样在写分析报告（个人习惯ppt），会在主流程介绍中，加一个流程图，一般完成这个主要功能，用户需要多少步，当前处于第几步。这样不管是自己，或者看到此分析报告的每一个人，都会清晰明了，这个产品主要实现的功能，以及当前所处位置。

一款产品，一般能满足一两个重要需求，其他的辅助分支流程，适当选择忽略吧，竞品分析报告，没有必要做的又臭又长。

产品设计：在使用时，我会留意那些让我心动、不经意发现、当我需要它已然存在的设计；然后在分析报告的主流程里，以tips的形式，展现这些心动的设计，并且将可以借鉴的部分，自己做个积累，或许自己的产品将来有用

（若无特别注明，雷锋网文章皆为原创，转载请注明出处)

原文链接: http://www.leiphone.com/s-dianping-pm.html

刚写了作业，正好与此有关。虽然质量不高，但是因为未见相似的答案，我就贴出来吧。

2003年是韩国电影史上重要的一年。这一年，除了奉俊昊堪称完美的《杀人回忆》，还有朴赞郁那情节诡异，行为癫狂，受昆汀.塔伦蒂诺青睐的《老男孩》和具有独特的华丽忧伤气质的恐怖片大师金知云的《蔷花，红莲》以及总是以灰暗基调叙事，淡青色调画面创作的金基德的《春夏秋冬又一春》。由此，韩国电影真正引起世界电影界的关注。

从1999年姜帝圭的《生死谍变》开始，四年间，韩国电影全面崛起。从此，不但商业片一片繁荣，艺术片也得以成功探索。正是这样的年份，全面完美的《杀人回忆》也变成“全面平庸”。

本片是奉俊昊的第二部长片。带给人的惊艳却犹如库布里克。《杀人回忆》之后，虽然商业片归商业片，艺术片归艺术片的趋势还在延续，但是它为后来者树立了一个榜样：主流商业片也可以有深刻的艺术性。不但技巧成熟，立意新颖，也思想深邃，关键是掷地有声。有人看，才是电影的意义所在。

《杀人回忆》是一部完美的电影。影史上极少有堪称完美的电影，大多人也不愿意断然肯定有完美的存在。每个人心目中都有一个哈姆雷特，我心目中的那个，是完美的电影榜单。《公民凯恩》和《八部半》赫然在列，《七宗罪》和《驱魔人》在列，《杀人回忆》也在列。人们常说，没有缺点是可怕的。《杀人回忆》树立的标杆如此高，使追随者趋之若鹜，于是照猫画虎，却少有可堪比肩的作品。以下，我们就来看看它的完美体现在何处。

摄影。作为最直观的电影元素，摄影实在太重要了。每一种镜头的运动、色调的选择和景别的权衡都决定这部电影的基调和风格。《杀人回忆》有大量的夜景戏，加上雨夜的设定，摄影师金炯求为其做了两种截然不同的风格。影片开头和结尾两段晴天麦田的高亮和主体的青灰色调形成鲜明对比。显得犯罪过程更加压抑。而开头的高亮象征着仅存的美好，末尾的高亮仿佛在说：“犯罪过去，生活继续，但是别忘了，开头的犯罪之前，也是这样的光景。”

以青灰色为主色调是犯罪片不二的选择，比如戈登.威利斯为《教父》设计的硬光加暗黑色调和戴瑞斯·康吉为《七宗罪》设计的弱光加青灰色调都堪称完美，金炯求为《杀人回忆》设计的细腻的柔光加青灰色调形成了独特的韩国犯罪片摄影风格，在细腻中，形成完美。近年来，除了《黄海》的硬光设计和朴赞郁愈发黑暗诡异的影片，韩国少有后来者越出柔光的圈子。足以见其影响。以青灰色为主色调符合人们对于犯罪现场的想象，片中的雨夜犯罪被这种摄影风格表现的十分贴切，压抑而无助，直至绝望。这正是本片的基调。

表演。作为观众观影欲望的最重要的源动力之一，演员的表演好坏，直接决定着一部电影的成败。身为韩国国宝级的演员，宋康昊大叔在片中饰演一个凭直觉查案的农村警察，出身舞台剧的宋大叔在一系列不同角色的商业片和实验片的磨练后，在《杀人回忆》里的表演十分可信。他那对小眼睛和椭圆形的大脸贴切的表现了一个农村警察的良心和愚昧，坚毅和无助。这个角色在影史上是无法被取代的。而大城市汉城来的年轻警官的质疑和轻蔑，认真与执着，到后来的无助和绝望，最终崩溃的过程也自然可信，金相庆的内心与行为的转变清晰可循，表演同样出彩。

主角之外，配角也是个个精彩。金罗河饰演的农村警察曹探员，为人正直，工作敬业，办案的方式只有一个：打。在办案过程中误伤了腿，需要截肢之前，他打过每一个犯罪嫌疑人。角色的暴力和正直被他诠释的丝丝入扣。类似的例子还有很多。

音乐。一部电影的成败，是配乐和画面的相互依托。配乐在本片中的地位十分重要，在本片不多的配乐中，其中一首歌曲是重要的线索，对剧情起着至关重要的作用。这样的音乐留白与《老无所依》类似。一次夜里的追逐戏，鼓点和凶手在雨夜杀人时的母音一样，像是在告诉观众，或许这个人就是凶手。而当汉城来的年轻警官面对一个曾经帮助过的女学生的死，在大雨中悲痛时，女声吟唱，彷佛在安慰女孩的灵魂。而当从美国传来的DNA分析报告显示他们认定的犯罪嫌疑人不是凶手的时候，却被处理成没有音乐，大雨打在地上，每一声都清楚，加深了绝望的情绪。

剧本。在那些显性的元素背后，《杀人回忆》的剧本无可挑剔。平静的田园生活中出现一具死亡多日的女尸，农村警察朴和曹开始断案。当他们凭自己的愚蠢手段结案时，汉城来的警官提出质疑，果不其然，再次有人遇害，探员们在分歧与碰撞中探寻真相，经历一次次的失望，确定再推翻，最后无果而终。这个改编自真实事件的故事脉络清晰，高潮迭起，松弛有度，是犯罪片的绝佳范本。而本片的导演兼编剧奉俊昊为其做了更为大胆的设定，在政治动荡，社会变迁的年代里，凶手最终逍遥法外。这是我喜欢的元素，时代背景包含着隐喻，这隐喻融入故事中，最终展现给观众。

这部完美的电影只需一个场景便可显示出导演的能力和观点。这里也作为本文的结尾。事发多年后，早已不做警察的朴警官经过当年发现第一具女尸的地点，忍不住前去，一个小女孩告诉他，前几天也有一个男人来到这里看，说是想起从前在这里做过的事，这一刻，大特写的朴警官转身看向观众，眉头颤动。