用户名*
邮箱*
密码*
确认密码*
验证码* 点击图片更换验证码
找回密码
忘记密码了？输入你的注册邮箱，并点击重置，稍后，你将会收到一封密码重置邮件。
RT
我可能还不够资格回答这个问题，没有经历过一个公司大数据平台从无到有到复杂的过程。不过说说看法吧，也算是梳理一下想法找找喷。
这是个需求驱动的过程。
曾经听过spotify的分享，印象很深的是，他们分享说，他们的hadoop集群第一次故障是因为，机器放在靠窗的地方，太阳晒了当机了（笑）。从简单的没有机房放在自家窗前的集群到一直到现在复杂的数据平台，这是一个不断演进的过程。
对小公司来说，大概自己找一两台机器架个集群算算，也算是大数据平台了。在初创阶段，数据量会很小，不需要多大的规模。这时候组件选择也很随意，Hadoop一套，任务调度用脚本或者轻量的框架比如luigi之类的，数据分析可能hive还不如导入RMDB快。监控和部署也许都没时间整理，用脚本或者轻量的监控，大约是没有ganglia、nagios，puppet什么的。这个阶段也许算是技术积累，用传统手段还是真大数据平台都是两可的事情，但是为了今后的扩展性，这时候上Hadoop也许是不错的选择。
当进入高速发展期，也许扩容会跟不上计划，不少公司可能会迁移平台到云上，比如AWS阿里云什么的。小规模高速发展的平台，这种方式应该是经济实惠的，省了运维和管理的成本，扩容比较省心。要解决的是选择平台本身提供的服务，计算成本，打通数据出入的通道。整个数据平台本身如果走这条路，可能就已经基本成型了。走这条路的比较有名的应该是netflix。
也有一个阶段，你发现云服务的费用太高，虽然省了你很多事，但是花钱嗖嗖的。几个老板一合计，再玩下去下个月工资发布出来了。然后无奈之下公司开始往私有集群迁移。这时候你大概需要一群靠谱的运维，帮你监管机器，之前两三台机器登录上去看看状态换个磁盘什么的也许就不可能了，你面对的是成百上千台主机，有些关键服务必须保证稳定，有些是数据节点，磁盘三天两头损耗，网络可能被压得不堪重负。你需要一个靠谱的人设计网络布局，设计运维规范，架设监控，值班团队走起7*24小时随时准备出台。然后上面再有平台组真的大数据平台走起。
然后是选型，如果有技术实力，可以直接用社区的一整套，自己管起来，监控部署什么的自己走起。这个阶段部署监控和用户管理什么的都不可能像两三个节点那样人肉搞了，配置管理，部署管理都需要专门的平台和组件；定期Review用户的作业和使用情况，决定是否扩容，清理数据等等。否则等机器和业务进一步增加，团队可能会死的很惨，疲于奔命，每天事故不断，进入恶性循环。
当然有金钱实力的大户可以找Cloudera，Hortonworks，国内可以找华为星环，会省不少事，适合非互联网土豪。当然互联网公司也有用这些东西的，比如Ebay。
接下去你可能需要一些重量的组件帮你做一些事情。
比如你的数据接入，之前可能找个定时脚本或者爬log发包找个服务器接收写入HDFS，现在可能不行了，这些大概没有高性能，没有异常保障，你需要更强壮的解决方案，比如Flume之类的。
你的业务不断壮大，老板需要看的报表越来越多，需要训练的数据也需要清洗，你就需要任务调度，比如oozie或者azkaban之类的，这些系统帮你管理关键任务的调度和监控。
数据分析人员的数据大概可能渐渐从RDBMS搬迁到集群了，因为传统数据库已经完全hold不住了，但他们不会写代码，所以你上马了Hive。然后很多用户用了Hive觉得太慢，你就又上马交互分析系统，比如Presto，Impala或者SparkSQL。
你的数据科学家需要写ML代码，他们跟你说你需要Mahout或者Spark MLLib，于是你也部署了这些。
至此可能数据平台已经是工程师的日常工作场所了，大多数业务都会迁移过来。这时候你可能面临很多不同的问题。
比如各个业务线数据各种数据表多的一塌糊涂，不管是你还是写数据的人大概都不知道数据从哪儿来，接下去到哪儿去。你就自己搞了一套元数据管理的系统。
你分析性能，发现你们的数据都是上百Column，各种复杂的Query，裸存的Text格式即便压缩了也还是慢的要死，于是你主推用户都使用列存，Parquet，ORC之类的。
又或者你发现你们的ETL很长，中间生成好多临时数据，于是你下狠心把pipeline改写成Spark了。
再接下来也许你会想到花时间去维护一个门户，把这些零散的组件都整合到一起，提供统一的用户体验，比如一键就能把数据从数据库chua一下拉到HDFS导入Hive，也能一键就chua一下再搞回去；点几下就能设定一个定时任务，每天跑了给老板自动推送报表；或者点一下就能起一个Storm的topology；或者界面上写几个Query就能查询Hbase的数据。这时候你的数据平台算是成型了。
当然，磕磕碰碰免不了。每天你都有新的问题和挑战，否则你就要失业了不是？
你发现社区不断在解决你遇到过的问题，于是你们架构师每天分出很多时间去看社区的进展，有了什么新工具，有什么公司发布了什么项目解决了什么问题，兴许你就能用上。
上了这些乱七八糟的东西，你以为就安生了？Hadoop平台的一个大特点就是坑多。尤其是新做的功能新起的项目。对于平台组的人，老板如果知道这是天然坑多的平台，那他也许会很高兴，因为跟进社区，帮忙修bug，一起互动其实是很提升公司影响力的实情。当然如果老板不理解，你就自求多福吧，招几个老司机，出了问题能马上带路才是正道。当然团队的技术积累不能不跟上，因为数据平台还是乱世，三天不跟进你就不知道世界是什么样了。任何一个新技术，都是坑啊坑啊修啊修啊才完善的。如果是关键业务换技术，那需要小心再小心，技术主管也要有足够的积累，能够驾驭，知道收益和风险。
亲身参与，作为主力完成了一个信息大数据分析平台。中间经历了很多问题，算是有些经验，因而作答。
整体而言，大数据平台从平台部署和数据分析过程可分为如下几步：
1、linux系统安装
一般使用开源版的Redhat系统–CentOS作为底层平台。为了提供稳定的硬件基础，在给硬盘做RAID和挂载数据存储节点的时，需要按情况配置。例如，可以选择给HDFS的namenode做RAID2以提高其稳定性，将数据存储与操作系统分别放置在不同硬盘上，以确保操作系统的正常运行。
2、分布式计算平台/组件安装
目前国内外的分布式系统的大多使用的是Hadoop系列开源系统。Hadoop的核心是HDFS，一个分布式的文件系统。在其基础上常用的组件有Yarn、Zookeeper、Hive、Hbase、Sqoop、Impala、ElasticSearch、Spark等。
先说下使用开源组件的优点：1）使用者众多，很多bug可以在网上找的答案（这往往是开发中最耗时的地方）。2）开源组件一般免费，学习和维护相对方便。3）开源组件一般会持续更新，提供必要的更新服务『当然还需要手动做更新操作』。4）因为代码开源，若出bug可自由对源码作修改维护。
再简略讲讲各组件的功能。分布式集群的资源管理器一般用Yarn，『全名是Yet Another Resource Negotiator』。常用的分布式数据数据『仓』库有Hive、Hbase。Hive可以用SQL查询『但效率略低』，Hbase可以快速『近实时』读取行。外部数据库导入导出需要用到Sqoop。Sqoop将数据从Oracle、MySQL等传统数据库导入Hive或Hbase。Zookeeper是提供数据同步服务，Yarn和Hbase需要它的支持。Impala是对hive的一个补充，可以实现高效的SQL查询。ElasticSearch是一个分布式的搜索引擎。针对分析，目前最火的是Spark『此处忽略其他，如基础的MapReduce 和 Flink』。Spark在core上面有ML lib，Spark Streaming、Spark QL和GraphX等库，可以满足几乎所有常见数据分析需求。
值得一提的是，上面提到的组件，如何将其有机结合起来，完成某个任务，不是一个简单的工作，可能会非常耗时。
3、数据导入
前面提到，数据导入的工具是Sqoop。用它可以将数据从文件或者传统数据库导入到分布式平台『一般主要导入到Hive，也可将数据导入到Hbase』。
4、数据分析
数据分析一般包括两个阶段：数据预处理和数据建模分析。
数据预处理是为后面的建模分析做准备，主要工作时从海量数据中提取可用特征，建立大宽表。这个过程可能会用到Hive SQL，Spark QL和Impala。
数据建模分析是针对预处理提取的特征/数据建模，得到想要的结果。如前面所提到的，这一块最好用的是Spark。常用的机器学习算法，如朴素贝叶斯、逻辑回归、决策树、神经网络、TFIDF、协同过滤等，都已经在ML lib里面，调用比较方便。
5、结果可视化及输出API
可视化一般式对结果或部分原始数据做展示。一般有两种情况，行数据展示，和列查找展示。在这里，要基于大数据平台做展示，会需要用到ElasticSearch和Hbase。Hbase提供快速『ms级别』的行查找。 ElasticSearch可以实现列索引，提供快速列查找。
平台搭建主要问题：
1、稳定性 Stability
理论上来说，稳定性是分布式系统最大的优势，因为它可以通过多台机器做数据及程序运行备份以确保系统稳定。但也由于大数据平台部署于多台机器上，配置不合适，也可能成为最大的问题。 曾经遇到的一个问题是Hbase经常挂掉，主要原因是采购的硬盘质量较差。硬盘损坏有时会到导致Hbase同步出现问题，因而导致Hbase服务停止。由于硬盘质量较差，隔三差五会出现服务停止现象，耗费大量时间。结论：大数据平台相对于超算确实廉价，但是配置还是必须高于家用电脑的。
2、可扩展性 Scalability
如何快速扩展已有大数据平台，在其基础上扩充新的机器是云计算等领域应用的关键问题。在实际2B的应用中，有时需要增减机器来满足新的需求。如何在保留原有功能的情况下，快速扩充平台是实际应用中的常见问题。
上述是自己项目实践的总结。整个平台搭建过程耗时耗力，非一两个人可以完成。一个小团队要真正做到这些也需要耗费很长时间。
目前国内和国际上已有多家公司提供大数据平台搭建服务，国外有名的公司有Cloudera，Hortonworks，MapR等，国内也有华为、明略数据、星环等。另外有些公司如明略数据等还提供一体化的解决方案，寻求这些公司合作对 于入门级的大数据企业或没有大数据分析能力的企业来说是最好的解决途径。
对于一些本身体量较小或者目前数据量积累较少的公司，个人认为没有必要搭建这一套系统，暂时先租用AWS和阿里云就够了。对于数据量大，但数据分析需求较简单的公司，可以直接买Tableau，Splunk，HP Vertica，或者IBM DB2等软件或服务即可。
以上是我从事大数据以来的一些认识。管见所及，可能有所疏漏，欢迎补充。
深夜撰文，难免差错，有问题欢迎拍砖。若有用也请点个赞！
谢谢!
首先写一下一个大数据平台是什么，然后再说一下如何搭建。
对于一个大数据平台主要分为三部分
数据接入是将数据写入数据仓储中，也就是数据整合。因为在企业中，数据可能分布在外部和内部，分布在外部的是企业使用第三方系统产生的数据和一些公共数据，分布在企业内部的是企业内部IT系统产生的数据。这些数据一般都是独立分布的，也就是所说的数据孤岛，此时的这些数据是没有什么意义的，因此数据接入就是将这些内外部的数据整合到一起，将这些数据综合起来进行分析。
数据处理是对接入的数据进行数据清洗和ETL建模，将各个数据表之间的关系建立起来，比如关联，聚合，追加等等这些处理。
数据分析是在数据处理后的数据基础上进行维度和数值的可视化分析，也就是基于OLAP的查询和分析，包含上卷，钻取，切片，转轴等操作，最后分析的结果通过报表或是仪表盘来呈现出来，从而支撑业务人员和决策人员。
按照数据处理的顺序可以将大数据平台分为传统型和敏捷型，传统型的是在将数据送入数据仓储里面之前做，存入数据仓储里面的数据已经定义好了事实维度这些模型关系，业务人员可以直接进行查询，但是实时性和灵活性会大打折扣，如果业务人员需要分析一个事先没有的数据的话，需要去跟技术人员反馈，技术人员来完成处理。而敏捷型的则是将数据处理放到了后面，这样业务人员可以根据自己的需要去自助探索式的建模和进行数据分析，但是对系统的性能要求较高。
上面只是从产品层面来进行了说明，下面从技术层面来进行对应。
首先是数据仓储，一般是基于HDFS，采用分布式的文件系统来进行存储。数据处理和数据分析需要基于大数据处理引擎，如果想要实时的查询则需要用Spark这类的基于内存计算的，如果实时性要求没那么高的则可以用基于MR的这些离线计算的引擎。数据分析需要OLAP以及前端可视化这些技术来进行支撑。
知道了是什么样的，接下来我们可以来做了。
通过上面的介绍，我们可以看出需要的技术成本是比较高的，因此对于初创型的公司建议采用第三方的工具来使用。比如国内的BDP(
数据处理-可视化拖拽和SQL
数据可视化-丰富的图表和交互
如果公司有足够的实力，想自建数据平台，可以在现有的一些开源的数据相关的工具来进行搭建，底层存储和计算平台的HDFS，Spark，Hive这些都是Apache开源的，OLAP有Kylin，Saiku这些开源工具，可视化有Airbnb开源的Superset，如果在这些基础上进行搭建和开发，相信能够省去一些开发量，但是事物除了有共性还是有个性的，想要绝对的满足需求是没有的，都是需要企业根据自身的需求来进行定制化开发的。
找到一大堆数据分析师
把他们灌倒or迷晕
获取他们公司数据库权限
把数据荡下来
当你荡的足够多的时候你就能搭建一个数据平台了！
我是认真的！
写爬虫爬？那得爬到猴年马月…
大数据交易？数据那么机密，谁敢跟你交易？现在的大数据平台有几个是活跃的？
云、生态、共享、数据集市……还得再吹两年的牛*吧！
数据交易这种敏感的事情一时半会儿是平台化不起来的，还得先走野路子！
不过数据交易平台前景是不错的，拿过来做融资很有前景！
打个广告：想搞野路子数据交易的请联系我！倒卖数据！联系方式见主页！
1、美团的大数据平台架构实践 – 知乎专栏
2、链家网大数据平台建设，平台枢纽–工具链 – 知乎专栏
扩展一下这个问题，从常规数据平台到大数据平台的选择可参考阅读：怎样选择数据平台的建设方案 – 知乎专栏
关于大数据平台建设
大数据平台的建设过程是由下而上逐步完成的。
首先要有Hadoop集群，在有HDFS与Hive后，才能开展数据接入工作，才能基于集群建设工具链；当工具链部分的OLAP引擎构建好，才有上层BI、报表系统和数据API，只有AdHoc能力构建好，才能提供基于SQL的数据探索平台，工具链中特别需要建设好调度系统，才能在实现好数据ETL任务的同时，管控数据流向与数据关系。最后则是服务层面的建设，重心在于迎合需求的同时，服务做得更加易用，数据管理系统会穿插于整个大数据平台中。所以弄清了每个部分的相互关系也就容易明白大数据平台的建设流程。
最后，关于大数据资讯和案例干货，欢迎关注专栏：帆软数据应用研究院 – 知乎专栏
咳咳，不请自答。
因为参与了以前公司大数据方向产品从0~1的过程，也正在参与现在公司平台化0.5~1的过程，吃了很多亏，踩了很多坑，所以想谈谈自己对这个问题的看法。
在之前公司参与0~1过程的时候，当时团队里没有这方面的专家，我本人也是刚刚从事这个领域，所以基本上是一穷二白一窍不通的。当时单单一个“大数据”及“云计算”两个的相同与不同就给我们造成了很大的困扰：我们到底要做一个什么样的产品？
所以，题主问如何创建一个大数据平台，那么我觉得第一个步骤绝对是做好定位。
而对产品的定义，往往都是需求决定的，所以先问问自己或者领导们，为什么我们要做大数据平台？确定有这个必要么？你们真的需要一个完整的大数据平台，还是只需要一个能够方便进行并行计算的系统？这一步的定位直接影响到后续工作的展开以及各种成本（人力、资金、时间），也关系到开展难度及最终收益。
做技术，尤其是没有太多经验从零开始做的时候，经常会为了做技术而做技术，这实际上是不可取的，我个人也在这点上栽过很多次。所以我的建议是，这一步请千万不要任性。
当对要做的产品有个很好的定位的时候，对一些概念也有了基本的认识，那么这个时候就要开始涉及技术选型啦。我个人的建议是由最贴近用户的那个组件由上往下开始逐一推导选择。加入你们大数据平台的用户是一群直接使用SQL的BI，那么这个时候用户接口那一层技术要么HIVE要么Spark sql，然后结合你们物理设备的状态，成本或者技术倾向性，技术背景等等因素做出选择。
由于现在社区活跃度高，网络上有很多例子可以参考，所以对于初期的架构搭建难度并不会很大，只要找个例子先把几个组件搭建起来就是第一步了。比如选择spark做计算引擎，选择hdfs做分布式文件系统，如果应用需要加个hbase，有了hbase必定会有zookeeper，如果要考虑流式计算和消息总线那么就加个kafka，然后用spark streaming做流式计算引擎等等等等。这一步只要设备到位，应该可以快速实现的。
为什么我会认为这一步应当快速实现？我非常推崇一句话就是“好的架构不是设计出来的而是演化出来的”。当你有了系统主体以后，你的系统首先是一个可运行的系统，这个系统已经可以简单地被用户开始使用了，比如跑跑简单的数据分析等等。然而在使用的过程中必定会发生很多很多事情，比如应用运行过程中性能低，哦，那么我们开始调整系统参数进行优化；比如应用运行过程中经常崩溃，哦，我先排个雷然后加个ganglia把系统监视起来……对于在生产环境中大规模使用的大数据平台这样的系统来说，相信我，不会有一个放之四海皆准的方案，具体怎么实施，一些参数怎么配置，都需要不停地演化。而系统的演化并不是架构师或者老板拍脑袋得到的，应当是由业务驱动的，是由实际出现的问题驱动的，这个过程是需要研发团队全程介入的。
上面的是关于技术的，然而一个大数据平台这样的系统，它的运行成功或失败绝不是仅仅取决于技术，它同样涉及到对人和制度的管理。建立一个平台就是在创造一套规则，发明一个游戏，然后让其他人在你的游戏规则下进行游戏。游戏规则是否科学会直接影响到这个平台执行的好坏。关于这点，可以参考一些成功的公有数据平台的方案，进行简化，本地化，然后拉上线。当然，这套规则也是在不断演化的。
乱七八糟说了一堆，希望能有帮助，对于这方面的问题，欢迎各种花式联系讨论~
以上~
这题目和“如何月入十万”有异曲同工之妙。
场景，预算，团队，商业模式是什么，把这些细节补充完了再请人答题。
电影级别的图形集群实际，有这类创业的朋友吧，核磁共振的数字人体数据是初步
把100G的数字人体数据活动起来就是一切大数据未来，其他只不过是数据挖掘
019.Win7下免Cygwin安装续与NativeBug解决与Dexpot_Hadoop第三季-Win7下免搭建Cygwin视频课程（共2课时）
零基础学习 Hadoop 该如何下手？ – 编程
请问有哪些关于大数据以及hadoop好的学习课程？ – 王门十哲之一的回答
15种最佳方式帮你顺利掌握Hadoop技术
Hadoop 实战 [中文版].pdf
Hadoop生态系统学习路线
概念，算法,应用全部有，迄今为止对大数据研究最透彻的文章……
十八款Hadoop工具帮你驯服大数据
盘点2014：十家最酷的大数据创业公司
l0个Hadoop的应用场景
100个替代昂贵商业软件的开源应用
从零开始搭建Hadoop2.7.1的分布式集群
Hadoop 的搭建.doc
Hadoop工程师成为热门职业
60款与Hadoop和大数据相关的顶级开源工具
Hadoop和大数据：60款顶级大数据开源工具
Hadoop完全分布式搭建
精通HADOOP.pdf
Presto 来自Facebook的开源分布式查询引擎
吕信：PrestoDB在京东的应用实践
转-朝花夕拾之–大数据平台CDH集群离线搭建
转-朝花夕拾之
穷人的持续集成与持续交付（上）
穷人的持续集成与持续交付（下）
Presto | 概览
Hadoop分布式文件系统HDFS的工作原理详述
Tachyon–以内存为核心的开源分布式存储系统
译|5个顶级的图形可视化工具
大数据游戏怎么玩？如何开始大数据创业？
用php做爬虫 百万级别知乎用户数据爬取与分析
运营商如何玩转大数据？ 浙江移动云计算和大数据实践（PPT附下载）
在美国，在R、NoSQL和MapReduce方面需求的专业人才薪水达到了每年约11万5千美元，在中国，大数据人才一将难求，创业公司不容易招大数据技术人才，即使招到，人才方面支出也较高。包括高薪、期权和股票等等；
R/Python/MATLAB（必备）：如果是做数据分析和模型开发，以我的观察来看，使用这三种工具的最多。R生来就是一个统计学家开发的软件，所做的事也自然围绕统计学展开。MATLAB虽然算不上是个专业的数据分析工具，但因为很多人不是专业做数据的，做数据还是为了自己的domain expertise（特别是科学计算、信号处理等），而MATLAB又是个强大无比的Domain expertise工具，所以很多人也就顺带让MATLAB也承担了数据处理的工作，虽然它有时候显得效率不高。Python虽然不是做数据分析的专业软件，但作为一个面向对象的高级动态语言，其开源的生态使Python拥有无比丰富的库，Numpy, Scipy 实现了矩阵运算/科学计算，相当于实现了MATLAB的功能，Pandas又使Python能够像R一样处理dataframe，scikit-learn又实现了机器学习。
SQL（必备）：虽然现在人们都说传统的关系型数据库如Oracle、MySQL越来越无法适应大数据的发展，但对于很多人来说，他们每天都有处理数据的需要，但可能一辈子都没机会接触TB级的数据。不管怎么说，不论是用关系型还是非关系型数据库，SQL语言是必须要掌握的技能，用什么数据库视具体情况而定。
MongoDB（可选）：目前最受欢迎的非关系型数据库NoSQL之一，不少人认为MongoDB完全可以取代mySQL。确实MongoDB方便易用，扩展性强，Web2.0时代的必需品。
Hadoop/Spark/Storm（可选）: MapReduce是当前最著名也是运用最广泛的分布式计算框架，由Google建立。Hadoop/Spark/storm都是基于MapReduce的框架建立起来的分布式计算系统，要说他们之间的区别就是，Hadoop用硬盘存储数据，Spark用内存存储数据，Storm只接受实时数据流而不存储数据。一言以蔽之，如果数据是离线的，如果数据比较复杂且对处理速度要求一般，就Hadoop，如果要速度，就Spark，如果数据是在线的实时的流数据，就Storm。
OpenRefine（可选）：Google开发的一个易于操作的数据清洗工具，可以实现一些基本的清洗功能。
Tableau（可选）：一个可交互的数据可视化工具，操作简单，开箱即用。而且图表都设计得非常漂亮。专业版1999美刀，终身使用。媒体和公关方面用得比较多。
Gephi（可选）：跟Tableau类似，都是那种可交互的可视化工具，不需要编程基础，生成的图表在美学和设计上也是花了心血的。更擅长复杂网络的可视化。
数据科学 怎样进行大数据的入门级学习？
扛住100亿次请求 如何做一个“有把握”的春晚红包系统？（PPT下载）
齐鲁财富网(山东瀚讯信息技术有限公司)是一家致力于“服务大众”的专业财经网站，首要目标是服务山东100万家小微企业、2500万经济从业者和1亿人口，向他们提供最实用、最专业、最权威、最有价值、与百姓息息相关的财经资讯。网站是集传统网站、移动客户端、微信公众平台、微博等多种新兴传播载体于一体的新锐媒体，设有大事、商业、财富、思想、生活、大数据等主要栏目、数十个细分栏目，正逐渐成为政府、企业、百姓之间的信息交流、互动平台，日常经营、管理、消费、生活等经济活动中最依赖、最信赖的专业网站。
大数据高级工程师
北京市 / 全职 / 30K以上 / 3-5年 / 大专
职位描述
1，负责公司大数据平台存储模块的架构设计和开发；
2，解决PB级数据的存储、访问以及数据安全；
3，持续优化巨量数据的存储效率，解决高并发情况下的低延时访问；
4，与数据计算/存储团队合作，开发维护公司大数据平台，并持续优化。
职位要求：
1，熟练掌握Java、Scala、C++、ruby、python中至少一种语言；
2，熟悉Hadoop、Hbase、Hive、spark、storm ，两年以上相关开发经验
3，熟悉大数据周边相关的数据库系统，如mongodb、redis
4，在开源社群活跃并有积极贡献者优先。
5，具有以下相关技能者优先：elasticSearch，drill，netty，kafka，zeppline，zabbix
乐视网招数据分析/开发工程师，薪水15k-40K
招聘办女秘书 2015-10-28 12:13:20 人才招聘 评论(0)
招聘岗位：
数据分析/开发工程师
薪水范围：
15k-40K；
就职地点：北京 朝阳公园 乐视大厦
工作描述：
1.参与数据仓库（DWS层）的搭建，根据BI项目的需求，制定ETL相关的设计方案。
2.负责BI项目汇总层的数据模型的设计。
3.负责数据源的调研，抽取，清洗、转化等etl开发。
4.在hadoop中使用hive及python开发脚本。
5.数据仓库日常运维、流程作业监控、数据质量监控。
6.使用kettle或者存储过程处理临时导数报表需求。
7.熟悉1-2款开源数据可视化产品应用或二次开发（better);
投简历邮箱：caiyingwei@letv.com
京东大数据平台招聘WEB前端架构师/Presto研发工程师
LinkinPark 2015-10-19 5:05:14 人才招聘 评论(0)
大数据
岗位名称：WEB前端架构师
岗位职责：
1.负责京东集团统点击流系统的架构升级及优化，保证系统的稳定运行；
2.负责制定开发及维护标准，保证开发及维护的便捷性；
3.负责相关新技术跟踪及技术选型，保证技术、架构的可扩展及先进性。
任职资格：
1.本科或以上学历，计算机相关专业，需要有较强的学习能力；
2.精通JavaScript/HTML/CSS等Web开发技术，熟悉页面架构和布局；
3.对css/JavaScript性能优化、解决多浏览器兼容性问题有一定的经验；
4.熟悉HTTP1.0/1.1等Web协议，熟悉Web前后端运行流程；
5.熟悉W3C标准，精通DIV+CSS布局，逻辑思维强；
6.熟悉SDK/APP相关开发技术；
7.具备良好的系统分析、架构设计能力；
8.强烈的责任心与主动性，对所负责工作有owner意识，并能自我驱动成长；
9.良好的沟通能力、抗压能力，责任心强；
10.从事过互联网日志采集工作者优先；
11.具备团队管理经验者优先。
请将简历发送至邮箱：bjgaowei@jd.com
———————————–
岗位名称：Presto研发工程师
岗位职责:
1.负责研发京东的Hadoop&Presto集群平台；
2.根据业务需求持续性改进和优化集群系统性能；
3.指导和优化上层业务分布式程序实现。
任职资格:
1.熟悉Presto或Hadoop等一种或几种分布式计算平台，理解实现原理；
2.精通java语言；熟悉shell、python等至少一个脚本语言；
3.有Presto/Mapreduce应用开发经验、熟悉数据挖掘等算法者优先；
4.掌握集群的安装和部署，有集群运维和优化经验者优先；
5.善于分析和解决问题，比较强的学习和创新能力，有责任心。
请将简历发送至邮箱：wangyanming@jd.com
Presto实现原理和美团的使用实践
木叶丸 本文已发表在《程序员》2014.6月刊 · 2014-06-16 10:45
Facebook的数据仓库存储在少量大型Hadoop/HDFS集群。Hive是Facebook在几年前专为Hadoop打造的一款数据仓库工具。在以前，Facebook的科学家和分析师一直依靠Hive来做数据分析。但Hive使用MapReduce作为底层计算框架，是专为批处理设计的。但随着数据越来越多，使用Hive进行一个简单的数据查询可能要花费几分到几小时，显然不能满足交互式查询的需求。Facebook也调研了其他比Hive更快的工具，但它们要么在功能有所限制要么就太简单，以至于无法操作Facebook庞大的数据仓库。
2012年开始试用的一些外部项目都不合适，他们决定自己开发，这就是Presto。2012年秋季开始开发，目前该项目已经在超过 1000名Facebook雇员中使用，运行超过30000个查询，每日数据在1PB级别。Facebook称Presto的性能比Hive要好上10倍多。2013年Facebook正式宣布开源Presto。
本文首先介绍Presto从用户提交SQL到执行的这一个过程，然后尝试对Presto实现实时查询的原理进行分析和总结，最后介绍Presto在美团的使用情况。
Presto架构
presto架构图
Presto查询引擎是一个Master-Slave的架构，由一个Coordinator节点，一个Discovery Server节点，多个Worker节点组成，Discovery Server通常内嵌于Coordinator节点中。Coordinator负责解析SQL语句，生成执行计划，分发执行任务给Worker节点执行。Worker节点负责实际执行查询任务。Worker节点启动后向Discovery Server服务注册，Coordinator从Discovery Server获得可以正常工作的Worker节点。如果配置了Hive Connector，需要配置一个Hive MetaStore服务为Presto提供Hive元信息，Worker节点与HDFS交互读取数据。
Presto执行查询过程简介
既然Presto是一个交互式的查询引擎，我们最关心的就是Presto实现低延时查询的原理，我认为主要是下面几个关键点，当然还有一些传统的SQL优化原理，这里不介绍了。
完全基于内存的并行计算
流水线
本地化计算
动态编译执行计划
小心使用内存和数据结构
类BlinkDB的近似查询
GC控制
为了介绍上述几个要点，这里先介绍一下Presto执行查询的过程
提交查询
用户使用Presto Cli提交一个查询语句后，Cli使用HTTP协议与Coordinator通信，Coordinator收到查询请求后调用SqlParser解析SQL语句得到Statement对象，并将Statement封装成一个QueryStarter对象放入线程池中等待执行。
SQL编译过程
Presto与Hive一样，使用Antlr编写SQL语法，语法规则定义在Statement.g和StatementBuilder.g两个文件中。
如下图中所示从SQL编译为最终的物理执行计划大概分为5部，最终生成在每个Worker节点上运行的LocalExecutionPlan，这里不详细介绍SQL解析为逻辑执行计划的过程，通过一个SQL语句来理解查询计划生成之后的计算过程。
SQL解析过程
样例SQL：
select c1.rank, count(*) from dim.city c1 join dim.city c2 on c1.id = c2.id where c1.id > 10 group by c1.rank limit 10;
逻辑执行计划
上面的SQL语句生成的逻辑执行计划Plan如上图所示。那么Presto是如何对上面的逻辑执行计划进行拆分以较高的并行度去执行完这个计划呢，我们来看看物理执行计划。
物理执行计划
逻辑执行计划图中的虚线就是Presto对逻辑执行计划的切分点，逻辑计划Plan生成的SubPlan分为四个部分，每一个SubPlan都会提交到一个或者多个Worker节点上执行。
SubPlan有几个重要的属性planDistribution、outputPartitioning、partitionBy属性。
PlanDistribution表示一个查询Stage的分发方式，逻辑执行计划图中的4个SubPlan共有3种不同的PlanDistribution方式：Source表示这个SubPlan是数据源，Source类型的任务会按照数据源大小确定分配多少个节点进行执行；Fixed表示这个SubPlan会分配固定的节点数进行执行（Config配置中的query.initial-hash-partitions参数配置，默认是8）；None表示这个SubPlan只分配到一个节点进行执行。在下面的执行计划中，SubPlan1和SubPlan0 PlanDistribution=Source，这两个SubPlan都是提供数据源的节点，SubPlan1所有节点的读取数据都会发向SubPlan0的每一个节点；SubPlan2分配8个节点执行最终的聚合操作；SubPlan3只负责输出最后计算完成的数据。
OutputPartitioning属性只有两个值HASH和NONE，表示这个SubPlan的输出是否按照partitionBy的key值对数据进行Shuffle。在下面的执行计划中只有SubPlan0的OutputPartitioning=HASH，所以SubPlan2接收到的数据是按照rank字段Partition后的数据。
查询的并行执行流程
Presto SQL的执行流程如下图所示
Cli通过HTTP协议提交SQL查询之后，查询请求封装成一个SqlQueryExecution对象交给Coordinator的SqlQueryManager#queryExecutor线程池去执行
每个SqlQueryExecution线程（图中Q-X线程）启动后对查询请求的SQL进行语法解析和优化并最终生成多个Stage的SqlStageExecution任务，每个SqlStageExecution任务仍然交给同样的线程池去执行
每个SqlStageExecution线程（图中S-X线程）启动后每个Stage的任务按PlanDistribution属性构造一个或者多个RemoteTask通过HTTP协议分配给远端的Worker节点执行
Worker节点接收到RemoteTask请求之后，启动一个SqlTaskExecution线程（图中T-X线程）将这个任务的每个Split包装成一个PrioritizedSplitRunner任务（图中SR-X）交给Worker节点的TaskExecutor#executor线程池去执行
查询执行流程
上面的执行计划实际执行效果如下图所示。
Coordinator通过HTTP协议调用Worker节点的 /v1/task 接口将执行计划分配给所有Worker节点（图中蓝色箭头）
SubPlan1的每个节点读取一个Split的数据并过滤后将数据分发给每个SubPlan0节点进行Join操作和Partial Aggr操作
SubPlan1的每个节点计算完成后按GroupBy Key的Hash值将数据分发到不同的SubPlan2节点
所有SubPlan2节点计算完成后将数据分发到SubPlan3节点
SubPlan3节点计算完成后通知Coordinator结束查询，并将数据发送给Coordinator
执行计划计算流程
源数据的并行读取
在上面的执行计划中SubPlan1和SubPlan0都是Source节点，其实它们读取HDFS文件数据的方式就是调用的HDFS InputSplit API，然后每个InputSplit分配一个Worker节点去执行，每个Worker节点分配的InputSplit数目上限是参数可配置的，Config中的query.max-pending-splits-per-node参数配置，默认是100。
分布式的Hash聚合
上面的执行计划在SubPlan0中会进行一次Partial的聚合计算，计算每个Worker节点读取的部分数据的部分聚合结果，然后SubPlan0的输出会按照group by字段的Hash值分配不同的计算节点，最后SubPlan3合并所有结果并输出
数据模型
Presto中处理的最小数据单元是一个Page对象，Page对象的数据结构如下图所示。一个Page对象包含多个Block对象，每个Block对象是一个字节数组，存储一个字段的若干行。多个Block横切的一行是真实的一行数据。一个Page最大1MB，最多16*1024行数据。
节点内部流水线计算
下图是一个Worker节点内部的计算流程图，左侧是任务的执行流程图。
Worker节点将最细粒度的任务封装成一个PrioritizedSplitRunner对象，放入pending split优先级队列中。每个
Worker节点启动一定数目的线程进行计算，线程数task.shard.max-threads=availableProcessors() * 4，在config中配置。
每个空闲的线程从队列中取出一个PrioritizedSplitRunner对象执行，如果执行完成一个周期，超过最大执行时间1秒钟，判断任务是否执行完成，如果完成，从allSplits队列中删除，如果没有，则放回pendingSplits队列中。
每个任务的执行流程如下图右侧，依次遍历所有Operator，尝试从上一个Operator取一个Page对象，如果取得的Page不为空，交给下一个Operator执行。
节点间流水线计算
下图是ExchangeOperator的执行流程图，ExchangeOperator为每一个Split启动一个HttpPageBufferClient对象，主动向上一个Stage的Worker节点拉数据，数据的最小单位也是一个Page对象，取到数据后放入Pages队列中
Presto在选择Source任务计算节点的时候，对于每一个Split，按下面的策略选择一些minCandidates
优先选择与Split同一个Host的Worker节点
如果节点不够优先选择与Split同一个Rack的Worker节点
如果节点还不够随机选择其他Rack的节点
对于所有Candidate节点，选择assignedSplits最少的节点。
Presto会将执行计划中的ScanFilterAndProjectOperator和FilterAndProjectOperator动态编译为Byte Code，并交给JIT去编译为native代码。Presto也使用了Google Guava提供的LoadingCache缓存生成的Byte Code。
上面的两段代码片段中，第一段为没有动态编译前的代码，第二段代码为动态编译生成的Byte Code反编译之后还原的优化代
码，我们看到这里采用了循环展开的优化方法。
循环展开最常用来降低循环开销，为具有多个功能单元的处理器提供指令级并行。也有利于指令流水线的调度。
使用Slice进行内存操作，Slice使用Unsafe#copyMemory实现了高效的内存拷贝，Slice仓库参考：airlift/slice · GitHub
Facebook工程师在另一篇介绍ORCFile优化的文章中也提到使用Slice将ORCFile的写性能提高了20%~30%，参考：
为了加快avg、count distinct、percentile等聚合函数的查询速度，Presto团队与BlinkDB作者之一Sameer Agarwal合作引入了一些近似查询函数approx_avg、approx_distinct、approx_percentile。approx_distinct使用HyperLogLog Counting算法实现。
Presto团队在使用hotspot java7时发现了一个JIT的BUG，当代码缓存快要达到上限时，JIT可能会停止工作，从而无法将使用频率高的代码动态编译为native代码。
Presto团队使用了一个比较Hack的方法去解决这个问题，增加一个线程在代码缓存达到70%以上时进行显式GC，使得已经加载的Class从perm中移除，避免JIT无法正常工作的BUG。
Presto TPCH benchmark测试
介绍了上述这么多点，我们最关心的还是Presto性能测试，Presto中实现了TPCH的标准测试，下面的表格给出了Presto 0.60 TPCH的测试结果。直接运行presto-main/src/test/java/com/facebook/presto/benchmark/BenchmarkSuite.java。
benchmarkName cpuNanos(MILLISECONDS) inputRows inputBytes inputRows/s inputBytes/s outputRows outputBytes outputRows/s outputBytes/s
count_agg 2.055ms 1.5M 12.9MB 730M/s 6.12GB/s 1 9B 486/s 4.28KB/s
double_sum_agg 14.792ms 1.5M 12.9MB 101M/s 870MB/s 1 9B 67/s 608B/s
hash_agg 174.576ms 1.5M 21.5MB 8.59M/s 123MB/s 3 45B 17/s 257B/s
predicate_filter 68.387ms 1.5M 12.9MB 21.9M/s 188MB/s 1.29M 11.1MB 18.8M/s 162MB/s
raw_stream 1.899ms 1.5M 12.9MB 790M/s 6.62GB/s 1.5M 12.9MB 790M/s 6.62GB/s
top100 58.735ms 1.5M 12.9MB 25.5M/s 219MB/s 100 900B 1.7K/s 15KB/s
in_memory_orderby_1.5M 1909.524ms 1.5M 41.5MB 786K/s 21.7MB/s 1.5M 28.6MB 786K/s 15MB/s
hash_build 588.471ms 1.5M 25.7MB 2.55M/s 43.8MB/s 1.5M 25.7MB 2.55M/s 43.8MB/s
hash_join 2400.006ms 6M 103MB 2.5M/s 42.9MB/s 6M 206MB 2.5M/s 85.8MB/s
hash_build_and_join 2996.489ms 7.5M 129MB 2.5M/s 43MB/s 6M 206MB 2M/s 68.8MB/s
hand_tpch_query_1 3146.931ms 6M 361MB 1.91M/s 115MB/s 4 300B 1/s 95B/s
hand_tpch_query_6 345.960ms 6M 240MB 17.3M/s 695MB/s 1 9B 2/s 26B/s
sql_groupby_agg_with_arithmetic 1211.444ms 6M 137MB 4.95M/s 113MB/s 2 30B 1/s 24B/s
sql_count_agg 3.635ms 1.5M 12.9MB 413M/s 3.46GB/s 1 9B 275/s 2.42KB/s
sql_double_sum_agg 16.960ms 1.5M 12.9MB 88.4M/s 759MB/s 1 9B 58/s 530B/s
sql_count_with_filter 81.641ms 1.5M 8.58MB 18.4M/s 105MB/s 1 9B 12/s 110B/s
sql_groupby_agg 169.748ms 1.5M 21.5MB 8.84M/s 126MB/s 3 45B 17/s 265B/s
sql_predicate_filter 46.540ms 1.5M 12.9MB 32.2M/s 277MB/s 1.29M 11.1MB 27.7M/s 238MB/s
sql_raw_stream 3.374ms 1.5M 12.9MB 445M/s 3.73GB/s 1.5M 12.9MB 445M/s 3.73GB/s
sql_top_100 60.663ms 1.5M 12.9MB 24.7M/s 212MB/s 100 900B 1.65K/s 14.5KB/s
sql_hash_join 4421.159ms 7.5M 129MB 1.7M/s 29.1MB/s 6M 206MB 1.36M/s 46.6MB/s
sql_join_with_predicate 1008.909ms 7.5M 116MB 7.43M/s 115MB/s 1 9B 0/s 8B/s
sql_varbinary_max 224.510ms 6M 97.3MB 26.7M/s 433MB/s 1 21B 4/s 93B/s
sql_distinct_multi 257.958ms 1.5M 32MB 5.81M/s 124MB/s 5 112B 19/s 434B/s
sql_distinct_single 112.849ms 1.5M 12.9MB 13.3M/s 114MB/s 1 9B 8/s 79B/s
sql_tpch_query_1 3168.782ms 6M 361MB 1.89M/s 114MB/s 4 336B 1/s 106B/s
sql_tpch_query_6 286.281ms 6M 240MB 21M/s 840MB/s 1 9B 3/s 31B/s
sql_like 3497.154ms 6M 232MB 1.72M/s 66.3MB/s 1.15M 9.84MB 328K/s 2.81MB/s
sql_in 80.267ms 6M 51.5MB 74.8M/s 642MB/s 25 225B 311/s 2.74KB/s
sql_semijoin_in 1945.074ms 7.5M 64.4MB 3.86M/s 33.1MB/s 3M 25.8MB 1.54M/s 13.2MB/s
sql_regexp_like 2233.004ms 1.5M 76.6MB 672K/s 34.3MB/s 1 9B 0/s 4B/s
sql_approx_percentile_long 587.748ms 1.5M 12.9MB 2.55M/s 21.9MB/s 1 9B 1/s 15B/s
sql_between_long 53.433ms 1.5M 12.9MB 28.1M/s 241MB/s 1 9B 18/s 168B/s
sampled_sql_groupby_agg_with_arithmetic 1369.485ms 6M 189MB 4.38M/s 138MB/s 2 30B 1/s 21B/s
sampled_sql_count_agg 11.367ms 1.5M 12.9MB 132M/s 1.11GB/s 1 9B 87/s 791B/s
sampled_sql_join_with_predicate 1338.238ms 7.5M 180MB 5.61M/s 135MB/s 1 9B 0/s 6B/s
sampled_sql_double_sum_agg 24.638ms 1.5M 25.7MB 60.9M/s 1.02GB/s 1 9B 40/s 365B/s
stat_long_variance 26.390ms 1.5M 12.9MB 56.8M/s 488MB/s 1 9B 37/s 341B/s
stat_long_variance_pop 26.583ms 1.5M 12.9MB 56.4M/s 484MB/s 1 9B 37/s 338B/s
stat_double_variance 26.601ms 1.5M 12.9MB 56.4M/s 484MB/s 1 9B 37/s 338B/s
stat_double_variance_pop 26.371ms 1.5M 12.9MB 56.9M/s 488MB/s 1 9B 37/s 341B/s
stat_long_stddev 26.266ms 1.5M 12.9MB 57.1M/s 490MB/s 1 9B 38/s 342B/s
stat_long_stddev_pop 26.350ms 1.5M 12.9MB 56.9M/s 489MB/s 1 9B 37/s 341B/s
stat_double_stddev 26.316ms 1.5M 12.9MB 57M/s 489MB/s 1 9B 38/s 342B/s
stat_double_stddev_pop 26.360ms 1.5M 12.9MB 56.9M/s 488MB/s 1 9B 37/s 341B/s
sql_approx_count_distinct_long 35.763ms 1.5M 12.9MB 41.9M/s 360MB/s 1 9B 27/s 251B/s
sql_approx_count_distinct_double 37.198ms 1.5M 12.9MB 40.3M/s 346MB/s 1 9B 26/s 241B/s
美团如何使用Presto
选择presto的原因
2013年我们也用过一段时间的impala，当时impala不支持线上1.x的hadoop社区版，所以搭了一个CDH的小集群，每天将大集群的热点数据导入小集群。但是hadoop集群年前完成升级2.2之后，当时的impala还不支持2.2 hadoop版本。而Presto刚好开始支持2.x hadoop社区版，并且Presto在Facebook 300PB大数据量的环境下可以成功的得到大量使用，我们相信它在美团也可以很好的支撑我们实时分析的需求，于是决定先上线测试使用一段时间。
部署和使用形式
考虑到两个原因：1、由于Hadoop集群主要是夜间完成昨天的计算任务，白天除了日志写入外，集群的计算负载较低。2、Presto Worker节点与DataNode节点布置在一台机器上可以本地计算。因此我们将Presto部署到了所有的DataNode机器上，并且夜间停止Presto服务，避免占用集群资源，夜间基本也不会有用户查询数据。
Presto二次开发和BUG修复
年后才正式上线Presto查询引擎，0.60版本，使用的时间不长，但是也遇到了一些问题：
美团的Hadoop使用的是2.2版本，并且开启了Security模式，但是Presto不支持Kerberos认证，我们修改了Presto代码，增加了Kerberos认证的功能。
Presto还不支持SQL的隐式类型转换，而Hive支持，很多自助查询的用户习惯了Hive，导致使用Presto时都会出现表达式中左右变量类型不匹配的问题，我们增加了隐式类型转换的功能，大大减小了用户SQL出错的概率。
Presto不支持查询lzo压缩的数据，需要修改hadoop-lzo的代码。
解决了一个having子句中有distinct字段时查询失败的BUG，并反馈了Presto团队 sql may fail with distinct columns in having statement by chenchun · Pull Request #1104 · facebook/presto · GitHub
所有代码的修改可以参考我们在github上的仓库 Commits · MTDATA/presto · GitHub
实际使用效果
这里给出一个公司内部开放给分析师、PM、工程师进行自助查询的查询中心的一个测试报告。这里选取了平时的5000个Hive查询，通过Presto查询的对比见下面的表格。
自助查询sql数
hive
presto
presto/hive
1424 154427s 27708s 0.179424582489
参考
Presto官方文档 Presto | Distributed SQL Query Engine for Big Data
Facebook Presto团队介绍Presto的文章
SlideShare两个分享Presto 的PPT
Presto overview
Hadoop Source Code Reading #15 in Japan
大数据平台？
大数据是因为业务需要才收集存储很多数据的，不是为了大数据而大数据
举个实际的例子：有个生产过程监控系统，为每个产品记录加工过程（谁、何时进行了什么工序，下载了哪些系统和应用文件）、测试结果（每个功能、部件的每种测试项）
然后就可以随时统计、分析、预警。。。了
具体环境：SQL2005+64G的机器，5年接近20亿条记录了（数据文件还没到1T）。。。。
目前正在做。占坑，有空答。
昵称*
E-Mail*
回复内容*
回复 ( 10 )
我可能还不够资格回答这个问题，没有经历过一个公司大数据平台从无到有到复杂的过程。不过说说看法吧，也算是梳理一下想法找找喷。
这是个需求驱动的过程。
曾经听过spotify的分享，印象很深的是，他们分享说，他们的hadoop集群第一次故障是因为，机器放在靠窗的地方，太阳晒了当机了（笑）。从简单的没有机房放在自家窗前的集群到一直到现在复杂的数据平台，这是一个不断演进的过程。
对小公司来说，大概自己找一两台机器架个集群算算，也算是大数据平台了。在初创阶段，数据量会很小，不需要多大的规模。这时候组件选择也很随意，Hadoop一套，任务调度用脚本或者轻量的框架比如luigi之类的，数据分析可能hive还不如导入RMDB快。监控和部署也许都没时间整理，用脚本或者轻量的监控，大约是没有ganglia、nagios，puppet什么的。这个阶段也许算是技术积累，用传统手段还是真大数据平台都是两可的事情，但是为了今后的扩展性，这时候上Hadoop也许是不错的选择。
当进入高速发展期，也许扩容会跟不上计划，不少公司可能会迁移平台到云上，比如AWS阿里云什么的。小规模高速发展的平台，这种方式应该是经济实惠的，省了运维和管理的成本，扩容比较省心。要解决的是选择平台本身提供的服务，计算成本，打通数据出入的通道。整个数据平台本身如果走这条路，可能就已经基本成型了。走这条路的比较有名的应该是netflix。
也有一个阶段，你发现云服务的费用太高，虽然省了你很多事，但是花钱嗖嗖的。几个老板一合计，再玩下去下个月工资发布出来了。然后无奈之下公司开始往私有集群迁移。这时候你大概需要一群靠谱的运维，帮你监管机器，之前两三台机器登录上去看看状态换个磁盘什么的也许就不可能了，你面对的是成百上千台主机，有些关键服务必须保证稳定，有些是数据节点，磁盘三天两头损耗，网络可能被压得不堪重负。你需要一个靠谱的人设计网络布局，设计运维规范，架设监控，值班团队走起7*24小时随时准备出台。然后上面再有平台组真的大数据平台走起。
然后是选型，如果有技术实力，可以直接用社区的一整套，自己管起来，监控部署什么的自己走起。这个阶段部署监控和用户管理什么的都不可能像两三个节点那样人肉搞了，配置管理，部署管理都需要专门的平台和组件；定期Review用户的作业和使用情况，决定是否扩容，清理数据等等。否则等机器和业务进一步增加，团队可能会死的很惨，疲于奔命，每天事故不断，进入恶性循环。
当然有金钱实力的大户可以找Cloudera，Hortonworks，国内可以找华为星环，会省不少事，适合非互联网土豪。当然互联网公司也有用这些东西的，比如Ebay。
接下去你可能需要一些重量的组件帮你做一些事情。
比如你的数据接入，之前可能找个定时脚本或者爬log发包找个服务器接收写入HDFS，现在可能不行了，这些大概没有高性能，没有异常保障，你需要更强壮的解决方案，比如Flume之类的。
你的业务不断壮大，老板需要看的报表越来越多，需要训练的数据也需要清洗，你就需要任务调度，比如oozie或者azkaban之类的，这些系统帮你管理关键任务的调度和监控。
数据分析人员的数据大概可能渐渐从RDBMS搬迁到集群了，因为传统数据库已经完全hold不住了，但他们不会写代码，所以你上马了Hive。然后很多用户用了Hive觉得太慢，你就又上马交互分析系统，比如Presto，Impala或者SparkSQL。
你的数据科学家需要写ML代码，他们跟你说你需要Mahout或者Spark MLLib，于是你也部署了这些。
至此可能数据平台已经是工程师的日常工作场所了，大多数业务都会迁移过来。这时候你可能面临很多不同的问题。
比如各个业务线数据各种数据表多的一塌糊涂，不管是你还是写数据的人大概都不知道数据从哪儿来，接下去到哪儿去。你就自己搞了一套元数据管理的系统。
你分析性能，发现你们的数据都是上百Column，各种复杂的Query，裸存的Text格式即便压缩了也还是慢的要死，于是你主推用户都使用列存，Parquet，ORC之类的。
又或者你发现你们的ETL很长，中间生成好多临时数据，于是你下狠心把pipeline改写成Spark了。
再接下来也许你会想到花时间去维护一个门户，把这些零散的组件都整合到一起，提供统一的用户体验，比如一键就能把数据从数据库chua一下拉到HDFS导入Hive，也能一键就chua一下再搞回去；点几下就能设定一个定时任务，每天跑了给老板自动推送报表；或者点一下就能起一个Storm的topology；或者界面上写几个Query就能查询Hbase的数据。这时候你的数据平台算是成型了。
当然，磕磕碰碰免不了。每天你都有新的问题和挑战，否则你就要失业了不是？
你发现社区不断在解决你遇到过的问题，于是你们架构师每天分出很多时间去看社区的进展，有了什么新工具，有什么公司发布了什么项目解决了什么问题，兴许你就能用上。
上了这些乱七八糟的东西，你以为就安生了？Hadoop平台的一个大特点就是坑多。尤其是新做的功能新起的项目。对于平台组的人，老板如果知道这是天然坑多的平台，那他也许会很高兴，因为跟进社区，帮忙修bug，一起互动其实是很提升公司影响力的实情。当然如果老板不理解，你就自求多福吧，招几个老司机，出了问题能马上带路才是正道。当然团队的技术积累不能不跟上，因为数据平台还是乱世，三天不跟进你就不知道世界是什么样了。任何一个新技术，都是坑啊坑啊修啊修啊才完善的。如果是关键业务换技术，那需要小心再小心，技术主管也要有足够的积累，能够驾驭，知道收益和风险。
亲身参与，作为主力完成了一个信息大数据分析平台。中间经历了很多问题，算是有些经验，因而作答。
整体而言，大数据平台从平台部署和数据分析过程可分为如下几步：
1、linux系统安装
一般使用开源版的Redhat系统–CentOS作为底层平台。为了提供稳定的硬件基础，在给硬盘做RAID和挂载数据存储节点的时，需要按情况配置。例如，可以选择给HDFS的namenode做RAID2以提高其稳定性，将数据存储与操作系统分别放置在不同硬盘上，以确保操作系统的正常运行。
2、分布式计算平台/组件安装
目前国内外的分布式系统的大多使用的是Hadoop系列开源系统。Hadoop的核心是HDFS，一个分布式的文件系统。在其基础上常用的组件有Yarn、Zookeeper、Hive、Hbase、Sqoop、Impala、ElasticSearch、Spark等。
先说下使用开源组件的优点：1）使用者众多，很多bug可以在网上找的答案（这往往是开发中最耗时的地方）。2）开源组件一般免费，学习和维护相对方便。3）开源组件一般会持续更新，提供必要的更新服务『当然还需要手动做更新操作』。4）因为代码开源，若出bug可自由对源码作修改维护。
再简略讲讲各组件的功能。分布式集群的资源管理器一般用Yarn，『全名是Yet Another Resource Negotiator』。常用的分布式数据数据『仓』库有Hive、Hbase。Hive可以用SQL查询『但效率略低』，Hbase可以快速『近实时』读取行。外部数据库导入导出需要用到Sqoop。Sqoop将数据从Oracle、MySQL等传统数据库导入Hive或Hbase。Zookeeper是提供数据同步服务，Yarn和Hbase需要它的支持。Impala是对hive的一个补充，可以实现高效的SQL查询。ElasticSearch是一个分布式的搜索引擎。针对分析，目前最火的是Spark『此处忽略其他，如基础的MapReduce 和 Flink』。Spark在core上面有ML lib，Spark Streaming、Spark QL和GraphX等库，可以满足几乎所有常见数据分析需求。
值得一提的是，上面提到的组件，如何将其有机结合起来，完成某个任务，不是一个简单的工作，可能会非常耗时。
3、数据导入
前面提到，数据导入的工具是Sqoop。用它可以将数据从文件或者传统数据库导入到分布式平台『一般主要导入到Hive，也可将数据导入到Hbase』。
4、数据分析
数据分析一般包括两个阶段：数据预处理和数据建模分析。
数据预处理是为后面的建模分析做准备，主要工作时从海量数据中提取可用特征，建立大宽表。这个过程可能会用到Hive SQL，Spark QL和Impala。
数据建模分析是针对预处理提取的特征/数据建模，得到想要的结果。如前面所提到的，这一块最好用的是Spark。常用的机器学习算法，如朴素贝叶斯、逻辑回归、决策树、神经网络、TFIDF、协同过滤等，都已经在ML lib里面，调用比较方便。
5、结果可视化及输出API
可视化一般式对结果或部分原始数据做展示。一般有两种情况，行数据展示，和列查找展示。在这里，要基于大数据平台做展示，会需要用到ElasticSearch和Hbase。Hbase提供快速『ms级别』的行查找。 ElasticSearch可以实现列索引，提供快速列查找。
平台搭建主要问题：
1、稳定性 Stability
理论上来说，稳定性是分布式系统最大的优势，因为它可以通过多台机器做数据及程序运行备份以确保系统稳定。但也由于大数据平台部署于多台机器上，配置不合适，也可能成为最大的问题。 曾经遇到的一个问题是Hbase经常挂掉，主要原因是采购的硬盘质量较差。硬盘损坏有时会到导致Hbase同步出现问题，因而导致Hbase服务停止。由于硬盘质量较差，隔三差五会出现服务停止现象，耗费大量时间。结论：大数据平台相对于超算确实廉价，但是配置还是必须高于家用电脑的。
2、可扩展性 Scalability
如何快速扩展已有大数据平台，在其基础上扩充新的机器是云计算等领域应用的关键问题。在实际2B的应用中，有时需要增减机器来满足新的需求。如何在保留原有功能的情况下，快速扩充平台是实际应用中的常见问题。
上述是自己项目实践的总结。整个平台搭建过程耗时耗力，非一两个人可以完成。一个小团队要真正做到这些也需要耗费很长时间。
目前国内和国际上已有多家公司提供大数据平台搭建服务，国外有名的公司有Cloudera，Hortonworks，MapR等，国内也有华为、明略数据、星环等。另外有些公司如明略数据等还提供一体化的解决方案，寻求这些公司合作对 于入门级的大数据企业或没有大数据分析能力的企业来说是最好的解决途径。
对于一些本身体量较小或者目前数据量积累较少的公司，个人认为没有必要搭建这一套系统，暂时先租用AWS和阿里云就够了。对于数据量大，但数据分析需求较简单的公司，可以直接买Tableau，Splunk，HP Vertica，或者IBM DB2等软件或服务即可。
以上是我从事大数据以来的一些认识。管见所及，可能有所疏漏，欢迎补充。
深夜撰文，难免差错，有问题欢迎拍砖。若有用也请点个赞！
谢谢!
首先写一下一个大数据平台是什么，然后再说一下如何搭建。
对于一个大数据平台主要分为三部分
数据接入是将数据写入数据仓储中，也就是数据整合。因为在企业中，数据可能分布在外部和内部，分布在外部的是企业使用第三方系统产生的数据和一些公共数据，分布在企业内部的是企业内部IT系统产生的数据。这些数据一般都是独立分布的，也就是所说的数据孤岛，此时的这些数据是没有什么意义的，因此数据接入就是将这些内外部的数据整合到一起，将这些数据综合起来进行分析。
数据处理是对接入的数据进行数据清洗和ETL建模，将各个数据表之间的关系建立起来，比如关联，聚合，追加等等这些处理。
数据分析是在数据处理后的数据基础上进行维度和数值的可视化分析，也就是基于OLAP的查询和分析，包含上卷，钻取，切片，转轴等操作，最后分析的结果通过报表或是仪表盘来呈现出来，从而支撑业务人员和决策人员。
按照数据处理的顺序可以将大数据平台分为传统型和敏捷型，传统型的是在将数据送入数据仓储里面之前做，存入数据仓储里面的数据已经定义好了事实维度这些模型关系，业务人员可以直接进行查询，但是实时性和灵活性会大打折扣，如果业务人员需要分析一个事先没有的数据的话，需要去跟技术人员反馈，技术人员来完成处理。而敏捷型的则是将数据处理放到了后面，这样业务人员可以根据自己的需要去自助探索式的建模和进行数据分析，但是对系统的性能要求较高。
上面只是从产品层面来进行了说明，下面从技术层面来进行对应。
首先是数据仓储，一般是基于HDFS，采用分布式的文件系统来进行存储。数据处理和数据分析需要基于大数据处理引擎，如果想要实时的查询则需要用Spark这类的基于内存计算的，如果实时性要求没那么高的则可以用基于MR的这些离线计算的引擎。数据分析需要OLAP以及前端可视化这些技术来进行支撑。
知道了是什么样的，接下来我们可以来做了。
通过上面的介绍，我们可以看出需要的技术成本是比较高的，因此对于初创型的公司建议采用第三方的工具来使用。比如国内的BDP(
数据处理-可视化拖拽和SQL
数据可视化-丰富的图表和交互
如果公司有足够的实力，想自建数据平台，可以在现有的一些开源的数据相关的工具来进行搭建，底层存储和计算平台的HDFS，Spark，Hive这些都是Apache开源的，OLAP有Kylin，Saiku这些开源工具，可视化有Airbnb开源的Superset，如果在这些基础上进行搭建和开发，相信能够省去一些开发量，但是事物除了有共性还是有个性的，想要绝对的满足需求是没有的，都是需要企业根据自身的需求来进行定制化开发的。
找到一大堆数据分析师
把他们灌倒or迷晕
获取他们公司数据库权限
把数据荡下来
当你荡的足够多的时候你就能搭建一个数据平台了！
我是认真的！
写爬虫爬？那得爬到猴年马月…
大数据交易？数据那么机密，谁敢跟你交易？现在的大数据平台有几个是活跃的？
云、生态、共享、数据集市……还得再吹两年的牛*吧！
数据交易这种敏感的事情一时半会儿是平台化不起来的，还得先走野路子！
不过数据交易平台前景是不错的，拿过来做融资很有前景！
打个广告：想搞野路子数据交易的请联系我！倒卖数据！联系方式见主页！
1、美团的大数据平台架构实践 – 知乎专栏
2、链家网大数据平台建设，平台枢纽–工具链 – 知乎专栏
扩展一下这个问题，从常规数据平台到大数据平台的选择可参考阅读：怎样选择数据平台的建设方案 – 知乎专栏
关于大数据平台建设
大数据平台的建设过程是由下而上逐步完成的。
首先要有Hadoop集群，在有HDFS与Hive后，才能开展数据接入工作，才能基于集群建设工具链；当工具链部分的OLAP引擎构建好，才有上层BI、报表系统和数据API，只有AdHoc能力构建好，才能提供基于SQL的数据探索平台，工具链中特别需要建设好调度系统，才能在实现好数据ETL任务的同时，管控数据流向与数据关系。最后则是服务层面的建设，重心在于迎合需求的同时，服务做得更加易用，数据管理系统会穿插于整个大数据平台中。所以弄清了每个部分的相互关系也就容易明白大数据平台的建设流程。
最后，关于大数据资讯和案例干货，欢迎关注专栏：帆软数据应用研究院 – 知乎专栏
咳咳，不请自答。
因为参与了以前公司大数据方向产品从0~1的过程，也正在参与现在公司平台化0.5~1的过程，吃了很多亏，踩了很多坑，所以想谈谈自己对这个问题的看法。
在之前公司参与0~1过程的时候，当时团队里没有这方面的专家，我本人也是刚刚从事这个领域，所以基本上是一穷二白一窍不通的。当时单单一个“大数据”及“云计算”两个的相同与不同就给我们造成了很大的困扰：我们到底要做一个什么样的产品？
所以，题主问如何创建一个大数据平台，那么我觉得第一个步骤绝对是做好定位。
而对产品的定义，往往都是需求决定的，所以先问问自己或者领导们，为什么我们要做大数据平台？确定有这个必要么？你们真的需要一个完整的大数据平台，还是只需要一个能够方便进行并行计算的系统？这一步的定位直接影响到后续工作的展开以及各种成本（人力、资金、时间），也关系到开展难度及最终收益。
做技术，尤其是没有太多经验从零开始做的时候，经常会为了做技术而做技术，这实际上是不可取的，我个人也在这点上栽过很多次。所以我的建议是，这一步请千万不要任性。
当对要做的产品有个很好的定位的时候，对一些概念也有了基本的认识，那么这个时候就要开始涉及技术选型啦。我个人的建议是由最贴近用户的那个组件由上往下开始逐一推导选择。加入你们大数据平台的用户是一群直接使用SQL的BI，那么这个时候用户接口那一层技术要么HIVE要么Spark sql，然后结合你们物理设备的状态，成本或者技术倾向性，技术背景等等因素做出选择。
由于现在社区活跃度高，网络上有很多例子可以参考，所以对于初期的架构搭建难度并不会很大，只要找个例子先把几个组件搭建起来就是第一步了。比如选择spark做计算引擎，选择hdfs做分布式文件系统，如果应用需要加个hbase，有了hbase必定会有zookeeper，如果要考虑流式计算和消息总线那么就加个kafka，然后用spark streaming做流式计算引擎等等等等。这一步只要设备到位，应该可以快速实现的。
为什么我会认为这一步应当快速实现？我非常推崇一句话就是“好的架构不是设计出来的而是演化出来的”。当你有了系统主体以后，你的系统首先是一个可运行的系统，这个系统已经可以简单地被用户开始使用了，比如跑跑简单的数据分析等等。然而在使用的过程中必定会发生很多很多事情，比如应用运行过程中性能低，哦，那么我们开始调整系统参数进行优化；比如应用运行过程中经常崩溃，哦，我先排个雷然后加个ganglia把系统监视起来……对于在生产环境中大规模使用的大数据平台这样的系统来说，相信我，不会有一个放之四海皆准的方案，具体怎么实施，一些参数怎么配置，都需要不停地演化。而系统的演化并不是架构师或者老板拍脑袋得到的，应当是由业务驱动的，是由实际出现的问题驱动的，这个过程是需要研发团队全程介入的。
上面的是关于技术的，然而一个大数据平台这样的系统，它的运行成功或失败绝不是仅仅取决于技术，它同样涉及到对人和制度的管理。建立一个平台就是在创造一套规则，发明一个游戏，然后让其他人在你的游戏规则下进行游戏。游戏规则是否科学会直接影响到这个平台执行的好坏。关于这点，可以参考一些成功的公有数据平台的方案，进行简化，本地化，然后拉上线。当然，这套规则也是在不断演化的。
乱七八糟说了一堆，希望能有帮助，对于这方面的问题，欢迎各种花式联系讨论~
以上~
这题目和“如何月入十万”有异曲同工之妙。
场景，预算，团队，商业模式是什么，把这些细节补充完了再请人答题。
电影级别的图形集群实际，有这类创业的朋友吧，核磁共振的数字人体数据是初步
把100G的数字人体数据活动起来就是一切大数据未来，其他只不过是数据挖掘
019.Win7下免Cygwin安装续与NativeBug解决与Dexpot_Hadoop第三季-Win7下免搭建Cygwin视频课程（共2课时）
零基础学习 Hadoop 该如何下手？ – 编程
请问有哪些关于大数据以及hadoop好的学习课程？ – 王门十哲之一的回答
15种最佳方式帮你顺利掌握Hadoop技术
Hadoop 实战 [中文版].pdf
Hadoop生态系统学习路线
概念，算法,应用全部有，迄今为止对大数据研究最透彻的文章……
十八款Hadoop工具帮你驯服大数据
盘点2014：十家最酷的大数据创业公司
l0个Hadoop的应用场景
100个替代昂贵商业软件的开源应用
从零开始搭建Hadoop2.7.1的分布式集群
Hadoop 的搭建.doc
Hadoop工程师成为热门职业
60款与Hadoop和大数据相关的顶级开源工具
Hadoop和大数据：60款顶级大数据开源工具
Hadoop完全分布式搭建
精通HADOOP.pdf
Presto 来自Facebook的开源分布式查询引擎
吕信：PrestoDB在京东的应用实践
转-朝花夕拾之–大数据平台CDH集群离线搭建
转-朝花夕拾之
穷人的持续集成与持续交付（上）
穷人的持续集成与持续交付（下）
Presto | 概览
Hadoop分布式文件系统HDFS的工作原理详述
Tachyon–以内存为核心的开源分布式存储系统
译|5个顶级的图形可视化工具
大数据游戏怎么玩？如何开始大数据创业？
用php做爬虫 百万级别知乎用户数据爬取与分析
运营商如何玩转大数据？ 浙江移动云计算和大数据实践（PPT附下载）
在美国，在R、NoSQL和MapReduce方面需求的专业人才薪水达到了每年约11万5千美元，在中国，大数据人才一将难求，创业公司不容易招大数据技术人才，即使招到，人才方面支出也较高。包括高薪、期权和股票等等；
R/Python/MATLAB（必备）：如果是做数据分析和模型开发，以我的观察来看，使用这三种工具的最多。R生来就是一个统计学家开发的软件，所做的事也自然围绕统计学展开。MATLAB虽然算不上是个专业的数据分析工具，但因为很多人不是专业做数据的，做数据还是为了自己的domain expertise（特别是科学计算、信号处理等），而MATLAB又是个强大无比的Domain expertise工具，所以很多人也就顺带让MATLAB也承担了数据处理的工作，虽然它有时候显得效率不高。Python虽然不是做数据分析的专业软件，但作为一个面向对象的高级动态语言，其开源的生态使Python拥有无比丰富的库，Numpy, Scipy 实现了矩阵运算/科学计算，相当于实现了MATLAB的功能，Pandas又使Python能够像R一样处理dataframe，scikit-learn又实现了机器学习。
SQL（必备）：虽然现在人们都说传统的关系型数据库如Oracle、MySQL越来越无法适应大数据的发展，但对于很多人来说，他们每天都有处理数据的需要，但可能一辈子都没机会接触TB级的数据。不管怎么说，不论是用关系型还是非关系型数据库，SQL语言是必须要掌握的技能，用什么数据库视具体情况而定。
MongoDB（可选）：目前最受欢迎的非关系型数据库NoSQL之一，不少人认为MongoDB完全可以取代mySQL。确实MongoDB方便易用，扩展性强，Web2.0时代的必需品。
Hadoop/Spark/Storm（可选）: MapReduce是当前最著名也是运用最广泛的分布式计算框架，由Google建立。Hadoop/Spark/storm都是基于MapReduce的框架建立起来的分布式计算系统，要说他们之间的区别就是，Hadoop用硬盘存储数据，Spark用内存存储数据，Storm只接受实时数据流而不存储数据。一言以蔽之，如果数据是离线的，如果数据比较复杂且对处理速度要求一般，就Hadoop，如果要速度，就Spark，如果数据是在线的实时的流数据，就Storm。
OpenRefine（可选）：Google开发的一个易于操作的数据清洗工具，可以实现一些基本的清洗功能。
Tableau（可选）：一个可交互的数据可视化工具，操作简单，开箱即用。而且图表都设计得非常漂亮。专业版1999美刀，终身使用。媒体和公关方面用得比较多。
Gephi（可选）：跟Tableau类似，都是那种可交互的可视化工具，不需要编程基础，生成的图表在美学和设计上也是花了心血的。更擅长复杂网络的可视化。
数据科学 怎样进行大数据的入门级学习？
扛住100亿次请求 如何做一个“有把握”的春晚红包系统？（PPT下载）
齐鲁财富网(山东瀚讯信息技术有限公司)是一家致力于“服务大众”的专业财经网站，首要目标是服务山东100万家小微企业、2500万经济从业者和1亿人口，向他们提供最实用、最专业、最权威、最有价值、与百姓息息相关的财经资讯。网站是集传统网站、移动客户端、微信公众平台、微博等多种新兴传播载体于一体的新锐媒体，设有大事、商业、财富、思想、生活、大数据等主要栏目、数十个细分栏目，正逐渐成为政府、企业、百姓之间的信息交流、互动平台，日常经营、管理、消费、生活等经济活动中最依赖、最信赖的专业网站。
大数据高级工程师
北京市 / 全职 / 30K以上 / 3-5年 / 大专
职位描述
1，负责公司大数据平台存储模块的架构设计和开发；
2，解决PB级数据的存储、访问以及数据安全；
3，持续优化巨量数据的存储效率，解决高并发情况下的低延时访问；
4，与数据计算/存储团队合作，开发维护公司大数据平台，并持续优化。
职位要求：
1，熟练掌握Java、Scala、C++、ruby、python中至少一种语言；
2，熟悉Hadoop、Hbase、Hive、spark、storm ，两年以上相关开发经验
3，熟悉大数据周边相关的数据库系统，如mongodb、redis
4，在开源社群活跃并有积极贡献者优先。
5，具有以下相关技能者优先：elasticSearch，drill，netty，kafka，zeppline，zabbix
乐视网招数据分析/开发工程师，薪水15k-40K
招聘办女秘书 2015-10-28 12:13:20 人才招聘 评论(0)
招聘岗位：
数据分析/开发工程师
薪水范围：
15k-40K；
就职地点：北京 朝阳公园 乐视大厦
工作描述：
1.参与数据仓库（DWS层）的搭建，根据BI项目的需求，制定ETL相关的设计方案。
2.负责BI项目汇总层的数据模型的设计。
3.负责数据源的调研，抽取，清洗、转化等etl开发。
4.在hadoop中使用hive及python开发脚本。
5.数据仓库日常运维、流程作业监控、数据质量监控。
6.使用kettle或者存储过程处理临时导数报表需求。
7.熟悉1-2款开源数据可视化产品应用或二次开发（better);
投简历邮箱：caiyingwei@letv.com
京东大数据平台招聘WEB前端架构师/Presto研发工程师
LinkinPark 2015-10-19 5:05:14 人才招聘 评论(0)
大数据
岗位名称：WEB前端架构师
岗位职责：
1.负责京东集团统点击流系统的架构升级及优化，保证系统的稳定运行；
2.负责制定开发及维护标准，保证开发及维护的便捷性；
3.负责相关新技术跟踪及技术选型，保证技术、架构的可扩展及先进性。
任职资格：
1.本科或以上学历，计算机相关专业，需要有较强的学习能力；
2.精通JavaScript/HTML/CSS等Web开发技术，熟悉页面架构和布局；
3.对css/JavaScript性能优化、解决多浏览器兼容性问题有一定的经验；
4.熟悉HTTP1.0/1.1等Web协议，熟悉Web前后端运行流程；
5.熟悉W3C标准，精通DIV+CSS布局，逻辑思维强；
6.熟悉SDK/APP相关开发技术；
7.具备良好的系统分析、架构设计能力；
8.强烈的责任心与主动性，对所负责工作有owner意识，并能自我驱动成长；
9.良好的沟通能力、抗压能力，责任心强；
10.从事过互联网日志采集工作者优先；
11.具备团队管理经验者优先。
请将简历发送至邮箱：bjgaowei@jd.com
———————————–
岗位名称：Presto研发工程师
岗位职责:
1.负责研发京东的Hadoop&Presto集群平台；
2.根据业务需求持续性改进和优化集群系统性能；
3.指导和优化上层业务分布式程序实现。
任职资格:
1.熟悉Presto或Hadoop等一种或几种分布式计算平台，理解实现原理；
2.精通java语言；熟悉shell、python等至少一个脚本语言；
3.有Presto/Mapreduce应用开发经验、熟悉数据挖掘等算法者优先；
4.掌握集群的安装和部署，有集群运维和优化经验者优先；
5.善于分析和解决问题，比较强的学习和创新能力，有责任心。
请将简历发送至邮箱：wangyanming@jd.com
Presto实现原理和美团的使用实践
木叶丸 本文已发表在《程序员》2014.6月刊 · 2014-06-16 10:45
Facebook的数据仓库存储在少量大型Hadoop/HDFS集群。Hive是Facebook在几年前专为Hadoop打造的一款数据仓库工具。在以前，Facebook的科学家和分析师一直依靠Hive来做数据分析。但Hive使用MapReduce作为底层计算框架，是专为批处理设计的。但随着数据越来越多，使用Hive进行一个简单的数据查询可能要花费几分到几小时，显然不能满足交互式查询的需求。Facebook也调研了其他比Hive更快的工具，但它们要么在功能有所限制要么就太简单，以至于无法操作Facebook庞大的数据仓库。
2012年开始试用的一些外部项目都不合适，他们决定自己开发，这就是Presto。2012年秋季开始开发，目前该项目已经在超过 1000名Facebook雇员中使用，运行超过30000个查询，每日数据在1PB级别。Facebook称Presto的性能比Hive要好上10倍多。2013年Facebook正式宣布开源Presto。
本文首先介绍Presto从用户提交SQL到执行的这一个过程，然后尝试对Presto实现实时查询的原理进行分析和总结，最后介绍Presto在美团的使用情况。
Presto架构
presto架构图
Presto查询引擎是一个Master-Slave的架构，由一个Coordinator节点，一个Discovery Server节点，多个Worker节点组成，Discovery Server通常内嵌于Coordinator节点中。Coordinator负责解析SQL语句，生成执行计划，分发执行任务给Worker节点执行。Worker节点负责实际执行查询任务。Worker节点启动后向Discovery Server服务注册，Coordinator从Discovery Server获得可以正常工作的Worker节点。如果配置了Hive Connector，需要配置一个Hive MetaStore服务为Presto提供Hive元信息，Worker节点与HDFS交互读取数据。
Presto执行查询过程简介
既然Presto是一个交互式的查询引擎，我们最关心的就是Presto实现低延时查询的原理，我认为主要是下面几个关键点，当然还有一些传统的SQL优化原理，这里不介绍了。
完全基于内存的并行计算
流水线
本地化计算
动态编译执行计划
小心使用内存和数据结构
类BlinkDB的近似查询
GC控制
为了介绍上述几个要点，这里先介绍一下Presto执行查询的过程
提交查询
用户使用Presto Cli提交一个查询语句后，Cli使用HTTP协议与Coordinator通信，Coordinator收到查询请求后调用SqlParser解析SQL语句得到Statement对象，并将Statement封装成一个QueryStarter对象放入线程池中等待执行。
提交查询
SQL编译过程
Presto与Hive一样，使用Antlr编写SQL语法，语法规则定义在Statement.g和StatementBuilder.g两个文件中。
如下图中所示从SQL编译为最终的物理执行计划大概分为5部，最终生成在每个Worker节点上运行的LocalExecutionPlan，这里不详细介绍SQL解析为逻辑执行计划的过程，通过一个SQL语句来理解查询计划生成之后的计算过程。
SQL解析过程
样例SQL：
select c1.rank, count(*) from dim.city c1 join dim.city c2 on c1.id = c2.id where c1.id > 10 group by c1.rank limit 10;
逻辑执行计划
上面的SQL语句生成的逻辑执行计划Plan如上图所示。那么Presto是如何对上面的逻辑执行计划进行拆分以较高的并行度去执行完这个计划呢，我们来看看物理执行计划。
物理执行计划
逻辑执行计划图中的虚线就是Presto对逻辑执行计划的切分点，逻辑计划Plan生成的SubPlan分为四个部分，每一个SubPlan都会提交到一个或者多个Worker节点上执行。
SubPlan有几个重要的属性planDistribution、outputPartitioning、partitionBy属性。
PlanDistribution表示一个查询Stage的分发方式，逻辑执行计划图中的4个SubPlan共有3种不同的PlanDistribution方式：Source表示这个SubPlan是数据源，Source类型的任务会按照数据源大小确定分配多少个节点进行执行；Fixed表示这个SubPlan会分配固定的节点数进行执行（Config配置中的query.initial-hash-partitions参数配置，默认是8）；None表示这个SubPlan只分配到一个节点进行执行。在下面的执行计划中，SubPlan1和SubPlan0 PlanDistribution=Source，这两个SubPlan都是提供数据源的节点，SubPlan1所有节点的读取数据都会发向SubPlan0的每一个节点；SubPlan2分配8个节点执行最终的聚合操作；SubPlan3只负责输出最后计算完成的数据。
OutputPartitioning属性只有两个值HASH和NONE，表示这个SubPlan的输出是否按照partitionBy的key值对数据进行Shuffle。在下面的执行计划中只有SubPlan0的OutputPartitioning=HASH，所以SubPlan2接收到的数据是按照rank字段Partition后的数据。
物理执行计划
完全基于内存的并行计算
查询的并行执行流程
Presto SQL的执行流程如下图所示
Cli通过HTTP协议提交SQL查询之后，查询请求封装成一个SqlQueryExecution对象交给Coordinator的SqlQueryManager#queryExecutor线程池去执行
每个SqlQueryExecution线程（图中Q-X线程）启动后对查询请求的SQL进行语法解析和优化并最终生成多个Stage的SqlStageExecution任务，每个SqlStageExecution任务仍然交给同样的线程池去执行
每个SqlStageExecution线程（图中S-X线程）启动后每个Stage的任务按PlanDistribution属性构造一个或者多个RemoteTask通过HTTP协议分配给远端的Worker节点执行
Worker节点接收到RemoteTask请求之后，启动一个SqlTaskExecution线程（图中T-X线程）将这个任务的每个Split包装成一个PrioritizedSplitRunner任务（图中SR-X）交给Worker节点的TaskExecutor#executor线程池去执行
查询执行流程
上面的执行计划实际执行效果如下图所示。
Coordinator通过HTTP协议调用Worker节点的 /v1/task 接口将执行计划分配给所有Worker节点（图中蓝色箭头）
SubPlan1的每个节点读取一个Split的数据并过滤后将数据分发给每个SubPlan0节点进行Join操作和Partial Aggr操作
SubPlan1的每个节点计算完成后按GroupBy Key的Hash值将数据分发到不同的SubPlan2节点
所有SubPlan2节点计算完成后将数据分发到SubPlan3节点
SubPlan3节点计算完成后通知Coordinator结束查询，并将数据发送给Coordinator
执行计划计算流程
源数据的并行读取
在上面的执行计划中SubPlan1和SubPlan0都是Source节点，其实它们读取HDFS文件数据的方式就是调用的HDFS InputSplit API，然后每个InputSplit分配一个Worker节点去执行，每个Worker节点分配的InputSplit数目上限是参数可配置的，Config中的query.max-pending-splits-per-node参数配置，默认是100。
分布式的Hash聚合
上面的执行计划在SubPlan0中会进行一次Partial的聚合计算，计算每个Worker节点读取的部分数据的部分聚合结果，然后SubPlan0的输出会按照group by字段的Hash值分配不同的计算节点，最后SubPlan3合并所有结果并输出
流水线
数据模型
Presto中处理的最小数据单元是一个Page对象，Page对象的数据结构如下图所示。一个Page对象包含多个Block对象，每个Block对象是一个字节数组，存储一个字段的若干行。多个Block横切的一行是真实的一行数据。一个Page最大1MB，最多16*1024行数据。
数据模型
节点内部流水线计算
下图是一个Worker节点内部的计算流程图，左侧是任务的执行流程图。
Worker节点将最细粒度的任务封装成一个PrioritizedSplitRunner对象，放入pending split优先级队列中。每个
Worker节点启动一定数目的线程进行计算，线程数task.shard.max-threads=availableProcessors() * 4，在config中配置。
每个空闲的线程从队列中取出一个PrioritizedSplitRunner对象执行，如果执行完成一个周期，超过最大执行时间1秒钟，判断任务是否执行完成，如果完成，从allSplits队列中删除，如果没有，则放回pendingSplits队列中。
每个任务的执行流程如下图右侧，依次遍历所有Operator，尝试从上一个Operator取一个Page对象，如果取得的Page不为空，交给下一个Operator执行。
节点内部流水线计算
节点间流水线计算
下图是ExchangeOperator的执行流程图，ExchangeOperator为每一个Split启动一个HttpPageBufferClient对象，主动向上一个Stage的Worker节点拉数据，数据的最小单位也是一个Page对象，取到数据后放入Pages队列中
节点间流水线计算
本地化计算
Presto在选择Source任务计算节点的时候，对于每一个Split，按下面的策略选择一些minCandidates
优先选择与Split同一个Host的Worker节点
如果节点不够优先选择与Split同一个Rack的Worker节点
如果节点还不够随机选择其他Rack的节点
对于所有Candidate节点，选择assignedSplits最少的节点。
动态编译执行计划
Presto会将执行计划中的ScanFilterAndProjectOperator和FilterAndProjectOperator动态编译为Byte Code，并交给JIT去编译为native代码。Presto也使用了Google Guava提供的LoadingCache缓存生成的Byte Code。
动态编译执行计划
动态编译执行计划
上面的两段代码片段中，第一段为没有动态编译前的代码，第二段代码为动态编译生成的Byte Code反编译之后还原的优化代
码，我们看到这里采用了循环展开的优化方法。
循环展开最常用来降低循环开销，为具有多个功能单元的处理器提供指令级并行。也有利于指令流水线的调度。
小心使用内存和数据结构
使用Slice进行内存操作，Slice使用Unsafe#copyMemory实现了高效的内存拷贝，Slice仓库参考：airlift/slice · GitHub
Facebook工程师在另一篇介绍ORCFile优化的文章中也提到使用Slice将ORCFile的写性能提高了20%~30%，参考：
类BlinkDB的近似查询
为了加快avg、count distinct、percentile等聚合函数的查询速度，Presto团队与BlinkDB作者之一Sameer Agarwal合作引入了一些近似查询函数approx_avg、approx_distinct、approx_percentile。approx_distinct使用HyperLogLog Counting算法实现。
GC控制
Presto团队在使用hotspot java7时发现了一个JIT的BUG，当代码缓存快要达到上限时，JIT可能会停止工作，从而无法将使用频率高的代码动态编译为native代码。
Presto团队使用了一个比较Hack的方法去解决这个问题，增加一个线程在代码缓存达到70%以上时进行显式GC，使得已经加载的Class从perm中移除，避免JIT无法正常工作的BUG。
Presto TPCH benchmark测试
介绍了上述这么多点，我们最关心的还是Presto性能测试，Presto中实现了TPCH的标准测试，下面的表格给出了Presto 0.60 TPCH的测试结果。直接运行presto-main/src/test/java/com/facebook/presto/benchmark/BenchmarkSuite.java。
benchmarkName cpuNanos(MILLISECONDS) inputRows inputBytes inputRows/s inputBytes/s outputRows outputBytes outputRows/s outputBytes/s
count_agg 2.055ms 1.5M 12.9MB 730M/s 6.12GB/s 1 9B 486/s 4.28KB/s
double_sum_agg 14.792ms 1.5M 12.9MB 101M/s 870MB/s 1 9B 67/s 608B/s
hash_agg 174.576ms 1.5M 21.5MB 8.59M/s 123MB/s 3 45B 17/s 257B/s
predicate_filter 68.387ms 1.5M 12.9MB 21.9M/s 188MB/s 1.29M 11.1MB 18.8M/s 162MB/s
raw_stream 1.899ms 1.5M 12.9MB 790M/s 6.62GB/s 1.5M 12.9MB 790M/s 6.62GB/s
top100 58.735ms 1.5M 12.9MB 25.5M/s 219MB/s 100 900B 1.7K/s 15KB/s
in_memory_orderby_1.5M 1909.524ms 1.5M 41.5MB 786K/s 21.7MB/s 1.5M 28.6MB 786K/s 15MB/s
hash_build 588.471ms 1.5M 25.7MB 2.55M/s 43.8MB/s 1.5M 25.7MB 2.55M/s 43.8MB/s
hash_join 2400.006ms 6M 103MB 2.5M/s 42.9MB/s 6M 206MB 2.5M/s 85.8MB/s
hash_build_and_join 2996.489ms 7.5M 129MB 2.5M/s 43MB/s 6M 206MB 2M/s 68.8MB/s
hand_tpch_query_1 3146.931ms 6M 361MB 1.91M/s 115MB/s 4 300B 1/s 95B/s
hand_tpch_query_6 345.960ms 6M 240MB 17.3M/s 695MB/s 1 9B 2/s 26B/s
sql_groupby_agg_with_arithmetic 1211.444ms 6M 137MB 4.95M/s 113MB/s 2 30B 1/s 24B/s
sql_count_agg 3.635ms 1.5M 12.9MB 413M/s 3.46GB/s 1 9B 275/s 2.42KB/s
sql_double_sum_agg 16.960ms 1.5M 12.9MB 88.4M/s 759MB/s 1 9B 58/s 530B/s
sql_count_with_filter 81.641ms 1.5M 8.58MB 18.4M/s 105MB/s 1 9B 12/s 110B/s
sql_groupby_agg 169.748ms 1.5M 21.5MB 8.84M/s 126MB/s 3 45B 17/s 265B/s
sql_predicate_filter 46.540ms 1.5M 12.9MB 32.2M/s 277MB/s 1.29M 11.1MB 27.7M/s 238MB/s
sql_raw_stream 3.374ms 1.5M 12.9MB 445M/s 3.73GB/s 1.5M 12.9MB 445M/s 3.73GB/s
sql_top_100 60.663ms 1.5M 12.9MB 24.7M/s 212MB/s 100 900B 1.65K/s 14.5KB/s
sql_hash_join 4421.159ms 7.5M 129MB 1.7M/s 29.1MB/s 6M 206MB 1.36M/s 46.6MB/s
sql_join_with_predicate 1008.909ms 7.5M 116MB 7.43M/s 115MB/s 1 9B 0/s 8B/s
sql_varbinary_max 224.510ms 6M 97.3MB 26.7M/s 433MB/s 1 21B 4/s 93B/s
sql_distinct_multi 257.958ms 1.5M 32MB 5.81M/s 124MB/s 5 112B 19/s 434B/s
sql_distinct_single 112.849ms 1.5M 12.9MB 13.3M/s 114MB/s 1 9B 8/s 79B/s
sql_tpch_query_1 3168.782ms 6M 361MB 1.89M/s 114MB/s 4 336B 1/s 106B/s
sql_tpch_query_6 286.281ms 6M 240MB 21M/s 840MB/s 1 9B 3/s 31B/s
sql_like 3497.154ms 6M 232MB 1.72M/s 66.3MB/s 1.15M 9.84MB 328K/s 2.81MB/s
sql_in 80.267ms 6M 51.5MB 74.8M/s 642MB/s 25 225B 311/s 2.74KB/s
sql_semijoin_in 1945.074ms 7.5M 64.4MB 3.86M/s 33.1MB/s 3M 25.8MB 1.54M/s 13.2MB/s
sql_regexp_like 2233.004ms 1.5M 76.6MB 672K/s 34.3MB/s 1 9B 0/s 4B/s
sql_approx_percentile_long 587.748ms 1.5M 12.9MB 2.55M/s 21.9MB/s 1 9B 1/s 15B/s
sql_between_long 53.433ms 1.5M 12.9MB 28.1M/s 241MB/s 1 9B 18/s 168B/s
sampled_sql_groupby_agg_with_arithmetic 1369.485ms 6M 189MB 4.38M/s 138MB/s 2 30B 1/s 21B/s
sampled_sql_count_agg 11.367ms 1.5M 12.9MB 132M/s 1.11GB/s 1 9B 87/s 791B/s
sampled_sql_join_with_predicate 1338.238ms 7.5M 180MB 5.61M/s 135MB/s 1 9B 0/s 6B/s
sampled_sql_double_sum_agg 24.638ms 1.5M 25.7MB 60.9M/s 1.02GB/s 1 9B 40/s 365B/s
stat_long_variance 26.390ms 1.5M 12.9MB 56.8M/s 488MB/s 1 9B 37/s 341B/s
stat_long_variance_pop 26.583ms 1.5M 12.9MB 56.4M/s 484MB/s 1 9B 37/s 338B/s
stat_double_variance 26.601ms 1.5M 12.9MB 56.4M/s 484MB/s 1 9B 37/s 338B/s
stat_double_variance_pop 26.371ms 1.5M 12.9MB 56.9M/s 488MB/s 1 9B 37/s 341B/s
stat_long_stddev 26.266ms 1.5M 12.9MB 57.1M/s 490MB/s 1 9B 38/s 342B/s
stat_long_stddev_pop 26.350ms 1.5M 12.9MB 56.9M/s 489MB/s 1 9B 37/s 341B/s
stat_double_stddev 26.316ms 1.5M 12.9MB 57M/s 489MB/s 1 9B 38/s 342B/s
stat_double_stddev_pop 26.360ms 1.5M 12.9MB 56.9M/s 488MB/s 1 9B 37/s 341B/s
sql_approx_count_distinct_long 35.763ms 1.5M 12.9MB 41.9M/s 360MB/s 1 9B 27/s 251B/s
sql_approx_count_distinct_double 37.198ms 1.5M 12.9MB 40.3M/s 346MB/s 1 9B 26/s 241B/s
美团如何使用Presto
选择presto的原因
2013年我们也用过一段时间的impala，当时impala不支持线上1.x的hadoop社区版，所以搭了一个CDH的小集群，每天将大集群的热点数据导入小集群。但是hadoop集群年前完成升级2.2之后，当时的impala还不支持2.2 hadoop版本。而Presto刚好开始支持2.x hadoop社区版，并且Presto在Facebook 300PB大数据量的环境下可以成功的得到大量使用，我们相信它在美团也可以很好的支撑我们实时分析的需求，于是决定先上线测试使用一段时间。
部署和使用形式
考虑到两个原因：1、由于Hadoop集群主要是夜间完成昨天的计算任务，白天除了日志写入外，集群的计算负载较低。2、Presto Worker节点与DataNode节点布置在一台机器上可以本地计算。因此我们将Presto部署到了所有的DataNode机器上，并且夜间停止Presto服务，避免占用集群资源，夜间基本也不会有用户查询数据。
Presto二次开发和BUG修复
年后才正式上线Presto查询引擎，0.60版本，使用的时间不长，但是也遇到了一些问题：
美团的Hadoop使用的是2.2版本，并且开启了Security模式，但是Presto不支持Kerberos认证，我们修改了Presto代码，增加了Kerberos认证的功能。
Presto还不支持SQL的隐式类型转换，而Hive支持，很多自助查询的用户习惯了Hive，导致使用Presto时都会出现表达式中左右变量类型不匹配的问题，我们增加了隐式类型转换的功能，大大减小了用户SQL出错的概率。
Presto不支持查询lzo压缩的数据，需要修改hadoop-lzo的代码。
解决了一个having子句中有distinct字段时查询失败的BUG，并反馈了Presto团队 sql may fail with distinct columns in having statement by chenchun · Pull Request #1104 · facebook/presto · GitHub
所有代码的修改可以参考我们在github上的仓库 Commits · MTDATA/presto · GitHub
实际使用效果
这里给出一个公司内部开放给分析师、PM、工程师进行自助查询的查询中心的一个测试报告。这里选取了平时的5000个Hive查询，通过Presto查询的对比见下面的表格。
自助查询sql数
hive
presto
presto/hive
1424 154427s 27708s 0.179424582489
参考
Presto官方文档 Presto | Distributed SQL Query Engine for Big Data
Facebook Presto团队介绍Presto的文章
SlideShare两个分享Presto 的PPT
Presto overview
Hadoop Source Code Reading #15 in Japan
大数据平台？
大数据是因为业务需要才收集存储很多数据的，不是为了大数据而大数据
举个实际的例子：有个生产过程监控系统，为每个产品记录加工过程（谁、何时进行了什么工序，下载了哪些系统和应用文件）、测试结果（每个功能、部件的每种测试项）
然后就可以随时统计、分析、预警。。。了
具体环境：SQL2005+64G的机器，5年接近20亿条记录了（数据文件还没到1T）。。。。
目前正在做。占坑，有空答。