You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@beam.apache.org by ja...@apache.org on 2016/05/27 17:06:46 UTC
[3/4] incubator-beam-site git commit: Resolve merge
Resolve merge
Project: http://git-wip-us.apache.org/repos/asf/incubator-beam-site/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator-beam-site/commit/b61cca94
Tree: http://git-wip-us.apache.org/repos/asf/incubator-beam-site/tree/b61cca94
Diff: http://git-wip-us.apache.org/repos/asf/incubator-beam-site/diff/b61cca94
Branch: refs/heads/asf-site
Commit: b61cca94a607e86ba0eec8c0dfa5ead35f9318ea
Parents: 15dd578
Author: James Malone <ja...@gmail.com>
Authored: Fri May 27 09:54:23 2016 -0700
Committer: James Malone <ja...@gmail.com>
Committed: Fri May 27 10:03:00 2016 -0700
----------------------------------------------------------------------
.../05/20/where-is-my-pcollection-dot-map.html | 212 +++++++++++++++++++
content/blog/index.html | 16 ++
content/capability-matrix/index.html | 4 +
content/feed.xml | 96 ++++++++-
content/index.html | 2 +
5 files changed, 328 insertions(+), 2 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/b61cca94/content/blog/2016/05/20/where-is-my-pcollection-dot-map.html
----------------------------------------------------------------------
diff --git a/content/blog/2016/05/20/where-is-my-pcollection-dot-map.html b/content/blog/2016/05/20/where-is-my-pcollection-dot-map.html
new file mode 100644
index 0000000..a45cb9c
--- /dev/null
+++ b/content/blog/2016/05/20/where-is-my-pcollection-dot-map.html
@@ -0,0 +1,212 @@
+<!DOCTYPE html>
+<html lang="en">
+
+ <head>
+ <meta charset="utf-8">
+ <meta http-equiv="X-UA-Compatible" content="IE=edge">
+ <meta name="viewport" content="width=device-width, initial-scale=1">
+
+ <title>Where's my PCollection.map()?</title>
+ <meta name="description" content="Have you ever wondered why Beam has PTransforms for everything instead of having methods on PCollection? Take a look at the history that led to this (and oth...">
+
+ <link rel="stylesheet" href="/styles/site.css">
+ <link rel="stylesheet" href="/css/theme.css">
+ <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.2.0/jquery.min.js"></script>
+ <script src="/js/bootstrap.min.js"></script>
+ <link rel="canonical" href="http://beam.incubator.apache.org/blog/2016/05/20/where-is-my-pcollection-dot-map.html">
+ <link rel="alternate" type="application/rss+xml" title="Apache Beam (incubating)" href="http://beam.incubator.apache.org/feed.xml">
+ <script>
+ (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+ m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+ })(window,document,'script','//www.google-analytics.com/analytics.js','ga');
+
+ ga('create', 'UA-73650088-1', 'auto');
+ ga('send', 'pageview');
+
+ </script>
+ <link rel="shortcut icon" type="image/x-icon" href="/images/favicon.ico">
+</head>
+
+
+ <body role="document">
+
+ <nav class="navbar navbar-default navbar-fixed-top">
+ <div class="container">
+ <div class="navbar-header">
+ <a href="/" class="navbar-brand" >
+ <img alt="Brand" style="height: 25px" src="/images/beam_logo_navbar.png">
+ </a>
+ <button type="button" class="navbar-toggle collapsed" data-toggle="collapse" data-target="#navbar" aria-expanded="false" aria-controls="navbar">
+ <span class="sr-only">Toggle navigation</span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ </button>
+ </div>
+ <div id="navbar" class="navbar-collapse collapse">
+ <ul class="nav navbar-nav">
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" aria-haspopup="true" aria-expanded="false">Documentation <span class="caret"></span></a>
+ <ul class="dropdown-menu">
+ <li class="dropdown-header">Guides</li>
+ <li><a href="/getting_started/">Getting Started</a></li>
+ <li role="separator" class="divider"></li>
+ <li class="dropdown-header">Technical Documentation</li>
+ <li><a href="/capability-matrix/">Capability Matrix</a></li>
+ <li><a href="https://goo.gl/ps8twC">Technical Docs</a></li>
+ <li><a href="https://goo.gl/nk5OM0">Technical Vision</a></li>
+ </ul>
+ </li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" aria-haspopup="true" aria-expanded="false">Community <span class="caret"></span></a>
+ <ul class="dropdown-menu">
+ <li class="dropdown-header">Community</li>
+ <li><a href="/mailing_lists/">Mailing Lists</a></li>
+ <li><a href="/team/">Apache Beam Team</a></li>
+ <li><a href="/public-meetings/">Public Meetings</a></li>
+ <li role="separator" class="divider"></li>
+ <li class="dropdown-header">Contribute</li>
+ <li><a href="/contribution-guide/">Contribution Guide</a></li>
+ <li><a href="/source_repository/">Source Repository</a></li>
+ <li><a href="/issue_tracking/">Issue Tracking</a></li>
+ </ul>
+ </li>
+ <li><a href="/blog">Blog</a></li>
+ <li class="dropdown">
+ <a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" aria-haspopup="true" aria-expanded="false">Project <span class="caret"></span></a>
+ <ul class="dropdown-menu">
+ <li><a href="/presentation-materials/">Presentation Materials</a></li>
+ <li><a href="/material/">Logos and design</a></li>
+ <li><a href="http://apache.org/licenses/LICENSE-2.0.html">License</a></li>
+ </ul>
+ </li>
+ </ul>
+ </div><!--/.nav-collapse -->
+ </div>
+</nav>
+
+
+<link rel="stylesheet" href="">
+
+
+ <div class="container" role="main">
+
+ <div class="container">
+
+
+<article class="post" itemscope itemtype="http://schema.org/BlogPosting">
+
+ <header class="post-header">
+ <h1 class="post-title" itemprop="name headline">Where's my PCollection.map()?</h1>
+ <p class="post-meta"><time datetime="2016-05-20T11:00:00-07:00" itemprop="datePublished">May 20, 2016</time> \u2022 Robert Bradshaw
+</p>
+ </header>
+
+ <div class="post-content" itemprop="articleBody">
+ <p>Have you ever wondered why Beam has PTransforms for everything instead of having methods on PCollection? Take a look at the history that led to this (and other) design decisions.
+<!--more-->
+Though Beam is relatively new, its design draws heavily on many years of experience with real-world pipelines. One of the primary inspirations is <a href="http://research.google.com/pubs/pub35650.html">FlumeJava</a>, which is Google\u2019s internal successor to MapReduce first introduced in 2009.</p>
+
+<p>The original FlumeJava API has methods like <code class="highlighter-rouge">count</code> and <code class="highlighter-rouge">parallelDo</code> on the PCollections. Though slightly more succinct, this approach has many disadvantages to extensibility. Every new user to FlumeJava wanted to add transforms, and adding them as methods to PCollection simply doesn\u2019t scale well. In contrast, a PCollection in Beam has a single <code class="highlighter-rouge">apply</code> method which takes any PTransform as an argument.</p>
+
+<p>Have you ever wondered why Beam has PTransforms for everything instead of having methods on PCollection? Take a look at the history that led to this (and other) design decisions.</p>
+
+<table class="table">
+ <tr>
+ <th>FlumeJava</th>
+ <th>Beam</th>
+ </tr>
+ <tr>
+ <td><pre>
+PCollection<T> input = \u2026
+PCollection<O> output = input.count()
+ .parallelDo(...);
+ </pre></td>
+ <td><pre>
+PCollection<T> input = \u2026
+PCollection<O> output = input.apply(Count.perElement())
+ .apply(ParDo.of(...));
+ </pre></td>
+ </tr>
+</table>
+
+<p>This is a more scalable approach for several reasons.</p>
+
+<h2 id="where-to-draw-the-line">Where to draw the line?</h2>
+<p>Adding methods to PCollection forces a line to be drawn between operations that are \u201cuseful\u201d enough to merit this special treatment and those that are not. It is easy to make the case for flat map, group by key, and combine per key. But what about filter? Count? Approximate count? Approximate quantiles? Most frequent? WriteToMyFavoriteSource? Going too far down this path leads to a single enormous class that contains nearly everything one could want to do. (FlumeJava\u2019s PCollection class is over 5000 lines long with around 70 distinct operations, and it could have been <em>much</em> larger had we accepted every proposal.) Furthermore, since Java doesn\u2019t allow adding methods to a class, there is a sharp syntactic divide between those operations that are added to PCollection and those that aren\u2019t. A traditional way to share code is with a library of functions, but functions (in traditional languages like Java at least) are written prefix-style, which doesn\u2019t mix well wit
h the fluent builder style (e.g. <code class="highlighter-rouge">input.operation1().operation2().operation3()</code> vs. <code class="highlighter-rouge">operation3(operation1(input).operation2())</code>).</p>
+
+<p>Instead in Beam we\u2019ve chosen a style that places all transforms\u2013whether they be primitive operations, composite operations bundled in the SDK, or part of an external library\u2013on equal footing. This also facilitates alternative implementations (which may even take different options) that are easily interchangeable.</p>
+
+<table class="table">
+ <tr>
+ <th>FlumeJava</th>
+ <th>Beam</th>
+ </tr>
+ <tr>
+ <td><pre>
+PCollection<O> output =
+ ExternalLibrary.doStuff(
+ MyLibrary.transform(input, myArgs)
+ .parallelDo(...),
+ externalLibArgs);
+ </pre></td>
+ <td><pre>
+PCollection<O> output = input
+ .apply(MyLibrary.transform(myArgs))
+ .apply(ParDo.of(...))
+ .apply(ExternalLibrary.doStuff(externalLibArgs));
+
+ </pre></td>
+ </tr>
+</table>
+
+<h2 id="configurability">Configurability</h2>
+<p>It makes for a fluent style to let values (PCollections) be the objects passed around and manipulated (i.e. the handles to the deferred execution graph), but it is the operations themselves that need to be composable, configurable, and extendable. Using PCollection methods for the operations doesn\u2019t scale well here, especially in a language without default or keyword arguments. For example, a ParDo operation can have any number of side inputs and side outputs, or a write operation may have configurations dealing with encoding and compression. One option is to separate these out into multiple overloads or even methods, but that exacerbates the problems above. (FlumeJava evolved over a dozen overloads of the <code class="highlighter-rouge">parallelDo</code> method!) Another option is to pass each method a configuration object that can be built up using more fluent idioms like the builder pattern, but at that point one might as well make the configuration object the operation itse
lf, which is what Beam does.</p>
+
+<h2 id="type-safety">Type Safety</h2>
+<p>Many operations can only be applied to collections whose elements are of a specific type. For example, the GroupByKey operation should only be applied to <code class="highlighter-rouge">PCollection<KV<K, V>></code>s. In Java at least, it\u2019s not possible to restrict methods based on the element type parameter alone. In FlumeJava, this led us to add a <code class="highlighter-rouge">PTable<K, V></code> subclassing <code class="highlighter-rouge">PCollection<KV<K, V>></code> to contain all the operations specific to PCollections of key-value pairs. This leads to the same question of which element types are special enough to merit being captured by PCollection subclasses. It is not very extensible for third parties and often requires manual downcasts/conversions (which can\u2019t be safely chained in Java) and special operations that produce these PCollection specializations.</p>
+
+<p>This is particularly inconvenient for transforms that produce outputs whose element types are the same as (or related to) their input\u2019s element types, requiring extra support to generate the right subclasses (e.g. a filter on a PTable should produce another PTable rather than just a raw PCollection of key-value pairs).</p>
+
+<p>Using PTransforms allows us to sidestep this entire issue. We can place arbitrary constraints on the context in which a transform may be used based on the type of its inputs; for instance GroupByKey is statically typed to only apply to a <code class="highlighter-rouge">PCollection<KV<K, V>></code>. The way this happens is generalizable to arbitrary shapes, without needing to introduce specialized types like PTable.</p>
+
+<h2 id="reusability-and-structure">Reusability and Structure</h2>
+<p>Though PTransforms are generally constructed at the site at which they\u2019re used, by pulling them out as separate objects one is able to store them and pass them around.</p>
+
+<p>As pipelines grow and evolve, it is useful to structure your pipeline into modular, often reusable components, and PTransforms allow one to do this nicely in a data-processing pipeline. In addition, modular PTransforms also expose the logical structure of your code to the system (e.g. for monitoring). Of the three different representations of the WordCount pipeline below, only the structured view captures the high-level intent of the pipeline. Letting even the simple operations be PTransforms means there\u2019s less of an abrupt edge to packaging things up into composite operations.</p>
+
+<p><img class="center-block" src="/images/blog/simple-wordcount-pipeline.png" alt="Three different visualizations of a simple WordCount pipeline" width="500" /></p>
+
+<div class="text-center">
+<i>Three different visualizations of a simple WordCount pipeline which computes the number of occurrences of every word in a set of text files. The flag view gives the full DAG of all operations performed. The execution view groups operations according to how they're executed, e.g. after performing runner-specific optimizations like function composition. The structured view nests operations according to their grouping in PTransforms.</i>
+</div>
+
+<h2 id="summary">Summary</h2>
+<p>Although it\u2019s tempting to add methods to PCollections, such an approach is not scalable, extensible, or sufficiently expressive. Putting a single apply method on PCollection and all the logic into the operation itself lets us have the best of both worlds, and avoids hard cliffs of complexity by having a single consistent style across simple and complex pipelines, and between predefined and user-defined operations.</p>
+
+ </div>
+
+</article>
+
+ </div>
+
+
+ <hr>
+ <div class="row">
+ <div class="col-xs-12">
+ <footer>
+ <p class="text-center">© Copyright 2016
+ <a href="http://www.apache.org">The Apache Software Foundation.</a> All Rights Reserved.</p>
+ <p class="text-center"><a href="/privacy_policy">Privacy Policy</a> |
+ <a href="/feed.xml">RSS Feed</a></p>
+ </footer>
+ </div>
+ </div>
+ <!-- container div end -->
+</div>
+
+
+ </body>
+
+</html>
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/b61cca94/content/blog/index.html
----------------------------------------------------------------------
diff --git a/content/blog/index.html b/content/blog/index.html
index d72dfbb..a352f45 100644
--- a/content/blog/index.html
+++ b/content/blog/index.html
@@ -104,6 +104,22 @@
<p>This is the blog for the Apache Beam project. This blog contains news and updates
for the project.</p>
+<h3 id="a-classpost-link-hrefblog20160520where-is-my-pcollection-dot-maphtmlwheres-my-pcollectionmapa"><a class="post-link" href="/blog/2016/05/20/where-is-my-pcollection-dot-map.html">Where\u2019s my PCollection.map()?</a></h3>
+<p><i>May 20, 2016 \u2022 Robert Bradshaw
+</i></p>
+
+<p>Have you ever wondered why Beam has PTransforms for everything instead of having methods on PCollection? Take a look at the history that led to this (and other) design decisions.</p>
+
+<!-- Render a "read more" button if the post is longer than the excerpt -->
+
+<p>
+<a class="btn btn-default btn-sm" href="/blog/2016/05/20/where-is-my-pcollection-dot-map.html#read-more" role="button">
+Read more <span class="glyphicon glyphicon-menu-right" aria-hidden="true"></span>
+</a>
+</p>
+
+<hr />
+
<h3 id="a-classpost-link-hrefblog20160518splitatfraction-methodhtmldynamic-work-rebalancing-for-beama"><a class="post-link" href="/blog/2016/05/18/splitAtFraction-method.html">Dynamic work rebalancing for Beam</a></h3>
<p><i>May 18, 2016 \u2022 Dan Halperin
</i></p>
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/b61cca94/content/capability-matrix/index.html
----------------------------------------------------------------------
diff --git a/content/capability-matrix/index.html b/content/capability-matrix/index.html
index 9981074..752e6b8 100644
--- a/content/capability-matrix/index.html
+++ b/content/capability-matrix/index.html
@@ -95,7 +95,11 @@
<div class="container">
<h1 id="apache-beam-capability-matrix">Apache Beam Capability Matrix</h1>
+<<<<<<< 657701378fc1935a67e5b5a5fe1427997b6c9029
<p><span style="font-size:11px;float:none">Last updated: 2016-05-27 18:38 CEST</span></p>
+=======
+<p><span style="font-size:11px;float:none">Last updated: 2016-05-20 14:42 PDT</span></p>
+>>>>>>> Regenerate to post PCollection blog post
<p>Apache Beam (incubating) provides a portable API layer for building sophisticated data-parallel processing engines that may be executed across a diversity of exeuction engines, or <i>runners</i>. The core concepts of this layer are based upon the Beam Model (formerly referred to as the <a href="http://www.vldb.org/pvldb/vol8/p1792-Akidau.pdf">Dataflow Model</a>), and implemented to varying degrees in each Beam runner. To help clarify the capabilities of individual runners, we\u2019ve created the capability matrix below.</p>
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/b61cca94/content/feed.xml
----------------------------------------------------------------------
diff --git a/content/feed.xml b/content/feed.xml
index 9a41d56..0208117 100644
--- a/content/feed.xml
+++ b/content/feed.xml
@@ -6,11 +6,103 @@
</description>
<link>http://beam.incubator.apache.org/</link>
<atom:link href="http://beam.incubator.apache.org/feed.xml" rel="self" type="application/rss+xml"/>
- <pubDate>Wed, 18 May 2016 20:55:36 -0700</pubDate>
- <lastBuildDate>Wed, 18 May 2016 20:55:36 -0700</lastBuildDate>
+ <pubDate>Fri, 20 May 2016 14:42:30 -0700</pubDate>
+ <lastBuildDate>Fri, 20 May 2016 14:42:30 -0700</lastBuildDate>
<generator>Jekyll v3.1.3</generator>
<item>
+ <title>Where's my PCollection.map()?</title>
+ <description><p>Have you ever wondered why Beam has PTransforms for everything instead of having methods on PCollection? Take a look at the history that led to this (and other) design decisions.
+<!--more-->
+Though Beam is relatively new, its design draws heavily on many years of experience with real-world pipelines. One of the primary inspirations is <a href="http://research.google.com/pubs/pub35650.html">FlumeJava</a>, which is Google\u2019s internal successor to MapReduce first introduced in 2009.</p>
+
+<p>The original FlumeJava API has methods like <code class="highlighter-rouge">count</code> and <code class="highlighter-rouge">parallelDo</code> on the PCollections. Though slightly more succinct, this approach has many disadvantages to extensibility. Every new user to FlumeJava wanted to add transforms, and adding them as methods to PCollection simply doesn\u2019t scale well. In contrast, a PCollection in Beam has a single <code class="highlighter-rouge">apply</code> method which takes any PTransform as an argument.</p>
+
+<p>Have you ever wondered why Beam has PTransforms for everything instead of having methods on PCollection? Take a look at the history that led to this (and other) design decisions.</p>
+
+<table class="table">
+ <tr>
+ <th>FlumeJava</th>
+ <th>Beam</th>
+ </tr>
+ <tr>
+ <td><pre>
+PCollection&lt;T&gt; input = \u2026
+PCollection&lt;O&gt; output = input.count()
+ .parallelDo(...);
+ </pre></td>
+ <td><pre>
+PCollection&lt;T&gt; input = \u2026
+PCollection&lt;O&gt; output = input.apply(Count.perElement())
+ .apply(ParDo.of(...));
+ </pre></td>
+ </tr>
+</table>
+
+<p>This is a more scalable approach for several reasons.</p>
+
+<h2 id="where-to-draw-the-line">Where to draw the line?</h2>
+<p>Adding methods to PCollection forces a line to be drawn between operations that are \u201cuseful\u201d enough to merit this special treatment and those that are not. It is easy to make the case for flat map, group by key, and combine per key. But what about filter? Count? Approximate count? Approximate quantiles? Most frequent? WriteToMyFavoriteSource? Going too far down this path leads to a single enormous class that contains nearly everything one could want to do. (FlumeJava\u2019s PCollection class is over 5000 lines long with around 70 distinct operations, and it could have been <em>much</em> larger had we accepted every proposal.) Furthermore, since Java doesn\u2019t allow adding methods to a class, there is a sharp syntactic divide between those operations that are added to PCollection and those that aren\u2019t. A traditional way to share code is with a library of functions, but functions (in traditional languages like Java at least) are written prefix-style, which does
n\u2019t mix well with the fluent builder style (e.g. <code class="highlighter-rouge">input.operation1().operation2().operation3()</code> vs. <code class="highlighter-rouge">operation3(operation1(input).operation2())</code>).</p>
+
+<p>Instead in Beam we\u2019ve chosen a style that places all transforms\u2013whether they be primitive operations, composite operations bundled in the SDK, or part of an external library\u2013on equal footing. This also facilitates alternative implementations (which may even take different options) that are easily interchangeable.</p>
+
+<table class="table">
+ <tr>
+ <th>FlumeJava</th>
+ <th>Beam</th>
+ </tr>
+ <tr>
+ <td><pre>
+PCollection&lt;O&gt; output =
+ ExternalLibrary.doStuff(
+ MyLibrary.transform(input, myArgs)
+ .parallelDo(...),
+ externalLibArgs);
+ </pre></td>
+ <td><pre>
+PCollection&lt;O&gt; output = input
+ .apply(MyLibrary.transform(myArgs))
+ .apply(ParDo.of(...))
+ .apply(ExternalLibrary.doStuff(externalLibArgs));
+ &nbsp;
+ </pre></td>
+ </tr>
+</table>
+
+<h2 id="configurability">Configurability</h2>
+<p>It makes for a fluent style to let values (PCollections) be the objects passed around and manipulated (i.e. the handles to the deferred execution graph), but it is the operations themselves that need to be composable, configurable, and extendable. Using PCollection methods for the operations doesn\u2019t scale well here, especially in a language without default or keyword arguments. For example, a ParDo operation can have any number of side inputs and side outputs, or a write operation may have configurations dealing with encoding and compression. One option is to separate these out into multiple overloads or even methods, but that exacerbates the problems above. (FlumeJava evolved over a dozen overloads of the <code class="highlighter-rouge">parallelDo</code> method!) Another option is to pass each method a configuration object that can be built up using more fluent idioms like the builder pattern, but at that point one might as well make the configurati
on object the operation itself, which is what Beam does.</p>
+
+<h2 id="type-safety">Type Safety</h2>
+<p>Many operations can only be applied to collections whose elements are of a specific type. For example, the GroupByKey operation should only be applied to <code class="highlighter-rouge">PCollection&lt;KV&lt;K, V&gt;&gt;</code>s. In Java at least, it\u2019s not possible to restrict methods based on the element type parameter alone. In FlumeJava, this led us to add a <code class="highlighter-rouge">PTable&lt;K, V&gt;</code> subclassing <code class="highlighter-rouge">PCollection&lt;KV&lt;K, V&gt;&gt;</code> to contain all the operations specific to PCollections of key-value pairs. This leads to the same question of which element types are special enough to merit being captured by PCollection subclasses. It is not very extensible for third parties and often requires manual downcasts/conversions (which can\u2019t be safely chained in Java) and special operations that produce thes
e PCollection specializations.</p>
+
+<p>This is particularly inconvenient for transforms that produce outputs whose element types are the same as (or related to) their input\u2019s element types, requiring extra support to generate the right subclasses (e.g. a filter on a PTable should produce another PTable rather than just a raw PCollection of key-value pairs).</p>
+
+<p>Using PTransforms allows us to sidestep this entire issue. We can place arbitrary constraints on the context in which a transform may be used based on the type of its inputs; for instance GroupByKey is statically typed to only apply to a <code class="highlighter-rouge">PCollection&lt;KV&lt;K, V&gt;&gt;</code>. The way this happens is generalizable to arbitrary shapes, without needing to introduce specialized types like PTable.</p>
+
+<h2 id="reusability-and-structure">Reusability and Structure</h2>
+<p>Though PTransforms are generally constructed at the site at which they\u2019re used, by pulling them out as separate objects one is able to store them and pass them around.</p>
+
+<p>As pipelines grow and evolve, it is useful to structure your pipeline into modular, often reusable components, and PTransforms allow one to do this nicely in a data-processing pipeline. In addition, modular PTransforms also expose the logical structure of your code to the system (e.g. for monitoring). Of the three different representations of the WordCount pipeline below, only the structured view captures the high-level intent of the pipeline. Letting even the simple operations be PTransforms means there\u2019s less of an abrupt edge to packaging things up into composite operations.</p>
+
+<p><img class="center-block" src="/images/blog/simple-wordcount-pipeline.png" alt="Three different visualizations of a simple WordCount pipeline" width="500" /></p>
+
+<div class="text-center">
+<i>Three different visualizations of a simple WordCount pipeline which computes the number of occurrences of every word in a set of text files. The flag view gives the full DAG of all operations performed. The execution view groups operations according to how they're executed, e.g. after performing runner-specific optimizations like function composition. The structured view nests operations according to their grouping in PTransforms.</i>
+</div>
+
+<h2 id="summary">Summary</h2>
+<p>Although it\u2019s tempting to add methods to PCollections, such an approach is not scalable, extensible, or sufficiently expressive. Putting a single apply method on PCollection and all the logic into the operation itself lets us have the best of both worlds, and avoids hard cliffs of complexity by having a single consistent style across simple and complex pipelines, and between predefined and user-defined operations.</p>
+</description>
+ <pubDate>Fri, 20 May 2016 11:00:00 -0700</pubDate>
+ <link>http://beam.incubator.apache.org/blog/2016/05/20/where-is-my-pcollection-dot-map.html</link>
+ <guid isPermaLink="true">http://beam.incubator.apache.org/blog/2016/05/20/where-is-my-pcollection-dot-map.html</guid>
+
+
+ <category>blog</category>
+
+ </item>
+
+ <item>
<title>Dynamic work rebalancing for Beam</title>
<description><p>This morning, Eugene and Malo from the Google Cloud Dataflow team posted <a href="https://cloud.google.com/blog/big-data/2016/05/no-shard-left-behind-dynamic-work-rebalancing-in-google-cloud-dataflow"><em>No shard left behind: dynamic work rebalancing in Google Cloud Dataflow</em></a>. This article discusses Cloud Dataflow\u2019s solution to the well-known straggler problem.</p>
http://git-wip-us.apache.org/repos/asf/incubator-beam-site/blob/b61cca94/content/index.html
----------------------------------------------------------------------
diff --git a/content/index.html b/content/index.html
index f875a64..c744043 100644
--- a/content/index.html
+++ b/content/index.html
@@ -177,6 +177,8 @@
<h3>Blog</h3>
<div class="list-group">
+ <a class="list-group-item" href="/blog/2016/05/20/where-is-my-pcollection-dot-map.html">May 20, 2016 - Where's my PCollection.map()?</a>
+
<a class="list-group-item" href="/blog/2016/05/18/splitAtFraction-method.html">May 18, 2016 - Dynamic work rebalancing for Beam</a>
<a class="list-group-item" href="/beam/capability/2016/04/03/presentation-materials.html">Apr 3, 2016 - Apache Beam Presentation Materials</a>