不得不说这是个浮躁的社会，人人在这个社会都想暴富或者成名。在这些引诱的驱使下很多人都脱离了原来的稳定工作创业。前几天看了《中国合伙人》，故事讲到了几个大学生从校园到工作、再到创办了一个伟大的企业，这个故事更加激励了创业大军的壮大。大家都想创业，那我们技术人员怎么创业？也就个人的经验分享一下：

1、好的想法、产品构思。
2、好的合伙人。三板斧，管理、销售、技术。
3、构建强大执行力的团队。

产品及想法：

什么是好的产品？一个朋友之前问到，这个问题要系统的回答还真有点不好说。看一下比较理论的解释，产品指一个能够满足用户的需求，我们能够使用可行的技术手段实现并且通过销售给用户给公司带来利润。好的产品指具有很好的用户体验，能够满足用户的刚性需求，受众用户市场空间很大，产品具有核心竞争力，具有不可复制性，有收益并且具备很好的产业链和利益平衡点。

我们技术人员设计产品会是什么样子？这点在创业中遇到了很多问题。有一些技术人员拿到一个产品就开始想象自己的产品未来如何的好，将来会赚多少钱，结果研发到最后往往不是这样的。为什么呢？因为技术人员平时自己总是在搞定一个又一个的问题，做完了一个别人提给自己的需求就觉得自己信心暴涨，认为这么简单的产品自己也可以很轻松就做出来了。看看自己搞的程序，这么复杂的工程，多有成就感。可是，自信心爆满的工程师如果不自我总结，研究用户需求、研究产品，只是自己一个人关门造车的话很难开发一个大众都喜欢的产品。

现在我们处于一个信息量大、优秀产品非常多的时代。要在这个时代获得成功必须得迎合用户的需求甚至超出期望才行。技术人员怎么操作呢？

1、做市场调研、多和客户沟通、认真做好需求分析。

这个看似简单，对于技术人员确实难度很大。因为毕竟大家习惯了面对电脑，喜欢了在电脑面前攻克难题，让我们去做这些事情总觉得时间花的不值得。有时候可能会想，我花这个时间去做个计划、去和客户沟通、写个需求文档还不如多学一点技术或者多写一些代码。技术相关的事情才是看得到摸得着的东西。这样就错了！大错特错！

很多创业公司开始没有产品经理，像facebook的ceo扎克伯格。或者只有技术一个人，这个时候公司的创始人就承担了产品经理的角色，如果创始人就把自己的点子抛出来给大家或者稍微分解一下就给到大家。然后大家分别去实现，自己也不管了，忙着开发自己的功能模块。以我们的经验，最后肯定是个四不像的产品。那意思就是不开发产品了吗？看看电影《社交网络》就知道，扎克伯克其实不仅仅是技术很牛，网站搞瘫了整个哈佛的网络，他的商业敏锐度和用户需求也拿捏得很好。在设计第一个长相匹配的网站时他知道整合爱德华的算法。在设计facebook时知道怎么利用其他学校都想和哈佛名牌学校的学生交友、如何通过熟人关系网络邮件营销、添加用户是否单身的标示（最后这个功能大获成功）。

看到这里其实大家会想到，其实facebook的成功并不是因为他本身产品的技术多么牛，而是他把握好了产品用户的心理、选择了合适的营销方式、整合自身独有的资源优势（哈佛）。其实他这个php网站我想现在很多学过web编程的都可以制造出来，有几个能做成facebook呢？

在《中国合伙人》中也有个场景，成东青因为在外面开小班被大学辞退了。最后一堂课时改变了原有的讲课风格，原来上课小心谨慎的照着课本讲，课上的同学都在睡觉（因为那个时候风气比较严谨），因为他在乎这份工作所以特别小心注意。最后一堂课给大家调侃自己的感情经历，已经释然反正都已经被学校辞退了，结果讲课的风格大受同学欢迎。这个就是市场，有时候自己觉得对的不一定是对的，而是要和用户交流，充分尊重用户。他最后把同学当成朋友，也为他后面赢得了新梦想。

这些在技术人员看起来的没有技术含量的脏活、累活反而是一个产品成功的关键。

2、适当的抛开技术，避免影响到产品设计和开发

技术人员设计产品时，总会把系统搞得特别是复杂。因为做技术框架时会想到重用、接口定义时要很灵活。一但这些技术方面的原因占据了产品的主导地位，那这个产品最终会超级复杂。不过有一点，除非你的客户是专有的或者是面向技术型客户。不过面向大部分社会上的产品一般都比较傻瓜化、尽量简化，不让用户思考，一看这个系统就知道怎么使用。

facebook曾经为了诸多技术原因选择了通用平台化的Html5作为技术实现。最终却因为用户的抱怨不得不重新使用ios、andriod开发原有应用。

很多技术在设计系统时，总想把很多新技术带入项目中来，让自己觉得特别牛X。殊不知这样的技术自己能否掌控，如果掌控不了到时候出了问题影响的就是产品的口碑。并且引入新技术，带来了学习成本，如果团队中还有其他成员，未来他们如何学习和开发。

技术人员还有个弊病。觉得自己的技术非常牛，人家不可能超越我的技术（也就是未来我的产品肯定是市场占有率最高的，通俗讲我的产品是最赚钱的）。研发几个月后发现竞争产品推出来了，会觉得他的技术多么弱，不削一顾。再过几个月，发现对方产品已经占据很多客户，并且推出了好几个新产品，还是觉得他的核心竞争力没有，技术能力弱，我的技术毫无压力的压倒他。再过几个月，tnnd，我这么好的产品怎么没有市场呢，赶紧换一个产品。。。。。结果可想而知。就算是自己最开始研发这种类型的产品，结果到后面反而没有赚到钱。这就是盲目的技术自信，而不是商业自信，开公司是要赚钱的，赚钱才能养活公司。

技术人员设计产品时，一定要有市场眼光、简单化功能、适当摈弃技术。刚开始要做到这些可能很难，需要大家强迫自己不往技术方面思考，不过我觉得只要多发现、总结自己的问题，并想到解决方案终会创造一款好的产品。如果大家尝试了无数次，还是技术影响整个产品的设计，推荐几个选择：
a、找到互补的合伙人，弥补你的短板。
b、开发技术类产品。
b、回到公司工作继续做技术。

现在大概总结了产品设计的一些经验，后面再总结下我们怎么把这个想法变成可运行的东西。

原创文章，转载请注明： 转载自LANCEYAN.COM

本文链接地址: 技术人员如何创业《一》—— 产品及想法

每个人日常所做的一切，都应该思考它是否能帮助你提高单位工作时间产出。我自己在思考这件事情的时候，会联想到工作杠杆率这个概念。

第一财经周刊副总编崔鹏先生对工作杠杆（他将之称为「职业杠杆」）的解释是：随着你所做工作的产品或者服务到的人增多，如果你付出的边际劳动量或者边际成本没有降低甚至越来越高，这就说明你的职业杠杆越比较低。反之，如果边际成本下降很快甚至是零，那么就是职业杠杆高。前英特尔CEO安迪·格鲁夫对此也有过阐述：“原则上来说，你每个小时的时间都应该用来增加产量，或是提升你所管理的人的生产价值。“

工作杠杆率低的工种有一个特性：简单、重复性、机械性；比如流水线工人，保洁阿姨；如果我只靠写专栏生活，也会是一种工作杠杆率低的工作：一篇文章一千多块，在国内已经是非常高的标准，但已经四年没怎么涨过，在物价不断上涨的情况下，要过上体面的生活，每年需要写更多的专栏才能维持与上一年相当的生活。

要提高工作杠杆率，LinkedIn创始人Reid Hoffman在《The Stat-Up of you》里提到的「A-B-Z职业规划」法则可以借鉴，借鉴这个原则，可以不断迭代自己的职业优势：

A计划指的是你现在的主业，一般来讲就是你目前的工作，它是你优势集中的领域，无论你是否喜欢，都可以/需要用它来吃饭。它稳定、保险、可预期，可预期意味着它的风险和收益都是可预期的，就像把钱放在银行一样保险，但长远收益小；

B计划指的是长远来看有可能产生巨大回报、但目前并不明朗、有高风险的事情，你如果All-In则非常不明智，但是不投入则会错失个人高成长的机会。面对B计划比较现实的计划是每周投入一些业余时间为之做准备，如果路径出现偏差则不断做修正与调整，一旦路径逐渐清晰，很有可能B计划会成为新的A计划，也就是所谓副业变主业的过程。Reid的第一个公司SocialNet（1997年创建的社交网络） 并不成功，但是在SocialNet的过程中保持对Paypal的关注和投入，当Paypal逐渐明朗的时候加入Paypal并与Elon Musk、Peter Thiel等人一起帮助Paypal取得了巨大的成功。这是Reid自己通过B计划取得成功的案例。

Z计划是用来兜底的，如果面临重大外部变化导致你失业了，Z计划保证你可以有一技之长来养活自己。

更具体一点来讲，对于个人来说，可以遵循这三个基本方法来不断提高自己的工作杠杆率，这些方法是：

• 减少完成某项工作需要的时间，增加一项工作带来的影响
• 外包低杠杆率的工作，时间分配到高杠杆率的工作
• 机械+思考相结合的多线程工作

如果某项工作能够提高自动化程度，那是值得投入去做的。比如开发工具，让重复性的工作自动化，可以显著减少完成某项工作需要的时间。

将家庭保洁工作外包给保洁阿姨，培养新员工或请助理帮助自己分担工作、在学习和技能提升上投资时间、每周3-5小时锻炼，都是将低杠杆率的工作外包给其他人以及自己时间分配到更高工作杠杆率的事情。面对明显浪费时间的事情要坚决说不，比如无效社交和浪费时间的会议、大而无当的各种行业活动等等。写文章也是高杠杆率的工作，一篇文章写完后可以持续地传播给很多人阅读，如果相似的内容需要反复和别人讲的话，也可以写出来，沟通效率可以得到显著提升。

很多事情可以多线程工作。比如在跑步机跑步的同时看一部电影，开车的时候可以听音频——更有效率的方式可能是打车代替开车，这样就可以在车里读书或处理邮件，必要的话甚至还能写点东西。

我在「在行」的工作法就是在将时间花在更有效率的事情上。单位时间收入是读者可感知的效率的提升，而实际上我在「在行」上碰到的人都非常有意思，我约见的每个人身上都能学到很多东西。比如各种有趣的创业项目、每个人自己工作中有趣的事情和困惑、碰到的每个人对我的反馈，是隐形的不可见的、但对我而言都是学习的过程。而学习永远都是最能提高工作杠杆率的事情，时间就应该投入在这里。

还可以有其它算法。假设我想留更多的时间给自己的话，我可以将工作量砍半，然后将剩下的时间用于阅读、陪家人、技能学习、运动或是旅游或者哪怕是发呆打游戏。这意味着，在保证自己过上体面生活的前提下，我还可以实现自己的时间自已自由掌控。毕竟终极的自由并不是财务自由，而是完全掌控自己时间的自由，以及由此带来的精神的独立与自由。

本文首发于「腾讯大家」，「数字弥母」（公众号：digital_meme）

网易将于 13 日正式发布基于 PAAS 的 IM 云服务“云信”。开发者可以通过客户端 SDK 和云端 REST API 让自己的应用快速轻松接入聊天功能。据介绍，网易新闻客户端的跟帖与私信功能采用的就是和“云信”一致的技术平台。

网易表示，云信的背后是网易 POPO 和网易即时通等产品积累的长达 15 年的即时通讯开发经验。产品优势在于可以为开发者提供更成熟的样本经验、更丰富性的模式选择、更稳定的CDN服务（多节点）。

官方资料称，网易拥有“业内最大”的服务集群架构，已成功发送1000亿条消息。经第三方权威测试，每日上亿条消息100%到达。基于POPO的私有精简二进制协议，可以提供更快的速度和更好的性能。

对接入后的开发者，云信将提供7*24小时实时运维监控，技术工程师全天候响应，定期开展免费培训课程和技术沙龙。

网易自己的网易新闻、网易云音乐、网易云课堂、网易花田等APP、以及顺丰快递、传化物流、家校无忧、企业书屋、上海清算所等单位都已经应用了云信的服务。

网易云信

单纯接入第三方支付很容易，只要团队中有开发经验稍微丰富的人，一般最多一周就能完成一家支付公司整体的接入，但如果要考虑与核心业务流程整合、可运营性、架构扩展、安全等问题时候，涉及的东西就很多。

作为一个产品经理，在设计支付产品时候，依赖于你公司及团队发展阶段，对应支付产品的设计策略及方案也不同。

第一阶段：业务发展初期/接入支付平台初期

此阶段的目标是跑通核心的业务流程，验证整体的业务模式，支付业务量较少。

因此对于支付本身的要求不高，在渠道上只需要接入一到两家支付渠道，业务上能够跑通完整支付流程就行。在核心业务系统上，对支付系统业务过多要求。

此时候的接入策略很简单：一般第三方支付都提供了接入的文档及对应语言的Demo程序，直接按照其文档及例子接入联调即可。

除了标准的支付、查询、充值、退款、转账、对账、结算等交易流程外，还需要重点注意如下几点：

1、差错的处理机制，包括掉单后的补单/查询机制、重复支付处理机制、结算对账时候的长短款处理机制等。
2、为清结算人员、运营人员提供完善的工具，降低开发人员介入日常运营的维护成本。
3、一定要有信息安全意识，包括支付相关数据安全、通讯安全、系统安全、网络安全等等。

当然在创业初期，如果团队缺少交易系统构建经验，也可以适当考虑诸如ping++、beecloud这样的厂商，优劣可以参考： 使用第三方支付集成有何风险，例如 Beecloud 或者 Ping++ ? - 梁川的回答

第二阶段：多种支付渠道整合

此阶段，核心业务已经形成一定规模，支付已经成为核心业务流程的一环，支付的成功率、用户体验、费率、安全性等都成为业务核心竞争力。

同时基于成本、风险、运营等角度考虑，一般会同时接入多家支付平台，一方面能够为用户提供多种选择，另外一方面可以在多个渠道间做路由切换（基于成本、流量、营销活动等等）。

此时候的接入策略不再是接入本身，而是：怎样让支付与核心业务系统整合？怎样做多渠道的整合，提高结算、运营的效率，降低运营的成本？

此时候需要从系统架构上做整体规划（实际上应当在第一阶段就做），包括系统的：
1、客户、用户、账户模型
2、支付网关
3、交易系统
4、账务系统
5、清结算系统（多个支付渠道）
6、多支付渠道渠道路由系统
7、风控系统/反欺诈系统（例如网游反欺诈）
8、支付相关的运营系统功能
等等

以上功能貌似包含了一个完整支付平台的相关功能，但作为商家的平台，其侧重点与支付平台并不相同。例如客户、用户、账户系统，对商家平台（例如电商平台）而言一般就是会员系统。

第三阶段：自建支付平台

此阶段，平台除了第三方支付外，还会自己接入一些银行渠道等金融机构资源，另外在业务创新上也会结合支付做一些创新（例如面向平台商户的供应链融资、面向平台用户的授信）。此时候，支付本身已经逐步演变为类第三方支付的支付平台。
此时候面临的问题基本上就是一个支付平台构建的所有问题。

回到题主的问题，由于一直是做客户端开发的，缺少支付及交易系统相关的经验。既然你们公司自己在搭建支付平台，强烈建议让公司做支付架构师、产品经理来参与你们的系统设计，避免走弯路。虽然接入第三方支付貌似很简单，相信你们几天就能完整接入微信支付/支付宝，但如果要考虑到未来系统的扩展性、安全、算清楚账等问题，还是让专业的人来干这事情。

关于平台资金流转的问题，以前的一个类似回答，供参考。美团、饿了么这些平台先收消费者的钱，然后再转账给商户，在财务上是怎么处理的？ - 梁川的回答

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

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

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的大数据田地 » 大数据环境下互联网行业数据仓库/数据平台的架构之漫谈