Data Integration: Methods, Architecture & Checklist

Table of contents目录

What Is Data Integration?什么是数据集成？

This focused article is part of the complete data integration guide; use the pillar guide to compare related concepts, methods, and implementation decisions across the full topic.

本文是完整的数据集成指南内容集群中的专题文章；如需比较完整主题下的相关概念、方法与实施决策，请返回基石指南。

Data integration is the process of connecting data from separate sources and making it consistent, accessible, and useful as a combined view. It can physically move and transform records into a warehouse or present a virtual view while the records remain in their original systems.

数据集成是连接不同来源的数据，并使其能够以一致、可访问、可共同使用的方式呈现的过程。它既可以把记录实际搬运、转换并装载到数据仓库，也可以在记录保留于源系统时提供虚拟统一视图。

The term describes an outcome, not a single product or pipeline pattern. ETL and ELT are common methods, but replication, change data capture (CDC), event streaming, application integration, and data virtualization can solve different parts of the same problem. A sound design begins with the consumer's decision or workflow, then works backward to freshness, quality, security, and operating requirements.

这个术语描述的是结果，而不是某一种产品或管道模式。ETL和ELT是常见方法，但复制、变更数据捕获（CDC）、事件流、应用集成和数据虚拟化也能解决同一问题的不同部分。合理设计应先明确使用者要完成的决策或工作流，再反推时效、质量、安全和运维要求。

Why Data Integration Matters为什么数据集成很重要

Organizations search for data integration when a question crosses system boundaries: revenue lives in billing, product behavior in an event store, support context in a CRM, and targets in a spreadsheet. Joining those records manually creates slow, inconsistent analysis. Integration makes relationships repeatable, so dashboards, operational workflows, machine learning, and audits can use agreed definitions.

当一个问题跨越系统边界时，团队往往需要数据集成：收入位于计费系统，产品行为位于事件存储，支持背景位于CRM，目标值又在电子表格中。手工拼接这些记录既缓慢又不一致。集成让数据关系可重复，使仪表板、运营流程、机器学习和审计都能采用共同定义。

Use it when适合使用

The same cross-source dataset is reused, freshness is measurable, transformations need ownership, or downstream systems require dependable contracts.

同一跨源数据集会反复使用；时效需要衡量；转换需要明确负责人；或下游系统需要稳定的数据契约。

Do not overbuild it when不宜过度建设

The question is one-off, the source already exposes a safe query interface, or moving sensitive data creates more risk than a governed federated query.

问题只出现一次；源系统已经提供安全查询接口；或搬运敏感数据的风险高于受治理的联邦查询。

Integration does not automatically create accurate data. It can distribute errors faster if identifiers, business definitions, access rules, and failure handling are weak. Treat quality and observability as part of the architecture, not cleanup after deployment.

集成并不会自动产生准确数据。如果标识符、业务定义、访问规则或失败处理薄弱，它反而可能更快扩散错误。因此，数据质量和可观测性必须属于架构本身，而不是上线后的补救工作。

Inputs to Prepare Before You Integrate开始集成前要准备什么

A connector list is not a requirements document. Before choosing technology, create a compact integration brief that names the business question, consumers, source owners, sensitivity, latency, retention, recovery expectations, and acceptance tests.

连接器清单并不是需求文档。选择技术前，应先建立简洁的集成说明，列出业务问题、使用者、源系统负责人、敏感级别、延迟、保留期限、恢复预期和验收测试。

Source inventory: databases, SaaS APIs, object storage, files, queues, schemas, owners, and maintenance windows.
Join and identity rules: canonical customer, account, product, and time keys; collision and missing-key behavior.
Target contract: grain, required fields, allowed nulls, units, time zone, update mode, and downstream SLA.
Security constraints: data classification, regional boundaries, encryption, least-privilege roles, masking, and audit logging.
Operational budget: data volume, peak change rate, source API limits, compute, storage, egress, and on-call ownership.

源系统清单：数据库、SaaS API、对象存储、文件、队列、Schema、负责人和维护窗口。
关联与身份规则：客户、账户、产品和时间的标准键，以及冲突和缺失键的处理方式。
目标契约：粒度、必填字段、允许为空的字段、单位、时区、更新模式和下游SLA。
安全约束：数据分级、地域边界、加密、最小权限角色、脱敏和审计日志。
运维预算：数据量、变更峰值、源API限制、计算、存储、出口成本和轮值负责人。

Solve the Hard Problems Before Choosing a Data Integration Tool选择数据集成工具前先解决核心难题

Data integration fails when teams treat transport as the whole problem. Moving rows or events is usually easier than agreeing on identity, meaning, time, ownership, and acceptable error. Start with a named business decision and define the result contract before selecting connectors or orchestration technology.

如果团队把传输当作全部问题，数据集成就容易失败。移动行或事件通常比统一身份、含义、时间、所有权和可接受误差更容易。应先确定一个明确的业务决策并定义结果契约，再选择连接器或编排技术。

Heterogeneous structure: sources use different keys, types, nesting, encodings, and update rules. Define canonical fields and preserve source values for reconciliation.

异构结构：来源采用不同的键、类型、嵌套、编码和更新规则。应定义规范字段，并保留源值用于核对。

Conflicting meaning: identical names may represent different populations, units, or business states. Assign a semantic owner and version every definition.

含义冲突：相同名称可能代表不同总体、单位或业务状态。应指定语义所有者，并对每个定义进行版本化。

Time and change: late events, deletions, mutable records, time zones, and schema drift can silently rewrite a result. State watermarks, replay windows, and correction policy.

时间与变化：迟到事件、删除、可变记录、时区和Schema漂移可能静默改写结果。应明确水位、重放窗口和更正策略。

Security and ownership: data can cross residency, purpose, and access boundaries during staging or export. Preserve identity, classification, lineage, retention, and accountable owners end to end.

安全与所有权：数据在暂存或导出期间可能跨越驻留、用途和访问边界。应端到端保留身份、分类、血缘、保留策略和责任人。

Make these decisions testable. A useful contract states grain, keys, allowed duplicates, null behavior, freshness, completeness, reconciliation tolerance, policy obligations, consumer, owner, rollback trigger, and evidence retention. Tools can enforce that contract, but they cannot invent it.

这些决定必须可测试。有效契约应说明粒度、键、允许重复、空值行为、新鲜度、完整性、核对容差、策略义务、使用者、所有者、回退触发条件和证据保留。工具可以执行契约，但不能替团队创造契约。

Data Integration Methods and Techniques数据集成的方法与技术

No method wins in every environment. The right pattern depends on where transformations should run, how quickly changes must arrive, whether records may be copied, and whether consumers need historical or current state.

没有一种方法适用于所有环境。正确模式取决于转换应在哪里运行、变更需要多快到达、记录能否复制，以及使用者需要历史状态还是当前状态。

Decision framework for common integration patterns常见集成模式决策框架
Method方法	Best fit适用情况	Main trade-off主要取舍
ETL	Transform before loading when the target requires controlled schemas or sensitive fields must be removed first.目标需要受控Schema，或敏感字段必须在装载前移除。	Upfront transformation can slow onboarding and make raw reprocessing harder.前置转换可能减慢接入，并增加原始数据重处理难度。
ELT	Load raw or lightly processed data into scalable analytical storage, then transform close to consumers.把原始或轻处理数据装入可扩展分析存储，再靠近使用者进行转换。	Raw zones need strict access, lifecycle, cost, and data-quality controls.原始区需要严格的访问、生命周期、成本和质量控制。
Replication / CDC复制 / CDC	Keep a target synchronized with inserts, updates, and deletes at low latency.以较低延迟同步插入、更新和删除。	Ordering, schema change, replay, and delete semantics require careful handling.顺序、Schema变更、重放和删除语义需要谨慎处理。
Streaming流处理	Operational alerts, events, and continuously updated products where minutes or seconds matter.分钟或秒级时效很重要的运营告警、事件和持续更新产品。	State, late events, exactly-once expectations, and backfills add complexity.状态、迟到事件、一次性语义预期和回填都会增加复杂度。
Virtualization数据虚拟化	Query sources through a unified layer without creating another full copy.通过统一层查询源系统，而不创建另一份完整副本。	Performance and availability remain coupled to source systems and network paths.性能与可用性仍受源系统和网络路径影响。
iPaaS / API	Synchronize business applications and trigger operational workflows.同步业务应用并触发运营工作流。	Application semantics, rate limits, and bidirectional conflict resolution dominate.应用语义、速率限制和双向冲突解决是主要难点。

Data integration vs ETL: data integration is the broader goal; ETL is one implementation sequence. Data integration vs data ingestion: ingestion gets data into a system, while integration also reconciles structure, meaning, identity, and usability across sources.

数据集成与ETL：数据集成是更广泛的目标，ETL只是其中一种实施顺序。数据集成与数据摄取：摄取负责把数据送入系统；集成还要协调不同来源的结构、含义、身份和可用性。

Map Schemas and Semantics Explicitly显式映射Schema与语义

A mapping is an executable contract between a source field and a consumer field. It should record the source object and version, target name, type conversion, transformation, default or null rule, unit, code set, key relationship, effective time, owner, and validation evidence. A diagram without these decisions is useful orientation, not an implementation specification.

映射是源字段与消费字段之间可执行的契约。它应记录源对象及版本、目标名称、类型转换、变换、默认值或空值规则、单位、代码集、键关系、生效时间、所有者和验证证据。缺少这些决定的图示只能用于理解方向，不能作为实施规范。

Minimum mapping decisions最低映射决策
Problem问题	Required decision必须决定	Evidence证据
Identity身份	Authoritative key, crosswalk, merge and split rules权威键、对照表、合并与拆分规则	Matched, unmatched, duplicate, and collision counts匹配、未匹配、重复与冲突计数
Types and units类型与单位	Precision, rounding, encoding, currency, and conversion owner精度、舍入、编码、币种与转换所有者	Boundary, overflow, and reversible sample tests边界、溢出与可逆样本测试
Time时间	Event time, processing time, time zone, late-data window事件时间、处理时间、时区与迟到窗口	Watermark, replay, and cutoff reconciliation水位、重放与截止点核对
Meaning含义	Population, status logic, exclusions, and effective version总体、状态逻辑、排除项与生效版本	Business invariants and approved examples业务不变量与获批示例

Keep mappings in version control beside tests and release notes. Trace every published metric back through transformations to its authoritative input. When a source schema or business definition changes, run impact analysis, compare old and new outputs on the same window, and require an owner to approve the migration.

应把映射与测试、发布说明一起纳入版本控制。每个已发布指标都要能沿转换过程追溯到权威输入。来源Schema或业务定义变化时，应执行影响分析，在同一时间窗口比较新旧输出，并由所有者批准迁移。

Choose a Data Integration Architecture and Toolset选择数据集成架构与工具组合

Choose the delivery pattern from workload evidence, not from a vendor category. Document source change behavior, volume, peak rate, freshness, replay needs, target shape, consumer concurrency, retention, residency, recovery, and the skills available to operate the system. Most mature programs use more than one pattern behind a common contract and governance model.

应依据工作负载证据选择交付模式，而不是从供应商类别出发。需要记录来源变化行为、数据量、峰值速率、新鲜度、重放需求、目标形态、消费并发、保留、驻留、恢复，以及团队可用于运行系统的技能。成熟项目通常会在统一契约和治理模型下组合多种模式。

Architecture fit by workload按工作负载选择架构
Pattern模式	Use when适用条件	Prove before adoption采用前证明
Batch ETL or ELT批量ETL或ELT	Large bounded windows and repeatable transformations matter more than sub-minute freshness大规模有界窗口与可重复转换比亚分钟新鲜度更重要	Incremental keys, restart point, cutoff consistency, and backfill cost增量键、重启点、截止一致性与回填成本
CDC or event streamingCDC或事件流	Consumers need continuous changes and can handle ordering, replay, and eventual correction使用者需要持续变化，并能处理顺序、重放与最终更正	Log retention, duplicate policy, schema evolution, and late-event behavior日志保留、重复策略、Schema演进与迟到事件行为
API or application integrationAPI或应用集成	A bounded operational action needs validation and an explicit service contract有界业务操作需要验证和明确服务契约	Idempotency, rate limits, partial failure, authentication, and compensation幂等、限速、部分失败、认证与补偿
Virtualization or federation虚拟化或联邦	Selective fresh access is needed while authoritative data remains in place需要选择性新鲜访问，同时权威数据留在原处	Pushdown, source load, transfer, semantics, availability, and policy equivalence下推、源端负载、传输、语义、可用性与策略等价

Evaluate tools with a representative proof, not a connector checklist. Test the hardest source and transformation, peak concurrency, schema change, credential rotation, replay, cancellation, lineage, observability, and export controls. Include infrastructure, network transfer, operations, incident response, and migration effort in cost. Prefer open formats and portable contracts so a tool replacement does not require redefining the business meaning of every output.

评估工具时应使用代表性验证，而不是只看连接器清单。测试最困难的来源与转换、峰值并发、Schema变化、凭据轮换、重放、取消、血缘、可观测性和导出控制。成本应包含基础设施、网络传输、运营、事件响应和迁移工作。优先采用开放格式和可移植契约，避免更换工具时重新定义每项输出的业务含义。

A Repeatable Data Integration Process可重复执行的数据集成流程

Define the outcome and service level. Name the decision, dataset grain, consumers, acceptable latency, and what happens when data is late.
Profile every source. Measure volume, keys, nulls, duplicates, formats, change rate, history, API behavior, and known data incidents.
Choose movement and transformation boundaries. Decide what stays at the source, what is copied, where raw data lands, and where business rules run.
Map semantics and identities. Document field-level mappings, units, time zones, reference data, slowly changing dimensions, and survivorship rules.
Design security and failure handling. Apply least privilege, encryption, masking, secrets rotation, retries, dead-letter handling, idempotency, and rollback paths.
Build incrementally. Start with one valuable end-to-end slice. Keep raw inputs, transformation versions, and run metadata traceable.
Test with reconciliations. Compare counts, sums, keys, freshness, sample records, deletes, boundary dates, and downstream calculations.
Operate with ownership. Monitor freshness, volume, schema drift, quality thresholds, runtime, cost, and incidents with named owners and runbooks.

定义结果和服务级别。说明要支持的决策、数据集粒度、使用者、可接受延迟，以及数据迟到时的处理方式。
剖析每个源系统。测量数据量、键、空值、重复、格式、变更速度、历史、API行为和已知数据事件。
选择搬运与转换边界。决定哪些数据留在源端、哪些需要复制、原始数据落在哪里、业务规则在哪里执行。
映射语义与身份。记录字段映射、单位、时区、参考数据、缓慢变化维度和主记录保留规则。
设计安全和失败处理。实施最小权限、加密、脱敏、密钥轮换、重试、死信处理、幂等和回滚路径。
增量构建。先交付一条有价值的端到端切片，并使原始输入、转换版本和运行元数据可追溯。
通过核对进行测试。比较数量、合计、键、时效、样本记录、删除、边界日期和下游计算。
明确负责人并持续运维。监控时效、数据量、Schema漂移、质量阈值、运行时间、成本和事件，并维护运行手册。

Example: Integrating Orders, Support, and Product Events示例：集成订单、支持与产品事件

Consider a hypothetical subscription company that wants a daily account-health dataset. Billing records are in PostgreSQL, support cases in a SaaS API, product events in object storage, and account targets in a controlled CSV. This is an illustrative architecture, not a customer case.

假设一家订阅制公司需要每日账户健康数据集。计费记录在PostgreSQL中，支持工单来自SaaS API，产品事件位于对象存储，账户目标保存在受控CSV中。这只是架构示例，并非客户案例。

The team chooses CDC for invoice changes, a scheduled incremental API pull for cases, and partitioned batch reads for events. Raw records land in restricted storage. Transformations normalize timestamps to UTC, map account identifiers through a governed crosswalk, calculate seven-day activity, and publish one row per account per day. The CSV is versioned and rejected when required columns change.

团队对发票变更采用CDC，对工单采用定时增量API拉取，对事件采用分区批量读取。原始记录进入受限存储。转换把时间统一为UTC，通过受治理的对照表映射账户标识，计算七日活跃度，并按“每个账户每天一行”发布结果。当CSV必填列发生变化时，系统会保留版本并拒绝异常输入。

Acceptance tests compare invoice totals with the billing source, ensure every published account maps to a known key, verify no account-day row is duplicated, and alert if freshness exceeds the documented threshold. A backfill uses the same versioned transformations, but runs separately so it cannot delay the daily workload.

验收测试会把发票合计与计费源核对，确保每条已发布账户记录都能映射到已知键，验证账户日记录不重复，并在时效超过文档阈值时告警。回填使用同一版本的转换逻辑，但独立运行，避免拖延每日任务。

Common Failures, Limits, and Risks常见故障、限制与风险

Schema driftSchema漂移

A renamed field, type change, or nested structure can silently produce nulls. Contract tests should fail visibly before corrupted data is published.

字段改名、类型变化或嵌套结构可能悄悄产生空值。契约测试应在错误数据发布前明确失败。

Identity mismatch身份不匹配

Email addresses and names are weak join keys. Preserve source identifiers and govern crosswalks instead of relying on fuzzy matches by default.

邮箱和姓名不是可靠关联键。应保留源标识并治理对照表，而不是默认依赖模糊匹配。

Partial and duplicate loads部分装载与重复装载

Retries can double-count data unless writes are idempotent and checkpoints are transactional or otherwise recoverable.

如果写入不具备幂等性、检查点不可恢复，重试可能造成重复计数。

Source impact源系统影响

Heavy extracts or virtual queries can compete with production traffic. Use read replicas, rate limits, pushdown controls, and workload windows.

大规模抽取或虚拟查询可能与生产流量争抢资源，应使用只读副本、速率限制、下推控制和工作窗口。

Other failure modes include late events, timezone ambiguity, undocumented deletes, API pagination mistakes, expired credentials, unbounded backfills, and cost growth hidden behind successful jobs. Integration also does not replace master data management, governance, or semantic modeling; it carries those decisions into execution.

其他故障还包括事件迟到、时区歧义、未记录的删除、API分页错误、凭据过期、无限制回填，以及隐藏在“运行成功”背后的成本增长。数据集成也不能取代主数据管理、治理或语义建模；它只是把这些决策落实到执行层。

How to Validate Data Integration Results如何验证数据集成结果

A green job status proves only that code finished. Validation must show that the intended data arrived, retained its meaning, stayed within policy, and remains usable downstream.

任务显示绿色只证明代码运行结束。验证还必须证明目标数据确实到达、含义未改变、符合政策，并能被下游正常使用。

Complete完整counts, keys, partitions数量、键、分区

Correct正确totals, rules, samples合计、规则、样本

Current及时freshness, lag, windows时效、延迟、窗口

Controlled受控access, lineage, cost访问、血缘、成本

Reconcile source and target row counts, sums, distinct keys, and deletion counts for the same bounded period.
Test null, uniqueness, referential integrity, allowed values, units, and business rules at the published grain.
Exercise first run, normal incremental run, retry, replay, schema change, source outage, and backfill paths.
Run representative downstream queries and compare them with an independently calculated sample.
Verify permissions with both authorized and unauthorized test identities; inspect logs for exposed secrets or sensitive values.
Set thresholds and owners for freshness, volume deviation, quality failure, runtime, and spend; test the alert route.

在同一限定期间核对源端和目标端的行数、合计、不同键数量和删除数量。
在发布粒度上测试空值、唯一性、引用完整性、允许值、单位和业务规则。
演练首次运行、正常增量、重试、重放、Schema变更、源系统中断和回填路径。
执行具有代表性的下游查询，并与独立计算的样本比较。
分别用授权和未授权测试身份验证权限，并检查日志是否暴露密钥或敏感值。
为时效、数据量偏差、质量失败、运行时间和支出设定阈值与负责人，并测试告警链路。

Data Integration Best Practices数据集成最佳实践

Design for change. Version schemas and transformations, preserve replayable raw data where policy permits, and separate backfills from routine workloads. Document who approves breaking changes and how consumers migrate.

为变化而设计。对Schema和转换进行版本管理；在政策允许时保留可重放的原始数据；把回填与常规工作负载分离；并记录破坏性变更的批准者和使用者迁移方式。

Make contracts executable. Convert grain, keys, required fields, freshness, and valid ranges into tests that run before publication. A wiki description without enforcement will drift from production.

让数据契约可执行。把粒度、键、必填字段、时效和有效范围转化为发布前自动运行的测试。只有Wiki描述而没有执行机制，最终会与生产脱节。

Prefer the smallest sufficient architecture. A daily batch is often safer and cheaper than streaming when the consumer works once per day. A governed virtual query may be better than another copy for exploratory cross-source analysis. Add complexity only when a measured requirement demands it.

优先选择足够用的最小架构。如果使用者每天只工作一次，日批通常比流处理更安全、更便宜。对于探索性跨源分析，受治理的虚拟查询可能优于再复制一份数据。只有可测量的需求确实要求时，才增加复杂度。

Separate facts from assumptions. Mark inferred mappings and hypothetical thresholds until owners approve them. Keep lineage from source fields through transformations to published metrics so an incident can be traced without guesswork.

区分事实与假设。在负责人批准前，应标记推断的映射和假设阈值。保留从源字段、转换到发布指标的血缘，使事件排查不依赖猜测。

Govern and Observe Data Integration in Production在生产环境治理并观测数据集成

Production readiness is not a successful first run. Define a service objective for each data product: expected freshness, completeness, accuracy tolerance, availability, recovery point, recovery time, and the time by which a correction must reach consumers. Measure those signals at the dataset and business-rule level, not only at the scheduler or connector.

生产就绪并不等于首次运行成功。应为每个数据产品定义服务目标：预期新鲜度、完整性、准确性容差、可用性、恢复点、恢复时间，以及更正必须到达使用者的时限。应在数据集和业务规则层面测量这些信号，而不只是监控调度器或连接器。

Observe flow: records read and written, lag, watermark, throughput, retries, dead letters, duplicate suppression, rejected rows, and cost by source and consumer.观测数据流：按来源和使用者记录读写数量、延迟、水位、吞吐、重试、死信、重复抑制、拒绝行和成本。
Observe meaning: key coverage, null rates, distribution shifts, referential integrity, aggregate invariants, and the version of every semantic rule.观测含义：监控键覆盖率、空值率、分布漂移、引用完整性、聚合不变量和每项语义规则的版本。
Control change: register schemas, test compatibility, preview impact, canary releases, dual-run important migrations, and keep a reversible deployment path.控制变更：注册Schema、测试兼容性、预览影响、金丝雀发布、对重要迁移进行双轨运行，并保留可逆部署路径。
Prepare incidents: name the owner, alert threshold, consumer communication path, replay boundary, credential revocation step, and evidence needed for post-incident review.准备事件响应：明确所有者、告警阈值、使用者沟通路径、重放边界、凭据撤销步骤和事后审查证据。

Separate technical success from business acceptance. A pipeline can be green while an important region is missing or a currency conversion is stale. Publish a compact quality status with each delivery, and stop or quarantine output when a blocking invariant fails. Review cost per useful record and consumer adoption so obsolete integrations can be retired instead of silently accumulating operational debt.

应区分技术成功与业务验收。即使管道显示绿色，关键区域仍可能缺失，币种转换也可能陈旧。每次交付都应发布简洁质量状态，并在阻断性不变量失败时停止或隔离输出。还要审查每条有效记录的成本和使用者采用情况，及时退役过时集成，避免运行债务静默积累。

Where InfiniSynapse FitsInfiniSynapse如何参与工作流

InfiniSynapse is relevant when the goal is analysis across already connected data sources. Its website describes direct connections to databases and multi-source analysis without requiring a complex migration first. That is a federated analysis path, not a claim that the product replaces ETL, ELT, replication, streaming, data-quality, or orchestration systems.

当目标是分析已经连接的多个数据源时，InfiniSynapse可以参与工作流。官网描述了对数据库的直接连接以及无需先进行复杂迁移的多源分析。这属于联邦分析路径，并不意味着产品能够取代ETL、ELT、复制、流处理、数据质量或编排系统。

Analyze connected sources without building another copy first无需先建立另一份数据副本，即可分析已连接来源

Prepare read-only connection details, approved credentials, the schemas you may query, and a clearly scoped business question. Then open the InfiniSynapse web app to connect supported sources and run cross-source analysis. Confirm supported connectors and access controls in your environment before using production data.

请先准备只读连接信息、已批准凭据、允许查询的Schema和范围明确的业务问题。然后打开InfiniSynapse Web App，连接受支持的数据源并进行跨源分析。使用生产数据前，请在自己的环境中确认连接器支持情况和访问控制。

Open the multi-source analysis app打开多源数据分析应用

If the same result must feed many dashboards, enforce a stable historical model, or trigger operational systems, build and operate the appropriate integration pipeline. Use federated analysis for exploration and questions that benefit from current source access; use materialized integration when performance, reuse, history, or isolation requires it.

如果同一结果需要供多个仪表板使用、强制稳定历史模型，或触发运营系统，就应构建并运维合适的集成管道。探索和依赖当前源状态的问题可采用联邦分析；性能、复用、历史或隔离要求较高时，应采用物化集成。

Data Integration FAQ数据集成常见问题

What is data integration in simple words?

用简单的话说，什么是数据集成？

Data integration connects information from separate systems and makes it consistent and usable together. It may move data into a common store or present a unified view without copying everything.

数据集成把不同系统中的信息连接起来，使其能够一致地共同使用。它可以把数据搬入公共存储，也可以在不复制全部数据的情况下提供统一视图。

Is data integration the same as ETL?

数据集成等同于ETL吗？

No. ETL is one data integration method. Data integration also includes ELT, replication, streaming, application integration, and data virtualization.

不等同。ETL只是数据集成的一种方法。数据集成还包括ELT、复制、流处理、应用集成和数据虚拟化。

How do you validate a data integration pipeline?

如何验证数据集成管道？

Reconcile source and target counts, totals, keys, freshness, duplicates, nulls, rejected records, permissions, and downstream queries against documented acceptance thresholds.

应依据已记录的验收阈值，核对源端与目标端的数量、合计、键、时效、重复、空值、拒绝记录、权限和下游查询。

When should data virtualization be used instead of moving data?

何时应使用数据虚拟化而不是搬运数据？

Use virtualization when consumers need a current cross-source view, copying is restricted or wasteful, and the source systems can support the query workload. Avoid it when sources are unstable or analytical performance requires a dedicated store.

当使用者需要当前跨源视图、复制受到限制或会造成浪费，并且源系统能够承担查询负载时，可使用虚拟化。如果源系统不稳定，或分析性能要求专用存储，则不宜使用。

Authoritative Sources and Next Steps权威来源与下一步

Use vendor-neutral requirements and test evidence to evaluate any implementation. The following first-party explainers document the broader concept and platform patterns; product-specific behavior still needs validation against the exact service and version you deploy.

评估任何实施方案时，都应使用与厂商无关的需求和测试证据。以下第一方资料解释了广义概念和平台模式；具体产品行为仍需针对你实际部署的服务与版本进行验证。