Scikit-learn: Python 로깅을 사용하여 장기 실행 작업에 대한 수렴 진행 수준 정보 보고

https://github.com/GaelVaroquaux/scikit-learn/tree/progress_logger 에서 이에 대한 작업이 시작되었습니다.

남은 일은 아마도 상당히 기계적인 작업일 것입니다.

새로운 Gradient Boosting 모듈에도 작업이 있습니다.

내 경험상 로깅은 실제로 사용하기가 쉽지 않으므로 -1입니다.

이 작업을 하는 사람이 있습니까?

기본적으로 STDOUT에 인쇄하는 로거를 추가하는 것은 어떻습니까? 상당히 간단해야 합니다. 맞죠?

이 문제는 2011년부터 공개된 문제인데 해결될지 궁금합니다. RFECV(https://github.com/scikit-learn/scikit-learn/blob/a24c8b464d094d2c468a16ea9f8bf8d42d949f84/sklearn/feature_selection/rfe.py#L273)에서 이 문제가 발생했습니다. 진행 상황을 인쇄하고 싶었지만 기본 상세 인쇄는 너무 많은 메시지를 인쇄합니다. 이 작업을 수행하기 위해 sys.stdout 를 원숭이 패치하고 싶지 않았으며 로거를 재정의하는 것이 간단하고 깨끗한 솔루션이 될 것입니다.

#8105 및 #10973과 같이 sklearn에서 실제 로그인을 통해 혜택을 볼 수 있는 다른 발행이 있습니다. 전반적으로 로깅은 sklearn에 큰 도움이 될 것이라고 생각합니다.

당신은 그것에 대해 작업을 환영합니다. 아마도 콜백 시스템이
벌채 반출

나는 지금 약간 바쁘지만 어떤 형태로든 sklean에서 사용자 정의 가능한 로깅을 지원합니다(비록 표준 파이썬 로깅을 선호하지만).

scikit-learn이 로깅을 사용하기 시작할 때 verbose=True 가 무엇을 의미하는지에 대한 논의가 있었습니까? 우리는 이것을 dask-ml에서 약간 다루고 있습니다: https://github.com/dask/dask-ml/pull/528.

라이브러리가 로깅 구성을 수행하지 않아야 한다는 점을 감안할 때 적절하게 로깅하도록 "응용 프로그램"(단지 스크립트 또는 대화식 세션일 수 있음)을 구성하는 것은 사용자의 몫입니다. 이것은 항상 올바르게 수행하는 것이 쉽지 않습니다.

https://github.com/dask/dask-ml/pull/528의 내 제안은 verbose=True 가 "나를 위해 일시적으로 로깅 구성"을 의미하는 것입니다. 컨텍스트 관리자를 사용하여 로깅을 구성 할 수 있으며 scikit-learn은 INFO 수준 메시지가 현재 동작과 일치하도록 stdout에 인쇄되도록 합니다.

일시적으로 핸들러 설정이 해당 설정과 관련되어 있음을 의미합니다.
추정기 또는 추정기 유형?

dask/dask-ml#528에서 내 제안은 verbose=True가 "나를 위해 일시적으로 로깅 구성"을 의미하는 것입니다.

이것은 좋은 균형인 것 같습니다. 로깅 모듈을 사용하는 것은 그다지 사용자 친화적이지 않습니다. 또 다른 "해킹"은 기본적으로 info 하는 것이지만 사용자가 verbose=True 하면 로그가 warning 로 올라갈 수 있습니다. 기본적으로 경고가 표시되기 때문에 작동합니다.

사용자가 더 많은 것을 요청할 때 특정 메시지의 수준을 변경하는 것 같아요
자세한 정보는 로깅 모듈의 의미와 정확히 반대입니다.
일하다. 그러나 로컬 핸들러는 경고에서 디버그로 변경될 수 있습니다.
자세한 내용이 증가함에 따라 스트림의 수준

@jnothman의 의견은 내 생각과 일치합니다. scikit-learn은 항상 메시지를 내보내고 verbose 키워드는 로거 수준과 처리기를 제어합니다.

그러나 로컬 핸들러는 경고에서 디버그로 변경될 수 있습니다.
자세한 내용이 증가함에 따라 스트림의 수준

좋아, 이것으로 가자. 현재 로깅 수준은 https://docs.python.org/3/library/logging.html#logging -levels입니다. 기본적으로 기본적으로 내보내지 않는 INFO 사용할 수 있습니다. verbose=1 일 때 핸들러 변경 정보 -> 경고 및 디버그 -> 정보가 있습니다. verbose>=2 설정하면 여전히 정보 -> 경고가 있지만 디버그 -> 경고도 있으며 추정기는 verbose>=2 를 "자세한 내용이 증가함에 따라 더 많은 디버그 메시지를 내보냄"을 의미하도록 해석할 수 있습니다. 이 의미는 추정기에 따라 다를 수 있습니다.

어떻게 생각하나요?

안녕하세요, 저는 이 문제에 관심이 많습니다. 저는 logging 대한 약간의 경험이 있으며 일부 합의와 계획에 도달하면 여기에서 개선 사항을 구현하는 데 도움을 주고 싶습니다.

여기에 언급된 아이디어를 요약하는 데 도움이 될 수 있습니다.

1. 콜백 패턴 사용
2. verbose 에 따라 메시지 수준 변경

    if verbose:
        logger.debug(message)
    else:
        logger.info(message)

1. 의 수준 변경 logger 에 따라 verbose

    if verbose:
        logger.selLevel("DEBUG")

1. 자세한 내용에 따라 DEBUG 수준의 핸들러 추가

    if verbose:
        verbose_handler = logging.StreamHandler()
        verbose_handler.setLevel("DEBUG")
        logger.addHandler(verbose_handler)

이 옵션에 대한 나의 견해:

옵션 1 또는 옵션 4가 가장 좋습니다.

• 옵션 1(콜백)은 가장 불가지론적이라는 점에서 좋습니다(사람들이 원하는 대로 기록할 수 있음). 그러나 메시징/상태 캡처 관점에서 유연성이 떨어질 수 있습니다. (콜백은 내부 루프 반복당 한 번 또는 한 번만 호출되지 않습니까?)
• 옵션 2, 여기에서 논의한 바와 같이 logging 라이브러리를 오용하고 있다고 생각합니다.
• 옵션 3은 작동하지만 logging 라이브러리를 사용하는 목적의 일부를 무효화한다고 생각합니다. sklearn이 logging 를 사용하는 경우 사용자는 logging 자체를 통해 자세한 정도를 조정할 수 있습니다(예: import logging; logging.getLogger("sklearn").setLevel("DEBUG") .
• 옵션 4는 아마도 가장 표준적일 것입니다. 문서는 NullHandler 이외의 라이브러리 코드에서 핸들러를 생성하지 _not_ 제안하지만 sklearn에 verbose 플래그가 있다는 점을 감안할 때 여기에서 의미가 있다고 생각합니다. 이 경우 로그 인쇄는 라이브러리의 "기능"입니다.

다섯 번째 옵션은 verbose 플래그를 제거하고 모든 곳에서 logging 를 사용하며 사용자가 logging API를 통해 자세한 정도를 조정할 수 있도록 하는 것입니다. 이것이 바로 logging 가 설계된 이유입니다.

@grisaitis 감사합니다! https://github.com/scikit-learn/scikit-learn/issues/17439 및 https://github.com/scikit-learn/scikit-learn/pull/16925#issuecomment -638956487에서 보다 최근의 관련 토론을 참조 하십시오 . (콜백 관련). 귀하의 도움은 대단히 감사하겠습니다. 주요 문제는 아직 어떤 접근 방식이 가장 좋을지 결정하지 못했다는 것입니다. :)

에스티메이터별 구성을 찾으면 자세한 정보 제거를 지원하겠습니다.
실망스럽고 임의의 장황한 숫자 값이 좋지 않습니다.
등을 문서화합니다. 클래스별 구성은 다음을 통해 처리됩니다.
여러 scikit-learn 로거 이름.

다섯 번째 옵션은 자세한 플래그를 제거하고 모든 곳에서 로깅을 사용하며 사용자가 로깅 API를 통해 자세한 정도를 조정할 수 있도록 하는 것입니다. 이것이 바로 로깅이 설계된 목적입니다.

에스티메이터별 구성을 찾으면 자세한 정보 제거를 지원하겠습니다.
실망스럽고 임의의 장황한 숫자 값이 좋지 않습니다.
문서화,

verbose 없애고 로깅 수준을 사용하는 것이 매우 좋을 것이라고 생각합니다. 내가 볼 수있는 유일한 단점은 로깅을 약간 덜 검색하게 만든다는 것입니다.

또한 로깅이 제공하는 한 가지는 문자열뿐만 아니라 각 로깅 메시지에 추가 정보를 첨부할 수 있다는 것입니다. 그래서 유용한 것들의 전체 딕셔너리. 따라서 학습 중 손실을 보고하려면 그렇게 하고 숫자 값을 저장할 수 있습니다. 또한 숫자 값을 숫자로 저장하고 이를 사용하여 logger.debug("Current loss: %(loss)s", {'loss': loss}) 와 같은 사용자 친화적인 문자열 형식을 지정할 수 있습니다. 나는 그것이 일반적으로 매우 유용하다는 것을 알았고 sklearn이 그것을 공개한다면 좋아할 것입니다.

모듈 또는 추정기 수준 로거를 갖는 것은 지금으로서는 약간 과하다고 생각하며 나중에 확장할 수 있는 간단한 것으로 시작해야 합니다.
또한 우리가 무엇을 하든 사용자가 현재 동작을 합리적으로 쉽게 재현할 수 있도록 해야 합니다.

로깅과 joblib는 어떻게 상호 작용합니까? 로깅 수준은 유지되지 않습니다(예상대로).

import logging
logger = logging.getLogger('sklearn')
logger.setLevel(2)

def get_level():
    another_logger = logging.getLogger('sklearn')
    return another_logger.level

results = Parallel(n_jobs=2)(
    delayed(get_level)() for _ in range(2)
)
results

```
[0, 0]

But that's probably not needed, since this works:
```python
import logging
import sys
logger = logging.getLogger('sklearn')
logger.setLevel(1)

handler = logging.StreamHandler(sys.stdout)
logger.addHandler(handler)


def log_some():
    another_logger = logging.getLogger('sklearn')
    another_logger.critical("log something")

results = Parallel(n_jobs=2)(
    delayed(log_some)() for _ in range(2)
)

솔직히, 나는 이것이 어떻게 작동하는지 완전히 확신하지 못합니다.

stdout과 stderr은 모두 jupyter btw에 표시되지 않습니다.

내 꿈: 한 줄로 현재 동작의 근사치를 얻을 수 있지만 대신 진행률 표시줄이나 플롯 수렴을 쉽게 사용할 수 있습니다.

re verbose: verbose를 사용하지 않는 것이 더 깨끗할 수 있지만 verbose를 사용하지 않고 추정기 수준 로깅이 없으면 하나의 추정기를 기록하지만 다른 것은 기록하지 않는 것이 조금 더 까다로워집니다. 그래도 사용자가 메시지를 필터링하도록 하는 것이 좋다고 생각합니다.

안녕하세요, 친절한 답변과 정보 감사합니다. 나는 다른 문제를 읽고 몇 가지 생각이 있습니다.

joblib 는 까다로울 것입니다. 그래도 몇 가지 아이디어가 있습니다.

@amueller 매우 이상합니다. 나는 당신의 예를 재현했습니다. 가지와 작업 할 concurrent.futures.ProcessPoolExecutor 내가 생각하기에, joblib 용도를 ...

joblib 가 logging 의 상태를 파괴하는 것 같습니다. 어떤 joblib 전문가가 무슨 일이 일어날 수 있는지에 대한 아이디어가 있습니까?

import concurrent.futures
import logging
import os

logger = logging.getLogger("demo🙂")
logger.setLevel("DEBUG")

handler = logging.StreamHandler()
handler.setFormatter(
    logging.Formatter("%(process)d (%(processName)s) %(levelname)s:%(name)s:%(message)s")
)
logger.addHandler(handler)

def get_logger_info(_=None):
    another_logger = logging.getLogger("demo🙂")
    print(os.getpid(), "another_logger:", another_logger, another_logger.handlers)
    another_logger.warning(f"hello from {os.getpid()}")
    return another_logger

if __name__ == "__main__":
    print(get_logger_info())

    print()
    print("concurrent.futures demo...")
    with concurrent.futures.ProcessPoolExecutor(2) as executor:
        results = executor.map(get_logger_info, range(2))
        print(list(results))

    print()
    print("joblib demo (<strong i="17">@amueller</strong>'s example #2)...")
    from joblib import Parallel, delayed
    results = Parallel(n_jobs=2)(delayed(get_logger_info)() for _ in range(2))
    print(results)

어떤 출력

19817 another_logger: <Logger demo🙂 (DEBUG)> [<StreamHandler <stderr> (NOTSET)>]
19817 (MainProcess) WARNING:demo🙂:hello from 19817
<Logger demo🙂 (DEBUG)>

concurrent.futures demo...
19819 another_logger: <Logger demo🙂 (DEBUG)> [<StreamHandler <stderr> (NOTSET)>]
19819 (SpawnProcess-1) WARNING:demo🙂:hello from 19819
19819 another_logger: <Logger demo🙂 (DEBUG)> [<StreamHandler <stderr> (NOTSET)>]
19819 (SpawnProcess-1) WARNING:demo🙂:hello from 19819
[<Logger demo🙂 (DEBUG)>, <Logger demo🙂 (DEBUG)>]

joblib demo (<strong i="21">@amueller</strong>'s example #2)...
19823 another_logger: <Logger demo🙂 (WARNING)> []
hello from 19823
19823 another_logger: <Logger demo🙂 (WARNING)> []
hello from 19823
[<Logger demo🙂 (DEBUG)>, <Logger demo🙂 (DEBUG)>]

메인 프로세스의 메인 로거에 로깅 메시지를 보내도록 joblib가 생성하는 프로세스를 구성해야 한다고 생각합니다. 그러면 메인 프로세스에서만 로깅을 제어할 수 있습니다. 이것 또는 이것 과 같은 것 . 따라서 로깅 큐 싱크와 소스가 있으며 함께 묶을 수 있습니다. 우리는 클러스터에서 이것을 사용하여 모든 컴퓨터의 모든 작업자의 모든 로깅을 중앙 위치로 보내 사용자의 컴퓨터에 표시합니다.

@mitar 동의합니다. 그게 최선의 선택일 수 있다고 생각합니다. (반드시 네트워크 기반 큐는 아니지만 프로세스 간 통신 큐)

저는 실제로 logging 의 QueueHandler / QueueListener 를 사용하여 예제를 코딩하고 있으며 joblib 및 concurrent.futures 로 테스트합니다. 여기에서 따를 것입니다.

다른 제안도 좋아합니다.

또한 로깅이 제공하는 한 가지는 문자열뿐만 아니라 각 로깅 메시지에 추가 정보를 첨부할 수 있다는 것입니다. 그래서 유용한 것들의 전체 딕셔너리. 따라서 학습 중 손실을 보고하려면 그렇게 하고 숫자 값을 저장할 수 있습니다. 또한 숫자 값을 숫자로 저장하고 이를 사용하여 logger.debug("Current loss: %(loss)s", {'loss': loss}) 와 같은 사용자 친화적인 문자열 형식을 지정할 수 있습니다. 나는 그것이 일반적으로 매우 유용하다는 것을 알았고 sklearn이 그것을 공개한다면 좋아할 것입니다.

extra 매개변수와 사용자 정의 핸들러 클래스를 사용하여 가우스 혼합 모델링의 시각화를 구현했습니다. 상태를 전달하고 사용자가 상태를 처리하는 방법을 결정하도록 하는 데 매우 훌륭하게 작동합니다.

또한 내가 위에서 알아차린 joblib 의 특이점을 다시 ... 나는 그것을 범위를 벗어나 있는 그대로 받아들일 것입니다. 어쨌든 대기열 기반 디자인이 가장 유연할 것입니다.

내가 생각할 수 있는 QueueHandler 사용의 유일한 제한 사항은 extra 상태( logger.debug("message", extra={...} )가 extra dict가 큐에 대해 직렬화 가능해야 한다는 것입니다. 그래서 numpy 배열이 없습니다. :/ 다른 문제는 생각할 수 없지만

저는 실제로 지금 QueueHandler / QueueListener를 사용하여 예제를 코딩하고 있습니다.

예, 소켓을 통한 전송이 언제 차단되는지 알 수 없고 로깅 차단으로 인해 모델 속도를 늦추고 싶지 않기 때문에 항상 대기열 처리기를 사용해야 합니다.

또한 extra 를 사용할 필요조차 없습니다. 나는 logger.debug("message %(foo)s", {'foo': 1, 'bar': 2}) 가 효과가 있다고 생각합니다.

예, 소켓을 통한 전송이 언제 차단되는지 알 수 없고 로깅 차단으로 인해 모델 속도를 늦추고 싶지 않기 때문에 항상 대기열 처리기를 사용해야 합니다.

joblib 케이스의 경우 QueueHandler / QueueListener 를 구현했다면 프로세스 풀에 어떤 상태를 전달해야 할까요? 그냥 queue , 맞죠?

또한 extra 를 사용할 필요조차 없습니다. 나는 logger.debug("message %(foo)s", {'foo': 1, 'bar': 2}) 가 효과가 있다고 생각합니다.

네 감사합니다. 텍스트로 변환하지 않고 상태를 기록하는 것도 유용합니다. 예를 들어 extra 에 numpy 배열을 포함하고 jupyter 노트북의 사용자 지정 로깅 핸들러를 사용하여 실시간 데이터 시각화(시각적 로깅)를 수행합니다. 이것은 sklearn에서 매우 훌륭할 것이며 @rth 가 콜백으로 유사한 작업을 수행한 것처럼 보입니다.

joblib의 경우 QueueHandler / QueueListener를 구현했다면 프로세스 풀에 어떤 상태를 전달해야 할까요? 그냥 대기열, 그렇지?

나도 그렇게 생각해. 프로세스 경계를 ​​넘어 이것을 사용하지 않았지만 다중 처리에 대한 문서화된 지원이 있는 것 같으므로 joblib에서도 작동해야 합니다. 동일한 프로세스 내에서 QueueHandler/QueueListener를 사용하고 있습니다. 로깅 전송에서 로깅 쓰기를 분리합니다. QueueHandler -> QueueListener -> 중앙 로깅 서비스로 보내기도 마찬가지입니다. 그러나 문서에서 다중 처리 대기열을 통해 작동할 수 있는 것처럼 보입니다.

나는 그것을 텍스트로 변환하지 않고 상태를 기록하는 것도 유용하다는 것을 알았습니다.

예. 내가 말하려는 것은 extra 를 사용할 필요가 없지만 dict를 직접 전달한 다음 메시지 형식화를 위해 해당 dict의 몇 가지 항목만 사용한다는 것입니다(형식 문자열에 사용되는 항목이 결정된다는 점에 유의하십시오. sklearn 라이브러리가 아닌 sklearn 라이브러리 사용자에 의해 예상하지 못한 서식을 지정하도록 항상 구성할 수 있으므로 정확히 텍스트로 변환되는 내용은 실제로 sklearn 제어 하에 있지 않습니다. extra 모든 값은 메시지 형식에도 사용할 수 있습니다. 그래서 extra 가 얼마나 유용한지 잘 모르겠습니다. 그러나 나는 또한 우리가 그것을 사용해서는 안된다고 말하는 것이 아닙니다. 왼쪽에 있는 문자열의 페이로드와 추가 사항이 훨씬 더 명확합니다. 그래서 우리는 둘 다 사용할 수도 있습니다. 나는 단지 이 대안이 알려져 있는지 확인하고 싶었습니다.

@grisaitis 참고로 커밋에서 이름을 언급하면 ​​커밋으로 무엇이든 할 때마다(예: 리베이스 또는 병합 또는 푸시) 그 사람은 이메일을 받기 때문에 일반적으로 권장하지 않습니다 ;)

죄송합니다 안드레아스! 😬 창피하네요... 그냥 문서화 잘 된 커밋을 하려고 했던 것 뿐이에요 ㅋㅋㅋㅋ 앞으로는 피할 것입니다.

그 리포지토리에서 QueueHandler / QueueListener 콤보를 사용하여 joblib 에서 로깅이 작동하는 방법을 알아냈습니다. 잘 작동하는 것으로 보입니다.

첫 번째 단계로 joblib 가 사용되는 sklearn의 일부에서 해당 접근 방식으로 로깅을 구현합니다. 아마도 앙상블 모델 중 하나일 것입니다. 새로운 PR을 엽니다.

joblib의 경우 QueueHandler / QueueListener를 구현하면

예, 다중 처리의 경우 로깅 모듈과 콜백을 사용하는 경우 모니터링 스레드(여기서는 QueueListener )를 시작/중지해야 할 것 같습니다(https://에서 다중 처리가 있는 콜백의 대략적인 예). github.com/scikit-learn/scikit-learn/pull/16925#issuecomment-656184396)

그래서 위에서 내가 "작동"한 유일한 이유는 공유 리소스 인 stdout에 인쇄되었고 print 는 python3 또는 이와 유사한 것에서 스레드로부터 안전하다는 것입니다.

그래서 위에서 내가 "작동"한 유일한 이유는 공유 리소스 인 stdout에 인쇄되었고 인쇄는 python3 또는 이와 유사한 것에서 스레드로부터 안전하다는 것입니다.

인쇄는 스레드로부터 안전하지 않습니다. 그들은 단지 동일한 파일 설명자로 인쇄합니다. 아마도 더 오랜 시간 동안 실행하면 메시지가 때때로 인터리브되고 행이 혼동되는 것을 볼 수 있습니다.