This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/beam.git
The following commit(s) were added to refs/heads/asf-site by this push:
new d82624a Publishing website 2020/01/21 17:16:15 at commit c8348d8
d82624a is described below
commit d82624ad55c13fc1c4e371c75dce78bdc4d1adc0
Author: jenkins <[email protected]>
AuthorDate: Tue Jan 21 17:16:16 2020 +0000
Publishing website 2020/01/21 17:16:15 at commit c8348d8
---
website/generated-content/blog/2017/02/13/stateful-processing.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/website/generated-content/blog/2017/02/13/stateful-processing.html
b/website/generated-content/blog/2017/02/13/stateful-processing.html
index dcccc4d..cb2aae2 100644
--- a/website/generated-content/blog/2017/02/13/stateful-processing.html
+++ b/website/generated-content/blog/2017/02/13/stateful-processing.html
@@ -386,7 +386,7 @@ imagine: The state you should store is the next index.</p>
<p>This presents a good opportunity to talk about big data and parallelism,
because the algorithm in those bullet points is not parallelizable at all! If
you wanted to apply this logic over an entire <code
class="highlighter-rouge">PCollection</code>, you would have to
-process each element of the <code class="highlighter-rouge">PCollection</code>
one-at-a-time… this is obvious a
+process each element of the <code class="highlighter-rouge">PCollection</code>
one-at-a-time… this is obviously a
bad idea. State in Beam is tightly scoped so that most of the time a stateful
<code class="highlighter-rouge">ParDo</code> transform should still be
possible for a runner to execute in parallel,
though you still have to be thoughtful about it.</p>
