Úvod: Pro podniky nebyla hlavní výzvou shromažďování dat nikdy pouhá „synchronizace“, ale jak zajistit přesnost, integritu a aktuálnost dat v rozsáhlém, heterogenním a složitém prostředí. Tento článek se zabývá praxí společnosti SUPCON při vytváření rámce pro shromažďování dat na úrovni podniku založeného na Apache SeaTunnelu, se zaměřením na sdílení specifických poznatků a řešení v oblastech, jako je konfigurace s vysokou dostupností klastrů, optimalizace výkonu, mechanismy tolerance chyb a monitorování kvality dat. Úvod: Pro podniky nebyla hlavní výzvou shromažďování dat nikdy pouhá „synchronizace“, ale jak zajistit přesnost, integritu a aktuálnost dat v rozsáhlém, heterogenním a složitém prostředí. Tento článek se zabývá praxí společnosti SUPCON při vytváření rámce pro shromažďování dat na úrovni podniku založeného na Apache SeaTunnelu, se zaměřením na sdílení specifických poznatků a řešení v oblastech, jako je konfigurace s vysokou dostupností klastrů, optimalizace výkonu, mechanismy tolerance chyb a monitorování kvality dat. Dilema: Siloed Collection Architecture a vysoké náklady na provoz a údržbu Jako společnost s průmyslovou platformou AI, která hluboce posiluje procesní průmysl, se globální podnikání společnosti SUPCON neustále rozvíjí. V současné době má téměř 40 globálních dceřiných společností a slouží více než 35 000 globálním zákazníkům. Neustálé rozšiřování podnikání klade vyšší požadavky na práci s daty: data musí být nejen „rychle vypočtena“, ale také „přesně přistála“. Za tímto účelem jsme vybudovali velkou datovou platformu pro řešení složitých scénářů. Avšak složitost samotné platformy naopak zvýšila obtížnost shromažďování dat, vývoje a provozu a údržby, zejména ve zdrojovém odkazu shromažďování dat, kde čelíme vážným výzvám: : V minulosti jsme se dlouho spoléhali na řešení složená z více nástrojů (například pomocí Sqoop pro synchronizaci bateriových dat s HDFS a Maxwell/StreamSets pro zpracování databázových incrementálních protokolů a jejich psaní do Kafky/Kudu). (1) Complex Architecture with Silos Nedostatek jednotného monitorovacího a varovného mechanismu znamená, že jakákoli abnormalita (jako jsou zpoždění synchronizace, vyčerpání zdrojů) vyžaduje spoustu pracovní síly pro odstraňování problémů a „požáry“, což ztěžuje zajištění stability. (2) O&M Black Hole, Constantly Firefighting : Když čelíme novým zdrojům dat (jako jsou domácí databáze a SAP HANA), musíme najít adaptační řešení v různých nástrojích nebo samostatně vyvíjet pluginy, což znemožňuje rychlou reakci na obchodní potřeby. (3) Segmented Capabilities, Difficult to Expand Výše uvedený obrázek jasně ukazuje dříve decentralizovaný ekosystém sběru. Uvědomili jsme si, že tento „dezorganizovaný“ model se stal nejzranitelnějším článkem v oblasti zpracování dat. Nejen, že selhává s budoucí rychlostí vývoje společnosti, ale také představuje potenciální hrozby pro kvalitu a včasnost dat. Budování jednotného, stabilního a efektivního rámce sběru dat se stalo rozhodujícím a naléhavým. Rozbít dilema: myšlenky na Unified Collection Framework a technologický výběr Po důkladné analýze a přemýšlení jsme objasnili pět základních kritérií pro výběr nových technologií: Měl by plně pokrýt všechny současné a budoucí typy zdrojů dat společnosti (od MySQL, Oracle, HANA až po Kafku, StarRocks atd.) a podporovat režimy sběru offline i v reálném čase, což zásadně řeší problém sjednocených technologických hromad. (1) Comprehensive Connectivity : Samotný rámec musí být vysoce dostupným distribuovaným klastrem se silnou chybovou tolerancí. Dokonce i v případě selhání jednoho uzlu by neměla být celá služba přerušena a může se automaticky obnovit, což zajišťuje nepřetržitý provoz potrubí pro sběr dat. (2) Cluster Stability and High Availability Na úrovni provádění úkolů musí poskytnout sémantiku zpracování Exactly-Once nebo At-Last-Once, aby se zajistilo, že úkoly se mohou automaticky zotavit z přerušení po abnormálních přerušeních, čímž se eliminuje duplicita nebo ztráta dat, což je základním kamenem kvality dat. (3) Reliable Data Consistency Guarantee Jeho architektura by měla podporovat horizontální expanzi a výkon synchronizace lze lineárně zlepšit přidáním uzlů k uspokojení potřeb růstu dat, které přináší rychlý rozvoj podnikání. (4) Strong Throughput Performance Musí poskytnout kompletní monitorovací a výstražný mechanismus, který může sledovat klíčové ukazatele, jako jsou abnormality, zpoždění a průtok během synchronizace dat v reálném čase, a včas informovat provozní a údržbářský personál, čímž přemění pasivní "požární boj" na aktivní "časné varování". (5) Observable O&M Experience Na základě těchto pěti kritérií jsme provedli hloubkový výzkum a srovnávací testování mainstreamových řešení v průmyslu.Konečně, Apache SeaTunnel se ve všech dimenzích vydařil výborně a stal se naším optimálním řešením pro překonání dilematu. 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. Komplexní konektivita Má extrémně bohatý ekosystém Connector, který oficiálně podporuje čtení a psaní stovek zdrojových / cílových databází, které plně pokrývají všechny naše typy dat. Jeden rámec může sjednotit offline a sběr v reálném čase. Stabilita clusteru a vysoká dostupnost Samostatná architektura SeaTunnel Engine zajišťuje, že i když je jediný Master nebo Worker uzel abnormální, nebude to mít vliv na kontinuitu úkolů sběru. Spolehlivá záruka konzistence dat Poskytuje výkonný mechanismus tolerance chyb, podporuje sémantiku Exactly-Once a může realizovat automatické obnovení rozpadového bodu po abnormalitách úkolů prostřednictvím mechanismu Checkpoint, což zajišťuje, že nejsou ztracena ani duplikována data. Silný průchod výkonem Má vynikající schopnosti zpracování distribuovaných dat. Paralelismus lze nastavit pomocí jednoduché konfigurace, snadno realizující horizontální expanzi. Pozoruhodné O&M zkušenosti Poskytuje bohaté monitorovací ukazatele a může být bezproblémově integrován s mainstreamovými monitorovacími a varovnými systémy, jako jsou Prometheus, Grafana a AlertManager, což nám umožňuje mít jasné pochopení procesu sběru dat. Pracovní postup: Specifické plány a podrobnosti provádění V počáteční fázi jsme stavěli na základě Apache SeaTunnel v2.3.5. V té době, abychom splnili některé specifické potřeby (jako je řešení problémů s citlivostí případů různých názvů tabulek databází nebo názvů polí), provedli jsme nějakou druhotnou vývojovou práci. Když jsme úspěšně upgradovali klastr na Apache SeaTunnel v2.3.11, byli jsme příjemně překvapeni, že potřeby, které dříve vyžadovaly vlastní vývoj, jsou nyní v nové verzi nativně podporovány. V současné době jsou všechny naše úkoly synchronizace dat realizovány na základě oficiální verze, dosahující nulové modifikace, což výrazně snižuje naše dlouhodobé náklady na údržbu a umožňuje nám bezproblémově využívat nejnovější funkce a vylepšení výkonu přinášené komunitou. Níže jsou uvedeny naše základní implementační plány založené na verzi v2.3.11, které byly ověřeny objemem dat na úrovni TB ve výrobním prostředí a položily pevný základ pro vynikající výkon 0 selhání od doby, kdy byl klastr postaven. 1) Plánování klastrů Abychom zajistili vysokou dostupnost klastru, doporučujeme upřednostnit nasazení samostatného klastru režimu. 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 Mistři-01 8C 32g 200g 30 g Mistrovství 02 8C 32g 200g 30 g Pracovník 01 16C 64g 500g 62g Pracovníci 02 16C 64g 500g 62g Pracovníci-03 16C 64g 500g 62g (2) Klíčové soubory konfigurace klastrů 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) Příklady sběrných úkolů ① MySQL-CDC to StarRocks Chcete-li shromažďovat data MySQL-CDC, je nutné zajistit, aby zdrojová databáze povolila Binlog s formátem ROW, uživatel má příslušná oprávnění a odpovídající balíček MySQL Jar je umístěn v Pro podrobnosti, prosím navštivte oficiální webové stránky: . ${SEATUNNEL_HOME}/lib https://seatunnel.apache.org/docs/2.3.11/connector-v2/source/MySQL-CDC Následuje vzorová konfigurace pro naši sbírku MySQL-CDC. 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 Chcete-li shromažďovat data Oracle-CDC, ujistěte se, že zdrojová databáze má Logminer povolen, uživatel má příslušná oprávnění a umístěte odpovídající balíky OJDBC.Jar a Orai18n.jar do Pro podrobnosti navštivte oficiální webové stránky: . ${SEATUNNEL_HOME}/lib https://seatunnel.apache.org/docs/2.3.11/connector-v2/source/Oracle-CDC Zvláště pokud jde o problémy se zpožděním, se kterými se setkáváte během sběru Oracle-CDC, doporučujeme nejprve požádat DBA, aby zkontrolovala, jak často jsou logminerové protokoly přepínány. Oficiální doporučení je udržet je kolem 10krát za hodinu – příliš časté přepínání může způsobit prodlouženou latenci. Pokud je frekvence příliš vysoká, zvýšit velikost jednotlivých protokolových souborů. -- 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#; Následuje vzorová konfigurace pro naši kolekci Oracle-CDC. 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) Pozorovatelné sledování Díky výkonným monitorovacím měřicím parametrům poskytovaným novou verzí SeaTunnelu a komplexnímu monitorovacímu systému, který jsme vybudovali, můžeme plně pochopit stav platformy pro sběr dat jak z pohledu celé skupiny, tak z pohledu na úkoly. ① Cluster Monitoring Stav uzlu: Real-time monitorování počtu klastrových uzlin a jejich stavu přežití, aby se zajistilo, že žádné abnormální offline Worker uzly a zaručit schopnosti zpracování klastru. Clusterový průtok: Monitorujte celkový SourceReceivedQPS a SinkWriteQPS klastru, abyste pochopili celkové míry přílivu a výstupu dat a vyhodnotili zatížení klastru. Stav zdrojů: Monitorování procesoru a paměti klastrových uzlin poskytuje základ pro rozšíření nebo optimalizaci zdrojů. Zdraví sítě: Zajištění dobrých podmínek sítě klastrů monitorováním vnitřního srdečního tepu a latence komunikace. ② Task Monitoring Stav provozu úkolů: Kontrola aktuálního stavu všech úkolů v reálném čase (Běh/Neúspěch/Dokončení) je nejzákladnějším požadavkem monitorování. Synchronizace objemu dat: Sledujte SourceReceivedCount a SinkWriteCount každého úkolu, abyste získali průtok každého datového potrubí v reálném čase. Čas latence: Jedná se o jeden z nejdůležitějších ukazatelů pro úkoly CDC. Upozornění se odesílají, když se na konci sběru vyskytne kontinuální latence. Výsledky: měřitelné přínosy Po období stabilního provozu nám rámec pro sběr dat nové generace postavený na Apache SeaTunnelu přinesl významné a měřitelné výhody, které se odrážejí především v následujících aspektech: (1) Stabilita: Od „konstantního protipožárního boje“ k „míru mysli“ : 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) Efektivita: zdvojnásobený rozvoj a efektivita O&M : 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 Architektura: optimalizace zdrojů a jednotný rámec : 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 Výhled: Plány do budoucna : 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. uznání Zároveň také děkujeme každému členovi interního projektového týmu společnosti – vaše tvrdá práce a odvaha k prozkoumání jsou klíčem k úspěšné realizaci této modernizace architektury. SUPCON dumped siloed datové nástroje pro Apache SeaTunnel – nyní základní synchronizační úkoly běží 0-zlyšení! 99% nižší selhání, 100% konzistence, 70% méně O&M náklady. Velké díky @ApacheSeaTunnel! #DataEngineering #OpenSource
