在Google Cloud上构建通用数据库（Database）- DataFlow1-

2 年 ago
科, 雅
1 minute

我們的團隊正在設計一個採用微服務架構的下一代後端，在全公共雲平台上進行。

经过

在之前的帖子中，我們大致確定了我們的目標，所以我們將在團隊內對每個子系統進行原型製作。這次我們來試試DataFlow。

前提

有一些关于CloudDataFlow的先前知识需要总结一下，所以我会一起总结出来。
※我会逐步增加。

总结

スクリーンショット 2016-10-28 23.30.56.png

部署

使用Eclipse或Maven创建的成果物将会被传输到CloudStorage中。
当成果物，如jar文件等传输到CloudStorage时，几乎同时会自动创建GCE实例，
并将其部署到该实例中。本次将参考此方案，在Eclipse中进行构建。

跑步者 zhě)

有几种可用的选项可以作为定义好的管道的启动模式（Runner）。

PipelineRunner概要DataflowPipelineRunnerパイプラインは、Googleのクラウド上で非同期に実行される。ジョブの進捗状況を監視することが可能。BlockingDataflowPipelineRunnerDataflowPipelineRunnerと同じように、クラウド上で実行されるが、立ち上げたジョブが終了するのを待ちます。ジョブを実行しながら、待っている間、ジョブステータスの更新とコンソールメッセージを出力する。DirectPipelineRunnerlocal execution, not in Google Cloud. ローカルマシンからの実行（クラウド上で実行しない）

来源: https://cloud.google.com/dataflow/pipelines/specifying-exec-params#asynchronous-execution

将下述内容以中文进行改写（只需要一个翻译版本）：

“Cloud Dataflow pipelines can be executed synchronously or asynchronously. In synchronous execution, the pipeline will not return until all the elements have been processed. In asynchronous execution, the pipeline initiates processing and returns immediately, allowing the caller to continue with other work. Asynchronous execution is useful when the caller does not require the pipeline’s full results before proceeding. To specify asynchronous execution in a pipeline, you need to set the appropriate execution parameters.”

有限的和无限的

数据可以通过PCollection对象进行交换，但存在两种形式。

PCollection概要in,outbounded有限リソースTextIO,BigQueryIO,DatastoreIOunbounded断続的リソース（stream）PubsubIO,BigQueryIO

来源：https://cloud.google.com/dataflow/model/pcollection#bounded-and-unbounded-pcollections

有界和无界的PCollection

有界和无界的PCollection是对数据集合进行分类的一种方式。有界PCollection表示数据集合的大小已知且有限，而无界PCollection表示数据集合的大小未知且可能无限。

在有界PCollection中，数据集合的大小通常是可预测的，并且会在某个时间点完成。对于这种类型的PCollection，我们可以在一次性处理中读取和处理整个数据集合。

相比之下，无界PCollection表示可能是无限的数据集合，其大小无法预测，并且可能随着时间的推移而增长。对于这种类型的数据集合，我们需要使用流式处理技术来连续地读取和处理数据。

有界和无界PCollection对于不同类型的数据处理任务非常重要，因此在使用Google Dataflow时需要了解它们之间的区别和适用场景。

因为本次是从PubsubIO到DatastoreIO，所以必须以一定的块来处理流数据。
解决方案是提供了窗口处理，因此可以使用它。

流式自动扩展

目前是2016年10月。

Beta
这是一个流媒体自动扩展的Beta版本。此功能可能会以不兼容的方式进行更改，且不受任何SLA或弃用政策的约束。

关于流式自动缩放，还是处于测试阶段。。。嗯。。。

流式自动缩放管道使用的工人数量在N/15到N之间变动，其中N是–maxNumWorkers的值。例如，如果您的管道在稳定状态下需要3或4个工人，您可以将–maxNumWorkers设置为15，管道将自动在1个工人和15个工人之间进行缩放。
–maxNumWorkers最多可为1000。

示例中有提到使用Worker 3或4，并指定–maxNumWorkers=15。在实际处理中，这似乎需要有一些性能优化。

来源：https://cloud.google.com/dataflow/faq

答：以下是对此的中国句子表达：

来源：https://cloud.google.com/dataflow/faq

云Pub/Sub的消息顺序性（一席话）

在途中我意识到Cloud Pub/Sub完全不保证消息的顺序性。或者说，从下面的内容来看，顺序性真的需要吗？这似乎是他们的立场。虽然没有明确提及这一点，但重点是在可扩展性和高可用性之间做取舍。

我明白了。您说得对。设计上类似于Apache Kafka，但需要重新考虑……果然还是需要大家一起投入进去。

    Message Ordering

下一次

下次终于能亲手操作了，但需要相当多的先备知识。我的技能水平让人困扰。。。

bannerAds