以下为分享实景全文：
我将我的时间分为三个Session:
1、 神州泰岳积极参与大数据时代的业务拓展
2、 海量用户通信业务平台的设计实践
3、 对于数据运营的思考
一、神州泰岳近几年在大数据领域做了不少投资和业务布局。归纳起来主要集中在四个层面：
1、入口：“智慧线”
2、基础设施：“IaaS”“DBaaS”“Hadoop”“MPP“ “智能推荐引擎”
3、数据源建设：“用户行为数据”“用户属性数据”“用户社交数据”“系统运行日志”“自然与地理信息数据”
4、行业应用：电信、金融、零售、互联网、旅游、气象
并成立了专业子公司来拓展大数据方面的业务。
应用案例之一，商场人流热度分析：
二、海量用户通信业务平台的设计实践
接下来我分享一下关于海量用户业务平台的设计实践，我的案例不少来自飞信业务。虽然它目前不能算一个特别成功的业务，但由于产品定位的特殊性以及移动用户的巨大数量，所以飞信在系统设计上也比较有特色，有很多有意思的地方，值得玩味。总结起来跟同类系统对比的差异是：
1、需要支持同帐号的多点登陆：这点很要命，由于不同终端的能力不一致性，系统需要增加很多能力协商机制以及多份数据快照，也使得消息的传输逻辑变得异常复杂；
2、需要将短信能力作为消息不可达时的补偿体系：难点在系统如何判定“不可达”，一旦失真，结果就是要不丢消息，要不多次骚扰；
3、是通信系统，不是社交娱乐工具：最本质的区别是消息要即时发送到达用户，用户体验难处理，用户期望值不一样；
4、客服要求高，监管婆婆多：电信系统特色，导致需要投入巨资建设数据实时查询系统，一旦有用户投诉需要立即处理，还有安全系统，对平台的日志要求高；
系统逻辑架构图举例：
我将系统设计中几个重点需要考虑的方面拎出来介绍一下：容量、可靠性与稳定性、数据处理、安全。个人的体会是业务运营到一定程度，雕琢的都是细节的问题了，也是最不好对付的。
1、容量
海量用户平台的设计首先碰到的是系统计算容量是否满足的问题，由于任何单一的系统和设备都不可能满足需求，就算有，成本也会高昂得难以承受。
网络层：由于飞信系统属于电信运营商的业务，所以系统设计上必须符合电信级规范，带来的第一个挑战就是防火墙设备性能不足的问题，需要通过组合来支持千万级同时在线。
主机：为了有效降低成本，采用都是通用架构的PC Server，我们通过优化后实现了单机承载同时在线用户数25万的目标，每秒处理请求：8000/秒
数据与存储：百亿条用户关系链；10亿用户账号；日处理消息百亿级；支持最高50000/秒的登录请求处理；过去在存储环节碰到的问题是磁盘容量够，但心轴数不够，导致存储的I/O能力不足，直到有了SSD硬盘，才缓解了该问题。现在经常碰到的问题是千兆网卡不够用的问题。
在实际运营过程中，还需要处理链路波动导致的潮涌冲击，譬如联通链路中断后，大量用户的自动重连将会带来远远超出系统设计容量的请求，此时就需要启动”优雅降级技术”，通过降低服务等级来集中资源处理登录业务（最大的瓶颈还是在数据库）。
2、可靠性与稳定性
海量用户通信业务平台的可靠性需要适应四个设计前提：
A、任何单一的计算节点都可能发生故障
磁盘：每天运维人员要推着磁盘车更换磁盘；
主机：某台主机宕机能够不影响用户体验（不让用户察觉）
网络：某个网络设备宕机，能够快速切换路由
B、任何研发环境里的测试都不可能是充分的
系统需要具备灰度发布能力:在单元测试、功能测试、性能测试、容量测试后，需要通过灰度发布机制，先将功能发布给部分典型用户试用，以控制故障和大规模投诉风险。
C、必须适应复杂的终端接入网络
由于全国的终端接入方式多种多样，部分组织和企业的IT管控策略差异很大，任何在终端设备上需要安装客户端软件的系统都必须要建立一套通用通讯引擎（更多是运营经验的积累），以穿透复杂网络的种种限制。
D、必须支持频繁变更情况下的系统稳定，用户体验稳定
互联网业务不同于电信业务，“快速迭代”的需求带来的就是频繁系统更新，如何能够不停服务的情况下而能够快速更新，特别是需要把更新分发到成千上万台机器上，需要在架构设计时就要预先考虑。
运维系统举例一：业务运行质量监控
运维系统举例二：60s级故障自动响应系统
3、数据处理：
在我经历的工程实践中，在数据处理这块主要解决的问题有：
A、数据库多的问题
对于一个大型运营业务，需要面临不同的业务单元或者部门需要创建和维护很多数据库，这会带来两个方面的问题：一是部署与管理困难；二是需要耗费很多DBA工程师并散落在各部门。这也是很多大型企业的IT建设中会碰到的问题。
我们的对策是开发了一套“DBOP”数据库托管平台，集中建设数据库平台，任何使用方只需提交申请，描述数据库的规格需求，就可以在1各小时内开通分配。这样就可以把优秀的DBA集中起来维护调优该平台，节省了大量的人力开支。现在已经跑着近300个数据库了。
B、数据库大的问题
对于海量用户平台，单表行数超亿条是非常正常的事，以往的处理都是采用显式分表的方式来缩小库表的尺寸，但这样导致程序员写代码非常不方便。
我们的对策是基于MySql开发了一套“DBPROXY”海量数据库平台，这样业务使用方的程序员彻底不用考虑分表的问题，对于他们来说都是透明的，就正常的写Sql语句就可以。
C、数据库杂的问题
一个大型运营业务中，产生各类数据是非常正常的。有些是结构化的，有些是非结构化的，有些是实时要求高的，有些是可以慢慢处理的。所以在我们的实践中同时维护着DB2,Oracle,SqlServer，MySql，Hadoop体系等各类数据存储和处理解决方案。为了节省开支，目前处于清理和统一的过程中。
数据平台逻辑结构示意图：
4、安全
在海量用户通信系统的设计中，安全方面的考虑消耗了大量的投资。主要包含的方面有：
1、网络安全
这个所有IT系统都会碰到，但量变会导致质变。正常的网络安全设计方法在量大到一定程度时就无法适用了，譬如没有那么大处理能力的IPS/IDS,DDOS黑洞,防火墙。当前很多的安全设备厂商和监管部门的观念还是比较落后，都是面向过程是否合规，而不是面向结果是否符合预期，所以导致事倍功半的局面。有时候为了应付审查，不得不投入巨资来满足规范。
2、业务安全
在系统设计中，个人非常认同一句话“一小撮人坏了大多数人的体验”。为了对付一小撮别有用心的人，需要给系统设置层层保护和障碍，使得正常用户的体验下降。举几个例子：
A、业务滥用
飞信具备免费发短信能力，这就可能被某些人滥用。“卡商养卡”是运营商业务特有的烦恼，你打击了他，他还会去工信部投诉你。
B、防止泄密
其实泄密最重要的就是用户密码问题。为了能够自动登录，必须在客户端保存密钥信息，那么本地存储是否会被盗，传输过程是否会被截获，后台会不会有内鬼这都是需要特别设计防护的。在现在的APP大发展时代，相信一定会有企业从APP安全业务中获得成功。
现在对于海量用户系统的盗号犯罪，已经是集团化的体系在运作，盗号，销售，发诈骗信息各有分工，打击起来非常困难。有些人在境外，有些人在边远地区，譬如儋州，楚雄，贵港等一般治安比较差的地方，警察一般都不愿意去。历史上我们在公安部和北京市公安局的帮助下打击过一批。
C、特殊情况
一个案例：曾经有人利用GAE平台进行编程，利用飞信可以免费发短信的特点，将短信和Twitter平台对接，就是发一条短信到某个飞信账号上，这个账号在GAE平台上接收信息然后发布到Twitter上，绕过了GFW，酿成了“重大安全事件”J,最后只好封杀所有来自GAE平台的访问。
3、内容安全
这个最具中国特色，一般的信息安全教科书上不太细谈。当然，有部分内容安全属于业务滥用范畴，比如当前很火的利用iMessage群发营销消息的生意，就是因为苹果公司没有这方面的运营经验造成的，他们对付不了“聪明”的中国人。
还有一部分就是“敏感词”范畴了，这个领域不多谈了，反正一般的NLP技术是对付不了的，我们是建立了一套“行为识别平台”来提升管控效果。
安全管控系统举例之一：实时行为数据监控分析系统
以上是一些工程实践中的系统设计总结，比较粗略，如果有群友有兴趣，可以找机会细聊。近期在思考一些关于大规模分布式软硬件系统如何更好的协同操作（所谓的电信级标准真的需要吗？）、什么才算好的可扩展计算架构，如何才能提升PUE效率的问题，因为未来的融合通信系统（全IP网络，长在线）将会面临这些问题。
在一个互联网业务运营中，其中很重要的一块是“数据运营”。但一般来讲，当前绝大部分企业或者业务所谓的数据运营还都是BI层面，还没到“大数据”层面，所以经常搞着搞着就觉得也没啥意思，“热闹”大于“实用”，花了很多钱，最后发现对于发展业务也不是那么有效，因为事实上当前很多所谓的数据分析都是基于算法和逻辑推理出来的结论，这些结论的获得从某种意义上来讲不值当花那么多钱，这是当前的一种比较普遍的现象，导致很多投资决策者失去兴趣，非常不利于“大数据”产业的发展。
“养“数据需要耐心和大投入。我们在实际运营中采集沉淀了很多数据，但往往因为缺少某些数据而导致这些数据不能被有效的串在一起，使得价值大打折扣。这时候就需要通过产品设计和运营活动来”养“出这些数据，这个过程比较漫长，也很费钱。
如何”用“好数据，非常考验使用者的智慧和经验，甚至生活阅历。在很多地方，往往存在这样一些思维：我这里有很多数据，看看你们BI工程师能不能挖掘出来点啥。事实证明，这样的效果往往很不好，没有商业需求驱动下的使用数据，在当前还没看到特别的好效果，我们也投入过几个类似项目，分析的结果就是出来一大堆报告，看上去很吸引人，但也没发现啥商业价值。但有些优秀产品人员就能够根据”大数据“的思维提出数据需求和简单的分析模型，譬如“找出某款游戏的潜在用户群”“找出中继节点的最佳部署位置”“勾勒用户社交关系的强弱图谱”等，然后数据部门就帮他准备数据并提供分析结果，来指导产品设计和运营，往往取得较好的成果。所以别指望着数据工程师或分析工程师”用”好数据。J
消除”数据孤岛“靠行政力量不行，唯有靠商业利益。譬如运营商拥有大量的数据，但用户的profile数据、消费记录、位置信息、增值业务行为数据等散落在不同部门，要想让各部门主动的贡献出来这些数据非常困难，所以很多创新业务就开展不起来，之前我们在推动时也颇感吃力。未来如果能够成立专业公司来运营这些数据并获取商业利益，再作价结算给各部门，才有些可能。这个问题同样也会发生在很多组织和企业里。
“服务用户”与“侵犯用户”的边界问题。现在很多产品和业务在采集用户数据方面是非常具备“侵略性”的，以前有些企业还会将采集的数据打乱塞在心跳包里偷偷上传，至少还掩饰一下，现在很多APP以更好的“服务用户“名义窃取用户手机里的信息时肆无忌惮，如果这些信息被滥用，导致用户出现反弹情绪，再引来CCTV的关注，那么就会严重损害产业的发展。如果有一些可信任的权威机构来统一建设一些基础数据库，并公平、规范的开放出来，将会使创新更加容易一些。
原文发布时间为：2014-05-12
本文来自云栖社区合作伙伴“大数据文摘”，了解相关信息可以关注“BigDataDigest”微信公众号
