什么是大数据？
这个问题要回答起来就和O2O一样漫无边际。
或许是因为互联网发展到现在，信息技术已经不仅仅是社会的「外挂」（逍遥子语）那么简单，而是深入到了人类社会和生活的方方面面，要想回答这个问题，涉及的不仅仅只有开发一个工具、或者打造一个平台，背后还有用户需求、产业链、商业模式等等一大堆需要同时解决的麻烦。
不同的人，因为对于技术理解的不同，因为所处环境的不同，对于大数据都会有自身不同维度的解释。譬如对于最初提出大数据4V理论的IBM而言，4V或许就是那个年代定义大数据最合理的解释，但是放到今天的技术环境和理解程度，如果还在说大数据4V，那基本就可以说是落伍了。
放到媒体层面，对于概念的解析就更加碎片化，公说公有理，婆说婆有理，甚至出现真假大数据的辨析。不过相比较O2O，大数据因为需要更多的技术理解能力，所以相对媒体报道的时候都很小心，没太出现睁眼说瞎话的情况。
大数据的模糊性，正如Steve Lohr在New York Times上的文章指出：「大数据这个词现在时常被人们随意使用，然而其语义十分模糊。简单地说，这个包罗万象的词条一般有三层含义：首先，它指代一揽子的技术；其次，它有可能引发一场度量数据规模的革命；最后，它为人们未来将会、甚或是应该如何制定政策提供了一个新视角、一种新理念。」
尽管因为工作需求，我也一直在尝试跟别人解释大数据，但我也不认为这些解释是一成不变的。核心在于，作为一个趋势概念，对于「大数据」本身的理解，是跟着业务需求在生长的，并不存在学术意义上可以被引用被讨论的定义。换句话说，「大数据」这个概念本身，同样在经历小步快跑的修正，每个人都可以也应该从自身业务出发，去归纳总结和吸收他人的解释，来形成最适合自己的定义。
从业务出发形成定义这件事情，说起来容易，做起来难。
特别是自己最近在实际参与数据业务之后，过去这段时间「大数据」自我定义的修正次数，恐怕比过去三年里的总和来得都要多。
所以，一年前听我叨比叨大数据的同学们，今天你再听到我讲大数据的时候，你一定会听到更多不一样的东西。整个修正的过程其实也很有意思，有时间再来形成一篇文章吧。
这里就先推荐一个朋友写的东西，他也是我在大数据这条道路上的引路人。关于什么是数据业务，关于怎么定义云计算背景下不同公司业务的合作，关于如何推动数据业务，文中都有比较精彩的描述。
因为他本身的理论水平也很棒，所以他写出来的东西也非常凝练，我会尝试在每段话之后对文中的一些用词和语句添加我自己的理解。
「数据连接是一切数据业务的上游」
1 把今晚跟哥们一起吃饭碰撞的收获分享出来，是近14个月学习后的收获。数据业务要解的问题是「A用B的数据」，这里A是有业务场景上改善经营的需求。首先A用B的数据，不是A把B的数据拷走，因为数据安全和业务隐私，除非签订严格的不对等契约这一步几乎不可能。我看过好几个奇葩的案例，最终走到最后大家彼此的互信越来越低，数据每加工一次熵增一次。A用B的数据，B要解决数据连接的问题，如何保障数据连接而保障持久的高频调用？这是一个难题。大一统的openID我不看好，B要保护好自己才能服务好A，所以需要「铁皮盒子」机制。身份证这类ID是前大数据时代的事情。还有，切莫指望数据连接称为公共服务，真正的公共服务是在云端协同的物理层。这一点，我也是花了好久才撇清认识。「谁来提供公共品」，并没有「这是不是公共品」重要。数据是生产要素，对A和B而言是纵深的视角，B提供的数据连接服务则是水平视角。数据合作没有上下游关系，只有战略合作关系。而数据连接是一切数据业务的上游。
现在业务上碰到的最大麻烦，是客户对于「数据上云」这件事情疑虑重重——而要实现文中所谓「A用B的数据」业务的前提，是数据能够在一个「云端协同的物理层」上打通。
目前来看，大部分的传统公司，CRM数据在CRM部门，ERP数据在销售部门，营销数据在市场部门，地方数据在各地分公司，而且，各自所使用的系统甚至来自于不同的软件开发商，哪怕是在这些公司内部，要解决这些数据的打通问题，也是需要通过自建数据中心来解决数据打通问题。那么，要想让公司和外部的平台实现数据上的合作，就必须首先实现「数据上云」，所有的数据在一个物理层面上流通，这样才能解决数据的可用性问题。
这也是文中所说，「真正的公共服务是在云端协同的物理层」的真意。
阿里云在这次云栖大会上说：「数据是生产资料」、「计算是公共服务」，可以自行感受一下。
不过，从另一个角度来看，原本的「死数据」通过上云成为可用的「活数据」，这或许就是DT时代的数据红利。
我们可以比照下淘宝的发展历史。
淘宝的发展，很长时间其实就完成了一个转变：零售上网——原本线下的街边店、买手店、经销商、实体店通过上网，把线下的店铺搬到了线上。这个被朋友玉关称为抓住「渠道红利」的发展史，却通过「上网」突破了零售的三重边界：1）场所变场景，地面销售变空中销售，线下实体交易变成线上随时随地的购买，原本小范围的实体销售变成面向全国的销售；2）有限货架变无限货架，碎片化需求不断得到聚集和满足，这也是淘宝成为「万物商店」的基础；3）导购和顾客的一次性交易关系变成卖家和买家的「always online」，经营粉丝比经营店铺更重要。
如果说「零售上网」是电子商务带来的第一波红利，那么「数据上云」就很可能是电子商务带来的第二波红利。移动互联网背景下，人（CRM数据）和货（库存数据）在场景下的连接，从而实现碎片化需求碎片化满足，都要通过机器自动化来完成，这就可能需要打破三层边界：1）企业或平台内部纵向和横向的数据壁垒；2）企业和平台之间的数据壁垒；3）全网全渠道的数据壁垒，小范围来看就是平台和平台之间的数据壁垒。
其中，解决数据连接的「铁皮盒子」是问题关键，这里通常会碰上三个理解误区：
1、大数据是公共服务。
计算才是公共服务，大数据不是。现在市面上所说的各种大数据服务猜想，或者把大数据称为「公共服务」的提法，都把「数据连接」看作了「公共服务」本身。归谬一下，如果全中国只需要一个店铺提供所有货物，大致上就是这种提法的感觉了。但事实上，人们是通过一个个店铺、一个个平台来和特定的货物产生连接，这些店铺和平台某种意义上就构成了连接过程的「铁皮盒子」。
2、A的数据会不会被拷走，B会不会看到A的数据，等等。
这个问题和上一个理解有关，「公共服务」并无法解决私有问题：第一点，「铁皮盒子」机制本质上解决了数据的「可用但不可见」，A的数据对B不可见；第二点，也是最重要的，数据可以连接和交换的前提，是把数据视为一种资产，而资产本身也要先确定产权，任何让数据可见的行为，都是在侵犯他人的数据产权。这点可以参考之前阿里发布的大数据产权声明。
3、数据业务的前提是数据共享。
这就忘了数据是一种资产，不是公共品，任何资产在使用过程中都是要付出代价的，数据也是一样。资产的交换和使用本身存在博弈行为，并不是一种共享过程。如果承认数据共享，那么就是默认「铁皮盒子」机制无用，而这和实际业务相悖。
即使是在一个公司内部，不同部门的数据交换也会存在交易成本，如果不是从这个角度去理解，那么就无法解释，为什么公司内部的数据打通都如此艰难。
场景：理解深度决定应用深度
2 我们祈愿每个有数据的人相连，是由于在解决具体业务过程中对数据的渴求。互联网的成长是用户行为数据的成长。每一个A都渴望在自己的运营场景中走向精细化，不管是拉新维旧，还是优化迭代。B在服务A的过程中，从自己的利益出发必须要走到A的业务场景中去测算B之数据的价值，不然难以定价。无法定价则难以签订契约。B必须搭建一个让数据可用但不透漏用户隐私也不产生数据泄漏的服务。在实践中，数据不管如何量化，只要不进入脱敏的极端情况，都会有安全问题。而业务策略不会，因为B必须要据此来建立计费计量的体系，来响应业务规则因数而变。由此催生了对计算平台的需求。B要服务好A，要满足A在业务场景中的响应需求。我现在对每一个这样的场景，首先问的就是：链路通路是否满足业务需求，相应而言业务规则具体如何切分？其次才是数据质量问题。这是可行与不可行的问题，其次才是便宜和贵的问题。合约定价在产权界定以先，A用B的成本究竟如何？这是服务科学里服务质量研究的内容了。总结下，A用B的数据，需要B在数据相连之上提供数据服务。所谓DP脱离了这个，天方夜谭！
其中描述的具体业务链路，需要的时候自然会懂，这里就不冗述了。这里主要聊聊业务场景。
「B在服务A的过程中，从自己的利益出发必须要走到A的业务场景中去测算B之数据的价值，不然难以定价。」
换句话来说，数据要从商业维度发挥价值，前提是要「满足A在业务场景中的相应需求」——理解业务场景，才能准确地定位问题，「一旦我们可将问题数据化，就能改变人们的意图，并在这些信息基础上产生新价值」。（via The Rise of Big Data，Foreign Affairs，2013 5/6th）
那么，我们又如何来理解业务场景？理解业务场景为何如此重要？
人们面临的现状，是社会整体线上线下的网络结构化，以便于计算机解析。数据化则被定义为一种问题的处理流程，通过数据化，人们把人和生活的方方面面转化成数据，比如好友关系数据、交易数据、金融数据等等。
以供应链举例，生产数据、库存数据、物流数据、销售数据打通，带来的就是淘宝上出现的「多批次、小批量的连续生产补货，保证产品全生命周期内不断货，同时也没有过多库存」（via 游五洋 《关于互联网+传统产业的9个观点》）。其中具体的业务场景，可以参考Gartner的供应链报告。
这其中，每一个业务场景，彼此之间都不是割裂的状态，需要整体地了解和深入考虑每个环节在流程中的作用，从系统的角度来优化局部。这其中做得最好的，就是连续7年蝉联Gartner供应链Top25的苹果。为了提高整体效率，加快价值传导，苹果形成了一套自己的纵向一体化供应体系。
由于苹果对于全流程的熟悉，苹果可以在洞察历史数据和产品数据的基础上，基于用户需求充分地优化整体的系统流程，预测可能存在的瓶颈和问题，并且根据数据的反馈来调整供应策略乃至商业策略。仅仅站在局部优化的角度上看，苹果的很多策略匪夷所思，比如投入人力和资金帮助供应商研发新技术，给供应商买数控机床，甚至直接收购指纹识别公司等等，但是，站在系统的角度，所有这些都保证了到达消费者手中的苹果产品的最终体验，正如iPhone6s的广告词，让苹果产品「唯一的不同是处处不同」。
这个过程中，「链路通路是否满足业务需求」是苹果考量供应链的第一要素，而不是每个局部的优化，也不是「便宜和贵的问题」。
再举一个例子，淘宝直通车。
「由于淘宝对其广告主全部转化流程的了解，使得淘宝直通车在利用后续数据优化广告系统，如转化预估、商品上下架同步等方面，都有着一般搜索广告难以达到的深入程度。」《计算广告》上关于淘宝直通车的这段描述，说明了购买的垂直搜索如何形成自身的闭环。
一方面，因为淘宝直通车自身特性，搜索结果和购买意愿强相关，购买转化高，而且商家可以复用商品图片用于制作推广创意，降低了成本；另一方面，垂直搜索数据、购买转化数据、商品推广成本、消费者数据等等结合，商家可以很方便地去根据数据反馈来判断自身的直通车投放策略是否成功，从而持续地改善和优化整体的投放策略乃至产品的商业策略。
而淘宝直通车系统在这个过程中，依靠积累的大量商家数据（可以视为对商家业务逻辑的深入了解），就可以给商家在「转化预估、商品上下架等方面」给予自动化的优化指导，这就大大降低了商家整体的学习成本和营销成本，经历过那个年代的电商应该都深有体会。
从这个逻辑上，「A用B的数据」前面应该还有一句话——B用A的业务逻辑，从而帮助A快速在B的数据体系里形成运营和产品的闭环，并用数据反馈持续优化商业目标。
「从数据开始，到数据结束。」
标签：「数据业务最精彩的地方」
3 前面两步，A用B的数据有了一个相对可靠的通路，那么如何让通路run起来？这里谈下标签。这个敏感的东西。通常A要探索B的数据是很困难的。去年做数据大连接，面向小伙伴们，感受到标签体系建设是一个庞大的工程。B只是先为A来做标签，数据加工的动作很难交付给A，因此有了「数据可用不可见」。这是一个整体，从资源层，数据开发层到数据服务层，需要系统考虑安全问题。另一个侧面是质量问题。鉴于此，产生的需求是A如何利用B的数据来自己做标签，因为B的服务效率永远会有瓶颈。人工一定要陆续被机器服务所优化，这是生产率提升的效率。A能够用到B的数据，依赖于B走过这么三段路，这条路更多是心路。这条路继续走下去会碰到什么？我也在路上。标签是一个海量、实时、高频的东西。它是数据业务最精彩的地方。就好比宇宙大爆炸，熵增到一个合适的程度，才会诞生如此美丽的地球，和上帝觉得「一切甚好」的人类。
在和某朋友讨论其数据产品的时候，最后我们发现，事实上，今天的数据业务，数据挖掘和算法都不算特别大的问题，特别是基于阿里巴巴的数据和技术能力，只要我们能想到的东西，都有办法去实现。
请分外注意加粗的「能想到」三个字。
另一位朋友，在利用阿里大数据投放钻展（阿里的Display Ads. Platform）的时候，在平日（非活动）ROI投出了1:16的峰值。总结经验的时候，发现是因为他们是做社会化数据抓取出身，通过社会化数据抓取及人群分析，他们能够清晰地认知到某群人的特性，通过抓取其中某些特征（比如爱喝咖啡），并在阿里的数据体系内通过对应的标签（比如：咖啡品牌、器具、咖啡豆等等）抓取人群，他们的钻展ROI不管是峰值还是均值都超过了大部分的商家。
也请分外注意加粗的部分。
总结来看，「A如何利用B的数据来自己做标签」，本质上看的就是A是否具备创造性使用数据的能力。和数据挖掘和算法能力相比，是否具备创造性使用数据的能力，恐怕将成为各大玩家的分水岭。和「能做到」相比，「能想到」是玩转标签非常重要的一步。
还是上述的第一位朋友，对此的总结是：「策略比数据业务本身更重要，而且会越来越重要。」而这种策略必然需要建立在对于数据挖掘和算法等基础知识的掌握之上，并且要对于其自身业务逻辑和所面对的市场有深入的了解，
B解决的是安全和质量问题，以及如何让标签更好地和场景相匹配。这里的场景指的不单纯是上文中的业务场景，包括用户的使用场景和消费场景等等。
B帮助A打通了数据业务的通路，A用B的数据标签圈出针对性的人群，B再帮助A快速在合适的场景下抵达这些人群——通过这样的「标签+场景」，B就能帮助A提升整体的效率，并且降低相应的成本。
这个过程，一句话描述就是「算法代替经验公式」，在数据业务里表达的其实是两个意思：
第一，有经验公式；
第二，能够通过算法把经验转化成可用的标签。
这就是A在使用B的数据过程中需要注意的部分。
从「数据作为生产要素」出发理解数据业务
4 我在说什么？「生产要素-公共品还是私有品-合约定价-产权界定」。9月是个好月份，沾技术大牛们的光，我人生第一次忝居某个专利的作者。这个专利是我在阿里最美的回忆之一。KPI压力很重，过去三天我最担心的事情有了解决之道，拜托诸君。但愿未来的路不再让我局促不安，以致于会有沮丧的时候。我也在努力寻求，会有什么帮助我战胜自己。
这部分的核心就在第一句话上，尽管该位大神已经有过解释，但我解释起来还是有些费力，只能说尽力而为。
事实上，目前对于数据的定义有很多，也不仅仅限于「生产要素」，也有人把数据定义为「生产资料」，这里就主要从「数据作为生产要素」来理解数据业务。
首先，如果我们认为数据是生产要素，那么从经济学上我们就在认定数据和土地、劳动力一样属于稀缺资源。
也许有同学会说，不对呀，大数据大数据，数据量不是应该非常巨大才对吗？同样还是拿土地做比较，整个中国960万平方公里土地，但是耕地只占其中的7%，可用土地面积远远小于我们能看到的数量。在数据业务里也是一样，目前经过处理后可用的数据表单占整体的比例也不太会超过7%，相比较庞大的业务量（人口）而言，这是一个很小的数字。
其次，既然属于稀缺资源，我们就需要像土地一样，先定义出哪些数据业务属于公有服务，哪些属于私有服务。比如说ID Mapping、Cookie Match就属于公有服务，而某些业务则属于私有服务。这和土地类似，如果不去区分公有和私有，不在此之上建立一套制度来区分不同的土地用途，那么，土地的使用就变成了一锅烂粥——每个人都在造房子，却不关心房子和房子之间是否要留下道路，留多宽。最后，虽然房子造起来了，但是因为没有道路，所以谁都没办法住到房子里面去。
只有合理的道路和房子的规划（制度），人们才能享受到房子和道路的不同用途（能力），并且充分发挥土地的价值。
再次，还是拿土地做类比：如果A要使用B的土地，那么，首先就要定义清楚，这块土地的产权属于B，而在这块土地上A所产出的作物，归属于A，但是A要支付一部分给B作为交换使用权的费用——在土地里面这就叫地租。
好的土地因为生产率高，就可以获得超额利润，同时要缴纳更高的地租；中等土地生产率普通，只能获得平均利润，就只需要缴纳普通地租，而低等土地因为生产率落后，获得利润低于平均水平，就无人愿意经营这些土地——这就叫做级差地租。
如果用数据来代替土地，也会发生同样的情形。
A用B的数据，那么就会有第一方、第二方、第三方数据的分别，A用B的第二方数据，就需要承认B对于第二方数据的产权，并且因此缴纳相应的数据使用费（地租）。
数据业务表现越出色，交换价值就越大，A就需要付出更多的数据使用费，来使用B的高性能数据来获取超额利润。但和级差地租类似，这里的红利在于，A在使用B的数据业务过程中，提升的生产率越多，就越能获取超越平均利润的超额利润，最终就会形成「瀑布」效应，市场上的超额利润会越来越聚集到A的手中。
一句话来说就是：「交换带来价值」。
最后，A和B就要签订合约，来具体确定数据使用费的价格，来确保数据供应链的畅通，来为B在数据处理过程中「采集、交换、加工、服务」支付费用。
至此，数据业务就从生产要素出发完成了其最终的「A用B的数据」的过程。
最后的最后
我非常感激文中的这位大神，感谢各位朋友和引路人，也非常感谢我所在的team，感谢阿里妈妈，能够给我这个机会，在第一线实际地触摸和观摩大数据业务这个「teenage sex」。
这恐怕是我写过最硬的文章了。如果你对此文章表示愤慨，我表示严重的理解，但作为一个连高数都没上过的文科生而言，我已经尽了最大努力去解释我所理解的数据业务。因为我对很多算法和技术原理尚不熟悉，对经济学也没有那么精通，所以，在整个描述过程中，肯定存在众多有理解偏差和不准确的地方，如果有疑问的地方，请千万来信来人和我一起探讨。
我的邮箱是anson.77.ho@live.com，请勿询问任何和我现在公司相关的具体业务问题，其他不管是批评还是情感问题我统统接下。
最后，以上内容仅代表本人观点，和所在公司无关。（据说加了这句就不会被请喝咖啡了呢。）
人了解世界的时候，都是先问who & where，慢慢学会问why，当对答案不满足的时候就开始问how，所以，knowhow才是人对世界的回答。谢谢关注Knowhow_Ho，何夕一言堂，这是我对世界的回答，一家之言，不求正确，但求有所启发。
