Inleiding: Voor bedrijven is de kernuitdaging van gegevensverzameling nooit louter "synchronisatie" geweest, maar hoe gegevensnauwkeurigheid, integriteit en tijdigheid kunnen worden gewaarborgd in een grootschalige, heterogene en complexe omgeving.Dit artikel onderzoekt SUPCON's praktijk van het bouwen van een kader voor gegevensverzameling op bedrijfsniveau op basis van Apache SeaTunnel, gericht op het delen van specifieke inzichten en oplossingen in aspecten zoals clusterhoge beschikbaarheidconfiguratie, prestatieoptimalisatie, fouttolerantiemechanismen en gegevenskwaliteitsmonitoring. Inleiding: Voor bedrijven is de kernuitdaging van gegevensverzameling nooit louter "synchronisatie" geweest, maar hoe gegevensnauwkeurigheid, integriteit en tijdigheid kunnen worden gewaarborgd in een grootschalige, heterogene en complexe omgeving.Dit artikel onderzoekt SUPCON's praktijk van het bouwen van een kader voor gegevensverzameling op bedrijfsniveau op basis van Apache SeaTunnel, gericht op het delen van specifieke inzichten en oplossingen in aspecten zoals clusterhoge beschikbaarheidconfiguratie, prestatieoptimalisatie, fouttolerantiemechanismen en gegevenskwaliteitsmonitoring. Dilemma: Siloed Collection Architecture en hoge operationele en onderhoudskosten Als een industrieel AI-platformbedrijf dat de procesindustrie diep macht geeft, heeft het wereldwijde bedrijfsleven van SUPCON zich voortdurend ontwikkeld. Op dit moment heeft het bijna 40 wereldwijde dochterondernemingen en bedient het meer dan 35.000 wereldwijde klanten. De voortdurende uitbreiding van het bedrijfsleven heeft hogere eisen gesteld aan gegevenswerk: gegevens moeten niet alleen "snel worden berekend" maar ook "nauwkeurig worden geland". Hiertoe hebben we een stroom-batch gescheiden big data-platform gebouwd om complexe scenario's aan te pakken. : In het verleden vertrouwden we lange tijd op oplossingen bestaande uit meerdere tools (zoals het gebruik van Sqoop voor batch data synchronisatie naar HDFS, en Maxwell/StreamSets om database incrementele logs te verwerken en ze te schrijven naar Kafka/Kudu). (1) Complex Architecture with Silos Het ontbreken van een uniforme monitoring- en waarschuwingsmechanisme betekent dat eventuele afwijkingen (zoals synchronisatievertragingen, uitputting van middelen) veel arbeidskrachten vereisen voor probleemoplossing en "brandbestrijding", waardoor het moeilijk is om stabiliteit te waarborgen. (2) O&M Black Hole, Constantly Firefighting : Wanneer we geconfronteerd worden met nieuwe gegevensbronnen (zoals binnenlandse databases en SAP HANA), moeten we aanpassingsoplossingen vinden in verschillende tools of onafhankelijk plug-ins ontwikkelen, waardoor het onmogelijk is om snel te reageren op zakelijke behoeften. (3) Segmented Capabilities, Difficult to Expand De bovenstaande figuur toont duidelijk het voorheen gedecentraliseerde verzamelecosysteem.We realiseren ons dat dit "disorganiseerde" model de meest kwetsbare link in de gegevensverwerking is geworden.Het niet alleen niet overeenkomt met de toekomstige ontwikkelingssnelheid van het bedrijf, maar ook potentiële bedreigingen vormt voor de kwaliteit en tijdigheid van de gegevens.Het bouwen van een verenigd, stabiel en efficiënt kader voor gegevensverzameling is cruciaal en dringend geworden. Breken van het dilemma: gedachten over een Unified Collection Framework en technologische selectie Na diepgaande analyse en nadenken hebben we de vijf kern selectiecriteria voor nieuwe technologieën verduidelijkt: : Het moet volledig alle huidige en toekomstige gegevensbrontypen van het bedrijf (van MySQL, Oracle, HANA tot Kafka, StarRocks, enz.) en ondersteunen zowel offline als real-time verzamelmodi, fundamenteel het probleem van eenvormige technologie stacks op te lossen. (1) Comprehensive Connectivity Het framework zelf moet een zeer beschikbare gedistribueerde cluster zijn met een sterke fouttolerantie.Zelfs als een enkele knoop faalt, mag de gehele service niet worden onderbroken en kan automatisch worden hersteld, waardoor de continue werking van de gegevensverzamelpijplijn wordt gewaarborgd. (2) Cluster Stability and High Availability Op het niveau van taakuitvoering moet het exact-een of minstens-een keer verwerkingssemantiek bieden om ervoor te zorgen dat taken automatisch kunnen herstellen van breakouts na abnormale onderbrekingen, waardoor data-duplicatie of -verlies wordt geëlimineerd, wat de hoeksteen is van gegevenskwaliteit. (3) Reliable Data Consistency Guarantee De architectuur moet horizontale uitbreiding ondersteunen, en de synchronisatieprestaties kunnen lineair worden verbeterd door knooppunten toe te voegen om te voldoen aan de behoeften aan gegevensgroei die worden gebracht door de snelle ontwikkeling van het bedrijf. (4) Strong Throughput Performance Het moet een compleet monitoring- en waarschuwingsmechanisme bieden, dat belangrijke indicatoren zoals afwijkingen, vertragingen en doorvoer tijdens gegevenssynchronisatie in realtime kan volgen en operationeel en onderhoudspersoneel tijdig kan informeren, waardoor passief "vuurbestrijding" wordt omgezet in actieve "vroege waarschuwing". (5) Observable O&M Experience Op basis van deze vijf criteria hebben we diepgaand onderzoek en vergelijkende tests uitgevoerd op mainstream oplossingen in de industrie.Ten slotte heeft Apache SeaTunnel in alle dimensies uitstekend gepresteerd en is het onze optimale oplossing geworden om het dilemma te doorbreken. 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. Algemene connectiviteit Het heeft een uiterst rijk Connector-ecosysteem, dat officieel ondersteuning biedt voor het lezen en schrijven van honderden bronnen / bestemmingsdatabases, die volledig alle gegevenstypen dekken. Clusterstabiliteit en hoge beschikbaarheid De gescheiden architectuur van SeaTunnel Engine zorgt ervoor dat zelfs als een enkele Master of Worker-knop abnormaal is, het de continuïteit van de verzamelwerkzaamheden niet beïnvloedt. Betrouwbare gegevensconsistentie garantie Het biedt een krachtig fouttolerantiemechanisme, ondersteunt Exactly-Once-semantiek en kan automatische breakpoint-heropening realiseren na taakafwijkingen via het Checkpoint-mechanisme, waardoor geen gegevensverlies of duplicatie wordt gewaarborgd. Sterke doorvoerprestaties Parallelisme kan worden aangepast door middel van eenvoudige configuratie, gemakkelijk te realiseren horizontale uitbreiding. O&M ervaringen Het biedt rijke monitoringindicatoren en kan naadloos worden geïntegreerd met mainstream monitoring- en waarschuwingssystemen zoals Prometheus, Grafana en AlertManager, waardoor we een duidelijk begrip van het gegevensverzamelingsproces kunnen hebben. Praktijk: Speciale uitvoeringsplannen en details In de vroege stadia hebben we gebouwd op basis van Apache SeaTunnel v2.3.5. Op dat moment, om te voldoen aan een aantal specifieke behoeften (zoals het omgaan met kwesties van casusgevoeligheid van verschillende database tabellennamen of veldnamen), hebben we wat secundaire ontwikkeling werk uitgevoerd. Toen we de cluster met succes upgraden naar Apache SeaTunnel v2.3.11, waren we aangenaam verbaasd om te ontdekken dat de behoeften die vroeger vereiste aangepaste ontwikkeling nu natief worden ondersteund in de nieuwe versie. Momenteel worden al onze data-synchronisatieopdrachten uitgevoerd op basis van de officiële versie, waarbij nul modificatie wordt bereikt, wat onze langetermijnonderhoudskosten aanzienlijk vermindert en ons in staat stelt naadloos te genieten van de nieuwste functies en prestatieverbeteringen die door de gemeenschap worden gebracht. De volgende zijn onze kernimplementatieplannen op basis van versie v2.3.11, die zijn geverifieerd op basis van TB-niveau gegevensvolume in de productieomgeving en een solide basis hebben gelegd voor de uitstekende prestaties van 0 storingen sinds de cluster werd gebouwd. 1) Clusterplanning Om de hoge beschikbaarheid van de cluster te garanderen, wordt aanbevolen om prioriteit te geven aan de implementatie van een afzonderlijke mode cluster. 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 Meester 01 8c 32g 200g 30g Meester 02 8c 32g 200g 30g Werknemer 01 16c 64g 500g 62g Werknemer 02 16c 64g 500g 62g Werknemer-03 16c 64g 500g 62g (2) Key Cluster Configuration-bestanden 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) Voorbeelden van collectieve taken ① MySQL-CDC to StarRocks Om MySQL-CDC-gegevens te verzamelen, is het noodzakelijk om ervoor te zorgen dat de brondatabase Binlog met het formaat van ROW heeft ingeschakeld, de gebruiker relevante machtigingen heeft en het overeenkomstige MySQL Jar-pakket wordt geplaatst in de directory. Voor details, verwijzen naar de officiële website: . ${SEATUNNEL_HOME}/lib https://seatunnel.apache.org/docs/2.3.11/connector-v2/source/MySQL-CDC Het volgende is een voorbeeldconfiguratie voor onze MySQL-CDC-collectie. 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 Om Oracle-CDC-gegevens te verzamelen, zorgt u ervoor dat de brondatabase Logminer heeft ingeschakeld, de gebruiker beschikt over relevante machtigingen en plaatst u de overeenkomstige OJDBC.Jar- en Orai18n.jar-pakketten in de directory. Voor details, verwijzen naar de officiële website: . ${SEATUNNEL_HOME}/lib https://seatunnel.apache.org/docs/2.3.11/connector-v2/source/Oracle-CDC Opmerkelijk, met betrekking tot latentieproblemen die tijdens Oracle-CDC-verzameling worden geconfronteerd, raden we aan om eerst de DBA te vragen om te controleren hoe vaak Logminer-logboeken worden overschakeld. De officiële aanbeveling is om het ongeveer 10 keer per uur te houden – te vaak overschakelen kan een langdurige latentie veroorzaken. Als de frequentie te hoog is, verhoog dan de grootte van individuele logbestanden. -- 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#; Het volgende is een voorbeeldconfiguratie voor onze Oracle-CDC-collectie. 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) Bewakende monitoring Dankzij de krachtige monitoringsmetricen van de nieuwe versie van SeaTunnel en het uitgebreide monitoringssysteem dat we hebben gebouwd, kunnen we de status van het gegevensverzamelplatform volledig begrijpen vanuit zowel cluster- als taakniveauperspectieven. ① Cluster Monitoring Node status: Real-time monitoring van het aantal cluster knooppunten en hun overlevingsstatus om geen abnormale offline van Worker knooppunten te garanderen en clusterverwerkingsmogelijkheden te garanderen. Cluster doorvoer: Monitor de algehele SourceReceivedQPS en SinkWriteQPS van de cluster om de wereldwijde gegevensin- en uitstroomcijfers te begrijpen en de clusterbelasting te evalueren. Resource status: Monitor de CPU en het geheugen van cluster knooppunten om een basis te bieden voor uitbreiding of optimalisatie van middelen. Netwerkgezondheid: Zorg voor goede clusternetwerkomstandigheden door de interne hartslag en communicatie latency te controleren. ② Task Monitoring Status van de uitvoering van de taak: Echttijds controleren van de uitvoeringstoestand (Running/Failed/Finished) van alle taken is de meest elementaire vereiste van monitoring. Gegevenssynchronisatievolume: Monitor de SourceReceivedCount en SinkWriteCount van elke taak om de doorvoer van elke gegevenspijplijn in realtime te begrijpen. Latency time: Dit is een van de meest kritische indicatoren voor CDC-taken. waarschuwingen worden verzonden wanneer continu latency optreedt aan het eind van de verzameling. Resultaten: meetbare voordelen Na een periode van stabiele werking heeft het op Apache SeaTunnel gebaseerde framework voor het verzamelen van gegevens van de volgende generatie aanzienlijke en meetbare voordelen opgeleverd, voornamelijk in de volgende aspecten: (1) Stabiliteit: van “Constant Firefighting” tot “Peace of Mind” : 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) Efficiëntie: verdubbelde ontwikkeling en O&M efficiëntie : 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 Architectuur: Resource Optimization en Unified Framework : 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 Perspectief: toekomstige plannen : 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 erkenning Tegelijkertijd bedanken we ook elk lid van het interne projectteam van het bedrijf – uw harde werk en moed om te verkennen zijn de sleutels voor de succesvolle implementatie van deze architectuurupgrade. SUPCON dumped siloed data tools for Apache SeaTunnel—nu kern synchronisatie taken run 0-failure! 99% lagere storingen, 100% consistentie, 70% minder O&M kosten.
