【业务科普】气象中的数据、大数据和云--之二：气象大数据

topmad

上一讲，大概讲了讲很基础的数据，因为偏底层，很多预报、科研业务压根涉及不到，对于在校的学生来说，更是遥遥不可及，显得很枯燥
然后一个漂亮的小姐姐{:soso__4381792760172653478_2:} 看的没胃口，今天打算好好做一下格式，希望不要被嫌弃

然而内容，可能依旧偏底层，也许写到最后，能够形成一个完整的闭环吧。
（漂亮警告，无关人员可以撤离了，底层劝退）

****正文开始****
为了好理解，后面所有的气象数据，除了特殊说明外，通指狭义的气象数据（温压湿风那些东东）



说起大数据，几乎现在任何领域都能沾上个边，各种概念炒的天花乱坠

1. import brain as talent

复制代码

诚然不可否认，大数据技术在这个信息时代带来的优势和冲击是不可阻挡的，剥去炒作的外壳，结合我们的气象，一起来看看气象的大数据

依旧，将气象的大数据，分为应用层和底层吧，

今天先从基础的底层讲起，大家最有兴趣的应用层的内容，后面再讲。毕竟。凡事都要有个基础。

后面的题目大概是
《举国震惊，大批预报员失业竟是因为它》
  《不看后悔一辈子，原来下不下雨竟由它决定》


     归纳一下后，应用层的气象大数据，指的是对大量气象或关联数据进行抽取分析，对其中关联的数学、物理、统计关系进行梳理或者通过机器学习（如果愿意的话叫什么深度学习，人工智能也行）的方式，对其规律进行探究，从而对其中的关系进行归纳总结。

今天讲的是底层的大数据，也可以理解为如何对应用层的大数据进行支持，其核心，就是数据管理。都是些定性的粗浅介绍，详细技术后面再谈，今天是总览

说到管理，就跟人一样...抛开规模谈管理 都是耍流氓{:soso__10550023340064966750_1:}

管一个人，一个班，一个学校，一个社区...  这管理方式，肯定是不同的。

放到气象数据领域，也是一个道理

如果我关注的是某一个站点过去几小时的数据，那么，很可能，一个excel就够了....
如果我关注的是一个省/区域几百个站点的数据，那么，很可能，需要好几个excel或者一个小规模的数据库....
如果我关注的是全国所有的地面、高空等数据，那么，很可能，光保存这些数据，就要几十台计算机协同工作了....
如果我关注的是全球的地面、高空、雷达卫星，那么，很可能，需要一栋特别大的楼，里面装满了各种设备....

上面仅仅是说了一个规模，如果算上其他的性能指标，那就更复杂了，
比如我要在全球范围内查询过去4小时亚太地区500百帕的温度场，指令发出后10个小时才返回结果，那预报员早就把电脑砸了

有了这些功能性（把数据存好）和非功能性（速度还要快）的需求，下面我们来看看

底层的气象大数据，都包括哪些部分，这些部分又有什么相互的联系呢？

首先，说说存储
上一讲也讲过了，气象数据需要一些特定的介质来保存，这里化繁为简，就说是普通的硬盘吧，把海量的数据存储起来，当然以目前的技术水平，还无法保存在一个硬盘内，需要许许多多硬盘组成一个大的存储系统来满足容量需求，但是硬盘毕竟是机械设备，存在一定的故障风险，比如硬盘坏了或者烧穿了
像这样（实际上，好多数据中心都需要推着小车换硬盘的.....）


这时候，就需要进行冗余和容错设计。什么raid 什么双活  就是让系统可以在某些组件失能的情况下，依旧保证基本功能。

     这还没完，
一旦保存数据的机房断电了、着火了怎么办？  答案是  在旁边再建立一个大楼机房保持相同的功能。
如果这个地区地震了或者其他原因无法使用，怎么办？ 答案是  我们在其他城市再建一个数据中心，


这就是赫赫有名的“两地三中心”，大概长这样...

                               
登录/注册后可看大图

来，顺便po一个机房的照片，...不敢放自己常去的那个

                               
登录/注册后可看大图

保存下来的数据要发挥它的价值，那么怎么用数据成了现在的当务之急，

就像刚刚说的，检索数据或者处理数据的时间如果太长，数据的价值就大打折扣甚至变得没有价值。为了保证访问的速度，还需要专门设计一套或者几套存储技术，确保数据访问的效率。

在一间房间里找某样东西，如果只有几个物品，那找起来当然很快，
可是如果有好多房间，每个房间都塞满了物品，那么，想找到确定的物品，不管用什么样的办法，总是要消耗更多的时间。

                               
登录/注册后可看大图

为了解决这一问题，在底层加入了诸多新技术和新方法比如分布式的关系型数据库，分析型数据库，对象存储，NAS等（不具体赘述）让数据检索的更快。

不同的存储技术对应不同的应用场景，比如天气预报需要短时间内获取广泛空间范围内的最近时刻的数据资料，以保证预报时效。
                                                          而气候业务需要段时间内获取长时间序列的完整的数据资料，以保证评估质量。

以上两个仅仅是一个简单的例子，实际应用中，远比这样的场景复杂，再加上卫星雷达等数据，就是一个纷繁复杂的过程了。

    {:soso__10824177594298302702_4:}说一个题外话，大家用的Micaps4 ，用户都说体验很好，实际上，从功能上来说，并没有什么质的飞跃（开发人员不要打我...）
但是因为对接了分布式关系型数据库Cassandra，不在基于传统的Samba文件系统，数据访问速度有了极大的提升，带来了很棒的用户反馈。




说完了存储，再说计算吧


计算，可以很简单，大家在自己的电脑上写个什么脚本，就能得到想要的结果

但是面对超大规模的时候，就又变得异常复杂，一个有趣而正确的理论是

一个人60秒能做完的事情，60个人1秒未必能完成。{:soso__7646437209695353583_2:}

面对海量的气象数据，格式不同、数据质量不同，在处理起来时，要面对繁多问题
传统单一的单节点计算机已经无法胜任这样规模的计算，需要众多计算机协同工作，如何保证参与工作的设备有序协调进行，如何保证结果的准确和同步，都是一个复杂的问题，所以引入了spark  storm等基于大数据的计算框架（具体实现过程不表了）

除去了存储和计算
剩下的就是一些更底层的东西了，那么多计算和存储的设备需要电力保证，需要散热保证，需要网络保证。这些都要需要系统工程性的建设和维护。

向那些辛苦的人致敬吧

言深深

优秀优秀！！！！

                               
登录/注册后可看大图

来自安卓APP客户端

一大碗年糕

顶呀顶{:5_213:}

樱桃瘦肉丸子

{:lxm_29:}{:lxm_29:}{:lxm_29:}