领读|解决方案介绍---22行代码，价值北京5套房！
关键词: 风能、集算器、运维
“世界对爱动感情的人是个悲剧，对爱思考的人是个喜剧”。不知道这句话是谁说的，我反复的读了好些遍，觉得很有道理。
因为我们不曾抵达更低，所以对更低缺少体会；因为我们不曾抵达更高，所以也不能体会“高处不胜寒”。正如我们不曾接触现场，所以我们不能体会现场的兴奋。
２２行代码，价值北京５套房，笑话吗？还真不是笑话，这可是实实在在的案例哦。
今天我们要讲的故事主人公是金爷。金爷原本是一个研发人员，也就是俗称的码农，在“数据蒋堂”代表的公司里码代码。
“数据蒋堂”是什么？之前我也不知道。这么说吧，在国内有这么一家公司，成立于2000年，一直专注于国内自有知识产权的数据计算的研究。默默的十七年，从一家致力于报表开发的公司，发展到现在的专注于计算中间件的公司，他的产品是专注于计算中间件的“集算器”。
没听说过？没关系，很快你就会听说的。这就像从石头里蹦出来的孙猴子一样，在蹦出来之前，他在石头里默默的待了3000年，藤蔓缠绕着他，乌鸦在他身上尽情的排泄，烈日毫不留情的暴晒他，雷雨肆无忌惮的侵蚀他……而一旦他破石而出，他就是“齐天大圣”。这家公司叫做“润乾信息”。
今天要表的是金爷。金爷，其貌中等，放在人海中肯定不好找，年轻的时候我不知道怎样，反正现在是这样的，哈哈。现在的金爷，从研发转而做售前了，一起与销售跌打滚爬在第一线。就是这个金爷，用22行代码创造了奇迹。
什么？代码是有价值的？什么代码有价值呢？
1、被时间检验过的代码，有价值。
2、反映需求的代码，有价值。
3、在实践中修改过的代码，有价值。
4、容易被阅读、容易被理解、容易被修改的代码，价值翻倍。
用“数据蒋堂”堂主的话说，作为计算的代码其价值主要是两点：数据计算在描述和实施上的效率问题。
先说说结果的对比：
下面统计一下使用C#/Java和集算器，实现本算法的差异，如下图：
我们的主角金爷，利用集算器，用22行代码实现了原来需要100倍代码的工作，关键的关键是消除了原来代码带来的计算不准确不稳定，消除了系统运行的不稳定性带来的隐患。
隐患？看来这个代码的主要价值是解决了隐患。为什么原来的C#/Java的代码不能解决呢，而且代码量要大出这么多倍？
话说金爷这次漂亮的解决的问题是“风电机组运行状况在线监测解决方案”中的风力发电机标准化采集的场景。
风能是一种干净的、可再生的能源，在当前国家大力保护环境、节约能源的背景下，利用风能发电是极为重要且极具有发展潜力的发电方式。根据现有情况推测，到二十一世纪三十年代初我国风力发电机组装机容量将有可能大大超过预估的2.3亿千瓦，甚至可能到达3亿千瓦。然而随着风电机组装机容量及机组单机容量不断增长的同时，又对风电机组的安全、可靠性提出了更高的要求。风电机组停机造成损失发电量，再加上风电场所处的地理位置比较偏僻，气候条件比较恶劣，而且机组处于高空运行，维修维护成本较高，严重影响风力发电的经济效益。因此，对于机组的运行要进行连续监控，第一时间了解机组的健康状态，具有重要的社会经济价值。据统计，使用在线监测系统的维修费用相比没有安装在线监测系统，可节省59%的费用。关键在于，在线监测系统的监测误差，它会带来许多的隐患。
目前的风电的典型状态：
现有风电场的建设一般较分散，要了解各风场的运行情况；
风电机组的数据采集和监控系统都是由风电机组制造商配套提供，各厂家的SACAD系统互不兼容，很难对其更新升级。这样就要求把各风场各厂家的运行参数集中起来以便于比较分析；
风电场的选址比较偏僻，地理环境比较恶劣，不易招到新的工作人员；
风电场相距较远，而每个风场内风机数量多，每个风场都需要配置一定的工作人员进行日常的巡检维护，从而造成了人员的浪费。
所以集中远程统一管理帮助客户实现了风电场无人值守的目标。
风电场远程监控系统主要包括三部分内容：
风力发电机组监控系统
场内变电站监控系统
风电场视频/安防系统
金爷在现场的这次工作主要就是针对“风力发电机组监控系统”。
工业设备生成的数据，通常由实时数据库进行初级采集。但实时数据过于原始，无法被信息管理系统、商业智能、数据挖掘等应用系统直接使用，这种情况下就需要进行标准化二次采集，形成规范一致的结构化数据。
由于实时库的特殊性，导致其标准化采集算法异常复杂，以前只能用JAVA\C#等高级语言实现，不仅设计周期长，且难以实现难以维护，执行效率也不尽人意。
集算器是彻底解决结构化计算难题的中间件产品，可代替JAVA\C#实现标准化采集算法。使用集算器后，可大幅缩减设计周期，快速直观地实现算法逻辑，显著提高执行效率。
以金爷在某新能源企业的风力发电机标准化状态采集为例。
应用系统功能：
应用系统是统计图+表格形式的报表，通过输入起点时间、终点时间、风机列表这三个参数，展现每个风机各停机了多长时间，并标记停机时间超过阈值的风机。
可见，应用系统其实非常简单，只要数据足够标准就行。
原始实时数据存储在麦杰数据库中，麦杰库没有JDBC接口，但有符合工业标准的OPC接口（OLE for Process Control）。通过该接口，JAVA程序可获取某时间段内某风力发电机每秒（或每毫秒）的起停状态。
难点分析：
接口特殊：麦杰接口是OPC，只能用API调用，访问起来很不方便，计算起来更是困难重重，因为它不像关系型数据库可用SQL语句实现查询、排序、聚合，它只能用JAVA/C#从底层实现，代码量极大，性能也难以保障。
算法复杂：其中：追溯（算法4）、停起对（算法7）、拉链（算法9）都是很难实现的算法。
频繁写库：由于拉链算法会频繁操作关系数据库，每次还要计算停起间隔，其他算法也会反复查询数据库，这就对数据库造成巨大压力，稳定性也会变差。算法中之所以易发生漏写数据、数据错误，就是因为频繁写库造成的。
易产生隐患：用C#实现追溯算法，由于缺乏直观易用的结构化库函数，只能用两个嵌套循环分别实现，一个用来计算本麦杰的停起对，向下循环；一个用来计算上麦杰的停起对，向上循环。向下循环比较直观，但向上循环过于抽象复杂，导致无法算出上麦杰的起机时间，只能用本麦杰的第一条（一定是起机时间）代替。这两个起机时间虽然属于同一个起机区，时间相差较小，但毕竟存在隐患，如果进行整月整年的统计，就会出现较大误差。
金爷的神器就是“集算器”，这神器厉害在那？
集算器除了关系型数据，还提供了大量非关系型数据接口，可直接访问Hive、MongoDB、Excel、Hbase、SPARK、redis、阿里云OTS，也包括麦杰。使用集算器访问并计算麦杰数据库，其便利性超过SQL，代码量极小。另外集算器库函数由专业级人士开发，有效保障性能。
以计算停起对为例，C#要195行代码，涉及大量嵌套循环以及难以理解的临时变量和条件关系，而集算器只需三行。可见，集算器代码精炼易懂，可以直观表达算法逻辑，且可断点调试，而同样的算法数据库也难以实现。
另外，集算器有统一入库口径，可在算法中实现数据比较、拉链、查询等操作，最后将原始数据和更改后的数据自动比对，批量生成SQL，只更新一次数据库。通过统一入库口径，数据库压力显著减轻，执行效率大大提升，原本C#中的漏写数据、数据错误不再发生。
集算器内置高性能结构化函数，上麦杰和本麦杰可合并后一起计算，不必分成两种算法，因此不存在这种隐患。类似的情况其实很多，原因也一样：C#/JAVA代码太长太复杂。
3亿千瓦的风电量，解决了运行状态监测的效率和消除了监测的不稳定性和隐患，您说，金爷的22行代码值多少钱？
最后，我们发现除了“风力发电机组监控系统”可以很好的使用金爷的神器“集算器”外，在“场内变电站监控系统”和“风电场视频/安防系统”内也有这个神器的用武之地哦。
想要了解金爷的神器“集算器”的朋友可以与我们联系和留言。
附：智能控制系统可大大提高风能利用率
美国雪城大学L.C.史密斯工程和计算机学院部分研究人员正在进行这方面的研究工作。目前，他们正在测试自己开发的主动式风流动智能控制系统。该系统的基本出发点是根据表面测量而估算流过叶片表面风的状况，然后将此信息传递给智能控制器，以便对叶片采取实时调整控制气流和提高风力发电机系统的整体效率。此举还有可能降低因流动分离而产生的过度噪音和叶片振动。
他们完成的初期仿真结果显示，对叶片1/2半径以外的外侧板施以气流控制，能在风力发电机额定功率输出相同的情况下，显著地增大风力发电机整体工作范围；或者说，在相同的工作范围，可适当地提高风力发电机的额定输出功率。
研究人员认为，在采用气流控制后，风力发电机的工作范围可以有效地提高80%，额定功率输出不变；或者将额定输出功率增加20%，工作范围保持不变。
借助雪城大学新落成的无回声风洞设施，研究人员同时还在分析和了解特定的叶片形状，以决定在气流极其不稳定的环境下，不同形状的叶片在受到适当气流控制时，其所具有的升力和阻力特性。此外，研究人员还将利用无回声风洞来评估和测量气流控制对风力发电机噪声频谱的影响。
这些最新领域的研究成果同样会碰到类似与本文的许多问题，“集算器”也会与广大的风力发电的厂家和集成商合作，共同为中国的风力发电事业作出贡献。
“相关文章阅读”
聚贤.堂近期招募信息