分類
發燒車訊

【Spring註解驅動開發】使用InitializingBean和DisposableBean來管理bean的生命周期,你真的了解嗎?

寫在前面

在《【Spring註解驅動開發】如何使用@Bean註解指定初始化和銷毀的方法?看這一篇就夠了!!》一文中,我們講述了如何使用@Bean註解來指定bean初始化和銷毀的方法。具體的用法就是在@Bean註解中使用init-method屬性和destroy-method屬性來指定初始化方法和銷毀方法。除此之外,Spring中是否還提供了其他的方式來對bean實例進行初始化和銷毀呢?

項目工程源碼已經提交到GitHub:https://github.com/sunshinelyz/spring-annotation

InitializingBean接口

1.InitializingBean接口概述

Spring中提供了一個InitializingBean接口,InitializingBean接口為bean提供了屬性初始化后的處理方法,它只包括afterPropertiesSet方法,凡是繼承該接口的類,在bean的屬性初始化后都會執行該方法。InitializingBean接口的源碼如下所示。

package org.springframework.beans.factory;
public interface InitializingBean {
	void afterPropertiesSet() throws Exception;
}

根據InitializingBean接口中提供的afterPropertiesSet()方法的名字可以推斷出:afterPropertiesSet()方法是在屬性賦好值之後調用的。那到底是不是這樣呢?我們來分析下afterPropertiesSet()方法的調用時機。

2.何時調用InitializingBean接口?

我們定位到Spring中的org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory類下的invokeInitMethods()方法中,來查看Spring加載bean的方法。

題外話:不要問我為什麼會是這個invokeInitMethods()方法,如果你和我一樣對Spring的源碼非常熟悉的話,你也會知道是這個invokeInitMethods()方法,哈哈哈哈!所以,小夥伴們不要只顧着使用Spring,還是要多看看Spring的源碼啊!Spring框架中使用了大量優秀的設計模型,其代碼的編寫規範和嚴謹程度也是業界開源框架中數一數二的,非常值得閱讀。

我們來到AbstractAutowireCapableBeanFactory類下的invokeInitMethods()方法,如下所示。

protected void invokeInitMethods(String beanName, final Object bean, @Nullable RootBeanDefinition mbd)
    throws Throwable {
	//判斷該bean是否實現了實現了InitializingBean接口,如果實現了InitializingBean接口,則調用bean的afterPropertiesSet方法
    boolean isInitializingBean = (bean instanceof InitializingBean);
    if (isInitializingBean && (mbd == null || !mbd.isExternallyManagedInitMethod("afterPropertiesSet"))) {
        if (logger.isTraceEnabled()) {
            logger.trace("Invoking afterPropertiesSet() on bean with name '" + beanName + "'");
        }
        if (System.getSecurityManager() != null) {
            try {
                AccessController.doPrivileged((PrivilegedExceptionAction<Object>) () -> {
                    //調用afterPropertiesSet()方法
                    ((InitializingBean) bean).afterPropertiesSet();
                    return null;
                }, getAccessControlContext());
            }
            catch (PrivilegedActionException pae) {
                throw pae.getException();
            }
        }
        else {
            //調用afterPropertiesSet()方法
            ((InitializingBean) bean).afterPropertiesSet();
        }
    }

    if (mbd != null && bean.getClass() != NullBean.class) {
        String initMethodName = mbd.getInitMethodName();
        if (StringUtils.hasLength(initMethodName) &&
            !(isInitializingBean && "afterPropertiesSet".equals(initMethodName)) &&
            !mbd.isExternallyManagedInitMethod(initMethodName)) {
            //通過反射的方式調用init-method
            invokeCustomInitMethod(beanName, bean, mbd);
        }
    }
}

分析上述代碼后,我們可以初步得出如下信息:

  • Spring為bean提供了兩種初始化bean的方式,實現InitializingBean接口,實現afterPropertiesSet方法,或者在配置文件和@Bean註解中通過init-method指定,兩種方式可以同時使用。
  • 實現InitializingBean接口是直接調用afterPropertiesSet()方法,比通過反射調用init-method指定的方法效率相對來說要高點。但是init-method方式消除了對Spring的依賴。
  • 如果調用afterPropertiesSet方法時出錯,則不調用init-method指定的方法。

也就是說Spring為bean提供了兩種初始化的方式,第一種實現InitializingBean接口,實現afterPropertiesSet方法,第二種配置文件或@Bean註解中通過init-method指定,兩種方式可以同時使用,同時使用先調用afterPropertiesSet方法,后執行init-method指定的方法。

DisposableBean接口

1.DisposableBean接口概述

實現org.springframework.beans.factory.DisposableBean接口的bean在銷毀前,Spring將會調用DisposableBean接口的destroy()方法。我們先來看下DisposableBean接口的源碼,如下所示。

package org.springframework.beans.factory;
public interface DisposableBean {
	void destroy() throws Exception;
}

可以看到,在DisposableBean接口中只定義了一個destroy()方法。

在Bean生命周期結束前調用destory()方法做一些收尾工作,亦可以使用destory-method。前者與Spring耦合高,使用類型強轉.方法名(),效率高。後者耦合低,使用反射,效率相對低

2.DisposableBean接口注意事項

多例bean的生命周期不歸Spring容器來管理,這裏的DisposableBean中的方法是由Spring容器來調用的,所以如果一個多例實現了DisposableBean是沒有啥意義的,因為相應的方法根本不會被調用,當然在XML配置文件中指定了destroy方法,也是沒有意義的。所以,在多實例bean情況下,Spring不會自動調用bean的銷毀方法。

單實例bean案例

創建一個Animal的類實現InitializingBean和DisposableBean接口,代碼如下:

package io.mykit.spring.plugins.register.bean;

import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.stereotype.Component;
/**
 * @author binghe
 * @version 1.0.0
 * @description 測試InitializingBean接口和DisposableBean接口
 */
public class Animal implements InitializingBean, DisposableBean {
    public Animal(){
        System.out.println("執行了Animal類的無參數構造方法");
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        System.out.println("執行了Animal類的初始化方法。。。。。");

    }
    @Override
    public void destroy() throws Exception {
        System.out.println("執行了Animal類的銷毀方法。。。。。");

    }
}

接下來,我們新建一個AnimalConfig類,並將Animal通過@Bean註解的方式註冊到Spring容器中,如下所示。

package io.mykit.spring.plugins.register.config;

import io.mykit.spring.plugins.register.bean.Animal;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
/**
 * @author binghe
 * @version 1.0.0
 * @description AnimalConfig
 */
@Configuration
@ComponentScan("io.mykit.spring.plugins.register.bean")
public class AnimalConfig {
    @Bean
    public Animal animal(){
        return new Animal();
    }
}

接下來,我們在BeanLifeCircleTest類中新增testBeanLifeCircle02()方法來進行測試,如下所示。

@Test
public void testBeanLifeCircle02(){
    //創建IOC容器
    AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(AnimalConfig.class);
    System.out.println("IOC容器創建完成...");
    //關閉IOC容器
    context.close();
}

運行BeanLifeCircleTest類中的testBeanLifeCircle02()方法,輸出的結果信息如下所示。

執行了Animal類的無參數構造方法
執行了Animal類的初始化方法。。。。。
IOC容器創建完成...
執行了Animal類的銷毀方法。。。。。

從輸出的結果信息可以看出:單實例bean下,IOC容器創建完成后,會自動調用bean的初始化方法;而在容器銷毀前,會自動調用bean的銷毀方法。

多實例bean案例

多實例bean的案例代碼基本與單實例bean的案例代碼相同,只不過在AnimalConfig類中,我們在animal()方法上添加了@Scope(“prototype”)註解,如下所示。

package io.mykit.spring.plugins.register.config;
import io.mykit.spring.plugins.register.bean.Animal;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Scope;
/**
 * @author binghe
 * @version 1.0.0
 * @description AnimalConfig
 */
@Configuration
@ComponentScan("io.mykit.spring.plugins.register.bean")
public class AnimalConfig {
    @Bean
    @Scope("prototype")
    public Animal animal(){
        return new Animal();
    }
}

接下來,我們在BeanLifeCircleTest類中新增testBeanLifeCircle03()方法來進行測試,如下所示。

@Test
public void testBeanLifeCircle03(){
    //創建IOC容器
    AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext(AnimalConfig.class);
    System.out.println("IOC容器創建完成...");
    System.out.println("-------");
    //調用時創建對象
    Object bean = ctx.getBean("animal");
    System.out.println("-------");
    //調用時創建對象
    Object bean1 = ctx.getBean("animal");
    System.out.println("-------");
    //關閉IOC容器
    ctx.close();
}

運行BeanLifeCircleTest類中的testBeanLifeCircle03()方法,輸出的結果信息如下所示。

IOC容器創建完成...
-------
執行了Animal類的無參數構造方法
執行了Animal類的初始化方法。。。。。
-------
執行了Animal類的無參數構造方法
執行了Animal類的初始化方法。。。。。
-------

從輸出的結果信息中可以看出:在多實例bean情況下,Spring不會自動調用bean的銷毀方法。

好了,咱們今天就聊到這兒吧!別忘了給個在看和轉發,讓更多的人看到,一起學習一起進步!!

項目工程源碼已經提交到GitHub:https://github.com/sunshinelyz/spring-annotation

寫在最後

如果覺得文章對你有點幫助,請微信搜索並關注「 冰河技術 」微信公眾號,跟冰河學習Spring註解驅動開發。公眾號回復“spring註解”關鍵字,領取Spring註解驅動開發核心知識圖,讓Spring註解驅動開發不再迷茫。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

FB行銷專家,教你從零開始的技巧

分類
發燒車訊

「半雞半鴨」:考古發現最古老禽類化石

摘錄自2020年3月28日大紀元報導

考古學家發現一隻禽類生物的頭骨和腿骨化石,經檢驗發現它生活在距今約6,680萬~6,670萬年前,是至今全球發現的最古老的鳥類化石。

這份近期發表在《自然》(Nature)期刊上的研究公布了這一發現。研究者之一劍橋大學的古生物學家菲爾德(Daniel Field)說:「這是我們至今發現的最早存在的鳥類的證據。」

恐龍大約在距今6,600萬年前滅絕,因此這隻生物生活在僅比那個時間點早一點的時期。在此之前,科學家找到的最早的鳥類化石大約生活在距今6,650萬年前。新發現的化石比這個更早一些。

研究人員估計這隻鳥的體重為400克左右,只有現在的水鳥——鳧的一半大。「我們認為它的臉看起來有點像現代的雞,但是頭骨的後面看起來又更像現在的鴨子。」菲爾德說。一起發現的還有它的腿骨化石,看起來它有著兩條細長的腿,說明它是生活在岸邊的一種禽類。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

FB行銷專家,教你從零開始的技巧

分類
發燒車訊

一種失去飛翔能力的鳥 使科學家重拾對環境的希望

環境資訊中心綜合外電;姜唯 編譯;林大利 審校

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

FB行銷專家,教你從零開始的技巧

分類
發燒車訊

氣候變遷納中歐關係核心 世界最大和第三大污染源諾推進氣候談判

環境資訊中心綜合外電;姜唯 編譯;林大利 審校

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

FB行銷專家,教你從零開始的技巧

分類
發燒車訊

輻射土由農家所有 福島農民告東電遭駁回

摘錄自2019年10月17日TVBS報導

日本在2011年發生了311大地震,伴隨而來的海嘯造成了福島第一核電廠爆炸,引發大規模輻射外洩,福島縣海洋、土壤受災嚴重。災後,當地農民依照國家規定,將農地進行翻土等除染作業,產出稻米也都符合安全值,卻喚不回消費者瓦解的信心。當地農家因此聚集控告東京電力公司,要求必須負責更換新土壤,以將田地輻射值降回核災前。但地方法院卻認為,落入農田的輻射已不歸電力公司管理,而是歸地主所有,因此駁回了農民控訴。

法院的裁決令農民們大失所望,但他們並不認輸,決定再上訴,不只是為自己討公道,更是要種出安心又安全、可以代代相傳的好米。

福島農民鈴木博之表示:「想到過去的美好就很心痛,我討厭沒有成績的工作,不管怎麼拚命都是原地踏步。」 鈴木先生在地震前創立了自我品牌,農產品自產自銷,更開設了米食店,賣著自家米做的麻糬、飯糰,眼看生意越做越好,沒想到遭遇了既是天災也是人禍的地震與核災。他說,「祖先交給我肥沃的田地,卻在我這代被弄髒了,我要讓它再變回原樣,傳承給下一代。」

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

FB行銷專家,教你從零開始的技巧

分類
發燒車訊

嫌環評太繁文縟節 川普提修法鬆綁 以加速油管、採礦工程

環境資訊中心綜合外電;姜唯 編譯;林大利 審校

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

FB行銷專家,教你從零開始的技巧

分類
發燒車訊

航空業新發現 只要微調飛行高度 就能大幅減少飛機雲、降低暖化效應

環境資訊中心綜合外電;姜唯 編譯;林大利 審校

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

FB行銷專家,教你從零開始的技巧

分類
發燒車訊

調查顯示電動車市占率有望在2020年超過10%

據悉,2013年中國節能與新能源汽車產業發展高峰論壇於上周在北京舉行,中國汽車工程學會副秘書長張寧在壇於上表示,針對486位汽車工程師進行的《電動汽車技術進步和產業化前景調查問卷》顯示,電動汽車有望在2020年-2025年之間實現商業化。2020年,電動車在世界乘用車市場中的佔有率將達到10%-15%。

根據調查數據,目前影響電動汽車發展的主要瓶頸還是電池技術、成本和續駛裡程。數據還顯示,到2020年,燃油汽車仍擁有15%-25%的發展潛力。因此,從中國的現階段來講,應當不要排斥某種技術路線,還是應當用多種方式推動節能減排,包括電動汽車及燃料汽車。

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

FB行銷專家,教你從零開始的技巧

分類
發燒車訊

Tesla執行長稱燃料電池不適合推廣 純電動車才有未來

據外媒本週二報導,美國電動跑車製造商特斯拉(Tesla)執行長Elon Musk本週在慕尼黑特斯拉展示中心表示,很多人都說純電動車根本沒有未來,但他認為,氫燃料電池基本上只是一種行銷的伎倆,氫是一種危險性頗高的氣體,比較適合用來推動火箭。

Elon Musk在演說中提到,旗下價格較低的大眾車種(可能會被命名為「Model E」)預料將在12-15個月內開發完成、2016年開賣,而休旅車「Model X」則會在明(2014)年問世。

此前,豐田汽車(Toyota) 董事長內山田武(Takeshi Uchiyamada)曾與9月30日在華盛頓特區經濟俱樂部(Economic Club of Washington, D.C.)發表演說後表示,Toyota之所以並未推出任何一款重量級純電動車,是因為該公司不認為這種產品會有市場。

目前全球燃料電池車的研發以日系車廠為軸心形成三大陣營,其中Toyota已表明計劃於2015年開賣燃料電池車。據日經新聞報導,預估2025年日本國內的燃料電池車普及數量將達200萬台。

另據日經新聞報導,日本政府也計劃於2015年度結束前,在國內整備100座氫燃料充填據點「氫氣站」,其他日本企業也紛紛著手進行相關技術的研發。為促進燃料電池車的普及,千代田化工建設(CHIYODA)計畫投下約300億日圓,於2015年在川崎市興建全球首座大規模氫燃料供應基地。

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※超省錢租車方案

※別再煩惱如何寫文案,掌握八大原則!

※回頭車貨運收費標準

※教你寫出一流的銷售文案?

FB行銷專家,教你從零開始的技巧

分類
發燒車訊

邊緣計算告訴你們公司空調怎麼開最省錢

據統計,現代城市人的生活與工作同樓宇息息相關,超過80%的時間都是在城市樓宇中度過,樓宇智能毋庸置疑是影響深遠的關鍵研究課題。

近年來,隨着邊緣計算技術的崛起,邊緣智能相關的場景應用拓展也成為科技公司爭相展現技術創新和商業價值的路徑,各種邊緣AI的解決方案亦應運而生,如華為雲智能邊緣平台IEF,一站式端雲協同多模態AI開發平台HiLens。據統計,現代城市人的生活與工作同樓宇息息相關,超過80%的時間都是在城市樓宇中度過,樓宇智能毋庸置疑是影響深遠的關鍵研究課題。本文將圍繞樓宇智能其中最重要的課題之一中央空調能效預測與管理來展開,目前,該課題面臨最大的瓶頸是:現有的大多數能效預測與管理方法僅限於雲端單任務,無法支撐中央空調能效模型在邊緣隱含的大量複雜場景上的能力。

眾所周知,暖通空調系統(包括供暖,通風和空調)主導着商業建築的用電量。對暖通空調系統的現有研究表明,準確量化冷水機組的能效比(數值越大越節能)非常重要,近期提出的數據驅動的能效比預測可以被應用到雲上。但是,由於不同園區擁有不同型號的空調或不同種類的傳感器,導致不同邊緣各個項目在特徵、模型等方面區別很大,在小樣本情況下很難用一個通用模型適應所有的項目。

近年來,華為雲邊緣雲創新lab與來自香港理工大學、IBM研究院、華中科技大學、同濟大學、深圳大學等知名校企研究團隊密切合作並持續開展技術研究,以邊緣樓宇智能領域場景為依託,希望逐步解決現實中隱含大量複雜場景的邊緣智能問題。有興趣的讀者歡迎關注2018到2020間年發表的多任務學習、多任務調度和多任務應用等歷史工作:

通用算法:多任務遷移與邊緣調度

基於元數據的多任務遷移關係發現

Zheng, Z., Wang Y., Dai Q., Zheng H., Wang, D. “Metadata-driven task relation discovery for multi-task learning.” In Proceedings of IJCAI (CCF-A), 2019.

在這篇論文中有一個多任務的實際應用案例,不同邊緣智能項目採用不同設備使得邊緣側模型不同,從而可以應用於多任務設定。這篇論文的亮點是引入元數據,元數據是數據集的描述信息,在複雜系統中用於日常系統運作,蘊含專家信息。基於元數據提取任務屬性,本論文設計了元數據任務屬性與樣本任務屬性層次結合的多任務通用AI算法(圖1)。相關論文專家評審也認為該技術在應用實踐中显示了實用價值,對機器學習項目真正落地具備重要意義,將成為當今大型組織感興趣的技術。

圖1 顏色代表不同聚類簇,数字代表不同設備型號。基於樣本屬性的方法容易導致負遷移(同一簇中混淆不同型號設備模型,左圖),而基於元數據的方法可以避免負遷移(右圖)。

多任務遷移學習的邊緣任務分配系統與實現

Zheng, Z., Chen, Q., Hu, C., Wang, D., & Liu, F. “On-edge Multi-task Transfer Learning: Model and Practice with Data-driven Task Allocation.” In Proceedings of IEEE TPDS (CCF-A), 2019.

Chen, Q., Zheng, Z., Hu, C., Wang, D., & Liu, F. “Data-driven task allocation for multi-task transfer learning on the edge. ” In Proceedings of IEEE ICDCS (CCF-B), 2019.

多任務遷移學習是解決邊緣上樣本不足的典型做法。而目前邊緣上的任務分配調度工作通常假設不同的多個任務是同等重要的,導致資源分配在任務層面不夠高效。為了提升系統性能與服務質量,我們發現不同任務對決策的重要性是一個亟需衡量的重要指標。我們證明了基於重要性的任務分配是NP-complete的背包問題變種,並且在多變的邊緣場景下該複雜問題的解需要被頻繁地重新計算。因此我們提出一個用於解決該邊緣計算問題的AI驅動算法,並且在實際多變的邊緣場景中進行算法測試(圖2),與SOTA算法相比該算法能減少3倍以上的處理時間和近50%的能源消耗。

圖2 根據邊緣場景動態進行任務分配調度

邊緣應用:樓宇智能

基於多任務的冷機負荷控制

Zheng, Z., Chen, Q., Fan, C., Guan, N., Vishwanath, A., Wang, D., & Liu, F. “Data Driven Chiller Sequencing for Reducing HVAC Electricity Consumption in Commercial Buildings.” In Proceedings of ACM e-Energy, 2018. Best Paper Award.

Zheng, Z., Chen, Q., Fan, C., Guan, N., Vishwanath, A., Wang, D., & Liu, F. “An Edge Based Data-Driven Chiller Sequencing Framework for HVAC Electricity Consumption Reduction in Commercial Buildings.” IEEE Transactions on Sustainable Computing, 2019.

多任務可以應用於樓宇節能中。冷機是樓宇中的耗能大戶。冷機能效預測與管理,預測冷機負荷決策的能效比並優化冷機負荷決策,一直是樓宇智能最重要的研究問題之一。本研究觀測到,在冷機決策能效預測中,不同邊緣項目的設備型號和工況不同會導致最終需求的模型不同。這種情況下僅採用雲端單一模型的做法容易導致精度下降和決策失誤。本工作研發了一種邊雲協同的多任務冷機負荷決策框架(圖3),在利用現有端邊節點且不部署額外硬件的情況下,較當前工業界方法節能30%以上。

圖3 邊雲協同的冷機負荷決策框架

基於多任務的空調舒適度預測

Zheng, Z., Dai Y., Wang D., “DUET: Towards a Portable Thermal Comfort Model.” In Proceedings of ACM BuildSys (Core rank A), 2019.

Yang, L., Zheng, Z., Sun, J., Wang, D., & Li, X. A domain-assisted data driven model for thermal comfort prediction in buildings. In Proceedings of ACM e-Energy. 2018.

空調舒適度預測是樓宇智能歷史長河中重要的研究課題之一。目前的舒適度預估方法通常要求額外的傳感器或者用戶反饋等人工干預,這使得規模化本身成為難題。基於機器學習方法的空調舒適度預測已被證明可以減少額外的人工干預。但在不同邊緣場景下,樓宇製冷類型、安裝傳感器類別等因素會使得雲上單一通用模型出現嚴重錯誤。本研究提出了一種多任務的方法進行空調舒適度的預測,在精度上較機理模型和單任務模型分別提升39%和31%。

邊緣自適應任務定義

基於以上項目,讀者可以了解到基於多任務的邊緣智能算法、系統與應用。值得注意的是,在使用多任務之前,首先需要回答任務如何定義和劃分的問題,如確定在一個應用內不同項目所需機器學習模型的數量以及各個模型的應用範圍。該方法目前通常只能由數據科學家和領域專家人工進行干預,自動化程度低,難以規模化複製。因此,邊緣自動定義機器學習任務是一個懸而未決但又重要的難題。

為了在邊緣各種場景自適應地定義機器學習預測任務,華為雲邊緣雲創新Lab近日發表了研究論文《MELODY: Adaptive Task Definition of COP Prediction with Metadata for HVAC Control and Electricity Saving》。該研究提出了一種包含任務定義的多任務預測框架(MELODY),其中任務定義能夠自適應地定義並學習複數能效比預測任務。

MELODY是第一個根據各種邊緣場景自適應定義能效比預測任務的方法。本研究工作為尋求自動有效的邊緣機器學習方法的研究人員和應用開發人員提供了一種有吸引力的機制,特別適用於對於元數據多樣化但數據樣本不足的複雜系統。MELODY的關鍵思想是使用元數據動態劃分多個任務,論文提出了元數據的數學定義以及提取元數據的2種來源和方法。

該團隊在實際應用中評估該方案的性能:基於2個大型工業園區中的8座建築物中9台冷機進行4個月實驗。實驗結果表明,MELODY解決方案優於最新的能效比預測方法,並且能夠為兩個園區每月節省252 MWh的電量,較當前建築中冷水機的運行方式節省了35%以上的能源。

MELODY論文已獲ACM e-Energy 2020接收:

Zimu Zheng,Daqi Xie,Jie Pu,Feng Wang. MELODY: Adaptive Task Definition of COP Prediction with Metadata for HVAC Control and Electricity Saving. ACM e-Energy 2020. Australia.

ACM e-Energy 屬於ACM EIG-Energy Interest Group、計算機與能源交叉的旗艦會議。

1、論文接受率23.2%,歷年接受率在20%左右;

2、與CCF-A的Ubicomp; CCF-B的ECAI、TKDD H5-index相同;

3、55位評審程序委員會成員中包括Andrew A. Chien、Klara Nahrstedt、Prashant Shenoy等8位ACM/IEEE Fellow(約15%);

4、評審程序委員會成員來自IBM研究院、伊利諾伊大學香檳分校、劍橋大學、華盛頓大學、普渡大學、馬薩諸塞大學阿默斯特分校、西蒙菲沙大學、南洋理工大學、清華大學、香港理工大學等國際知名校企;

5、與CCF-A的STOC、ISCA、PLDI;CCF-B的IWQos、SIG Metric、COLT、HPDC、ICS、LCTES、SPAA等同屬ACM Federated Computing Research Conference (FCRC)系列的13個會議中,ACM FCRC頂會系列由Google、微軟、IBM、華為、arm、Xilinx等國際知名企業贊助。

能效比預測

基於冷機的暖通空調系統通常用於商業建築中,消耗的電力占建築物總用電量的40%至70%,這種消耗量主要由暖通空調系統的消耗量決定。商業建築物支付的電費(其中大部分歸於暖通空調系統)通常位於組織運營支出的前三名。這種趨勢給設施管理者帶來了巨大的壓力,他們需要通過減少與暖通空調系統相關的電力消耗來提高建築的能源利用效率。

暖通空調的主要消耗來自冷機(見圖4)。典型的冷機負荷控制的有效性在很大程度上取決於冷機運行時的性能,即在不同的冷負荷條件下的能效比。能效比是衡量冷機能效的指標,指的是在單位輸入功率消耗下的輸出冷量。能效比通常大於1,值越大,意味着效率越高。在實踐中,設施管理人員通常在冷機部署到建築物期間,在首次測試和調試冷水機組時衡量能效比的初始信息,並用該初始信息來執行冷機負荷控制。初始信息測試時通常將冷量負荷視為唯一參數。然而,這些初始信息無法捕獲實際參數的影響,並且已被近期研究證明是不精確的。

圖4 冷機示意圖

本研究以能效比預測問題作為個例研究。能效比高度依賴於多種因素,例如工況、冷量需求、設備老化、天氣等。為了在冷水機組中捕獲這些因素,現有工作已經提出採用數據驅動方法。能效比預測問題可以看做是在訓練階段學習一種被稱為模型的“公式”,該公式在推理階段能夠輸出具有給定特徵的能效比。

自適應任務定義

現有方法通常假定預測任務的配置,比如同一應用下的預測模型的數量和預測模型的應用範圍,是由數據科學家或領域專家定義和固定的。下文比較三種被廣泛接受的設定:單任務設定、多任務設定和專家輔助的多任務設定。

單任務設定

一個最典型的、被廣泛接受的預測任務配置方法是基於固定的單任務設定:這意味着將所有數據集作為一個整體合併在一起,並訓練單個預測模型。研究人員可以使用任何機器學習算法(例如SVM、神經網絡、Boosting等)來學習這種模型,並在任何場景下的推理階段都應用訓練出的這單個模型。

單任務設定假設對於同一應用下不同項目內不同的數據集,單個模型應足以描述所選特徵和能效比之間的關係。但是,這種假設可能並不總是成立。

比方說有兩個園區採用了兩種類型的冷水機:園區H使用了特靈CVHG1100冷水機和園區J使用了開利W3C100冷水機,那麼應根據冷水機的型號調整在特徵和能效比之間的熱力學模型。邊緣用戶往往也期待看到應用到兩個邊緣項目的模型有所不同:即使兩種冷水機輸入相同的水溫等特徵值,輸出的能效比也應不同。但如果將兩個數據集合併在一起並訓練同一個能效比模型,通常很難在沒有人工干預的情況下確保這一點。

論文作者過去的研究還表明,除了不同邊緣項目採用冷機型號不同可能導致模型不同外,可能導致模型不同的例子還包括:不同項目採用的工況和參數配置不同、不同項目採用的傳感器種類不同、不同季節採用特徵不同等(篇幅原因不再贅述,感興趣的讀者可以參考文章開頭提及的研究團隊歷史工作)。不同邊緣場景訓練出的模型應用範圍可能是迥乎不同的。所以對於不同的場景都採用單任務設定並非總是最佳選擇,這可能在實踐中引發重大錯誤,尤其是某些邊緣智能項目中訓練樣本的大小不足以在大量特徵中自動將場景彼此區分的情況。

多任務設定

但目前預測任務的配置,例如所需模型的數量以及模型的應用範圍,仍然是一個開放性問題。為了深入研究此問題,該團隊進一步驗證多任務設定而非單任務設定,也即觀察多個模型在多個測試集上的性能。在一個實際建築物中,使用了從冷機1到冷機5的訓練數據集訓練了5個模型(以下稱為M1 – M5)。然後在另外5個測試數據集(T1 – T5)的不同場景中測試了5個模型的性能。實驗及其結果分別如圖5-1、5-2所示。

圖5-1 複數冷機訓練模型在不同冷機測試集下的實驗示意圖

圖5-2 複數冷機訓練模型在不同冷機測試集下的預測準確率和樣本採集時間對比結果

觀察結果显示,

1)精度

儘管是基於不同的數據集進行訓練,但是冷機1的模型在冷機2和冷機3的測試集上效果很好,而在冷機4和冷機5的測試集上卻導致嚴重錯誤。對於冷機2到冷機5的模型可以看到類似的觀察結果。這是因為冷機1到冷機3來自同一種冷機型號,而冷機4和冷機5是另一種型號。

2)樣本採集時間

如果按冷機來劃分任務,每個冷機任務至少需要81天的樣本。但如果按照型號劃分為2個任務,每個型號任務僅需30天的樣本。這是因為每個型號任務包含多台冷機採集的數據。

根據上述精度和樣本採集時間的結果,與其考慮5個冷機從而定義5個冷機任務,在這個數據集下不如考慮2個型號(冷機1-3和冷機4-5)從而定義2個型號任務,在上述例子中可以降低63%左右的樣本採集時間,同時提升近10%的精度。

專家輔助的多任務設定

實際上,不僅冷機型號,隨時間變化的環境(例如,天氣條件)和工況(例如,供水溫度)也可以導致能效比模型的變化。藉助領域專家的知識,可以在構建的環境中定義固定的任務,並將這些固定的任務應用於不同的建築中。

例如,基於建築環境研究中的領域專業知識,該團隊最近一項工作在三座建築物中根據工況給出了固定的50個任務,用於多任務冷機能效比預測;該團隊最近另外一項工作根據季節和製冷類型在160座建築物中給出了固定的4個任務,以進行多任務熱舒適性預測。

但是,所需模型的數量及其應用範圍可以根據不同的邊緣項目場景而變化,而領域專家的配置很難跟隨不同邊緣項目動態擴展。例如,在一個建築物的少量數據集中,最好有3個任務,即訓練3種不同的模型進行能效比預測。但是在另一個包含1000座建築物的大型數據集中,最好有75個任務。在邊緣場景手動定義要預測的機器學習任務通常會導致成本過高或準確性降低,尤其是當任務隨項目和時間而動態變化時。因此,有必要針對不同場景自適應地定義任務。

MELODY

本研究工作旨在解決自適應任務定義問題,也即不同場景下自動化定義不同的任務,例如,在不同場景中確定需要使用的模型數量以及模型的應用範圍等。該團隊遇到三個主要挑戰,並提出了使用自適應任務定義方法的多任務預測框架(MELODY)。

挑戰1:當前項目的目標未知,而且通常更糟糕的是,可能的任務候選集也未知。

MELODY通過提出任務挖掘解決了第一個挑戰。它基於諸如任務森林等新穎結構和算法來自適應地定義任務,參見圖6。這使得MELODY可規模化到眾多建築和環境的能效比預測。

圖6 任務森林的例子:數據表示模型訓練樣本,屬性表示模型應用範圍;節點表示子任務,包括數據、屬性和模型(若有);森林的每個根節點,也即每棵樹的頂點,表示各個子任務合併成的一個任務。對任務森林初始化和維護等具體實現和算法複雜度等證明,有興趣的讀者可以閱讀論文附錄。

挑戰2:標誌能效比模型應用範圍的屬性未知,同時此類屬性的來源也在研究中。

MELODY通過使用元數據作為任務屬性的來源來解決第二個挑戰。

元數據由領域專家定義,用於建築管理系統的日常控制。例如,傳感器的名稱和建築物的類型是元數據。在MELODY框架中,該團隊提出了從數據庫的兩個來源中提取兩種元數據的方法。

元數據包含潛在領域信息,藉助這些信息,能夠自適應地提取具有領域知識的任務,併為自動和強大的任務定義打開了方便之門,如圖7所示。

圖7 基於元數據提取的任務定義(具體實現請參見論文)

挑戰3:任務組合數量隨屬性數量指數增長;因此,冷機樣本不足以為所有組合訓練模型。

MELODY通過利用多任務遷移學習克服了第三個挑戰。在多任務優化中,學習任務可以使用來自其他不同任務的知識,從而減少數據量的需求。

多任務評估

本研究工作通過將其應用於實際數據來評估方案的性能,在2個大型工業園區中的8座建築物中9台冷機進行4個月時間的實驗。園區情況可參見圖8。

圖8 2個大型工業園區中的8座建築物及其冷機信息

表1 任務定義輸出結果

表1显示了通過任務定義算法挖掘出的任務的總體信息,在Park J和Park H中發現了兩組不同的任務集合。觀察显示不同項目模型的數量和使用模型時的場景都不同。藉助五分鐘的間隔數據,可以在Park J中挖掘出33個任務,這些任務模型的應用範圍主要根據冷機額定功率和平均濕度的來判斷。藉助一小時的時間間隔數據,Park H中僅有2個任務,應用範圍需要通過額定功率和額定製冷量來判斷。可以發現每個任務中的樣本量很小。 對於總共35個任務,有13個任務的樣本數少於100,其餘22個任務的樣本數少於1000。

研究比較了幾種應用於冷機能效預測的典型方法:

(1)工業界當前方法:初始配置文件(IP)利用安裝時測量的初始配置文件來估算未來的能效比,是目前工業界正在使用的方法。

(2)學術界常用方法:單任務學習(STL)通過將來自每個數據集的所有任務的數據匯總在一起來學習一個模型;

(3)近期研究工作:關於數據源的獨立多任務學習(IMTL),它獨立於數據源學習每個任務。例如,針對9個冷機固定9個任務,而無需在任務之間共享任何樣本或知識;

(4)近期研究工作:具有領域知識的多任務學習(MTL),它學習具有由領域知識定義的任務聚類。例如,固定的50個任務,其中10個負載比和5個冷機。

表2 各方法錯誤率提升

表2結果显示,MELODY的任務定義可以比STL(單任務方法)有所提升。 但是,不正確的任務定義(即IMTL和MTL)對比單任務方法未能有所提升。這主要是因為與在不同數據集中(如MELODY)使用自適應任務的方法相比,IMTL和MTL在劃分任務後會生成較小的數據集,這導致部分任務內缺乏訓練樣本。當任務數量隨着屬性數目和時間推移而增加時,效果變得更差,因為任務遷移關係變得越來越複雜。在這種情況下,任務之間共享知識變得更具挑戰性,並容易導致一種被稱為負遷移的影響,也即從不相關的源域到目標域共享知識而導致的錯誤。可以看到,MELODY能解決相關問題,從而使得結果優於最新的能效比預測方法,將能效比預測誤差率降低了18.18-61.70%,最終能夠在兩個園區上每月節省252 MWh的電量,與當前建築中冷水機的運行方式相比節省了36.75%以上的能源。

本文作者:鄭博士,華為雲邊緣雲創新Lab高級研究工程師,畢業於香港理工大學,主要研究方向是邊緣智能及AIoT。發表國際相關領域頂級會議及期刊 (TPDS、 IJCAI、 ICDCS、CIKM、TOSN、TIST等) 論文十餘篇,多次獲得最佳會議論文獎項,多次獲得關鍵技術突破、高價值專利和新服務孵化等華為傑出貢獻獎項。

華為雲邊緣雲創新Lab:願景是探索端邊雲協同關鍵技術,構建無所不在的、極致體驗的智能邊緣雲。聯合工業夥伴和學術機構,共同致力於研究邊緣雲創新技術、孵化邊緣雲創新應用、構建邊緣雲繁榮生態。研究方向包括大規模智能邊緣雲平台、邊雲協同AI、端邊雲協同渲染與視頻加速。目前已孵化上線華為邊緣計算平台IEF,並貢獻首個基於Kubernetes的雲原生邊緣計算平台KubeEdge,獲尖峰開源技術創新獎、最佳智能邊緣計算技術創新平台等多項獎項;孵化的業內首個邊雲協同增量學習工作流即將上線華為雲HiLens服務、IEF服務;學術上近2年已發表7篇邊雲協同AI、雲原生邊緣計算相關頂會論文,獲多項最佳論文和優秀論文獎項。

 

點擊關注,第一時間了解華為雲新鮮技術~

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

新北清潔公司,居家、辦公、裝潢細清專業服務

※別再煩惱如何寫文案,掌握八大原則!

※教你寫出一流的銷售文案?

※超省錢租車方案

FB行銷專家,教你從零開始的技巧