一 : 网站数据分析的一些问题1
从事数据仓库和数据分析相关的工作也有段时间了，其实很多问题一直萦绕在脑中，有些甚至已经困扰相当长的一段时间，自己也在不断学习和工作的过程中寻找各种解决方案或者不断优化和替换之前的方案。这些问题从宏观层面到细节层面，很多问题其实没有绝对完美的解决方案，我们只能一步一步地摸索，不断寻找更优的方案以其让问题能够更好高效地得到解决，但每个人掌握的知识有限，所以无论怎么样每个人对问题的看法都会存在局限性；同时因为每个人的知识背景和经历的差异性，对各种问题又会触发各种不同的见解，所以通过集思广益往往能够得到让人眼前一亮的结论。
先说说博客，无论怎么样我的博客只是想做些记录和总结，只是表述一些个人的观点，我想每个人在学习工作中总会有所积累，有自己在专业领域的一些收获，每个人公平地享有相同的时间，每个人学到的掌握的都是有限的，没有孰强孰弱之分，差别只在于愿不愿意将其分享出来；博客中整理的内容，可能有些人认为不适合公开，毕竟有些东西还有些实用价值，但必须看到的是目前互联网发展速度太快了，我之前发的文章等半年之后回去看就会发现当时自己的想法并不成熟，如果在现阶段可能不会完全按照上面的思路去实现了，知识的更新和积累让我们不断选择更优的方法，不断改进和升级自身的知识体系，更何况很多东西在一个业务体系下适用，到另外的体系下就不适用了，聪明的人不会完全照搬照抄原方法，而是寻找最合适的方法，或者使用更灵活变通的方式去使用方法，所以也不必担心技能被“偷学”，因为只会模仿的人不知道怎么用好这些方法，而足够聪明的人到哪里都能学到适合自己的方法，在这个信息膨胀的环境下无法阻止他们的“偷学”。
其实博客最大的收获还是通过博客认识了很多朋友，尤其是网站分析领域的，相当一部分也有自己的博客，大家互相交流学到了很多东西，有些东西是互补并相互促进的，这些朋友都是乐意分享自己想法的人，每个人都有各自领域的专业和强项，这样反而使我听到和学到了很多耳目一新的东西，受益匪浅。所以如果你有时间写写博客，那么得到的收获绝对要比你觉得可能会失去的多得多。
既然我在博客里面已经写了很多，所以这里想换一个角色，我想通过几篇文章把之前遇到的诸多问题罗列出来，希望大家能够不吝提出自己的看法和解决方案。其实我更希望在博客的评论中看到更多不同的看法或者通过文章的思路扩展衍生出在其他方向上有价值的应用。另外，知乎真的是一个非常棒的知识分享和学习的平台，潜藏了很多的大牛，我会把整理的每个问题都贴到知乎上面，这样可以收集到更多牛人的看法，希望大家在知乎上有认识相关领域的大牛的可以积极地进行邀请。
这篇是第一篇，想重点罗列一些跟网站数据分析行业和数据分析师相关的问题。
Q1、你因何会选择网站分析或互联网数据分析这个行业，你认为这个行业的价值何在，发展前景如何？（知乎）
我的答案：互联网是一个阳光行业，而数据分析本身又是一个非常有意思的工作，很多时候，它就像是一个侦探从细枝末节的线索中寻找那个唯一的真相，如果你喜欢这种探秘的感觉，那么你同样会喜欢上网站数据分析这个行业。
其实我之前在《网站分析的应用和价值》这篇文章中介绍过网站数据分析的价值，简单地说就是“系统地帮助网站实现更加高效的运营”。
互联网数据量的快速膨胀，急需对数据进行系统化的处理和分析，以便快速地发现信息，转化价值，所以就目前来看，无论是国外的发展趋势，还是国内对这个行业的需求都是快速增长的，发展前景是比较乐观的。
Q2、作为网站的数据分析师，你完成的最有成就感的事情是什么，感到最纠结的事情又是什么？（知乎）
我的答案：最有成就感的事情就是用数据实现价值，无论是通过数据排查问题进而解决问题，还是通过数据分析应用优化网站产品，其实都是创造价值的过程。
最纠结的事情其实不是整日需要维护和验证数据的一致性、准确性，数据时常会存在诸多细节上的问题，因为这些基本是必然存在的，无论在哪个公司，网站从事何种业务，技术或者数据的环境如何，数据的问题还是无所不在，而保证数据质量本身就是数据分析师最基础的工作，也是开展分析的前提和基础。
我最纠结的还是在于数据的需求和应用，如果与数据的需求方在数据的理解上达不成一致，那么很多数据需求就会存在反复的调整变动，期间就会做很多重复的工作或者无用功，甚至有些时候数据分析师大费周章地提取的一份数据在需求方那里只是用几秒钟扫视一遍，没有产生任何的价值，这也是令数据分析师最伤感的事情。所以数据分析始终要从获取最终insight的角度出发，如果数据需求中无法说明获取数据是为了试图得出何种insight，那么这个需求基本就没有实现的必要了。
Q3、作为网站的数据分析师，你日常工作中最常做的是什么，需要与哪些同事交流，一般会用到哪些工具？（知乎）
我的答案：数据分析师的日常工作很简单，就是数据处理和观察报表，而且这两块工作会占用每天的大部分时间。如果每天能够准时提供准确的报表，及时地反馈数据异常，那么你已经是一个合格的数据分析师了。
数据分析师要接触的部门会比较多，可以是任何有数据需求的部门，运营、产品、市场、销售、客服……甚至是各层级的BOSS。
同样，数据分析师日常使用的工具其实也非常简单，估计在90%的时间都在使用数据库的SQL、Excel或者PPT，当然视每个公司的情况会有差异。所以如果你听到某位数据分析师说他天天在研究什么什么样的高级分析方法或者高深的数据算法，天天在使用R、SPSS、SAS，那么不排除有装X的嫌疑。
Q4、在你刚刚步入网站数据分析的工作，或者你曾经新到一个公司或者网站从事数据分析师的工作，你是如何着手开始你的新工作的，你觉得你需要了解哪些东西，会从哪些方面优先开始学习？（知乎）
我的答案：“业务 => 网站或产品 => 数据处理流程 => 指标和报表”，我的基本流程就是这样的，当然这个也不绝对是前后的顺序，可以是同时结合着看的。
数据分析的重点不在于数据而在于分析，分析针对的是业务，所以业务是首要了解的东西，就像一个人做事情，首先要明确的是要做的是什么事情；然后是网站或产品，它是实现业务的媒介，就像是做事情时使用的工作或方法；数据的处理流程包括了数据的获取、处理和存储模型，它是记录信息，可以看做是日记，记录了一个人做事情的整个流程；指标和报表就是为了将一个人做事情的整个流程复述出来，把握重点同时又不失关键细节，所以必须要了解指标的统计规则和报表的展现方式，以便更好地突显重点，了解省略的细节，让复述贴近事实。
很明显，当你了解了这个人在做什么事情之后再去阅读这个人在做事情时记录的信息或听取复述要远比你直接通过复述内容或者阅读记录信息来猜测这个人在做什么事情来得高效得多。
文章来源：网站数据分析
注：相关网站建设技巧阅读请移步到建站教程频道。
二 : 网站数据 每10个网站中就有1个色情网站
过去，从杂志到电视的色情付费频道，美国的成人产业一直以来都相当兴盛。［ www.61k.com ］在网路崛起后，这些电视付费频道就逐渐凋零，就连老牌《花花公子》杂志都不得不开源节流。对美国商人来说，色情是一项有利可图的商品，让我们产业面看看美国网路的成人产业有多兴盛吧!
1、色情网站占全球网站整体数量的12%。平均来说，如果你每天会逛10个网站，可能其中一个就是色情网站。
2、每秒钟有28,258人在观看色情网站，同时每秒也花费3,075.64美金在色情网站上。
3、4千万个美国人有浏览色情网站的习惯，其中每三个人当中有一个是女性;而浏览色情网站的男性中，有70%的年龄是18到24岁。
4、在美国，色情网站每年的收入总值为28.4亿美元，而全球色情网站每年收入总值为49亿美元。
5、美国人每天收到的电子邮件中，有25亿封邮件来自色情网站，占整体邮件的8%。
6、在使用搜寻引擎时，每四次的搜寻中，就有一次是搜寻「情色」相关的关键字，每天共搜寻6,800万次。
7、色情档案占所有网际网路下载量的35%，超过3分之1。
(後面还有：另7个惊人的统计数字)
8、与色情有关的前三名关键字为7500万次的「性(Sex)」、3000万次的「成人约会(Adult Dating)」与230万次的「色情图片(Porn)」。而美国伊利诺州的Elmhurst 是最爱搜寻这些关键字的城市。
9、美国犹他州订阅色情网站的用户比例居全美之冠。
10、34%的美国人经常在使用邮件以及搜寻时，找到毫无相关的色情连结。
11、令人心惊的是，每天仍然有人搜寻「儿童色情」11万6000次。
12、平均来说，现在的小孩从11岁开始看色情网站。
13、有五分之一的美国男性在上班的时候逛色情网站。
14、星期日是美国人逛色情网站的高峰期，感恩节当天则是色情网站一年中的最低潮。
资料、图片来源： Business Insider
三 : 解析网站处理数据交换时的序列化和反序列化
#摘要
序列化和反序列化几乎是工程师们每天都要面对的事情，但是要精确掌握这两个概念并不容易：一方面，它们往往作为框架的一部分出现而湮没在框架之中；另一方面，它们会以其他更容易理解的概念出现，例如加密、持久化。然而，序列化和反序列化的选型却是系统设计或重构一个重要的环节，在分布式、大数据量系统设计里面更为显著。恰当的序列化协议不仅可以提高系统的通用性、强健性、安全性、优化系统性能，而且会让系统更加易于调试、便于扩展。本文从多个角度去分析和讲解“序列化和反序列化”，并对比了当前流行的几种序列化协议，期望对读者做序列化选型有所帮助。
简介
文章作者服务于美团推荐与个性化组，该组致力于为美团用户提供每天billion级别的高质量个性化推荐以及排序服务。从Terabyte级别的用户行为数据，到Gigabyte级别的Deal/Poi数据；从对实时性要求毫秒以内的用户实时地理位置数据，到定期后台job数据，推荐与重排序系统需要多种类型的数据服务。推荐与重排序系统客户包括各种内部服务、美团客户端、美团网站。为了提供高质量的数据服务，为了实现与上下游各系统进行良好的对接，序列化和反序列化的选型往往是我们做系统设计的一个重要考虑因素。
本文内容按如下方式组织：
第一部分给出了序列化和反序列化的定义，以及其在通讯协议中所处的位置。
第二部分从使用者的角度探讨了序列化协议的一些特性。
第三部分描述在具体的实施过程中典型的序列化组件，并与数据库组建进行了类比。
第四部分分别讲解了目前常见的几种序列化协议的特性，应用场景，并对相关组件进行举例。
最后一部分，基于各种协议的特性，以及相关benchmark数据，给出了作者的技术选型建议。
#一、定义以及相关概念
互联网的产生带来了机器间通讯的需求，而互联通讯的双方需要采用约定的协议，序列化和反序列化属于通讯协议的一部分。通讯协议往往采用分层模型，不同模型每层的功能定义以及颗粒度不同，例如：TCP/IP协议是一个四层协议，而OSI模型却是七层协议模型。在OSI七层协议模型中展现层（Presentation Layer）的主要功能是把应用层的对象转换成一段连续的二进制串，或者反过来，把二进制串转换成应用层的对象--这两个功能就是序列化和反序列化。一般而言，TCP/IP协议的应用层对应与OSI七层协议模型的应用层，展示层和会话层，所以序列化协议属于TCP/IP协议应用层的一部分。本文对序列化协议的讲解主要基于OSI七层协议模型。
序列化： 将数据结构或对象转换成二进制串的过程
反序列化：将在序列化过程中所生成的二进制串转换成数据结构或者对象的过程
数据结构、对象与二进制串
不同的计算机语言中，数据结构，对象以及二进制串的表示方式并不相同。
数据结构和对象：对于类似Java这种完全面向对象的语言，工程师所操作的一切都是对象（Object），来自于类的实例化。在Java语言中最接近数据结构的概念，就是POJO（Plain Old Java Object）或者Javabean－－那些只有setter/getter方法的类。而在C++这种半面向对象的语言中，数据结构和struct对应，对象和class对应。
二进制串：序列化所生成的二进制串指的是存储在内存中的一块数据。C++语言具有内存操作符，所以二进制串的概念容易理解，例如，C++语言的字符串可以直接被传输层使用，因为其本质上就是以' '结尾的存储在内存中的二进制串。在Java语言里面，二进制串的概念容易和String混淆。实际上String 是Java的一等公民，是一种特殊对象（Object）。对于跨语言间的通讯，序列化后的数据当然不能是某种语言的特殊数据类型。二进制串在Java里面所指的是byte[]，byte是Java的8中原生数据类型之一（Primitive data types）。
#二、序列化协议特性
每种序列化协议都有优点和缺点，它们在设计之初有自己独特的应用场景。在系统设计的过程中，需要考虑序列化需求的方方面面，综合对比各种序列化协议的特性，最终给出一个折衷的方案。
通用性
通用性有两个层面的意义：
第一、技术层面，序列化协议是否支持跨平台、跨语言。如果不支持，在技术层面上的通用性就大大降低了。
第二、流行程度，序列化和反序列化需要多方参与，很少人使用的协议往往意味着昂贵的学习成本；另一方面，流行度低的协议，往往缺乏稳定而成熟的跨语言、跨平台的公共包。
强健性/鲁棒性
以下两个方面的原因会导致协议不够强健：
第一、成熟度不够，一个协议从制定到实施，到最后成熟往往是一个漫长的阶段。协议的强健性依赖于大量而全面的测试，对于致力于提供高质量服务的系统，采用处于测试阶段的序列化协议会带来很高的风险。
第二、语言/平台的不公平性。为了支持跨语言、跨平台的功能，序列化协议的制定者需要做大量的工作；但是，当所支持的语言或者平台之间存在难以调和的特性的时候，协议制定者需要做一个艰难的决定--支持更多人使用的语言/平台，亦或支持更多的语言/平台而放弃某个特性。当协议的制定者决定为某种语言或平台提供更多支持的时候，对于使用者而言，协议的强健性就被牺牲了。
可调试性/可读性
序列化和反序列化的数据正确性和业务正确性的调试往往需要很长的时间，良好的调试机制会大大提高开发效率。序列化后的二进制串往往不具备人眼可读性，为了验证序列化结果的正确性，写入方不得同时撰写反序列化程序，或提供一个查询平台--这比较费时；另一方面，如果读取方未能成功实现反序列化，这将给问题查找带来了很大的挑战--难以定位是由于自身的反序列化程序的bug所导致还是由于写入方序列化后的错误数据所导致。对于跨公司间的调试，由于以下原因，问题会显得更严重：
第一、支持不到位，跨公司调试在问题出现后可能得不到及时的支持，这大大延长了调试周期。
第二、访问限制，调试阶段的查询平台未必对外公开，这增加了读取方的验证难度。
如果序列化后的数据人眼可读，这将大大提高调试效率， XML和JSON就具有人眼可读的优点。
性能
性能包括两个方面，时间复杂度和空间复杂度：
第一、空间开销（Verbosity）， 序列化需要在原有的数据上加上描述字段，以为反序列化解析之用。如果序列化过程引入的额外开销过高，可能会导致过大的网络，磁盘等各方面的压力。对于海量分布式存储系统，数据量往往以TB为单位，巨大的的额外空间开销意味着高昂的成本。
第二、时间开销（Complexity），复杂的序列化协议会导致较长的解析时间，这可能会使得序列化和反序列化阶段成为整个系统的瓶颈。
可扩展性/兼容性
移动互联时代，业务系统需求的更新周期变得更快，新的需求不断涌现，而老的系统还是需要继续维护。如果序列化协议具有良好的可扩展性，支持自动增加新的业务字段，而不影响老的服务，这将大大提供系统的灵活度。
安全性/访问限制
在序列化选型的过程中，安全性的考虑往往发生在跨局域网访问的场景。当通讯发生在公司之间或者跨机房的时候，出于安全的考虑，对于跨局域网的访问往往被限制为基于HTTP/HTTPS的80和443端口。如果使用的序列化协议没有兼容而成熟的HTTP传输层框架支持，可能会导致以下三种结果之一：
第一、因为访问限制而降低服务可用性。
第二、被迫重新实现安全协议而导致实施成本大大提高。
第三、开放更多的防火墙端口和协议访问，而牺牲安全性。
#三、序列化和反序列化的组件
典型的序列化和反序列化过程往往需要如下组件：
IDL（Interface description language）文件：参与通讯的各方需要对通讯的内容需要做相关的约定（Specifications）。为了建立一个与语言和平台无关的约定，这个约定需要采用与具体开发语言、平台无关的语言来进行描述。这种语言被称为接口描述语言（IDL），采用IDL撰写的协议约定称之为IDL文件。
IDL Compiler：IDL文件中约定的内容为了在各语言和平台可见，需要有一个编译器，将IDL文件转换成各语言对应的动态库。
Stub/Skeleton Lib：负责序列化和反序列化的工作代码。Stub是一段部署在分布式系统客户端的代码，一方面接收应用层的参数，并对其序列化后通过底层协议栈发送到服务端，另一方面接收服务端序列化后的结果数据，反序列化后交给客户端应用层；Skeleton部署在服务端，其功能与Stub相反，从传输层接收序列化参数，反序列化后交给服务端应用层，并将应用层的执行结果序列化后最终传送给客户端Stub。
Client/Server：指的是应用层程序代码，他们面对的是IDL所生存的特定语言的class或struct。
底层协议栈和互联网：序列化之后的数据通过底层的传输层、网络层、链路层以及物理层协议转换成数字信号在互联网中传递。
序列化组件与数据库访问组件的对比
数据库访问对于很多工程师来说相对熟悉，所用到的组件也相对容易理解。下表类比了序列化过程中用到的部分组件和数据库访问组件的对应关系，以便于大家更好的把握序列化相关组件的概念。
#四、几种常见的序列化和反序列化协议
互联网早期的序列化协议主要有COM和CORBA。
COM主要用于Windows平台，并没有真正实现跨平台，另外COM的序列化的原理利用了编译器中虚表，使得其学习成本巨大（想一下这个场景， 工程师需要是简单的序列化协议，但却要先掌握语言编译器）。由于序列化的数据与编译器紧耦合，扩展属性非常麻烦。
CORBA是早期比较好的实现了跨平台，跨语言的序列化协议。COBRA的主要问题是参与方过多带来的版本过多，版本之间兼容性较差，以及使用复杂晦涩。这些政治经济，技术实现以及早期设计不成熟的问题，最终导致COBRA的渐渐消亡。J2SE 1.3之后的版本提供了基于CORBA协议的RMI-IIOP技术，这使得Java开发者可以采用纯粹的Java语言进行CORBA的开发。
这里主要介绍和对比几种当下比较流行的序列化协议，包括XML、JSON、Protobuf、Thrift和Avro。
一个例子
如前所述，序列化和反序列化的出现往往晦涩而隐蔽，与其他概念之间往往相互包容。为了更好了让大家理解序列化和反序列化的相关概念在每种协议里面的具体实现，我们将一个例子穿插在各种序列化协议讲解中。在该例子中，我们希望将一个用户信息在多个系统里面进行传递；在应用层，如果采用Java语言，所面对的类对象如下所示：
Java Code复制内容到剪贴板
XML&SOAP
XML是一种常用的序列化和反序列化协议，具有跨机器，跨语言等优点。 XML历史悠久，其1.0版本早在1998年就形成标准，并被广泛使用至今。XML的最初产生目标是对互联网文档（Document）进行标记，所以它的设计理念中就包含了对于人和机器都具备可读性。 但是，当这种标记文档的设计被用来序列化对象的时候，就显得冗长而复杂（Verbose and Complex）。 XML本质上是一种描述语言，并且具有自我描述（Self-describing）的属性，所以XML自身就被用于XML序列化的IDL。 标准的XML描述格式有两种：DTD（Document Type Definition）和XSD（XML Schema Definition）。作为一种人眼可读（Human-readable）的描述语言，XML被广泛使用在配置文件中，例如O/R mapping、 Spring Bean Configuration File 等。
SOAP（Simple Object Access protocol） 是一种被广泛应用的，基于XML为序列化和反序列化协议的结构化消息传递协议。SOAP在互联网影响如此大，以至于我们给基于SOAP的解决方案一个特定的名称--Web service。SOAP虽然可以支持多种传输层协议，不过SOAP最常见的使用方式还是XML+HTTP。SOAP协议的主要接口描述语言（IDL）是WSDL（Web Service Description Language）。SOAP具有安全、可扩展、跨语言、跨平台并支持多种传输层协议。如果不考虑跨平台和跨语言的需求，XML的在某些语言里面具有非常简单易用的序列化使用方法，无需IDL文件和第三方编译器， 例如Java＋XStream。
自我描述与递归
SOAP是一种采用XML进行序列化和反序列化的协议，它的IDL是WSDL. 而WSDL的描述文件是XSD，而XSD自身是一种XML文件。 这里产生了一种有趣的在数学上称之为“递归”的问题，这种现象往往发生在一些具有自我属性（Self-description）的事物上。
IDL文件举例
采用WSDL描述上述用户基本信息的例子如下：
<xsd:complexType name='Address'>
<xsd:attribute name='city' type='xsd:string' />
<xsd:attribute name='postcode' type='xsd:string' />
<xsd:attribute name='street' type='xsd:string' />
</xsd:complexType>
<xsd:complexType name='UserInfo'>
<xsd:sequence>
<xsd:element name='address' type='tns:Address'/>
<xsd:element name='address1' type='tns:Address'/>
</xsd:sequence>
<xsd:attribute name='userid' type='xsd:int' />
<xsd:attribute name='name' type='xsd:string' />
</xsd:complexType>
由于XML的额外空间开销大，序列化之后的数据量剧增，对于数据量巨大序列持久化应用常景，这意味着巨大的内存和磁盘开销，不太适合XML。另外，XML的序列化和反序列化的空间和时间开销都比较大，对于对性能要求在ms级别的服务，不推荐使用。WSDL虽然具备了描述对象的能力，SOAP的S代表的也是simple，但是SOAP的使用绝对不简单。对于习惯于面向对象编程的用户，WSDL文件不直观。
JSON（Javascript Object Notation）
JSON起源于弱类型语言Javascript， 它的产生来自于一种称之为"Associative array"的概念，其本质是就是采用"Attribute－value"的方式来描述对象。实际上在Javascript和PHP等弱类型语言中，类的描述方式就是Associative array。JSON的如下优点，使得它快速成为最广泛使用的序列化协议之一：
1、这种Associative array格式非常符合工程师对对象的理解。
2、它保持了XML的人眼可读（Human-readable）的优点。
3、相对于XML而言，序列化后的数据更加简洁。 来自于的以下链接的研究表明：XML所产生序列化之后文件的大小接近JSON的两倍。http://www.codeproject.com/Articles/604720/JSON-vs-XML-Some-hard-numbers-about-verbosity
4、它具备Javascript的先天性支持，所以被广泛应用于Web browser的应用常景中，是Ajax的事实标准协议。
5、与XML相比，其协议比较简单，解析速度比较快。
6、松散的Associative array使得其具有良好的可扩展性和兼容性。
IDL悖论
JSON实在是太简单了，或者说太像各种语言里面的类了，所以采用JSON进行序列化不需要IDL。这实在是太神奇了，存在一种天然的序列化协议，自身就实现了跨语言和跨平台。然而事实没有那么神奇，之所以产生这种假象，来自于两个原因：
第一、Associative array在弱类型语言里面就是类的概念，在PHP和Javascript里面Associative array就是其class的实际实现方式，所以在这些弱类型语言里面，JSON得到了非常良好的支持。
第二、IDL的目的是撰写IDL文件，而IDL文件被IDL Compiler编译后能够产生一些代码（Stub/Skeleton），而这些代码是真正负责相应的序列化和反序列化工作的组件。 但是由于Associative array和一般语言里面的class太像了，他们之间形成了一一对应关系，这就使得我们可以采用一套标准的代码进行相应的转化。对于自身支持Associative array的弱类型语言，语言自身就具备操作JSON序列化后的数据的能力；对于Java这强类型语言，可以采用反射的方式统一解决，例如Google提供的Gson。
典型应用场景和非应用场景
JSON在很多应用场景中可以替代XML，更简洁并且解析速度更快。典型应用场景包括：
1、公司之间传输数据量相对小，实时性要求相对低（例如秒级别）的服务。
2、基于Web browser的Ajax请求。
3、由于JSON具有非常强的前后兼容性，对于接口经常发生变化，并对可调式性要求高的场景，例如Mobile app与服务端的通讯。
4、由于JSON的典型应用场景是JSON＋HTTP，适合跨防火墙访问。
总的来说，采用JSON进行序列化的额外空间开销比较大，对于大数据量服务或持久化，这意味着巨大的内存和磁盘开销，这种场景不适合。没有统一可用的IDL降低了对参与方的约束，实际操作中往往只能采用文档方式来进行约定，这可能会给调试带来一些不便，延长开发周期。 由于JSON在一些语言中的序列化和反序列化需要采用反射机制，所以在性能要求为ms级别，不建议使用。
IDL文件举例
以下是UserInfo序列化之后的一个例子：
{"userid":1,"name":"messi","address":[{"city":"北京","postcode":"1000000","street":"wangjingdonglu"}]}
Thrift
Thrift是Facebook开源提供的一个高性能，轻量级RPC服务框架，其产生正是为了满足当前大数据量、分布式、跨语言、跨平台数据通讯的需求。 但是，Thrift并不仅仅是序列化协议，而是一个RPC框架。相对于JSON和XML而言，Thrift在空间开销和解析性能上有了比较大的提升，对于对性能要求比较高的分布式系统，它是一个优秀的RPC解决方案；但是由于Thrift的序列化被嵌入到Thrift框架里面，Thrift框架本身并没有透出序列化和反序列化接口，这导致其很难和其他传输层协议共同使用（例如HTTP）。
典型应用场景和非应用场景
对于需求为高性能，分布式的RPC服务，Thrift是一个优秀的解决方案。它支持众多语言和丰富的数据类型，并对于数据字段的增删具有较强的兼容性。所以非常适用于作为公司内部的面向服务构建（SOA）的标准RPC框架。
不过Thrift的文档相对比较缺乏，目前使用的群众基础相对较少。另外由于其Server是基于自身的Socket服务，所以在跨防火墙访问时，安全是一个顾虑，所以在公司间进行通讯时需要谨慎。 另外Thrift序列化之后的数据是Binary数组，不具有可读性，调试代码时相对困难。最后，由于Thrift的序列化和框架紧耦合，无法支持向持久层直接读写数据，所以不适合做数据持久化序列化协议。
IDL文件举例
struct Address
{
1: required string city;
2: optional string postcode;
3: optional string street;
}
struct UserInfo
{
1: required string userid;
2: required i32 name;
3: optional list<Address> address;
}
Protobuf是一个纯粹的展示层协议，可以和各种传输层协议一起使用；Protobuf的文档也非常完善。 但是由于Protobuf产生于Google，所以目前其仅仅支持Java、C++、Python三种语言。另外Protobuf支持的数据类型相对较少，不支持常量类型。由于其设计的理念是纯粹的展现层协议（Presentation Layer），目前并没有一个专门支持Protobuf的RPC框架。
典型应用场景和非应用场景
Protobuf具有广泛的用户基础，空间开销小以及高解析性能是其亮点，非常适合于公司内部的对性能要求高的RPC调用。由于Protobuf提供了标准的IDL以及对应的编译器，其IDL文件是参与各方的非常强的业务约束，另外，Protobuf与传输层无关，采用HTTP具有良好的跨防火墙的访问属性，所以Protobuf也适用于公司间对性能要求比较高的场景。由于其解析性能高，序列化后数据量相对少，非常适合应用层对象的持久化场景。
它的主要问题在于其所支持的语言相对较少，另外由于没有绑定的标准底层传输层协议，在公司间进行传输层协议的调试工作相对麻烦。
IDL文件举例
message Address
{
required string city=1;
optional string postcode=2;
optional string street=3;
}
message UserInfo
{
required string userid=1;
required string name=2;
repeated Address address=3;
}
Avro
Avro的产生解决了JSON的冗长和没有IDL的问题，Avro属于Apache Hadoop的一个子项目。 Avro提供两种序列化格式：JSON格式或者Binary格式。Binary格式在空间开销和解析性能方面可以和Protobuf媲美，JSON格式方便测试阶段的调试。 Avro支持的数据类型非常丰富，包括C++语言里面的union类型。Avro支持JSON格式的IDL和类似于Thrift和Protobuf的IDL（实验阶段），这两者之间可以互转。Schema可以在传输数据的同时发送，加上JSON的自我描述属性，这使得Avro非常适合动态类型语言。 Avro在做文件持久化的时候，一般会和Schema一起存储，所以Avro序列化文件自身具有自我描述属性，所以非常适合于做Hive、Pig和MapReduce的持久化数据格式。对于不同版本的Schema，在进行RPC调用的时候，服务端和客户端可以在握手阶段对Schema进行互相确认，大大提高了最终的数据解析速度。
典型应用场景和非应用场景
Avro解析性能高并且序列化之后的数据非常简洁，比较适合于高性能的序列化服务。
由于Avro目前非JSON格式的IDL处于实验阶段，而JSON格式的IDL对于习惯于静态类型语言的工程师来说不直观。
IDL文件举例
protocol Userservice {
record Address {
string city;
string postcode;
string street;
}
record UserInfo {
string name;
int userid;
array<Address> address = [];
}
}
JavaScript Code复制内容到剪贴板
#五、Benchmark以及选型建议
##Benchmark
以下数据来自https://code.google.com/p/thrift-protobuf-compare/wiki/Benchmarking
解析性能
序列化之空间开销
从上图可得出如下结论：
1、XML序列化（Xstream）无论在性能和简洁性上比较差。
2、Thrift与Protobuf相比在时空开销方面都有一定的劣势。
3、Protobuf和Avro在两方面表现都非常优越。
选型建议
以上描述的五种序列化和反序列化协议都各自具有相应的特点，适用于不同的场景：
1、对于公司间的系统调用，如果性能要求在100ms以上的服务，基于XML的SOAP协议是一个值得考虑的方案。
2、基于Web browser的Ajax，以及Mobile app与服务端之间的通讯，JSON协议是首选。对于性能要求不太高，或者以动态类型语言为主，或者传输数据载荷很小的的运用场景，JSON也是非常不错的选择。
3、对于调试环境比较恶劣的场景，采用JSON或XML能够极大的提高调试效率，降低系统开发成本。
4、当对性能和简洁性有极高要求的场景，Protobuf，Thrift，Avro之间具有一定的竞争关系。
5、对于T级别的数据的持久化应用场景，Protobuf和Avro是首要选择。如果持久化后的数据存储在Hadoop子项目里，Avro会是更好的选择。
6、由于Avro的设计理念偏向于动态类型语言，对于动态语言为主的应用场景，Avro是更好的选择。
7、对于持久层非Hadoop项目，以静态类型语言为主的应用场景，Protobuf会更符合静态类型语言工程师的开发习惯。
8、如果需要提供一个完整的RPC解决方案，Thrift是一个好的选择。
9、如果序列化之后需要支持不同的传输层协议，或者需要跨防火墙访问的高性能场景，Protobuf可以优先考虑。
61阅读| 精彩专题| 最新文章| 热门文章| 苏ICP备13036349号-1