당신의 우상 수리: 오픈 소스 소프트웨어를 당신의 팀처럼 일하게 하세요

팀에서 사용하는 핵심 소프트웨어 패키지 1)이 오픈소스이고 2)제대로 작동하지 않을 때
네가 그것을 원하거나 기대하면 이렇게 수리해라!당신의 팀은 더욱 효율적일 것입니다. 당신은 더 많은 것을 얻을 수 있을 것입니다
그것의 작업 원리를 익히면 보답을 가져올 수 있다.

사례 연구: Apache Airflow

나의 업무 직책 중의 하나는 나의 데이터 엔지니어 동료들이 그들의 일을 더욱 효율적으로 완성하도록 돕는 것이다
ETL 파이프를 건조하고 유지보수합니다.우리가 사용하는 도구는 Apache Airflow 이다. 이것은 우리가 파이프를 정의하고 스케줄링할 수 있게 한다.마땅히
다음 그림과 같이 DAG 목록에 파이프가 생성되었습니다.

우리 그룹에서 이 목록은 페이지를 나누기에 충분할 정도로 훨씬 길다(페이지당 100개의 DAG)
기본 설정은 공기 흐름이며 일부 설정은 닫기(첫 번째 열)로 전환됩니다.

도전+패치

도전: 내 달리기 다그는 어디에 있습니까?

"DAG Runs"밑에 밝은 초록색 동그라미가 보이면.example_branch_dop_operator_v3, 3 부 사본이 있음을 나타냅니다.
현재 실행 중인 DAG입니다.당신이 흥미를 가지고 있다고 상상해 보세요.
수백 개의 DAG 목록에서 DAG 실행: DAG의 여러 페이지를 수동으로 읽는 것을 의미합니다.
밝은 녹색 동그라미를 찾거나 검색하세요.우리 팀에게는
공기 흐름 그래픽 사용자 인터페이스를 살펴보십시오. 실행 중인 DAG가 맞습니다.

솔루션: 실행을 통한 DAG 정렬

이것이 바로 우리가 기류 코드 라이브러리를 깊이 이해하는 곳이다.나는 장난스럽게 이 일과 뒤이어 발생한 일을 했다
라이브 Airflow 웹 서버의 site-packages/airflow 디렉토리에 있습니다.
미안합니다.
우선, 나는 마우스 오른쪽 단추로 그 중 밝은 녹색의 "running DAG"동그라미를 클릭하고 "inspect"를 진행한다
원소, 이것은 나로 하여금 최종적으로 jQuery를 찾게 했다. 이것은 모든
DAG의 "DAG 실행"에는 세 개의 원이 있습니다. 각 원은 "state"와
계수.이 물체는 fetch를 통해 기류 뒤쪽, 즉 단점으로 얻는다
호출/dag_stats.fetch 호출에 대한 응답에서 우리는 어떤 방식으로든 DAG를 정렬하기를 희망한다.그러나
DAG 목록 페이지 다음에 호출/dag_stats 노드
과부하가 걸려서 우리는 작은 수술을 해야 한다.
우선, 우리는 Airflow의 코드 라이브러리에서 이 단점을 찾을 수 있다. $ grep -r dag_stats airflow/ 단서
미국 here.payload 이 함수의 끝은 사전인 것 같고, 키는dag_ids, 그 값은 사전 목록이며, 모든 사전은 (기타 제외) 포함된다
사물) 가능한 각 DAG 상태의 상태, 계수 및 색상저희가 알고 있어요.
GUI에서 세 개의 원을 지정하는 세 가지 가능한 DAG 상태입니다.
그렇다면 모든 DAG를 보여주기 전에 DAG 상태 사전을 어떻게 가져와서 정렬할 수 있습니까?응, 그거
제가 추적한 jQuery는 이름입니다.
dags.html . 단점이 무엇이든
이 틀은 바로 우리가 원하는 것이다.역시 동일views.py 모듈에서/dag_stats 우리는 this (즉 "/" 단점을 가지고 있다.그 중 하나는 복잡한 매개 변수화 설정이 있다
SQLAlchemy 쿼리는 템플릿의 DAG를 가져오고, 필터링하고, 정렬합니다.대신
이 단점의 주체에 복잡한 (효율이 높을 수 있지만) 다중 테이블 조회를 추가합니다.
우리는 단지 /dag_stats 단점에서 모든 코드를 복사하고 정렬에 따라 DAG를
렌더링하기 전에: dags = sorted(dags, key=lambda dag: (-payload[dag.dag_id][1]['count'], dag.dag_id)) 추정한 바와 같이 [1] 인덱스는'실행'상태 사전이다... 에 의하여
GUI에 표시되는 순서입니다.
이러한 코드 변경, 코드 한 줄에 기존 코드에 대한 위치 변경, 실행 중인 모든 DAG
우선 열거!

도전: 나의 DAG 마지막 달리기는 언제??

이것은 이상한 현상이다. 어떤 원인에서 기류는'마지막'중의 마지막을 나타낸다execution_date"실행"열, 실제 마지막 실행 날짜/시간을 알고 싶으면 마우스를
날짜/시간 옆에 표시되는 작은 정보 간격입니다.우리 팀으로 말하자면, 이것은 많은 것을 초래할 것이다.
대다수가 아니었다면, DAG는 사실보다 24시간 빠른'마지막 달리기'날짜를 표시했을 것이다.이로 인해
디버깅할 때 골치 아픈 시도와 불필요한 시도(DAG 코드, 기류 스케줄러 등)를 많이 했습니다.
- 사용자 경험 부족, 시간 낭비!
이 값들을 교환해 주시겠습니까?검색 중
dags.html
우리는'마지막 운행'의 주석이 좋은 칸을 보았다. 우리의 목표.last_run.start_date last_run.execution_date 우리가 교환하고 싶은 두 개의 값으로 보인다.
그들은 라벨을 교환했다.
이게 해결이야!우리가 예상한 바와 같이, 실제 마지막 운행 날짜가 나타난다
먼저 일어나다.

도전: CRON이라고 할 줄 알아요?

DAG를 스케줄링하는 방법은 매개변수에 CRON 문자열을 제공하는 것입니다.schedule_interval . 공기 흐름 GUI가 DAG 일정을 표시하는 방식은
CRON 문자열을 표시합니다.그러나 우리 팀에서 모두가 CRON을 말하는 것은 아니다. 내가 그 중의 하나이다.
여러분, 저는 거의 매번 구글로 이 문자열을 검색합니다.더 중요한 것은 내가 한 장면을 상상할 수 있다는 것이다
그곳에서 비엔지니어가 DAG를 훔쳐보았지만 아무것도 수집하지 않았다. 예를 들어 0 0 * * *.
당연히 좀 더 인간적인 방식으로 이런 걸 보여줄 수 있을까요?빠른 구글 검색 Cron Descriptor , "cron 표현식을 인간이 읽을 수 있는 문자열로 변환하는Python 라이브러리"하면, 만약, 만약...
이를 우리 환경으로 가져오기 (from cron_descriptor import get_description 우리는 거의 읽을 수 있는 해결 방안을 얻었다. def convert_schedule_to_natural_language(cronstring): if dag.schedule_interval and not dag.schedule_interval.startswith('@'): try: dag.schedule_interval = get_description(dag.schedule_interval) except cron_descriptor.Exception.FormatException: pass return dag ... dags = [convert_schedule_to_natural_language(dag) for dag in dags] ... return self.render(... @hourly 등은 이미 인류가 읽을 수 있는 것이기 때문에 우리는 그것들을 상관하지 않는다.그리고 우리
각 DAG를 렌더링하기 전에 변환합니다schedule_interval.그래서
위 화면 캡처의 처음 두 간격은 오전 00:00 및 분당으로 번역됩니다.
따로따로좀 이상하지만, 많든 적든 가독성!

결론: 광범위하게 사용되는 도구를 최적화합니다!

전체적으로 말하자면, 이러한 변경은 CRON을 번역하는 가방을 찾는 데 약 75분이 걸렸다
문자열이 자연 언어로 변환됩니다.나는 다음 48분 동안 우리는 팀 전체에서 75분을 이길 것이라고 추측한다
시간그 후 이 모든 것이 팀 생산력을 증가시켰다.내 제안:
1) 여러 명이 사용하는 도구에서 이러한 기회를 발견할 때마다
정기적
2) 오후 또는 그 이상의 시간이 필요합니다.
이것은 천재일우의 기회이다.들고 있어!