北京大数据研究院环境大数据研究中心于2016年7月建立，由北京大学副教务长、学科建设办公室主任、中国科学院院士张平文教授领衔。针对目前我国大气与海洋环境观测数据的缺失与失准、预报精度不足的问题，研究中心综合了来自北京大学、清华大学等高校的教师、博士后、研究生与本科生资源，发挥其在数据处理、模型分析与算法优化方面的优势，以京津冀雾霾与空气污染为应用实例，致力利用大数据分析技术优化处理原始资料、提高数值预报精度，为政府决策及人民生活提供有效参考；综合研究大气与海洋环境对相关产业的影响，基于历史数据处理、现阶段进展分析与未来潜能预测，为产业规划升级提供理论基础与技术支持。目前的雾霾计算与预测团队分观测数据的预处理与同化、使用气象模式WRF-chem运行数值预报、利用统计方法进行结果后处理三个模块，从大数据的视角对气象与雾霾预报的全过程实现全面优化。
北京大学大数据研究院环境大数据研究中心空气质量预报系统，是基于WRF-CHEM数值预报模式，对常规气象要素以及空气污染物进行数值预报和分析研究的大数据模拟系统，其中常规气象要素包括风、温度、湿度、气压和降水等，空气污染物包括细颗粒物(PM2.5)、粗颗粒物(PM10)、臭氧(O3)、一氧化碳(CO)、二氧化氮(NO2)和二氧化硫(SO2)等。
雾霾计算与预测项目组雾霾预报系统，是基于WRF-CHEM空气质量数值预报模式，在气象和空气污染物预报的基础上，对雾霾PM2.5浓度进行数值预报和分析研究的大数据模拟系统。雾霾预报系统运作流程大致分为初始场前处理、WRF-CHEM模式数值计算和数值结果后处理三个步骤。预报具有针对性，并将大数据算法应用到雾霾预报系统，从而进一步提高预报精度。
通过对实时监控点污染物浓度的查询，如O2、NO2、CO、PM10，PM2.5等，对污染物的时空特征进行分析，并结合气象数据，通过基于WRF-chem的综合污染物预测系统计算，实时对未来的气象及污染物情况进行预测，自动识别需要预警的污染物情况并进行预警，为污染应急提供技术指导和理论支持，对应急决策方案进行模拟，并给出预测结果，以及决策效果对比评估。大数据分析环境安装1
&&&&&&&&&&&&&&&&&&
大数据分析平台主要提供海量的数据存储和处理，其中主要使用了开源领域的Hadoop族的相关软件。
本文档描述大数据分析环境的搭建，主要包括Hadoop组建及其以来的其他组建的安装。
本文档以集群中包括安装三台机器为例，介绍环境的安装。多台机器的安装方法类似。
&Workstation-Full-7.0.1-…bundl
64FG3DA-DHZ57-081CY-LEY59-N3UZ2
[.Linux.5.2.64].RedHat.Enterprise.Linux.5.Update.2.x64.iso
linux01network
/etc/hosts
linux01ifcfh-eth0
无密码认证
接下来配置SSH无密码登录，最终达到的目的是linux01主机与其他两台主机之间SSH登陆无需密码认证
linux01主/root
然后进入cd &/root/.ssh/下面，会看到两个文件&id_rsa.pub，id_rsa，然后执行
修改文件"authorized_keys"的权限
设置完之后记得重启SSH服务，才能使刚才设置有效。
linux01/root/.ssh/rootlinux02
linux02.ssh
Network Time
Protocol(NTP)NTPNTP
1．Linux主机做时间服务器
第一步：检查是否已经安装有ntp软件包。输入
ntp-x.x.xpx-x.xx
使用以下命令检查ntp的版本：
ntprpmrpm -ivh
ntp-xxxrpm/opt/software/ntp
ntp/etc/ntpconf
27.10.1.11Linuxip
这样，该虚拟机的时间就和服务器上的相同了。
如果要实现自动同步，执行：
在里面编辑以下内容，必须用绝对路径：
1JDK/opt/software“java”
jdk-6u16-linux-i586-rpm.binjava
Enteryes/noyes
在最后加入一下语句：
使配置立即生效
验证安装，输入
出现以下提示说明安装成功
java version
"1.4.2"等jdk版本信息说明jdk安装成功。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。大数据的两个典型应用是面向用户的服务和搜索引擎，主要特点是：第一，数据处理技术比面向用户服务的技术所占比重更大;第二，数据规模比以前大很多;第三，通过快速迭代进行创新。随着对大数据系统更深层次的理解，林仕鼎认为大数据需要新的硬件体系结构，整个数据中心是一台计算机，软硬件协同创新。
百度的大数据系统有两个典型的应用：
第一是面向用户的服务，主要包括logic、cache、data这样的技术，绝大多数应用通常放在MySql、Nosql里面。这种应用的特点是每次用户查询来的时候我可能对于这个logic要求比较好，这个好处就是一个PC并不需要访问很多的数据。用户可能会有一些突发性的增长，就是尖峰的到来使这个系统压力变得更大。
还有一种典型应用是搜索引擎，通常来说它有几部分。我们希望从网络中爬那个数据，爬下来之后放在大的网页库里面，对网页库进行挖掘和分析，把那些作弊的网页去掉，找到每一个页面全值对它进行监控，进大排表。这里有几个不一样的地方，用户查询来的时候会访问大排表，但是每一次的访问对大排表的数据基本上每台机器都要访问到，另外后面处理是不间断的进行的，我们要把网页更新抓下来放到网页库分析。到中间有一个大的存储，逐渐又要发展成更实时的结构，我们希望借助更新的变化可以更快反馈到用户这边来，比如说谷歌做的系统就是这样的。
这两类应用都有一些特点：首先，越来越多的Workload转向离线数据处理。百度开始就是后台处理机器比用户服务机器多的公司。我们关注怎么帮助用户存储UTC，怎么让他访问UTC，不一定跟钱有关系的交易，客户逻辑这些工作。我们慢慢过渡到做大量的数据处理，数据处理从大规模越来越做得复杂、实时。
其次，随着我们对整个业界和数据越来越重视，每个公司的数据量都在增加，这是我们新应用的特点。今天我们数据量大概是1000PB，每天我们处理100PB以上的数据，网页数量接近一万亿章，中文加其他语言的页面，每天我们响应请求数量也是在百亿的数量级。我们这种请求跟普通用户的PV不一样的，因为每一次的查询是后面的这些机器，放到大排表的机器都需要访问一遍，每天产生一个TB的日志，这样的数据量大家可以看到会比一般公司高一到两个量级。
第三个应用的特点就是整个互联网的服务是以迭代式的方式开发的。很多时候我们做功能并不能一开始就做好，我要通过不断的实验去找出来哪一种做法是好的，而这种实验越来越多需要在线上完成，我们利用一小部分用户让他去做实验。比方说我们有两种算法A和B，我不知道哪个好，从线下调研下都很难知道哪个好，还有我们界面的改版只有让用户评价才知道哪个是好的。我们把大量的离线分析和在线实验结合起来，在线需要很多数据，通过大量线下数据进行处理才能生成，这个速度又非常重要，怎么把用户在线产生的数据更快速跟线下数据结合，再推到线上来。这个带来了很多问题，比如说发现同样一种功能其实在线上跑好几个版本的，我怎么对多版本程序逻辑管理，怎么为他们分配资源，怎么给导流，分配数据都是一个大问题。
比如说搜索引擎的迭代，我们看基本的网页库存储以外，我们需要有一个平台，根据网页库要分析的数据我们做特征的训练。在用户去做查询的时候我们可能分配不同小的用户去做CN，这个CN里面有不同的策略和算法，很多时候需要全量的数据，你做一个实验需要有全量大排表的数据，这个实验要根据结果做很快的分析。对于普通面向用户的产品实际上也需要做不断的迭代，我们从一个产品的想法到它的原型，然后变成系统到产品你可以做做运维，做运营的过程你要根据用户使用去做更快速的调整，这里面每个步骤要有大量技术支持.从想法开始，你可能需要一些数据分析验证你的想法，不一定说你非要做这个产品出来，你可以在事前验证究竟是不是靠谱。PM可能需要你的主意，你要怎么做，用最快的方式把原型拿出来，我们就可以使这个产品更快把功能确定下来，然后测试，这是典型的互联网产品所需要迭代的过程。
对于这样的一些问题，数据中心运用的模式是这样的，云计算、大规模存储，我们都做了很多系统。然后有大规模的计算，现在基于实时数据的分析和处理。我们有虚拟机可以支持多租户的环境，使得以前的应用可以更频繁的迁移过来。我们还做了App Engine，整体来说我们做这些功能是要解决Scalability的问题，但是这个是不是够我们可以看一下。大家可能不仅仅做了这些，像我们做了很多的存储，一开始的时候我们给每一个都做一套系统，随着系统越来越大之后我们发现很多问题是共性的，存储系统跟你数据组织和接口无关的这些技术我们需要处理。所以我们开始去整合这些系统，就重新设计一套这个系统希望说用一套系统支持不同数据的结构，好几个接口。这是我们统一的系统，然后我们构建一个数据结构，希望用内存加速这种实时的数据处理。这样的话我们去平衡应用需要大流量，高并发看起来比较矛盾的需求，通过一些技术组合去实现矛盾的需求。同时我们也去做数据访问，把数据不仅存下来而且传输也是统一的。在计算方面我们做了混合式的计算，从批量到增量到更实时的处理引擎。我们做了这么多，是不是够呢?这里又个有问题：
第一个问题就是所有的快速交付在向底下基础设施要需求的时候，你要让我快速把业务拿到，让我部署上去把业务运行起来。最好就是说我提出这个需求的时候我马上拿到这个资源。对于一个业务来说还好办，但是对于底下的基础设施来说你需要的需求不一样的，有时候需要硬盘大的等多样性的需求和快速交付有一个天然的矛盾问题。怎么解决这个矛盾的?首先说我们要改变传统的预算模式。我们还是业务线提这个预算，我们需要做这个审核，每年有几次的预算审核，如果大家有过几十万台大数据中心，你发现每年预算这个复杂性基本上是不可承受的工作。而且每个预算提出来的时候，他希望我最好拿到我需要的资源，但是这是不可能实现的事情。因为需求的越多样就意味着说你每个量PC就越少，就是越需要定制，越不能交付。提供交付能力我们改变这个运算模式，由按需预算改成定期扩容。我们做over provisioning，利用系统冗余资源满足业务突发需求和多样性的需求。你提前准备好这种资源一定是确定的，来自业务线的需求是不确定的。我们怎么能够做到这点，你要做provisioning你必须是标准化的需求。对于上面应用来说最重要能力就是做快速迭代，它拿到资源以后可以利用上去去做实验，去升级它的版本。但是我们怎么使这个迭代做的更快，除了我们现在提供的这些功能之外，实际上还需要很多很多东西，一个我们需要有更好的资源调度，需要有平台帮你处理容错和扩容的问题。这个实际上很难，我们做了很久，整个业界也做了很久，实际上这个还是很难做到的。我们下面有一个平台，上面的业务还是要做处理，需要把模块之间关系曝露给你，需要把数据提取出来，前面需要逻辑的部分是无状态的，这时候我才能在错误出现的时候做调度，流量变大的时候做扩容，但是这个意味着你这个结构需要重构，而且底下的系统需要有更好的错误监测和调度的能力。对于应用来说你需要有更好的部署能力，这个部署能力在大规模的系统里面，实际上也是一个很复杂的事情。我们典型的在线服务可能是几百个上千个模块在里头。我们做部署的时候你发现我们部署一个系统，它有很多的模块间的依赖关系，每个模块有好多个版本，要做多版本的迭代，这时候业务要存一个多版本的数量。怎么由系统帮助你维护服务之间的拓扑关系，这是需要解决的问题。我们有了一套环境之后你可能要扩建多个环境出来。
第二个问题：我们分发可能经历灰度过程从5%到10%到90%到100%，这个过程中间需要处理，这个业界很少做这个研究的。资源首先应该是弹性的，基站位网络还有机器，这是真正可以弹性扩张的。下面你快速迭代，服务运营的需求，对这种服务运营的需求你同样也需要支持这种弹性扩张。我们说到系统的弹性，它应该每个上面都有这种端到端统一做交付，由这些能力加起来才是真正弹性的平台。根据多年关于Elasticity的经验，你没有一个更好的预算模型，更好的硬件系统架构的话，是一个很大的瓶颈。当你把资源问题解决掉，功能解决掉，对上面的业务来说实际上最典型要处理的问题就是它需要做快速的迭代，做快速的版本升级，这里面需要有很多环境的支持。然后做运营的时候有大量收集数据和分析数据的需求，这些都应该集成到我们整体的平台上去才行，只有把这些做起来才是真正弹性的平台。我们为了解决这个问题，我们需要什么东西?我们考虑这个数据中心体系是什么?你本身基础设施怎么升级做到标准化，在标准化下满足应用多样性的需求。我们需要把那些资源都给出来，现在的机器一个一个节点都是CPU、内存、硬盘、SID，我们有那么多台机器插入的时候，整个基站和数据中心是单位，我们还可以把那些资源拿出来，CPU、内存、硬盘都拿出来，拿出来以后我们有很多的灵活性，我们就可以重新构造成一台一台的机器。这个有点像是说我们需要定义数据中心的体系，这个体系对于单机来说更像是原体系机构，我们配置这些原体系机构变成一台一台机构的体系结构。
另外我们在这个上面需要OS，可以帮助我们做资源的调度、更好的部署整个发布的管理，这是整个OS需要的功能。disaggregation我们把每一个节点里面CPU和电源拿出来放在后面去，下一步可能把网络拿出来放到后面去，这是无物理机的方式，这个不会改变整个系统的disaggregation。下面我们会做一件事情就是把里面机器节点直接联系起来，现在有这样一些技术可以使它们联系起来。一些机器可以访问另一台机器的某一个设备。再一下我们彻底的把它们重组起来，我们通过disaggregation出来，然后就可以形成一台一台需要的机器。这样我们可以在标准化系统交互的标准下满足应用多样化的需求。
我们需要有机器的管理，这个上面我们可以帮助做部署和发布，这时候应用的架构需要做变化，我们需要每一个应用里面服务依赖关系抽出来由系统管理，这个我们叫PIS的服务。然后一些应用可能服务加大，有一些它的数据，这个数据同样要列出来在前期管理，我们对应用做迁移和扩容的时候是无状态的也可以，很容易扩容。对应用的多个版本我们同样需要做软件包的管理，把它所依赖软件的环境都抽离出来由系统统一管理，这样我们可以构建出多种多样的环境出来，多个版本的环境出来。上面还要构建一些兼容系统，这个系统本身运行也会产生大量数据，我们对这些数据分析可以帮助我们指导系统的优化。这个我们已经做了一些工作，我们对磁盘做了大量的改进，现在可以把磁盘误报的错误率降低80%。在这个基础上还可以做机器CPU内存使用情况，网络通信情况，模块和模块之间通信的情况，我们把数据收集起来可以做分析，异常的检测，把异常的检测和错误事件解决连接起来，这样可以发现这个系统存在的问题防止一些错误的发生。
第三个问题，我们今天所说的大数据不仅是规模大，更重要是其他的特点。第一个我们需要有大规模的数据管理和处理能力。第二个特性是多样的，数据从多个来源来的，它的形态不一样的，我们需要有多模态的管理能力，我们需要管理视频，管理视频的特征，还有图片语音的特征，而且能够对它特征进行更好的分析查询的服务。我们需要具有关联分析能力，数据从多个来源来的时候，一定把多个来源的数据放再一块分析才可以发掘你要的东西出来。另外一个数据是不断的变化的，我们除了具有大规模数据处理能力之外还需要有智能的数据挖掘算法。
多媒体的分析、NOP、广告这些，中间是数据处理和管理包括大规模数据仓库和平台，后面是技术架构，软件架构包，实时的数据计算以及硬件的基础设施。这个基础之上我们可以把一个完整的大数据系统构建出来，比如说对于大规模的数据通过分布式的存储和计算引入进来。我们初步处理以后可以灌到机器学习算法里面去，通过引擎把消费者连接起来。让人标注可以帮助到我们的学习，现在所谓众包就是这个概念，有这样的系统之后我们可以支持评估、推荐、智能交通这样一些APP。对于实时的存储和计算我们除了做那些功能，我们还需要把完整的体系构建出来。我们需要有分布式的结构，你要做实时的分析数据一定要放在内存里面，你把数据放在内存应该在上面直接构建分布式数据处理。
我们发现说我们做了这么久软件上的架构还是不够的，很多问题还是解决不了，比如说我们做一个迭代，大家知道它是PSP的模型，所有的节点都需要你装满数据，这个基本上系统的瓶颈都在最后的交互数据上。这些东西除了我们软件做很多模型，更重要我们需要有新的硬件体系机构支持它。包括Power-efficent，还有以数据的移动和处理为中心，新的存储、通信、计算架构，异构化，同时还引入ARM、GPU、FPGA等技术。
我们现在做新的CRAY，这个CRAY机器里面有很多线。今天有了更多的数据以后我们还是要回到以数据交互为中心，而且这个需要跟其它服务共享基础设施，才可能成为真正的大规模系统，提高内聚性、配件池、标准化交付，满足应用层的差异性需求。以软件接口的方式隐藏异构性。现在我们做的事情就是新的软硬件一体的集成方案，包括应用驱动、软件定义、实现全系统的集成。这里想给硬件公司提几个建议：一个是硬件应该尽量简化。赢家呢可控制性、剥离控制逻辑应放在更重要的位置，硬件应尽可能多地收集数据，包括历史统计、当前状态，并通过数据分析去做更多的优化和智能。
转载请注明来自36大数据（)： &
除非特别注明，本站所有文章均不代表本站观点。报道中出现的商标属于其合法持有人。请遵守理性，宽容，换位思考的原则。