Įvadas: Įmonėms pagrindinis duomenų rinkimo iššūkis niekada nebuvo tik „sinchronizavimas“, bet ir tai, kaip užtikrinti duomenų tikslumą, vientisumą ir savalaikiškumą didelio masto, nevienalytėje ir sudėtingoje aplinkoje.Šiame straipsnyje nagrinėjama SUPCON praktika kurti įmonės lygmens duomenų rinkimo sistemą, pagrįstą „Apache SeaTunnel“, daugiausia dėmesio skiriant konkrečių įžvalgų ir sprendimų dalijimui tokiais aspektais kaip didelio prieinamumo konfigūracija, našumo optimizavimas, klaidų tolerancijos mechanizmai ir duomenų kokybės stebėjimas. Įvadas: Įmonėms pagrindinis duomenų rinkimo iššūkis niekada nebuvo tik „sinchronizavimas“, bet ir tai, kaip užtikrinti duomenų tikslumą, vientisumą ir savalaikiškumą didelio masto, nevienalytėje ir sudėtingoje aplinkoje.Šiame straipsnyje nagrinėjama SUPCON praktika kurti įmonės lygmens duomenų rinkimo sistemą, pagrįstą „Apache SeaTunnel“, daugiausia dėmesio skiriant konkrečių įžvalgų ir sprendimų dalijimui tokiais aspektais kaip didelio prieinamumo konfigūracija, našumo optimizavimas, klaidų tolerancijos mechanizmai ir duomenų kokybės stebėjimas. Dilema: Siloed kolekcijos architektūra ir didelės eksploatavimo ir techninės priežiūros išlaidos Kaip pramoninės AI platformos įmonė, kuri giliai įgalina procesų pramonę, SUPCON pasaulinis verslas nuolat vystosi. Šiuo metu ji turi beveik 40 pasaulinių dukterinių bendrovių ir aptarnauja daugiau nei 35 000 pasaulinių klientų. Nuolatinis verslo plėtrai keliami didesni reikalavimai duomenų darbui: duomenys turi būti ne tik „skaičiuojami greitai“, bet ir „nustatyti tiksliai“. Šiuo tikslu mes sukūrėme srauto partijos atskirtą didelių duomenų platformą, kad galėtume susidoroti su sudėtingais scenarijais. Tačiau pačios platformos sudėtingumas atvirkščiai padidino duomenų rinkimo, plėtros ir eksploatavimo ir priežiūros sunkumus, ypač duomenų rinkimo šaltinio linijoje, kur susiduriame su rimtais iššūkiais: : Anksčiau mes ilgai remiamės sprendimais, sudarytais iš kelių įrankių (pavyzdžiui, naudojant Sqoop batch duomenų sinchronizavimui su HDFS ir Maxwell/StreamSets, kad apdorotume duomenų bazės inkrementinius žurnalus ir įrašytume juos į Kafka/Kudu). (1) Complex Architecture with Silos Vieningo stebėjimo ir perspėjimo mechanizmo trūkumas reiškia, kad bet kokie sutrikimai (pvz., sinchronizavimo vėlavimai, išteklių išsekimas) reikalauja daug darbo jėgos trikčių šalinimui ir „gaisrų gesinimui“, todėl sunku užtikrinti stabilumą. (2) O&M Black Hole, Constantly Firefighting : Susidūrę su naujais duomenų šaltiniais (pavyzdžiui, vidaus duomenų bazėmis ir SAP HANA), turime rasti pritaikymo sprendimus skirtinguose įrankiuose arba savarankiškai kurti įskiepius, todėl neįmanoma greitai reaguoti į verslo poreikius. (3) Segmented Capabilities, Difficult to Expand Aukščiau pateiktas skaičius aiškiai parodo anksčiau decentralizuotą rinkimo ekosistemą. Mes supratome, kad šis „neorganizuotas“ modelis tapo labiausiai pažeidžiamu duomenų apdorojimo ryšiu. Jis ne tik neatitinka įmonės būsimo vystymosi greičio, bet ir kelia galimą grėsmę duomenų kokybei ir savalaikiškumui. Išspręskite dilemą: mintys apie vieningą kolekcijos sistemą ir technologijų pasirinkimą Po nuodugnios analizės ir apmąstymo paaiškinome penkis pagrindinius naujų technologijų atrankos kriterijus: Ji turėtų visiškai aprėpti visus dabartinius ir būsimus įmonės duomenų šaltinių tipus (nuo MySQL, Oracle, HANA iki Kafka, StarRocks ir tt) ir palaikyti tiek neprisijungus, tiek realaus laiko rinkimo režimus, iš esmės išsprendžiant unifikuotų technologijų sluoksnių problemą. (1) Comprehensive Connectivity Pats rėmas turi būti labai prieinamas paskirstytas klasteris su stipria klaidų tolerancija. net jei vienas mazgas nepavyksta, visa paslauga neturėtų būti nutraukta ir gali automatiškai atkurti, užtikrinant nuolatinį duomenų rinkimo vamzdžio veikimą. (2) Cluster Stability and High Availability Užduočių vykdymo lygiu jis turi pateikti "Tiksliai vieną kartą" arba "Mažiausiai vieną kartą" apdorojimo semantiką, kad užduotys galėtų automatiškai atsigauti po sutrikimų po nenormalių pertraukų, pašalinant duomenų dubliavimą ar praradimą, kuris yra duomenų kokybės kertinis akmuo. (3) Reliable Data Consistency Guarantee Jos architektūra turėtų palaikyti horizontalią plėtrą, o sinchronizavimo našumą galima linijiniu būdu pagerinti pridedant mazgų, kad būtų patenkinti duomenų augimo poreikiai, kuriuos lemia sparčiai besivystantis verslas. (4) Strong Throughput Performance Ji turi pateikti išsamų stebėjimo ir perspėjimo mechanizmą, kuris gali stebėti pagrindinius rodiklius, tokius kaip anomalijos, vėlavimai ir pralaidumas duomenų sinchronizavimo metu realiuoju laiku, ir laiku pranešti eksploatavimo ir techninės priežiūros darbuotojams, paverčiant pasyvų „gaisrų gesinimą“ aktyviu „ankstyvuoju perspėjimu“. (5) Observable O&M Experience Remiantis šiais penkiais kriterijais, mes atlikome išsamius tyrimus ir lyginamuosius bandymus su pagrindiniais pramonės sprendimais. Our Core Requirements Apache SeaTunnel's Solutions Comprehensive Connectivity It has an extremely rich Connector ecosystem, officially supporting the reading and writing of hundreds of source/destination databases, fully covering all our data types. A single framework can unify offline and real-time collection. Cluster Stability and High Availability The separated architecture of SeaTunnel Engine ensures that even if a single Master or Worker node is abnormal, it will not affect the continuity of collection tasks. Reliable Data Consistency Guarantee It provides a powerful fault tolerance mechanism, supports Exactly-Once semantics, and can realize automatic breakpoint resumption after task abnormalities through the Checkpoint mechanism, ensuring no data loss or duplication. Strong Throughput Performance It has excellent distributed data processing capabilities. Parallelism can be adjusted through simple configuration, easily realizing horizontal expansion. Observable O&M Experience It provides rich monitoring indicators and can be seamlessly integrated with mainstream monitoring and alerting systems such as Prometheus, Grafana, and AlertManager, allowing us to have a clear understanding of the data collection process. Visapusiškas ryšys Ji turi labai turtingą "Connector" ekosistemą, kuri oficialiai palaiko šimtus šaltinio / paskirties duomenų bazių skaitymą ir rašymą, visiškai apimantį visus mūsų duomenų tipus. Klasterio stabilumas ir didelis prieinamumas Atskira „SeaTunnel Engine“ architektūra užtikrina, kad net jei vienas „Master“ arba „Worker“ mazgas yra nenormalus, tai neturės įtakos rinkimo užduočių tęstinumui. Patikimas duomenų nuoseklumo užtikrinimas Jis suteikia galingą klaidų tolerancijos mechanizmą, palaiko "Exactly-Once" semantiką ir gali realizuoti automatinį skilimo taško atnaujinimą po užduočių sutrikimų per "Checkpoint" mechanizmą, užtikrinant, kad nebūtų duomenų praradimo ar dubliavimo. Stiprus perdavimo efektyvumas Jis turi puikias paskirstytų duomenų apdorojimo galimybes. Paralelizmą galima reguliuoti paprasta konfigūracija, lengvai realizuojant horizontalią plėtrą. Įspūdinga O&M patirtis Jis siūlo turtingus stebėjimo rodiklius ir gali būti sklandžiai integruojamas su pagrindinėmis stebėjimo ir perspėjimo sistemomis, tokiomis kaip „Prometheus“, „Grafana“ ir „AlertManager“, kad galėtume aiškiai suprasti duomenų rinkimo procesą. Praktika: konkretūs įgyvendinimo planai ir detalės Mūsų praktika su „Apache SeaTunnel“ taip pat yra projekto augimo kelias.Ankstyvosiose stadijose mes sukūrėme „Apache SeaTunnel v2.3.5“ pagrindu.Tuo metu, norėdami patenkinti kai kuriuos konkrečius poreikius (pavyzdžiui, spręsti įvairių duomenų bazių lentelių pavadinimų ar laukų pavadinimų atvejų jautrumo problemas), mes atlikome kai kuriuos antrinius kūrimo darbus. Tačiau sparčiai plėtojant SeaTunnel bendruomenei, naujos versijos funkcijos ir konverteriai tapo vis išsamesni.Kai mes sėkmingai atnaujinome klasterį į Apache SeaTunnel v2.3.11, mes maloniai nustebome, kad poreikiai, kuriems anksčiau reikėjo individualizuotos plėtros, dabar natūraliai palaikomi naujoje versijoje. Šiuo metu visos mūsų duomenų sinchronizavimo užduotys įgyvendinamos remiantis oficialiąja versija, pasiekus nulinę modifikaciją, o tai labai sumažina mūsų ilgalaikes techninės priežiūros išlaidas ir leidžia mums sklandžiai mėgautis naujausiomis bendruomenės teikiamomis funkcijomis ir našumo patobulinimais. Toliau pateikiami mūsų pagrindiniai įgyvendinimo planai, pagrįsti versija v2.3.11, kurie buvo patikrinti TB lygio duomenų kiekiu gamybos aplinkoje ir sukūrė tvirtą pagrindą puikiam 0 gedimų našumui nuo klasterio sukūrimo. 1) Klasterio planavimas Siekiant užtikrinti aukštą klasterio prieinamumą, rekomenduojama teikti pirmenybę atskiro režimo klasterio diegimui. Node CPU Memory Disk JVM Heap Master-01 8C 32G 200G 30G Master-02 8C 32G 200G 30G Worker-01 16C 64G 500G 62G Worker-02 16C 64G 500G 62G Worker-03 16C 64G 500G 62G Meistras-01 8C 32g 200 g 30g Meistras 02 8C 32g 200 g 30g Darbuotojas 01 16C 64 g 500 g 62 g Darbuotojas 02 16C 64 g 500 g 62 g Darbuotojas 03 16C 64 g 500 g 62 g (2) Pagrindiniai klasterio konfigūracijos failai This configuration file is mainly used to define the execution behavior, fault tolerance mechanism, and operation and maintenance monitoring settings of jobs. It optimizes performance by enabling class loading caching and dynamic resource allocation, and ensures job fault tolerance and data consistency by configuring S3-based Checkpoints. In addition, it can enable indicator collection, log management, and settings, thereby providing comprehensive support for the stable operation, monitoring, and daily management of jobs. seatunnel.yaml seatunnel: engine: # Class loader cache mode: After enabling, it can significantly improve performance when jobs are frequently started and stopped, reducing class loading overhead. It is recommended to enable it in the production environment. classloader-cache-mode: true # Expiration time of historical job data (unit: minutes): 3 days. Historical information of completed jobs exceeding this time will be automatically cleaned up. history-job-expire-minutes: 4320 # Number of data backups backup-count: 1 # Queue type: Blocking queue queue-type: blockingqueue # Execution information printing interval (seconds): Print job execution information in the log every 60 seconds. print-execution-info-interval: 60 # Job metric information printing interval (seconds): Print detailed metric information in the log every 60 seconds. print-job-metrics-info-interval: 60 slot-service: # Dynamic Slot management: After enabling, the engine will dynamically allocate computing slots based on node resource conditions, improving resource utilization. dynamic-slot: true # Checkpoint configuration. checkpoint: interval: 60000 # Time interval between two Checkpoints, in milliseconds (ms). Here it is 1 minute. timeout: 600000 # Timeout for Checkpoint execution, in milliseconds (ms). Here it is 10 minutes. storage: type: hdfs # The storage type is declared as HDFS here, and the actual storage is in the S3 below. max-retained: 3 # Maximum number of Checkpoint histories to retain. Old Checkpoints will be automatically deleted to save space. plugin-config: storage.type: s3 # The actual configured storage type is S3 (or object storage compatible with S3 protocol such as MinIO) fs.s3a.access.key: xxxxxxx # Access Key of S3-compatible storage fs.s3a.secret.key: xxxxxxx # Secret Key of S3-compatible storage fs.s3a.endpoint: http://xxxxxxxx:8060 # Service endpoint (Endpoint) address of S3-compatible storage s3.bucket: s3a://seatunel-pro-bucket # Name of the bucket used to store Checkpoint data fs.s3a.aws.credentials.provider: org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider # Authentication credential provider # Observability configuration telemetry: metric: enabled: true # Enable metric collection logs: # Enable scheduled log deletion: Enable the automatic cleaning function of log files to prevent logs from filling up the disk. scheduled-deletion-enable: true # Web UI and REST API configuration http: enable-http: true # Enable Web UI and HTTP REST API services port: 8080 # Port number bound by the Web service enable-dynamic-port: false # Disable dynamic ports. Whether to enable other ports if 8080 is occupied. # The following is the Web UI basic authentication configuration enable-basic-auth: true # Enable basic identity authentication basic-auth-username: admin # Login username basic-auth-password: xxxxxxx # Login password This JVM parameter configuration file is mainly used to ensure the stability and performance of the SeaTunnel engine during large-scale data processing. It provides basic memory guarantee by setting the heap memory and metaspace capacity, and conducts a series of optimizations specifically for the G1 garbage collector to effectively manage memory garbage, control garbage collection pause time, and improve operating efficiency. jvm_master_options # JVM heap memory -Xms30g -Xmx30g # Memory overflow diagnosis: Automatically generate a Heap Dump file when OOM occurs, and save it to the specified path for subsequent analysis. -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/seatunnel/dump/zeta-server # Metaspace: Limit the maximum capacity to 5GB to prevent metadata from expanding infinitely and occupying too much local memory. -XX:MaxMetaspaceSize=5g # G1 garbage collector related configuration -XX:+UseG1GC # Enable G1 garbage collector -XX:+PrintGCDetails # Print detailed GC information in the log -Xloggc:/path/to/gc.log # Output GC logs to the specified file -XX:+PrintGCDateStamps # Print timestamps in GC logs -XX:MaxGCPauseMillis=5000 # The target maximum GC pause time is 5000 milliseconds (5 seconds) -XX:InitiatingHeapOccupancyPercent=50 # Start concurrent GC cycle when heap memory usage reaches 50% -XX:+UseStringDeduplication # Enable string deduplication to save memory space -XX:GCTimeRatio=4 # Set the target ratio of GC time to application time -XX:G1ReservePercent=15 # Reserve 15% of heap memory -XX:ConcGCThreads=6 # Set the number of threads used in the concurrent GC phase to 6 -XX:G1HeapRegionSize=32m # Set the G1 region size to 32MB This configuration file defines the underlying distributed architecture and collaboration mechanism of the SeaTunnel engine cluster. It is mainly used to establish and manage network communication between cluster nodes. The configuration also includes a high-precision failure detection heartbeat mechanism to ensure that node failure problems can be quickly detected and handled, ensuring the high availability of the cluster. At the same time, it enables distributed data persistence based on S3-compatible storage, reliably saving key state information to object storage. hazelcast-master.yaml (iMap stored in self-built object storage) hazelcast: cluster-name: seatunnel # Cluster name, which must be consistent across all nodes network: rest-api: enabled: true # Enable REST API endpoint-groups: CLUSTER_WRITE: enabled: true DATA: enabled: true join: tcp-ip: enabled: true # Use TCP/IP discovery mechanism member-list: # Cluster node list - 10.xx.xx.xxx:5801 - 10.xx.xx.xxx:5801 - 10.xx.xx.xxx:5802 - 10.xx.xx.xxx:5802 - 10.xx.xx.xxx:5802 port: auto-increment: false # Disable port auto-increment port: 5801 # Fixed port 5801 properties: hazelcast.invocation.max.retry.count: 20 # Maximum number of invocation retries hazelcast.tcp.join.port.try.count: 30 # Number of TCP connection port attempts hazelcast.logging.type: log4j2 # Use log4j2 logging framework hazelcast.operation.generic.thread.count: 50 # Number of generic operation threads hazelcast.heartbeat.failuredetector.type: phi-accrual # Use Phi-accrual failure detector hazelcast.heartbeat.interval.seconds: 2 # Heartbeat interval (seconds) hazelcast.max.no.heartbeat.seconds: 180 # No heartbeat timeout (seconds) hazelcast.heartbeat.phiaccrual.failuredetector.threshold: 10 # Failure detection threshold hazelcast.heartbeat.phiaccrual.failuredetector.sample.size: 200 # Detection sample size hazelcast.heartbeat.phiaccrual.failuredetector.min.std.dev.millis: 100 # Minimum standard deviation (milliseconds) hazelcast.operation.call.timeout.millis: 150000 # Operation call timeout (milliseconds) map: engine*: map-store: enabled: true # Enable Map storage persistence initial-mode: EAGER # Load all data immediately at startup factory-class-name: org.apache.seatunnel.engine.server.persistence.FileMapStoreFactory # Persistence factory class properties: type: hdfs # Storage type namespace: /seatunnel/imap # Namespace path clusterName: seatunnel-cluster # Cluster name storage.type: s3 # Actually use S3-compatible storage fs.s3a.access.key: xxxxxxxxxxxxxxxx # S3 access key fs.s3a.secret.key: xxxxxxxxxxxxxxxx # S3 secret key fs.s3a.endpoint: http://xxxxxxx:8060 # S3 endpoint address s3.bucket: s3a://seatunel-pro-bucket # S3 storage bucket name fs.s3a.aws.credentials.provider: org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider # Authentication provider 3) Rinkimų užduočių pavyzdžiai ① MySQL-CDC to StarRocks Norint surinkti MySQL-CDC duomenis, būtina užtikrinti, kad šaltinio duomenų bazė įgalintų "Binlog" su ROW formatu, vartotojas turi atitinkamas teises, o atitinkamas "MySQL Jar" paketas yra įdėtas į Daugiau informacijos, prašome kreiptis į oficialią svetainę: . ${SEATUNNEL_HOME}/lib https://seatunnel.apache.org/docs/2.3.11/connector-v2/source/MySQL-CDC Toliau pateikiama mūsų MySQL-CDC kolekcijos pavyzdinė konfigūracija. env { parallelism = 1 # Parallelism is set to 1; only 1 is allowed for streaming collection job.mode = "STREAMING" # Streaming job mode job.name = cdh2sr # Job name identifier job.retry.times = 3 # Number of retries if the job fails job.retry.interval.seconds=180 # Retry interval (in seconds) } source { MySQL-CDC { base-url = "jdbc:mysql://xxxxxxx:3306/databasename" # MySQL connection address username = "xxxxxxr" # Database username password = "xxxxxx" # Database password table-names = ["databasename.table1","databasename_pro.table2"] # List of tables to sync (format: database.table name) startup.mode = "latest" # Start syncing from the latest position exactly_once = true # Enable Exactly-Once semantics debezium { include.schema.changes = "false" # Exclude schema changes snapshot.mode = when_needed # Take snapshots on demand } } } transform { TableRename { plugin_input = "cdc" # Input plugin identifier plugin_output = "rs" # Output plugin identifier convert_case = "LOWER" # Convert table names to lowercase prefix = "ods_cdh_databasename_" # Add prefix to table names } } sink { StarRocks { plugin_input = "rs" # Input plugin identifier (consistent with transform output) nodeUrls = ["xxxxxxx:8030","xxxxxxx:8030","xxxxxxx:8030"] # StarRocks FE node addresses base-url = "jdbc:mysql://xxxxxxx:3307" # StarRocks MySQL protocol address username = "xxxx" # StarRocks username password ="xxxxxxx" # StarRocks password database = "ods" # Target database enable_upsert_delete = true # Enable update/delete functionality max_retries = 3 # Number of retries if write fails http_socket_timeout_ms = 360000 # HTTP timeout (in milliseconds) retry_backoff_multiplier_ms = 2000 # Retry backoff multiplier max_retry_backoff_ms = 20000 # Maximum retry backoff time batch_max_rows = 2048 # Maximum number of rows per batch batch_max_bytes = 50000000 # Maximum bytes per batch } } ② Oracle-CDC to StarRocks Norėdami rinkti Oracle-CDC duomenis, įsitikinkite, kad šaltinio duomenų bazėje yra įgalintas Logminer, vartotojas turi atitinkamas teises, ir įdėkite atitinkamus OJDBC.Jar ir Orai18n.jar paketus į Išsamesnės informacijos ieškokite oficialioje svetainėje: . ${SEATUNNEL_HOME}/lib https://seatunnel.apache.org/docs/2.3.11/connector-v2/source/Oracle-CDC Atsižvelgiant į Oracle-CDC surinkimo metu susidariusias uždelsimo problemas, pirmiausia rekomenduojame paprašyti DBA patikrinti, kaip dažnai keičiasi „Logminer“ žurnalai. Oficiali rekomendacija yra laikyti jį maždaug 10 kartų per valandą – pernelyg dažnas perjungimas gali sukelti ilgą uždelsimą. Jei dažnis yra per didelis, padidinkite atskirų žurnalų failų dydį. -- Query log switch frequency SELECT GROUP#, THREAD#, BYTES/1024/1024 || 'MB' "SIZE", ARCHIVED, STATUS FROM V$LOG; SELECT TO_CHAR(first_time, 'YYYY-MM-DD HH24') AS hour, COUNT(*) AS switch_count FROM v$log_history WHERE first_time >= TRUNC(SYSDATE) - 1 -- Data from the past day GROUP BY TO_CHAR(first_time, 'YYYY-MM-DD HH24') ORDER BY hour; -- Query log file size SELECT F.MEMBER, L.GROUP#, L.THREAD#, L.SEQUENCE#, L.BYTES/1024/1024 AS SIZE_MB, L.ARCHIVED, L.STATUS, L.FIRST_CHANGE#, L.NEXT_CHANGE# FROM V$LOG L, V$LOGFILE F WHERE F.GROUP# = L.GROUP# ORDER BY L.GROUP#; Toliau pateikiama mūsų Oracle-CDC kolekcijos pavyzdinė konfigūracija. env { parallelism = 1 # Parallelism is 1; only 1 is allowed for streaming collection job.mode = "STREAMING" # Streaming job mode job.name = bpm2sr # Job name identifier job.retry.times = 3 # Number of retries if the job fails job.retry.interval.seconds=180 # Retry interval (in seconds) } source { Oracle-CDC { plugin_output = "cdc" # Output plugin identifier base-url = "jdbc:oracle:thin:@xxxxxx:1521:DB" # Oracle connection address username = "xxxxxx" # Database username password = "xxxxxx" # Database password table-names = ["DB.SC.TABLE1","DB.SC.TABLE2"] # Tables to sync (format: database.schema.table name) startup.mode = "latest" # Start syncing from the latest position database-names = ["DB"] # Database name schema-names = ["SC"] # Schema name skip_analyze = true # Skip table analysis use_select_count = true # Use statistics exactly_once = true # Enable Exactly-Once semantics connection.pool.size = 20 # Connection pool size debezium { log.mining.strategy = "online_catalog" # Log mining strategy log.mining.continuous.mine = true # Continuously mine logs lob.enabled = false # Disable LOB support internal.log.mining.dml.parser ="legacy" # Use legacy DML parser } } } transform { TableRename { plugin_input = "cdc" # Input plugin identifier plugin_output = "rs" # Output plugin identifier convert_case = "LOWER" # Convert table names to lowercase prefix = "ods_crm_db_" # Add prefix to table names } } sink { StarRocks { plugin_input = "rs" # Input plugin identifier nodeUrls = ["xxxxxxx:8030","xxxxxxx:8030","xxxxxxx:8030"] # StarRocks FE nodes base-url = "jdbc:mysql://xxxxxxx:3307" # JDBC connection address username = "xxxx" # Username password ="xxxxxxx" # Password database = "ods" # Target database enable_upsert_delete = true # Enable update/delete max_retries = 3 # Maximum number of retries http_socket_timeout_ms = 360000 # HTTP timeout retry_backoff_multiplier_ms = 2000 # Retry backoff multiplier max_retry_backoff_ms = 20000 # Maximum retry backoff time batch_max_rows = 2048 # Maximum rows per batch batch_max_bytes = 50000000 # Maximum bytes per batch } } 4) stebimas stebėjimas Naujosios „SeaTunnel“ versijos ir sukurtos visapusiškos stebėsenos sistemos teikiamos galingos stebėsenos metrikos dėka galime visiškai suvokti duomenų rinkimo platformos būklę tiek visoje grupėje, tiek užduočių lygyje. ① Cluster Monitoring Nodo būsenos: Realaus laiko stebėjimas grupės mazgų skaičių ir jų išlikimo būseną, siekiant užtikrinti, kad nėra nenormalių išjungti darbininkų mazgų ir garantuoti grupės apdorojimo galimybes. Klasterio pralaidumas: stebėkite bendrą SourceReceivedQPS ir SinkWriteQPS klasterį, kad suprastumėte pasaulinius duomenų įplaukimo ir išleidimo rodiklius ir įvertintumėte klasterio apkrovą. Išteklių būklė: stebėti CPU ir atminties klasterio mazgų suteikti pagrindą išteklių plėtrai ar optimizavimui. Tinklo sveikata: Užtikrinti geras grupės tinklo sąlygas, stebint vidinį širdies plakimą ir ryšio vėlavimą. ② Task Monitoring Užduočių veikimo būklė: visų užduočių vykdymo būklės tikralaikis tikrinimas (Vykdymas / Nesėkmė / Baigtas) yra pagrindinis stebėjimo reikalavimas. Duomenų sinchronizavimo tūris: Stebėkite kiekvienos užduoties „SourceReceivedCount“ ir „SinkWriteCount“, kad realiu laiku suprastumėte kiekvieno duomenų vamzdžio pralaidumą. Vėlavimo laikas: Tai yra vienas iš svarbiausių CDC užduočių rodiklių. įspėjimai siunčiami, kai nuolatinis vėlavimas įvyksta surinkimo pabaigoje. Rezultatai: išmatuojama nauda Po stabilaus veikimo laikotarpio naujos kartos duomenų rinkimo sistema, sukurta remiantis „Apache SeaTunnel“, suteikė mums didelių ir kiekybinių privalumų, kurie daugiausia atsispindi šiuose aspektuose: (1) Stabilumas: nuo „nuolatinės ugnies“ iki „minties taikos“ : Under the old solution, 1-3 synchronization abnormalities needed to be handled per month. Since the new cluster was launched, core data synchronization tasks have maintained 0 failures, with no data service interruptions caused by the framework itself. Task failure rate reduced by over 99% : Relying on Apache SeaTunnel's Exactly-Once semantics and powerful Checkpoint mechanism, end-to-end Exactly-Once processing is achieved, completely solving the problem of potential trace data duplication or loss and fundamentally ensuring data quality. 100% data consistency : The high-availability design of the cluster ensures 99.99% service availability. Any single-point failure can be automatically recovered within minutes, with no impact on business operations. Significantly improved availability (2) Efektyvumas: dvigubas vystymasis ir O&M efektyvumas : From writing and maintaining multiple sets of scripts in the past to unified configuration-based development. The time to connect new data sources has been reduced from 1-2 person-days to within 1 minute, showing a significant efficiency improvement. 50% improvement in development efficiency : Now, the overall status can be monitored through the Grafana dashboard, with daily active O&M investment of less than 0.5 person-hours. 70% reduction in O&M costs : End-to-end data latency has been optimized from minutes to seconds, providing a solid foundation for real-time data analysis and decision-making. Optimized data timeliness (3) Architektūra: išteklių optimizavimas ir vieninga sistema : Successfully integrated multiple technology stacks such as Sqoop and StreamSets into Apache SeaTunnel, greatly reducing technical complexity and long-term maintenance costs. Unified technology stack Perspektyvos: ateities planai : We will actively explore the native deployment and scheduling capabilities of Apache SeaTunnel on Kubernetes, leveraging its elastic scaling features to achieve on-demand allocation of computing resources, further optimizing costs and efficiency, and better embracing hybrid cloud and multi-cloud strategies. (1) Full cloud native adoption : Build AIOps capabilities based on the rich Metrics data collected, realizing intelligent prediction of task performance, automatic root cause analysis of faults, and intelligent parameter tuning. (2) Intelligent O&M 6 Pripažinimai Čia nuoširdžiai dėkojame atviro kodo „Apache SeaTunnel“ bendruomenei.Tuo pačiu metu taip pat dėkojame kiekvienam įmonės vidaus projekto komandos nariui – jūsų sunkus darbas ir drąsa ištirti yra sėkmingo šios architektūros atnaujinimo įgyvendinimo raktas. „SUPCON“ išmetė „Siloed“ duomenų įrankius „Apache SeaTunnel“ – dabar pagrindinės sinchronizavimo užduotys veikia „0-failure“! 99% mažiau gedimų, 100% nuoseklumas, 70% mažiau O&M išlaidų.
