本文根据高效运维系列微信群「坐而论道」活动整理而成。“高效运维”公众号作为本系列群的官方唯一公众号，原创并独家首发。
欢迎关注“高效运维”公众号，以免费参加「运维讲坛」每月一次的线下交流活动；并抢先赏阅干货满满的各种原创文章（详见文末）。
编辑
- 程成@爱普（整理，编辑）
- 萧田国（修订 & 点评）
主要讨论人员
- 提问： 付海军@时趣
- 回答： 卢东明
引言
「坐而论道」是一个轮流问答的玩法，在回答完提问后，有权向下一位群里朋友提问，以此类推。
8月的第二周是大数据主题周，几位国内一线专家激情问答，期间，各位群友也积极参与，该活动首秀便受到大家的一致好评！
精彩问题
本文涉及的提问包括如下几个：
- 当今内存计算的势头不错，但是大数据与内存计算似乎总有一些矛盾，未来的趋势如何？
- 在企业内部大数据平台建设上卢总提一些架构选型上的建议吧
精彩回复
Q1: 当今内存计算的势头不错，但是大数据与内存计算似乎总有一些矛盾，未来的趋势如何？
内存计算我觉得既新也不新，值得说的代表性公司和产品有两家：
- TimesTen，1996年成立，2005年被Oracle收购。
- SAP HANA，2010年由SAP推出，现在一直在发展。
TimesTen
TimesTen在96年（记得我说的数据库的第一个春天吧？）那个时期，服务器的内存量基本上是几十MB，32-64MB左右吧，想到把数据库完全放到内存里还是蛮有创新的，但是它的局限性（也可能是最终导致它被收购的原因）在于一直是基于传统的行式数据库技术（移到内存而已），针对的场景主要还是OLTP，没有放开眼界，没有真正的突破性思维。
SAP HANA
SAP HANA在2010年横空出世，打了所有人（特别是Oracle）一个措手不及，这是一个基于韩国的一个著名数据库专家车相均的研究结果，主要的突破点在于：
- 放开了内存数据库的容量瓶颈，使用PB级内存，设计把整个数据仓库都放进内存
- 列式数据库技术，引入压缩，从而更好地服务于数据分析领域，进而大数据领域
- 以一体机的方式销售，迅速做成业界标准，使各家硬件公司跟风，快速形成势头
2010年SAP收购Sybase，推出HANA，喊出“三年内成为数据库界第二大公司”的口号，令数据库界为之一震，以SAP的体量，业界影响力，资源的投入，决心，其实没法不害怕的……当然现在大S已经收回成命，市场上的声音也有了转移，就不说了……（你懂的……）
但是，从未来看，我还是非常看好内存数据库的发展方向，和数据流相似，这一技术强调的重点是“实时”，只要大家认可实时的价值会越来越被市场认可，这个内存数据库的方向就会一直走下去。
当然这里面一直有一些技术上的难度，如内存数据的持久化，一致性等等，我感觉最近几年随着SSD，Flash卡等技术的成熟和价格低廉化，也许越来越不是个问题。
相信以后这类数据库也应该在价格上更有竞争力，越来越多地融入大家的大数据整体架构中。
Q2: 在企业内部大数据平台建设上卢总提一些架构选型上的建议吧
我觉得企业的大数据平台应该考虑几层问题：
- 自建还是外租（云计算平台）
- 如果外租，和采购其他商品无异，要看谁家的架构完整，技术实力强劲，服务承诺及口碑好，价格等因素......价格这一块相对简单，基本上云平台公司也会把TCO打包分租出来，额外的成本相对较少。
- 如果自建，问题肯定多很多，技术上的挑战只是一方面，在成本上的挑战只是一方面，在成本上就经常出现计算成本时由于对运行层面的成本预估不足，而产生后期超预算，坚持不下去，而导致整体项目失败的惨痛教训。
自建的问题是：
- 人才……人才永远是最重要的资源，是需要给予足够的重视的，这个重视程度很多时候会落到一个衡量指标上，钱！这个冷酷而又真实地指标。我经常见到口口声声把大数据的重要性说的很高的公司，但是到抢人才的时候才是真正反映出他们对数据的理解和重视程度的。
- 对大数据的理解：从上到下，有没有一个大数据战略。有没有对大数据工作的长期性/持久性和价值认识清楚，对业务的影响有没有足够的接受度和战略眼光。大数据项目很多都是自顶而下的项目，没有高层的政治理念，就只能看平级的一批中层干部各自为政，为地盘和既得利益打得不可开交而让项目无法推进。
- 投入：不光是在资金上的，还有很多决策流程上，关键性人才上的。
最后才是技术架构，这里面当然说起来问题多多，林林总总。
我只想说以下几点：
对自己的业务好好审视，对自己的数据好好审视，对自己的经济能力好好审视
不是所有的互联网公司都是百度、阿里、腾讯，甚至并不是所有的电商都应该复制阿里，所有的社交媒体都应该复制腾讯等等。
一个最经典的例子
大约2009年前后，大家对12306的诟病简直是无以复加，互联网界齐声声讨铁道部。
12306项目组，认为一个阿里巴巴用开源软件Hadoop搭起如此强悍的平台，双十一一天数十亿的交易量都可以撑下来，铁路客票每天1000万张票都卖不出去，为什么死成那个样，一时间各种“专家”，“大V”出谋献策，都指向铁道部的腐败无能，导致花了钱买数据库（其实背后的确是Sybase数据库）还解决不了。
而阿里可以用免费数据库支撑几十倍/几百倍的交易量。阿里也真的派了人去铁科院帮忙“换架构”，一时间志士仁人成立了12306.org，信心满满群策群力利用开源力量开发12306客票系统等等……
等进去了，才知道中国的铁路客票业务的复杂性，以及从数据库的角度，才知道了什么是真正的OLTP！
每次双十一大家都对淘宝、天猫的交易量交口称赞，暗挑大指。但是，正如淘宝是由数十万个小电商组成的，商家之间的商品、客户关联不大或极少关联。淘宝的OLTP，抽象地说是数十万个小OLTP集群起来，很少（几乎没有）店铺X和店铺Y之间串货和交易的情况，而且买东西和收款是分开的交易，甚至极端地说，有多少淘宝商家是真正的实时交易，库存和销售是实时维护的？
多半都是先卖了再说，这才有双十一之后出现大量的长期无货状态，买了也收不到货品。
而铁路客票这样做试一试？不仅不可能卖空票，而且每一张票的分配都有复杂的规则和数据库交易。
例如一个人买了京广线上8/18日某次车从北京-郑州段8车厢5号上铺的票，在客票系统的票库里面，除了产生一张北京-郑州的票之外，还要实时生成一张从郑州到广州的票，而这一个分票的工作在数据库里面是异常复杂的，基本上需要18个相应的数据库交易才能完成。
也就是说假如平均每天卖出1800万张票，不是对应着1800万个交易，而可能是3.24亿个数据库交易，以及随之而来的大量读写操作。
而且更难以想象的是，一张北京-郑州的票，除了要应对多人抢票的场景，还要应对数以亿计的查票的需求，每个在互联网后面的焦急等票的人每一次“再按一次查询键”，都是一个复杂的数据库实时查询工作……
不要试图简单复制“大公司的成功”，阿里的架构后面有数以千计的工程师在维护着不那么完美的开源代码，他们维护完的那个分支说实话你是拿不到的，而你有没有那个实力去重新走一遍每一个弯路，这是大量的资金和人员成本的。
现在的大数据场景很多，每一个场景都很挑战，或者在数据量上，或者在数据延时上，或者在数据分析复杂度上，或者以上都有。几乎可以负责的说，没有一个商业数据库/开源数据库敢声称可以完全/完美地解决你的大数据问题，这也是为什么大家都只说有大数据解决方案，而不说大数据产品（说了请你也不要信）。
最大的难度是要有把多种产品/技术组合起来的能力，这个能力要求其实比很多DBA，数据库专家的水平要高很多，这也是为什么大数据架构不容易做的问题。
坦率地说，在大数据架构方面，我也没有简单的答案给你们，只是提醒大家要兼顾数据整个生命周期的量、态、性，配合业务的需求来考虑各家的产品和理念……以获取高效的整体效果。
基本上OLTP的技术比较成熟，应该不是选择的难点，数据分析领域多花一些功夫考察最适合的，长期发展符合你们的发展战略/愿景的，另外再提一下，请关注数据流的场景及使用，也许3-5年之后这是竞争的焦点。
