| <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Apache Beam – python</title><link>/categories/python/</link><description>Recent content in python on Apache Beam</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Wed, 09 Nov 2022 00:00:01 -0800</lastBuildDate><atom:link href="/categories/python/index.xml" rel="self" type="application/rss+xml"/><item><title>Blog: New Resources Available for Beam ML</title><link>/blog/ml-resources/</link><pubDate>Wed, 09 Nov 2022 00:00:01 -0800</pubDate><guid>/blog/ml-resources/</guid><description> |
| <!-- |
| Licensed under the Apache License, Version 2.0 (the "License"); |
| you may not use this file except in compliance with the License. |
| You may obtain a copy of the License at |
| http://www.apache.org/licenses/LICENSE-2.0 |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| <p>If you&rsquo;ve been paying attention, over the past year you&rsquo;ve noticed that |
| Beam has released a number of features designed to make Machine Learning |
| easy. Ranging from things like the introduction of the <code>RunInference</code> |
| transform to the continued refining of <code>Beam Dataframes</code>, this has been |
| an area where we&rsquo;ve seen Beam make huge strides. While development has |
| advanced quickly, however, until recently there has been a lack of |
| resources to help people discover and use these new features.</p> |
| <p>Over the past several months, we&rsquo;ve been hard at work building out |
| documentation and notebooks to make it easier to use these new features |
| and to show how Beam can be used to solve common Machine Learning problems. |
| We&rsquo;re now happy to present this new and improved Beam ML experience!</p> |
| <p>To get started, we encourage you to visit Beam&rsquo;s new <a href="/documentation/ml/overview/">AI/ML landing page</a>. |
| We&rsquo;ve got plenty of content on things like <a href="/documentation/ml/multi-model-pipelines/">multi-model pipelines</a>, |
| <a href="/documentation/ml/runinference-metrics/">performing inference with metrics</a>, |
| <a href="/documentation/ml/online-clustering/">online training</a>, and much more.</p> |
| <p><img class="center-block" |
| src="/images/blog/ml-landing.png" |
| alt="ML landing page"></p> |
| <p>We&rsquo;ve also introduced a number of example <a href="https://github.com/apache/beam/tree/master/examples/notebooks/beam-ml">Jupyter Notebooks</a> |
| showing how to use built in beam transforms like <code>RunInference</code> and <code>Beam Dataframes</code>.</p> |
| <p><img class="center-block" |
| src="/images/blog/ensemble-model-notebook.png" |
| alt="Example ensemble notebook with RunInference"></p> |
| <p>Adding more examples and notebooks will be a point of emphasis going forward. |
| For our next round of improvements, we are planning on adding examples of |
| using RunInference with &gt;30GB models, with multi-language pipelines, with |
| common Beam concepts, and with TensorRT. We will also add examples showing |
| other pieces of the Machine Learning lifecycle like model evaluation with TFMA, |
| per-entity training, and more online training.</p> |
| <p>We hope you find this useful! As always, if you see any areas for improvement, please <a href="https://github.com/apache/beam/issues/new/choose">open an issue</a> |
| or a <a href="https://github.com/apache/beam/pulls">pull request</a>!</p></description></item><item><title>Blog: Improved Annotation Support for the Python SDK</title><link>/blog/python-improved-annotations/</link><pubDate>Fri, 21 Aug 2020 00:00:01 -0800</pubDate><guid>/blog/python-improved-annotations/</guid><description> |
| <!-- |
| Licensed under the Apache License, Version 2.0 (the "License"); |
| you may not use this file except in compliance with the License. |
| You may obtain a copy of the License at |
| http://www.apache.org/licenses/LICENSE-2.0 |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| <p>The importance of static type checking in a dynamically |
| typed language like Python is not up for debate. Type hints |
| allow developers to leverage a strong typing system to:</p> |
| <ul> |
| <li>write better code,</li> |
| <li>self-document ambiguous programming logic, and</li> |
| <li>inform intelligent code completion in IDEs like PyCharm.</li> |
| </ul> |
| <p>This is why we&rsquo;re excited to announce upcoming improvements to |
| the <code>typehints</code> module of Beam&rsquo;s Python SDK, including support |
| for typed PCollections and Python 3 style annotations on PTransforms.</p> |
| <h1 id="improved-annotations">Improved Annotations</h1> |
| <p>Today, you have the option to declare type hints on PTransforms using either |
| class decorators or inline functions.</p> |
| <p>For instance, a PTransform with decorated type hints might look like this:</p> |
| <pre tabindex="0"><code>@beam.typehints.with_input_types(int) |
| @beam.typehints.with_output_types(str) |
| class IntToStr(beam.PTransform): |
| def expand(self, pcoll): |
| return pcoll | beam.Map(lambda num: str(num)) |
| strings = numbers | beam.ParDo(IntToStr()) |
| </code></pre><p>Using inline functions instead, the same transform would look like this:</p> |
| <pre tabindex="0"><code>class IntToStr(beam.PTransform): |
| def expand(self, pcoll): |
| return pcoll | beam.Map(lambda num: str(num)) |
| strings = numbers | beam.ParDo(IntToStr()).with_input_types(int).with_output_types(str) |
| </code></pre><p>Both methods have problems. Class decorators are syntax-heavy, |
| requiring two additional lines of code, whereas inline functions provide type hints |
| that aren&rsquo;t reusable across other instances of the same transform. Additionally, both |
| methods are incompatible with static type checkers like MyPy.</p> |
| <p>With Python 3 annotations however, we can subvert these problems to provide a |
| clean and reusable type hint experience. Our previous transform now looks like this:</p> |
| <pre tabindex="0"><code>class IntToStr(beam.PTransform): |
| def expand(self, pcoll: PCollection[int]) -&gt; PCollection[str]: |
| return pcoll | beam.Map(lambda num: str(num)) |
| strings = numbers | beam.ParDo(IntToStr()) |
| </code></pre><p>These type hints will actively hook into the internal Beam typing system to |
| play a role in pipeline type checking, and runtime type checking.</p> |
| <p>So how does this work?</p> |
| <h2 id="typed-pcollections">Typed PCollections</h2> |
| <p>You guessed it! The PCollection class inherits from <code>typing.Generic</code>, allowing it to be |
| parameterized with either zero types (denoted <code>PCollection</code>) or one type (denoted <code>PCollection[T]</code>).</p> |
| <ul> |
| <li>A PCollection with zero types is implicitly converted to <code>PCollection[Any]</code>.</li> |
| <li>A PCollection with one type can have any nested type (e.g. <code>Union[int, str]</code>).</li> |
| </ul> |
| <p>Internally, Beam&rsquo;s typing system makes these annotations compatible with other |
| type hints by removing the outer PCollection container.</p> |
| <h2 id="pbegin-pdone-none">PBegin, PDone, None</h2> |
| <p>Finally, besides PCollection, a valid annotation on the <code>expand(...)</code> method of a PTransform is |
| <code>PBegin</code> or <code>None</code>. These are generally used for PTransforms that begin or end with an I/O operation.</p> |
| <p>For instance, when saving data, your transform&rsquo;s output type should be <code>None</code>.</p> |
| <pre tabindex="0"><code>class SaveResults(beam.PTransform): |
| def expand(self, pcoll: PCollection[str]) -&gt; None: |
| return pcoll | beam.io.WriteToBigQuery(...) |
| </code></pre><h1 id="next-steps">Next Steps</h1> |
| <p>What are you waiting for.. start using annotations on your transforms!</p> |
| <p>For more background on type hints in Python, see: |
| <a href="/documentation/sdks/python-type-safety/">Ensuring Python Type Safety</a>.</p> |
| <p>Finally, please |
| <a href="/community/contact-us/">let us know</a> |
| if you encounter any issues.</p></description></item><item><title>Blog: Performance-Driven Runtime Type Checking for the Python SDK</title><link>/blog/python-performance-runtime-type-checking/</link><pubDate>Fri, 21 Aug 2020 00:00:01 -0800</pubDate><guid>/blog/python-performance-runtime-type-checking/</guid><description> |
| <!-- |
| Licensed under the Apache License, Version 2.0 (the "License"); |
| you may not use this file except in compliance with the License. |
| You may obtain a copy of the License at |
| http://www.apache.org/licenses/LICENSE-2.0 |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| <p>In this blog post, we&rsquo;re announcing the upcoming release of a new, opt-in |
| runtime type checking system for Beam&rsquo;s Python SDK that&rsquo;s optimized for performance |
| in both development and production environments.</p> |
| <p>But let&rsquo;s take a step back - why do we even care about runtime type checking |
| in the first place? Let&rsquo;s look at an example.</p> |
| <pre tabindex="0"><code>class MultiplyNumberByTwo(beam.DoFn): |
| def process(self, element: int): |
| return element * 2 |
| p = Pipeline() |
| p | beam.Create([&#39;1&#39;, &#39;2&#39;] | beam.ParDo(MultiplyNumberByTwo()) |
| </code></pre><p>In this code, we passed a list of strings to a DoFn that&rsquo;s clearly intended for use with |
| integers. Luckily, this code will throw an error during pipeline construction because |
| the inferred output type of <code>beam.Create(['1', '2'])</code> is <code>str</code> which is incompatible with |
| the declared input type of <code>MultiplyNumberByTwo.process</code> which is <code>int</code>.</p> |
| <p>However, what if we turned pipeline type checking off using the <code>no_pipeline_type_check</code> |
| flag? Or more realistically, what if the input PCollection to <code>MultiplyNumberByTwo</code> arrived |
| from a database, meaning that the output data type can only be known at runtime?</p> |
| <p>In either case, no error would be thrown during pipeline construction. |
| And even at runtime, this code works. Each string would be multiplied by 2, |
| yielding a result of <code>['11', '22']</code>, but that&rsquo;s certainly not the outcome we want.</p> |
| <p>So how do you debug this breed of &ldquo;hidden&rdquo; errors? More broadly speaking, how do you debug |
| any typing or serialization error in Beam?</p> |
| <p>The answer is to use runtime type checking.</p> |
| <h1 id="runtime-type-checking-rtc">Runtime Type Checking (RTC)</h1> |
| <p>This feature works by checking that actual input and output values satisfy the declared |
| type constraints during pipeline execution. If you ran the code from before with |
| <code>runtime_type_check</code> on, you would receive the following error message:</p> |
| <pre tabindex="0"><code>Type hint violation for &#39;ParDo(MultiplyByTwo)&#39;: requires &lt;class &#39;int&#39;&gt; but got &lt;class &#39;str&#39;&gt; for element |
| </code></pre><p>This is an actionable error message - it tells you that either your code has a bug |
| or that your declared type hints are incorrect. Sounds simple enough, so what&rsquo;s the catch?</p> |
| <p><em>It is soooo slowwwwww.</em> See for yourself.</p> |
| <table> |
| <thead> |
| <tr> |
| <th>Element Size</th> |
| <th>Normal Pipeline</th> |
| <th>Runtime Type Checking Pipeline</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td>1</td> |
| <td>5.3 sec</td> |
| <td>5.6 sec</td> |
| </tr> |
| <tr> |
| <td>2,001</td> |
| <td>9.4 sec</td> |
| <td>57.2 sec</td> |
| </tr> |
| <tr> |
| <td>10,001</td> |
| <td>24.5 sec</td> |
| <td>259.8 sec</td> |
| </tr> |
| <tr> |
| <td>18,001</td> |
| <td>38.7 sec</td> |
| <td>450.5 sec</td> |
| </tr> |
| </tbody> |
| </table> |
| <p>In this micro-benchmark, the pipeline with runtime type checking was over 10x slower, |
| with the gap only increasing as our input PCollection increased in size.</p> |
| <p>So, is there any production-friendly alternative?</p> |
| <h1 id="performance-runtime-type-check">Performance Runtime Type Check</h1> |
| <p>There is! We developed a new flag called <code>performance_runtime_type_check</code> that |
| minimizes its footprint on the pipeline&rsquo;s time complexity using a combination of</p> |
| <ul> |
| <li>efficient Cython code,</li> |
| <li>smart sampling techniques, and</li> |
| <li>optimized mega type-hints.</li> |
| </ul> |
| <p>So what do the new numbers look like?</p> |
| <table> |
| <thead> |
| <tr> |
| <th>Element Size</th> |
| <th>Normal</th> |
| <th>RTC</th> |
| <th>Performance RTC</th> |
| </tr> |
| </thead> |
| <tbody> |
| <tr> |
| <td>1</td> |
| <td>5.3 sec</td> |
| <td>5.6 sec</td> |
| <td>5.4 sec</td> |
| </tr> |
| <tr> |
| <td>2,001</td> |
| <td>9.4 sec</td> |
| <td>57.2 sec</td> |
| <td>11.2 sec</td> |
| </tr> |
| <tr> |
| <td>10,001</td> |
| <td>24.5 sec</td> |
| <td>259.8 sec</td> |
| <td>25.5 sec</td> |
| </tr> |
| <tr> |
| <td>18,001</td> |
| <td>38.7 sec</td> |
| <td>450.5 sec</td> |
| <td>39.4 sec</td> |
| </tr> |
| </tbody> |
| </table> |
| <p>On average, the new Performance RTC is 4.4% slower than a normal pipeline whereas the old RTC |
| is over 900% slower! Additionally, as the size of the input PCollection increases, the fixed cost |
| of setting up the Performance RTC system is spread across each element, decreasing the relative |
| impact on the overall pipeline. With 18,001 elements, the difference is less than 1 second.</p> |
| <h2 id="how-does-it-work">How does it work?</h2> |
| <p>There are three key factors responsible for this upgrade in performance.</p> |
| <ol> |
| <li> |
| <p>Instead of type checking all values, we only type check a subset of values, known as |
| a sample in statistics. Initially, we sample a substantial number of elements, but as our |
| confidence that the element type won&rsquo;t change over time increases, we reduce our |
| sampling rate (up to a fixed minimum).</p> |
| </li> |
| <li> |
| <p>Whereas the old RTC system used heavy wrappers to perform the type check, the new RTC system |
| moves the type check to a Cython-optimized, non-decorated portion of the codebase. For reference, |
| Cython is a programming language that gives C-like performance to Python code.</p> |
| </li> |
| <li> |
| <p>Finally, we use a single mega type hint to type-check only the output values of transforms |
| instead of type-checking both the input and output values separately. This mega typehint is composed of |
| the original transform&rsquo;s output type constraints along with all consumer transforms&rsquo; input type |
| constraints. Using this mega type hint allows us to reduce overhead while simultaneously allowing |
| us to throw <em>more actionable errors</em>. For instance, consider the following error (which was |
| generated from the old RTC system):</p> |
| </li> |
| </ol> |
| <pre tabindex="0"><code>Runtime type violation detected within ParDo(DownstreamDoFn): Type-hint for argument: &#39;element&#39; violated. Expected an instance of &lt;class ‘str’&gt;, instead found 9, an instance of &lt;class ‘int’&gt;. |
| </code></pre><p>This error tells us that the <code>DownstreamDoFn</code> received an <code>int</code> when it was expecting a <code>str</code>, but doesn&rsquo;t tell us |
| who created that <code>int</code> in the first place. Who is the offending upstream transform that&rsquo;s responsible for |
| this <code>int</code>? Presumably, <em>that</em> transform&rsquo;s output type hints were too expansive (e.g. <code>Any</code>) or otherwise non-existent because |
| no error was thrown during the runtime type check of its output.</p> |
| <p>The problem here boils down to a lack of context. If we knew who our consumers were when type |
| checking our output, we could simultaneously type check our output value against our output type |
| constraints and every consumers&rsquo; input type constraints to know whether there is <em>any</em> possibility |
| for a mismatch. This is exactly what the mega type hint does, and it allows us to throw errors |
| at the point of declaration rather than the point of exception, saving you valuable time |
| while providing higher quality error messages.</p> |
| <p>So what would the same error look like using Performance RTC? It&rsquo;s the exact same string but with one additional line:</p> |
| <pre tabindex="0"><code>[while running &#39;ParDo(UpstreamDoFn)&#39;] |
| </code></pre><p>And that&rsquo;s much more actionable for an investigation :)</p> |
| <h1 id="next-steps">Next Steps</h1> |
| <p>Go play with the new <code>performance_runtime_type_check</code> feature!</p> |
| <p>It&rsquo;s in an experimental state so please |
| <a href="/community/contact-us/">let us know</a> |
| if you encounter any issues.</p></description></item><item><title>Blog: Python SDK Typing Changes</title><link>/blog/python-typing/</link><pubDate>Thu, 28 May 2020 00:00:01 -0800</pubDate><guid>/blog/python-typing/</guid><description> |
| <!-- |
| Licensed under the Apache License, Version 2.0 (the "License"); |
| you may not use this file except in compliance with the License. |
| You may obtain a copy of the License at |
| http://www.apache.org/licenses/LICENSE-2.0 |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| <p>Beam Python has recently increased its support and integration of Python 3 type |
| annotations for improved code clarity and type correctness checks. |
| Read on to find out what&rsquo;s new.</p> |
| <p>Python supports type annotations on functions (PEP 484). Static type checkers, |
| such as mypy, are used to verify adherence to these types. |
| For example:</p> |
| <pre tabindex="0"><code>def f(v: int) -&gt; int: |
| return v[0] |
| </code></pre><p>Running mypy on the above code will give the error: |
| <code>Value of type &quot;int&quot; is not indexable</code>.</p> |
| <p>We&rsquo;ve recently made changes to Beam in 2 areas:</p> |
| <p>Adding type annotations throughout Beam. Type annotations make a large and |
| sophisticated codebase like Beam easier to comprehend and navigate in your |
| favorite IDE.</p> |
| <p>Second, we&rsquo;ve added support for Python 3 type annotations. This allows SDK |
| users to specify a DoFn&rsquo;s type hints in one place. |
| We&rsquo;ve also expanded Beam&rsquo;s support of <code>typing</code> module types.</p> |
| <p>For more background see: |
| <a href="/documentation/sdks/python-type-safety/">Ensuring Python Type Safety</a>.</p> |
| <h1 id="beam-is-typed">Beam Is Typed</h1> |
| <p>In tandem with the new type annotation support within DoFns, we&rsquo;ve invested a |
| great deal of time adding type annotations to the Beam python code itself. |
| With this in place, we have begun using mypy, a static type |
| checker, as part of Beam&rsquo;s code review process, which ensures higher quality |
| contributions and fewer bugs. |
| The added context and insight that type annotations add throughout Beam is |
| useful for all Beam developers, contributors and end users alike, but |
| it is especially beneficial for developers who are new to the project. |
| If you use an IDE that understands type annotations, it will provide richer |
| type completions and warnings than before. |
| You&rsquo;ll also be able to use your IDE to inspect the types of Beam functions and |
| transforms to better understand how they work, which will ease your own |
| development. |
| Finally, once Beam is fully annotated, end users will be able to benefit from |
| the use of static type analysis on their own pipelines and custom transforms.</p> |
| <h1 id="new-ways-to-annotate">New Ways to Annotate</h1> |
| <h2 id="python-3-syntax-annotations">Python 3 Syntax Annotations</h2> |
| <p>Coming in Beam 2.21 (BEAM-8280), you will be able to use Python annotation |
| syntax to specify input and output types.</p> |
| <p>For example, this new form:</p> |
| <pre tabindex="0"><code>class MyDoFn(beam.DoFn): |
| def process(self, element: int) -&gt; typing.Text: |
| yield str(element) |
| </code></pre><p>is equivalent to this:</p> |
| <pre tabindex="0"><code>@apache_beam.typehints.with_input_types(int) |
| @apache_beam.typehints.with_output_types(typing.Text) |
| class MyDoFn(beam.DoFn): |
| def process(self, element): |
| yield str(element) |
| </code></pre><p>One of the advantages of the new form is that you may already be using it |
| in tandem with a static type checker such as mypy, thus getting additional |
| runtime type checking for free.</p> |
| <p>This feature will be enabled by default, and there will be 2 mechanisms in |
| place to disable it:</p> |
| <ol> |
| <li>Calling <code>apache_beam.typehints.disable_type_annotations()</code> before pipeline |
| construction will disable the new feature completely.</li> |
| <li>Decorating a function with <code>@apache_beam.typehints.no_annotations</code> will |
| tell Beam to ignore annotations for it.</li> |
| </ol> |
| <p>Uses of Beam&rsquo;s <code>with_input_type</code>, <code>with_output_type</code> methods and decorators will |
| still work and take precedence over annotations.</p> |
| <h3 id="sidebar">Sidebar</h3> |
| <p>You might ask: couldn&rsquo;t we use mypy to type check Beam pipelines? |
| There are several reasons why this is not the case.</p> |
| <ul> |
| <li>Pipelines are constructed at runtime and may depend on information that is |
| only known at that time, such as a config file or database table schema.</li> |
| <li>PCollections don&rsquo;t have the necessary type information, so mypy sees them as |
| effectively containing any element type. |
| This may change in the future.</li> |
| <li>Transforms using lambdas (ex: <code>beam.Map(lambda x: (1, x)</code>) cannot be |
| annotated properly using PEP 484. |
| However, Beam does a best-effort attempt to analyze the output type |
| from the bytecode.</li> |
| </ul> |
| <h2 id="typing-module-support">Typing Module Support</h2> |
| <p>Python&rsquo;s <a href="https://docs.python.org/3/library/typing.html">typing</a> module defines |
| types used in type annotations. This is what we call &ldquo;native&rdquo; types. |
| While Beam has its own typing types, it also supports native types. |
| While both Beam and native types are supported, for new code we encourage using |
| native typing types. Native types have as these are supported by additional tools.</p> |
| <p>While working on Python 3 annotations syntax support, we&rsquo;ve also discovered and |
| fixed issues with native type support. There may still be bugs and unsupported |
| native types. Please |
| <a href="/community/contact-us/">let us know</a> if you encounter |
| issues.</p></description></item><item><title>Blog: Dataflow Python SDK is now public!</title><link>/blog/python-sdk-now-public/</link><pubDate>Thu, 25 Feb 2016 13:00:00 -0800</pubDate><guid>/blog/python-sdk-now-public/</guid><description> |
| <!-- |
| Licensed under the Apache License, Version 2.0 (the "License"); |
| you may not use this file except in compliance with the License. |
| You may obtain a copy of the License at |
| http://www.apache.org/licenses/LICENSE-2.0 |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| <p>When the Apache Beam project proposed entry into the <a href="https://wiki.apache.org/incubator/BeamProposal">Apache Incubator</a> the proposal |
| included the <a href="https://github.com/GoogleCloudPlatform/DataflowJavaSDK">Dataflow Java SDK</a>. In the long term, however, Apache Beam aims to support SDKs implemented in multiple languages, such as Python.</p> |
| <p>Today, Google submitted the <a href="https://github.com/GoogleCloudPlatform/DataflowPythonSDK">Dataflow Python (2.x) SDK</a> on GitHub. Google is committed to including the in progress python SDK in Apache Beam and, in that spirit, we&rsquo;ve moved development of the Python SDK to a public repository. While this SDK will not be included with the initial (incubating) releases of Apache Beam, our we plan on incorporating the Python SDK into beam during incubation. We want to take the time to implement changes from the <a href="https://goo.gl/nk5OM0">technical vision</a> into the Java SDK before we introduce a Python SDK for Apache Beam. We believe this will allow us to work on the model and SDKs in an ordered fashion.</p> |
| <p>You can look for the Apache Beam Python SDK in the coming months once we finish forking and refactoring the Java SDK.</p> |
| <p>Best,</p> |
| <p>Apache Beam Team</p></description></item></channel></rss> |
