Einführung: Für Unternehmen war die zentrale Herausforderung bei der Datenerhebung nie nur die "Synchronisierung", sondern auch, wie Datengenauigkeit, Integrität und Aktualität in einem groß angelegten, heterogenen und komplexen Umfeld sichergestellt werden können.Dieser Artikel untersucht die Praxis von SUPCON beim Aufbau eines Datenerhebungsrahmens auf Unternehmensebene auf der Grundlage von Apache SeaTunnel und konzentriert sich auf den Austausch spezifischer Erkenntnisse und Lösungen in Aspekten wie Cluster-Hochverfügbarkeits-Konfiguration, Leistungsoptimierung, Fehlertoleranzmechanismen und Datenqualitätsüberwachung. Einführung: Für Unternehmen war die zentrale Herausforderung bei der Datenerhebung nie nur die "Synchronisierung", sondern auch, wie Datengenauigkeit, Integrität und Aktualität in einem groß angelegten, heterogenen und komplexen Umfeld sichergestellt werden können.Dieser Artikel untersucht die Praxis von SUPCON beim Aufbau eines Datenerhebungsrahmens auf Unternehmensebene auf der Grundlage von Apache SeaTunnel und konzentriert sich auf den Austausch spezifischer Erkenntnisse und Lösungen in Aspekten wie Cluster-Hochverfügbarkeits-Konfiguration, Leistungsoptimierung, Fehlertoleranzmechanismen und Datenqualitätsüberwachung. Dilemma: Siloed Collection Architecture und hohe Betriebs- und Wartungskosten Als ein industrielles AI-Plattformunternehmen, das die Prozessindustrie tief ermächtigt, hat sich das globale Geschäft von SUPCON kontinuierlich weiterentwickelt. Derzeit verfügt es über fast 40 globale Tochtergesellschaften und bedient mehr als 35.000 globale Kunden. Die kontinuierliche Expansion des Geschäfts hat höhere Anforderungen an die Datenarbeit gestellt: Daten müssen nicht nur "schnell berechnet" werden, sondern auch "genau gelandet" werden. Zu diesem Zweck haben wir eine Stream-batch-separierte Big Data-Plattform gebaut, um komplexe Szenarien zu bewältigen. : In der Vergangenheit haben wir uns lange auf Lösungen verlassen, die aus mehreren Tools bestehen (z. B. mit Sqoop zur Batch-Datensynchronisierung mit HDFS und Maxwell/StreamSets zur Verarbeitung von Datenbank-Inkrementallogs und zum Schreiben in Kafka/Kudu). (1) Complex Architecture with Silos Die Abwesenheit eines einheitlichen Überwachungs- und Warnmechanismus bedeutet, dass jegliche Anomalien (wie Synchronisierungsverzögerungen, Ressourcenverschwendung) eine Menge Arbeitskraft für die Fehlerbehebung und "Feuerwehr" erfordern, was es schwierig macht, Stabilität zu gewährleisten. (2) O&M Black Hole, Constantly Firefighting : Bei der Konfrontation mit neuen Datenquellen (z.B. inländische Datenbanken und SAP HANA) müssen wir Anpassungslösungen in verschiedenen Tools finden oder Plug-ins unabhängig entwickeln, was es unmöglich macht, schnell auf geschäftliche Bedürfnisse zu reagieren. (3) Segmented Capabilities, Difficult to Expand Das obige Bild zeigt deutlich das zuvor dezentralisierte Sammelökosystem.Wir haben erkannt, dass dieses "unorganisierte" Modell zum anfälligsten Bindeglied in der Datenverarbeitung geworden ist.Es ist nicht nur nicht in der Lage, die zukünftige Entwicklungsgeschwindigkeit des Unternehmens zu entsprechen, sondern stellt auch potenzielle Bedrohungen für Datenqualität und -zeitlichkeit dar. 2. Das Dilemma brechen: Gedanken zu einem einheitlichen Sammlungsrahmen und Technologieauswahl Nach eingehender Analyse und Überlegung haben wir die fünf Kernkriterien für die Auswahl neuer Technologien geklärt: : Es sollte alle aktuellen und zukünftigen Datenquelle-Typen des Unternehmens (von MySQL, Oracle, HANA bis Kafka, StarRocks usw.) vollständig abdecken und sowohl Offline- als auch Echtzeit-Sammlungsmodi unterstützen, was das Problem der einheitlichen Technologie-Stapel grundlegend löst. (1) Comprehensive Connectivity : Das Framework selbst muss ein hochverfügbarer verteilter Cluster mit starker Fehlertoleranz sein. Selbst wenn ein einzelner Knoten fehlschlägt, sollte der gesamte Service nicht unterbrochen werden und kann automatisch wiederhergestellt werden, was den kontinuierlichen Betrieb der Datenerfassungspipeline gewährleistet. (2) Cluster Stability and High Availability : Auf der Ebene der Aufgabenausführung muss es die Semantik für die Verarbeitung Exactly-Once oder At-Least-Once bereitstellen, um sicherzustellen, dass Aufgaben nach abnormalen Unterbrechungen automatisch von Unterbrechungen wiederhergestellt werden können, wodurch Datenduplikation oder -verlust beseitigt wird, was der Grundstein für die Datenqualität ist. (3) Reliable Data Consistency Guarantee Ihre Architektur sollte die horizontale Expansion unterstützen, und die Synchronisierungsleistung kann linear verbessert werden, indem Knoten hinzugefügt werden, um den Datenwachstumsbedürfnissen zu entsprechen, die durch die schnelle Entwicklung des Geschäfts entstehen. (4) Strong Throughput Performance Es muss einen vollständigen Überwachungs- und Warnmechanismus bereitstellen, der wichtige Indikatoren wie Abnormalitäten, Verzögerungen und Durchsatz während der Datensynchronisierung in Echtzeit verfolgen und Betriebs- und Wartungspersonal rechtzeitig benachrichtigen kann, wodurch die passive "Feuerwehr" in eine aktive "Frühwarnung" umgewandelt wird. (5) Observable O&M Experience Auf der Grundlage dieser fünf Kriterien führten wir eingehende Forschungen und vergleichende Tests auf Mainstream-Lösungen in der Branche durch. schließlich hat Apache SeaTunnel in allen Dimensionen hervorragende Leistungen erzielt und wurde zu unserer optimalen Lösung, um das Dilemma zu brechen. 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. umfassende Konnektivität Es verfügt über ein extrem reichhaltiges Connector-Ökosystem, das offiziell das Lesen und Schreiben von Hunderten von Quell- / Zieldatenbanken unterstützt und alle unsere Datentypen vollständig abdeckt. Cluster Stabilität und hohe Verfügbarkeit Die getrennte Architektur von SeaTunnel Engine sorgt dafür, dass selbst wenn ein einzelner Master- oder Worker-Node abnormal ist, dies die Kontinuität der Sammelaufgaben nicht beeinträchtigt. Zuverlässige Datenkonsistenzgarantie Es bietet einen leistungsstarken Fehler-Toleranz-Mechanismus, unterstützt Exactly-Once-Semantik und kann automatische Breakpoint-Wiederholung nach Aufgabenabnormalitäten über den Checkpoint-Mechanismus realisieren, wodurch kein Datenverlust oder Duplizierung sichergestellt wird. Starke Durchlaufleistung Es verfügt über ausgezeichnete verteilte Datenverarbeitungsfähigkeiten.Parallelismus kann durch einfache Konfiguration angepasst werden, wodurch die horizontale Expansion leicht realisiert wird. Sehenswerte O&M Erfahrungen Es bietet reiche Überwachungsindikatoren und kann nahtlos mit Mainstream-Überwachungs- und Alarmsystemen wie Prometheus, Grafana und AlertManager integriert werden, so dass wir ein klares Verständnis des Datenerfassungsvorgangs haben können. 3. Praxis: Spezifische Umsetzungspläne und Details Unsere Praxis mit Apache SeaTunnel ist auch der Wachstumspfad des Projekts.In der frühen Phase haben wir auf der Grundlage von Apache SeaTunnel v2.3.5 gebaut. Zu dieser Zeit haben wir, um einige spezifische Bedürfnisse zu erfüllen (wie zum Beispiel die Bearbeitung von Fallempfindlichkeitsproblemen verschiedener Datenbanktabellen oder Feldnamen), einige sekundäre Entwicklungsarbeiten durchgeführt. Als wir den Cluster erfolgreich auf Apache SeaTunnel v2.3.11 aktualisiert haben, waren wir angenehm überrascht zu entdecken, dass die Bedürfnisse, die zuvor eine benutzerdefinierte Entwicklung erforderten, jetzt in der neuen Version nativ unterstützt werden. Derzeit werden alle unsere Datensynchronisierungsaufgaben auf der Grundlage der offiziellen Version implementiert, wobei Null Modifikation erzielt wird, was unsere langfristigen Wartungskosten erheblich senkt und uns ermöglicht, nahtlos die neuesten Funktionen und Leistungsverbesserungen der Community zu genießen. Im Folgenden finden Sie unsere Kernimplementierungspläne, die auf der Version v2.3.11 basieren, die nach dem Datenvolumen auf TB-Ebene in der Produktionsumgebung verifiziert wurden und eine solide Grundlage für die hervorragende Leistung von 0 Ausfällen seit dem Bau des Clusters gelegt haben. 1) Clusterplanung Um die hohe Verfügbarkeit des Clusters zu gewährleisten, wird empfohlen, die Bereitstellung eines separaten Modus-Clusters zu priorisieren. 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 Meister 01 8c 32g 200g 30g Meister 02 8c 32g 200g 30g Arbeiter 01 16c 64g 500g 62g Arbeiter 02 16c 64g 500g 62g Arbeiter 03 16c 64g 500g 62g (2) Key Cluster Konfigurationsdateien 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) Sammlung von Aufgabenbeispielen ① MySQL-CDC to StarRocks Um MySQL-CDC-Daten zu sammeln, ist es notwendig sicherzustellen, dass die Quelldatenbank Binlog mit dem Format von ROW aktiviert hat, der Benutzer über die entsprechenden Berechtigungen verfügt und das entsprechende MySQL Jar-Paket in die Verzeichnis. Für Details, bitte auf die offizielle Website: . ${SEATUNNEL_HOME}/lib https://seatunnel.apache.org/docs/2.3.11/connector-v2/source/MySQL-CDC Im Folgenden finden Sie eine Musterkonfiguration für unsere MySQL-CDC-Sammlung. 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 Um Oracle-CDC-Daten zu sammeln, stellen Sie sicher, dass die Quelldatenbank Logminer aktiviert hat, der Benutzer über die entsprechenden Berechtigungen verfügt und die entsprechenden OJDBC.Jar- und Orai18n.jar-Pakete in die Verzeichnis. Für Details, besuchen Sie die offizielle Website: . ${SEATUNNEL_HOME}/lib https://seatunnel.apache.org/docs/2.3.11/connector-v2/source/Oracle-CDC Hinzu kommt, dass in Bezug auf Latenzprobleme, die während der Oracle-CDC-Sammlung aufgetreten sind, wir empfehlen, zunächst den DBA zu bitten, zu überprüfen, wie häufig Logminer-Protokolle gewechselt werden. Die offizielle Empfehlung besteht darin, sie etwa 10 Mal pro Stunde zu behalten – zu häufiges Wechseln kann zu längerer Latenz führen. Wenn die Frequenz zu hoch ist, erhöhen Sie die Größe einzelner Log-Dateien. -- 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#; Im Folgenden finden Sie eine Musterkonfiguration für unsere Oracle-CDC-Kollektion. 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. Beobachtbare Überwachung Dank der leistungsstarken Überwachungsmetriken der neuen SeaTunnel-Version und des umfassenden Überwachungssystems, das wir gebaut haben, können wir den Status der Datenerfassungsplattform sowohl auf Cluster- als auch auf Aufgabenebene vollständig erfassen. ① Cluster Monitoring Node-Status: Echtzeitüberwachung der Anzahl der Cluster-Nodes und ihres Überlebensstatus, um keine abnormalen Offline von Worker-Nodes zu gewährleisten und Cluster-Verarbeitungsfähigkeiten zu garantieren. Cluster Durchsatz: Überwachen Sie die Gesamt SourceReceivedQPS und SinkWriteQPS des Clusters, um die globalen Dateneingangs- und Ausflussraten zu erfassen und die Clusterlast zu bewerten. Ressourcenstatus: Überwachen Sie die CPU und den Speicher von Cluster-Knoten, um eine Grundlage für die Erweiterung oder Optimierung von Ressourcen zu schaffen. Netzwerkgesundheit: Gewährleisten Sie gute Cluster-Netzwerkbedingungen, indem Sie den internen Herzschlag und die Kommunikationslatenz überwachen. ② Task Monitoring Task Operation Status: Echtzeitüberprüfung des laufenden Zustands (Run/Failed/Finished) aller Aufgaben ist die grundlegendste Anforderung der Überwachung. Datensynchronisierungsvolumen: Überwachen Sie den SourceReceivedCount und den SinkWriteCount jeder Aufgabe, um den Durchsatz jeder Datenleitung in Echtzeit zu erfassen. Verzögerungszeit: Dies ist einer der kritischsten Indikatoren für CDC-Aufgaben.Warnungen werden gesendet, wenn eine kontinuierliche Verzögerung am Ende der Sammlung auftritt. 4. Ergebnisse: Messbare Vorteile Nach einer Periode des stabilen Betriebs hat uns das auf Apache SeaTunnel basierende Datenerfassungs-Framework der nächsten Generation erhebliche und messbare Vorteile gebracht, die sich hauptsächlich in den folgenden Aspekten widerspiegeln: (1) Stabilität: Von „Ständiger Feuerwehr“ bis hin zu „Frieden des Geistes“ : 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) Effizienz: Doppelte Entwicklung und O&M Effizienz : 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 Architektur: Ressourcenoptimierung und einheitlicher Rahmen : 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 Ausblick: Zukunftspläne : 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. Anerkennung Gleichzeitig danken wir auch jedem Mitglied des internen Projektteams des Unternehmens – Ihre harte Arbeit und den Mut zu erkunden sind die Schlüssel zur erfolgreichen Implementierung dieses Architektur-Upgrades. SUPCON dumpfte Siloed-Datenwerkzeuge für Apache SeaTunnel – jetzt laufen Kernsynchronisierungsaufgaben 0-Fehler! 99% weniger Fehler, 100% Konsistenz, 70% weniger O&M-Kosten. großes Dankeschön an @ApacheSeaTunnel! #DataEngineering #OpenSource
