Airflow ເປັນ​ເຄື່ອງ​ມື​ສໍາ​ລັບ​ການ​ສະ​ດວກ​ແລະ​ວ່ອງ​ໄວ​ການ​ພັດ​ທະ​ນາ​ແລະ​ການ​ຮັກ​ສາ​ຂະ​ບວນ​ການ​ການ​ປຸງ​ແຕ່ງ​ຂໍ້​ມູນ batch​

ສະບາຍດີ, Habr! ໃນບົດຄວາມນີ້ຂ້ອຍຕ້ອງການເວົ້າກ່ຽວກັບເຄື່ອງມືທີ່ດີສໍາລັບການພັດທະນາຂະບວນການປະມວນຜົນຂໍ້ມູນ batch, ສໍາລັບຕົວຢ່າງ, ໃນໂຄງສ້າງພື້ນຖານຂອງບໍລິສັດ DWH ຫຼື DataLake ຂອງທ່ານ. ພວກເຮົາຈະເວົ້າກ່ຽວກັບ Apache Airflow (ຕໍ່ໄປນີ້ເອີ້ນວ່າ Airflow). ມັນໄດ້ຖືກປະຕິເສດຢ່າງບໍ່ຍຸຕິທໍາຂອງຄວາມສົນໃຈໃນHabre, ແລະໃນສ່ວນຕົ້ນຕໍຂ້າພະເຈົ້າຈະພະຍາຍາມເຮັດໃຫ້ເຈົ້າຫມັ້ນໃຈວ່າຢ່າງຫນ້ອຍ Airflow ມີມູນຄ່າເບິ່ງໃນເວລາທີ່ເລືອກຕາຕະລາງສໍາລັບຂະບວນການ ETL / ELT ຂອງທ່ານ.

ກ່ອນຫນ້ານີ້, ຂ້າພະເຈົ້າໄດ້ຂຽນບົດເລື່ອງກ່ຽວກັບຫົວຂໍ້ຂອງ DWH ເມື່ອຂ້ອຍເຮັດວຽກຢູ່ທະນາຄານ Tinkoff. ຕອນນີ້ຂ້ອຍໄດ້ກາຍເປັນສ່ວນຫນຶ່ງຂອງທີມ Mail.Ru Group ແລະກໍາລັງພັດທະນາເວທີສໍາລັບການວິເຄາະຂໍ້ມູນໃນພື້ນທີ່ເກມ. ຕົວຈິງແລ້ວ, ຍ້ອນວ່າຂ່າວແລະວິທີແກ້ໄຂທີ່ຫນ້າສົນໃຈປາກົດ, ທີມງານຂອງຂ້ອຍແລະຂ້ອຍຈະເວົ້າທີ່ນີ້ກ່ຽວກັບເວທີຂອງພວກເຮົາສໍາລັບການວິເຄາະຂໍ້ມູນ.

Prologue

ດັ່ງນັ້ນ, ໃຫ້ເລີ່ມຕົ້ນ. Airflow ແມ່ນຫຍັງ? ນີ້ແມ່ນຫ້ອງສະຫມຸດ (ຫຼື ຊຸດຂອງຫ້ອງສະຫມຸດ) ເພື່ອພັດທະນາ, ວາງແຜນ ແລະ ຕິດຕາມຂະບວນການເຮັດວຽກ. ຄຸນນະສົມບັດຕົ້ນຕໍຂອງ Airflow: ລະຫັດ Python ຖືກນໍາໃຊ້ເພື່ອອະທິບາຍ (ພັດທະນາ) ຂະບວນການ. ມັນມີຂໍ້ດີຫຼາຍສໍາລັບການຈັດຕັ້ງໂຄງການແລະການພັດທະນາຂອງທ່ານ: ໂດຍເນື້ອແທ້ແລ້ວ, ໂຄງການ ETL ຂອງທ່ານແມ່ນພຽງແຕ່ໂຄງການ Python, ແລະທ່ານສາມາດຈັດມັນຕາມທີ່ທ່ານຕ້ອງການ, ໂດຍຄໍານຶງເຖິງສະເພາະຂອງໂຄງສ້າງພື້ນຖານ, ຂະຫນາດຂອງທີມງານແລະ. ຄວາມຕ້ອງການອື່ນໆ. ໂດຍວິທີທາງການ, ທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍ. ໃຊ້ຕົວຢ່າງເຊັ່ນ PyCharm + Git. ມັນ​ເປັນ​ສິ່ງ​ມະ​ຫັດ​ແລະ​ສະ​ດວກ​ຫຼາຍ​!

ຕອນນີ້ໃຫ້ເບິ່ງຫນ່ວຍງານຕົ້ນຕໍຂອງ Airflow. ໂດຍການເຂົ້າໃຈເນື້ອແທ້ ແລະຈຸດປະສົງຂອງພວກມັນ, ທ່ານສາມາດຈັດໂຄງສ້າງຂະບວນການຂອງທ່ານໄດ້ດີທີ່ສຸດ. ບາງທີຫົວຫນ່ວຍຕົ້ນຕໍແມ່ນ Directed Acyclic Graph (ຕໍ່ໄປນີ້ເອີ້ນວ່າ DAG).

DAG

A DAG ແມ່ນບາງການເຊື່ອມໂຍງທີ່ມີຄວາມຫມາຍຂອງວຽກງານຂອງທ່ານທີ່ທ່ານຕ້ອງການທີ່ຈະສໍາເລັດໃນລໍາດັບທີ່ກໍານົດໄວ້ຢ່າງເຂັ້ມງວດຕາມຕາຕະລາງສະເພາະ. Airflow ໃຫ້ການໂຕ້ຕອບເວັບທີ່ສະດວກສໍາລັບການເຮັດວຽກກັບ DAGs ແລະຫນ່ວຍງານອື່ນໆ:

DAG ອາດຈະເບິ່ງຄືວ່ານີ້:

ນັກພັດທະນາ, ເມື່ອອອກແບບ DAG, ວາງຊຸດຂອງຕົວປະຕິບັດການທີ່ວຽກງານພາຍໃນ DAG ຈະຖືກສ້າງ. ໃນທີ່ນີ້ພວກເຮົາມາຮອດຫນ່ວຍງານທີ່ສໍາຄັນອີກອັນຫນຶ່ງ: Airflow Operator.

ຜູ້ປະຕິບັດງານ

ຜູ້ປະກອບການແມ່ນນິຕິບຸກຄົນບົນພື້ນຖານຂອງຕົວຢ່າງວຽກທີ່ຖືກສ້າງຂຶ້ນ, ເຊິ່ງອະທິບາຍສິ່ງທີ່ຈະເກີດຂຶ້ນໃນລະຫວ່າງການປະຕິບັດຕົວຢ່າງວຽກ. Airflow ປ່ອຍອອກມາຈາກ GitHub ມີຊຸດຕົວປະຕິບັດການພ້ອມທີ່ຈະໃຊ້ແລ້ວ. ຕົວຢ່າງ:

• BashOperator - ປະຕິບັດການສໍາລັບການປະຕິບັດຄໍາສັ່ງ bash.
• PythonOperator - ຜູ້ປະກອບການສໍາລັບການໂທຫາລະຫັດ Python.
• EmailOperator — ປະ​ຕິ​ບັດ​ການ​ສໍາ​ລັບ​ການ​ສົ່ງ​ອີ​ເມວ​.
• HTTPOperator - ປະຕິບັດການສໍາລັບການເຮັດວຽກກັບຄໍາຮ້ອງຂໍ http.
• SqlOperator - ປະຕິບັດການສໍາລັບການປະຕິບັດລະຫັດ SQL.
• ເຊັນເຊີແມ່ນຕົວປະຕິບັດການສໍາລັບການລໍຖ້າເຫດການ (ການມາຮອດຂອງເວລາທີ່ກໍານົດໄວ້, ຮູບລັກສະນະຂອງໄຟລ໌ທີ່ຕ້ອງການ, ເສັ້ນໃນຖານຂໍ້ມູນ, ການຕອບສະຫນອງຈາກ API, ແລະອື່ນໆ).

ມີຜູ້ປະຕິບັດການສະເພາະເພີ່ມເຕີມ: DockerOperator, HiveOperator, S3FileTransferOperator, PrestoToMysqlOperator, SlackOperator.

ນອກນັ້ນທ່ານຍັງສາມາດພັດທະນາຜູ້ປະກອບການໂດຍອີງໃສ່ຄຸນລັກສະນະຂອງທ່ານເອງແລະນໍາໃຊ້ພວກມັນໃນໂຄງການຂອງທ່ານ. ຕົວຢ່າງເຊັ່ນ, ພວກເຮົາໄດ້ສ້າງ MongoDBToHiveViaHdfsTransfer, ຜູ້ປະກອບການສໍາລັບການສົ່ງອອກເອກະສານຈາກ MongoDB ໄປ Hive, ແລະຜູ້ປະກອບການຈໍານວນຫນຶ່ງສໍາລັບການເຮັດວຽກກັບ ກົດປຸ່ມ: CHLoadFromHiveOperator ແລະ CHTableLoaderOperator. ໂດຍພື້ນຖານແລ້ວ, ທັນທີທີ່ໂຄງການໄດ້ໃຊ້ເລື້ອຍໆລະຫັດທີ່ສ້າງຂຶ້ນໃນຄໍາຖະແຫຼງການພື້ນຖານ, ທ່ານສາມາດຄິດກ່ຽວກັບການສ້າງມັນເຂົ້າໄປໃນຄໍາຖະແຫຼງໃຫມ່. ນີ້ຈະເຮັດໃຫ້ການພັດທະນາງ່າຍຂຶ້ນ, ແລະທ່ານຈະຂະຫຍາຍຫ້ອງສະຫມຸດຂອງຜູ້ປະຕິບັດການຂອງທ່ານໃນໂຄງການ.

ຕໍ່ໄປ, ທຸກໆກໍລະນີເຫຼົ່ານີ້ຕ້ອງໄດ້ຮັບການປະຕິບັດ, ແລະຕອນນີ້ພວກເຮົາຈະເວົ້າກ່ຽວກັບຕົວກໍານົດເວລາ.

ຜູ້ຈັດຕາຕະລາງ

ຕົວກຳນົດເວລາໜ້າວຽກຂອງ Airflow ແມ່ນສ້າງຂຶ້ນ Celery. Celery ແມ່ນຫ້ອງສະຫມຸດ Python ທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດຈັດລະບຽບຄິວບວກກັບການປະຕິບັດວຽກທີ່ບໍ່ກົງກັນແລະແຈກຢາຍ. ໃນດ້ານ Airflow, ວຽກງານທັງຫມົດແມ່ນແບ່ງອອກເປັນສະນຸກເກີ. ສະນຸກເກີແມ່ນສ້າງດ້ວຍຕົນເອງ. ໂດຍປົກກະຕິ, ຈຸດປະສົງຂອງພວກເຂົາແມ່ນເພື່ອຈໍາກັດການເຮັດວຽກຂອງການເຮັດວຽກກັບແຫຼ່ງຫຼືເພື່ອພິມຫນ້າວຽກພາຍໃນ DWH. ສະນຸກເກີສາມາດຖືກຈັດການຜ່ານສ່ວນຕິດຕໍ່ເວັບ:

ແຕ່ລະສະນຸກເກີມີຂອບເຂດຈໍາກັດກ່ຽວກັບຈໍານວນຂອງສະລັອດຕິງ. ເມື່ອສ້າງ DAG, ມັນໄດ້ຖືກມອບໃຫ້:

ALERT_MAILS =  Variable.get("gv_mail_admin_dwh")
DAG_NAME = 'dma_load'
OWNER = 'Vasya Pupkin'
DEPENDS_ON_PAST = True
EMAIL_ON_FAILURE = True
EMAIL_ON_RETRY = True
RETRIES = int(Variable.get('gv_dag_retries'))
POOL = 'dma_pool'
PRIORITY_WEIGHT = 10

start_dt = datetime.today() - timedelta(1)
start_dt = datetime(start_dt.year, start_dt.month, start_dt.day)

default_args = {
    'owner': OWNER,
    'depends_on_past': DEPENDS_ON_PAST,
    'start_date': start_dt,
    'email': ALERT_MAILS,
    'email_on_failure': EMAIL_ON_FAILURE,
    'email_on_retry': EMAIL_ON_RETRY,
    'retries': RETRIES,
    'pool': POOL,
    'priority_weight': PRIORITY_WEIGHT
}
dag = DAG(DAG_NAME, default_args=default_args)
dag.doc_md = __doc__

ສະນຸກເກີທີ່ກໍານົດຢູ່ໃນລະດັບ DAG ສາມາດຖືກ overridden ໃນລະດັບຫນ້າວຽກ.
ຂະບວນການແຍກຕ່າງຫາກ, Scheduler, ຮັບຜິດຊອບສໍາລັບການກໍານົດເວລາວຽກງານທັງຫມົດໃນ Airflow. ຕົວຈິງແລ້ວ, Scheduler ຈັດການກັບກົນໄກການກໍານົດວຽກງານສໍາລັບການປະຕິບັດ. ວຽກງານດັ່ງກ່າວຜ່ານຫຼາຍຂັ້ນຕອນກ່ອນທີ່ຈະຖືກປະຕິບັດ:

1. ວຽກ​ງານ​ທີ່​ຜ່ານ​ມາ​ໄດ້​ຮັບ​ການ​ສໍາ​ເລັດ​ໃນ DAG​, ເປັນ​ຫນຶ່ງ​ໃຫມ່​ສາ​ມາດ​ຈັດ​ຄິວ​ໄດ້​.
2. ແຖວຖືກຈັດຮຽງຂຶ້ນຢູ່ກັບບູລິມະສິດຂອງວຽກງານ (ບູລິມະສິດຍັງສາມາດຄວບຄຸມໄດ້), ແລະຖ້າມີຊ່ອງຫວ່າງໃນສະນຸກເກີ, ວຽກງານສາມາດຖືກປະຕິບັດ.
3. ຖ້າມີ celery ພະນັກງານຟຣີ, ວຽກງານແມ່ນຖືກສົ່ງໄປຫາມັນ; ວຽກງານທີ່ທ່ານຕັ້ງໂຄງການຢູ່ໃນບັນຫາເລີ່ມຕົ້ນ, ການນໍາໃຊ້ຫນຶ່ງຫຼືຕົວປະຕິບັດການອື່ນ.

ງ່າຍດາຍພຽງພໍ.

Scheduler ເຮັດວຽກຢູ່ໃນຊຸດຂອງ DAGs ທັງຫມົດແລະຫນ້າວຽກທັງຫມົດພາຍໃນ DAGs.

ສໍາລັບ Scheduler ເພື່ອເລີ່ມຕົ້ນການເຮັດວຽກກັບ DAG, DAG ຕ້ອງການກໍານົດເວລາ:

dag = DAG(DAG_NAME, default_args=default_args, schedule_interval='@hourly')

ມີຊຸດຂອງ presets ທີ່ກຽມພ້ອມ: @once, @hourly, @daily, @weekly, @monthly, @yearly.

ທ່ານຍັງສາມາດໃຊ້ການສະແດງອອກ cron:

dag = DAG(DAG_NAME, default_args=default_args, schedule_interval='*/10 * * * *')

ວັນທີປະຕິບັດ

ເພື່ອເຂົ້າໃຈວິທີການເຮັດວຽກຂອງ Airflow, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະເຂົ້າໃຈວ່າວັນທີປະຕິບັດແມ່ນຫຍັງສໍາລັບ DAG. ໃນ Airflow, DAG ມີຂະຫນາດຂອງວັນທີປະຕິບັດ, i.e., ອີງຕາມຕາຕະລາງການເຮັດວຽກຂອງ DAG, ຕົວຢ່າງວຽກແມ່ນຖືກສ້າງຂຶ້ນສໍາລັບແຕ່ລະວັນທີປະຕິບັດ. ແລະສໍາລັບແຕ່ລະວັນທີປະຕິບັດ, ວຽກງານສາມາດຖືກປະຕິບັດຄືນໃຫມ່ - ຫຼື, ຕົວຢ່າງ, DAG ສາມາດເຮັດວຽກພ້ອມໆກັນໃນຫຼາຍໆວັນທີປະຕິບັດ. ນີ້ແມ່ນສະແດງໃຫ້ເຫັນຢ່າງຊັດເຈນທີ່ນີ້:

ແຕ່ຫນ້າເສຍດາຍ (ຫຼືອາດຈະໂຊກດີ: ມັນຂຶ້ນກັບສະຖານະການ), ຖ້າການປະຕິບັດວຽກງານໃນ DAG ຖືກແກ້ໄຂ, ຫຼັງຈາກນັ້ນ, ການປະຕິບັດໃນວັນທີປະຕິບັດທີ່ຜ່ານມາຈະດໍາເນີນການພິຈາລະນາການປັບຕົວ. ນີ້ແມ່ນດີຖ້າທ່ານຕ້ອງການຄິດໄລ່ຂໍ້ມູນໃນໄລຍະເວລາທີ່ຜ່ານມາໂດຍໃຊ້ algorithm ໃຫມ່, ແຕ່ມັນບໍ່ດີເພາະວ່າການສືບພັນຂອງຜົນໄດ້ຮັບຈະສູນເສຍ (ແນ່ນອນ, ບໍ່ມີໃຜລົບກວນທ່ານທີ່ຈະສົ່ງຄືນລະຫັດແຫຼ່ງທີ່ຕ້ອງການຈາກ Git ແລະຄິດໄລ່ວ່າແມ່ນຫຍັງ. ທ່ານຕ້ອງການຄັ້ງດຽວ, ວິທີທີ່ທ່ານຕ້ອງການ).

ກຳລັງສ້າງໜ້າວຽກ

ການປະຕິບັດຂອງ DAG ແມ່ນລະຫັດໃນ Python, ດັ່ງນັ້ນພວກເຮົາມີວິທີທີ່ສະດວກຫຼາຍທີ່ຈະຫຼຸດຜ່ອນຈໍານວນລະຫັດໃນເວລາທີ່ເຮັດວຽກ, ສໍາລັບການຍົກຕົວຢ່າງ, ກັບແຫຼ່ງ sharded. ໃຫ້ເວົ້າວ່າທ່ານມີສາມ MySQL shards ເປັນແຫຼ່ງ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ປີນເຂົ້າໄປໃນແຕ່ລະຄົນແລະເອົາຂໍ້ມູນບາງຢ່າງ. ຍິ່ງໄປກວ່ານັ້ນ, ເປັນເອກະລາດແລະຂະຫນານ. ລະຫັດ Python ໃນ DAG ອາດຈະເບິ່ງຄືວ່ານີ້:

connection_list = lv.get('connection_list')

export_profiles_sql = '''
SELECT
  id,
  user_id,
  nickname,
  gender,
  {{params.shard_id}} as shard_id
FROM profiles
'''

for conn_id in connection_list:
    export_profiles = SqlToHiveViaHdfsTransfer(
        task_id='export_profiles_from_' + conn_id,
        sql=export_profiles_sql,
        hive_table='stg.profiles',
        overwrite=False,
        tmpdir='/data/tmp',
        conn_id=conn_id,
        params={'shard_id': conn_id[-1:], },
        compress=None,
        dag=dag
    )
    export_profiles.set_upstream(exec_truncate_stg)
    export_profiles.set_downstream(load_profiles)

DAG ມີລັກສະນະນີ້:

ໃນກໍລະນີນີ້, ທ່ານສາມາດເພີ່ມຫຼືເອົາ shard ໄດ້ໂດຍພຽງແຕ່ປັບການຕັ້ງຄ່າແລະປັບປຸງ DAG. ສະດວກສະບາຍ!

ທ່ານຍັງສາມາດໃຊ້ການສ້າງລະຫັດທີ່ສັບສົນຫຼາຍ, ສໍາລັບການຍົກຕົວຢ່າງ, ເຮັດວຽກກັບແຫຼ່ງໃນຮູບແບບຂອງຖານຂໍ້ມູນຫຼືອະທິບາຍໂຄງສ້າງຕາຕະລາງ, ສູດການຄິດໄລ່ສໍາລັບການເຮັດວຽກກັບຕາຕະລາງ, ແລະຄໍານຶງເຖິງລັກສະນະຂອງໂຄງສ້າງພື້ນຖານຂອງ DWH, ສ້າງຂະບວນການ. ສໍາລັບການໂຫຼດຕາຕະລາງ N ເຂົ້າໄປໃນບ່ອນເກັບຂໍ້ມູນຂອງທ່ານ. ຫຼື, ສໍາລັບການຍົກຕົວຢ່າງ, ການເຮັດວຽກກັບ API ທີ່ບໍ່ສະຫນັບສະຫນູນການເຮັດວຽກກັບພາລາມິເຕີໃນຮູບແບບຂອງບັນຊີລາຍຊື່, ທ່ານສາມາດສ້າງວຽກງານ N ໃນ DAG ຈາກບັນຊີລາຍຊື່ນີ້, ຈໍາກັດການຂະຫນານຂອງຄໍາຮ້ອງຂໍໃນ API ກັບສະນຸກເກີແລະຂູດ. ຂໍ້ມູນທີ່ຈໍາເປັນຈາກ API. ປ່ຽນແປງໄດ້!

ຄັງເກັບມ້ຽນ

Airflow ມີ repository backend ຂອງຕົນເອງ, ຖານຂໍ້ມູນ (ສາມາດເປັນ MySQL ຫຼື Postgres, ພວກເຮົາມີ Postgres), ເຊິ່ງເກັບຮັກສາສະຖານະຂອງຫນ້າວຽກ, DAGs, ການຕັ້ງຄ່າການເຊື່ອມຕໍ່, ຕົວແປທົ່ວໂລກ, ແລະອື່ນໆ. repository ໃນ Airflow ແມ່ນງ່າຍດາຍຫຼາຍ (ປະມານ 20 ຕາຕະລາງ) ແລະສະດວກຖ້າທ່ານຕ້ອງການສ້າງຂະບວນການຂອງຕົນເອງຢູ່ເທິງສຸດຂອງມັນ. ຂ້າພະເຈົ້າຈື່ 100500 ຕາຕະລາງໃນຄັງເກັບຂໍ້ມູນ Informatica, ເຊິ່ງຕ້ອງໄດ້ສຶກສາເປັນເວລາດົນນານກ່ອນທີ່ຈະເຂົ້າໃຈວິທີການສ້າງແບບສອບຖາມ.

ການຕິດຕາມ

ເນື່ອງຈາກຄວາມງ່າຍດາຍຂອງ repository, ທ່ານສາມາດສ້າງຂະບວນການຕິດຕາມກວດກາວຽກງານທີ່ສະດວກສໍາລັບທ່ານ. ພວກເຮົາໃຊ້ notepad ໃນ Zeppelin, ບ່ອນທີ່ພວກເຮົາເບິ່ງສະຖານະຂອງວຽກງານ:

ນີ້ອາດຈະເປັນສ່ວນຕິດຕໍ່ເວັບຂອງ Airflow ເອງ:

ລະຫັດ Airflow ແມ່ນແຫຼ່ງເປີດ, ດັ່ງນັ້ນພວກເຮົາໄດ້ເພີ່ມການແຈ້ງເຕືອນໃສ່ Telegram. ແຕ່ລະຕົວຢ່າງການເຮັດວຽກຂອງວຽກງານ, ຖ້າມີຂໍ້ຜິດພາດເກີດຂຶ້ນ, spams ກຸ່ມໃນ Telegram, ບ່ອນທີ່ທີມງານພັດທະນາແລະສະຫນັບສະຫນູນທັງຫມົດປະກອບດ້ວຍ.

ພວກເຮົາໄດ້ຮັບການຕອບສະຫນອງທັນທີໂດຍຜ່ານ Telegram (ຖ້າຕ້ອງການ), ແລະຜ່ານ Zeppelin ພວກເຮົາໄດ້ຮັບຮູບພາບລວມຂອງວຽກງານໃນ Airflow.

ລວມ

Airflow ແມ່ນແຫຼ່ງເປີດຕົ້ນຕໍ, ແລະທ່ານບໍ່ຄວນຄາດຫວັງວ່າສິ່ງມະຫັດສະຈັນຈາກມັນ. ຈົ່ງກຽມພ້ອມທີ່ຈະເອົາເວລາແລະຄວາມພະຍາຍາມທີ່ຈະສ້າງການແກ້ໄຂທີ່ເຮັດວຽກ. ເປົ້າຫມາຍແມ່ນບັນລຸໄດ້, ເຊື່ອຂ້ອຍ, ມັນຄຸ້ມຄ່າ. ຄວາມໄວຂອງການພັດທະນາ, ຄວາມຍືດຫຍຸ່ນ, ຄວາມງ່າຍຂອງການເພີ່ມຂະບວນການໃຫມ່ - ທ່ານຈະມັກມັນ. ແນ່ນອນ, ທ່ານຈໍາເປັນຕ້ອງເອົາໃຈໃສ່ຫຼາຍຕໍ່ອົງການຈັດຕັ້ງຂອງໂຄງການ, ຄວາມຫມັ້ນຄົງຂອງ Airflow ຕົວຂອງມັນເອງ: ມະຫັດສະຈັນບໍ່ເກີດຂຶ້ນ.

ໃນປັດຈຸບັນພວກເຮົາມີ Airflow ເຮັດວຽກປະຈໍາວັນ ປະມານ 6,5 ພັນວຽກງານ. ພວກເຂົາເຈົ້າແມ່ນຂ້ອນຂ້າງແຕກຕ່າງກັນໃນລັກສະນະ. ມີວຽກງານການໂຫຼດຂໍ້ມູນເຂົ້າໄປໃນ DWH ຕົ້ນຕໍຈາກຫຼາຍແຫຼ່ງທີ່ແຕກຕ່າງກັນແລະສະເພາະຫຼາຍ, ມີວຽກງານການຄິດໄລ່ຫນ້າຮ້ານພາຍໃນ DWH ຕົ້ນຕໍ, ມີວຽກງານເຜີຍແຜ່ຂໍ້ມູນເຂົ້າໄປໃນ DWH ໄວ, ມີຫຼາຍ, ຫຼາຍວຽກງານທີ່ແຕກຕ່າງກັນ - ແລະ Airflow. chews ພວກ​ເຂົາ​ທັງ​ຫມົດ​ເຖິງ​ມື້​ຕໍ່​ໄປ​. ເວົ້າໃນຕົວເລກ, ນີ້ແມ່ນ 2,3 ພັນ ວຽກງານ ELT ຂອງຄວາມສັບສົນທີ່ແຕກຕ່າງກັນພາຍໃນ DWH (Hadoop), ປະມານ. 2,5 ຮ້ອຍຖານຂໍ້ມູນ ແຫຼ່ງຂໍ້ມູນ, ນີ້ແມ່ນທີມງານຈາກ 4 ຜູ້ພັດທະນາ ETL, ເຊິ່ງແບ່ງອອກເປັນການປະມວນຜົນຂໍ້ມູນ ETL ໃນການປະມວນຜົນຂໍ້ມູນ DWH ແລະ ELT ພາຍໃນ DWH ແລະແນ່ນອນຫຼາຍ. ຫນຶ່ງ admin, ຜູ້ທີ່ຈັດການກັບໂຄງສ້າງພື້ນຖານຂອງການບໍລິການ.

ແຜນສໍາລັບອະນາຄົດ

ຈໍານວນຂອງຂະບວນການແມ່ນການຂະຫຍາຍຕົວຢ່າງຫຼີກລ່ຽງບໍ່ໄດ້, ແລະສິ່ງທີ່ສໍາຄັນທີ່ພວກເຮົາຈະເຮັດໃນດ້ານໂຄງສ້າງພື້ນຖານຂອງ Airflow ແມ່ນການຂະຫຍາຍຂະຫນາດ. ພວກເຮົາຕ້ອງການສ້າງກຸ່ມ Airflow, ຈັດສັນຂາຄູ່ສໍາລັບພະນັກງານ Celery, ແລະເຮັດໃຫ້ຫົວທີ່ຊ້ໍາກັນດ້ວຍຕົນເອງດ້ວຍຂະບວນການກໍານົດເວລາວຽກແລະບ່ອນເກັບມ້ຽນ.

Epilogue

ນີ້, ແນ່ນອນ, ບໍ່ແມ່ນທຸກສິ່ງທຸກຢ່າງທີ່ຂ້ອຍຢາກບອກກ່ຽວກັບ Airflow, ແຕ່ຂ້ອຍພະຍາຍາມເນັ້ນໃສ່ຈຸດຕົ້ນຕໍ. ຄວາມຢາກອາຫານມາພ້ອມກັບການກິນ, ລອງເບິ່ງແລ້ວເຈົ້າຈະມັກມັນ :)

ແຫຼ່ງຂໍ້ມູນ: www.habr.com