企業にとって、データ収集の核心的な課題は決して単なる「同期化」ではなく、大規模で異質で複雑な環境でデータの正確性、完全性、タイミングを確保する方法です。この記事は、クラスターの高可用性構成、パフォーマンス最適化、エラー容忍メカニズム、データ品質モニタリングなどの側面における特定の洞察とソリューションを共有することに焦点を当てたApache SeaTunnelに基づく企業レベルのデータ収集枠組みを構築するSUPCONの実践について説明します。 企業にとって、データ収集の核心的な課題は決して単なる「同期化」ではなく、大規模で異質で複雑な環境でデータの正確性、完全性、タイミングを確保する方法です。この記事は、クラスターの高可用性構成、パフォーマンス最適化、エラー容忍メカニズム、データ品質モニタリングなどの側面における特定の洞察とソリューションを共有することに焦点を当てたApache SeaTunnelに基づく企業レベルのデータ収集枠組みを構築するSUPCONの実践について説明します。 Dilemma: Siloed Collection Architecture and High Operation & Maintenance Costs (シロード・コレクション・アーキテクチャと高い運用・メンテナンスコスト) SUPCONのグローバルビジネスは、プロセス業界を深く強化する産業AIプラットフォーム企業として、継続的に発展してきました。現在、約40のグローバル子会社を擁し、35000を超えるグローバル顧客にサービスを提供しています。ビジネスの継続的な拡大は、データ作業により高い要求を提示しています:データは「迅速に計算する」だけでなく「正確に着陸する」必要があります。この目的のために、私たちは複雑なシナリオに対処するためにストリームバッチ分離のビッグデータプラットフォームを構築しました。しかし、プラットフォーム自体の複雑さは、データ収集、開発、および運用およびメンテナンスの困難を逆に増加させました、特にデータ収集のソースリンクにおいて、深刻 : 過去には、複数のツールで構成されたソリューション(例えば、Sqoopを使用してバッチデータをHDFSに同期し、Maxwell/StreamSetsを使用してデータベースの増加ログを処理してKafka/Kuduに書き込む)を長い間使用していました。 (1) Complex Architecture with Silos 複数の技術ルートは、操作およびメンテナンスの監視の圧力の倍を意味します。統一された監視および警告メカニズムの欠如により、いかなる異常(同期の遅延、資源の枯渇など)は、トラブルシューティングおよび「消防」のための大量の労働力を必要とし、安定性を確保することが困難になります。 (2) O&M Black Hole, Constantly Firefighting : 新たなデータソース(国内データベースやSAP HANAなど)に直面する際には、さまざまなツールで適応ソリューションを見つけるか、プラグインを独立して開発する必要があります。 (3) Segmented Capabilities, Difficult to Expand 上記の数字は、これまで分散化された収集エコシステムを明確に示しています。この「非組織化」モデルが、データ処理における最も脆弱なリンクとなっていることに気付きました。このモデルは、企業の将来の開発速度に合致しないだけでなく、データの質とタイミングに潜在的な脅威をもたらします。 Breaking the Dilemma: Thoughts on a Unified Collection Framework and Technology Selection ユニファイド・コレクション・フレームワークとテクノロジー選択に関する考え方 詳細な分析と思考を経て、新技術の5つのコア選択基準を明確にしました。 すべての現在および将来のデータソースタイプ(MySQL、Oracle、HANAからKafka、StarRocksなど)を完全にカバーし、オフラインおよびリアルタイムの収集モードをサポートし、基本的に統一テクノロジースタックの問題を解決する。 (1) Comprehensive Connectivity : フレームワーク自体は、強力なエラー耐性を持つ高度に利用可能な分散クラスターでなければなりません。たとえ単一のノードが失敗しても、サービス全体が中断されず、自動的に回復することができ、データ収集パイプラインの継続的な動作を保証します。 (2) Cluster Stability and High Availability タスク実行レベルでは、タスクが異常な中断の後に自動的にバラバラから回復できるようにするために、データの重複または損失を排除し、データ品質の基盤であるデータの損失を確保するために、Exactly-OnceまたはAt-Least-Once処理のセマンティクスを提供する必要があります。 (3) Reliable Data Consistency Guarantee そのアーキテクチャは水平拡張をサポートすべきであり、同期パフォーマンスは、ビジネスの急速な発展によって引き起こされるデータ成長のニーズを満たすノードを追加することによって線形的に改善することができる。 (4) Strong Throughput Performance データ同期の際の異常、遅延、通過などの主要な指標をリアルタイムで追跡できる完全な監視および警報メカニズムを提供し、運用およびメンテナンススタッフを適時通知し、被動的な「消防」をアクティブな「早期警報」に変える必要があります。 (5) Observable O&M Experience これらの5つの基準に基づき、我々は業界の主流ソリューションの詳細な研究と比較テストを実施しました。最後に、Apache SeaTunnelはあらゆる次元で優れたパフォーマンスを果たし、この問題を解決するための最適なソリューションとなりました。 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. 総合的な接続 それは非常に豊富なコネクタエコシステムを持っており、公式に何百ものソース/目的地データベースの読み取りと書き込みをサポートし、すべてのデータタイプを完全にカバーしています。 Cluster 安定性と高可用性 SeaTunnel Engineの別々のアーキテクチャにより、単一のマスターまたはワーカーノードが異常である場合でも、収集タスクの継続性に影響を与えません。 データ一貫性の保証 強力なエラー寛容メカニズムを提供し、Exactly-Onceセマンティクスをサポートし、チェックポイントメカニズムを通じてタスク異常後に自動的にブレークポイント再起動を実現し、データの損失や複製を保証しません。 強力なパフォーマンス Throughput それは優れた分散データ処理能力を持っています。パラレリズムはシンプルな構成を通じて調整することができ、容易に水平拡張を実現します。 O&M体験 豊富なモニタリング指標を提供し、Prometheus、Grafana、AlertManagerなどの主流のモニタリングおよび警報システムとシームレスに統合することができ、データ収集プロセスの明確な理解を可能にします。 3.実践:具体的な実施計画と詳細 初期段階では、Apache SeaTunnel v2.3.5 をベースに構築しました。当時、いくつかの特定のニーズを満たすために(例えば、異なるデータベーステーブル名やフィールド名のケース敏感性の問題に対処するなど)、私たちはいくつかの副開発作業を行いました。 しかし、SeaTunnelコミュニティの急速な発展に伴い、新しいバージョンの機能とコンバータはますます完成し、クラスターをApache SeaTunnel v2.3.11にアップグレードしたとき、以前はカスタマイズされた開発を必要としたニーズが新しいバージョンでネイティブにサポートされていることに驚きました。 現在、すべてのデータ同期タスクは公式バージョンに基づいて実装されており、ゼロの変更を達成し、長期的なメンテナンスコストを大幅に削減し、コミュニティが提供する最新の機能とパフォーマンスの向上をシームレスに楽しむことができます。 以下は、バージョン v2.3.11 に基づく、生産環境における TB レベルのデータボリュームで検証され、クラスターが構築されて以来 0 件の失敗の優れたパフォーマンスのための堅固な基盤を築いたコアの実装計画です。 (1)クラスタプランニング クラスターの高可用性を確保するためには、別々のモードクラスターの展開を優先することをお勧めします。 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 マスター-01 8C 32G 200g 30g マスター-02 8C 32G 200g 30g 職人01 16C 64G 500g 62G 労働者02 16C 64G 500g 62G 労働者-03 16C 64G 500g 62G (2) Key Cluster Configuration Files 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)コレクションタスク例 ① MySQL-CDC to StarRocks MySQL-CDC データを収集するには、ソース データベースが Binlog を ROW フォーマットで有効にしていること、ユーザーが関連する権限を持っていること、および関連する MySQL Jar パッケージが ROW フォーマットに配置されていることを確認する必要があります。 詳細については、公式サイトをご参照ください: . ${SEATUNNEL_HOME}/lib https://seatunnel.apache.org/docs/2.3.11/connector-v2/source/MySQL-CDC 以下は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 Oracle-CDC データを収集するには、ソース データベースが Logminer を有効にしていることを確認し、ユーザーが関連する権限を持っていることを確認し、OJDBC.Jar および Orai18n.jar パッケージをインストールします。 詳細については、公式サイトを参照してください: . ${SEATUNNEL_HOME}/lib https://seatunnel.apache.org/docs/2.3.11/connector-v2/source/Oracle-CDC 特に、Oracle-CDC 収集中に発生した遅延問題については、まず DBA にログミナーログがどの程度頻繁に切り替えられているかを確認するように依頼することをお勧めします。 公式の勧告は、1 時間あたり約 10 回保存することです - 頻繁に切り替えることは長期遅延を引き起こす可能性があります。 頻度があまりにも高い場合は、個々のログファイルのサイズを増やすことをお勧めします。 第二に、非常に高い QPS を有するテーブルを新しい SeaTunnel タスクに分割することを検討してください。 -- 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#; 以下は、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)監視 新バージョンのSeaTunnelが提供する強力なモニタリングメトリクスと我々が構築した包括的なモニタリングシステムのおかげで、クラスター全体とタスクレベルの両方からデータ収集プラットフォームの状態を完全に把握することができます。 ① Cluster Monitoring ノード状態:クラスターノードの数とその生存状態のリアルタイムモニタリングで、Workerノードの異常なオフラインを保証し、クラスター処理能力を保証します。 Cluster throughput: クラスターのSourceReceivedQPSおよびSinkWriteQPS全体をモニタリングして、グローバルデータのインフラと出力率を把握し、クラスター負荷を評価します。 リソースの状態: クラスターノードの CPU とメモリをモニタリングして、リソースの拡張または最適化のための基盤を提供します。 ネットワークの健康:内部の心拍数とコミュニケーションの遅延を監視することによって、クラスターネットワークの良好な条件を確保します。 ② Task Monitoring タスクの実行状態:すべてのタスクの実行状態(実行/失敗/完了)をリアルタイムでチェックすることは、監視の最も基本的な要件です。 データ同期ボリューム: 各タスクの SourceReceivedCount および SinkWriteCount をモニタリングして、各データパイプラインのパスポートをリアルタイムで把握します。 遅延時間:これはCDCタスクの最も重要な指標の1つです. アラートは、収集終了時に継続的な遅延が発生したときに送信されます。 タグ : 測定可能な利益 安定した運用期間を経て、Apache SeaTunnelに基づく次世代のデータ収集フレームワークは、主に以下の側面に反映される重要かつ測定可能な利点をもたらしました。 (1)安定:「絶え間ない消防」から「心の平和」へ : 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)効率性:倍増した開発と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 (3)アーキテクチャ:リソース最適化と統一フレームワーク : 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 5. 展望:未来の計画 : 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.認定 ここでは、Apache SeaTunnelのオープンソースコミュニティに心から感謝します。同時に、当社の内部プロジェクトチームのすべてのメンバーに感謝します - あなたの努力と探求する勇気は、このアーキテクチャアップグレードの成功の鍵です。最後に、我々は、Apache SeaTunnelプロジェクトにより良い未来とより繁栄したエコシステムを願っています! SUPCONは、Apache SeaTunnel用のシロードデータツールをリリースし、コア同期タスクが0エラーで実行されます! ほぼ99%低いエラー、100%一貫性、70%低いO&Mコストです。
