ინტეგრირებული: საწარმოებისთვის, მონაცემთა კვლევების ძირითადი მოვლენები არ იყო მხოლოდ "სანიკრონიზაცია", არამედ, თუ როგორ უნდა უზრუნველყოს მონაცემთა სიზუსტით, ინტენსივობისა და დროულიას ფართო ზომის, უარყოფითი და კომპლექსური გარემოში. ამ სტატიაში შეამოწმოთ SUPCON- ის პრაქტიკას, რათა შექმნათ Apache SeaTunnel- ის საფუძველზე ინტეგრირებული მონაცემთა კვლევების რკინიგზაციის რკინიგზაცია, რომელიც განკუთვნილია კონკრეტული მიმოხილვა და გადაწყვეტილებები, როგორიცაა კლასის მაღალი ხელმისაწვდომობის კონფიგურაცია, შესრულების გაუმჯობესება, ინტეგრირებული: საწარმოებისთვის, მონაცემთა კვლევების ძირითადი მოვლენები არ იყო მხოლოდ "სანიკრონიზაცია", არამედ, თუ როგორ უნდა უზრუნველყოს მონაცემთა სიზუსტით, ინტენსივობისა და დროულიას ფართო ზომის, უარყოფითი და კომპლექსური გარემოში. ამ სტატიაში შეამოწმოთ SUPCON- ის პრაქტიკას, რათა შექმნათ Apache SeaTunnel- ის საფუძველზე ინტეგრირებული მონაცემთა კვლევების რკინიგზაციის რკინიგზაცია, რომელიც განკუთვნილია კონკრეტული მიმოხილვა და გადაწყვეტილებები, როგორიცაა კლასის მაღალი ხელმისაწვდომობის კონფიგურაცია, შესრულების გაუმჯობესება, Dilemma: Siloed Collection Architecture და მაღალი ოპერაციის და შენარჩუნების ღირებულება როგორც ინდუსტრიული AI პლატფორმა კომპანია, რომელიც ფართოდ გაფართოება პროცესის ინდუსტრიაში, SUPCON- ის გლობალური ბიზნესის მუდმივი განვითარება. ამჟამად, მას აქვს თითქმის 40 გლობალური შვილობილი და მომსახურება მეტი 35,000 გლობალური მომხმარებელს. ბიზნესის მუდმივი გაფართოება გააჩნია მაღალი მოთხოვნებს მონაცემთა მუშაობისთვის: მონაცემები არ მხოლოდ უნდა იყოს "კვირთული სწრაფად", არამედ "გადასტურა". ამ მიზნით, ჩვენ აშენდა ფართო ფართო მონაცემთა პლატფორმა, რათა შეესაბამება კომპლექსური სინამდვილეები. თუმცა, პლატფორმა თავდაპირველად გაზრდა მონაცემთა მოცულობა, განვითარება და : ადრე, ჩვენ ხანგრძლივად დამოკიდებულია გადაწყვეტილებებს, რომელიც შეიცავს მრავალფეროვანი ინსტრუმენტები (გალითად, გამოყენებით Sqoop for batch data synchronization to HDFS, და Maxwell / StreamSets დამუშავების მონაცემთა მონაცემთა სტრატეგიული ლოგები და დააწკაპუნეთ მათ Kafka / Kudu). ეს "patchwork" არქიტექტურა გამოწვევა ფართო ტექნოლოგიური stacks და მაღალი შენარჩუნების ღირებულება. (1) Complex Architecture with Silos : მრავალჯერადი ტექნიკური მარშრუტი ნიშნავს, რომ ოპერაციის და შენარჩუნების მონიტორინგის ზედმეტი წნევა. ერთობლივი მონიტორინგის და შეტყობინების მექანიზმი არ არის, რაც იმას ნიშნავს, რომ ნებისმიერი ნორმალურია (გალითად, სინქრონიზაციის შეზღუდვა, რესურსების შეშფოთება) მოითხოვს მრავალფეროვანი მენეფექტურობის გაუმჯობესებას და "ბადის დაცვა", რაც რთულია სტაბილურობის უზრუნველყოფს. (2) O&M Black Hole, Constantly Firefighting : როდესაც ახალი მონაცემთა წყაროების (მაგ. შიდა მონაცემთა ბაზები და SAP HANA) შეხვდება, საჭიროა განსხვავებული ინსტრუმენტები ან თვითმართველობის plug-ins განვითარება, რაც არ არის შესაძლებელი სწრაფად პასუხი ბიზნეს მოთხოვნებს. (3) Segmented Capabilities, Difficult to Expand გამოქვეყნებული ფაილი ნათლად აჩვენებს, რომ ადრე decentralized კოლექციური ოკუსიზმი. ჩვენ აღიარებთ, რომ ეს "შემორგებული" მოდელი გახდა ყველაზე შეუზღუდავი კავშირი მონაცემთა დამუშავება. ეს არა მხოლოდ არ შეესაბამება კომპანიის მომავალში განვითარების სიჩქარე, არამედ პოტენციური რისკები მონაცემთა ხარისხის და სწრაფი. შექმნა ერთობლივი, სტაბილური და ეფექტური მონაცემთა კოლექციის რკინიგზმი გახდა მნიშვნელოვანია და უსამრავი. 2. გადარჩენა dilemma: მიმოხილვა Unified Collection Framework და ტექნოლოგიური არჩევანი მას შემდეგ, რაც ინტელექტუალური ანალიზი და განიხილება, ჩვენ გაითვალისწინეთ ახალი ტექნოლოგიების ძირითადი არჩევანი: : იგი უნდა სრულიად მოიცავს ყველა მიმდინარე და მომავალში მონაცემთა წყარო ტიპის კომპანიის (შესამ MySQL, Oracle, HANA Kafka, StarRocks და ა.შ.) და მხარს უჭერს ორივე off-line და რეალურ დროში კოლექციის რეჟიმები, ძირითადად გადაწყვეტა პრობლემა ერთობლივი ტექნოლოგიური stacks. (1) Comprehensive Connectivity : Framework itself უნდა იყოს მაღალი ხელმისაწვდომობის გაფართოებული კლასის ძლიერი შეცდომა Tolerance. მიუხედავად იმისა, რომ ერთი ღონისძიება არ გაქვთ, მთელი მომსახურება არ უნდა იყოს შეუზღუდავი და შეიძლება ავტომატურად გადაიხადოს, უზრუნველყოფს მუდმივი ოპერაცია მონაცემთა მოპოვების მილის. (2) Cluster Stability and High Availability : საქმიანობის შესრულების დონეზე, მას უნდა უზრუნველყოს Exactly-Once ან At-Last-Once დამუშავების სანტასტიკა, რათა უზრუნველყოს, რომ საქმიანობა ავტომატურად გადაიხადოს breakpoints შემდეგ ნორმალური შეზღუდვები, გადაიხადოს მონაცემთა duplication ან დაკარგვა, რომელიც არის ღონისძიება მონაცემთა ხარისხის. (3) Reliable Data Consistency Guarantee : მას უნდა იყოს შეუძლიათ ადვილად შეესაბამება ჩვენი ყოველდღიური TB დონეზე მონაცემთა მოვლენები. მისი არქიტექტურა უნდა მხარს უჭერს ჰორიზონტალური გაფართოებას, და სინქრონიზაციის ეფექტურობა შეიძლება linearly გაუმჯობესდეს, დაამატოთ ნომრები, რათა შეესაბამება მონაცემთა ზრდის საჭიროებების მოცემული სწრაფი ბიზნესის განვითარება. (4) Strong Throughput Performance : ეს უნდა უზრუნველყოს სრული მონიტორინგი და შეტყობინების მექანიზმი, რომელიც შეუძლია რეალურ დროში მონიტორინგი და შეტყობინება ძირითადი ინტიმატორები, როგორიცაა ნორმები, შეზღუდვა და გადაღების დროს მონაცემთა სინთრონიზაციის დროს, და სწრაფად შეტყობინება ოპერაცია და მენეჯმენტები, გადარჩენა პასტიკური "ბეჭდვა" აქტიური "ჩვეულებრივი შეტყობინება". (5) Observable O&M Experience ამ ხუთი კრედიტორიის საფუძველზე, ჩვენ გააკეთა დეტალური კვლევა და შედარებით ტესტირება საწარმოში mainstream გადაწყვეტილებები. ბოლოს, 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. Comprehensive კავშირი მას აქვს ძალიან ფართო Connector- ის ოპტიკური სისტემა, რომელიც ოფიციალურად მხარს უჭერს Hundreds of Source / Destination Databases, რომელიც სრულიად მოიცავს ყველა ჩვენი მონაცემთა ტიპის. ერთი Framework შეუძლია შეუერთოს offline და რეალურ დროის კოლექცია. Cluster Stability და მაღალი ხელმისაწვდომობა SeaTunnel Engine- ის განსხვავებული არქიტექტურა უზრუნველყოფს, რომ მაშინაც კი, თუ ერთ-ერთი Master ან Worker ღონისძიება არ არის ნორმალური, ეს არ ეფუძნება შენარჩუნების საქმიანობას. საიმედო მონაცემთა კონფიდენციალურობის გარანტია ეს უზრუნველყოფს ძლიერი შეცდომა Tolerance მექანიზმი, მხარს უჭერს Exactly-Once სამანტიკა, და შეუძლია ავტომატური breakpoint განთავსება მას შემდეგ, რაც საქმიანობის ცვლილებები Checkpoint მექანიზმი, უზრუნველყოფს არ მონაცემების დაკარგვა ან duplication. Strong Throughput შესრულება მას აქვს შესანიშნავი გაფართოებული მონაცემების დამუშავების შესაძლებლობები. პარამეტრიზმი შეიძლება შეესაბამება მარტივი კონფიგურაცია, ადვილად გააკეთოს ჰორიზონტალური გაფართოება. O&M გამოცდილება ეს უზრუნველყოფს ფართო მონიტორინგი ნარკოტიკები და შეუძლია უჭერს ინტეგრირებული mainstream მონიტორინგი და შეტყობინება სისტემები, როგორიცაა Prometheus, Grafana და AlertManager, საშუალებას გაძლევთ გააკეთოთ ნათელი ცოდნა პროცესში მონაცემების მოკლე. 3. პრაქტიკა: კონკრეტული მიზნების გეგმა და დეტალები ჩვენი პრაქტიკა Apache SeaTunnel- ს ერთად არის ასევე პროექტის ზრდის გზა. დასაწყისში, ჩვენ აშენდათ Apache SeaTunnel v2.3.5. ამ დროს, ზოგიერთი კონკრეტული საჭიროებებს შეესაბამება (მაგ. განსხვავებული მონაცემთა მონაცემთა ტაბლეის სახის ან ფართო სახის კმაყოფილება), ჩვენ გააკეთა ზოგიერთი წამყვანი განვითარების მუშაობა. მიუხედავად იმისა, რომ SeaTunnel საზოგადოების სწრაფი განვითარება, ახალი ვერსია ფუნქციები და კონვერტატორები იზრდება. როდესაც ჩვენ წარმატებით გააუმჯობესდა Cluster Apache SeaTunnel v2.3.11, ჩვენ მივიღე საოცარი, რომ მოთხოვნები, რომლებიც ადრე მოითხოვს მორგებული განვითარება, ახლა ჩვეულებრივი მხარდაჭერა ახალი ვერსია. ამჟამად, ყველა ჩვენი მონაცემთა სინქრონიზაციის საქმიანობა განახლებულია ოფიციალური ვერსიაზე, დაახლოებით Zero Modification, რაც მნიშვნელოვნად შეამციროს ჩვენი გრძელვადიანი შენარჩუნების ღირებულება და საშუალებას გაძლევთ უახლესი ფუნქციონების და შესრულების გაუმჯობესების სარგებლობენ. შემდეგი არის ჩვენი ძირითადი განხორციელების გეგმა, რომელიც დაფუძნებულია ვერსია v2.3.11, რომელიც ტაბლეტის დონეზე მონაცემთა მოცულობა წარმოების გარემოში შეამოწმებულია და დააყენა ძლიერი საფუძველზე 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 200 გ 30 გ მთავარი-02 8C 32G 200 გ 30 გ სამუშაოები 01 16C 64G 500 გ 62გ სამუშაოები 02 16C 64G 500 გ 62გ მობილური-03 16C 64G 500 გ 62გ (2) Key Cluster კონფიგურაციის ფაილი 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 პაკეტი დააყენა გთხოვთ დაგვიკავშირდეთ ოფიციალური საიტზე: . ${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- ს დაეხმარება, მომხმარებლის დაკავშირებული საშუალებას გაძლევთ, და დააყენეთ corresponding OJDBC.Jar და Orai18n.jar პაკეტები გთხოვთ გთხოვთ გაიგოთ ინფორმაცია ოფიციალური ვებგვერდზე: . ${SEATUNNEL_HOME}/lib https://seatunnel.apache.org/docs/2.3.11/connector-v2/source/Oracle-CDC Oracle-CDC კოლექციის დროს შეხვდა თარიღი პრობლემების შესახებ, ჩვენ გირჩევთ, რომ პირველი გთხოვთ DBA- ს შეამოწმოთ, თუ როგორ ჩვეულებრივ Logminer- ის სტატისტიკები გადახდის. ოფიციალური რეკომენდაციას არის, რომ ამ სტატისტიკის გარშემო 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 Node სტატისტიკა: რეალურ დროში მონიტორინგის რაოდენობა cluster nodes და მათი სიცოცხლის სტატისტიკა, რათა უზრუნველყოს არ ნორმალური off-line Worker nodes და უზრუნველყოს cluster დამუშავების შესაძლებლობები. Cluster throughput: მონიტორინგი საერთო SourceReceivedQPS და SinkWriteQPS კლასტერის შეკუმშოთ საერთო მონაცემთა დატვირთვის სიჩქარეები და შეფასება კლასტერის დატვირთვა. Resource Status: მონიტორინგი CPU და მექანიზია cluster nodes, რათა უზრუნველყოს საფუძველზე resource გაფართოება ან ოპტიმიზაცია. ქსელის ჯანმრთელობა: უზრუნველყოს კარგი ქსელის ქსელის პირობები, მონიტორინგი შიდა Heartbeat და კომუნიკაციის თარიღი. ② Task Monitoring Task Operation Status: რეალურ დროში შეამოწმება გაშვებული სტატისტიკა (Running / Failed / Finished) ყველა სამუშაო არის ყველაზე ძირითადი მოთხოვნები მონიტორინგი. Data Synchronization Volume: მონიტორინგი SourceReceivedCount და SinkWriteCount თითოეული საქმიანობის შეკუმშვის გადაცემის თითოეული მონაცემთა pipeline რეალურ დროში. თარიღი დრო: ეს არის ერთ-ერთი ყველაზე მნიშვნელოვანი ნარკოტიკების CDC სამუშაოები. შეტყობინებები გამოგზავნილია, როდესაც მუდმივი თარიღი ხდება კოლექციის ბოლოს. 4. შედეგები: შეზღუდული მოგება მუდმივი ოპერაციის შემდეგ, Apache SeaTunnel- ზე დაფუძნებული ახალი გენერაციის მონაცემთა კოლექციის რკინიგზია მივიღა მნიშვნელოვანი და ზუსტი ხარისხის უპირატესობები, რომლებიც ძირითადად მოიცავს: (1) სტაბილურობა: “კონტალუალური საწინააღმდეგო” to “მაგონტალურობა” : 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) არქიტექტურა: Resource Optimization და 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 Outlook: მომავალი გეგმები : 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 პროექტი უკეთესი მომავალი და უფრო ბედნიერი ოკსიპედია! SUPCON დატვირთული Siloed მონაცემთა ინსტრუმენტები Apache SeaTunnel- ახლა ძირითადი სინქრონიკის საქმიანობა იყენებს 0-სკრიალებს! 99% ნაკლები შეკრიალებები, 100% კონფიგურაცია, 70% ნაკლები O&M ღირებულება. დიდი მადლობა @ApacheSeaTunnel! #DataEngineering #OpenSource
