您可以在终端、代码或 AI 代理中管理 Quicknode。现已支持 CLI、管理 API、MCP 和 SDK。
开始构建 通过 SOC 2 II 类认证 · ISO 27001
简而言之：区块链数据流是一种基于推送的访问区块链数据的方式，当新的区块、交易和事件在链上生成时，会自动发送到您的应用程序或数据库中。您的应用程序无需反复向节点询问“有新数据吗？”（轮询），而是由流服务在数据一经生成时立即将其发送给您。 流式传输可降低延迟、避免事件遗漏、简化后端架构，并且其扩展效率远高于传统的请求-响应模式。
简明解释
从任何系统获取数据主要有两种基本方式：你可以主动请求（拉取），或者由系统主动发送给你（推送）。 在区块链发展的大部分时间里，开发者一直采用“拉取”模式。你的应用程序向节点发送一个 RPC 请求，节点返回响应，然后由你的应用程序决定何时再次请求。这就是轮询模式。这种模式虽然实现简单，但效率较低，尤其是在你的应用程序需要与区块链的最新状态保持同步时。
流式处理颠覆了这种模式。不再需要应用程序每天数千次地询问“最新区块发生了什么”，而是只需建立一次数据管道，流式处理服务就会在每个新区块生成时，将其数据直接传递给您的应用程序或数据库。您的应用程序由此成为连续数据流的消费者，而非离散数据快照的请求者。
这个比喻就像是每五分钟刷新一次新闻网站，与订阅推送通知——在新闻一经发布时立即收到提醒——之间的区别。虽然两种方式最终都能获得相同的信息，但推送模式更快、更省时，也更可靠。
区块链数据流的工作原理
流式处理服务位于区块链节点与您的应用程序或数据基础设施之间。在数据摄取端，该服务连接到受支持网络中的各个节点，并在每个新区块最终确定后立即对其进行处理。它会提取原始区块数据，包括区块头、交易、交易收据（含事件日志）以及可选的执行跟踪信息。这些原始数据完整记录了该区块中发生的一切。
在处理环节，流式服务会应用您所配置的任何过滤器或转换规则。例如，您可能只关注来自特定合约集的 ERC-20 转账事件。由 JavaScript 或其他受支持语言编写的过滤器会对每个区块的数据进行处理，仅让符合您条件的记录通过。这种服务器端的过滤对效率至关重要，因为这意味着您的目标端只会接收并存储您实际需要的数据，而非整个区块。
在数据传输方面，经过过滤的数据将发送至您配置的目标位置。这可以是您的应用程序监听的 Webhook URL、PostgreSQL 数据库、Snowflake 数据仓库、Amazon S3 存储桶、Azure Blob Storage，或是其他受支持的端点。流式传输服务负责处理传输保障，包括失败时的重试、去重以及正确排序，从而确保您的目标位置能够接收无间断、顺序排列的区块链数据流。
流式处理与传统ETL方法的对比
传统的区块链 ETL（提取、转换、加载）管道要求开发人员构建和维护庞大的基础设施。 典型的自定义 ETL 架构通常包括：一个按计划调用 RPC 端点以获取新区块的轮询 worker；一个负责解码和转换原始数据的处理层；一个负责插入记录的数据库写入器；一个管理重试和故障的错误处理程序；一个用于识别并回滚来自被放弃分叉的数据的重组检测器；以及在任何组件出现故障时发出警报的监控机制。每个组件都增加了系统复杂性，且每个组件都是潜在的故障点。
流式服务将所有这些功能整合到一条统一管理的管道中。数据提取、过滤、转换、传输、重试逻辑、排序以及重组织处理等操作均在提供商的基础设施上完成。您只需配置所需的数据、数据发送目标以及数据处理方式。这极大地减少了构建和维护区块链数据基础设施所需的工程工作量。
性能差异同样显著。基于轮询的管道其延迟本质上等于轮询间隔。如果你的工作节点每 5 秒检查一次是否有新区块，那么即使一切运行完美，你仍可能比区块链末端滞后多达 5 秒。由于错误、速率限制或工作节点重启导致的轮询遗漏会进一步拉大这一差距。 流式传输消除了轮询延迟，因为数据一经生成就会立即推送。在每几百毫秒就会生成一个区块的高吞吐量区块链上，对于对延迟敏感的应用程序而言，这一差异意义重大。
生产流媒体的主要特点
生产级流式传输与简单的 WebSocket 订阅相比，具有多项显著特点。可靠交付机制可确保每个数据块的数据仅被发送一次至目标端，即使连接暂时中断或目标端出现短暂故障也是如此。流式传输服务会进行缓冲并不断重试，直到确认数据已成功送达，因此您的数据中绝不会出现缺失。
最终性顺序交付意味着数据按照区块链视为规范的顺序到达。在最终性时间可变的区块链上，流式传输服务会等待区块获得充分确认后再进行交付，从而防止您的应用程序处理那些可能因重组而在后续被视为无效的数据。当发生重组时，该服务会检测到分叉，识别哪些区块不再是规范的，并发送更正数据包，以便目标端能够相应地进行更新。
历史数据回填功能使您能够将同一条流式处理管道用于历史数据，而不仅仅适用于新区块。您无需为历史数据和实时数据分别构建独立的ETL流程，只需配置一条以过去某个区块为起点的流，让其向前处理历史数据，待其追上区块链末端后，即可无缝过渡到实时处理。这种统一的管道简化了您的架构，并确保了历史数据与实时数据之间的一致性。
服务器端过滤和转换可减少到达目标端的数据量，从而降低带宽成本、存储成本和处理开销。过滤器可根据地址、事件签名、函数选择器、事务值或块数据的任何其他属性进行匹配。转换操作可重构有效载荷、解码 ABI 编码的数据、计算派生值，并以与您的数据库表匹配的模式输出记录。
Quicknode Streams 如何提供区块链数据流服务
QuicknodeStreams 是一项 专为区块链数据流和 ETL 设计的专用服务，可提供覆盖 80 多条区块链的实时和历史数据，并具备内置过滤、转换及交付保障功能。Streams 支持多种数据集类型（区块、交易、收据、事件日志、跟踪记录）和多种目标（Webhook、PostgreSQL、Snowflake、Amazon S3、Azure Storage 等）。
Streams 按照最终性顺序处理数据，并保证“仅一次”交付；通过发送更正负载自动处理链重组；同时支持可配置的批处理和压缩功能，以在历史数据补全过程中实现最佳吞吐量。JavaScript 过滤器在 Quicknode 的基础设施上运行，允许您在数据到达目标之前对事件进行解码、匹配模式、引用外部键值存储，以及塑造输出负载。 一键式数据补全模板为 20 多条区块链上的常见数据集提供了预配置的管道，并在您开始操作前清晰显示成本和预计完成时间。
对于更复杂的工作流，Streams 与 Quicknode Functions 集成，可在流式数据基础上实现无服务器自动化。Functions 可以利用额外的链上数据丰富记录内容、调用外部 API、触发通知，或根据流式事件执行任意业务逻辑。Streams 与 Functions 相结合，提供了一个完整的区块链数据平台，用可托管且可扩展的解决方案取代了自定义 ETL 基础设施。
流式传输和轮询有什么区别？
轮询和流式传输是应用程序跟踪链上活动的两种方式，它们处于一个光谱的两端。轮询采用拉取模式：应用程序会反复向节点查询是否有新数据。流式传输采用推送模式：服务会在新数据一经生成时立即将其发送给您。下表从选择方案时最关键的几个维度对这两种方式进行了比较。
维度 | 民意调查 | 流媒体 |
|---|
数据流 | 应用程序按计划运行 | 服务在数据生成时进行推送 |
延迟 | 受投票间隔的限制 | 近实时，无间隔延迟 |
数据缺失风险 | 若调查失败或被跳过，则会出现数据缺失 | 保证无缝交付 |
重组处理 | 自己动手做 | 通过校正有效载荷内置 |
运行负荷 | 您负责运行和扩展工作进程 | 由服务提供商管理 |
如需更深入地比较这两种分发模式以及何时适用哪种模式，请参阅“轮询与流式传输”一文。
区块链数据流有哪些常见的应用场景？
流式处理适用于任何必须快速响应链上活动或保持数据库持续同步的工作负载。常见的示例包括实时钱包和投资组合追踪、DeFi 仪表盘、交易和清算机器人、NFT 铸造与销售监控、欺诈和合规警报，以及摄取每个区块的数据分析仓库。这些应用均受益于低延迟和无缝数据传输，而非周期性快照。如需查看更全面的模式列表，请参阅区块链流式处理用例。
流式处理如何处理实时数据与历史数据？
一个强大的流处理管道将实时数据和历史数据视为一条连续的时间线，而非两个独立的系统。 您可以从过去很久的区块开始一个流，让它向前回填历史数据，然后在追上区块链末端时无缝过渡到实时区块。这样就避免了维护两个具有不同代码路径的管道。要了解最新数据与存档数据之间的权衡，请参阅“实时与历史区块链数据”；关于回填策略，请参阅“如何访问历史区块链数据”。
流式处理如何应对区块链重组？
重组是处理实时区块链数据过程中最棘手的部分，因为应用程序已经处理过的区块可能会被竞争区块取代。生产级流式服务通过按最终性顺序传输数据来处理这一问题；当发生重组时，系统会发送更正数据包，告知目标端哪些区块不再是规范区块，以便其回滚受影响的记录。这消除了自定义管道中最容易出错的环节之一。更多详情请参阅“什么是区块链重组”。
流式处理与索引有什么区别？
流式处理和索引解决的是相关但不同的问题。流式处理侧重于数据传输：在数据产生的同时将其传输到目标位置。索引则侧重于数据组织：将数据结构化为可查询的数据库，以便您能够快速执行历史查询和聚合查询。许多团队会利用流式处理向索引提供数据，然后通过查询索引来进行分析。请参阅“什么是区块链索引”和“如何查询区块链数据”，了解这些组件是如何相互配合的。
常见问题解答
区块链数据流与 WebSocket 订阅是一回事吗？
不完全是这样。WebSocket 订阅是一种低级连接，在套接字保持打开状态时会推送事件，但它不提供投递保证，且一旦连接中断就会停止。生产级流式传输在此基础推送模型之上，额外提供了“仅一次”投递、最终性排序、重组纠正、服务器端过滤以及历史数据补全等功能。
流媒体播放能保证我不会错过任何片段吗？
是的，通过生产级服务即可实现。有保障的交付意味着服务提供商会进行缓冲并不断重试，直到每个数据块在目标端得到确认，因此即使您的终端出现短暂中断，您也能获得无缝的数据流。像Quicknode Webhooks这样的推送式事件服务，也会将相同的可靠性原则应用于事件通知。
在流式数据到达目标之前，我可以对其进行过滤吗？
是的。服务器端过滤功能允许您根据地址、事件签名、函数选择器、值或阻塞的任何其他属性进行匹配，从而仅将您关心的记录传递给您。由于您永远不会收到不需要的数据，因此这可以降低带宽、存储和处理成本。
流处理能否取代自定义的ETL管道？
对于大多数团队来说，确实如此。托管流式处理服务将数据提取、过滤、转换、交付、重试、排序以及重组处理整合到一条管道中，从而消除了自建 ETL 架构中众多复杂的组件。您只需配置所需的数据及其流向，其余工作由服务提供商负责处理。
流式数据可以传输到哪些目的地？
常见的目标包括 Webhook URL、PostgreSQL、Snowflake、Amazon S3 和 Azure Blob Storage 等。这使您能够将流式数据直接传输到应用程序后端、数据仓库或对象存储中，而无需为每个目标分别构建自定义连接器。
延伸阅读
