diff --git a/docs/config.toml b/docs/config.toml
index a7fd9b56a6..24246c0d50 100644
--- a/docs/config.toml
+++ b/docs/config.toml
@@ -81,3 +81,8 @@ posts = "/:year/:month/:day/:title/"
languageName = '中文版'
contentDir = 'content.zh'
weight = 2
+
+[languages.tr]
+ languageName = 'Türkçe'
+ contentDir = 'content.tr'
+ weight = 2
\ No newline at end of file
diff --git a/docs/content.tr/_index.md b/docs/content.tr/_index.md
new file mode 100644
index 0000000000..d7bbf51de6
--- /dev/null
+++ b/docs/content.tr/_index.md
@@ -0,0 +1,25 @@
+---
+title: Apache Flink® — Veri Akışları Üzerinde Durumlu Hesaplamalar
+type: docs
+home: true
+---
+
+
+{{< recent_posts >}}
diff --git a/docs/content.tr/documentation/_index.md b/docs/content.tr/documentation/_index.md
new file mode 100644
index 0000000000..7fd951daa8
--- /dev/null
+++ b/docs/content.tr/documentation/_index.md
@@ -0,0 +1,26 @@
+---
+title: Dokümantasyon
+bookCollapseSection: true
+weight: 15
+menu_weight: 1
+---
+
+
+# Dokümantasyon
diff --git a/docs/content.tr/documentation/flink-cdc-master.md b/docs/content.tr/documentation/flink-cdc-master.md
new file mode 100644
index 0000000000..97f6fcdc07
--- /dev/null
+++ b/docs/content.tr/documentation/flink-cdc-master.md
@@ -0,0 +1,27 @@
+---
+weight: 7
+title: CDC Master (snapshot)
+bookHref: "https://nightlies.apache.org/flink/flink-cdc-docs-master"
+---
+
+
+# Flink CDC documentation (latest snapshot)
+
+{{< external_link name="You can find the Flink CDC documentation for the latest snapshot here.">}}
\ No newline at end of file
diff --git a/docs/content.tr/documentation/flink-cdc-stable.md b/docs/content.tr/documentation/flink-cdc-stable.md
new file mode 100644
index 0000000000..027231337a
--- /dev/null
+++ b/docs/content.tr/documentation/flink-cdc-stable.md
@@ -0,0 +1,27 @@
+---
+weight: 6
+title: CDC $FlinkCDCStableShortVersion (stable)
+bookHref: "https://nightlies.apache.org/flink/flink-cdc-docs-stable"
+---
+
+
+# Flink CDC documentation (latest stable release)
+
+{{< external_link name="You can find the Flink CDC documentation for the latest stable release here.">}}
\ No newline at end of file
diff --git a/docs/content.tr/documentation/flink-kubernetes-operator-master.md b/docs/content.tr/documentation/flink-kubernetes-operator-master.md
new file mode 100644
index 0000000000..0ad20a1b70
--- /dev/null
+++ b/docs/content.tr/documentation/flink-kubernetes-operator-master.md
@@ -0,0 +1,27 @@
+---
+weight: 5
+title: Kubernetes Operator Main (snapshot)
+bookHref: "https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-main"
+---
+
+
+# Flink Kubernetes Operator documentation (latest snapshot)
+
+{{< external_link name="You can find the Flink Kubernetes Operator documentation for the latest snapshot here.">}}
\ No newline at end of file
diff --git a/docs/content.tr/documentation/flink-kubernetes-operator-stable.md b/docs/content.tr/documentation/flink-kubernetes-operator-stable.md
new file mode 100644
index 0000000000..02ea0ec743
--- /dev/null
+++ b/docs/content.tr/documentation/flink-kubernetes-operator-stable.md
@@ -0,0 +1,27 @@
+---
+weight: 4
+title: Kubernetes Operator $FlinkKubernetesOperatorStableShortVersion (latest)
+bookHref: "https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-stable/"
+---
+
+
+# Flink Kubernetes Operator documentation (latest stable release)
+
+{{< external_link name="You can find the Flink Kubernetes Operator documentation for the latest stable release here.">}}
\ No newline at end of file
diff --git a/docs/content.tr/documentation/flink-lts.md b/docs/content.tr/documentation/flink-lts.md
new file mode 100644
index 0000000000..a453d652fc
--- /dev/null
+++ b/docs/content.tr/documentation/flink-lts.md
@@ -0,0 +1,27 @@
+---
+weight: 2
+title: Flink $FlinkLTSShortVersion (LTS)
+bookHref: "https://nightlies.apache.org/flink/flink-docs-lts/"
+---
+
+
+# Flink documentation (latest LTS release)
+
+{{< external_link name="You can find the Flink documentation for the latest Long-Term Support(LTS) release here.">}}
\ No newline at end of file
diff --git a/docs/content.tr/documentation/flink-master.md b/docs/content.tr/documentation/flink-master.md
new file mode 100644
index 0000000000..937bc92084
--- /dev/null
+++ b/docs/content.tr/documentation/flink-master.md
@@ -0,0 +1,27 @@
+---
+weight: 3
+title: Flink Master (snapshot)
+bookHref: "https://nightlies.apache.org/flink/flink-docs-master/"
+---
+
+
+# Flink documentation (latest snapshot)
+
+{{< external_link name="You can find the Flink documentation for the latest snapshot here.">}}
\ No newline at end of file
diff --git a/docs/content.tr/documentation/flink-stable.md b/docs/content.tr/documentation/flink-stable.md
new file mode 100644
index 0000000000..ef210c2671
--- /dev/null
+++ b/docs/content.tr/documentation/flink-stable.md
@@ -0,0 +1,27 @@
+---
+weight: 1
+title: Flink $FlinkStableShortVersion (stable)
+bookHref: "https://nightlies.apache.org/flink/flink-docs-stable/"
+---
+
+
+# Flink documentation (latest stable release)
+
+{{< external_link name="You can find the Flink documentation for the latest stable release here.">}}
\ No newline at end of file
diff --git a/docs/content.tr/documentation/flink-stateful-functions-master.md b/docs/content.tr/documentation/flink-stateful-functions-master.md
new file mode 100644
index 0000000000..4f41dae05c
--- /dev/null
+++ b/docs/content.tr/documentation/flink-stateful-functions-master.md
@@ -0,0 +1,27 @@
+---
+weight: 11
+title: Stateful Functions Master (snapshot)
+bookHref: "https://nightlies.apache.org/flink/flink-statefun-docs-master"
+---
+
+
+# Flink Stateful Functions documentation (latest snapshot)
+
+{{< external_link name="You can find the Flink Stateful Functions documentation for the latest snapshot here.">}}
\ No newline at end of file
diff --git a/docs/content.tr/documentation/flink-stateful-functions-stable.md b/docs/content.tr/documentation/flink-stateful-functions-stable.md
new file mode 100644
index 0000000000..69971a9b26
--- /dev/null
+++ b/docs/content.tr/documentation/flink-stateful-functions-stable.md
@@ -0,0 +1,27 @@
+---
+weight: 10
+title: Stateful Functions $StateFunStableShortVersion (stable)
+bookHref: "https://nightlies.apache.org/flink/flink-statefun-docs-stable/"
+---
+
+
+# Flink documentation (latest stable release)
+
+{{< external_link name="You can find the Flink documentation for the latest stable release here.">}}
\ No newline at end of file
diff --git a/docs/content.tr/documentation/flinkml-master.md b/docs/content.tr/documentation/flinkml-master.md
new file mode 100644
index 0000000000..73c4fbc8fb
--- /dev/null
+++ b/docs/content.tr/documentation/flinkml-master.md
@@ -0,0 +1,27 @@
+---
+weight: 9
+title: ML Master (snapshot)
+bookHref: "https://nightlies.apache.org/flink/flink-ml-docs-master"
+---
+
+
+# Flink ML documentation (latest snapshot)
+
+{{< external_link name="You can find the Flink ML documentation for the latest snapshot here.">}}
\ No newline at end of file
diff --git a/docs/content.tr/documentation/flinkml-stable.md b/docs/content.tr/documentation/flinkml-stable.md
new file mode 100644
index 0000000000..225170a0ec
--- /dev/null
+++ b/docs/content.tr/documentation/flinkml-stable.md
@@ -0,0 +1,27 @@
+---
+weight: 8
+title: ML $FlinkMLStableShortVersion (stable)
+bookHref: "https://nightlies.apache.org/flink/flink-ml-docs-stable/"
+---
+
+
+# Flink ML documentation (latest stable release)
+
+{{< external_link name="You can find the Flink ML documentation for the latest stable release here.">}}
\ No newline at end of file
diff --git a/docs/content.tr/downloads.md b/docs/content.tr/downloads.md
new file mode 100644
index 0000000000..89ff79e509
--- /dev/null
+++ b/docs/content.tr/downloads.md
@@ -0,0 +1,172 @@
+---
+title: İndirmeler
+bookCollapseSection: false
+weight: 5
+menu_weight: 2
+---
+
+
+# Apache Flink® İndirmeleri
+
+## Apache Flink
+
+Apache Flink® {{< param FlinkStableVersion >}}, en son kararlı sürümdür.
+
+{{% flink_download "flink" %}}
+
+## Apache Flink konnektörleri
+
+Bunlar, ana Flink sürümlerinden ayrı olarak yayınlanan konnektörlerdir.
+
+{{% flink_download "flink_connectors" %}}
+
+## Apache Flink CDC
+
+Apache Flink® CDC {{< param FlinkCDCStableShortVersion >}}, en son kararlı sürümdür.
+
+{{% flink_download "flink_cdc" %}}
+
+## Apache Flink Stateful Functions
+
+Apache Flink® Stateful Functions {{< param StateFunStableShortVersion >}}, en son kararlı sürümdür.
+
+{{% flink_download "statefun" %}}
+
+## Apache Flink ML
+
+Apache Flink® ML {{< param FlinkMLStableShortVersion >}}, en son kararlı sürümdür.
+
+{{% flink_download "flink_ml" %}}
+
+## Apache Flink Kubernetes Operator
+
+Apache Flink® Kubernetes Operator {{< param FlinkKubernetesOperatorStableShortVersion >}}, en son kararlı sürümdür.
+
+{{% flink_download "flink_kubernetes_operator" %}}
+
+## Ek Bileşenler
+
+Bunlar, Flink projesinin geliştirdiği ve ana Flink sürümünün bir parçası olmayan bileşenlerdir:
+
+{{% flink_download "additional_components" %}}
+
+## Hash'leri ve İmzaları Doğrulama
+
+Sürümlerimizle birlikte, `*.sha512` dosyalarında sha512 hash'leri ve `*.asc` dosyalarında kriptografik imzalar da sağlıyoruz. Apache Software Foundation, herhangi bir sürüm imzalama [KEYS](https://downloads.apache.org/flink/KEYS) dosyasını kullanarak takip edebileceğiniz kapsamlı bir [hash ve imza doğrulama eğitimi](http://www.apache.org/info/verification.html) sunmaktadır.
+
+## Maven Bağımlılıkları
+
+### Apache Flink
+
+Projenize Apache Flink'i dahil etmek için `pom.xml` dosyanıza aşağıdaki bağımlılıkları ekleyebilirsiniz. Bu bağımlılıklar yerel bir yürütme ortamı içerir ve böylece yerel testleri destekler.
+
+- **Scala API**: Scala API'sini kullanmak için, `flink-java` artifact id'sini `flink-scala_2.12` ile ve `flink-streaming-java`'yı `flink-streaming-scala_2.12` ile değiştirin.
+
+```xml
+
+ org.apache.flink
+ flink-java
+ {{< param FlinkStableVersion >}}
+
+
+ org.apache.flink
+ flink-streaming-java
+ {{< param FlinkStableVersion >}}
+
+
+ org.apache.flink
+ flink-clients
+ {{< param FlinkStableVersion >}}
+
+```
+
+### Apache Flink Stateful Functions
+
+Projenize Apache Flink Stateful Functions'ı dahil etmek için `pom.xml` dosyanıza aşağıdaki bağımlılıkları ekleyebilirsiniz.
+
+```xml
+
+ org.apache.flink
+ statefun-sdk
+ {{< param StateFunStableVersion >}}
+
+
+ org.apache.flink
+ statefun-flink-harness
+ {{< param StateFunStableVersion >}}
+
+```
+
+`statefun-sdk` bağımlılığı, uygulamalar geliştirmeye başlamak için ihtiyacınız olan tek bağımlılıktır.
+`statefun-flink-harness` bağımlılığı, uygulamanızı bir IDE'de yerel olarak test etmenizi sağlayan yerel bir yürütme ortamı içerir.
+
+### Apache Flink ML
+
+Projenize Apache Flink ML'yi dahil etmek için `pom.xml` dosyanıza aşağıdaki bağımlılıkları ekleyebilirsiniz.
+
+```xml
+
+ org.apache.flink
+ flink-ml-core
+ {{< param FlinkMLStableVersion >}}
+
+
+ org.apache.flink
+ flink-ml-iteration
+ {{< param FlinkMLStableVersion >}}
+
+
+ org.apache.flink
+ flink-ml-lib
+ {{< param FlinkMLStableVersion >}}
+
+```
+
+İleri düzey kullanıcılar, hedef kullanım senaryoları için yalnızca minimum Flink ML bağımlılık setini içe aktarabilirler:
+
+- Özel ML algoritmaları geliştirmek için `flink-ml-core` artifact'ini kullanın.
+- İterasyon gerektiren özel ML algoritmaları geliştirmek için `flink-ml-core` ve `flink-ml-iteration` artifact'lerini kullanın.
+- Flink ML'den hazır ML algoritmalarını kullanmak için `flink-ml-lib` artifact'ini kullanın.
+
+### Apache Flink Kubernetes Operator
+
+Projenize Apache Flink Kubernetes Operator'ı dahil etmek için `pom.xml` dosyanıza aşağıdaki bağımlılıkları ekleyebilirsiniz.
+
+```xml
+
+ org.apache.flink
+ flink-kubernetes-operator
+ {{< param FlinkKubernetesOperatorStableVersion >}}
+
+```
+
+## Eski sürümler için Güncelleme Politikası
+
+Mart 2017 itibariyle, Flink topluluğu mevcut ve önceki küçük sürümü hata düzeltmeleri ile destekleme [kararı aldı](https://lists.apache.org/thread/qf4hot3gb1dgvh4csxv2317263b6omm4). Eğer 1.2.x mevcut sürüm ise, 1.1.y desteklenen önceki küçük sürümdür. Her iki sürüm de kritik sorunlar için hata düzeltmeleri alacaktır.
+
+Mart 2023 itibariyle, Flink topluluğu yeni bir Flink küçük sürümünün yayınlanmasıyla birlikte, desteğini kaybeden Flink küçük sürümündeki çözülmüş kritik/engelleyici sorunlar için son bir hata düzeltme sürümü yapma [kararı aldı](https://lists.apache.org/thread/9w99mgx3nw5tc0v26wcvlyqxrcrkpzdz). Eğer 1.16.1 mevcut sürüm ve 1.15.4 en son önceki yama sürümü ise, 1.17.0 yayınlandığında çözülmüş kritik/engelleyici sorunları temizlemek için bir 1.15.5 oluşturacağız.
+
+Topluluğun her zaman daha eski sürümler için hata düzeltme sürümlerini tartışmaya açık olduğunu unutmayın. Bunun için lütfen geliştiricilerle dev@flink.apache.org e-posta listesinden iletişime geçin.
+
+## Tüm kararlı sürümler
+
+Tüm Flink sürümleri, sağlama toplamları ve kriptografik imzalar dahil olmak üzere [https://archive.apache.org/dist/flink/](https://archive.apache.org/dist/flink/) üzerinden erişilebilir. Yazı yazıldığı sırada, bu aşağıdaki sürümleri içermektedir:
+
+{{% flink_archive "release_archive" %}}
\ No newline at end of file
diff --git a/docs/content.tr/flink-packages.md b/docs/content.tr/flink-packages.md
new file mode 100644
index 0000000000..a0de5c5d24
--- /dev/null
+++ b/docs/content.tr/flink-packages.md
@@ -0,0 +1,27 @@
+---
+title: flink-packages.org
+bookCollapseSection: false
+bookHref: "https://flink-packages.org/"
+---
+
+
+# What is the Flink Kubernetes Operator?
+
+All information on the flink-packages can be found on the [flink-packages website.](https://flink-packages.org)
\ No newline at end of file
diff --git a/docs/content.tr/getting-started/_index.md b/docs/content.tr/getting-started/_index.md
new file mode 100644
index 0000000000..f2b86d35b6
--- /dev/null
+++ b/docs/content.tr/getting-started/_index.md
@@ -0,0 +1,26 @@
+---
+title: Başlarken
+bookCollapseSection: true
+weight: 10
+menu_weight: 1
+---
+
+
+# Documentation
diff --git a/docs/content.tr/getting-started/training-course.md b/docs/content.tr/getting-started/training-course.md
new file mode 100644
index 0000000000..77922d50e4
--- /dev/null
+++ b/docs/content.tr/getting-started/training-course.md
@@ -0,0 +1,27 @@
+---
+weight: 6
+title: Eğitim Kursu
+bookHref: "https://nightlies.apache.org/flink/flink-docs-stable/docs/learn-flink/overview/"
+---
+
+
+# Eğitim Kursu
+
+{{< external_link name="Flink Eğitim Kursu hakkında tüm bilgileri buradan okuyabilirsiniz.">}}
\ No newline at end of file
diff --git a/docs/content.tr/getting-started/with-flink-cdc.md b/docs/content.tr/getting-started/with-flink-cdc.md
new file mode 100644
index 0000000000..ede0be3a15
--- /dev/null
+++ b/docs/content.tr/getting-started/with-flink-cdc.md
@@ -0,0 +1,27 @@
+---
+weight: 3
+title: Flink CDC
+bookHref: "https://nightlies.apache.org/flink/flink-cdc-docs-stable/docs/get-started/introduction/"
+---
+
+
+# Getting Started with Flink CDC
+
+{{< external_link name="Read how you can get started with Flink CDC here.">}}
diff --git a/docs/content.tr/getting-started/with-flink-kubernetes-operator.md b/docs/content.tr/getting-started/with-flink-kubernetes-operator.md
new file mode 100644
index 0000000000..da8149151a
--- /dev/null
+++ b/docs/content.tr/getting-started/with-flink-kubernetes-operator.md
@@ -0,0 +1,27 @@
+---
+weight: 2
+title: Flink Kubernetes Operator
+bookHref: "https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-stable/docs/try-flink-kubernetes-operator/quick-start/"
+---
+
+
+# Getting Started with Flink Kubernetes Operator
+
+{{< external_link name="Read how you can get started with Flink Kubernetes Operator here.">}}
\ No newline at end of file
diff --git a/docs/content.tr/getting-started/with-flink-ml.md b/docs/content.tr/getting-started/with-flink-ml.md
new file mode 100644
index 0000000000..9c83a2bf33
--- /dev/null
+++ b/docs/content.tr/getting-started/with-flink-ml.md
@@ -0,0 +1,27 @@
+---
+weight: 4
+title: Flink ML
+bookHref: "https://nightlies.apache.org/flink/flink-ml-docs-stable/docs/try-flink-ml/quick-start/"
+---
+
+
+# Getting Started with Flink ML
+
+{{< external_link name="Read how you can get started with Flink ML here.">}}
\ No newline at end of file
diff --git a/docs/content.tr/getting-started/with-flink-stateful-functions.md b/docs/content.tr/getting-started/with-flink-stateful-functions.md
new file mode 100644
index 0000000000..e7400613b0
--- /dev/null
+++ b/docs/content.tr/getting-started/with-flink-stateful-functions.md
@@ -0,0 +1,27 @@
+---
+weight: 5
+title: Flink Stateful Functions
+bookHref: "https://nightlies.apache.org/flink/flink-statefun-docs-stable/getting-started/project-setup.html"
+---
+
+
+# Getting Started with Flink Stateful Functions
+
+{{< external_link name="Read how you can get started with Flink Stateful Functions here.">}}
\ No newline at end of file
diff --git a/docs/content.tr/getting-started/with-flink.md b/docs/content.tr/getting-started/with-flink.md
new file mode 100644
index 0000000000..4e78c8ea20
--- /dev/null
+++ b/docs/content.tr/getting-started/with-flink.md
@@ -0,0 +1,27 @@
+---
+weight: 1
+title: Flink
+bookHref: "https://nightlies.apache.org/flink/flink-docs-stable/docs/try-flink/local_installation/"
+---
+
+
+# Getting Started with Flink
+
+{{< external_link name="Read how you can get started with Flink here.">}}
\ No newline at end of file
diff --git a/docs/content.tr/how-to-contribute/_index.md b/docs/content.tr/how-to-contribute/_index.md
new file mode 100644
index 0000000000..87fcdfce75
--- /dev/null
+++ b/docs/content.tr/how-to-contribute/_index.md
@@ -0,0 +1,26 @@
+---
+title: Nasıl Katkıda Bulunulur
+bookCollapseSection: true
+weight: 20
+menu_weight: 1
+---
+
+
+# Nasıl katkıda bulunulur
\ No newline at end of file
diff --git a/docs/content.tr/how-to-contribute/code-style-and-quality-common.md b/docs/content.tr/how-to-contribute/code-style-and-quality-common.md
new file mode 100644
index 0000000000..e8dc67bf67
--- /dev/null
+++ b/docs/content.tr/how-to-contribute/code-style-and-quality-common.md
@@ -0,0 +1,363 @@
+---
+title: Kod Stili ve Kalite Kılavuzu — Genel Kurallar
+bookCollapseSection: false
+bookHidden: true
+---
+
+# Kod Stili ve Kalite Kılavuzu — Genel Kurallar
+
+#### [Önsöz]({{< relref "how-to-contribute/code-style-and-quality-preamble" >}})
+#### [Pull Request'ler ve Değişiklikler]({{< relref "how-to-contribute/code-style-and-quality-pull-requests" >}})
+#### [Genel Kodlama Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-common" >}})
+#### [Java Dili Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-java" >}})
+#### [Scala Dili Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-scala" >}})
+#### [Bileşenler Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-components" >}})
+#### [Biçimlendirme Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-formatting" >}})
+
+
+
+## 1. Telif Hakkı
+
+Her dosya, başlık olarak Apache lisans bilgisini içermelidir.
+
+```
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you 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.
+ */
+```
+
+## 2. Araçlar
+
+IDE araçlarını yapılandırmak için {{< docs_link file="flink-docs-stable/docs/flinkdev/ide_setup/" name="IDE Kurulum Kılavuzu">}}'nu takip etmenizi öneririz.
+
+
+
+
+### Uyarılar
+
+* Sıfır uyarıya ulaşmaya çalışırız
+* Mevcut kodda birçok uyarı olsa da, yeni değişiklikler ek derleyici uyarıları eklememeli
+* Uyarıyı sağlıklı bir şekilde ele almak mümkün değilse (jeneriklerle çalışırken bazı durumlarda), uyarıyı bastırmak için bir ek açıklama ekleyin
+* Yöntemleri kullanımdan kaldırırken, bunun ek uyarılar getirmediğinden emin olun
+
+
+
+## 3. Yorumlar ve Kod Okunabilirliği
+
+
+### Yorumlar
+
+**Altın kural: Kodun anlaşılmasını desteklemek için gerektiği kadar yorum ekleyin, ancak gereksiz bilgi eklemeyin.**
+
+Şunları düşünün:
+
+* Kod ne yapıyor?
+* Kod bunu nasıl yapıyor?
+* Kod neden böyle?
+
+Kodun kendisi, mümkün olduğunca "ne " ve "nasıl " sorularını açıklamalıdır.
+
+* Sınıfların rollerini ve yöntemlerin sözleşmelerini, yöntem adından açıkça anlaşılamadığı durumlarda tanımlamak için JavaDoc'ları kullanın ("ne" sorusu).
+* Kodun akışı, "nasıl" sorusuna iyi bir açıklama sağlamalıdır.
+ Değişken ve yöntem adlarını, kodun kendini belgelendirmesinin bir parçası olarak düşünün.
+* Bir birim oluşturan daha büyük blokları, o bloğun ne yaptığını tanımlayan açıklayıcı bir isimle özel bir yönteme taşımak, kodun okunmasını genellikle kolaylaştırır.
+
+Kod içi yorumlar, "neden" sorusunu açıklamaya yardımcı olur.
+
+* Örneğin `// bu belirli kod düzeni JIT'in şunu veya bunu daha iyi yapmasına yardımcı olur`
+* Veya `// bu alanı burada null yapmak, gelecekteki yazma girişimlerinin daha hızlı başarısız olması anlamına gelir`
+* Veya `// bu yöntemin gerçekte çağrıldığı argümanlarla, görünüşte naif olan bu yaklaşım aslında optimize edilmiş/akıllı sürümlerden daha iyi çalışır`
+
+Kod içi yorumlar, kodun kendisinde zaten açık olan "ne" ve "nasıl" hakkında gereksiz bilgiler belirtmemelidir.
+
+JavaDoc'lar anlamsız bilgiler belirtmemelidir (sadece Checkstyle denetleyicisini memnun etmek için).
+
+__Yapmayın:__
+
+```
+/**
+ * The symbol expression.
+ */
+public class CommonSymbolExpression {}
+```
+__Yapın:__
+
+```
+/**
+ * An expression that wraps a single specific symbol.
+ * A symbol could be a unit, an alias, a variable, etc.
+ */
+public class CommonSymbolExpression {}
+```
+
+
+### Dallar ve İç İçe Geçme
+
+If koşulunu çevirerek ve erken çıkarak, kapsamların derin iç içe geçmesinden kaçının.
+
+__Yapmayın:__
+
+```
+if (a) {
+ if (b) {
+ if (c) {
+ the main path
+ }
+ }
+}
+```
+
+__Yapın:__
+
+```
+if (!a) {
+ return ..
+}
+
+if (!b) {
+ return ...
+}
+
+if (!c) {
+ return ...
+}
+
+the main path
+```
+
+
+## 4. Tasarım ve Yapı
+
+Bunun ne olduğunu tam olarak belirtmek zor olduğu gibi, iyi tasarım için bazı özellikler vardır. Bu özellikler varsa, iyi bir yönde olduğu ihtimali yüksektir. Bu özellikler elde edilemiyorsa, tasarımın hatalı olduğu ihtimali yüksektir.
+
+
+### Immutability ve Eager Initialization
+
+1. Mümkün olduğunca immutable türler kullanmayı deneyin, özellikle API'ler, mesajlar, tanımlayıcılar, özellikler, yapılandırma, vb.
+2. İyi bir genel yaklaşım, bir sınıfın mümkün olduğunca çok alanını `final` yapmayı denemektir.
+3. Haritaların anahtarları olarak kullanılan sınıfların tamamen sabit ve sadece `final` alanları olmalıdır (muhtemelen yardımcı alanlar hariç, örneğin ilk önce yüklenen hash kodları).
+4. Sınıfları ilk önce tamamlanana kadar kullanılabilir hale getirin. Kurucu tamamlanana kadar nesne kullanılamaz.
+
+
+### Değiştirilebilir Alanların Null Olabilirliği
+
+Nullability için Flink kod tabanı, aşağıdaki konvansiyonları takip etmeyi hedefler:
+
+* Alanlar, parametreler ve dönüş türleri her zaman null olmayan, eğer bunun aksi belirtilmediği sürece
+* Tüm alanlar, parametreler ve yöntem türleri, null olabilecekleri için `@javax.annotation.Nullable` ile işaretlenmelidir.
+ Böylece, IntelliJ'den tüm bölümlerde null değerleri hakkında düşünmeniz gerektiğini bildirir.
+* Tüm değişken (final olmayan) alanlar için varsayım, alan değeri değişirken her zaman bir değer olduğudur.
+ * Bu, bu nesnenin ömrü boyunca bu gerçekten null olmayabileceğini değil, değişken değeri değişirken her zaman bir değer olduğunu görmek için iki kere kontrol etmek gerektiğini gösterir.
+
+_Not: Bu, `@Nonnull` ek açıklamaları genellikle gerekli olmadığını, ancak önceki ek açıklama ile geçersiz kılmak için veya null olmayı belirtmek için bir bağlamda kullanılabilir._
+
+`Optional` bir yöntem için dönüş türü için iyi bir çözümdür, böylece null dönüş türleri `Optional` ile değiştirilebilir. Bkz. [Java Optional'un kullanımı]({{< relref "how-to-contribute/code-style-and-quality-java" >}}#java-optional).
+
+
+### Kod Duplicasyonunu Önleme
+
+1. Her zaman kodu/kopyalamak veya benzer bir tür işlevi farklı bir yerde yeniden oluşturmak için, değişiklikleri yeniden kullanmak/soyutlamak/soyutlamak için yollarını düşünün.
+2. Farklı özellemeler arasındaki ortak davranışlar, başka bir bileşene (veya paylaşılan bir sınıfa) paylaşılmalıdır.
+3. Her zaman "özel statik final" sabitleri kullanın, aksi takdirde farklı yerlerde dizeler veya diğer özel değerleri tekrarlamak. Sabitler, bir sınıfın üst üye alanında bildirilmelidir.
+
+
+### Test Edilebilirlik İçin Tasarım
+
+Test edilebilir kod genellikle iyi bir bütünleşik işlevi ve dışarıdan yeniden kullanılabilir olarak yapılır.
+
+Bir özet veya sorunlar / belirtiler ve önerilen yeniden düzenleme, PDF'deki bağlantıda bulunabilir. Lütfen not, PDF'deki örnekler genellikle bir bağımlılık enjeksiyon çerçevesi (Guice) kullanır, ancak bunun aynı şekilde çalışmadığını unutmayın.[^1]
+
+[http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf](http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf)
+
+Burada en önemli noktaların kısa bir özeti bulunmaktadır.
+
+
+**Bağımlılıkları Enjekte Et**
+
+Reusability, bağımlılıkları oluşturan kurucuların (alanları atayan nesneler) oluşturmamasına yardımcı olur, ancak bunları parametreler olarak kabul ederler.
+
+* Etkili bir şekilde, kurucuların `new` anahtar kelimesi olmaması gerekir.
+* Özel durumlar, yeni boş bir koleksiyon (`new ArrayList<>()`) veya benzer yardımcı alanları oluşturmaktır (yalnızca temel bağımlılıkları olan nesneler).
+
+Tam nesne oluşturmak için kolay / okunabilirlik için, tüm nesneyi bağımlılıklarıyla oluşturmak için fabrika yöntemleri veya ek olarak kullanılabilir ekstra kurucular ekleyin.
+
+Hiçbir zaman, bir testte nesne alanlarını değiştirmek için yansıma veya "Beyaz Kutu" util'ini kullanmanız gerekmez veya PowerMock'i kullanmanız gerekmez.
+
+
+**"Çok İşlevli" Önleme**
+
+Eğer test sırasında büyük bir diğer bileşen setine ihtiyacınız varsa (çok işlevli), yeniden düzenlemeyi düşünün.
+
+Test etmek istediğiniz bileşen/sınıf, muhtemelen başka bir geniş bileşene (ve bunun uygulamasına) bağlıdır, yerine minimal arayüz (soyutlama) gerekli için.
+
+Bu durumda, arayüzleri (minimal gerekli arayüzü çıkarın) ve bu durumda test stub sağlayın.
+
+* Örneğin, S3RecoverableMultiPartUploader test etmek için gerçek S3 erişimi gerekiyorsa
+ o zaman S3 erişimi, bir arayüzün ve testin bunu test stub ile değiştirmesi gerekir
+* Bu, doğal olarak bağımlılıkları enjekte etmeyi gerektirir (bkz. yukarıda)
+
+⇒ Lütfen not, bu adımlar genellikle test uygulamak için daha fazla çaba gerektirir, ancak diğer bileşenlerde değişiklikler yapılırken testlerin daha dayanıklı olmasını sağlar, yani diğer bileşenlerde değişiklikler yapılırken testleri değiştirmeniz gerekmez.
+
+### Performans Duyarlılığı
+
+Biz, kodun "koordinasyon" ve kodun "veri işleme" olduğunu kavramakla ilgilenebiliriz. Koordinasyon kodu her zaman basitlik ve temizlik için favori olmalıdır. Veri işleme kodu, performans için yüksek performans gerektiren ve performans için optimize edilmelidir.
+
+Bu, genel fikirlerin bölümlerdeki üstünü uygulamak anlamına gelir, ancak belki bazı noktalarda bazı yönleri atlamak için daha fazla performans için mümkündür.
+
+
+**Hangi kod yolları veri işleme yollarıdır?**
+
+* Kayıt bazı yolları: Kayıt bazı yöntemler ve kod yolları, her kayıt için çağrılır. Örneğin, Bağlayıcılar, Serileştiriciler, Durum Sonları, Formatlar, Görevler, Operatörler, Ölçümler, çalışma zamanı veri yapıları, vb.
+* I/O yöntemleri: Mesajları veya veri parçalarını tamponlar arasında taşımak. Örnekler, RPC sistemi, Ağ Yığını, Dosya Sistemleri, Kodlayıcılar / Kod Çözücüler, vb.
+
+
+**Performans kritik kodun ne yaptığını öğrendiği şeyler**
+
+* Mutable nesneleri (ve bazen GC'ye basınç atmak için) kullanmak, bazen immutability için ödün vermek anlamına gelir.
+* Temel türleri, temel türlerin dizilerini veya MemorySegment/ByteBuffer kullanıp temel türlerine ve byte dizilerine anlamını kodlamak, bunları ayrı sınıflar ve nesneler kullanıp kullanmamak anlamına gelir.
+* Kodu, çok kayıt için çalışırken pahalı işleri (ayırma, arama, sanal yöntem çağrıları, vb.) çok kayıt için çalışırken çalışırken amortize etmek için yapılandırın.
+* Okunabilirlik için optimize edilmiş kod düzeni, JIT için değil, okunabilirlik için değil, JIT derleyicisinin içine almak anlamına gelir. Örnekler, başka bir sınıfın alanlarını içine alıp (JIT'in bunu çalışma zamanında işlemesi sorgulanırken) veya kodu JIT derleyicisinin içine almak için yapılandırın, veya döngüleri içine alıp, vektörizasyonu, vb.
+
+
+
+## 5. Eşzamanlılık ve İş Parçacığı
+
+**Çoğunluk kod yolları herhangi bir eşzamanlılık gerektirmez.** Doğru iç içe işlevler, neredeyse her zaman ihtiyacınızı ortadan kaldırır.
+
+* Flink çekirdeği ve çalışma zamanı, bu inşa bloklarını sağlamak için eşzamanlılık kullanır.
+ Örnekler, RPC sistemi, Ağ Yığını, Görevlerin posta kutusu modeli veya bazı önceden tanımlı Kaynak / Kuyruk yardımcılarıdır.
+* Flink çekirdeği ve çalışma zamanı, bu yapı bloklarını sağlamak için eşzamanlılık kullanır.
+ Örnekler, RPC sistemi, Ağ Yığını, Görevlerin posta kutusu modeli veya bazı önceden tanımlı Kaynak / Kuyruk yardımcılarıdır.
+* Tamamen bu noktada değiliz, ancak kendi eşzamanlılığını uygulayan herhangi bir yeni eklenti, temel sistem yapı blokları kategorisine girmedikçe inceleme altında olmalıdır.
+* Katkıda bulunanlar, eşzamanlı kod uygulamaları gerektiğini düşünüyorlarsa, mevcut bir soyutlama/yapı bloğu olup olmadığını veya bir tane eklenip eklenmemesi gerektiğini görmek için committer'lar ile iletişime geçmelidir.
+
+
+**Bir bileşen geliştirirken iş parçacığı modeli ve senkronizasyon noktaları hakkında önceden düşünün.**
+
+* Örneğin: tek iş parçacıklı, engelleyici, engelleyici olmayan, senkron, asenkron, çok iş parçacıklı, iş parçacığı havuzu, mesaj kuyrukları, volatile, senkronize blok/yöntemler, muteksler, atomikler, geri çağrılar, …
+* Bu şeyleri doğru almak ve bunlar hakkında önceden düşünmek, sınıf arayüzlerini/sorumluluklarını tasarlamaktan daha da önemlidir, çünkü sonradan değiştirmek çok daha zordur.
+
+
+**Mümkünse her şekilde iş parçacıklarını kullanmaktan kaçınmaya çalışın.**
+
+* Eğer bir iş parçacığı başlatmak için bir durumunuz olduğunu düşünüyorsanız, bunu açıkça incelenmesi gereken bir şey olarak pull request'te belirtin.
+
+
+**İş parçacıklarını kullanmanın başlangıçta göründüğünden çok daha zor olduğunu unutmayın**
+
+* İş parçacıklarının temiz bir şekilde kapatılması çok zordur.
+* Kesintileri sağlam bir şekilde ele almak (hem yavaş kapatmadan hem de canlı kilitlerden kaçınmak) neredeyse bir Java Sihirbazı gerektirir.
+* İş parçacıklarından temiz hata yayılımını tüm durumlarda sağlamak, titiz bir tasarım gerektirir.
+* Çok iş parçacıklı uygulama/bileşen/sınıfın karmaşıklığı, her ek senkronizasyon noktası/blok/kritik bölüm ile üstel olarak artar. Kodunuz başlangıçta anlaşılması kolay olabilir, ancak hızlı bir şekilde bu noktanın ötesine geçebilir.
+* Çok iş parçacıklı kodun düzgün şekilde test edilmesi temel olarak imkansızdır, alternatif yaklaşımlar (asenkron kod, engelleyici olmayan kod, mesaj kuyrukları ile aktör modeli gibi) test edilmesi oldukça kolaydır.
+* Genellikle çok iş parçacıklı kod, modern donanımda alternatif yaklaşımlara kıyasla daha az verimlidir.
+
+
+**java.util.concurrent.CompletableFuture'dan haberdar olun**
+
+* Diğer eşzamanlı kodlarda olduğu gibi, bir CompletableFuture kullanmaya nadiren ihtiyaç olmalıdır.
+* Bir future'ı tamamlamak, açıkça bir tamamlama yürütücüsü belirtilmedikçe, sonucun tamamlanmasını bekleyen zincirlenmiş herhangi bir future'ı çağrı iş parçacığında da tamamlayacaktır.
+* Bu, örneğin Scheduler / ExecutionGraph'ın bölümlerinde olduğu gibi, tüm yürütme senkron / tek iş parçacıklı olması gerekiyorsa kasıtlı olabilir.
+ * Flink, tek iş parçacıklı bir RPC uç noktası çalıştığı gibi aynı iş parçacığında zincirlenmiş işleyicileri çağırmaya izin vermek için bir "ana iş parçacığı yürütücüsü" kullanır.
+* Bu, future'ı tamamlayan iş parçacığı hassas bir iş parçacığı ise beklenmedik olabilir.
+ * Bu durumda, bir yürütücü mevcut olduğunda `future.complete(value)` yerine `CompletableFuture.supplyAsync(value, executor)` kullanmak daha iyi olabilir.
+* Bir future'ın tamamlanmasını beklerken engellendiğinizde, her zaman sonuç için bir zaman aşımı sağlayın ve zaman aşımlarını açıkça ele alın.
+* Şunları beklemek istiyorsanız `CompletableFuture.allOf()`/`anyOf()`, `ExecutorCompletionService` veya `org.apache.flink.runtime.concurrent.FutureUtils#waitForAll` kullanın: tüm sonuçlar/herhangi bir sonuç/tüm sonuçlar ancak (yaklaşık) tamamlanma sırasına göre ele alınan.
+
+
+
+
+## 6. Bağımlılıklar ve Modüller
+
+* **Bağımlılık ayak izini küçük tutun**
+ * Ne kadar çok bağımlılık olursa, topluluğun bunları bir bütün olarak yönetmesi o kadar zorlaşır.
+ * Bağımlılık yönetimi, bağımlılık çakışmaları, lisansları ve ilgili bildirimleri sürdürme ve güvenlik açıklarını ele almayı içerir.
+ * Bağımlılığın gelecekteki çakışmaları önlemek için gölgelenip/yeniden konumlandırıp konumlandırılmaması gerektiğini tartışın.
+* **Sadece bir yöntem için bağımlılık eklemeyin**
+ * Mümkünse Java'nın yerleşik araçlarını kullanın.
+ * Eğer yöntem Apache lisanslı ise, uygun atıf ile yöntemi bir Flink yardımcı sınıfına kopyalayabilirsiniz.
+* **Bağımlılıkların beyanı**
+ * Açıkça dayandığınız bağımlılıkları beyan edin, ister doğrudan içe aktarıp kullandığınız sınıfları sağlasın, isterse Log4J gibi doğrudan kullandığınız bir hizmet sağlasın.
+ * Geçişli bağımlılıklar yalnızca çalışma zamanında ihtiyaç duyulan ancak kendinizin kullanmadığınız bağımlılıkları sağlamalıdır.
+ * [[kaynak](https://stackoverflow.com/questions/15177661/maven-transitive-dependencies)]
+* **Maven modüllerindeki sınıfların konumu**
+ * Yeni bir sınıf oluşturduğunuzda, nereye koyacağınızı düşünün.
+ * Bir sınıf gelecekte birden fazla modül tarafından kullanılabilir ve bu durumda bir `common` modülüne ait olabilir.
+
+
+
+## 7. Test Etme
+
+### Araçlar
+
+Kod tabanımızı test çerçevesi ve iddia kütüphanesi olarak [JUnit 5](https://junit.org/junit5/docs/current/user-guide/) ve [AssertJ](https://assertj.github.io/doc/)'ye taşıyoruz.
+
+Belirli bir neden olmadığı sürece, Flink'e yeni testlerle katkıda bulunurken ve hatta mevcut testleri değiştirirken JUnit 5 ve AssertJ kullandığınızdan emin olun. Hamcrest, JUnit iddialarını ve `assert` yönergesini kullanmayın.
+Testlerinizi okunabilir hale getirin ve AssertJ tarafından veya bazı flink modülleri tarafından sağlanan [özel iddialar](https://assertj.github.io/doc/#assertj-core-custom-assertions) tarafından sağlanan iddia mantığını çoğaltmayın.
+Örneğin, şundan kaçının:
+
+```java
+assert list.size() == 10;
+for (String item : list) {
+ assertTrue(item.length() < 10);
+}
+```
+
+Ve bunun yerine şunu kullanın:
+
+```java
+assertThat(list)
+ .hasSize(10)
+ .allMatch(item -> item.length() < 10);
+```
+
+### Hedefli testler yazın
+
+* Uygulamaları değil sözleşmeleri test edin : Bir dizi eylemden sonra, bileşenlerin belirli bir durumda olduğunu test edin, bileşenlerin bir dizi dahili durum değişikliği izlediğini test etmek yerine.
+ * Örneğin, tipik bir anti-pattern, testin bir parçası olarak belirli bir yöntemin çağrılıp çağrılmadığını kontrol etmektir.
+* Bunu uygulamanın bir yolu, bir birim testi yazarken _Düzenle_, _Harekete Geç_, _İddia Et_ test yapısını takip etmeye çalışmaktır ([https://xp123.com/articles/3a-arrange-act-assert/](https://xp123.com/articles/3a-arrange-act-assert/))
+
+ Bu, testin mekaniğinden ziyade testin amacını (test altındaki senaryo nedir) iletmeye yardımcı olur. Teknik detaylar, test sınıfının altındaki statik yöntemlere gider.
+
+ Bu modeli takip eden Flink'teki testlerin örnekleri şunlardır:
+
+ * [https://github.com/apache/flink/blob/master/flink-core/src/test/java/org/apache/flink/util/LinkedOptionalMapTest.java](https://github.com/apache/flink/blob/master/flink-core/src/test/java/org/apache/flink/util/LinkedOptionalMapTest.java)
+ * [https://github.com/apache/flink/blob/master/flink-filesystems/flink-s3-fs-base/src/test/java/org/apache/flink/fs/s3/common/writer/RecoverableMultiPartUploadImplTest.java](https://github.com/apache/flink/blob/master/flink-filesystems/flink-s3-fs-base/src/test/java/org/apache/flink/fs/s3/common/writer/RecoverableMultiPartUploadImplTest.java)
+
+
+### Mockito'dan Kaçının - Yeniden Kullanılabilir Test Uygulamaları Kullanın
+
+* Mockito tabanlı testler, işlevselliğin çoğaltılmasını ve etki yerine uygulamayı test etmeyi teşvik ederek uzun vadede bakımı maliyetli olma eğilimindedir.
+ * Daha fazla ayrıntı: [https://docs.google.com/presentation/d/1fZlTjOJscwmzYadPGl23aui6zopl94Mn5smG-rB0qT8](https://docs.google.com/presentation/d/1fZlTjOJscwmzYadPGl23aui6zopl94Mn5smG-rB0qT8)
+* Bunun yerine, yeniden kullanılabilir test uygulamaları ve yardımcı programlar oluşturun.
+ * Bu şekilde, bazı sınıflar değiştiğinde, sadece birkaç test yardımcı programı veya sahte nesneyi güncellemek zorunda kalırız.
+
+### JUnit testlerinde zaman aşımlarından kaçının
+
+Genel olarak, JUnit testlerinde yerel zaman aşımları ayarlamaktan kaçınmalı, bunun yerine Azure'daki global zaman aşımına güvenmeliyiz. Global zaman aşımı, oluşturma zaman aşımına uğramadan hemen önce iş parçacığı dökümlerini alarak hata ayıklamayı kolaylaştırır.
+
+Aynı zamanda, manuel olarak ayarladığınız herhangi bir zaman aşımı değeri keyfidir. Çok düşük ayarlanırsa, test kararsızlıkları elde edersiniz. Çok düşük ne demek, donanım ve mevcut kullanım (özellikle G/Ç) gibi çok sayıda faktöre bağlıdır. Dahası, yerel bir zaman aşımı daha fazla bakım gerektiriyor. Bir oluşturmayı ayarlayabileceğiniz bir düğme daha. Testi biraz değiştirirseniz, zaman aşımını da iki kez kontrol etmeniz gerekir. Bu nedenle, sadece zaman aşımlarını artıran oldukça fazla commit olmuştur.
+
+
+[^1]: We are keeping such frameworks out of Flink, to make debugging easier and avoid dependency clashes.
diff --git a/docs/content.tr/how-to-contribute/code-style-and-quality-components.md b/docs/content.tr/how-to-contribute/code-style-and-quality-components.md
new file mode 100644
index 0000000000..1695fee1d4
--- /dev/null
+++ b/docs/content.tr/how-to-contribute/code-style-and-quality-components.md
@@ -0,0 +1,149 @@
+---
+title: Kod Stili ve Kalite Kılavuzu — Bileşenler Kılavuzu
+bookCollapseSection: false
+bookHidden: true
+---
+
+# Kod Stili ve Kalite Kılavuzu — Bileşenler Kılavuzu
+
+#### [Önsöz]({{< relref "how-to-contribute/code-style-and-quality-preamble" >}})
+#### [Pull Request'ler ve Değişiklikler]({{< relref "how-to-contribute/code-style-and-quality-pull-requests" >}})
+#### [Genel Kodlama Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-common" >}})
+#### [Java Dili Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-java" >}})
+#### [Scala Dili Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-scala" >}})
+#### [Bileşenler Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-components" >}})
+#### [Biçimlendirme Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-formatting" >}})
+
+## Bileşene Özel Kılavuzlar
+
+_Belirli bileşenlerdeki değişiklikler hakkında ek kılavuzlar._
+
+
+### Konfigürasyon Değişiklikleri
+
+Konfigürasyon seçeneği nerede olmalıdır?
+
+* 'flink-conf.yaml': İşler arasında standartlaştırmak isteyebileceğiniz yürütme davranışıyla ilgili tüm konfigürasyon. Bunu, birinin "ops" şapkasıyla veya diğer ekiplere bir stream processing platformu sağlayan birinin ayarlayacağı parametreler olarak düşünün.
+
+* 'ExecutionConfig' : Yürütme sırasında operatörler tarafından ihtiyaç duyulan, belirli bir Flink uygulamasına özgü parametreler. Tipik örnekler watermark aralığı, serializer parametreleri, nesne yeniden kullanımıdır.
+* ExecutionEnvironment (kodda) : Belirli bir Flink uygulamasına özgü olan ve yalnızca program / veri akışı oluşturmak için gereken, yürütme sırasında operatörler içinde gerekmeyen her şey.
+
+Konfigürasyon anahtarlarının adlandırılması:
+
+* Konfigürasyon anahtarı adları hiyerarşik olmalıdır.
+ Konfigürasyonu iç içe nesneler (JSON tarzı) olarak düşünün
+
+ ```
+ taskmanager: {
+ jvm-exit-on-oom: true,
+ network: {
+ detailed-metrics: false,
+ request-backoff: {
+ initial: 100,
+ max: 10000
+ },
+ memory: {
+ fraction: 0.1,
+ min: 64MB,
+ max: 1GB,
+ buffers-per-channel: 2,
+ floating-buffers-per-gate: 16
+ }
+ }
+ }
+ ```
+
+* Sonuç olarak konfigürasyon anahtarları şöyle olmalıdır:
+
+ **DEĞİL** `"taskmanager.detailed.network.metrics"`
+
+ **Bunun yerine** `"taskmanager.network.detailed-metrics"`
+
+
+### Connector'lar
+
+Connector'lar tarihsel olarak uygulanması zordur ve thread'ler, concurrency ve checkpointing'in birçok yönüyle başa çıkmaları gerekir.
+
+[FLIP-27](https://cwiki.apache.org/confluence/display/FLINK/FLIP-27%3A+Refactor+Source+Interface)'nin bir parçası olarak, kaynaklar için bunu çok daha basit hale getirmek için çalışıyoruz. Yeni kaynakların artık concurrency/threading ve checkpointing'in herhangi bir yönüyle başa çıkması gerekmemelidir.
+
+Yakın gelecekte sink'ler için benzer bir FLIP beklenebilir.
+
+
+### Örnekler
+
+Örnekler kendine yeterli olmalı ve çalıştırmak için Flink dışında sistemler gerektirmemelidir. Kafka connector gibi belirli connector'ların nasıl kullanılacağını gösteren örnekler hariç. Kullanılması uygun olan kaynak/sink'ler, üretimde kullanılmaması gereken ancak işlerin nasıl çalıştığını keşfetmek için oldukça kullanışlı olan `StreamExecutionEnvironment.socketTextStream` ve dosya tabanlı kaynak/sink'lerdir. (Streaming için sürekli dosya kaynağı vardır)
+
+Örnekler ayrıca saf oyuncak örnekler olmamalı, gerçek dünya kodu ile tamamen soyut örnekler arasında bir denge kurmalıdır. WordCount örneği artık oldukça eskimiş olsa da, işlevselliği vurgulayan ve yararlı şeyler yapabilen basit kodun iyi bir örneğidir.
+
+Örnekler ayrıca yorumlarda yoğun olmalıdır. Sınıf düzeyindeki Javadoc'ta örneğin genel fikrini açıklamalı ve kod boyunca neler olduğunu ve hangi işlevselliğin kullanıldığını açıklamalıdır. Beklenen giriş verileri ve çıkış verileri de açıklanmalıdır.
+
+Örnekler, `bin/flink run path/to/myExample.jar --param1 … --param2` kullanarak bir örnek çalıştırabilmeniz için parametre ayrıştırmayı içermelidir.
+
+
+### Table & SQL API
+
+
+#### Semantik
+
+**SQL standardı ana doğruluk kaynağı olmalıdır.**
+
+* Sözdizimi, semantik ve özellikler SQL ile uyumlu olmalıdır!
+* Tekerleği yeniden icat etmemize gerek yok. Çoğu sorun endüstri genelinde zaten tartışılmış ve SQL standardında yazılmıştır.
+* En yeni standarda güveniyoruz (bu belgeyi yazarken SQL:2016 veya ISO/IEC 9075:2016 ([indirme](https://standards.iso.org/ittf/PubliclyAvailableStandards/c065143_ISO_IEC_TR_19075-5_2016.zip)). Her bölüm çevrimiçi olarak mevcut değildir, ancak hızlı bir web araması burada yardımcı olabilir.
+
+Standarttan sapmaları veya satıcıya özgü yorumları tartışın.
+
+* Bir sözdizimi veya davranış bir kez tanımlandığında kolayca geri alınamaz.
+* Standardı genişletmek veya yorumlamak gereken katkılar, toplulukla kapsamlı bir tartışma gerektirir.
+* Lütfen, Postgres, Microsoft SQL Server, Oracle, Hive, Calcite, Beam gibi diğer satıcıların bu tür durumları nasıl ele aldığı hakkında bazı ilk araştırmaları yaparak committer'lara yardımcı olun.
+
+
+Table API'yi SQL ve Java/Scala programlama dünyası arasında bir köprü olarak düşünün.
+
+* Table API, ilişkisel modeli takip eden analitik programlar için Gömülü Alana Özgü bir Dildir.
+ Sözdizimi ve adlar açısından SQL standardını katı bir şekilde takip etmesi gerekmez, ancak daha sezgisel hissetmeye yardımcı oluyorsa, bir programlama dilinin fonksiyonları ve özellikleri adlandıracağı/yapacağı şekilde daha yakın olabilir.
+* Table API'nin bazı SQL olmayan özellikleri olabilir (örn. map(), flatMap() vb.) ancak yine de "SQL gibi hissetmelidir". Mümkünse fonksiyonlar ve işlemler eşit semantik ve isimlendirmeye sahip olmalıdır.
+
+
+#### Yaygın hatalar
+
+* Bir özellik eklerken SQL'in tip sistemini destekleyin.
+ * Bir SQL fonksiyonu, connector'ı veya formatı, en başından itibaren çoğu SQL tipini doğal olarak desteklemelidir.
+ * Desteklenmeyen tipler kafa karışıklığına yol açar, kullanılabilirliği sınırlar ve aynı kod yollarına birden çok kez dokunarak ek yük oluşturur.
+ * Örneğin, bir `SHIFT_LEFT` fonksiyonu eklerken, katkının sadece `INT` için değil, aynı zamanda `BIGINT` veya `TINYINT` için de yeterince genel olduğundan emin olun.
+
+
+#### Test etme
+
+Null olabilirliği test edin.
+
+* SQL doğal olarak neredeyse her işlem için `NULL`'u destekler ve 3 değerli bir boolean mantığına sahiptir.
+* Her özelliği null olabilirlik açısından da test ettiğinizden emin olun.
+
+
+Tam entegrasyon testlerinden kaçının
+
+* Bir Flink mini-cluster'ı başlatmak ve bir SQL sorgusu için üretilen kodun derlenmesini gerçekleştirmek pahalıdır.
+* Planlayıcı testleri veya API çağrılarının varyasyonları için entegrasyon testlerinden kaçının.
+* Bunun yerine, bir planlayıcıdan çıkan optimize edilmiş planı doğrulayan birim testleri kullanın. Veya doğrudan bir runtime operatörünün davranışını test edin.
+
+
+#### Uyumluluk
+
+Yama sürümlerinde fiziksel plan değişiklikleri getirmeyin!
+
+* Streaming SQL'de durum için geriye dönük uyumluluk, fiziksel yürütme planının sabit kalması gerçeğine dayanır. Aksi takdirde, oluşturulan Operatör Adları/ID'leri değişir ve durum eşleştirilemez ve geri yüklenemez.
+* Dolayısıyla, optimize edilmiş bir streaming pipeline'ının fiziksel planında değişikliklere yol açan her hata düzeltmesi uyumluluğu bozar.
+* Sonuç olarak, farklı optimizer planlarına yol açan türdeki değişiklikler şimdilik yalnızca ana sürümlerde birleştirilebilir.
+
+
+#### Scala / Java birlikte çalışabilirliği (eski kod parçaları)
+
+Arayüzleri tasarlarken Java'yı aklınızda tutun.
+
+* Bir sınıfın gelecekte bir Java sınıfıyla etkileşime girip girmeyeceğini düşünün.
+* Java kodu ile sorunsuz entegrasyon için arayüzlerde Java koleksiyonları ve Java Optional kullanın.
+* Bir sınıf Java'ya dönüştürülmeye tabi tutulacaksa, yapım için .copy() veya apply() gibi case class'ların özelliklerini kullanmayın.
+* Saf Scala kullanıcı odaklı API'ler, Scala ile doğal ve idiomatik ("scalaesk") entegrasyon için saf Scala koleksiyonları/yinelenebilirleri/vb. kullanmalıdır.
+
+
diff --git a/docs/content.tr/how-to-contribute/code-style-and-quality-formatting.md b/docs/content.tr/how-to-contribute/code-style-and-quality-formatting.md
new file mode 100644
index 0000000000..e55fc2bd68
--- /dev/null
+++ b/docs/content.tr/how-to-contribute/code-style-and-quality-formatting.md
@@ -0,0 +1,132 @@
+---
+title: Kod Stili ve Kalite Kılavuzu — Biçimlendirme Kılavuzu
+bookCollapseSection: false
+bookHidden: true
+---
+
+# Kod Stili ve Kalite Kılavuzu — Biçimlendirme Kılavuzu
+
+#### [Önsöz]({{< relref "how-to-contribute/code-style-and-quality-preamble" >}})
+#### [Pull Request'ler ve Değişiklikler]({{< relref "how-to-contribute/code-style-and-quality-pull-requests" >}})
+#### [Genel Kodlama Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-common" >}})
+#### [Java Dili Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-java" >}})
+#### [Scala Dili Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-scala" >}})
+#### [Bileşenler Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-components" >}})
+#### [Biçimlendirme Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-formatting" >}})
+
+## Java Kodu Biçimlendirme Stili
+
+IDE'yi otomatik olarak kod stilini kontrol edecek şekilde ayarlamanızı öneriyoruz. Lütfen {{< docs_link file="flink-docs-stable/docs/flinkdev/ide_setup/" name="IDE Kurulum Kılavuzu">}} sayfasını takip ederek
+{{< docs_link file="flink-docs-stable/docs/flinkdev/ide_setup/#code-formatting" name="spotless">}} ve
+{{< docs_link file="flink-docs-stable/docs/flinkdev/ide_setup/#checkstyle-for-java" name="checkstyle">}} araçlarını kurun.
+
+### Lisans
+
+* **Apache lisans başlıkları.** Dosyalarınızda Apache Lisans başlıklarının olduğundan emin olun. Kodu derlediğinizde RAT eklentisi bunu kontrol eder.
+
+### Import İfadeleri
+
+* **Paket bildirimi öncesinde ve sonrasında boş satır.**
+* **Kullanılmayan import ifadeleri olmamalı.**
+* **Gereksiz import ifadeleri olmamalı.**
+* **Wildcard import ifadeleri olmamalı.** Bunlar, koda ekleme yaparken ve bazı durumlarda yeniden düzenleme sırasında bile sorunlara neden olabilir.
+* **Import sıralaması.** Import ifadeleri alfabetik olarak sıralanmalı, aşağıdaki bloklara ayrılmalı ve her blok arasında boş bir satır olmalıdır:
+ * <org.apache.flink.* 'den importlar>
+ * <org.apache.flink.shaded.* 'den importlar>
+ * <diğer kütüphanelerden importlar>
+ * <javax.* 'den importlar>
+ * <java.* 'den importlar>
+ * <scala.* 'den importlar>
+ * <static importlar>
+
+
+### İsimlendirme
+
+* **Paket adları bir harfle başlamalı ve büyük harf veya özel karakterler içermemelidir.**
+ **Non-private static final alanlar büyük harf olmalı ve kelimeler alt çizgilerle ayrılmalıdır.**(`MY_STATIC_VARIABLE`)
+* **Non-static alanlar/metodlar küçük deve (camel) case olmalıdır.** (`myNonStaticField`)
+
+
+### Boşluklar
+
+* **Tablar ve boşluklar.** Girinti için tab yerine boşluk kullanıyoruz.
+* **Satır sonunda boşluk olmamalı.**
+* **Operatörler/anahtar kelimeler etrafında boşluklar.** Operatörler (`+`, `=`, `>`, …) ve anahtar kelimeler (`if`, `for`, `catch`, …) satırın başında veya sonunda olmadıkları sürece önlerinde ve arkalarında bir boşluk olmalıdır.
+
+
+### Uzun İfadelerde Satır Düzenleme Kuralları
+
+Genel olarak, kod okunabilirliğini artırmak için uzun satırlardan kaçınılmalıdır. Aynı soyutlama düzeyinde çalışan kısa ifadeler kullanmaya çalışın. Uzun ifadeleri, daha fazla yerel değişken tanımlayarak, yardımcı metodlar oluşturarak vb. yollarla kısaltın.
+
+Uzun satırların iki temel kaynağı şunlardır:
+
+* **Fonksiyon tanımında veya çağrısında uzun argüman listesi**: `void func(type1 arg1, type2 arg2, ...)`
+* **Uzun zincirleme metod çağrı dizisi**: `list.stream().map(...).reduce(...).collect(...)...`
+
+Uzun satırları kırma kuralları:
+
+* Satır uzunluk sınırını aşıyorsa veya kırmanın kod okunabilirliğini artıracağını düşünüyorsanız argüman listesini veya çağrı zincirini kırın
+* Bir satırı kırdığınızda, ilk argüman/çağrı da dahil olmak üzere her argüman/çağrı ayrı bir satırda olmalıdır
+* Her yeni satır, üst fonksiyon adının veya çağrılan öğenin satırına göre bir ek girinti (fonksiyon tanımı için iki) içermelidir
+
+Fonksiyon argümanları için ek kurallar:
+
+* Açılış parantezi her zaman üst fonksiyon adının bulunduğu satırda kalır
+* Olası fırlatılan istisna listesi asla kırılmaz ve satır uzunluğu limitini aşsa bile aynı son satırda kalır
+* Son argüman hariç, fonksiyon argümanının bulunduğu her satır aynı satırda kalan bir virgülle bitmelidir
+
+Fonksiyon argümanları listesini kırma örneği:
+
+```
+public void func(
+ int arg1,
+ int arg2,
+ ...) throws E1, E2, E3 {
+
+}
+```
+
+Zincirleme bir çağrıda nokta işareti her zaman, o zincirleme çağrının kendi satırında, çağrının başında yer alır.
+
+Zincirleme çağrılar listesini kırma örneği:
+
+```
+values
+ .stream()
+ .map(...)
+ .collect(...);
+```
+
+
+### Süslü Parantezler
+
+* **Sol süslü parantezler ({
) yeni bir satıra yerleştirilmemelidir.**
+* Sağ süslü parantezler (}
) her zaman satırın başına yerleştirilmelidir.
+* Bloklar. if
, for
, while
, do
, … gibi ifadelerden sonra gelen tüm ifadeler, her zaman süslü parantezlerle bir blok içinde kapsüllenmelidir (blok bir ifade içerse bile).
+
+
+### Javadoc'lar
+
+* **Tüm public/protected metodlar ve sınıflar bir Javadoc'a sahip olmalıdır.**
+* **Javadoc'un ilk cümlesi bir nokta ile bitmelidir.**
+* **Paragraflar yeni bir satırla ayrılmalı ve ile başlamalıdır.**
+
+
+### Erişim Belirteçleri (Modifiers)
+
+* **Gereksiz erişim belirteçleri olmamalı.** Örneğin, interface metodlarında public erişim belirteçleri.
+* **JLS3 erişim belirteci sıralamasını takip edin.** Erişim belirteçleri şu sırayla düzenlenmelidir: public, protected, private, abstract, static, final, transient, volatile, synchronized, native, strictfp.
+
+
+### Dosyalar
+
+* **Tüm dosyalar \n
ile bitmelidir.**
+* Dosya uzunluğu 3000 satırı geçmemelidir.
+
+
+### Çeşitli
+
+* **Diziler Java tarzında tanımlanmalıdır.** Örneğin, `public String[] array`.
+* **Flink Preconditions kullanın.** Homojenliği artırmak için, Apache Commons Validate veya Google Guava yerine tutarlı bir şekilde `org.apache.flink.Preconditions` metodları olan `checkNotNull` ve `checkArgument` kullanın.
+
+[^1]: Bu tür framework'leri hata ayıklamayı kolaylaştırmak ve bağımlılık çakışmalarını önlemek için Flink'in dışında tutuyoruz.
diff --git a/docs/content.tr/how-to-contribute/code-style-and-quality-java.md b/docs/content.tr/how-to-contribute/code-style-and-quality-java.md
new file mode 100644
index 0000000000..99758a29bb
--- /dev/null
+++ b/docs/content.tr/how-to-contribute/code-style-and-quality-java.md
@@ -0,0 +1,120 @@
+---
+title: Kod Stili ve Kalite Kılavuzu — Java
+bookCollapseSection: false
+bookHidden: true
+---
+
+# Kod Stili ve Kalite Kılavuzu — Java
+
+#### [Önsöz]({{< relref "how-to-contribute/code-style-and-quality-preamble" >}})
+#### [Pull Request'ler ve Değişiklikler]({{< relref "how-to-contribute/code-style-and-quality-pull-requests" >}})
+#### [Genel Kodlama Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-common" >}})
+#### [Java Dili Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-java" >}})
+#### [Scala Dili Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-scala" >}})
+#### [Bileşenler Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-components" >}})
+#### [Biçimlendirme Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-formatting" >}})
+
+## Java Dili Özellikleri ve Kütüphaneleri
+
+
+### Ön Koşullar ve Loglama İfadeleri
+
+* Parametrelerde asla dizeleri birleştirmeyin
+ * Yapmayın: `Preconditions.checkState(value <= threshold, "value must be below " + threshold)`
+ * Yapmayın: `LOG.debug("value is " + value)`
+ * Yapın: `Preconditions.checkState(value <= threshold, "value must be below %s", threshold)`
+ * Yapın: `LOG.debug("value is {}", value)`
+
+
+### Generics
+
+* **Raw type kullanmayın:** Kesinlikle gerekli olmadıkça raw type kullanmayın (bazen imza eşleşmeleri, diziler için gereklidir).
+* **Kontrol edilmemiş dönüşümler için uyarıları bastırın:** Kaçınılamıyorsa uyarıları bastırmak için annotation ekleyin (örneğin "unchecked" veya "serial"). Aksi takdirde, generics hakkındaki uyarılar yapıyı doldurur ve ilgili uyarıları boğar.
+
+
+### equals() / hashCode()
+
+* **equals() / hashCode() yalnızca iyi tanımlandıklarında eklenmelidir.**
+* İyi tanımlanmadıkları zaman **testlerde daha basit bir assertion sağlamak için eklenmemelidir**. Bu durumda hamcrest matcher'larını kullanın: [https://github.com/junit-team/junit4/wiki/matchers-and-assertthat](https://github.com/junit-team/junit4/wiki/matchers-and-assertthat)
+* Yöntemlerin iyi tanımlanmadığının yaygın bir göstergesi, alanların bir alt kümesini dikkate almalarıdır (tamamen yardımcı alanlar dışında).
+* Yöntemler mutable alanları dikkate aldığında, genellikle bir tasarım sorununuz vardır. `equals()`/`hashCode()` yöntemleri, türü bir anahtar olarak kullanmayı önerir, ancak imzalar türü değiştirmeye devam etmenin güvenli olduğunu gösterir.
+
+
+### Java Serialization
+
+* **Hiçbir şey için Java Serialization kullanmayın !!!**
+* **Hiçbir şey için Java Serialization kullanmayın !!! !!!**
+* **Hiçbir şey için Java Serialization kullanmayın !!! !!! !!!**
+* Flink içinde, Java serialization, mesajları ve programları RPC aracılığıyla taşımak için kullanılır. Bu, Java serialization kullandığımız tek durumdur. Bu nedenle, bazı sınıfların serializable olması gerekir (RPC aracılığıyla taşınıyorlarsa).
+* **Serializable sınıflar bir Serial Version UID tanımlamalıdır:**
+
+ `private static final long serialVersionUID = 1L;`
+* **Yeni sınıflar için Serial Version UID 1'den başlamalıdır** ve genellikle Java serialization uyumluluğu tanımına göre sınıfta yapılan her uyumsuz değişiklikte artırılmalıdır (örneğin: bir alanın türünü değiştirmek veya bir sınıfı sınıf hiyerarşisinde taşımak).
+
+
+### Java Reflection
+
+**Java'nın Reflection API'sini kullanmaktan kaçının**
+
+* Java'nın Reflection API'si belirli durumlarda çok kullanışlı bir araç olabilir, ancak her durumda bir hack'tir ve alternatifler araştırılmalıdır. Flink'in reflection kullanması gereken tek durumlar şunlardır:
+ * Başka bir modülden dinamik olarak implementasyonları yükleme (web UI, ek serializer'lar, pluggable query processor'lar gibi).
+ * TypeExtractor sınıfı içinde türleri çıkarma. Bu yeterince kırılgandır ve TypeExtractor sınıfının dışında yapılmamalıdır.
+ * Bir sınıfın/metodun tüm sürümlerde bulunduğunu varsayamadığımız için reflection kullanmamız gereken, JDK sürümleri arası özelliklerin bazı durumları.
+* Testlerde metodlara veya alanlara erişmek için reflection'a ihtiyacınız varsa, bu genellikle daha derin mimari sorunlara işaret eder, örneğin yanlış scoping, ilgi alanlarının kötü ayrımı veya test edilen sınıfa component'ler/dependency'ler sağlamanın temiz bir yolunun olmadığı durumlar.
+
+
+### Collections
+
+* **ArrayList ve ArrayDeque, listenin ortasında sık sık ekleme ve silme yapıldığı durumlar dışında neredeyse her zaman LinkedList'ten üstündür.**
+* **Map'ler için, birden çok lookup gerektiren pattern'lardan kaçının**
+ * `get()` öncesinde `contains()` → `get()` ve null kontrolü
+ * `put()` öncesinde `contains()` → `putIfAbsent()` veya `computeIfAbsent()`
+ * Key'ler üzerinde yineleme, value'ları alma → `entrySet()` üzerinde yineleme
+* **Bir collection için initial capacity'i yalnızca bunun için iyi kanıtlanmış bir neden varsa ayarlayın**, aksi takdirde kodu karıştırmayın. **Map'ler** durumunda bu daha da yanıltıcı olabilir çünkü Map'in load factor'ü etkili bir şekilde capacity'i azaltır.
+
+
+### Java Optional
+
+* Nullable değerler için `Optional` kullanmadığınız yerlerde **@Nullable annotation kullanın**.
+* `Optional` kullanımının kritik kodda **performance degradation'a yol açacağını kanıtlayabiliyorsanız, @Nullable'a fallback yapın**.
+* Kanıtlanmış bir performans endişesi durumu dışında, API/public method'larda **nullable değerleri döndürmek için her zaman Optional kullanın**.
+* Bunun yerine ya metodu overload edin ya da fonksiyon argümanları seti için Builder pattern kullanın, **Optional'ı bir fonksiyon argümanı olarak kullanmayın**.
+ * Not: Kodun basitleştirildiğine inanıyorsanız, private helper method'da bir Optional argümanına izin verilebilir
+ ([örnek](https://github.com/apache/flink/blob/master/flink-formats/flink-avro/src/main/java/org/apache/flink/formats/avro/typeutils/AvroFactory.java#L95)).
+* **Class field'ları için Optional kullanmayın**.
+
+
+### Lambda Expressions
+
+* Non-capturing lambda'ları tercih edin (dış scope'daki referansları içermeyen lambda'lar). Capturing lambda'lar her çağrı için yeni bir nesne instance'ı oluşturmalıdır. Non-capturing lambda'lar, her invocation için aynı instance'ı kullanabilir.
+
+ **yapmayın:**
+ ```
+ map.computeIfAbsent(key, x -> key.toLowerCase())
+ ```
+
+ **yapın:**
+ ```
+ map.computeIfAbsent(key, k -> k.toLowerCase());
+ ```
+
+* Inline lambda'lar yerine method reference'ları düşünün
+
+ **yapmayın**:
+ ```
+ map.computeIfAbsent(key, k-> Loader.load(k));
+ ```
+
+ **yapın:**
+ ```
+ map.computeIfAbsent(key, Loader::load);
+ ```
+
+
+### Java Streams
+
+* Performance-critical olan herhangi bir kodda Java Streams kullanmaktan kaçının.
+* Java Streams kullanmanın ana motivasyonu, kod readability'sini geliştirmek olmalıdır. Bu nedenle, data-intensive olmayan, ancak koordinasyonla ilgilenen kod parçaları için iyi bir match olabilirler.
+* İkinci durumda bile, scope'u bir metod ile veya bir internal class içindeki birkaç private metod ile sınırlamaya çalışın.
+
+
diff --git a/docs/content.tr/how-to-contribute/code-style-and-quality-preamble.md b/docs/content.tr/how-to-contribute/code-style-and-quality-preamble.md
new file mode 100644
index 0000000000..7537fa0420
--- /dev/null
+++ b/docs/content.tr/how-to-contribute/code-style-and-quality-preamble.md
@@ -0,0 +1,31 @@
+---
+title: Kod Stili ve Kalite Kılavuzu
+bookCollapseSection: false
+weight: 19
+---
+
+# Apache Flink Kod Stili ve Kalite Kılavuzu
+
+#### [Önsöz]({{< relref "how-to-contribute/code-style-and-quality-preamble" >}})
+#### [Pull Request'ler ve Değişiklikler]({{< relref "how-to-contribute/code-style-and-quality-pull-requests" >}})
+#### [Genel Kodlama Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-common" >}})
+#### [Java Dili Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-java" >}})
+#### [Scala Dili Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-scala" >}})
+#### [Bileşenler Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-components" >}})
+#### [Biçimlendirme Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-formatting" >}})
+
+
+
+Bu, sürdürmek istediğimiz kod ve kalite standardını yakalama girişimidir.
+
+Bir kod katkısı (veya herhangi bir kod parçası) çeşitli şekillerde değerlendirilebilir: Özellik kümelerinden biri, kodun doğru ve verimli olup olmadığıdır. Bu, _mantıksal veya algoritmik problemi_ doğru ve iyi bir şekilde çözmeyi gerektirir.
+
+Diğer bir özellik kümesi ise, kodun sezgisel bir tasarım ve mimariyi takip edip etmediği, iyi yapılandırılmış ve doğru ilgi ayrımına sahip olup olmadığı ve kodun kolayca anlaşılabilir olup olmadığı ve varsayımlarını açık hale getirip getirmediğidir. Bu özellik kümesi, _yazılım mühendisliği problemini_ iyi çözmeyi gerektirir. İyi bir çözüm, kodun kolayca test edilebilir, orijinal yazarlarından başka kişiler tarafından da bakımının yapılabilir (çünkü yanlışlıkla bozmak daha zordur) ve geliştirmek için verimli olduğu anlamına gelir.
+
+İlk özellik kümesinin oldukça nesnel onay kriterleri varken, ikinci özellik kümesini değerlendirmek çok daha zordur, ancak Apache Flink gibi bir açık kaynak projesi için büyük önem taşır. Kod tabanını birçok katkıda bulunana davet etmek, katkıları orijinal kodu yazmayan geliştiriciler için anlaşılması kolay hale getirmek ve kodu birçok katkı karşısında sağlam tutmak için, iyi tasarlanmış kod çok önemlidir.[^1] İyi tasarlanmış kod için, zaman içinde doğru ve hızlı kalmasını sağlamak daha kolaydır.
+
+Bu elbette iyi tasarlanmış kod nasıl yazılır konusunda tam bir kılavuz değildir. Bunu yakalamaya çalışan büyük kitapların dünyası var. Bu kılavuz, Flink'i geliştirme bağlamında gözlemlediğimiz en iyi uygulamaların, desenlerin, anti-desenlerin ve yaygın hataların bir kontrol listesi olarak düşünülmüştür.
+
+Yüksek kaliteli açık kaynak katkılarının büyük bir kısmı, inceleyicinin katkıyı anlamasına ve etkileri çift kontrol etmesine yardımcı olmakla ilgilidir, bu nedenle bu kılavuzun önemli bir kısmı, bir pull request'i inceleme için nasıl yapılandıracağınızla ilgilidir.
+
+[^1]: Daha önceki günlerde, biz (Flink topluluğu) buna her zaman yeterince dikkat etmedik, bu da Flink'in bazı bileşenlerinin geliştirilmesini ve katkıda bulunulmasını zorlaştırdı.
diff --git a/docs/content.tr/how-to-contribute/code-style-and-quality-pull-requests.md b/docs/content.tr/how-to-contribute/code-style-and-quality-pull-requests.md
new file mode 100644
index 0000000000..b3da75996d
--- /dev/null
+++ b/docs/content.tr/how-to-contribute/code-style-and-quality-pull-requests.md
@@ -0,0 +1,100 @@
+---
+title: Kod Stili ve Kalite Kılavuzu — Pull Request'ler ve Değişiklikler
+bookCollapseSection: false
+bookHidden: true
+---
+
+# Kod Stili ve Kalite Kılavuzu — Pull Request'ler ve Değişiklikler
+
+#### [Önsöz]({{< relref "how-to-contribute/code-style-and-quality-preamble" >}})
+#### [Pull Request'ler ve Değişiklikler]({{< relref "how-to-contribute/code-style-and-quality-pull-requests" >}})
+#### [Genel Kodlama Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-common" >}})
+#### [Java Dili Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-java" >}})
+#### [Scala Dili Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-scala" >}})
+#### [Bileşenler Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-components" >}})
+#### [Biçimlendirme Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-formatting" >}})
+
+
+
+**Gerekçe:** Katkıda bulunanlara, pull request'leri daha kolay ve daha kapsamlı bir şekilde incelenebilecekleri bir duruma getirmek için biraz ekstra çaba harcamalarını istiyoruz. Bu, topluluğa birçok açıdan yardımcı olur:
+
+* İncelemeler çok daha hızlıdır ve böylece katkılar daha erken birleştirilir.
+* Katkılardaki daha az sorunu gözden kaçırarak daha yüksek kod kalitesini sağlayabiliriz.
+* Committer'lar aynı sürede daha fazla katkıyı inceleyebilir, bu da Flink'in yaşadığı yüksek katkı oranıyla başa çıkmaya yardımcı olur.
+
+Lütfen bu kılavuzu takip etmeyen katkıların incelenmesinin daha uzun süreceğini ve bu nedenle genellikle topluluk tarafından daha düşük öncelikle ele alınacağını anlayın. Bu kötü niyet değil, yapılandırılmamış Pull Request'leri incelemenin eklediği karmaşıklıktan kaynaklanmaktadır.
+
+
+## 1. JIRA Sorunu ve İsimlendirme
+
+Pull request'in bir [JIRA sorununa](https://issues.apache.org/jira/projects/FLINK/issues) karşılık geldiğinden emin olun.
+
+İstisnalar, JavaDoc'lardaki veya dokümantasyon dosyalarındaki yazım hatalarının düzeltilmesi gibi ****acil düzeltmelerdir****.
+
+
+Pull request'i `[FLINK-XXXX][bileşen] Pull request'in başlığı` şeklinde adlandırın, burada `FLINK-XXXX` gerçek sorun numarasıyla değiştirilmelidir. Bileşenler, JIRA sorununda kullanılanlarla aynı olmalıdır.
+
+Acil düzeltmeler, örneğin `[hotfix][docs] Olay zamanı tanıtımındaki yazım hatasını düzelt` veya `[hotfix][javadocs] PuncuatedWatermarkGenerator için JavaDoc'u genişlet` şeklinde adlandırılmalıdır.
+
+
+## 2. Açıklama
+
+Katkıyı tanımlamak için lütfen pull request şablonunu doldurun. Lütfen inceleyen kişinin sorunu ve çözümü yalnızca koddan değil, açıklamadan da anlamasını sağlayacak şekilde açıklayın.
+
+İyi açıklanmış bir pull request'in mükemmel bir örneği [https://github.com/apache/flink/pull/7264](https://github.com/apache/flink/pull/7264) 'tür.
+
+Açıklamanın PR tarafından çözülen problem için yeterli olduğundan emin olun. Küçük değişiklikler bir duvar metni gerektirmez. İdeal durumlarda, sorun Jira sorunununda açıklanmıştır ve açıklama büyük ölçüde oradan kopyalanabilir.
+
+Uygulama sırasında ek açık sorular/sorunlar keşfedildiyse ve bunlarla ilgili bir seçim yaptıysanız, bunları pull request metninde açıklayın, böylece inceleyenler varsayımları iki kez kontrol edebilsin. Bir örnek [https://github.com/apache/flink/pull/8290](https://github.com/apache/flink/pull/8290) (Bölüm "Açık Mimari Soruları") içinde bulunabilir.
+
+
+## 3. Refactoring, Temizleme ve Bağımsız Değişiklikleri Ayırma
+
+****NOT: Bu bir optimizasyon değil, kritik bir gerekliliktir.****
+
+Pull Request'ler temizlik, refactoring ve temel değişiklikleri ayrı commit'lere koymalıdır. Bu şekilde, inceleyici bağımsız olarak temizlik ve refactoring'e bakabilir ve bu değişikliklerin davranışı değiştirmediğinden emin olabilir. Ardından, inceleyici temel değişikliklere izole olarak (diğer değişikliklerin gürültüsü olmadan) bakabilir ve bunun temiz ve sağlam bir değişiklik olduğundan emin olabilir.
+
+Kesinlikle ayrı bir commit'e gitmesi gereken değişiklik örnekleri şunları içerir:
+
+* Önceden var olan koddaki temizlik, stil ve uyarıları düzeltme
+* Paketleri, sınıfları veya yöntemleri yeniden adlandırma
+* Kodu taşıma (diğer paketlere veya sınıflara)
+* Yapıyı refactoring veya tasarım desenlerini değiştirme
+* İlgili testleri veya yardımcı programları birleştirme
+* Mevcut testlerdeki varsayımları değiştirme (değiştirilen varsayımların neden mantıklı olduğunu açıklayan bir commit mesajı ekleyin).
+
+Aynı PR'nin önceki commit'lerinde tanıtılan sorunları düzelten temizleme commit'leri olmamalıdır. Commit'ler kendi içinde temiz olmalıdır.
+
+Ek olarak, herhangi bir daha büyük katkı, değişiklikleri bağımsız olarak incelenebilecek bir dizi bağımsız değişikliğe ayırmalıdır.
+
+Sorunları ayrı commit'lere bölmenin iki harika örneği şunlardır:
+
+* [https://github.com/apache/flink/pull/6692](https://github.com/apache/flink/pull/6692) (temizleme ve refactoring'i ana değişikliklerden ayırır)
+* [https://github.com/apache/flink/pull/7264](https://github.com/apache/flink/pull/7264) (ayrıca ana değişiklikleri bağımsız olarak incelenebilir parçalara ayırır)
+
+Bir pull request hala büyük commit'ler içeriyorsa (örneğin, 1000'den fazla değiştirilen satırı olan bir commit), yukarıdaki örnekte olduğu gibi commit'i birden çok alt probleme nasıl böleceğinizi düşünmek faydalı olabilir.
+
+
+## 4. Commit İsimlendirme Kuralları
+
+Commit mesajları, pull request'in tamamına benzer bir modeli takip etmelidir:
+`[FLINK-XXXX][bileşen] Commit açıklaması`.
+
+Bazı durumlarda, sorun burada bir alt görev olabilir ve bileşen Pull Request'in ana bileşeninden farklı olabilir. Örneğin, commit bir çalışma zamanı değişikliği için uçtan uca bir test getirdiğinde, PR `[runtime]` olarak etiketlenecektir, ancak bireysel commit `[e2e]` olarak etiketlenecektir.
+
+Commit mesajları için örnekler:
+
+* `[hotfix] Sürüm son eklerine izin vermek için update_branch_version.sh düzeltildi`
+* `[hotfix] [table] Kullanılmayan geometri bağımlılığını kaldır`
+* `[FLINK-11704][tests] AbstractCheckpointStateOutputStreamTestBase'i geliştir`
+* `[FLINK-10569][runtime] ExecutionVertexCancelTest'te Instance kullanımını kaldır`
+* `[FLINK-11702][table-planner-blink] Yeni bir tablo tip sistemi tanıt`
+
+
+## 5. Sistemin Gözlemlenebilir Davranışındaki Değişiklikler
+
+Katkıda bulunanlar, PR'lerinde Flink'in gözlemlenebilir davranışını herhangi bir şekilde bozan değişikliklerin farkında olmalıdır, çünkü birçok durumda bu tür değişiklikler mevcut kurulumları bozabilir. Kodlama sırasında veya incelemelerde bu sorunla ilgili olarak soru işaretleri uyandırması gereken kırmızı bayraklar, örneğin:
+
+* Bozan değişiklikle testlerin tekrar geçmesini sağlamak için iddialar değiştirilmiştir.
+* Mevcut testlerin geçmeye devam etmesi için yapılandırma ayarının aniden (varsayılan olmayan) değerlere ayarlanması gerekir. Bu, özellikle bozucu bir varsayılana sahip yeni ayarlar için olabilir.
+* Mevcut komut dosyalarının veya yapılandırmaların ayarlanması gerekir.
diff --git a/docs/content.tr/how-to-contribute/code-style-and-quality-scala.md b/docs/content.tr/how-to-contribute/code-style-and-quality-scala.md
new file mode 100644
index 0000000000..11bceb2b56
--- /dev/null
+++ b/docs/content.tr/how-to-contribute/code-style-and-quality-scala.md
@@ -0,0 +1,82 @@
+---
+title: Kod Stili ve Kalite Kılavuzu — Scala
+bookCollapseSection: false
+bookHidden: true
+---
+
+# Kod Stili ve Kalite Kılavuzu — Scala
+
+#### [Önsöz]({{< relref "how-to-contribute/code-style-and-quality-preamble" >}})
+#### [Pull Request'ler ve Değişiklikler]({{< relref "how-to-contribute/code-style-and-quality-pull-requests" >}})
+#### [Genel Kodlama Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-common" >}})
+#### [Java Dili Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-java" >}})
+#### [Scala Dili Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-scala" >}})
+#### [Bileşenler Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-components" >}})
+#### [Biçimlendirme Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-formatting" >}})
+
+## Scala Dili Özellikleri
+
+### Scala'nın Kullanılacağı (ve Kullanılmayacağı) Yerler
+
+**Scala'yı Scala API'leri veya saf Scala kütüphaneleri için kullanırız.**
+
+**Temel API'lerde ve runtime bileşenlerinde Scala kullanmıyoruz. Bu bileşenlerden mevcut Scala kullanımını (kod ve dependency'ler) kaldırmayı hedefliyoruz.**
+
+⇒ Bu Scala'yı sevmediğimizden değil, "doğru iş için doğru araç" yaklaşımının bir sonucudur (aşağıya bakın).
+
+API'ler için, temeli Java'da geliştiririz ve Scala'yı üzerine katmanlarız.
+
+* Bu geleneksel olarak hem Java hem de Scala için en iyi birlikte çalışabilirliği sağlamıştır
+* Bu, Scala API'sini güncel tutmak için özel çaba gerektiği anlamına gelir
+
+Neden temel API'lerde ve runtime'da Scala kullanmıyoruz?
+
+* Geçmiş göstermiştir ki Scala, işlevsellikte zor değişikliklerle çok hızlı gelişmektedir. Her Scala sürüm yükseltmesi, Flink topluluğu için oldukça büyük bir çaba gerektiren bir süreçti.
+* Scala her zaman Java sınıflarıyla iyi etkileşim kurmaz, örneğin Scala'nın görünürlük kapsamları farklı çalışır ve genellikle Java kullanıcılarına istenilenin ötesinde daha fazla erişim sağlar
+* Scala, artifact/dependency yönetimine ek bir karmaşıklık katmanı ekler.
+ * Runtime'da Akka gibi Scala'ya bağlı kütüphaneleri tutmak isteyebiliriz, ancak bunları bir arayüz aracılığıyla soyutlamak ve ayrı bir classloader'da yüklemek, bunları korumalı tutmak ve sürüm çakışmalarını önlemek için gerekebilir.
+* Scala, bilgili Scala programcılarının, Scala konusunda daha az bilgili programcıların anlaması çok zor olan kodlar yazmasını çok kolaylaştırır. Bu, çeşitli deneyim seviyelerine sahip geniş bir topluluğa sahip bir açık kaynak projesi için özellikle zordur. Bununla başa çıkmak, Scala özellik setini büyük ölçüde kısıtlamak anlamına gelir, bu da Scala'yı kullanmanın asıl amacının önemli bir kısmını engeller.
+
+
+### API Eşitliği
+
+Java API ve Scala API'yi işlevsellik ve kod kalitesi açısından senkronize tutun.
+
+Scala API, Java API'lerinin tüm özelliklerini de kapsamalıdır.
+
+Scala API'leri, DataStream API'den aşağıdaki örnek gibi bir "tamlık testi"ne sahip olmalıdır: [https://github.com/apache/flink/blob/master/flink-streaming-scala/src/test/scala/org/apache/flink/streaming/api/scala/StreamingScalaAPICompletenessTest.scala](https://github.com/apache/flink/blob/master/flink-streaming-scala/src/test/scala/org/apache/flink/streaming/api/scala/StreamingScalaAPICompletenessTest.scala)
+
+
+### Dil Özellikleri
+
+* **Scala implicit'lerinden kaçının.**
+ * Scala'nın implicit'leri sadece Table API expression'ları veya type information extraction gibi kullanıcı odaklı API iyileştirmeleri için kullanılmalıdır.
+ * Bunları dahili "sihir" için kullanmayın.
+* **Class üyeleri için açık tip belirtin.**
+ * Class field'ları ve method dönüş tipleri için implicit tip çıkarımına güvenmeyin:
+
+ **Yapmayın:**
+ ```
+ var expressions = new java.util.ArrayList[String]()
+ ```
+
+ **Yapın:**
+ ```
+ var expressions: java.util.List[String] = new java.util.ArrayList[]()
+ ```
+
+ * Stack'teki yerel değişkenler için tip çıkarımı kullanmak sorun değildir.
+* **Katı görünürlük kullanın.**
+ * Scala'nın paket özel özelliklerinden (private[flink] gibi) kaçının ve bunun yerine normal private/protected kullanın.
+ * `private[flink]` ve `protected` üyelerin Java'da public olduğunu unutmayın.
+ * `private[flink]`'in hala Flink tarafından sağlanan örneklerde tüm üyeleri açığa çıkardığını unutmayın.
+
+
+### Kod Biçimlendirme
+
+**Kodunuzu yapılandırmak için satır kaydırmayı kullanın.**
+
+* Scala'nın fonksiyonel doğası, uzun dönüşüm zincirlerine izin verir (`x.map().map().foreach()`).
+* Geliştiricileri kodlarını yapılandırmaya zorlamak için, satır uzunluğu 100 karakterle sınırlıdır.
+* Daha iyi bakım yapılabilirlik için dönüşüm başına bir satır kullanın.
+
diff --git a/docs/content.tr/how-to-contribute/contribute-code.md b/docs/content.tr/how-to-contribute/contribute-code.md
new file mode 100644
index 0000000000..a9fa54f71d
--- /dev/null
+++ b/docs/content.tr/how-to-contribute/contribute-code.md
@@ -0,0 +1,236 @@
+---
+title: Kod Katkısında Bulunma
+bookCollapseSection: false
+weight: 17
+---
+
+# Kod Katkısında Bulunma
+
+Apache Flink, gönüllülerin kod katkılarıyla bakımı yapılan, geliştirilen ve genişletilen bir projedir. Flink'e yapılan katkıları memnuniyetle karşılıyoruz, ancak projenin büyüklüğü ve kod tabanının yüksek kalitesini korumak için bu belgede açıklanan bir katkı sürecini takip ediyoruz.
+
+**Lütfen istediğiniz zaman soru sormaktan çekinmeyin.** [Geliştirici e-posta listesine]({{< relref "community" >}}#mailing-lists) bir e-posta gönderin veya üzerinde çalıştığınız Jira sorununa yorum yapın.
+
+**ÖNEMLİ**: Kod katkısında bulunmaya başlamadan önce lütfen bu belgeyi dikkatlice okuyun. Aşağıda açıklanan süreci ve yönergeleri izleyin. Apache Flink'e katkıda bulunmak, bir pull request açmakla başlamaz. Katkıda bulunanların önce bizimle iletişime geçerek genel yaklaşımı birlikte tartışmalarını bekliyoruz. Flink committer'ları ile fikir birliği olmadan, katkılar önemli ölçüde yeniden çalışma gerektirebilir veya incelenmeyecektir.
+
+## Ne katkıda bulunacağınızı arıyorsunuz
+
+Katkı için iyi bir fikriniz varsa, [kod katkı sürecine](#code-contribution-process) geçebilirsiniz.
+Neye katkıda bulunabileceğinizi arıyorsanız, [Flink'in hata izleyicisinde]({{< relref "community" >}}#issue-tracker) atanmamış açık Jira sorunlarına göz atabilir ve ardından [kod katkı sürecini](#code-contribution-process) takip edebilirsiniz. Flink projesine çok yeniyseniz ve proje ve katkı süreci hakkında bilgi edinmek istiyorsanız, _starter_ etiketi ile işaretlenmiş [başlangıç sorunlarını](https://issues.apache.org/jira/issues/?filter=12349196) kontrol edebilirsiniz.
+
+## Kod Katkı Süreci
+
+
+
+
+
+
Not: Kod katkı süreci yakın zamanda değişti (Haziran 2019). Topluluk, pull request'lerden Jira'ya "geri basıncı" kaydırmaya
karar verdi . Bu nedenle katkıda bulunanların, pull request açmadan önce fikir birliğine varmaları (bilete atanmaları ile belirtilir) gerekmektedir.
+
+
+
+
+
+
+
+
+
Bir Jira bileti veya e-posta listesi tartışması oluşturun ve fikir birliğine varın
+
Biletin önemi, ilgisi, kapsamı konusunda anlaşın, uygulama yaklaşımını tartışın ve değişikliği incelemeye ve birleştirmeye istekli bir committer bulun.
+
Jira biletlerini yalnızca committer'lar atayabilir.
+
+
+
+
+
+
+
+
Değişikliği }}">Kod Stili ve Kalite Kılavuzu 'na ve Jira biletinde üzerinde anlaşılan yaklaşıma göre uygulayın.
+
Yaklaşım konusunda fikir birliği varsa (örneğin bilet size atanmışsa) uygulamaya başlayın
+
+
+
+
+
+
+
+
Bir pull request açın ve inceleyici ile çalışın.
+
Atanmamış Jira biletlerine ait veya atanan kişi tarafından yazılmamış pull request'ler topluluk tarafından incelenmeyecek veya birleştirilmeyecektir.
+
+
+
+
+
+
+
+
Flink'in bir committer'ı, katkının gereksinimleri karşılayıp karşılamadığını kontrol eder ve kodu kod tabanına birleştirir.
+
+
+
+
+
+
+
+
+
+ Not: Yazım hataları veya sözdizimi hataları gibi önemsiz acil düzeltmeler, Jira bileti olmadan [hotfix]
pull request'i olarak açılabilir.
+
+
+
+
+
+
+
+
+
+### 1. Jira Bileti Oluşturun ve Fikir Birliğine Varın
+
+
+Apache Flink'e katkıda bulunmanın ilk adımı, Flink topluluğuyla fikir birliğine varmaktır. Bu, bir değişikliğin kapsamı ve uygulama yaklaşımı konusunda anlaşmak anlamına gelir.
+
+Çoğu durumda tartışma, [Flink'in hata izleyicisi: Jira]({{< relref "community" >}}#issue-tracker)'da gerçekleşmelidir.
+
+Aşağıdaki değişiklik türleri, [Flink Geliştirici e-posta listesinde]({{< relref "community" >}}#mailing-lists) bir `[DISCUSS]` konusu gerektirir:
+
+- büyük değişiklikler (önemli yeni özellik; büyük yeniden düzenlemeler, birden fazla bileşeni içeren)
+- potansiyel olarak tartışmalı değişiklikler veya konular
+- yaklaşımların belirsiz olduğu veya birden fazla eşit yaklaşımın olduğu değişiklikler
+
+Tartışma bir sonuca varmadan önce bu tür değişiklikler için bir Jira bileti açmayın.
+Bir dev@ tartışmasına dayalı Jira biletlerinin o tartışmaya bağlantı vermesi ve sonucu özetlemesi gerekir.
+
+
+
+**Bir Jira biletinin fikir birliğine varması için gereksinimler:**
+
+- Resmi gereksinimler
+ - *Başlık* sorunu kısaca açıklar.
+ - *Açıklama*, sorunu veya özellik isteğini anlamak için gereken tüm ayrıntıları verir.
+ - *Bileşen* alanı ayarlanmıştır: Birçok committer ve katkıda bulunan sadece Flink'in belirli alt sistemlerine odaklanır. Uygun bileşeni ayarlamak, dikkatlerini çekmek için önemlidir.
+- Biletin geçerli bir sorunu çözdüğü ve Flink için **iyi bir uyum** olduğu konusunda **anlaşma** vardır.
+ Flink topluluğu aşağıdaki hususları göz önünde bulundurur:
+ - Katkı, özellikler veya bileşenlerin davranışını, önceki kullanıcıların programlarını ve kurulumlarını bozabilecek şekilde değiştiriyor mu? Eğer öyleyse, bu değişikliğin arzu edilir olduğu konusunda bir tartışma ve anlaşma olmalıdır.
+ - Katkı kavramsal olarak Flink'e iyi uyuyor mu? Soyutlamaları/API'leri daha karmaşık hale getirecek kadar özel bir durum mu?
+ - Özellik Flink'in mimarisine iyi uyuyor mu? Ölçeklenecek mi ve Flink'i gelecek için esnek tutacak mı, yoksa özellik Flink'i gelecekte kısıtlayacak mı?
+ - Özellik, (mevcut bir parçanın iyileştirilmesinden ziyade) önemli bir yeni eklenti mi? Eğer öyleyse, Flink topluluğu bu özelliği sürdürmeyi taahhüt edecek mi?
+ - Bu özellik, Flink'in yol haritası ve şu anda devam eden çabalarla iyi uyumlu mu?
+ - Özellik, Flink kullanıcıları veya geliştiricileri için katma değer üretiyor mu? Yoksa ilgili kullanıcı veya geliştirici faydası sağlamadan regresyon riski mi getiriyor?
+ - Katkı, örneğin Apache Bahir veya başka bir harici depoda yaşayabilir mi?
+ - Bu, sadece açık kaynaklı bir projede commit almak için yapılan bir katkı mı (yazım hatalarını düzeltme, sadece zevk için stil değişiklikleri yapma)
+- Sorunun nasıl çözüleceği konusunda **fikir birliği** vardır. Bu, aşağıdaki hususları içerir:
+ - API ve veri geriye dönük uyumluluğu ve geçiş stratejileri
+ - Test stratejileri
+ - Flink'in derleme süresi üzerindeki etki
+ - Bağımlılıklar ve lisansları
+
+Eğer bir değişiklik Jira'daki tartışmada büyük veya tartışmalı bir değişiklik olarak tanımlanırsa, anlaşma ve fikir birliğine varmak için bir [Flink İyileştirme Önerisi (FLIP)](https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals) veya [Geliştirici e-posta listesinde]({{< relref "community" >}}#mailing-lists) bir tartışma gerektirebilir.
+
+Katkıda bulunanlar, bileti açtıktan sonra birkaç gün içinde bir committer'dan ilk tepkiyi alabilirler. Eğer bir bilet dikkat çekmezse, [geliştirici e-posta listesine]({{< relref "community" >}}#mailing-lists) ulaşmanızı öneririz. Flink topluluğunun bazen gelen tüm katkıları kabul etme kapasitesi olmadığını unutmayın.
+
+
+Biletin tüm gereksinimleri karşılandığında, bir committer üzerinde çalışması için birini biletin *`Assignee`* alanına atayacaktır.
+Yalnızca committer'ların birini atama izni vardır.
+
+**Atanmamış Jira biletlerine ait pull request'ler topluluk tarafından incelenmeyecek veya birleştirilmeyecektir**.
+
+
+
+
+### 2. Değişikliğinizi uygulayın
+
+Bir Jira sorununa atandıktan sonra, gerekli değişiklikleri uygulamaya başlayabilirsiniz.
+
+Uygulama sırasında akılda tutulması gereken bazı diğer noktalar:
+
+- [Bir Flink geliştirme ortamı kurun](https://cwiki.apache.org/confluence/display/FLINK/Setting+up+a+Flink+development+environment)
+- Flink'in [Kod Stili ve Kalite Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-preamble" >}})'nu takip edin
+- Jira sorunu veya tasarım belgesindeki tüm tartışmaları ve gereksinimleri dikkate alın.
+- İlgisiz sorunları tek bir katkıda karıştırmayın.
+
+
+
+
+### 3. Bir Pull Request Açın
+
+Pull request açmadan önce dikkat edilmesi gerekenler:
+
+- Tüm kontrollerin geçtiğinden, kodun derlendiğinden ve tüm testlerin geçtiğinden emin olmak için **`mvn clean verify`** komutunun değişikliklerinizde başarıyla çalıştığından emin olun.
+- [Flink'in Uçtan Uca testlerini](https://github.com/apache/flink/tree/master/flink-end-to-end-tests#running-tests) çalıştırın.
+- İlgisiz veya gereksiz yeniden biçimlendirme değişikliklerinin dahil edilmediğinden emin olun.
+- Commit geçmişinizin gereksinimlere uyduğundan emin olun.
+- Değişikliğinizin taban dalınızdaki en son commit'lere yeniden yazıldığından emin olun.
+- Pull request'in ilgili Jira'ya atıfta bulunduğundan ve her Jira sorununun tam olarak bir pull request'e atandığından emin olun (bir Jira için birden fazla pull request varsa, önce bu durumu çözün)
+
+Pull request açmadan önce veya açtıktan hemen sonra dikkate alınması gerekenler:
+
+- Dalın [Azure DevOps](https://dev.azure.com/apache-flink/apache-flink/_build?definitionId=2) üzerinde başarıyla oluşturulduğundan emin olun.
+
+Flink'teki kod değişiklikleri, [GitHub pull request'leri](https://help.github.com/en/articles/creating-a-pull-request) aracılığıyla incelenir ve kabul edilir.
+
+[Bir pull request'i nasıl inceleyeceğiniz]({{< relref "how-to-contribute/reviewing-prs" >}}) konusunda, pull request inceleme sürecimizi de içeren ayrı bir kılavuz bulunmaktadır. Kod yazarı olarak, pull request'inizi tüm gereksinimleri karşılayacak şekilde hazırlamalısınız.
+
+
+
+### 4. Değişikliği birleştirin
+
+İnceleme tamamlandıktan sonra kod, Flink'in bir committer'ı tarafından birleştirilecektir. Ardından Jira bileti kapatılacaktır.
+
diff --git a/docs/content.tr/how-to-contribute/contribute-documentation.md b/docs/content.tr/how-to-contribute/contribute-documentation.md
new file mode 100644
index 0000000000..efabac607b
--- /dev/null
+++ b/docs/content.tr/how-to-contribute/contribute-documentation.md
@@ -0,0 +1,69 @@
+---
+title: Dokümantasyona Katkıda Bulunma
+bookCollapseSection: false
+weight: 20
+---
+
+# Dokümantasyona Katkıda Bulunma
+
+İyi bir dokümantasyon, her türlü yazılım için çok önemlidir. Bu, özellikle Apache Flink gibi dağıtık veri işleme motorları olan karmaşık yazılım sistemleri için geçerlidir. Apache Flink topluluğu, özlü, kesin ve eksiksiz dokümantasyon sağlamayı amaçlar ve Apache Flink'in dokümantasyonunu iyileştirmeye yönelik her türlü katkıyı memnuniyetle karşılar.
+
+## Dokümantasyon kaynaklarını edinme
+
+Apache Flink'in dokümantasyonu, kod tabanı ile aynı [git](http://git-scm.com/) deposunda tutulur. Bu, kod ve dokümantasyonun kolayca senkronize tutulabilmesini sağlamak için yapılır.
+
+Dokümantasyona katkıda bulunmanın en kolay yolu, [GitHub'daki Flink'in yansıtılmış deposunu](https://github.com/apache/flink) sağ üst köşedeki fork düğmesine tıklayarak kendi GitHub hesabınıza fork etmektir. GitHub hesabınız yoksa, ücretsiz olarak bir tane oluşturabilirsiniz.
+
+Ardından, fork'unuzu yerel makinenize klonlayın.
+
+```
+git clone https://github.com//flink.git
+```
+
+Dokümantasyon, Flink kod tabanının `docs/` alt dizininde bulunur.
+
+## Dokümantasyon üzerinde çalışmaya başlamadan önce...
+
+...lütfen katkınıza karşılık gelen bir [Jira](https://issues.apache.org/jira/browse/FLINK) sorunu olduğundan emin olun. Yazım hataları gibi önemsiz düzeltmeler dışında, tüm dokümantasyon değişikliklerinin bir Jira sorununa atıfta bulunmasını gerektiriyoruz.
+
+Ayrıca, erişilebilir, tutarlı ve kapsayıcı dokümantasyon yazma konusunda bazı rehberlik için [Dokümantasyon Stil Kılavuzu]({{< relref "how-to-contribute/documentation-style-guide" >}}) sayfasına göz atın.
+
+## Dokümantasyonu güncelleme veya genişletme
+
+Flink dokümantasyonu [Markdown](http://daringfireball.net/projects/markdown/) ile yazılmıştır. Markdown, HTML'ye çevrilebilen hafif bir işaretleme dilidir.
+
+Dokümantasyonu güncellemek veya genişletmek için Markdown (`.md`) dosyalarını değiştirmeniz gerekir. Lütfen değişikliklerinizi, yapım komut dosyasını önizleme modunda başlatarak doğrulayın.
+
+```
+./build_docs.sh -p
+```
+
+Bu komut dosyası, Markdown dosyalarını statik HTML sayfalarına derler ve yerel bir web sunucusu başlatır. Derlenen dokümantasyonu değişikliklerinizle birlikte görüntülemek için tarayıcınızı `http://localhost:1313/` adresinde açın. Markdown dosyalarını değiştirip kaydettiğinizde ve tarayıcınızı yenilediğinizde, sunulan dokümantasyon otomatik olarak yeniden derlenir ve güncellenir.
+
+Lütfen geliştirici e-posta listesinde her türlü sorunuzu sormaktan çekinmeyin.
+
+## Çince dokümantasyon çevirisi
+
+Flink topluluğu hem İngilizce hem de Çince dokümantasyonu sürdürmektedir. Dokümantasyonu güncellemek veya genişletmek istiyorsanız, hem İngilizce hem de Çince dokümantasyon güncellenmelidir. Çince diline aşina değilseniz, lütfen mevcut JIRA sorunuyla bağlantılı olarak Çince dokümantasyon çevirisi için `chinese-translation` bileşeni ile etiketlenmiş bir JIRA açın. Çince diline aşina iseniz, her iki tarafı da bir pull request'te güncellemeniz teşvik edilir.
+
+*NOT: Flink topluluğu hala Çince dokümantasyonları çevirme sürecindedir, bazı belgeler henüz çevrilmemiş olabilir. Güncellediğiniz belge henüz çevrilmemişse, İngilizce değişiklikleri Çince belgeye kopyalayabilirsiniz.*
+
+Çince belgeler `content.zh/docs` klasöründe bulunmaktadır. İngilizce belge değişikliklerine göre `content.zh/docs` klasöründeki Çince dosyayı güncelleyebilir veya genişletebilirsiniz.
+
+## Katkınızı gönderme
+
+Flink projesi, dokümantasyon katkılarını [GitHub Mirror](https://github.com/apache/flink) üzerinden [Pull Request'ler](https://help.github.com/articles/using-pull-requests) olarak kabul eder. Pull request'ler, değişiklikleri içeren bir kod dalına işaret ederek yama sunmanın basit bir yoludur.
+
+Bir pull request hazırlamak ve göndermek için şu adımları izleyin.
+
+1. Değişikliklerinizi yerel git deponuza commit edin. Commit mesajı, ilgili Jira sorununa `[FLINK-XXXX]` ile başlayarak işaret etmelidir.
+
+2. Commit edilen katkınızı GitHub'daki Flink depo fork'unuza push edin.
+
+ ```
+ git push origin myBranch
+ ```
+
+3. Depo fork'unuzun web sitesine gidin (`https://github.com//flink`) ve pull request oluşturmaya başlamak için "Create Pull Request" düğmesini kullanın. Temel fork'un `apache/flink master` olduğundan ve head fork'un değişikliklerinizi içeren dalı seçtiğinden emin olun. Pull request'e anlamlı bir açıklama verin ve gönderin.
+
+Bir yamayı bir [Jira]({{< param FlinkIssuesUrl >}}) sorununa eklemek de mümkündür.
diff --git a/docs/content.tr/how-to-contribute/documentation-style-guide.md b/docs/content.tr/how-to-contribute/documentation-style-guide.md
new file mode 100644
index 0000000000..0dc15f24dd
--- /dev/null
+++ b/docs/content.tr/how-to-contribute/documentation-style-guide.md
@@ -0,0 +1,366 @@
+---
+title: Dokümantasyon Stil Kılavuzu
+bookCollapseSection: false
+weight: 21
+---
+
+# Dokümantasyon Stil Kılavuzu
+
+Bu kılavuz, Flink dokümantasyonunu yazma ve katkıda bulunma konusunda temel stil kurallarına genel bir bakış sağlar. Mevcut dokümantasyonu iyileştirme ve genişletme konusundaki topluluk çabasına katkı yolculuğunuzu desteklemek ve dokümantasyonu daha **erişilebilir**, **tutarlı** ve **kapsayıcı** hale getirmeye yardımcı olmak amacıyla hazırlanmıştır.
+
+## Dil
+
+Flink dokümantasyonu **ABD İngilizcesi** ve **Çince** dillerinde sürdürülür — dokümantasyonu genişletirken veya güncellerken, her iki sürüm de tek bir pull request ile ele alınmalıdır. Çince diline aşina değilseniz, katkınızın şu ek adımlarla tamamlandığından emin olun:
+
+* [JIRA]({{< relref "community" >}}#issue-tracker) üzerinde chinese-translation bileşeni ile etiketlenmiş bir çeviri bileti açın;
+* Bileti orijinal katkı JIRA biletine bağlayın.
+
+Mevcut dokümantasyonu Çince'ye çevirmeye katkıda bulunmak için stil kılavuzları mı arıyorsunuz? [Bu çeviri şartnamesine](https://cwiki.apache.org/confluence/display/FLINK/Flink+Translation+Specifications) danışabilirsiniz.
+
+## Dil Stili
+
+Aşağıda, yazılarınızda okunabilirliği ve erişilebilirliği sağlamaya yardımcı olabilecek bazı temel kurallar bulabilirsiniz. Dil stili hakkında daha derin ve eksiksiz bir inceleme için [Genel Yönlendirici İlkeler](#genel-yönlendirici-i̇lkeler) bölümüne de bakın.
+
+### Ses ve Ton
+
+* **Etken çatı kullanın.** [Etken çatı](https://medium.com/@DaphneWatson/technical-writing-active-vs-passive-voice-485dfaa4e498), kısalığı destekler ve içeriği daha çekici hale getirir. Bir cümledeki fiilin ardından _zombiler tarafından_ ifadesini eklerseniz ve hala mantıklı oluyorsa, edilgen çatı kullanıyorsunuz demektir.
+
+ * **Etken Çatı**
+ "Bu örneği IDE'nizde veya komut satırında çalıştırabilirsiniz."
+ * **Edilgen Çatı**
+ "Bu örnek, IDE'nizde veya komut satırında çalıştırılabilir (zombiler tarafından)."
+
+* **Biz değil, siz kullanın.** _Biz_ kullanmak bazı kullanıcılar için kafa karıştırıcı ve küçümseyici olabilir, "hepimiz gizli bir kulübün üyesiyiz ve _sen_ bir üyelik daveti almadın" izlenimi verebilir. Kullanıcıya _siz_ olarak hitap edin.
+
+* **Cinsiyet ve kültüre özgü dilden kaçının.** Dokümantasyonda cinsiyet belirtmeye gerek yoktur: teknik yazı [cinsiyet açısından nötr](https://techwhirl.com/gender-neutral-technical-writing/) olmalıdır. Ayrıca, kendi dilinizde veya kültürünüzde doğal kabul ettiğiniz jargon ve gelenekler, başka yerlerde genellikle farklıdır. Mizah bunun tipik bir örneğidir: bir kültürde harika bir şaka, başka bir kültürde yanlış anlaşılabilir.
+
+* **Eylemleri nitelendirmekten ve önyargılı değerlendirmelerden kaçının.** Bir eylemi tamamlamakta zorlanan veya hayal kırıklığına uğrayan bir kullanıcı için _hızlı_ veya _kolay_ gibi kelimeler kullanmak, kötü bir dokümantasyon deneyimine yol açabilir.
+
+* **İfadeleri vurgulamak için BÜYÜK HARFLER kullanmaktan kaçının.** Anahtar kelimeleri **kalın** veya _italik_ yazı tipini kullanarak vurgulamak genellikle daha nazik görünür. Önemli ancak açık olmayan ifadelere dikkat çekmek istiyorsanız, bunları uygun bir HTML etiketi ile vurgulanan bir etiketle başlayan ayrı paragraflara gruplamayı deneyin:
+ * `Not `
+ * `Uyarı `
+ * `Tehlike `
+
+### Flink'e Özgü Terimleri Kullanma
+
+Terimlerin net tanımlarını kullanın veya bir şeyin ne anlama geldiği konusunda, diğer dokümantasyon sayfaları veya {{< docs_link file="flink-docs-stable/docs/concepts/glossary" name="Flink Sözlüğü">}} gibi yararlı kaynaklara bağlantı ekleyerek ek talimatlar sağlayın. Sözlük hala geliştirilme aşamasındadır, bu nedenle bir pull-request açarak yeni terimler de önerebilirsiniz.
+
+## Depo
+
+Markdown dosyaları (.md), kapsanan konuyu özetleyen, **küçük harfle** yazılmış ve kelimeler arasında **tire (-)** ile ayrılmış kısa bir isme sahip olmalıdır. Çince sürüm dosyı, İngilizce sürümle aynı isme sahip olmalı, ancak **content.zh** klasöründe saklanmalıdır.
+
+## Sözdizimi
+
+Dokümantasyon web sitesi [Hugo](https://gohugo.io/) kullanılarak oluşturulur ve sayfalar, web yayıncılığı için hafif taşınabilir bir format olan (ancak bununla sınırlı olmayan) [Markdown](https://daringfireball.net/projects/markdown/syntax) ile yazılır.
+
+### Genişletilmiş Sözdizimi
+
+Markdown ayrıca [GitHub Flavored Markdown](https://guides.github.com/features/mastering-markdown/) ve düz [HTML](http://www.simplehtmlguide.com/cheatsheet.php) ile birlikte de kullanılabilir. Örneğin, bazı katkıda bulunanlar görüntüler için HTML etiketleri kullanmayı tercih eder ve bu karışımı serbestçe kullanabilirler.
+
+### Ön Kısım (Front Matter)
+
+Markdown'a ek olarak, her dosya, sayfada değişkenleri ve meta verileri ayarlamak için kullanılacak bir YAML [ön kısım bloğu](https://jekyllrb.com/docs/front-matter/) içerir. Ön kısım, dosyadaki ilk şey olmalı ve üçlü çizgili satırlar arasında geçerli bir YAML kümesi olarak belirtilmelidir.
+
+### Apache Lisansı
+
+Her dokümantasyon dosyası için, ön kısımdan hemen sonra Apache Lisansı ifadesi gelmelidir. Her iki dil sürümü için de bu blok ABD İngilizcesinde belirtilmeli ve aşağıdaki örnekteki ile tam olarak aynı kelimelerle kopyalanmalıdır.
+
+
+```
+---
+title: Concepts
+layout: redirect
+---
+
+```
+
+Aşağıda, Flink dokümantasyonunda en yaygın kullanılan ön kısım değişkenleri bulunmaktadır.
+
+
+
+
+
+
+ Değişken
+ Olası Değerler
+ Açıklama
+
+
+ Layout
+ layout
+ {base,plain,redirect}
+ Kullanılacak düzen dosyası. Düzen dosyaları _layouts dizini altında bulunur.
+
+
+ İçerik
+ title
+ %s
+ Sayfa için en üst düzey (Seviye-1) başlık olarak kullanılacak başlık.
+
+
+ Navigasyon
+ nav-id
+ %s
+ Sayfanın ID'si. Diğer sayfalar bu ID'yi nav-parent_id olarak kullanabilir.
+
+
+ nav-parent_id
+ {root,%s}
+ Üst sayfanın ID'si. En düşük navigasyon seviyesi root'tur.
+
+
+ nav-pos
+ %d
+ Navigasyon seviyesi başına sayfaların göreceli konumu.
+
+
+ nav-title
+ %s
+ Varsayılan bağlantı metnini (başlık) geçersiz kılmak için kullanılacak başlık.
+
+
+
+
+
+`_config.yml` altında bulunan dokümantasyon genelindeki bilgiler ve yapılandırma ayarları da site değişkeni aracılığıyla ön kısma sunulur. Bu ayarlara aşağıdaki sözdizimi kullanılarak erişilebilir:
+
+```liquid
+{{ "{{ site.CONFIG_KEY " }}}}
+```
+Yer tutucu, dokümantasyon oluşturulurken `CONFIG_KEY` adlı değişkenin değeriyle değiştirilecektir.
+
+## Biçimlendirme
+
+Aşağıdaki bölümlerde, tutarlı ve gezinmesi kolay dokümantasyon yazma konusunda sizi başlatacak temel biçimlendirme kuralları listelenmiştir.
+
+### Başlıklar
+
+Markdown'da başlıklar, başında diyez işareti (#) olan herhangi bir satırdır; diyez sayısı başlık düzeyini gösterir. Başlıklar iç içe ve ardışık olmalıdır — stil nedeniyle asla bir başlık düzeyini atlamayın!
+
+
+
+
+
+ Sözdizimi
+ Seviye
+ Açıklama
+
+
+ # Başlık
+ Seviye-1
+ Sayfa başlığı Ön Kısımda tanımlanır, bu nedenle bu seviye kullanılmamalıdır .
+
+
+ ## Başlık
+ Seviye-2
+ Bölümler için başlangıç seviyesi. İçeriği daha yüksek düzeydeki konulara veya hedeflere göre düzenlemek için kullanılır.
+
+
+ ### Başlık
+ Seviye-3
+ Alt bölümler. Destekleyici bilgileri veya görevleri ayırmak için her Bölümde kullanılır.
+
+
+ #### Başlık
+ Seviye-4
+
+
+
+
+
+#### En İyi Uygulama
+
+Başlıkların ifadesinde açıklayıcı bir dil kullanın. Örneğin, dinamik tablolar hakkında bir dokümantasyon sayfası için, "Arka Plan" veya "Teknik Bilgi" yerine "Dinamik Tablolar ve Sürekli Sorgular" daha açıklayıcıdır.
+
+### İçindekiler
+
+Dokümantasyon oluşturulurken, **İçindekiler** (TOC) otomatik olarak aşağıdaki işaretleme satırı kullanılarak sayfanın başlıklarından oluşturulur:
+
+```liquid
+{{ "{:toc" }}}
+```
+
+**Seviye-3**'e kadar tüm başlıklar dikkate alınır. Belirli bir başlığı TOC'den hariç tutmak için:
+
+```liquid
+{{ "# Hariç Tutulan Başlık
+{:.no_toc" }}}
+```
+
+#### En İyi Uygulama
+
+Ele alınan konuya kısa ve öz bir giriş yazın ve bunu TOC'den önce yerleştirin. Temel mesajların bir taslağı gibi küçük bir bağlam, dokümantasyonun tutarlı olmasını ve her bilgi seviyesindeki kişiler tarafından anlaşılabilir olmasını sağlamada uzun bir yol kat eder.
+
+
+### Navigasyon
+
+Dokümantasyon oluşturulurken, navigasyon her sayfanın [ön kısım değişkenleri](#ön-kısım-front-matter) içinde yapılandırılan özellikler kullanılarak tanımlanır.
+
+Kapsamlı dokümantasyon sayfalarında, kullanıcıların manuel olarak yukarı kaydırmadan sayfanın başına gidebilmelerini sağlayan _Başa Dön_ bağlantıları kullanmak mümkündür. İşaretlemede bu, dokümantasyon oluşturulduğunda varsayılan bir bağlantı ile değiştirilen bir yer tutucu olarak uygulanır:
+
+```liquid
+{{ "{% top " }}%}
+```
+
+#### En İyi Uygulama
+
+Başa Dön bağlantılarını en azından her Seviye-2 bölümünün sonunda kullanmanız önerilir.
+
+### Açıklamalar
+
+Dokümantasyona uç durumları, sıkı ilişkili bilgileri veya bilinmesi güzel bilgileri dahil etmek istediğinizde, bunları özel açıklamalar kullanarak vurgulamak çok iyi bir uygulamadır.
+
+* Yararlı olabilecek bir ipucu veya bilgi parçasını vurgulamak için:
+
+ ```html
+ // Bilgi Mesajı
+ ```
+
+* Tuzakların tehlikesini bildirmek veya takip edilmesi kritik öneme sahip önemli bir bilgi parçasına dikkat çekmek için:
+
+ ```html
+ // Tehlike Mesajı
+ ```
+
+### Bağlantılar
+
+Dokümantasyona bağlantılar eklemek, kullanıcıyı üzerine yazma riski olmadan konuyu daha iyi anlamasına yönlendirmenin etkili bir yoludur.
+
+* **Sayfadaki bölümlere bağlantılar.** Her başlık, bir sayfa içinde doğrudan bağlantı vermek için örtük bir tanımlayıcı oluşturur. Bu tanımlayıcı, başlığı küçük harfe çevirerek ve iç boşlukları kısa çizgilerle değiştirerek oluşturulur.
+
+ * **Başlık:** ## Başlık Adı
+ * **ID:** #başlık-adı
+
+
+ ```liquid
+ [Bağlantı Metni](#başlık-adı)
+ ```
+
+* **Flink dokümantasyonunun diğer sayfalarına bağlantılar.**
+
+ ```liquid
+ [Bağlantı Metni]({% link path/to/link-page.md %})
+ ```
+
+* **Harici sayfalara bağlantılar**
+
+ ```liquid
+ [Bağlantı Metni](external_url)
+ ```
+
+#### En İyi Uygulama
+
+Eylem veya hedef hakkında bilgi veren açıklayıcı bağlantılar kullanın. Örneğin, "Daha Fazla Bilgi" veya "Buraya Tıklayın" bağlantıları kullanmaktan kaçının.
+
+### Görsel Öğeler
+
+Şekiller ve diğer görsel öğeler kök _fig_ klasörü altına yerleştirilir ve dokümantasyon sayfalarında bağlantılara benzer bir sözdizimi kullanılarak referans gösterilebilir:
+
+```liquid
+{{< img src="/fig/image_name.png" alt="Resim Metni" width="200px" >}}
+```
+
+#### En İyi Uygulama
+
+Akış şemaları, tablolar ve şekilleri uygun veya gerekli olduğunda ek açıklama için kullanın, ancak asla tek başına bilgi kaynağı olarak kullanmayın. Bu öğelere dahil edilen herhangi bir metnin okunabilecek kadar büyük olduğundan ve genel çözünürlüğün yeterli olduğundan emin olun.
+
+### Kod
+
+* **Satır içi kod.** Normal metin akışında küçük kod parçaları veya dil yapılarına referanslar çevreleyen ters tırnak işaretleriyle ( **\`** ) vurgulanmalıdır.
+
+* **Kod blokları.** Kendi başına yeterli örnekleri, özellik tanıtımlarını, en iyi uygulamaların gösterimini veya diğer yararlı senaryoları temsil eden kod, uygun [sözdizimi vurgulaması](https://github.com/rouge-ruby/rouge/wiki/List-of-supported-languages-and-lexers) ile çevrili bir kod bloğu kullanılarak sarılmalıdır. Bunu işaretleme ile elde etmenin bir yolu:
+
+ ````liquid
+ ```java
+ // Java Kodu
+ ```
+ ````
+
+Birden fazla programlama dili belirtirken, her kod bloğu bir sekme olarak şekillendirilmelidir:
+
+ ```html
+
+
+
+
+ ```java
+ // Java Kodu
+ ```
+
+
+
+
+
+ ```scala
+ // Scala Kodu
+ ```
+
+
+
+
+ ```
+
+Bu kod blokları genellikle öğrenmek ve keşfetmek için kullanılır, bu nedenle akılda tutulması gereken bazı en iyi uygulamalar vardır:
+
+* **Anahtar geliştirme görevlerini sergileyin.** Kod örneklerini, kullanıcılar için anlamlı olan yaygın uygulama senaryoları için saklayın. Daha uzun ve karmaşık örnekleri öğreticiler veya adım adım kılavuzlar için bırakın.
+
+* **Kodun bağımsız olduğundan emin olun.** Kod örnekleri kendi kendine yeterli olmalı ve harici bağımlılıklara sahip olmamalıdır (belirli konnektörlerin nasıl kullanılacağına ilişkin örnekler gibi aykırı durumlar hariç). Joker karakterler kullanmadan tüm import ifadelerini dahil edin, böylece yeni başlayanlar hangi paketlerin kullanıldığını anlayabilir ve öğrenebilir.
+
+* **Kısayollardan kaçının.** Örneğin, gerçek dünya kodunda yapacağınız gibi istisnaları ve temizleme işlemlerini ele alın.
+
+* **Yorumlar ekleyin, ancak abartmayın.** Kodun ana işlevselliğini ve okunmasından açık olmayabilecek olası tuzakları açıklayan bir giriş sağlayın. Uygulama ayrıntılarını açıklamak ve beklenen çıktıyı tanımlamak için yorumlar kullanın.
+
+* **Kod bloklarındaki komutlar.** Komutlar, `bash` sözdizimi vurgulanan kod blokları kullanılarak belgelenebilir. Dokümantasyona komut eklerken aşağıdaki hususlar dikkate alınmalıdır:
+ * **Uzun parametre adları kullanın.** Uzun parametre adları, okuyucunun komutun amacını anlamasına yardımcı olur. Bunlar, kısa muadillerine göre tercih edilmelidir.
+ * **Satır başına bir parametre.** Uzun parametre adları kullanmak, komutu okumayı muhtemelen zorlaştırır. Her satıra bir parametre koymak okunabilirliği artırır. Kopyala ve yapıştır işlemini desteklemek için her ara satırın sonunda satır sonunu belirten bir ters eğik çizgi `\` eklemeniz gerekir.
+ * **Girinti**. Each new parameter line should be indented by 6 spaces.
+ * **Komut başlangıcını belirtmek için `$` öneki kullanın**. Birden fazla komut olduğunda kod bloğunun okunabilirliği kötüleşebilir. Her yeni komutun önüne dolar işareti `$` koymak bir komutun başlangıcını belirlemeye yardımcı olur.
+
+ Doğru biçimlendirilmiş bir komut şöyle görünür:
+
+```bash
+$ ./bin/flink run-application \
+--target kubernetes-application \
+-Dkubernetes.cluster-id=my-first-application-cluster \
+-Dkubernetes.container.image=custom-image-name \
+local:///opt/flink/usrlib/my-flink-job.jar
+```
+
+## Genel Yönlendirici İlkeler
+
+Bu stil kılavuzu, **Erişilebilir**, **Tutarlı**, **Nesnel**, **Mantıklı** ve **Kapsayıcı** dokümantasyon için temel oluşturma gibi kapsayıcı bir amaca sahiptir.
+
+#### Erişilebilir
+
+Flink topluluğu çeşitli ve uluslararasıdır, bu nedenle dokümantasyon yazarken geniş ve küresel düşünmeniz gerekir. Herkes İngilizceyi anadil düzeyinde konuşmaz ve Flink (ve genel olarak stream processing) ile ilgili deneyim seviyesi mutlak yeni başlayanlardan deneyimli ileri düzey kullanıcılara kadar değişir. Ürettiğiniz içerikte teknik doğruluğu ve dilsel netliği sağlayın, böylece tüm kullanıcılar tarafından anlaşılabilsin.
+
+#### Tutarlı
+
+Bu stil kılavuzunda detaylandırılan temel kurallara bağlı kalın ve metni yazım, büyük harf kullanımı, kısa çizgi kullanımı, kalın ve italik yazma konusunda aynı şekilde biçimlendirmek için kendi en iyi yargınızı kullanın. Doğru dilbilgisi, noktalama ve yazım arzu edilir, ancak sert bir gereklilik değildir — dokümantasyon katkıları her düzeyde dil yeterliliğine açıktır.
+
+#### Nesnel
+
+Cümlelerinizi kısa ve öz tutun. Bir kural olarak, eğer bir cümle 14 kelimeden kısaysa, okuyucular muhtemelen içeriğinin yüzde 90'ını anlayacaktır. 25'ten fazla kelime içeren cümleler genellikle anlaşılması daha zordur ve mümkün olduğunda gözden geçirilmeli ve bölünmelidir. Kısa ve öz olmak ve iyi bilinen anahtar kelimeler kullanmak, kullanıcıların ilgili dokümantasyona az çabayla ulaşmalarını sağlar.
+
+#### Mantıklı
+
+Çoğu kullanıcının çevrimiçi içeriği tarayacağını ve sadece [yüzde 28'ini](https://www.nngroup.com/articles/website-reading/) okuyacağını unutmayın. Bu, ilgili fikirleri açık bir bilgi hiyerarşisinde bir araya getirmenin ve odaklanmış, açıklayıcı başlıklar kullanmanın önemini vurgular. Her bölümün ilk iki paragrafına en ilgili bilgileri yerleştirmek, kullanıcı için "harcanan zamanın geri dönüşünü" artıran iyi bir uygulamadır.
+
+#### Kapsayıcı
+
+İçeriğin tüm kullanıcılar tarafından bulunabilir ve onlara açık olmasını sağlamak için olumlu bir dil ve somut, ilişkilendirilebilir örnekler kullanın. Dokümantasyon diğer dillere çevrilir, bu nedenle basit bir dil ve tanıdık kelimeler kullanmak çeviri çabasını da azaltmaya yardımcı olur.
\ No newline at end of file
diff --git a/docs/content.tr/how-to-contribute/getting-help.md b/docs/content.tr/how-to-contribute/getting-help.md
new file mode 100644
index 0000000000..c55d33ed94
--- /dev/null
+++ b/docs/content.tr/how-to-contribute/getting-help.md
@@ -0,0 +1,149 @@
+---
+title: Yardım Alma
+bookCollapseSection: false
+weight: 25
+aliases:
+- /getting-help.html
+- /getting-help/index.html
+
+---
+
+
+# Yardım Alma
+
+## Bir Sorunuz mu Var?
+
+Apache Flink topluluğu her gün birçok kullanıcı sorusunu yanıtlar. Arşivlerde yanıt ve tavsiye arayabilir veya yardım ve rehberlik için toplulukla iletişime geçebilirsiniz.
+
+### Kullanıcı E-posta Listesi
+
+Birçok Flink kullanıcısı, katkıda bulunan ve committer, Flink'in kullanıcı e-posta listesine abonedir. Kullanıcı e-posta listesi, yardım istemek için çok iyi bir yerdir.
+
+E-posta listesine göndermeden önce, aşağıdaki web sitelerinde sizin sorunlarınızla ilgili konuları tartışan e-posta dizilerini aramak için e-posta listesi arşivlerini arayabilirsiniz.
+
+- [Apache E-posta Listesi Arşivi](https://lists.apache.org/list.html?user@flink.apache.org)
+
+E-posta listesine göndermek istiyorsanız, şunları yapmanız gerekir:
+
+1. `user-subscribe@flink.apache.org` adresine bir e-posta göndererek e-posta listesine abone olun,
+2. Onay e-postasını yanıtlayarak aboneliği onaylayın ve
+3. E-postanızı `user@flink.apache.org` adresine gönderin.
+
+Abone değilseniz e-postanıza yanıt alamayacağınızı lütfen unutmayın.
+
+### Slack
+
+[Slack'teki Apache Flink topluluğuna katılabilirsiniz.]({{< param FlinkSlackInviteUrl >}})
+Slack'te bir hesap oluşturduktan sonra, #introductions kanalında kendinizi tanıtmayı unutmayın.
+Slack'in sınırlamaları nedeniyle davet bağlantısı 100 davetten sonra süresi dolar. Süresi dolmuşsa, lütfen [Dev e-posta listesi]({{< relref "community" >}}#mailing-lists) ile iletişime geçin.
+Herhangi bir mevcut Slack üyesi de başka herhangi birini katılmaya davet edebilir.
+
+Birkaç topluluk kuralı vardır:
+
+* **Saygılı olun** - Bu en önemli kuraldır!
+* Tüm önemli kararlar ve sonuçlar **e-posta listelerine yansıtılmalıdır.**
+ "Eğer bir e-posta listesinde olmadıysa, olmamıştır." - [Apache Motto'ları](http://theapacheway.com/on-list/)
+* Paralel konuşmaların bir kanalı bunaltmasını önlemek için **Slack dizilerini** kullanın.
+* Ya [#pyflink](https://apache-flink.slack.com/archives/C03G7LJTS2G) (tüm Python Flink soruları için) ya da [#troubleshooting](https://apache-flink.slack.com/archives/C03G7LJTS2G) (diğer tüm Flink soruları için) kullanın.
+* Sorun giderme, Jira atama ve PR incelemesi için lütfen insanlara **doğrudan mesaj göndermeyin**. Bunu yapmak Slack'ten çıkarılmanıza neden olabilir.
+
+### Stack Overflow
+
+Flink topluluğunun birçok üyesi [Stack Overflow](https://stackoverflow.com)'da aktiftir. [\[apache-flink\]](https://stackoverflow.com/questions/tagged/apache-flink) etiketini kullanarak sorular ve cevaplar arayabilir veya sorularınızı gönderebilirsiniz.
+
+## Bir Hata mı Buldunuz?
+
+Bir hata nedeniyle oluşabilecek beklenmeyen bir davranış gözlemlerseniz, bildirilmiş hataları arayabilir veya [Flink'in JIRA'sında]({{< relref "community#issue-tracker" >}}) bir hata raporu oluşturabilirsiniz.
+
+Beklenmeyen davranışın bir hata nedeniyle mi oluştuğundan emin değilseniz, lütfen [kullanıcı e-posta listesine]({{< relref "community" >}}#user-mailing-list) bir soru gönderin.
+
+## Bir Hata Mesajı mı Aldınız?
+
+Bir hata mesajının nedenini belirlemek zor olabilir. Aşağıda, en yaygın hata mesajlarını listeliyor ve bunları nasıl ele alacağınızı açıklıyoruz.
+
+### NotSerializableException hatası alıyorum.
+
+Flink, uygulama mantığının kopyalarını (uyguladığınız fonksiyonlar ve işlemler, program yapılandırması vb.) paralel çalışan işlemlere dağıtmak için Java serileştirmesini kullanır. Bu nedenle, API'ye aktardığınız tüm fonksiyonlar, [java.io.Serializable](http://docs.oracle.com/javase/8/docs/api/java/io/Serializable.html) tarafından tanımlandığı gibi serileştirilebilir olmalıdır.
+
+Fonksiyonunuz anonim bir iç sınıfsa, şunları düşünün:
+
+- Fonksiyonu bağımsız bir sınıf veya statik bir iç sınıf haline getirin.
+- Java 8 lambda fonksiyonu kullanın.
+
+Fonksiyonunuz zaten statik bir sınıfsa, sınıfın bir örneğini oluşturduğunuzda atadığınız alanları kontrol edin. Alanlardan biri büyük olasılıkla serileştirilemeyen bir türü tutuyor.
+
+- Java'da, bir `RichFunction` kullanın ve sorunlu alanları `open()` metodunda başlatın.
+- Scala'da, genellikle başlatmayı dağıtılmış yürütme gerçekleşene kadar ertelemek için "lazy val" kullanabilirsiniz. Bu, küçük bir performans maliyetine neden olabilir. Doğal olarak Scala'da da bir `RichFunction` kullanabilirsiniz.
+
+### Scala API'sini kullanırken, implicit değerler ve evidence parametreleri hakkında bir hata alıyorum.
+
+Bu hata, tür bilgisi için implicit değerin sağlanamadığı anlamına gelir. Kodunuzda bir `import org.apache.flink.streaming.api.scala._` (DataStream API) veya bir `import org.apache.flink.api.scala._` (DataSet API) ifadesinin olduğundan emin olun.
+
+Genel parametreler alan fonksiyonlar veya sınıflar içinde Flink işlemleri kullanıyorsanız, o parametre için bir TypeInformation mevcut olmalıdır. Bu, bir bağlam sınırı kullanılarak elde edilebilir:
+
+~~~scala
+def myFunction[T: TypeInformation](input: DataSet[T]): DataSet[Seq[T]] = {
+ input.reduceGroup( i => i.toSeq )
+}
+~~~
+
+Flink'in türleri nasıl ele aldığına dair derinlemesine bir tartışma için [Tür Çıkarma ve Serileştirme]({{< param DocsBaseUrl >}}/dev/types_serialization.html) bölümüne bakın.
+
+### ClassCastException görüyorum: X, X'e dönüştürülemiyor.
+
+`com.foo.X`, `com.foo.X`'e dönüştürülemiyor (veya `com.foo.X`'e atanamıyor) tarzında bir istisna gördüğünüzde, bu `com.foo.X` sınıfının birden fazla versiyonunun farklı sınıf yükleyiciler tarafından yüklendiği ve bu sınıfın türlerinin birbirine atanmaya çalışıldığı anlamına gelir.
+
+Bunun nedeni şunlar olabilir:
+
+- `child-first` sınıf yükleme yoluyla sınıf çoğaltma. Bu, kullanıcıların Flink'in kullandığı aynı bağımlılıkların farklı sürümlerini kullanmasına izin vermek için tasarlanmış bir mekanizmadır. Ancak, bu sınıfların farklı kopyaları Flink'in çekirdeği ve kullanıcı uygulama kodu arasında hareket ederse, böyle bir istisna oluşabilir. Bunun nedenini doğrulamak için, yapılandırmada `classloader.resolve-order: parent-first` ayarını yapmayı deneyin. Eğer bu hata kaybolursa, bir hata olup olmadığını kontrol etmek için lütfen e-posta listesine yazın.
+
+- Guava'nın Interners'ı veya Avro'nun Schema önbelleği gibi yardımcı programlar tarafından farklı yürütme girişimlerinden sınıfların önbelleğe alınması. Interners kullanmamaya çalışın veya yeni bir görev yürütmesi başlatıldığında yeni bir önbelleğin oluşturulduğundan emin olmak için interners/önbelleğin kapsamını azaltın.
+
+### AbstractMethodError veya NoSuchFieldError hatası alıyorum.
+
+Bu tür hatalar genellikle bazı bağımlılık sürümlerinde bir karışıklığı gösterir. Bu, yürütme sırasında yüklenen bir bağımlılığın (bir kütüphanenin) sürümünün, kodun derlendiği sürümden farklı olduğu anlamına gelir.
+
+Flink 1.4.0'dan itibaren, uygulama JAR dosyanızdaki bağımlılıklar, Flink'in çekirdeği tarafından kullanılan bağımlılıklara veya sınıf yolundaki diğer bağımlılıklara (örneğin Hadoop'tan) göre farklı sürümlere sahip olabilir. Bu, varsayılan olan `child-first` sınıf yüklemenin etkinleştirilmesini gerektirir.
+
+Bu sorunları Flink 1.4+ sürümünde görüyorsanız, aşağıdakilerden biri doğru olabilir:
+
+- Uygulama kodunuzda bir bağımlılık sürüm çakışması var. Tüm bağımlılık sürümlerinizin tutarlı olduğundan emin olun.
+- Flink'in `child-first` sınıf yükleme yoluyla destekleyemediği bir kütüphane ile çakışıyorsunuz. Şu anda bunlar, Scala standart kütüphane sınıfları, Flink'in kendi sınıfları, loglama API'leri ve herhangi bir Hadoop çekirdek sınıfıdır.
+
+
+### DataStream uygulamam, olaylar içeri girmesine rağmen çıktı üretmiyor.
+
+DataStream uygulamanız *Event Time* kullanıyorsa, watermark'larınızın güncellendiğinden emin olun. Watermark üretilmezse, event time pencereleri hiçbir zaman tetiklenmeyebilir ve uygulama sonuç üretmeyebilir.
+
+Flink'in web arayüzünde (watermark bölümü) watermark'ların ilerleme kaydedip kaydetmediğini kontrol edebilirsiniz.
+
+### "Insufficient number of network buffers" bildiren bir istisna görüyorum.
+
+Flink'i çok yüksek bir paralellikle çalıştırırsanız, ağ tamponlarının sayısını artırmanız gerekebilir.
+
+Varsayılan olarak Flink, minimum 64MB ve maksimum 1GB ile JVM yığın boyutunun %10'unu ağ tamponları için alır. Tüm bu değerleri `taskmanager.network.memory.fraction`, `taskmanager.network.memory.min` ve `taskmanager.network.memory.max` aracılığıyla ayarlayabilirsiniz.
+
+Ayrıntılar için lütfen [Yapılandırma Referansı](https://nightlies.apache.org/flink/flink-docs-stable/docs/deployment/)'na bakın.
+
+### İşim HDFS/Hadoop kodundan çeşitli istisnalarla başarısız oluyor. Ne yapabilirim?
+
+Bunun en yaygın nedeni, Flink'in sınıf yolundaki Hadoop sürümünün, bağlanmak istediğiniz kümenin Hadoop sürümünden farklı olmasıdır (HDFS / YARN).
+
+Bunu düzeltmenin en kolay yolu, Hadoop içermeyen bir Flink sürümü seçmek ve Hadoop yolunu ve sınıf yolunu kümeden basitçe dışa aktarmaktır.
diff --git a/docs/content.tr/how-to-contribute/improve-website.md b/docs/content.tr/how-to-contribute/improve-website.md
new file mode 100644
index 0000000000..9ff26b8a23
--- /dev/null
+++ b/docs/content.tr/how-to-contribute/improve-website.md
@@ -0,0 +1,106 @@
+---
+title: Web Sitesine Katkıda Bulunma
+bookCollapseSection: false
+weight: 22
+---
+
+# Web Sitesini İyileştirme
+
+[Apache Flink web sitesi](http://flink.apache.org), Apache Flink'i ve topluluğunu tanıtır. Web sitesi aşağıdakiler dahil olmak üzere çeşitli amaçlara hizmet eder:
+
+- Ziyaretçileri Apache Flink ve özellikleri hakkında bilgilendirmek.
+- Ziyaretçileri Flink'i indirmeye ve kullanmaya teşvik etmek.
+- Ziyaretçileri toplulukla etkileşime geçmeye teşvik etmek.
+
+Web sitemizi iyileştirmek için yapılacak her türlü katkıyı memnuniyetle karşılıyoruz. Bu belge, Flink'in web sitesini iyileştirmek için gerekli tüm bilgileri içerir.
+
+## Web sitesi kaynaklarını edinme
+
+Apache Flink'in web sitesi, GitHub'da [https://github.com/apache/flink-web](https://github.com/apache/flink-web) adresinde yansıtılan özel bir [git](http://git-scm.com/) deposunda barındırılmaktadır.
+
+Web sitesi güncellemelerine katkıda bulunmanın en kolay yolu, [GitHub'daki yansıtılmış web sitesi deposunu](https://github.com/apache/flink-web) sağ üst köşedeki fork düğmesine tıklayarak kendi GitHub hesabınıza fork etmektir. GitHub hesabınız yoksa, ücretsiz olarak bir tane oluşturabilirsiniz.
+
+Ardından, fork'unuzu yerel makinenize klonlayın.
+
+```
+git clone https://github.com//flink-web.git
+```
+
+`flink-web` dizini, klonlanmış depoyu içerir. Web sitesi, deponun `asf-site` dalında bulunur. Dizine girmek ve `asf-site` dalına geçmek için aşağıdaki komutları çalıştırın.
+
+```
+cd flink-web
+git checkout asf-site
+```
+
+## Dizin yapısı ve dosyalar
+
+Flink'in web sitesi [Markdown](http://daringfireball.net/projects/markdown/) ile yazılmıştır. Markdown, HTML'ye çevrilebilen hafif bir işaretleme dilidir. Markdown'dan statik HTML dosyaları oluşturmak için [Hugo](https://gohugo.io/) kullanıyoruz.
+
+Web sitesi git deposundaki dosya ve dizinler aşağıdaki rollere sahiptir:
+
+- `.md` ile biten tüm dosyalar Markdown dosyalarıdır. Bu dosyalar statik HTML dosyalarına dönüştürülür.
+- `docs` dizini, web sitesini oluşturmak ve/veya oluşturmak için gereken tüm dokümantasyonu, temaları ve diğer içeriği içerir.
+- `docs/content/docs` klasörü tüm İngilizce içeriği içerir. `docs/content.zh/docs` tüm Çince içeriği içerir.
+- `docs/content/posts` tüm blog yazılarını içerir.
+- `content/` dizini Hugo'dan oluşturulan HTML dosyalarını içerir. Flink web sitesini barındıran Apache Altyapısı HTML içeriğini bu dizinden çektiği için dosyaları bu dizine yerleştirmek önemlidir. (Committer'lar için: Web sitesi git'ine değişiklikleri gönderirken, `content/` dizinindeki güncellemeleri de gönderin!)
+
+## Dokümantasyonu güncelleme veya genişletme
+
+Web sitesini Markdown dosyalarını veya CSS dosyaları gibi diğer kaynakları değiştirerek veya ekleyerek güncelleyebilir ve genişletebilirsiniz. Değişikliklerinizi doğrulamak için oluşturma komut dosyasını önizleme modunda başlatın.
+
+```
+./build.sh
+```
+
+Komut dosyası, Markdown dosyalarını HTML'ye derler ve yerel bir web sunucusu başlatır. Değişikliklerinizi içeren web sitesini görüntülemek için tarayıcınızı `http://localhost:1313` adresinde açın. Çince çeviri `http://localhost:1313/zh/` adresinde bulunur. Sunulan web sitesi, herhangi bir dosyayı değiştirip kaydettiğinizde ve tarayıcınızı yenilediğinizde otomatik olarak yeniden derlenir ve güncellenir.
+
+Dokümantasyonlarınızda veya blog yazılarınızda Flink'in resmi dokümantasyonuna harici bir bağlantı eklemek için, lütfen aşağıdaki sözdizimini kullanın:
+
+```markdown
+{{* docs_link file="relative_path/" name="Title"*/>}}
+```
+
+Örneğin:
+
+```markdown
+{{* docs_link file="flink-docs-stable/docs/dev/datastream/side_output/" name="Side Output"*/>}}
+```
+
+Lütfen geliştirici e-posta listesinde her türlü sorunuzu sormaktan çekinmeyin.
+
+## Katkınızı gönderme
+
+Flink projesi, web sitesi katkılarını [GitHub Mirror](https://github.com/apache/flink-web) üzerinden [Pull Request'ler](https://help.github.com/articles/using-pull-requests) olarak kabul eder. Pull request'ler, değişiklikleri içeren bir kod dalına işaret ederek yama sunmanın basit bir yoludur.
+
+Bir pull request hazırlamak ve göndermek için şu adımları izleyin.
+
+1. Değişikliklerinizi yerel git deponuza commit edin. Katkınız web sitesinin büyük bir yeniden düzenlemesi olmadığı sürece, lütfen bunu tek bir commit olarak sıkıştırın.
+
+2. Commit'i, Flink deposunun GitHub'daki fork'unuzun özel bir dalına push edin.
+
+ ```
+ git push origin myBranch
+ ```
+
+3. Depo fork'unuzun web sitesine gidin (`https://github.com//flink-web`) ve bir pull request oluşturmaya başlamak için "Create Pull Request" düğmesini kullanın. Temel fork'un `apache/flink-web asf-site` olduğundan ve head fork'un değişikliklerinizi içeren dalı seçtiğinden emin olun. Pull request'e anlamlı bir açıklama verin ve gönderin.
+
+## Committer bölümü
+
+**Bu bölüm yalnızca committer'lar için geçerlidir.**
+
+### ASF web sitesi git depoları
+
+**ASF yazılabilir**: https://gitbox.apache.org/repos/asf/flink-web.git
+
+ASF git deposu için kimlik bilgilerinin nasıl ayarlanacağına ilişkin ayrıntılar [burada bağlantılıdır](https://gitbox.apache.org/).
+
+### Bir pull request'i birleştirme
+
+Katkıların yalnızca kaynak dosyalar üzerinde yapılması beklenir (`content/` dizinindeki derlenmiş dosyalarda değişiklik yapılmaz). Bir web sitesi değişikliğini push etmeden önce, lütfen oluşturma komut dosyasını çalıştırın
+
+```
+./build.sh
+```
+
+değişiklikleri `content/` dizinine ek bir commit olarak ekleyin ve değişiklikleri ASF temel deposuna push edin.
diff --git a/docs/content.tr/how-to-contribute/overview.md b/docs/content.tr/how-to-contribute/overview.md
new file mode 100644
index 0000000000..d61338addd
--- /dev/null
+++ b/docs/content.tr/how-to-contribute/overview.md
@@ -0,0 +1,128 @@
+---
+title: Genel Bakış
+bookCollapseSection: false
+weight: 16
+---
+
+# Nasıl Katkıda Bulunulur
+
+Apache Flink, açık ve dostane bir topluluk tarafından geliştirilmektedir. Herkes topluluğa katılmaya ve Apache Flink'e katkıda bulunmaya içtenlikle davetlidir. Toplulukla etkileşime geçmenin ve Flink'e katkıda bulunmanın soru sormak, hata raporları göndermek, yeni özellikler önermek, e-posta listelerindeki tartışmalara katılmak, kod veya dokümantasyon katkısında bulunmak, web sitesini geliştirmek veya sürüm adaylarını test etmek gibi çeşitli yolları vardır.
+
+
+## Ne yapmak istiyorsunuz?
+Apache Flink'e katkıda bulunmak, proje için kod yazmaktan daha fazlasını içerir. Aşağıda, projeye yardım etmek için farklı fırsatları listeliyoruz:
+
+
+
+
+
+ Alan
+ Daha fazla bilgi
+
+
+
+
+ Hata Bildir
+ Flink ile ilgili bir sorunu bildirmek için, Flink'in Jira 'sını açın, gerekirse giriş yapın ve üstteki kırmızı Oluştur düğmesine tıklayın.
+ Lütfen karşılaştığınız sorun hakkında detaylı bilgi verin ve mümkünse sorunu yeniden oluşturmaya yardımcı olacak bir açıklama ekleyin.
+
+
+ Kod Katkısında Bulun
+ }}">Kod Katkı Kılavuzu 'nu okuyun
+
+
+ Kod İncelemelerine Yardım Et
+ }}">Kod İnceleme Kılavuzu 'nu okuyun
+
+
+ Bir Sürüm Hazırlamaya Yardım Et
+
+ Yeni bir sürüm yayınlama şu adımlardan oluşur:
+
+ Yeni bir sürüm adayı oluşturmak ve dev@flink.apache.org listesinde bir oylama başlatmak (genellikle 72 saat sürer)
+ Sürüm adayını test etmek ve oylamak (herhangi bir sorun bulunmadıysa +1, sürüm adayında sorunlar varsa -1).
+ Sürüm adayında sorunlar varsa 1. adıma geri dönmek. Aksi takdirde sürümü yayınlarız.
+
+ Bir sürüm için test prosedürünü okuyun.
+
+
+
+ Dokümantasyona Katkıda Bulun
+ }}">Dokümantasyon Katkı Kılavuzu 'nu okuyun
+
+
+ Flink Kullanıcılarına Destek Ol
+
+
+
+
+
+ Web Sitesini Geliştir
+ }}">Web Sitesi Katkı Kılavuzu 'nu okuyun
+
+
+ Flink Hakkında Bilgi Yay
+
+
+
+
+
+
+ Başka bir sorunuz mu var? Yardım almak için }}#mailing-lists">dev@flink.apache.org e-posta listesiyle iletişime geçin!
+
+
+
+
+
+
+
+## Daha fazla okuma
+
+
+#### Committer olmak için
+
+Committer'lar, projenin depolarına yazma erişimi olan topluluk üyeleridir, yani kodu, dokümantasyonu ve web sitesini kendileri değiştirebilir ve diğer katkıları da kabul edebilirler.
+
+Committer veya PMC üyesi olmak için katı bir protokol yoktur. Yeni committer'lar için adaylar, genellikle aktif katkıda bulunanlar ve topluluk üyeleridir.
+
+Yeni committer'lar için adaylar, mevcut committer'lar veya PMC üyeleri tarafından önerilir ve PMC tarafından oylanır.
+
+Eğer committer olmak istiyorsanız, toplulukla etkileşime geçmeli ve yukarıdaki yollardan herhangi biriyle Apache Flink'e katkıda bulunmaya başlamalısınız. Ayrıca diğer committer'larla konuşabilir, tavsiye ve rehberliklerini isteyebilirsiniz.
+
+#### Committer'larda neleri arıyoruz
+
+Committer olmak, projeye (topluluk veya teknoloji) önemli bir katkıda bulunan olarak tanınmak ve gelişime yardımcı olacak araçlara sahip olmak anlamına gelir. Committer adayları, uzun bir süre boyunca iyi katkılarda bulunmuş ve katkılarına devam etmek isteyen topluluk üyeleridir.
+
+Topluluk katkıları, e-posta listesindeki kullanıcı sorularını yanıtlamaya yardımcı olmak, sürüm adaylarını doğrulamak, konuşmalar yapmak, topluluk etkinlikleri düzenlemek ve diğer tanıtım ve topluluk oluşturma biçimlerini içerir. "Apache Yolu", proje topluluğuna güçlü bir şekilde odaklanır ve committer'lar, herhangi bir kod katkısı olmadan bile üstün topluluk katkıları için tanınabilirler.
+
+Kod/teknoloji katkıları, katkıda bulunulan pull request'leri (patch'ler), tasarım tartışmaları, incelemeler, testler ve hataları tanımlama ve düzeltmede diğer yardımları içerir. Özellikle yapıcı ve yüksek kaliteli tasarım tartışmaları ve diğer katkıda bulunanlara yardım etmek, güçlü göstergelerdir.
+
+Önceki noktalar umut verici adayları tanımlamanın yollarını verirken, aşağıdakiler herhangi bir committer adayı için "olmazsa olmaz"lardır:
+
+- Topluluk odaklı olmak: Aday, topluluk yönetiminin liyakat ilkelerini anlar. Her zaman mümkün olduğunca kişisel katkıyı optimize etmezler, ancak mantıklı olduğunda başkalarına yardım eder ve onları güçlendirirler.
+
+- Bir committer adayının depolara yazma erişimini sorumlu bir şekilde kullanacağına ve şüphe durumunda, muhafazakâr davranacağına güveniriz. Flink büyük bir sistemdir ve committer'ların neyi bildiklerinin ve neyi bilmediklerinin farkında olmaları önemlidir. Şüphe durumunda, committer'lar iyi tanımadıkları kısımlara commit etmek yerine ikinci bir göz istemelidir. (En deneyimli committer'lar bile bu uygulamayı takip ederler.)
+
+- Diğer topluluk üyelerine saygılı davrandıklarını ve tartışmalarda yapıcı olduklarını göstermişlerdir.
+
+
+#### PMC üyelerinde neleri arıyoruz
+
+PMC, projenin resmi kontrol organıdır. PMC üyeleri PMC'nin resmi sorumluluklarını (sürümleri ve committer'ların/PMC'nin büyümesini doğrulamak) yerine getirebilmelidir. Onların Flink, teknoloji ve topluluk açısından bir vizyona sahip kişiler olmasını "isteriz".
+
+Şüpheye yer bırakmamak için, her PMC üyesinin Flink'in sürüm sürecinin tam olarak nasıl çalıştığının tüm ayrıntılarını bilmesi gerekmez (özünü ve ayrıntıları nasıl bulacağını anlamak yeterlidir). Aynı şekilde, her PMC üyesinin vizyoner olması gerekmez. Her üyenin farklı güçlü yönler getirdiğini anlayarak, tüm kısımları iyi kapsayan bir PMC oluşturmaya çalışırız.
+
+İdeal olarak, Flink'in yönünü (teknoloji ve topluluk) şekillendirme girişiminde bulunmuş ve sürüm oluşturma veya doğrulama gibi resmi süreçleri öğrenme istekliliği göstermiş aktif topluluk üyeleri arasında adaylar buluruz.
+
+Bir PMC üyesi aynı zamanda bir committer'dır. Adaylar ya zaten committer'dır ya da PMC'ye katıldıklarında otomatik olarak committer olurlar. Bu nedenle, "Committer'larda neleri arıyoruz?" bölümü PMC adayları için de geçerlidir.
+
+Bir PMC üyesinin bir projede büyük bir gücü vardır. Tek bir PMC üyesi, birçok kararı engelleyebilir ve genel olarak projeyi birçok şekilde durdurabilir ve zarar verebilir. Bu nedenle, PMC adaylarının soğukkanlı, yapıcı, destekleyici olduklarına ve zaman zaman "katılmayıp kabul etmeye" istekli olduklarına güvenmeliyiz.
+
diff --git a/docs/content.tr/how-to-contribute/reviewing-prs.md b/docs/content.tr/how-to-contribute/reviewing-prs.md
new file mode 100644
index 0000000000..3fd9c3ed4e
--- /dev/null
+++ b/docs/content.tr/how-to-contribute/reviewing-prs.md
@@ -0,0 +1,89 @@
+---
+title: Pull Request'leri İnceleme
+bookCollapseSection: false
+weight: 18
+---
+
+# Bir Pull Request Nasıl İncelenir
+
+Bu kılavuz, kod katkılarını incelemek isteyen tüm committer'lar ve katkıda bulunanlar içindir. Çabanız için teşekkür ederiz - iyi incelemeler, bir açık kaynak projesinin en önemli ve kritik parçalarından biridir. Bu kılavuz, topluluğun aşağıdaki şekilde incelemeler yapmasına yardımcı olmayı amaçlamaktadır:
+
+* Katkıda bulunanlar iyi bir katkı deneyimi yaşarlar.
+* İncelemelerimiz yapılandırılmıştır ve bir katkının tüm önemli yönlerini kontrol eder.
+* Flink'te yüksek kod kalitesini korumayı sağlarız.
+* Katkıda bulunanların ve inceleyicilerin, daha sonra reddedilen bir katkıyı geliştirmek için çok zaman harcadığı durumlardan kaçınırız.
+
+## İnceleme Kontrol Listesi
+
+Her inceleme aşağıdaki altı yönü kontrol etmelidir. **Bu yönleri sırayla kontrol etmenizi teşvik ediyoruz; böylece resmi gereksinimler karşılanmadığında veya değişikliği kabul etmek için toplulukta fikir birliği olmadığında, ayrıntılı kod kalitesi incelemelerine zaman harcamaktan kaçınmış olursunuz.**
+
+### 1. Katkı İyi Tanımlanmış mı?
+
+Katkının, iyi bir incelemeyi desteklemek için yeterince iyi tanımlanıp tanımlanmadığını kontrol edin. Önemsiz değişiklikler ve düzeltmeler uzun bir açıklama gerektirmez. Uygulama tam olarak [Jira'daki veya geliştirme e-posta listesindeki önceki tartışmaya göre]({{< relref "how-to-contribute/contribute-code" >}}#consensus) ise, sadece o tartışmaya kısa bir referans yeterlidir.
+Uygulama, fikir birliği tartışmasında üzerinde anlaşılan yaklaşımdan farklıysa, katkının daha fazla incelenmesi için uygulamanın ayrıntılı bir açıklaması gereklidir.
+
+İşlevselliği veya davranışı değiştiren herhangi bir pull request, bu değişikliklerin büyük resmini açıklamalıdır, böylece incelemeler neye bakacaklarını bilirler (ve değişikliğin ne yaptığını anlamak için kodu incelemek zorunda kalmazlar).
+
+
+**Aşağıdaki 2, 3 ve 4. sorular koda bakmadan cevaplanabiliyorsa katkı iyi tanımlanmıştır.**
+
+-----
+
+### 2. Değişikliğin veya Özelliğin Flink'e Girmesi Konusunda Fikir Birliği Var mı?
+
+Bu soru doğrudan bağlantılı Jira sorunuyla cevaplanabilir. Önceden fikir birliği olmadan oluşturulan pull request'ler için, [fikir birliği aramak için Jira'da bir tartışma]({{< relref "how-to-contribute/contribute-code" >}}) gerekecektir.
+
+
+`[hotfix]` pull request'leri için, pull request'te fikir birliği kontrolü yapılması gerekir.
+
+
+-----
+
+### 3. Katkı Bazı Belirli Committer'lardan Dikkat Gerektiriyor mu ve Bu Committer'lardan Zaman Taahhüdü Var mı?
+
+Bazı değişiklikler belirli committer'ların dikkatini ve onayını gerektirir. Örneğin, performansa çok duyarlı olan veya dağıtılmış koordinasyon ve hata toleransı üzerinde kritik bir etkisi olan parçalardaki değişiklikler, bileşene derinlemesine aşina olan bir committer'dan girdiye ihtiyaç duyar.
+
+Kural olarak, Pull Request açıklaması şablondaki "Bu pull request aşağıdaki parçalardan birini potansiyel olarak etkiliyor mu" bölümündeki sorulardan birine 'evet' ile cevap verdiğinde özel dikkat gereklidir.
+
+Bu soru şu şekilde cevaplanabilir:
+
+* *Özel dikkat gerektirmez*
+* *X için özel dikkat gerektirir (X, örneğin kontrol noktası oluşturma, jobmanager vb. olabilir).*
+* *@committerA, @contributorB tarafından X için özel dikkat var*
+
+**Pull request özel dikkat gerektiriyorsa, etiketlenen committer'lardan/katkıda bulunanlardan biri nihai onayı vermelidir.**
+
+----
+
+### 4. Uygulama, Üzerinde Anlaşılan Genel Yaklaşımı/Mimariyi Takip Ediyor mu?
+
+Bu adımda, bir katkının Jira'daki veya e-posta listelerindeki önceki tartışmada üzerinde anlaşılan yaklaşımı takip edip etmediğini kontrol ediyoruz.
+
+Bu soru mümkün olduğunca Pull Request açıklamasından (veya bağlantılı Jira'dan) cevaplanabilmelidir.
+
+Değişikliğin bireysel kısımları hakkında yorum yapmak gibi ayrıntılara girmeden önce bunu kontrol etmenizi öneririz.
+
+----
+
+### 5. Genel Kod Kalitesi İyi mi, Flink'te Sürdürmek İstediğimiz Standartları Karşılıyor mu?
+
+Bu, gerçek değişikliklerin ayrıntılı kod incelemesidir ve şunları kapsar:
+
+* Değişiklikler Jira biletinde veya tasarım belgesinde açıklanan şeyi yapıyor mu?
+* Kod doğru yazılım mühendisliği uygulamalarını takip ediyor mu? Kod doğru, sağlam, bakımı yapılabilir, test edilebilir mi?
+* Performansa duyarlı bir kısmı değiştirirken, değişiklikler performans bilinciyle yapılmış mı?
+* Değişiklikler testlerle yeterince kapsanmış mı?
+* Testler hızlı çalışıyor mu, yani ağır entegrasyon testleri sadece gerektiğinde mi kullanılıyor?
+* Kod formatı Flink'in checkstyle desenini takip ediyor mu?
+* Kod, ek derleyici uyarıları getirmekten kaçınıyor mu?
+* Bağımlılıklar değiştirildiyse, NOTICE dosyaları güncellendi mi?
+
+Kod yönergeleri [Flink Kod Stili ve Kalite Kılavuzu]({{< relref "how-to-contribute/code-style-and-quality-preamble" >}})'nda bulunabilir.
+
+----
+
+### 6. İngilizce ve Çince Belgeler Güncellendi mi?
+
+Pull request yeni bir özellik tanıtıyorsa, özellik belgelenmelidir. Flink topluluğu hem İngilizce hem de Çince belgeleri sürdürmektedir. Bu nedenle her iki belge de güncellenmelidir. Çince diline aşina değilseniz, lütfen Çince belge çevirisi için `chinese-translation` bileşenine atanmış bir Jira açın ve bunu mevcut Jira sorunu ile ilişkilendirin. Çince diline aşinaysanız, her iki tarafı da bir pull request'te güncellemeniz teşvik edilir.
+
+[Belgelere nasıl katkıda bulunulacağı]({{< relref "how-to-contribute/contribute-documentation" >}}) hakkında daha fazla bilgi alın.
\ No newline at end of file
diff --git a/docs/content.tr/material.md b/docs/content.tr/material.md
new file mode 100644
index 0000000000..bb133939a6
--- /dev/null
+++ b/docs/content.tr/material.md
@@ -0,0 +1,111 @@
+---
+title: Material
+bold: true
+bookCollapseSection: false
+bookHidden: true
+
+tables:
+ png:
+ name: "png"
+
+ cols:
+ - id: "Colored"
+ name: "Colored logo"
+ - id: "WhiteFilled"
+ name: "White filled logo"
+ - id: "BlackOutline"
+ name: "Black outline logo"
+
+ rows:
+ - Colored:
+ val: " "
+ html: true
+ WhiteFilled:
+ val: " "
+ html: true
+ BlackOutline:
+ val: " "
+ html: true
+ - Colored: "**Sizes (px)** [50x50](/img/logo/png/50/color_50.png), [100x100](/img/logo/png/100/flink_squirrel_100_color.png), [200x200](/img/logo/png/200/flink_squirrel_200_color.png), [500x500](/img/logo/png/500/flink_squirrel_500.png), [1000x1000](/img/logo/png/1000/flink_squirrel_1000.png)"
+ WhiteFilled: "**Sizes (px)**: [50x50](/img/logo/png/50/white_50.png), [100x100](/img/logo/png/100/flink_squirrel_100_white.png), [200x200](/img/logo/png/200/flink_squirrel_200_white.png), [500x500](/img/logo/png/500/flink_squirrel_500_white.png), [1000x1000](/img/logo/png/1000/flink_squirrel_white_1000.png)"
+ BlackOutline: "**Sizes (px)**: [50x50](/img/logo/png/50/black_50.png), [100x100](/img/logo/png/100/flink_squirrel_100_black.png), [200x200](/img/logo/png/200/flink_squirrel_200_black.png), [500x500](/img/logo/png/500/flink_squirrel_500_black.png), [1000x1000](/img/logo/png/1000/flink_squirrel_black_1000.png)"
+
+ svg:
+ name: "svg"
+
+ cols:
+ - id: "Colored"
+ name: "Colored logo"
+ - id: "WhiteFilled"
+ name: "White filled logo"
+ - id: "BlackOutline"
+ name: "Black outline logo"
+
+ rows:
+ - Colored:
+ val: " "
+ html: true
+ WhiteFilled:
+ val: " "
+ html: true
+ BlackOutline:
+ val: " "
+ html: true
+ - Colored: "Colored logo with black text ([color_black.svg](/img/logo/svg/color_black.svg))"
+ WhiteFilled: "White filled logo ([white_filled.svg](/img/logo/svg/white_filled.svg))"
+ BlackOutline: "Black outline logo ([black_outline.svg](/img/logo/svg/black_outline.svg))"
+
+
+---
+
+
+# Material
+
+## Apache Flink Logos
+
+We provide the Apache Flink logo in different sizes and formats. You can [download all variants](/img/logo.zip) (7.4 MB) or just pick the one you need from this page.
+
+### Portable Network Graphics (PNG)
+
+{{< table "png" >}}
+
+You can find more variants of the logo [in this directory](/img/logo/png) or [download all variants](/img/logo.zip) (7.4 MB).
+
+### Scalable Vector Graphics (SVG)
+
+{{< table "svg" >}}
+
+You can find more variants of the logo [in this directory](/img/logo/svg) or [download all variants](/img/logo.zip) (7.4 MB).
+
+### Photoshop (PSD)
+
+You can download the logo in PSD format as well:
+
+- **Colored logo**: [1000x1000](/img/logo/psd/flink_squirrel_1000.psd).
+- **Black outline logo with text**: [1000x1000](/img/logo/psd/flink_1000.psd), [5000x5000](/img/logo/psd/flink_5000.psd).
+
+You can find more variants of the logo [in this directory](/img/logo/psd) or [download all variants](/img/logo.zip) (7.4 MB).
+
+## Color Scheme
+
+You can use the provided color scheme which incorporates some colors of the Flink logo:
+
+- [PDF color scheme](/img/logo/colors/flink_colors.pdf)
+- [Powerpoint color scheme](/img/logo/colors/flink_colors.pptx)
diff --git a/docs/content.tr/posts/2014-08-26-release-0.6.md b/docs/content.tr/posts/2014-08-26-release-0.6.md
new file mode 100644
index 0000000000..24f5d6de56
--- /dev/null
+++ b/docs/content.tr/posts/2014-08-26-release-0.6.md
@@ -0,0 +1,80 @@
+---
+date: "2014-08-26T10:00:00Z"
+title: Apache Flink 0.6 available
+aliases:
+- /news/2014/08/26/release-0.6.html
+---
+
+We are happy to announce the availability of Flink 0.6. This is the
+first release of the system inside the Apache Incubator and under the
+name Flink. Releases up to 0.5 were under the name Stratosphere, the
+academic and open source project that Flink originates from.
+
+## What is Flink?
+
+Apache Flink is a general-purpose data processing engine for
+clusters. It runs on YARN clusters on top of data stored in Hadoop, as
+well as stand-alone. Flink currently has programming APIs in Java and
+Scala. Jobs are executed via Flink's own runtime engine. Flink
+features:
+
+**Robust in-memory and out-of-core processing:** once read, data stays
+ in memory as much as possible, and is gracefully de-staged to disk in
+ the presence of memory pressure from limited memory or other
+ applications. The runtime is designed to perform very well both in
+ setups with abundant memory and in setups where memory is scarce.
+
+**POJO-based APIs:** when programming, you do not have to pack your
+ data into key-value pairs or some other framework-specific data
+ model. Rather, you can use arbitrary Java and Scala types to model
+ your data.
+
+**Efficient iterative processing:** Flink contains explicit "iterate" operators
+ that enable very efficient loops over data sets, e.g., for machine
+ learning and graph applications.
+
+**A modular system stack:** Flink is not a direct implementation of its
+ APIs but a layered system. All programming APIs are translated to an
+ intermediate program representation that is compiled and optimized
+ via a cost-based optimizer. Lower-level layers of Flink also expose
+ programming APIs for extending the system.
+
+**Data pipelining/streaming:** Flink's runtime is designed as a
+ pipelined data processing engine rather than a batch processing
+ engine. Operators do not wait for their predecessors to finish in
+ order to start processing data. This results to very efficient
+ handling of large data sets.
+
+## Release 0.6
+
+Flink 0.6 builds on the latest Stratosphere 0.5 release. It includes
+many bug fixes and improvements that make the system more stable and
+robust, as well as breaking API changes.
+
+The full release notes are available [here](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12327101).
+
+Download the release [here](http://flink.incubator.apache.org/downloads.html).
+
+## Contributors
+
+* Wilson Cao
+* Ufuk Celebi
+* Stephan Ewen
+* Jonathan Hasenburg
+* Markus Holzemer
+* Fabian Hueske
+* Sebastian Kunert
+* Vikhyat Korrapati
+* Aljoscha Krettek
+* Sebastian Kruse
+* Raymond Liu
+* Robert Metzger
+* Mingliang Qi
+* Till Rohrmann
+* Henry Saputra
+* Chesnay Schepler
+* Kostas Tzoumas
+* Robert Waury
+* Timo Walther
+* Daniel Warneke
+* Tobias Wiens
diff --git a/docs/content.tr/posts/2014-09-26-release-0.6.1.md b/docs/content.tr/posts/2014-09-26-release-0.6.1.md
new file mode 100644
index 0000000000..8ae5dde4ea
--- /dev/null
+++ b/docs/content.tr/posts/2014-09-26-release-0.6.1.md
@@ -0,0 +1,13 @@
+---
+date: "2014-09-26T10:00:00Z"
+title: Apache Flink 0.6.1 available
+aliases:
+- /news/2014/09/26/release-0.6.1.html
+---
+
+We are happy to announce the availability of Flink 0.6.1.
+
+0.6.1 is a maintenance release, which includes minor fixes across several parts
+of the system. We suggest all users of Flink to work with this newest version.
+
+[Download](/downloads.html) the release today.
\ No newline at end of file
diff --git a/docs/content.tr/posts/2014-10-03-upcoming_events.md b/docs/content.tr/posts/2014-10-03-upcoming_events.md
new file mode 100644
index 0000000000..fc9aa175df
--- /dev/null
+++ b/docs/content.tr/posts/2014-10-03-upcoming_events.md
@@ -0,0 +1,87 @@
+---
+date: "2014-10-03T10:00:00Z"
+title: Upcoming Events
+aliases:
+- /news/2014/10/03/upcoming_events.html
+---
+
+We are happy to announce several upcoming Flink events both in Europe and the US. Starting with a **Flink hackathon in Stockholm** (Oct 8-9) and a talk about Flink at the **Stockholm Hadoop User Group** (Oct 8). This is followed by the very first **Flink Meetup in Berlin** (Oct 15). In the US, there will be two Flink Meetup talks: the first one at the **Pasadena Big Data User Group** (Oct 29) and the second one at **Silicon Valley Hands On Programming Events** (Nov 4).
+
+We are looking forward to seeing you at any of these events. The following is an overview of each event and links to the respective Meetup pages.
+
+### Flink Hackathon, Stockholm (Oct 8-9)
+
+The hackathon will take place at KTH/SICS from Oct 8th-9th. You can sign up here: https://docs.google.com/spreadsheet/viewform?formkey=dDZnMlRtZHJ3Z0hVTlFZVjU2MWtoX0E6MA.
+
+Here is a rough agenda and a list of topics to work upon or look into. Suggestions and more topics are welcome.
+
+#### Wednesday (8th)
+
+9:00 - 10:00 Introduction to Apache Flink, System overview, and Dev
+environment (by Stephan)
+
+10:15 - 11:00 Introduction to the topics (Streaming API and system by Gyula
+& Marton), (Graphs by Vasia / Martin / Stephan)
+
+11:00 - 12:30 Happy hacking (part 1)
+
+12:30 - Lunch (Food will be provided by KTH / SICS. A big thank you to them
+and also to Paris, for organizing that)
+
+13:xx - Happy hacking (part 2)
+
+#### Thursday (9th)
+
+Happy hacking (continued)
+
+
+#### Suggestions for topics
+
+##### Streaming
+
+ - Sample streaming applications (e.g. continuous heavy hitters and topics
+on the twitter stream)
+
+ - Implement a simple SQL to Streaming program parser. Possibly using
+Apache Calcite (http://optiq.incubator.apache.org/)
+
+ - Implement different windowing methods (count-based, time-based, ...)
+
+ - Implement different windowed operations (windowed-stream-join,
+windowed-stream-co-group)
+
+ - Streaming state, and interaction with other programs (that access state
+of a stream program)
+
+##### Graph Analysis
+
+ - Prototype a Graph DSL (simple graph building, filters, graph
+properties, some algorithms)
+
+ - Prototype abstractions different Graph processing paradigms
+(vertex-centric, partition-centric).
+
+ - Generalize the delta iterations, allow flexible state access.
+
+### Meetup: Hadoop User Group Talk, Stockholm (Oct 8)
+
+Hosted by Spotify, opens at 6 PM.
+
+http://www.meetup.com/stockholm-hug/events/207323222/
+
+### 1st Flink Meetup, Berlin (Oct 15)
+
+We are happy to announce the first Flink meetup in Berlin. You are very welcome to to sign up and attend. The event will be held in Betahaus Cafe.
+
+http://www.meetup.com/Apache-Flink-Meetup/events/208227422/
+
+### Meetup: Pasadena Big Data User Group (Oct 29)
+
+http://www.meetup.com/Pasadena-Big-Data-Users-Group/
+
+### Meetup: Silicon Valley Hands On Programming Events (Nov 4)
+
+http://www.meetup.com/HandsOnProgrammingEvents/events/210504392/
+
+
+
diff --git a/docs/content.tr/posts/2014-11-04-release-0.7.0.md b/docs/content.tr/posts/2014-11-04-release-0.7.0.md
new file mode 100644
index 0000000000..a8908e04eb
--- /dev/null
+++ b/docs/content.tr/posts/2014-11-04-release-0.7.0.md
@@ -0,0 +1,69 @@
+---
+date: "2014-11-04T10:00:00Z"
+title: Apache Flink 0.7.0 available
+aliases:
+- /news/2014/11/04/release-0.7.0.html
+---
+
+We are pleased to announce the availability of Flink 0.7.0. This release includes new user-facing features as well as performance and bug fixes, brings the Scala and Java APIs in sync, and introduces Flink Streaming. A total of 34 people have contributed to this release, a big thanks to all of them!
+
+Download Flink 0.7.0 [here](http://flink.incubator.apache.org/downloads.html)
+
+See the release changelog [here](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12327648)
+
+## Overview of major new features
+
+**Flink Streaming:** The gem of the 0.7.0 release is undoubtedly Flink Streaming. Available currently in alpha, Flink Streaming provides a Java API on top of Apache Flink that can consume streaming data sources (e.g., from Apache Kafka, Apache Flume, and others) and process them in real time. A dedicated blog post on Flink Streaming and its performance is coming up here soon. You can check out the Streaming programming guide [here]({{< param DocsBaseUrl >}}flink-docs-release-0.7/streaming_guide.html).
+
+**New Scala API:** The Scala API has been completely rewritten. The Java and Scala APIs have now the same syntax and transformations and will be kept from now on in sync in every future release. See the new Scala API [here]({{< param DocsBaseUrl >}}flink-docs-release-0.7/programming_guide.html).
+
+**Logical key expressions:** You can now specify grouping and joining keys with logical names for member variables of POJO data types. For example, you can join two data sets as ``persons.join(cities).where(“zip”).equalTo(“zipcode”)``. Read more [here]({{< param DocsBaseUrl >}}flink-docs-release-0.7/programming_guide.html#specifying-keys).
+
+**Hadoop MapReduce compatibility:** You can run unmodified Hadoop Mappers and Reducers (mapred API) in Flink, use all Hadoop data types, and read data with all Hadoop InputFormats.
+
+**Collection-based execution backend:** The collection-based execution backend enables you to execute a Flink job as a simple Java collections program, bypassing completely the Flink runtime and optimizer. This feature is extremely useful for prototyping, and embedding Flink jobs in projects in a very lightweight manner.
+
+**Record API deprecated:** The (old) Stratosphere Record API has been marked as deprecated and is planned for removal in the 0.9.0 release.
+
+**BLOB service:** This release contains a new service to distribute jar files and other binary data among the JobManager, TaskManagers and the client.
+
+**Intermediate data sets:** A major rewrite of the system internals introduces intermediate data sets as first class citizens. The internal state machine that tracks the distributed tasks has also been completely rewritten for scalability. While this is not visible as a user-facing feature yet, it is the foundation for several upcoming exciting features.
+
+**Note:** Currently, there is limited support for Java 8 lambdas when compiling and running from an IDE. The problem is due to type erasure and whether Java compilers retain type information. We are currently working with the Eclipse and OpenJDK communities to resolve this.
+
+## Contributors
+
+* Tamas Ambrus
+* Mariem Ayadi
+* Marton Balassi
+* Daniel Bali
+* Ufuk Celebi
+* Hung Chang
+* David Eszes
+* Stephan Ewen
+* Judit Feher
+* Gyula Fora
+* Gabor Hermann
+* Fabian Hueske
+* Vasiliki Kalavri
+* Kristof Kovacs
+* Aljoscha Krettek
+* Sebastian Kruse
+* Sebastian Kunert
+* Matyas Manninger
+* Robert Metzger
+* Mingliang Qi
+* Till Rohrmann
+* Henry Saputra
+* Chesnay Schelper
+* Moritz Schubotz
+* Hung Sendoh Chang
+* Peter Szabo
+* Jonas Traub
+* Fabian Tschirschnitz
+* Artem Tsikiridis
+* Kostas Tzoumas
+* Timo Walther
+* Daniel Warneke
+* Tobias Wiens
+* Yingjun Wu
\ No newline at end of file
diff --git a/docs/content.tr/posts/2014-11-18-hadoop-compatibility.md b/docs/content.tr/posts/2014-11-18-hadoop-compatibility.md
new file mode 100644
index 0000000000..8ba28339b9
--- /dev/null
+++ b/docs/content.tr/posts/2014-11-18-hadoop-compatibility.md
@@ -0,0 +1,90 @@
+---
+author: Fabian Hüske
+author-twitter: fhueske
+date: "2014-11-18T10:00:00Z"
+title: Hadoop Compatibility in Flink
+aliases:
+- /news/2014/11/18/hadoop-compatibility.html
+---
+
+[Apache Hadoop](http://hadoop.apache.org) is an industry standard for scalable analytical data processing. Many data analysis applications have been implemented as Hadoop MapReduce jobs and run in clusters around the world. Apache Flink can be an alternative to MapReduce and improves it in many dimensions. Among other features, Flink provides much better performance and offers APIs in Java and Scala, which are very easy to use. Similar to Hadoop, Flink’s APIs provide interfaces for Mapper and Reducer functions, as well as Input- and OutputFormats along with many more operators. While being conceptually equivalent, Hadoop’s MapReduce and Flink’s interfaces for these functions are unfortunately not source compatible.
+
+## Flink’s Hadoop Compatibility Package
+
+
+
+
+
+To close this gap, Flink provides a Hadoop Compatibility package to wrap functions implemented against Hadoop’s MapReduce interfaces and embed them in Flink programs. This package was developed as part of a [Google Summer of Code](https://developers.google.com/open-source/soc/) 2014 project.
+
+With the Hadoop Compatibility package, you can reuse all your Hadoop
+
+* ``InputFormats`` (mapred and mapreduce APIs)
+* ``OutputFormats`` (mapred and mapreduce APIs)
+* ``Mappers`` (mapred API)
+* ``Reducers`` (mapred API)
+
+in Flink programs without changing a line of code. Moreover, Flink also natively supports all Hadoop data types (``Writables`` and ``WritableComparable``).
+
+The following code snippet shows a simple Flink WordCount program that solely uses Hadoop data types, InputFormat, OutputFormat, Mapper, and Reducer functions.
+
+```java
+
+// Definition of Hadoop Mapper function
+public class Tokenizer implements Mapper { ... }
+// Definition of Hadoop Reducer function
+public class Counter implements Reducer { ... }
+
+public static void main(String[] args) {
+ final String inputPath = args[0];
+ final String outputPath = args[1];
+
+ final ExecutionEnvironment env = ExecutionEnvironment.getExecutionEnvironment();
+
+ // Setup Hadoop’s TextInputFormat
+ HadoopInputFormat hadoopInputFormat =
+ new HadoopInputFormat(
+ new TextInputFormat(), LongWritable.class, Text.class, new JobConf());
+ TextInputFormat.addInputPath(hadoopInputFormat.getJobConf(), new Path(inputPath));
+
+ // Read a DataSet with the Hadoop InputFormat
+ DataSet> text = env.createInput(hadoopInputFormat);
+ DataSet> words = text
+ // Wrap Tokenizer Mapper function
+ .flatMap(new HadoopMapFunction(new Tokenizer()))
+ .groupBy(0)
+ // Wrap Counter Reducer function (used as Reducer and Combiner)
+ .reduceGroup(new HadoopReduceCombineFunction(
+ new Counter(), new Counter()));
+
+ // Setup Hadoop’s TextOutputFormat
+ HadoopOutputFormat hadoopOutputFormat =
+ new HadoopOutputFormat(
+ new TextOutputFormat(), new JobConf());
+ hadoopOutputFormat.getJobConf().set("mapred.textoutputformat.separator", " ");
+ TextOutputFormat.setOutputPath(hadoopOutputFormat.getJobConf(), new Path(outputPath));
+
+ // Output & Execute
+ words.output(hadoopOutputFormat);
+ env.execute("Hadoop Compat WordCount");
+}
+
+```
+
+As you can see, Flink represents Hadoop key-value pairs as `Tuple2` tuples. Note, that the program uses Flink’s `groupBy()` transformation to group data on the key field (field 0 of the `Tuple2`) before it is given to the Reducer function. At the moment, the compatibility package does not evaluate custom Hadoop partitioners, sorting comparators, or grouping comparators.
+
+Hadoop functions can be used at any position within a Flink program and of course also be mixed with native Flink functions. This means that instead of assembling a workflow of Hadoop jobs in an external driver method or using a workflow scheduler such as [Apache Oozie](http://oozie.apache.org), you can implement an arbitrary complex Flink program consisting of multiple Hadoop Input- and OutputFormats, Mapper and Reducer functions. When executing such a Flink program, data will be pipelined between your Hadoop functions and will not be written to HDFS just for the purpose of data exchange.
+
+
+
+
+
+## What comes next?
+
+While the Hadoop compatibility package is already very useful, we are currently working on a dedicated Hadoop Job operation to embed and execute Hadoop jobs as a whole in Flink programs, including their custom partitioning, sorting, and grouping code. With this feature, you will be able to chain multiple Hadoop jobs, mix them with Flink functions, and other operations such as [Spargel]({{< param DocsBaseUrl >}}flink-docs-release-0.7/spargel_guide.html) operations (Pregel/Giraph-style jobs).
+
+## Summary
+
+Flink lets you reuse a lot of the code you wrote for Hadoop MapReduce, including all data types, all Input- and OutputFormats, and Mapper and Reducers of the mapred-API. Hadoop functions can be used within Flink programs and mixed with all other Flink functions. Due to Flink’s pipelined execution, Hadoop functions can arbitrarily be assembled without data exchange via HDFS. Moreover, the Flink community is currently working on a dedicated Hadoop Job operation to supporting the execution of Hadoop jobs as a whole.
+
+If you want to use Flink’s Hadoop compatibility package checkout our [documentation]({{< param DocsBaseUrl >}}flink-docs-master/apis/batch/hadoop_compatibility.html).
diff --git a/docs/content.tr/posts/2015-01-06-december-in-flink.md b/docs/content.tr/posts/2015-01-06-december-in-flink.md
new file mode 100644
index 0000000000..4b4e68690d
--- /dev/null
+++ b/docs/content.tr/posts/2015-01-06-december-in-flink.md
@@ -0,0 +1,62 @@
+---
+date: "2015-01-06T10:00:00Z"
+title: December 2014 in the Flink community
+aliases:
+- /news/2015/01/06/december-in-flink.html
+---
+
+This is the first blog post of a “newsletter” like series where we give a summary of the monthly activity in the Flink community. As the Flink project grows, this can serve as a "tl;dr" for people that are not following the Flink dev and user mailing lists, or those that are simply overwhelmed by the traffic.
+
+
+### Flink graduation
+
+The biggest news is that the Apache board approved Flink as a top-level Apache project! The Flink team is working closely with the Apache press team for an official announcement, so stay tuned for details!
+
+### New Flink website
+
+The [Flink website](http://flink.apache.org) got a total make-over, both in terms of appearance and content.
+
+### Flink IRC channel
+
+A new IRC channel called #flink was created at irc.freenode.org. An easy way to access the IRC channel is through the [web client](http://webchat.freenode.net/). Feel free to stop by to ask anything or share your ideas about Apache Flink!
+
+### Meetups and Talks
+
+Apache Flink was presented in the [Amsterdam Hadoop User Group](http://www.meetup.com/Netherlands-Hadoop-User-Group/events/218635152)
+
+## Notable code contributions
+
+**Note:** Code contributions listed here may not be part of a release or even the current snapshot yet.
+
+### [Streaming Scala API](https://github.com/apache/incubator-flink/pull/275)
+
+The Flink Streaming Java API recently got its Scala counterpart. Once merged, Flink Streaming users can use both Scala and Java for their development. The Flink Streaming Scala API is built as a thin layer on top of the Java API, making sure that the APIs are kept easily in sync.
+
+### [Intermediate datasets](https://github.com/apache/incubator-flink/pull/254)
+
+This pull request introduces a major change in the Flink runtime. Currently, the Flink runtime is based on the notion of operators that exchange data through channels. With the PR, intermediate data sets that are produced by operators become first-class citizens in the runtime. While this does not have any user-facing impact yet, it lays the groundwork for a slew of future features such as blocking execution, fine-grained fault-tolerance, and more efficient data sharing between cluster and client.
+
+### [Configurable execution mode](https://github.com/apache/incubator-flink/pull/259)
+
+This pull request allows the user to change the object-reuse behaviour. Before this pull request, some operations would reuse objects passed to the user function while others would always create new objects. This introduces a system wide switch and changes all operators to either reuse objects or don’t reuse objects.
+
+### [Distributed Coordination via Akka](https://github.com/apache/incubator-flink/pull/149)
+
+Another major change is a complete rewrite of the JobManager / TaskManager components in Scala. In addition to that, the old RPC service was replaced by Actors, using the Akka framework.
+
+### [Sorting of very large records](https://github.com/apache/incubator-flink/pull/249 )
+
+Flink's internal sort-algorithms were improved to better handle large records (multiple 100s of megabytes or larger). Previously, the system did in some cases hold instances of multiple large records, resulting in high memory consumption and JVM heap thrashing. Through this fix, large records are streamed through the operators, reducing the memory consumption and GC pressure. The system now requires much less memory to support algorithms that work on such large records.
+
+### [Kryo Serialization as the new default fallback](https://github.com/apache/incubator-flink/pull/271)
+
+Flink’s build-in type serialization framework is handles all common types very efficiently. Prior versions uses Avro to serialize types that the built-in framework could not handle.
+Flink serialization system improved a lot over time and by now surpasses the capabilities of Avro in many cases. Kryo now serves as the default fallback serialization framework, supporting a much broader range of types.
+
+### [Hadoop FileSystem support](https://github.com/apache/incubator-flink/pull/268)
+
+This change permits users to use all file systems supported by Hadoop with Flink. In practice this means that users can use Flink with Tachyon, Google Cloud Storage (also out of the box Flink YARN support on Google Compute Cloud), FTP and all the other file system implementations for Hadoop.
+
+## Heading to the 0.8.0 release
+
+The community is working hard together with the Apache infra team to migrate the Flink infrastructure to a top-level project. At the same time, the Flink community is working on the Flink 0.8.0 release which should be out very soon.
\ No newline at end of file
diff --git a/docs/content.tr/posts/2015-01-21-release-0.8.md b/docs/content.tr/posts/2015-01-21-release-0.8.md
new file mode 100644
index 0000000000..735aa4a271
--- /dev/null
+++ b/docs/content.tr/posts/2015-01-21-release-0.8.md
@@ -0,0 +1,76 @@
+---
+date: "2015-01-21T10:00:00Z"
+title: Apache Flink 0.8.0 available
+aliases:
+- /news/2015/01/21/release-0.8.html
+---
+
+
+We are pleased to announce the availability of Flink 0.8.0. This release includes new user-facing features as well as performance and bug fixes, extends the support for filesystems and introduces the Scala API and flexible windowing semantics for Flink Streaming. A total of 33 people have contributed to this release, a big thanks to all of them!
+
+[Download Flink 0.8.0](http://www.apache.org/dyn/closer.cgi/flink/flink-0.8.0/flink-0.8.0-bin-hadoop2.tgz)
+
+[See the release changelog](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12328699)
+
+## Overview of major new features
+
+
+ - **Extended filesystem support**: The former `DistributedFileSystem` interface has been generalized to `HadoopFileSystem` now supporting all sub classes of `org.apache.hadoop.fs.FileSystem`. This allows users to use all file systems supported by Hadoop with Apache Flink.
+[See connecting to other systems]({{< param DocsBaseUrl >}}flink-docs-release-0.8/example_connectors.html)
+
+ - **Streaming Scala API**: As an alternative to the existing Java API Streaming is now also programmable in Scala. The Java and Scala APIs have now the same syntax and transformations and will be kept from now on in sync in every future release.
+
+ - **Streaming windowing semantics**: The new windowing api offers an expressive way to define custom logic for triggering the execution of a stream window and removing elements. The new features include out-of-the-box support for windows based in logical or physical time and data-driven properties on the events themselves among others. [Read more here]({{< param DocsBaseUrl >}}flink-docs-release-0.8/streaming_guide.html#window-operators)
+
+ - **Mutable and immutable objects in runtime** All Flink versions before 0.8.0 were always passing the same objects to functions written by users. This is a common performance optimization, also used in other systems such as Hadoop.
+ However, this is error-prone for new users because one has to carefully check that references to the object aren’t kept in the user function. Starting from 0.8.0, Flink allows to configure a mode which is disabling that mechanism.
+
+ - **Performance and usability improvements**: The new Apache Flink 0.8.0 release brings several new features which will significantly improve the performance and the usability of the system. Amongst others, these features include:
+ - Improved input split assignment which maximizes computation locality
+ - Smart broadcasting mechanism which minimizes network I/O
+ - Custom partitioners which let the user control how the data is partitioned within the cluster. This helps to prevent data skewness and allows to implement highly efficient algorithms.
+ - coGroup operator now supports group sorting for its inputs
+
+ - **Kryo is the new fallback serializer**: Apache Flink has a sophisticated type analysis and serialization framework that is able to handle commonly used types very efficiently.
+ In addition to that, there is a fallback serializer for types which are not supported. Older versions of Flink used the reflective [Avro](http://avro.apache.org/) serializer for that purpose. With this release, Flink is using the powerful [Kryo](https://github.com/EsotericSoftware/kryo) and twitter-chill library for support of types such as Java Collections and Scala specifc types.
+
+ - **Hadoop 2.2.0+ is now the default Hadoop dependency**: With Flink 0.8.0 we made the “hadoop2” build profile the default build for Flink. This means that all users using Hadoop 1 (0.2X or 1.2.X versions) have to specify version “0.8.0-hadoop1” in their pom files.
+
+ - **HBase module updated** The HBase version has been updated to 0.98.6.1. Also, Hbase is now available to the Hadoop1 and Hadoop2 profile of Flink.
+
+
+## Contributors
+
+ - Marton Balassi
+ - Daniel Bali
+ - Carsten Brandt
+ - Moritz Borgmann
+ - Stefan Bunk
+ - Paris Carbone
+ - Ufuk Celebi
+ - Nils Engelbach
+ - Stephan Ewen
+ - Gyula Fora
+ - Gabor Hermann
+ - Fabian Hueske
+ - Vasiliki Kalavri
+ - Johannes Kirschnick
+ - Aljoscha Krettek
+ - Suneel Marthi
+ - Robert Metzger
+ - Felix Neutatz
+ - Chiwan Park
+ - Flavio Pompermaier
+ - Mingliang Qi
+ - Shiva Teja Reddy
+ - Till Rohrmann
+ - Henry Saputra
+ - Kousuke Saruta
+ - Chesney Schepler
+ - Erich Schubert
+ - Peter Szabo
+ - Jonas Traub
+ - Kostas Tzoumas
+ - Timo Walther
+ - Daniel Warneke
+ - Chen Xu
\ No newline at end of file
diff --git a/docs/content.tr/posts/2015-02-04-january-in-flink.md b/docs/content.tr/posts/2015-02-04-january-in-flink.md
new file mode 100644
index 0000000000..fe406f85d5
--- /dev/null
+++ b/docs/content.tr/posts/2015-02-04-january-in-flink.md
@@ -0,0 +1,48 @@
+---
+date: "2015-02-04T10:00:00Z"
+title: January 2015 in the Flink community
+aliases:
+- /news/2015/02/04/january-in-flink.html
+---
+
+Happy 2015! Here is a (hopefully digestible) summary of what happened last month in the Flink community.
+
+### 0.8.0 release
+
+Flink 0.8.0 was released. See [here](http://flink.apache.org/news/2015/01/21/release-0.8.html) for the release notes.
+
+### Flink roadmap
+
+The community has published a [roadmap for 2015](https://cwiki.apache.org/confluence/display/FLINK/Flink+Roadmap) on the Flink wiki. Check it out to see what is coming up in Flink, and pick up an issue to contribute!
+
+### Articles in the press
+
+The Apache Software Foundation [announced](https://blogs.apache.org/foundation/entry/the_apache_software_foundation_announces69) Flink as a Top-Level Project. The announcement was picked up by the media, e.g., [here](http://sdtimes.com/inside-apache-software-foundations-newest-top-level-project-apache-flink/?utm_content=11232092&utm_medium=social&utm_source=twitter), [here](http://www.datanami.com/2015/01/12/apache-flink-takes-route-distributed-data-processing/), and [here](http://i-programmer.info/news/197-data-mining/8176-flink-reaches-top-level-status.html).
+
+### Hadoop Summit
+
+A submitted abstract on Flink Streaming won the community vote at “The Future of Hadoop” track.
+
+### Meetups and talks
+
+Flink was presented at the [Paris Hadoop User Group](http://www.meetup.com/Hadoop-User-Group-France/events/219778022/), the [Bay Area Hadoop User Group](http://www.meetup.com/hadoop/events/167785202/), the [Apache Tez User Group](http://www.meetup.com/Apache-Tez-User-Group/events/219302692/), and [FOSDEM 2015](https://fosdem.org/2015/schedule/track/graph_processing/). The January [Flink meetup in Berlin](http://www.meetup.com/Apache-Flink-Meetup/events/219639984/) had talks on recent community updates and new features.
+
+## Notable code contributions
+
+**Note:** Code contributions listed here may not be part of a release or even the Flink master repository yet.
+
+### [Using off-heap memory](https://github.com/apache/flink/pull/290)
+
+This pull request enables Flink to use off-heap memory for its internal memory uses (sort, hash, caching of intermediate data sets).
+
+### [Gelly, Flink’s Graph API](https://github.com/apache/flink/pull/335)
+
+This pull request introduces Gelly, Flink’s brand new Graph API. Gelly offers a native graph programming abstraction with functionality for vertex-centric programming, as well as available graph algorithms. See [this slide set](http://www.slideshare.net/vkalavri/largescale-graph-processing-with-apache-flink-graphdevroom-fosdem15) for an overview of Gelly.
+
+### [Semantic annotations](https://github.com/apache/flink/pull/311)
+
+Semantic annotations are a powerful mechanism to expose information about the behavior of Flink functions to Flink’s optimizer. The optimizer can leverage this information to generate more efficient execution plans. For example the output of a Reduce operator that groups on the second field of a tuple is still partitioned on that field if the Reduce function does not modify the value of the second field. By exposing this information to the optimizer, the optimizer can generate plans that avoid expensive data shuffling and reuse the partitioned output of Reduce. Semantic annotations can be defined for most data types, including (nested) tuples and POJOs. See the snapshot documentation for details (not online yet).
+
+### [New YARN client](https://github.com/apache/flink/pull/292)
+
+The improved YARN client of Flink now allows users to deploy Flink on YARN for executing a single job. Older versions only supported a long-running YARN session. The code of the YARN client has been refactored to provide an (internal) Java API for controlling YARN clusters more easily.
diff --git a/docs/content.tr/posts/2015-02-09-streaming-example.md b/docs/content.tr/posts/2015-02-09-streaming-example.md
new file mode 100644
index 0000000000..5a809af276
--- /dev/null
+++ b/docs/content.tr/posts/2015-02-09-streaming-example.md
@@ -0,0 +1,681 @@
+---
+date: "2015-02-09T12:00:00Z"
+title: Introducing Flink Streaming
+aliases:
+- /news/2015/02/09/streaming-example.html
+---
+
+This post is the first of a series of blog posts on Flink Streaming,
+the recent addition to Apache Flink that makes it possible to analyze
+continuous data sources in addition to static files. Flink Streaming
+uses the pipelined Flink engine to process data streams in real time
+and offers a new API including definition of flexible windows.
+
+In this post, we go through an example that uses the Flink Streaming
+API to compute statistics on stock market data that arrive
+continuously and combine the stock market data with Twitter streams.
+See the [Streaming Programming
+Guide]({{< param DocsBaseUrl >}}flink-docs-master/apis/streaming/index.html) for a
+detailed presentation of the Streaming API.
+
+First, we read a bunch of stock price streams and combine them into
+one stream of market data. We apply several transformations on this
+market data stream, like rolling aggregations per stock. Then we emit
+price warning alerts when the prices are rapidly changing. Moving
+towards more advanced features, we compute rolling correlations
+between the market data streams and a Twitter stream with stock mentions.
+
+For running the example implementation please use the *0.9-SNAPSHOT*
+version of Flink as a dependency. The full example code base can be
+found [here](https://github.com/mbalassi/flink/blob/stockprices/flink-staging/flink-streaming/flink-streaming-examples/src/main/scala/org/apache/flink/streaming/scala/examples/windowing/StockPrices.scala) in Scala and [here](https://github.com/mbalassi/flink/blob/stockprices/flink-staging/flink-streaming/flink-streaming-examples/src/main/java/org/apache/flink/streaming/examples/windowing/StockPrices.java) in Java7.
+
+
+
+
+
+[Back to top](#top)
+
+Reading from multiple inputs
+---------------
+
+First, let us create the stream of stock prices:
+
+1. Read a socket stream of stock prices
+1. Parse the text in the stream to create a stream of `StockPrice` objects
+1. Add four other sources tagged with the stock symbol.
+1. Finally, merge the streams to create a unified stream.
+
+
+
+
+
+{{< highlight scala >}}
+def main(args: Array[String]) {
+
+ val env = StreamExecutionEnvironment.getExecutionEnvironment
+
+ //Read from a socket stream at map it to StockPrice objects
+ val socketStockStream = env.socketTextStream("localhost", 9999).map(x => {
+ val split = x.split(",")
+ StockPrice(split(0), split(1).toDouble)
+ })
+
+ //Generate other stock streams
+ val SPX_Stream = env.addSource(generateStock("SPX")(10) _)
+ val FTSE_Stream = env.addSource(generateStock("FTSE")(20) _)
+ val DJI_Stream = env.addSource(generateStock("DJI")(30) _)
+ val BUX_Stream = env.addSource(generateStock("BUX")(40) _)
+
+ //Merge all stock streams together
+ val stockStream = socketStockStream.merge(SPX_Stream, FTSE_Stream,
+ DJI_Stream, BUX_Stream)
+
+ stockStream.print()
+
+ env.execute("Stock stream")
+}
+{{< / highlight >}}
+
+
+{{< highlight java >}}
+public static void main(String[] args) throws Exception {
+
+ final StreamExecutionEnvironment env =
+ StreamExecutionEnvironment.getExecutionEnvironment();
+
+ //Read from a socket stream at map it to StockPrice objects
+ DataStream socketStockStream = env
+ .socketTextStream("localhost", 9999)
+ .map(new MapFunction() {
+ private String[] tokens;
+
+ @Override
+ public StockPrice map(String value) throws Exception {
+ tokens = value.split(",");
+ return new StockPrice(tokens[0],
+ Double.parseDouble(tokens[1]));
+ }
+ });
+
+ //Generate other stock streams
+ DataStream SPX_stream = env.addSource(new StockSource("SPX", 10));
+ DataStream FTSE_stream = env.addSource(new StockSource("FTSE", 20));
+ DataStream DJI_stream = env.addSource(new StockSource("DJI", 30));
+ DataStream BUX_stream = env.addSource(new StockSource("BUX", 40));
+
+ //Merge all stock streams together
+ DataStream stockStream = socketStockStream
+ .merge(SPX_stream, FTSE_stream, DJI_stream, BUX_stream);
+
+ stockStream.print();
+
+ env.execute("Stock stream");
+ {{< / highlight >}}
+
+
+
+See
+[here]({{< param DocsBaseUrl >}}flink-docs-master/apis/streaming/index.html#data-sources)
+on how you can create streaming sources for Flink Streaming
+programs. Flink, of course, has support for reading in streams from
+[external
+sources]({{< param DocsBaseUrl >}}flink-docs-master/apis/streaming/connectors/index.html)
+such as Apache Kafka, Apache Flume, RabbitMQ, and others. For the sake
+of this example, the data streams are simply generated using the
+`generateStock` method:
+
+
+
+
+{{< highlight scala >}}
+val symbols = List("SPX", "FTSE", "DJI", "DJT", "BUX", "DAX", "GOOG")
+
+case class StockPrice(symbol: String, price: Double)
+
+def generateStock(symbol: String)(sigma: Int)(out: Collector[StockPrice]) = {
+ var price = 1000.
+ while (true) {
+ price = price + Random.nextGaussian * sigma
+ out.collect(StockPrice(symbol, price))
+ Thread.sleep(Random.nextInt(200))
+ }
+}
+{{< / highlight >}}
+
+
+{{< highlight java >}}
+private static final ArrayList SYMBOLS = new ArrayList(
+ Arrays.asList("SPX", "FTSE", "DJI", "DJT", "BUX", "DAX", "GOOG"));
+
+public static class StockPrice implements Serializable {
+
+ public String symbol;
+ public Double price;
+
+ public StockPrice() {
+ }
+
+ public StockPrice(String symbol, Double price) {
+ this.symbol = symbol;
+ this.price = price;
+ }
+
+ @Override
+ public String toString() {
+ return "StockPrice{" +
+ "symbol='" + symbol + '\'' +
+ ", count=" + price +
+ '}';
+ }
+}
+
+public final static class StockSource implements SourceFunction {
+
+ private Double price;
+ private String symbol;
+ private Integer sigma;
+
+ public StockSource(String symbol, Integer sigma) {
+ this.symbol = symbol;
+ this.sigma = sigma;
+ }
+
+ @Override
+ public void invoke(Collector collector) throws Exception {
+ price = DEFAULT_PRICE;
+ Random random = new Random();
+
+ while (true) {
+ price = price + random.nextGaussian() * sigma;
+ collector.collect(new StockPrice(symbol, price));
+ Thread.sleep(random.nextInt(200));
+ }
+ }
+}
+{{< / highlight >}}
+
+
+
+To read from the text socket stream please make sure that you have a
+socket running. For the sake of the example executing the following
+command in a terminal does the job. You can get
+[netcat](http://netcat.sourceforge.net/) here if it is not available
+on your machine.
+
+```
+nc -lk 9999
+```
+
+If we execute the program from our IDE we see the system the
+stock prices being generated:
+
+```
+INFO Job execution switched to status RUNNING.
+INFO Socket Stream(1/1) switched to SCHEDULED
+INFO Socket Stream(1/1) switched to DEPLOYING
+INFO Custom Source(1/1) switched to SCHEDULED
+INFO Custom Source(1/1) switched to DEPLOYING
+…
+1> StockPrice{symbol='SPX', count=1011.3405732645239}
+2> StockPrice{symbol='SPX', count=1018.3381290039248}
+1> StockPrice{symbol='DJI', count=1036.7454894073978}
+3> StockPrice{symbol='DJI', count=1135.1170217478427}
+3> StockPrice{symbol='BUX', count=1053.667523187687}
+4> StockPrice{symbol='BUX', count=1036.552601487263}
+```
+
+[Back to top](#top)
+
+Window aggregations
+---------------
+
+We first compute aggregations on time-based windows of the
+data. Flink provides [flexible windowing semantics]({{< param DocsBaseUrl >}}flink-docs-master/apis/streaming/windows.html) where windows can
+also be defined based on count of records or any custom user defined
+logic.
+
+We partition our stream into windows of 10 seconds and slide the
+window every 5 seconds. We compute three statistics every 5 seconds.
+The first is the minimum price of all stocks, the second produces
+maximum price per stock, and the third is the mean stock price
+(using a map window function). Aggregations and groupings can be
+performed on named fields of POJOs, making the code more readable.
+
+
+
+
+
+
+
+{{< highlight scala >}}
+//Define the desired time window
+val windowedStream = stockStream
+ .window(Time.of(10, SECONDS)).every(Time.of(5, SECONDS))
+
+//Compute some simple statistics on a rolling window
+val lowest = windowedStream.minBy("price")
+val maxByStock = windowedStream.groupBy("symbol").maxBy("price")
+val rollingMean = windowedStream.groupBy("symbol").mapWindow(mean _)
+
+//Compute the mean of a window
+def mean(ts: Iterable[StockPrice], out: Collector[StockPrice]) = {
+ if (ts.nonEmpty) {
+ out.collect(StockPrice(ts.head.symbol, ts.foldLeft(0: Double)(_ + _.price) / ts.size))
+ }
+}
+{{< / highlight >}}
+
+
+
+
+
+{{< highlight java >}}
+//Define the desired time window
+WindowedDataStream windowedStream = stockStream
+ .window(Time.of(10, TimeUnit.SECONDS))
+ .every(Time.of(5, TimeUnit.SECONDS));
+
+//Compute some simple statistics on a rolling window
+DataStream lowest = windowedStream.minBy("price").flatten();
+DataStream maxByStock = windowedStream.groupBy("symbol")
+ .maxBy("price").flatten();
+DataStream rollingMean = windowedStream.groupBy("symbol")
+ .mapWindow(new WindowMean()).flatten();
+
+//Compute the mean of a window
+public final static class WindowMean implements
+ WindowMapFunction {
+
+ private Double sum = 0.0;
+ private Integer count = 0;
+ private String symbol = "";
+
+ @Override
+ public void mapWindow(Iterable values, Collector out)
+ throws Exception {
+
+ if (values.iterator().hasNext()) {s
+ for (StockPrice sp : values) {
+ sum += sp.price;
+ symbol = sp.symbol;
+ count++;
+ }
+ out.collect(new StockPrice(symbol, sum / count));
+ }
+ }
+}
+{{< / highlight >}}
+
+
+
+
+
+Let us note that to print a windowed stream one has to flatten it first,
+thus getting rid of the windowing logic. For example execute
+`maxByStock.flatten().print()` to print the stream of maximum prices of
+ the time windows by stock. For Scala `flatten()` is called implicitly
+when needed.
+
+[Back to top](#top)
+
+Data-driven windows
+---------------
+
+The most interesting event in the stream is when the price of a stock
+is changing rapidly. We can send a warning when a stock price changes
+more than 5% since the last warning. To do that, we use a delta-based window providing a
+threshold on when the computation will be triggered, a function to
+compute the difference and a default value with which the first record
+is compared. We also create a `Count` data type to count the warnings
+every 30 seconds.
+
+
+
+
+
+
+
+{{< highlight scala >}}
+case class Count(symbol: String, count: Int)
+val defaultPrice = StockPrice("", 1000)
+
+//Use delta policy to create price change warnings
+val priceWarnings = stockStream.groupBy("symbol")
+ .window(Delta.of(0.05, priceChange, defaultPrice))
+ .mapWindow(sendWarning _)
+
+//Count the number of warnings every half a minute
+val warningsPerStock = priceWarnings.map(Count(_, 1))
+ .groupBy("symbol")
+ .window(Time.of(30, SECONDS))
+ .sum("count")
+
+def priceChange(p1: StockPrice, p2: StockPrice): Double = {
+ Math.abs(p1.price / p2.price - 1)
+}
+
+def sendWarning(ts: Iterable[StockPrice], out: Collector[String]) = {
+ if (ts.nonEmpty) out.collect(ts.head.symbol)
+}
+
+{{< / highlight >}}
+
+
+
+
+
+{{< highlight java >}}
+
+private static final Double DEFAULT_PRICE = 1000.;
+private static final StockPrice DEFAULT_STOCK_PRICE = new StockPrice("", DEFAULT_PRICE);
+
+//Use delta policy to create price change warnings
+DataStream priceWarnings = stockStream.groupBy("symbol")
+ .window(Delta.of(0.05, new DeltaFunction() {
+ @Override
+ public double getDelta(StockPrice oldDataPoint, StockPrice newDataPoint) {
+ return Math.abs(oldDataPoint.price - newDataPoint.price);
+ }
+ }, DEFAULT_STOCK_PRICE))
+.mapWindow(new SendWarning()).flatten();
+
+//Count the number of warnings every half a minute
+DataStream warningsPerStock = priceWarnings.map(new MapFunction() {
+ @Override
+ public Count map(String value) throws Exception {
+ return new Count(value, 1);
+ }
+}).groupBy("symbol").window(Time.of(30, TimeUnit.SECONDS)).sum("count").flatten();
+
+public static class Count implements Serializable {
+ public String symbol;
+ public Integer count;
+
+ public Count() {
+ }
+
+ public Count(String symbol, Integer count) {
+ this.symbol = symbol;
+ this.count = count;
+ }
+
+ @Override
+ public String toString() {
+ return "Count{" +
+ "symbol='" + symbol + '\'' +
+ ", count=" + count +
+ '}';
+ }
+}
+
+public static final class SendWarning implements MapWindowFunction {
+ @Override
+ public void mapWindow(Iterable values, Collector out)
+ throws Exception {
+
+ if (values.iterator().hasNext()) {
+ out.collect(values.iterator().next().symbol);
+ }
+ }
+}
+
+{{< / highlight >}}
+
+
+
+
+
+[Back to top](#top)
+
+Combining with a Twitter stream
+---------------
+
+Next, we will read a Twitter stream and correlate it with our stock
+price stream. Flink has support for connecting to [Twitter's
+API]({{< param DocsBaseUrl >}}flink-docs-master/apis/streaming/connectors/twitter.html)
+but for the sake of this example we generate dummy tweet data.
+
+
+
+
+
+
+
+
+{{< highlight scala >}}
+//Read a stream of tweets
+val tweetStream = env.addSource(generateTweets _)
+
+//Extract the stock symbols
+val mentionedSymbols = tweetStream.flatMap(tweet => tweet.split(" "))
+ .map(_.toUpperCase())
+ .filter(symbols.contains(_))
+
+//Count the extracted symbols
+val tweetsPerStock = mentionedSymbols.map(Count(_, 1))
+ .groupBy("symbol")
+ .window(Time.of(30, SECONDS))
+ .sum("count")
+
+def generateTweets(out: Collector[String]) = {
+ while (true) {
+ val s = for (i <- 1 to 3) yield (symbols(Random.nextInt(symbols.size)))
+ out.collect(s.mkString(" "))
+ Thread.sleep(Random.nextInt(500))
+ }
+}
+{{< / highlight >}}
+
+
+
+
+
+{{< highlight java >}}
+//Read a stream of tweets
+DataStream tweetStream = env.addSource(new TweetSource());
+
+//Extract the stock symbols
+DataStream mentionedSymbols = tweetStream.flatMap(
+ new FlatMapFunction() {
+ @Override
+ public void flatMap(String value, Collector out) throws Exception {
+ String[] words = value.split(" ");
+ for (String word : words) {
+ out.collect(word.toUpperCase());
+ }
+ }
+}).filter(new FilterFunction() {
+ @Override
+ public boolean filter(String value) throws Exception {
+ return SYMBOLS.contains(value);
+ }
+});
+
+//Count the extracted symbols
+DataStream tweetsPerStock = mentionedSymbols.map(new MapFunction() {
+ @Override
+ public Count map(String value) throws Exception {
+ return new Count(value, 1);
+ }
+}).groupBy("symbol").window(Time.of(30, TimeUnit.SECONDS)).sum("count").flatten();
+
+public static final class TweetSource implements SourceFunction {
+ Random random;
+ StringBuilder stringBuilder;
+
+ @Override
+ public void invoke(Collector collector) throws Exception {
+ random = new Random();
+ stringBuilder = new StringBuilder();
+
+ while (true) {
+ stringBuilder.setLength(0);
+ for (int i = 0; i < 3; i++) {
+ stringBuilder.append(" ");
+ stringBuilder.append(SYMBOLS.get(random.nextInt(SYMBOLS.size())));
+ }
+ collector.collect(stringBuilder.toString());
+ Thread.sleep(500);
+ }
+
+ }
+}
+
+{{< / highlight >}}
+
+
+
+
+
+[Back to top](#top)
+
+Streaming joins
+---------------
+
+Finally, we join real-time tweets and stock prices and compute a
+rolling correlation between the number of price warnings and the
+number of mentions of a given stock in the Twitter stream. As both of
+these data streams are potentially infinite, we apply the join on a
+30-second window.
+
+
+
+
+
+
+
+
+{{< highlight scala >}}
+
+//Join warnings and parsed tweets
+val tweetsAndWarning = warningsPerStock.join(tweetsPerStock)
+ .onWindow(30, SECONDS)
+ .where("symbol")
+ .equalTo("symbol") { (c1, c2) => (c1.count, c2.count) }
+
+val rollingCorrelation = tweetsAndWarning.window(Time.of(30, SECONDS))
+ .mapWindow(computeCorrelation _)
+
+rollingCorrelation print
+
+//Compute rolling correlation
+def computeCorrelation(input: Iterable[(Int, Int)], out: Collector[Double]) = {
+ if (input.nonEmpty) {
+ val var1 = input.map(_._1)
+ val mean1 = average(var1)
+ val var2 = input.map(_._2)
+ val mean2 = average(var2)
+
+ val cov = average(var1.zip(var2).map(xy => (xy._1 - mean1) * (xy._2 - mean2)))
+ val d1 = Math.sqrt(average(var1.map(x => Math.pow((x - mean1), 2))))
+ val d2 = Math.sqrt(average(var2.map(x => Math.pow((x - mean2), 2))))
+
+ out.collect(cov / (d1 * d2))
+ }
+}
+
+{{< / highlight >}}
+
+
+
+
+
+{{< highlight java >}}
+
+//Join warnings and parsed tweets
+DataStream> tweetsAndWarning = warningsPerStock
+ .join(tweetsPerStock)
+ .onWindow(30, TimeUnit.SECONDS)
+ .where("symbol")
+ .equalTo("symbol")
+ .with(new JoinFunction>() {
+ @Override
+ public Tuple2 join(Count first, Count second) throws Exception {
+ return new Tuple2(first.count, second.count);
+ }
+ });
+
+//Compute rolling correlation
+DataStream rollingCorrelation = tweetsAndWarning
+ .window(Time.of(30, TimeUnit.SECONDS))
+ .mapWindow(new WindowCorrelation());
+
+rollingCorrelation.print();
+
+public static final class WindowCorrelation
+ implements WindowMapFunction, Double> {
+
+ private Integer leftSum;
+ private Integer rightSum;
+ private Integer count;
+
+ private Double leftMean;
+ private Double rightMean;
+
+ private Double cov;
+ private Double leftSd;
+ private Double rightSd;
+
+ @Override
+ public void mapWindow(Iterable> values, Collector out)
+ throws Exception {
+
+ leftSum = 0;
+ rightSum = 0;
+ count = 0;
+
+ cov = 0.;
+ leftSd = 0.;
+ rightSd = 0.;
+
+ //compute mean for both sides, save count
+ for (Tuple2 pair : values) {
+ leftSum += pair.f0;
+ rightSum += pair.f1;
+ count++;
+ }
+
+ leftMean = leftSum.doubleValue() / count;
+ rightMean = rightSum.doubleValue() / count;
+
+ //compute covariance & std. deviations
+ for (Tuple2 pair : values) {
+ cov += (pair.f0 - leftMean) * (pair.f1 - rightMean) / count;
+ }
+
+ for (Tuple2 pair : values) {
+ leftSd += Math.pow(pair.f0 - leftMean, 2) / count;
+ rightSd += Math.pow(pair.f1 - rightMean, 2) / count;
+ }
+ leftSd = Math.sqrt(leftSd);
+ rightSd = Math.sqrt(rightSd);
+
+ out.collect(cov / (leftSd * rightSd));
+ }
+}
+
+{{< / highlight >}}
+
+
+
+
+
+[Back to top](#top)
+
+
+Other things to try
+---------------
+
+For a full feature overview please check the [Streaming Guide]({{< param DocsBaseUrl >}}flink-docs-master/apis/streaming/index.html), which describes all the available API features.
+You are very welcome to try out our features for different use-cases we are looking forward to your experiences. Feel free to [contact us](http://flink.apache.org/community.html#mailing-lists).
+
+Upcoming for streaming
+---------------
+
+There are some aspects of Flink Streaming that are subjects to
+change by the next release making this application look even nicer.
+
+Stay tuned for later blog posts on how Flink Streaming works
+internally, fault tolerance, and performance measurements!
+
+[Back to top](#top)
diff --git a/docs/content.tr/posts/2015-03-02-february-2015-in-flink.md b/docs/content.tr/posts/2015-03-02-february-2015-in-flink.md
new file mode 100644
index 0000000000..e0c5bcd4f1
--- /dev/null
+++ b/docs/content.tr/posts/2015-03-02-february-2015-in-flink.md
@@ -0,0 +1,112 @@
+---
+date: "2015-03-02T10:00:00Z"
+title: February 2015 in the Flink community
+aliases:
+- /news/2015/03/02/february-2015-in-flink.html
+---
+
+February might be the shortest month of the year, but this does not
+mean that the Flink community has not been busy adding features to the
+system and fixing bugs. Here’s a rundown of the activity in the Flink
+community last month.
+
+### 0.8.1 release
+
+Flink 0.8.1 was released. This bugfixing release resolves a total of 22 issues.
+
+### New committer
+
+[Max Michels](https://github.com/mxm) has been voted a committer by the Flink PMC.
+
+### Flink adapter for Apache SAMOA
+
+[Apache SAMOA (incubating)](http://samoa.incubator.apache.org) is a
+distributed streaming machine learning (ML) framework with a
+programming abstraction for distributed streaming ML algorithms. SAMOA
+runs on a variety of backend engines, currently Apache Storm and
+Apache S4. A [pull
+request](https://github.com/apache/incubator-samoa/pull/11) is
+available at the SAMOA repository that adds a Flink adapter for SAMOA.
+
+### Easy Flink deployment on Google Compute Cloud
+
+Flink is now integrated in bdutil, Google’s open source tool for
+creating and configuring (Hadoop) clusters in Google Compute
+Engine. Deployment of Flink clusters in now supported starting with
+[bdutil
+1.2.0](https://groups.google.com/forum/#!topic/gcp-hadoop-announce/uVJ_6y9cGKM).
+
+### Flink on the Web
+
+A new blog post on [Flink
+Streaming](http://flink.apache.org/news/2015/02/09/streaming-example.html)
+was published at the blog. Flink was mentioned in several articles on
+the web. Here are some examples:
+
+- [How Flink became an Apache Top-Level Project](http://dataconomy.com/how-flink-became-an-apache-top-level-project/)
+
+- [Stale Synchronous Parallelism: The new frontier for Apache Flink?](https://www.linkedin.com/pulse/stale-synchronous-parallelism-new-frontier-apache-flink-nam-luc-tran?utm_content=buffer461af&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer)
+
+- [Distributed data processing with Apache Flink](http://www.hadoopsphere.com/2015/02/distributed-data-processing-with-apache.html)
+
+- [Ciao latency, hello speed](http://www.hadoopsphere.com/2015/02/ciao-latency-hallo-speed.html)
+
+## In the Flink master
+
+The following features have been now merged in Flink’s master repository.
+
+### Gelly
+
+Gelly, Flink’s Graph API allows users to manipulate graph-shaped data
+directly. Here’s for example a calculation of shortest paths in a
+graph:
+
+{{< highlight java >}}
+Graph graph = Graph.fromDataSet(vertices, edges, env);
+
+DataSet> singleSourceShortestPaths = graph
+ .run(new SingleSourceShortestPaths(srcVertexId,
+ maxIterations)).getVertices();
+{{< / highlight >}}
+
+See more Gelly examples
+[here](https://github.com/apache/flink/tree/master/flink-libraries/flink-gelly-examples).
+
+### Flink Expressions
+
+The newly merged
+[flink-table](https://github.com/apache/flink/tree/master/flink-libraries/flink-table)
+module is the first step in Flink’s roadmap towards logical queries
+and SQL support. Here’s a preview on how you can read two CSV file,
+assign a logical schema to, and apply transformations like filters and
+joins using logical attributes rather than physical data types.
+
+{{< highlight scala >}}
+val customers = getCustomerDataSet(env)
+ .as('id, 'mktSegment)
+ .filter( 'mktSegment === "AUTOMOBILE" )
+
+val orders = getOrdersDataSet(env)
+ .filter( o => dateFormat.parse(o.orderDate).before(date) )
+ .as('orderId, 'custId, 'orderDate, 'shipPrio)
+
+val items =
+ orders.join(customers)
+ .where('custId === 'id)
+ .select('orderId, 'orderDate, 'shipPrio)
+{{< / highlight >}}
+
+### Access to HCatalog tables
+
+With the [flink-hcatalog
+module](https://github.com/apache/flink/tree/master/flink-batch-connectors/flink-hcatalog),
+you can now conveniently access HCatalog/Hive tables. The module
+supports projection (selection and order of fields) and partition
+filters.
+
+### Access to secured YARN clusters/HDFS.
+
+With this change users can access Kerberos secured YARN (and HDFS)
+Hadoop clusters. Also, basic support for accessing secured HDFS with
+a standalone Flink setup is now available.
+
diff --git a/docs/content.tr/posts/2015-03-13-peeking-into-Apache-Flinks-Engine-Room.md b/docs/content.tr/posts/2015-03-13-peeking-into-Apache-Flinks-Engine-Room.md
new file mode 100644
index 0000000000..7c5d83baf9
--- /dev/null
+++ b/docs/content.tr/posts/2015-03-13-peeking-into-Apache-Flinks-Engine-Room.md
@@ -0,0 +1,182 @@
+---
+author: Fabian Hüske
+author-twitter: fhueske
+date: "2015-03-13T10:00:00Z"
+excerpt: Joins are prevalent operations in many data processing applications. Most
+ data processing systems feature APIs that make joining data sets very easy. However,
+ the internal algorithms for join processing are much more involved – especially
+ if large data sets need to be efficiently handled. In this blog post, we cut through
+ Apache Flink’s layered architecture and take a look at its internals with a focus
+ on how it handles joins.
+title: Peeking into Apache Flink's Engine Room
+aliases:
+- /news/2015/03/13/peeking-into-Apache-Flinks-Engine-Room.html
+---
+
+### Join Processing in Apache Flink
+
+Joins are prevalent operations in many data processing applications. Most data processing systems feature APIs that make joining data sets very easy. However, the internal algorithms for join processing are much more involved – especially if large data sets need to be efficiently handled. Therefore, join processing serves as a good example to discuss the salient design points and implementation details of a data processing system.
+
+In this blog post, we cut through Apache Flink’s layered architecture and take a look at its internals with a focus on how it handles joins. Specifically, I will
+
+* show how easy it is to join data sets using Flink’s fluent APIs,
+* discuss basic distributed join strategies, Flink’s join implementations, and its memory management,
+* talk about Flink’s optimizer that automatically chooses join strategies,
+* show some performance numbers for joining data sets of different sizes, and finally
+* briefly discuss joining of co-located and pre-sorted data sets.
+
+*Disclaimer*: This blog post is exclusively about equi-joins. Whenever I say “join” in the following, I actually mean “equi-join”.
+
+### How do I join with Flink?
+
+Flink provides fluent APIs in Java and Scala to write data flow programs. Flink’s APIs are centered around parallel data collections which are called data sets. data sets are processed by applying Transformations that compute new data sets. Flink’s transformations include Map and Reduce as known from MapReduce [[1]](http://research.google.com/archive/mapreduce.html) but also operators for joining, co-grouping, and iterative processing. The documentation gives an overview of all available transformations [[2]]({{< param DocsBaseUrl >}}flink-docs-release-0.8/dataset_transformations.html).
+
+Joining two Scala case class data sets is very easy as the following example shows:
+
+```scala
+// define your data types
+case class PageVisit(url: String, ip: String, userId: Long)
+case class User(id: Long, name: String, email: String, country: String)
+
+// get your data from somewhere
+val visits: DataSet[PageVisit] = ...
+val users: DataSet[User] = ...
+
+// filter the users data set
+val germanUsers = users.filter((u) => u.country.equals("de"))
+// join data sets
+val germanVisits: DataSet[(PageVisit, User)] =
+ // equi-join condition (PageVisit.userId = User.id)
+ visits.join(germanUsers).where("userId").equalTo("id")
+
+```
+
+Flink’s APIs also allow to:
+
+* apply a user-defined join function to each pair of joined elements instead returning a `($Left, $Right)` tuple,
+* select fields of pairs of joined Tuple elements (projection), and
+* define composite join keys such as `.where(“orderDate”, “zipCode”).equalTo(“date”, “zip”)`.
+
+See the documentation for more details on Flink’s join features [[3]]({{< param DocsBaseUrl >}}flink-docs-release-0.8/dataset_transformations.html#join).
+
+
+### How does Flink join my data?
+
+Flink uses techniques which are well known from parallel database systems to efficiently execute parallel joins. A join operator must establish all pairs of elements from its input data sets for which the join condition evaluates to true. In a standalone system, the most straight-forward implementation of a join is the so-called nested-loop join which builds the full Cartesian product and evaluates the join condition for each pair of elements. This strategy has quadratic complexity and does obviously not scale to large inputs.
+
+In a distributed system joins are commonly processed in two steps:
+
+1. The data of both inputs is distributed across all parallel instances that participate in the join and
+1. each parallel instance performs a standard stand-alone join algorithm on its local partition of the overall data.
+
+The distribution of data across parallel instances must ensure that each valid join pair can be locally built by exactly one instance. For both steps, there are multiple valid strategies that can be independently picked and which are favorable in different situations. In Flink terminology, the first phase is called Ship Strategy and the second phase Local Strategy. In the following I will describe Flink’s ship and local strategies to join two data sets *R* and *S*.
+
+#### Ship Strategies
+Flink features two ship strategies to establish a valid data partitioning for a join:
+
+* the *Repartition-Repartition* strategy (RR) and
+* the *Broadcast-Forward* strategy (BF).
+
+The Repartition-Repartition strategy partitions both inputs, R and S, on their join key attributes using the same partitioning function. Each partition is assigned to exactly one parallel join instance and all data of that partition is sent to its associated instance. This ensures that all elements that share the same join key are shipped to the same parallel instance and can be locally joined. The cost of the RR strategy is a full shuffle of both data sets over the network.
+
+
+
+
+
+The Broadcast-Forward strategy sends one complete data set (R) to each parallel instance that holds a partition of the other data set (S), i.e., each parallel instance receives the full data set R. Data set S remains local and is not shipped at all. The cost of the BF strategy depends on the size of R and the number of parallel instances it is shipped to. The size of S does not matter because S is not moved. The figure below illustrates how both ship strategies work.
+
+
+
+
+
+The Repartition-Repartition and Broadcast-Forward ship strategies establish suitable data distributions to execute a distributed join. Depending on the operations that are applied before the join, one or even both inputs of a join are already distributed in a suitable way across parallel instances. In this case, Flink will reuse such distributions and only ship one or no input at all.
+
+#### Flink’s Memory Management
+Before delving into the details of Flink’s local join algorithms, I will briefly discuss Flink’s internal memory management. Data processing algorithms such as joining, grouping, and sorting need to hold portions of their input data in memory. While such algorithms perform best if there is enough memory available to hold all data, it is crucial to gracefully handle situations where the data size exceeds memory. Such situations are especially tricky in JVM-based systems such as Flink because the system needs to reliably recognize that it is short on memory. Failure to detect such situations can result in an `OutOfMemoryException` and kill the JVM.
+
+Flink handles this challenge by actively managing its memory. When a worker node (TaskManager) is started, it allocates a fixed portion (70% by default) of the JVM’s heap memory that is available after initialization as 32KB byte arrays. These byte arrays are distributed as working memory to all algorithms that need to hold significant portions of data in memory. The algorithms receive their input data as Java data objects and serialize them into their working memory.
+
+This design has several nice properties. First, the number of data objects on the JVM heap is much lower resulting in less garbage collection pressure. Second, objects on the heap have a certain space overhead and the binary representation is more compact. Especially data sets of many small elements benefit from that. Third, an algorithm knows exactly when the input data exceeds its working memory and can react by writing some of its filled byte arrays to the worker’s local filesystem. After the content of a byte array is written to disk, it can be reused to process more data. Reading data back into memory is as simple as reading the binary data from the local filesystem. The following figure illustrates Flink’s memory management.
+
+
+
+
+
+This active memory management makes Flink extremely robust for processing very large data sets on limited memory resources while preserving all benefits of in-memory processing if data is small enough to fit in-memory. De/serializing data into and from memory has a certain cost overhead compared to simply holding all data elements on the JVM’s heap. However, Flink features efficient custom de/serializers which also allow to perform certain operations such as comparisons directly on serialized data without deserializing data objects from memory.
+
+#### Local Strategies
+
+After the data has been distributed across all parallel join instances using either a Repartition-Repartition or Broadcast-Forward ship strategy, each instance runs a local join algorithm to join the elements of its local partition. Flink’s runtime features two common join strategies to perform these local joins:
+
+* the *Sort-Merge-Join* strategy (SM) and
+* the *Hybrid-Hash-Join* strategy (HH).
+
+The Sort-Merge-Join works by first sorting both input data sets on their join key attributes (Sort Phase) and merging the sorted data sets as a second step (Merge Phase). The sort is done in-memory if the local partition of a data set is small enough. Otherwise, an external merge-sort is done by collecting data until the working memory is filled, sorting it, writing the sorted data to the local filesystem, and starting over by filling the working memory again with more incoming data. After all input data has been received, sorted, and written as sorted runs to the local file system, a fully sorted stream can be obtained. This is done by reading the partially sorted runs from the local filesystem and sort-merging the records on the fly. Once the sorted streams of both inputs are available, both streams are sequentially read and merge-joined in a zig-zag fashion by comparing the sorted join key attributes, building join element pairs for matching keys, and advancing the sorted stream with the lower join key. The figure below shows how the Sort-Merge-Join strategy works.
+
+
+
+
+
+The Hybrid-Hash-Join distinguishes its inputs as build-side and probe-side input and works in two phases, a build phase followed by a probe phase. In the build phase, the algorithm reads the build-side input and inserts all data elements into an in-memory hash table indexed by their join key attributes. If the hash table outgrows the algorithm's working memory, parts of the hash table (ranges of hash indexes) are written to the local filesystem. The build phase ends after the build-side input has been fully consumed. In the probe phase, the algorithm reads the probe-side input and probes the hash table for each element using its join key attribute. If the element falls into a hash index range that was spilled to disk, the element is also written to disk. Otherwise, the element is immediately joined with all matching elements from the hash table. If the hash table completely fits into the working memory, the join is finished after the probe-side input has been fully consumed. Otherwise, the current hash table is dropped and a new hash table is built using spilled parts of the build-side input. This hash table is probed by the corresponding parts of the spilled probe-side input. Eventually, all data is joined. Hybrid-Hash-Joins perform best if the hash table completely fits into the working memory because an arbitrarily large the probe-side input can be processed on-the-fly without materializing it. However even if build-side input does not fit into memory, the the Hybrid-Hash-Join has very nice properties. In this case, in-memory processing is partially preserved and only a fraction of the build-side and probe-side data needs to be written to and read from the local filesystem. The next figure illustrates how the Hybrid-Hash-Join works.
+
+
+
+
+
+### How does Flink choose join strategies?
+
+Ship and local strategies do not depend on each other and can be independently chosen. Therefore, Flink can execute a join of two data sets R and S in nine different ways by combining any of the three ship strategies (RR, BF with R being broadcasted, BF with S being broadcasted) with any of the three local strategies (SM, HH with R being build-side, HH with S being build-side). Each of these strategy combinations results in different execution performance depending on the data sizes and the available amount of working memory. In case of a small data set R and a much larger data set S, broadcasting R and using it as build-side input of a Hybrid-Hash-Join is usually a good choice because the much larger data set S is not shipped and not materialized (given that the hash table completely fits into memory). If both data sets are rather large or the join is performed on many parallel instances, repartitioning both inputs is a robust choice.
+
+Flink features a cost-based optimizer which automatically chooses the execution strategies for all operators including joins. Without going into the details of cost-based optimization, this is done by computing cost estimates for execution plans with different strategies and picking the plan with the least estimated costs. Thereby, the optimizer estimates the amount of data which is shipped over the the network and written to disk. If no reliable size estimates for the input data can be obtained, the optimizer falls back to robust default choices. A key feature of the optimizer is to reason about existing data properties. For example, if the data of one input is already partitioned in a suitable way, the generated candidate plans will not repartition this input. Hence, the choice of a RR ship strategy becomes more likely. The same applies for previously sorted data and the Sort-Merge-Join strategy. Flink programs can help the optimizer to reason about existing data properties by providing semantic information about user-defined functions [[4]]({{< param DocsBaseUrl >}}flink-docs-release-1.0/apis/batch/index.html#semantic-annotations). While the optimizer is a killer feature of Flink, it can happen that a user knows better than the optimizer how to execute a specific join. Similar to relational database systems, Flink offers optimizer hints to tell the optimizer which join strategies to pick [[5]]({{< param DocsBaseUrl >}}flink-docs-release-1.0/apis/batch/dataset_transformations.html#join-algorithm-hints).
+
+### How is Flink’s join performance?
+
+Alright, that sounds good, but how fast are joins in Flink? Let’s have a look. We start with a benchmark of the single-core performance of Flink’s Hybrid-Hash-Join implementation and run a Flink program that executes a Hybrid-Hash-Join with parallelism 1. We run the program on a n1-standard-2 Google Compute Engine instance (2 vCPUs, 7.5GB memory) with two locally attached SSDs. We give 4GB as working memory to the join. The join program generates 1KB records for both inputs on-the-fly, i.e., the data is not read from disk. We run 1:N (Primary-Key/Foreign-Key) joins and generate the smaller input with unique Integer join keys and the larger input with randomly chosen Integer join keys that fall into the key range of the smaller input. Hence, each tuple of the larger side joins with exactly one tuple of the smaller side. The result of the join is immediately discarded. We vary the size of the build-side input from 1 million to 12 million elements (1GB to 12GB). The probe-side input is kept constant at 64 million elements (64GB). The following chart shows the average execution time of three runs for each setup.
+
+
+
+
+
+The joins with 1 to 3 GB build side (blue bars) are pure in-memory joins. The other joins partially spill data to disk (4 to 12GB, orange bars). The results show that the performance of Flink’s Hybrid-Hash-Join remains stable as long as the hash table completely fits into memory. As soon as the hash table becomes larger than the working memory, parts of the hash table and corresponding parts of the probe side are spilled to disk. The chart shows that the performance of the Hybrid-Hash-Join gracefully decreases in this situation, i.e., there is no sharp increase in runtime when the join starts spilling. In combination with Flink’s robust memory management, this execution behavior gives smooth performance without the need for fine-grained, data-dependent memory tuning.
+
+So, Flink’s Hybrid-Hash-Join implementation performs well on a single thread even for limited memory resources, but how good is Flink’s performance when joining larger data sets in a distributed setting? For the next experiment we compare the performance of the most common join strategy combinations, namely:
+
+* Broadcast-Forward, Hybrid-Hash-Join (broadcasting and building with the smaller side),
+* Repartition, Hybrid-Hash-Join (building with the smaller side), and
+* Repartition, Sort-Merge-Join
+
+for different input size ratios:
+
+* 1GB : 1000GB
+* 10GB : 1000GB
+* 100GB : 1000GB
+* 1000GB : 1000GB
+
+The Broadcast-Forward strategy is only executed for up to 10GB. Building a hash table from 100GB broadcasted data in 5GB working memory would result in spilling proximately 95GB (build input) + 950GB (probe input) in each parallel thread and require more than 8TB local disk storage on each machine.
+
+As in the single-core benchmark, we run 1:N joins, generate the data on-the-fly, and immediately discard the result after the join. We run the benchmark on 10 n1-highmem-8 Google Compute Engine instances. Each instance is equipped with 8 cores, 52GB RAM, 40GB of which are configured as working memory (5GB per core), and one local SSD for spilling to disk. All benchmarks are performed using the same configuration, i.e., no fine tuning for the respective data sizes is done. The programs are executed with a parallelism of 80.
+
+
+
+
+
+As expected, the Broadcast-Forward strategy performs best for very small inputs because the large probe side is not shipped over the network and is locally joined. However, when the size of the broadcasted side grows, two problems arise. First the amount of data which is shipped increases but also each parallel instance has to process the full broadcasted data set. The performance of both Repartitioning strategies behaves similar for growing input sizes which indicates that these strategies are mainly limited by the cost of the data transfer (at max 2TB are shipped over the network and joined). Although the Sort-Merge-Join strategy shows the worst performance all shown cases, it has a right to exist because it can nicely exploit sorted input data.
+
+### I’ve got sooo much data to join, do I really need to ship it?
+
+We have seen that off-the-shelf distributed joins work really well in Flink. But what if your data is so huge that you do not want to shuffle it across your cluster? We recently added some features to Flink for specifying semantic properties (partitioning and sorting) on input splits and co-located reading of local input files. With these tools at hand, it is possible to join pre-partitioned data sets from your local filesystem without sending a single byte over your cluster’s network. If the input data is even pre-sorted, the join can be done as a Sort-Merge-Join without sorting, i.e., the join is essentially done on-the-fly. Exploiting co-location requires a very special setup though. Data needs to be stored on the local filesystem because HDFS does not feature data co-location and might move file blocks across data nodes. That means you need to take care of many things yourself which HDFS would have done for you, including replication to avoid data loss. On the other hand, performance gains of joining co-located and pre-sorted can be quite substantial.
+
+### tl;dr: What should I remember from all of this?
+
+* Flink’s fluent Scala and Java APIs make joins and other data transformations easy as cake.
+* The optimizer does the hard choices for you, but gives you control in case you know better.
+* Flink’s join implementations perform very good in-memory and gracefully degrade when going to disk.
+* Due to Flink’s robust memory management, there is no need for job- or data-specific memory tuning to avoid a nasty `OutOfMemoryException`. It just runs out-of-the-box.
+
+#### References
+
+[1] [“MapReduce: Simplified data processing on large clusters”](), Dean, Ghemawat, 2004
+[2] [Flink 0.8.1 documentation: Data Transformations]({{< param DocsBaseUrl >}}flink-docs-release-0.8/dataset_transformations.html)
+[3] [Flink 0.8.1 documentation: Joins]({{< param DocsBaseUrl >}}flink-docs-release-0.8/dataset_transformations.html#join)
+[4] [Flink 1.0 documentation: Semantic annotations]({{< param DocsBaseUrl >}}flink-docs-release-1.0/apis/batch/index.html#semantic-annotations)
+[5] [Flink 1.0 documentation: Optimizer join hints]({{< param DocsBaseUrl >}}flink-docs-release-1.0/apis/batch/dataset_transformations.html#join-algorithm-hints)
diff --git a/docs/content.tr/posts/2015-04-07-march-in-flink.md b/docs/content.tr/posts/2015-04-07-march-in-flink.md
new file mode 100644
index 0000000000..c7a82857bc
--- /dev/null
+++ b/docs/content.tr/posts/2015-04-07-march-in-flink.md
@@ -0,0 +1,66 @@
+---
+date: "2015-04-07T10:00:00Z"
+title: March 2015 in the Flink community
+aliases:
+- /news/2015/04/07/march-in-flink.html
+---
+
+March has been a busy month in the Flink community.
+
+### Scaling ALS
+
+Flink committers employed at [data Artisans](http://data-artisans.com) published a [blog post](http://data-artisans.com/how-to-factorize-a-700-gb-matrix-with-apache-flink/) on how they scaled matrix factorization with Flink and Google Compute Engine to matrices with 28 billion elements.
+
+### Learn about the internals of Flink
+
+The community has started an effort to better document the internals
+of Flink. Check out the first articles on the Flink wiki on [how Flink
+manages
+memory](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=53741525),
+[how tasks in Flink exchange
+data](https://cwiki.apache.org/confluence/display/FLINK/Data+exchange+between+tasks),
+[type extraction and serialization in
+Flink](https://cwiki.apache.org/confluence/display/FLINK/Type+System%2C+Type+Extraction%2C+Serialization),
+as well as [how Flink builds on Akka for distributed
+coordination](https://cwiki.apache.org/confluence/display/FLINK/Akka+and+Actors).
+
+Check out also the [new blog
+post](http://flink.apache.org/news/2015/03/13/peeking-into-Apache-Flinks-Engine-Room.html)
+on how Flink executes joins with several insights into Flink's runtime.
+
+### Meetups and talks
+
+Flink's machine learning efforts were presented at the [Machine
+Learning Stockholm meetup
+group](http://www.meetup.com/Machine-Learning-Stockholm/events/221144997/). The
+regular Berlin Flink meetup featured a talk on the past, present, and
+future of Flink. The talk is available on
+[youtube](https://www.youtube.com/watch?v=fw2DBE6ZiEQ&feature=youtu.be).
+
+## In the Flink master
+
+### Table API in Scala and Java
+
+The new [Table
+API](https://github.com/apache/flink/tree/master/flink-libraries/flink-table)
+in Flink is now available in both Java and Scala. Check out the
+examples [here (Java)](https://github.com/apache/flink/blob/master/flink-libraries/flink-table/src/main/java/org/apache/flink/examples/java/JavaTableExample.java) and [here (Scala)](https://github.com/apache/flink/tree/master/flink-libraries/flink-table/src/main/scala/org/apache/flink/examples/scala).
+
+### Additions to the Machine Learning library
+
+Flink's [Machine Learning
+library](https://github.com/apache/flink/tree/master/flink-libraries/flink-ml)
+is seeing quite a bit of traction. Recent additions include the [CoCoA
+algorithm](http://arxiv.org/abs/1409.1458) for distributed
+optimization.
+
+### Exactly-once delivery guarantees for streaming jobs
+
+Flink streaming jobs now provide exactly once processing guarantees
+when coupled with persistent sources (notably [Apache
+Kafka](http://kafka.apache.org)). Flink periodically checkpoints and
+persists the offsets of the sources and restarts from those
+checkpoints at failure recovery. This functionality is currently
+limited in that it does not yet handle large state and iterative
+programs.
+
diff --git a/docs/content.tr/posts/2015-04-13-release-0.9.0-milestone1.md b/docs/content.tr/posts/2015-04-13-release-0.9.0-milestone1.md
new file mode 100644
index 0000000000..cff0d2d963
--- /dev/null
+++ b/docs/content.tr/posts/2015-04-13-release-0.9.0-milestone1.md
@@ -0,0 +1,230 @@
+---
+date: "2015-04-13T10:00:00Z"
+title: Announcing Flink 0.9.0-milestone1 preview release
+aliases:
+- /news/2015/04/13/release-0.9.0-milestone1.html
+---
+
+The Apache Flink community is pleased to announce the availability of
+the 0.9.0-milestone-1 release. The release is a preview of the
+upcoming 0.9.0 release. It contains many new features which will be
+available in the upcoming 0.9 release. Interested users are encouraged
+to try it out and give feedback. As the version number indicates, this
+release is a preview release that contains known issues.
+
+You can download the release
+[here](http://flink.apache.org/downloads.html#preview) and check out the
+latest documentation
+[here]({{< param DocsBaseUrl >}}flink-docs-master/). Feedback
+through the Flink [mailing
+lists](http://flink.apache.org/community.html#mailing-lists) is, as
+always, very welcome!
+
+## New Features
+
+### Table API
+
+Flink’s new Table API offers a higher-level abstraction for
+interacting with structured data sources. The Table API allows users
+to execute logical, SQL-like queries on distributed data sets while
+allowing them to freely mix declarative queries with regular Flink
+operators. Here is an example that groups and joins two tables:
+
+```scala
+val clickCounts = clicks
+ .groupBy('user).select('userId, 'url.count as 'count)
+
+val activeUsers = users.join(clickCounts)
+ .where('id === 'userId && 'count > 10).select('username, 'count, ...)
+```
+
+Tables consist of logical attributes that can be selected by name
+rather than physical Java and Scala data types. This alleviates a lot
+of boilerplate code for common ETL tasks and raises the abstraction
+for Flink programs. Tables are available for both static and streaming
+data sources (DataSet and DataStream APIs).
+
+Check out the Table guide for Java and Scala
+[here]({{< param DocsBaseUrl >}}flink-docs-master/apis/batch/libs/table.html).
+
+### Gelly Graph Processing API
+
+Gelly is a Java Graph API for Flink. It contains a set of utilities
+for graph analysis, support for iterative graph processing and a
+library of graph algorithms. Gelly exposes a Graph data structure that
+wraps DataSets for vertices and edges, as well as methods for creating
+graphs from DataSets, graph transformations and utilities (e.g., in-
+and out- degrees of vertices), neighborhood aggregations, iterative
+vertex-centric graph processing, as well as a library of common graph
+algorithms, including PageRank, SSSP, label propagation, and community
+detection.
+
+Gelly internally builds on top of Flink’s [delta
+iterations]({{< param DocsBaseUrl >}}flink-docs-master/apis/batch/iterations.html). Iterative
+graph algorithms are executed leveraging mutable state, achieving
+similar performance with specialized graph processing systems.
+
+Gelly will eventually subsume Spargel, Flink’s Pregel-like API. Check
+out the Gelly guide
+[here]({{< param DocsBaseUrl >}}flink-docs-master/apis/batch/libs/gelly.html).
+
+### Flink Machine Learning Library
+
+This release includes the first version of Flink’s Machine Learning
+library. The library’s pipeline approach, which has been strongly
+inspired by scikit-learn’s abstraction of transformers and estimators,
+makes it easy to quickly set up a data processing pipeline and to get
+your job done.
+
+Flink distinguishes between transformers and learners. Transformers
+are components which transform your input data into a new format
+allowing you to extract features, cleanse your data or to sample from
+it. Learners on the other hand constitute the components which take
+your input data and train a model on it. The model you obtain from the
+learner can then be evaluated and used to make predictions on unseen
+data.
+
+Currently, the machine learning library contains transformers and
+learners to do multiple tasks. The library supports multiple linear
+regression using a stochastic gradient implementation to scale to
+large data sizes. Furthermore, it includes an alternating least
+squares (ALS) implementation to factorizes large matrices. The matrix
+factorization can be used to do collaborative filtering. An
+implementation of the communication efficient distributed dual
+coordinate ascent (CoCoA) algorithm is the latest addition to the
+library. The CoCoA algorithm can be used to train distributed
+soft-margin SVMs.
+
+### Flink on YARN leveraging Apache Tez
+
+We are introducing a new execution mode for Flink to be able to run
+restricted Flink programs on top of [Apache
+Tez](http://tez.apache.org). This mode retains Flink’s APIs,
+optimizer, as well as Flink’s runtime operators, but instead of
+wrapping those in Flink tasks that are executed by Flink TaskManagers,
+it wraps them in Tez runtime tasks and builds a Tez DAG that
+represents the program.
+
+By using Flink on Tez, users have an additional choice for an
+execution platform for Flink programs. While Flink’s distributed
+runtime favors low latency, streaming shuffles, and iterative
+algorithms, Tez focuses on scalability and elastic resource usage in
+shared YARN clusters.
+
+Get started with Flink on Tez
+[here]({{< param DocsBaseUrl >}}flink-docs-master/setup/flink_on_tez.html).
+
+### Reworked Distributed Runtime on Akka
+
+Flink’s RPC system has been replaced by the widely adopted
+[Akka](http://akka.io) framework. Akka’s concurrency model offers the
+right abstraction to develop a fast as well as robust distributed
+system. By using Akka’s own failure detection mechanism the stability
+of Flink’s runtime is significantly improved, because the system can
+now react in proper form to node outages. Furthermore, Akka improves
+Flink’s scalability by introducing asynchronous messages to the
+system. These asynchronous messages allow Flink to be run on many more
+nodes than before.
+
+### Exactly-once processing on Kafka Streaming Sources
+
+This release introduces stream processing with exacly-once delivery
+guarantees for Flink streaming programs that analyze streaming sources
+that are persisted by [Apache Kafka](http://kafka.apache.org). The
+system is internally tracking the Kafka offsets to ensure that Flink
+can pick up data from Kafka where it left off in case of an failure.
+
+Read
+[here]({{< param DocsBaseUrl >}}flink-docs-master/apis/streaming_guide.html#apache-kafka)
+on how to use the persistent Kafka source.
+
+### Improved YARN support
+
+Flink’s YARN client contains several improvements, such as a detached
+mode for starting a YARN session in the background, the ability to
+submit a single Flink job to a YARN cluster without starting a
+session, including a “fire and forget” mode. Flink is now also able to
+reallocate failed YARN containers to maintain the size of the
+requested cluster. This feature allows to implement fault-tolerant
+setups on top of YARN. There is also an internal Java API to deploy
+and control a running YARN cluster. This is being used by system
+integrators to easily control Flink on YARN within their Hadoop 2
+cluster.
+
+See the YARN docs
+[here]({{< param DocsBaseUrl >}}flink-docs-master/setup/yarn_setup.html).
+
+## More Improvements and Fixes
+
+* [FLINK-1605](https://issues.apache.org/jira/browse/FLINK-1605):
+ Flink is not exposing its Guava and ASM dependencies to Maven
+ projects depending on Flink. We use the maven-shade-plugin to
+ relocate these dependencies into our own namespace. This allows
+ users to use any Guava or ASM version.
+
+* [FLINK-1417](https://issues.apache.org/jira/browse/FLINK-1605):
+Automatic recognition and registration of Java Types at Kryo and the
+internal serializers: Flink has its own type handling and
+serialization framework falling back to Kryo for types that it cannot
+handle. To get the best performance Flink is automatically registering
+all types a user is using in their program with Kryo.Flink also
+registers serializers for Protocol Buffers, Thrift, Avro and YodaTime
+automatically. Users can also manually register serializers to Kryo
+(https://issues.apache.org/jira/browse/FLINK-1399)
+
+* [FLINK-1296](https://issues.apache.org/jira/browse/FLINK-1296): Add
+ support for sorting very large records
+
+* [FLINK-1679](https://issues.apache.org/jira/browse/FLINK-1679):
+ "degreeOfParallelism" methods renamed to "parallelism"
+
+* [FLINK-1501](https://issues.apache.org/jira/browse/FLINK-1501): Add
+ metrics library for monitoring TaskManagers
+
+* [FLINK-1760](https://issues.apache.org/jira/browse/FLINK-1760): Add
+ support for building Flink with Scala 2.11
+
+* [FLINK-1648](https://issues.apache.org/jira/browse/FLINK-1648): Add
+ a mode where the system automatically sets the parallelism to the
+ available task slots
+
+* [FLINK-1622](https://issues.apache.org/jira/browse/FLINK-1622): Add
+ groupCombine operator
+
+* [FLINK-1589](https://issues.apache.org/jira/browse/FLINK-1589): Add
+ option to pass Configuration to LocalExecutor
+
+* [FLINK-1504](https://issues.apache.org/jira/browse/FLINK-1504): Add
+ support for accessing secured HDFS clusters in standalone mode
+
+* [FLINK-1478](https://issues.apache.org/jira/browse/FLINK-1478): Add
+ strictly local input split assignment
+
+* [FLINK-1512](https://issues.apache.org/jira/browse/FLINK-1512): Add
+ CsvReader for reading into POJOs.
+
+* [FLINK-1461](https://issues.apache.org/jira/browse/FLINK-1461): Add
+ sortPartition operator
+
+* [FLINK-1450](https://issues.apache.org/jira/browse/FLINK-1450): Add
+ Fold operator to the Streaming api
+
+* [FLINK-1389](https://issues.apache.org/jira/browse/FLINK-1389):
+ Allow setting custom file extensions for files created by the
+ FileOutputFormat
+
+* [FLINK-1236](https://issues.apache.org/jira/browse/FLINK-1236): Add
+ support for localization of Hadoop Input Splits
+
+* [FLINK-1179](https://issues.apache.org/jira/browse/FLINK-1179): Add
+ button to JobManager web interface to request stack trace of a
+ TaskManager
+
+* [FLINK-1105](https://issues.apache.org/jira/browse/FLINK-1105): Add
+ support for locally sorted output
+
+* [FLINK-1688](https://issues.apache.org/jira/browse/FLINK-1688): Add
+ socket sink
+
+* [FLINK-1436](https://issues.apache.org/jira/browse/FLINK-1436):
+ Improve usability of command line interface
diff --git a/docs/content.tr/posts/2015-05-11-Juggling-with-Bits-and-Bytes.md b/docs/content.tr/posts/2015-05-11-Juggling-with-Bits-and-Bytes.md
new file mode 100644
index 0000000000..b4c2ae47f1
--- /dev/null
+++ b/docs/content.tr/posts/2015-05-11-Juggling-with-Bits-and-Bytes.md
@@ -0,0 +1,190 @@
+---
+author: Fabian Hüske
+author-twitter: fhueske
+date: "2015-05-11T10:00:00Z"
+excerpt: |-
+ Nowadays, a lot of open-source systems for analyzing large data sets are implemented in Java or other JVM-based programming languages. The most well-known example is Apache Hadoop, but also newer frameworks such as Apache Spark, Apache Drill, and also Apache Flink run on JVMs. A common challenge that JVM-based data analysis engines face is to store large amounts of data in memory - both for caching and for efficient processing such as sorting and joining of data. Managing the JVM memory well makes the difference between a system that is hard to configure and has unpredictable reliability and performance and a system that behaves robustly with few configuration knobs.
+ In this blog post we discuss how Apache Flink manages memory, talk about its custom data de/serialization stack, and show how it operates on binary data.
+title: Juggling with Bits and Bytes
+aliases:
+- /news/2015/05/11/Juggling-with-Bits-and-Bytes.html
+---
+
+## How Apache Flink operates on binary data
+
+Nowadays, a lot of open-source systems for analyzing large data sets are implemented in Java or other JVM-based programming languages. The most well-known example is Apache Hadoop, but also newer frameworks such as Apache Spark, Apache Drill, and also Apache Flink run on JVMs. A common challenge that JVM-based data analysis engines face is to store large amounts of data in memory - both for caching and for efficient processing such as sorting and joining of data. Managing the JVM memory well makes the difference between a system that is hard to configure and has unpredictable reliability and performance and a system that behaves robustly with few configuration knobs.
+
+In this blog post we discuss how Apache Flink manages memory, talk about its custom data de/serialization stack, and show how it operates on binary data.
+
+## Data Objects? Let’s put them on the heap!
+
+The most straight-forward approach to process lots of data in a JVM is to put it as objects on the heap and operate on these objects. Caching a data set as objects would be as simple as maintaining a list containing an object for each record. An in-memory sort would simply sort the list of objects.
+However, this approach has a few notable drawbacks. First of all it is not trivial to watch and control heap memory usage when a lot of objects are created and invalidated constantly. Memory overallocation instantly kills the JVM with an `OutOfMemoryError`. Another aspect is garbage collection on multi-GB JVMs which are flooded with new objects. The overhead of garbage collection in such environments can easily reach 50% and more. Finally, Java objects come with a certain space overhead depending on the JVM and platform. For data sets with many small objects this can significantly reduce the effectively usable amount of memory. Given proficient system design and careful, use-case specific system parameter tuning, heap memory usage can be more or less controlled and `OutOfMemoryErrors` avoided. However, such setups are rather fragile especially if data characteristics or the execution environment change.
+
+## What is Flink doing about that?
+
+Apache Flink has its roots at a research project which aimed to combine the best technologies of MapReduce-based systems and parallel database systems. Coming from this background, Flink has always had its own way of processing data in-memory. Instead of putting lots of objects on the heap, Flink serializes objects into a fixed number of pre-allocated memory segments. Its DBMS-style sort and join algorithms operate as much as possible on this binary data to keep the de/serialization overhead at a minimum. If more data needs to be processed than can be kept in memory, Flink’s operators partially spill data to disk. In fact, a lot of Flink’s internal implementations look more like C/C++ rather than common Java. The following figure gives a high-level overview of how Flink stores data serialized in memory segments and spills to disk if necessary.
+
+
+
+
+
+Flink’s style of active memory management and operating on binary data has several benefits:
+
+1. **Memory-safe execution & efficient out-of-core algorithms.** Due to the fixed amount of allocated memory segments, it is trivial to monitor remaining memory resources. In case of memory shortage, processing operators can efficiently write larger batches of memory segments to disk and later them read back. Consequently, `OutOfMemoryErrors` are effectively prevented.
+2. **Reduced garbage collection pressure.** Because all long-lived data is in binary representation in Flink's managed memory, all data objects are short-lived or even mutable and can be reused. Short-lived objects can be more efficiently garbage-collected, which significantly reduces garbage collection pressure. Right now, the pre-allocated memory segments are long-lived objects on the JVM heap, but the Flink community is actively working on allocating off-heap memory for this purpose. This effort will result in much smaller JVM heaps and facilitate even faster garbage collection cycles.
+3. **Space efficient data representation.** Java objects have a storage overhead which can be avoided if the data is stored in a binary representation.
+4. **Efficient binary operations & cache sensitivity.** Binary data can be efficiently compared and operated on given a suitable binary representation. Furthermore, the binary representations can put related values, as well as hash codes, keys, and pointers, adjacently into memory. This gives data structures with usually more cache efficient access patterns.
+
+These properties of active memory management are very desirable in a data processing systems for large-scale data analytics but have a significant price tag attached. Active memory management and operating on binary data is not trivial to implement, i.e., using `java.util.HashMap` is much easier than implementing a spillable hash-table backed by byte arrays and a custom serialization stack. Of course Apache Flink is not the only JVM-based data processing system that operates on serialized binary data. Projects such as [Apache Drill](http://drill.apache.org/), [Apache Ignite (incubating)](http://ignite.incubator.apache.org/) or [Apache Geode (incubating)](http://projectgeode.org/) apply similar techniques and it was recently announced that also [Apache Spark](http://spark.apache.org/) will evolve into this direction with [Project Tungsten](https://databricks.com/blog/2015/04/28/project-tungsten-bringing-spark-closer-to-bare-metal.html).
+
+In the following we discuss in detail how Flink allocates memory, de/serializes objects, and operates on binary data. We will also show some performance numbers comparing processing objects on the heap and operating on binary data.
+
+
+## How does Flink allocate memory?
+
+A Flink worker, called TaskManager, is composed of several internal components such as an actor system for coordination with the Flink master, an IOManager that takes care of spilling data to disk and reading it back, and a MemoryManager that coordinates memory usage. In the context of this blog post, the MemoryManager is of most interest.
+
+The MemoryManager takes care of allocating, accounting, and distributing MemorySegments to data processing operators such as sort and join operators. A [MemorySegment](https://github.com/apache/flink/blob/release-0.9.0-milestone-1/flink-core/src/main/java/org/apache/flink/core/memory/MemorySegment.java) is Flink’s distribution unit of memory and is backed by a regular Java byte array (size is 32 KB by default). A MemorySegment provides very efficient write and read access to its backed byte array using Java’s unsafe methods. You can think of a MemorySegment as a custom-tailored version of Java’s NIO ByteBuffer. In order to operate on multiple MemorySegments like on a larger chunk of consecutive memory, Flink uses logical views that implement Java’s `java.io.DataOutput` and `java.io.DataInput` interfaces.
+
+MemorySegments are allocated once at TaskManager start-up time and are destroyed when the TaskManager is shut down. Hence, they are reused and not garbage-collected over the whole lifetime of a TaskManager. After all internal data structures of a TaskManager have been initialized and all core services have been started, the MemoryManager starts creating MemorySegments. By default 70% of the JVM heap that is available after service initialization is allocated by the MemoryManager. It is also possible to configure an absolute amount of managed memory. The remaining JVM heap is used for objects that are instantiated during task processing, including objects created by user-defined functions. The following figure shows the memory distribution in the TaskManager JVM after startup.
+
+
+
+
+
+## How does Flink serialize objects?
+
+The Java ecosystem offers several libraries to convert objects into a binary representation and back. Common alternatives are standard Java serialization, [Kryo](https://github.com/EsotericSoftware/kryo), [Apache Avro](http://avro.apache.org/), [Apache Thrift](http://thrift.apache.org/), or Google’s [Protobuf](https://github.com/google/protobuf). Flink includes its own custom serialization framework in order to control the binary representation of data. This is important because operating on binary data such as comparing or even manipulating binary data requires exact knowledge of the serialization layout. Further, configuring the serialization layout with respect to operations that are performed on binary data can yield a significant performance boost. Flink’s serialization stack also leverages the fact, that the type of the objects which are going through de/serialization are exactly known before a program is executed.
+
+Flink programs can process data represented as arbitrary Java or Scala objects. Before a program is optimized, the data types at each processing step of the program’s data flow need to be identified. For Java programs, Flink features a reflection-based type extraction component to analyze the return types of user-defined functions. Scala programs are analyzed with help of the Scala compiler. Flink represents each data type with a [TypeInformation](https://github.com/apache/flink/blob/release-0.9.0-milestone-1/flink-core/src/main/java/org/apache/flink/api/common/typeinfo/TypeInformation.java). Flink has TypeInformations for several kinds of data types, including:
+
+* BasicTypeInfo: Any (boxed) Java primitive type or java.lang.String.
+* BasicArrayTypeInfo: Any array of a (boxed) Java primitive type or java.lang.String.
+* WritableTypeInfo: Any implementation of Hadoop’s Writable interface.
+* TupleTypeInfo: Any Flink tuple (Tuple1 to Tuple25). Flink tuples are Java representations for fixed-length tuples with typed fields.
+* CaseClassTypeInfo: Any Scala CaseClass (including Scala tuples).
+* PojoTypeInfo: Any POJO (Java or Scala), i.e., an object with all fields either being public or accessible through getters and setter that follow the common naming conventions.
+* GenericTypeInfo: Any data type that cannot be identified as another type.
+
+Each TypeInformation provides a serializer for the data type it represents. For example, a BasicTypeInfo returns a serializer that writes the respective primitive type, the serializer of a WritableTypeInfo delegates de/serialization to the write() and readFields() methods of the object implementing Hadoop’s Writable interface, and a GenericTypeInfo returns a serializer that delegates serialization to Kryo. Object serialization to a DataOutput which is backed by Flink MemorySegments goes automatically through Java’s efficient unsafe operations. For data types that can be used as keys, i.e., compared and hashed, the TypeInformation provides TypeComparators. TypeComparators compare and hash objects and can - depending on the concrete data type - also efficiently compare binary representations and extract fixed-length binary key prefixes.
+
+Tuple, Pojo, and CaseClass types are composite types, i.e., containers for one or more possibly nested data types. As such, their serializers and comparators are also composite and delegate the serialization and comparison of their member data types to the respective serializers and comparators. The following figure illustrates the serialization of a (nested) `Tuple3` object where `Person` is a POJO and defined as follows:
+
+```java
+public class Person {
+ public int id;
+ public String name;
+}
+```
+
+
+
+
+
+Flink’s type system can be easily extended by providing custom TypeInformations, Serializers, and Comparators to improve the performance of serializing and comparing custom data types.
+
+## How does Flink operate on binary data?
+
+Similar to many other data processing APIs (including SQL), Flink’s APIs provide transformations to group, sort, and join data sets. These transformations operate on potentially very large data sets. Relational database systems feature very efficient algorithms for these purposes since several decades including external merge-sort, merge-join, and hybrid hash-join. Flink builds on this technology, but generalizes it to handle arbitrary objects using its custom serialization and comparison stack. In the following, we show how Flink operates with binary data by the example of Flink’s in-memory sort algorithm.
+
+Flink assigns a memory budget to its data processing operators. Upon initialization, a sort algorithm requests its memory budget from the MemoryManager and receives a corresponding set of MemorySegments. The set of MemorySegments becomes the memory pool of a so-called sort buffer which collects the data that is be sorted. The following figure illustrates how data objects are serialized into the sort buffer.
+
+
+
+
+
+The sort buffer is internally organized into two memory regions. The first region holds the full binary data of all objects. The second region contains pointers to the full binary object data and - depending on the key data type - fixed-length sort keys. When an object is added to the sort buffer, its binary data is appended to the first region, and a pointer (and possibly a key) is appended to the second region. The separation of actual data and pointers plus fixed-length keys is done for two purposes. It enables efficient swapping of fix-length entries (key+pointer) and also reduces the data that needs to be moved when sorting. If the sort key is a variable length data type such as a String, the fixed-length sort key must be a prefix key such as the first n characters of a String. Note, not all data types provide a fixed-length (prefix) sort key. When serializing objects into the sort buffer, both memory regions are extended with MemorySegments from the memory pool. Once the memory pool is empty and no more objects can be added, the sort buffer is completely filled and can be sorted. Flink’s sort buffer provides methods to compare and swap elements. This makes the actual sort algorithm pluggable. By default, Flink uses a Quicksort implementation which can fall back to HeapSort.
+The following figure shows how two objects are compared.
+
+
+
+
+
+The sort buffer compares two elements by comparing their binary fix-length sort keys. The comparison is successful if either done on a full key (not a prefix key) or if the binary prefix keys are not equal. If the prefix keys are equal (or the sort key data type does not provide a binary prefix key), the sort buffer follows the pointers to the actual object data, deserializes both objects and compares the objects. Depending on the result of the comparison, the sort algorithm decides whether to swap the compared elements or not. The sort buffer swaps two elements by moving their fix-length keys and pointers. The actual data is not moved. Once the sort algorithm finishes, the pointers in the sort buffer are correctly ordered. The following figure shows how the sorted data is returned from the sort buffer.
+
+
+
+
+
+The sorted data is returned by sequentially reading the pointer region of the sort buffer, skipping the sort keys and following the sorted pointers to the actual data. This data is either deserialized and returned as objects or the binary representation is copied and written to disk in case of an external merge-sort (see this [blog post on joins in Flink](http://flink.apache.org/news/2015/03/13/peeking-into-Apache-Flinks-Engine-Room.html)).
+
+## Show me numbers!
+
+So, what does operating on binary data mean for performance? We’ll run a benchmark that sorts 10 million `Tuple2` objects to find out. The values of the Integer field are sampled from a uniform distribution. The String field values have a length of 12 characters and are sampled from a long-tail distribution. The input data is provided by an iterator that returns a mutable object, i.e., the same tuple object instance is returned with different field values. Flink uses this technique when reading data from memory, network, or disk to avoid unnecessary object instantiations. The benchmarks are run in a JVM with 900 MB heap size which is approximately the required amount of memory to store and sort 10 million tuple objects on the heap without dying of an `OutOfMemoryError`. We sort the tuples on the Integer field and on the String field using three sorting methods:
+
+1. **Object-on-heap.** The tuples are stored in a regular `java.util.ArrayList` with initial capacity set to 10 million entries and sorted using Java’s regular collection sort.
+2. **Flink-serialized.** The tuple fields are serialized into a sort buffer of 600 MB size using Flink’s custom serializers, sorted as described above, and finally deserialized again. When sorting on the Integer field, the full Integer is used as sort key such that the sort happens entirely on binary data (no deserialization of objects required). For sorting on the String field a 8-byte prefix key is used and tuple objects are deserialized if the prefix keys are equal.
+3. **Kryo-serialized.** The tuple fields are serialized into a sort buffer of 600 MB size using Kryo serialization and sorted without binary sort keys. This means that each pair-wise comparison requires two object to be deserialized.
+
+All sort methods are implemented using a single thread. The reported times are averaged over ten runs. After each run, we call `System.gc()` to request a garbage collection run which does not go into measured execution time. The following figure shows the time to store the input data in memory, sort it, and read it back as objects.
+
+
+
+
+
+We see that Flink’s sort on binary data using its own serializers significantly outperforms the other two methods. Comparing to the object-on-heap method, we see that loading the data into memory is much faster. Since we actually collect the objects, there is no opportunity to reuse the object instances, but have to re-create every tuple. This is less efficient than Flink’s serializers (or Kryo serialization). On the other hand, reading objects from the heap comes for free compared to deserialization. In our benchmark, object cloning was more expensive than serialization and deserialization combined. Looking at the sorting time, we see that also sorting on the binary representation is faster than Java’s collection sort. Sorting data that was serialized using Kryo without binary sort key, is much slower than both other methods. This is due to the heavy deserialization overhead. Sorting the tuples on their String field is faster than sorting on the Integer field due to the long-tailed value distribution which significantly reduces the number of pair-wise comparisons. To get a better feeling of what is happening during sorting we monitored the executing JVM using VisualVM. The following screenshots show heap memory usage, garbage collection activity and CPU usage over the execution of 10 runs.
+
+
+
+
+ Garbage Collection
+ Memory Usage
+
+
+ Object-on-Heap (int)
+
+
+
+
+ Flink-Serialized (int)
+
+
+
+
+ Kryo-Serialized (int)
+
+
+
+
+
+The experiments run single-threaded on an 8-core machine, so full utilization of one core only corresponds to a 12.5% overall utilization. The screenshots show that operating on binary data significantly reduces garbage collection activity. For the object-on-heap approach, the garbage collector runs in very short intervals while filling the sort buffer and causes a lot of CPU usage even for a single processing thread (sorting itself does not trigger the garbage collector). The JVM garbage collects with multiple parallel threads, explaining the high overall CPU utilization. On the other hand, the methods that operate on serialized data rarely trigger the garbage collector and have a much lower CPU utilization. In fact the garbage collector does not run at all if the tuples are sorted on the Integer field using the flink-serialized method because no objects need to be deserialized for pair-wise comparisons. The kryo-serialized method requires slightly more garbage collection since it does not use binary sort keys and deserializes two objects for each comparison.
+
+The memory usage charts shows that the flink-serialized and kryo-serialized constantly occupy a high amount of memory (plus some objects for operation). This is due to the pre-allocation of MemorySegments. The actual memory usage is much lower, because the sort buffers are not completely filled. The following table shows the memory consumption of each method. 10 million records result in about 280 MB of binary data (object data plus pointers and sort keys) depending on the used serializer and presence and size of a binary sort key. Comparing this to the memory requirements of the object-on-heap approach we see that operating on binary data can significantly improve memory efficiency. In our benchmark more than twice as much data can be sorted in-memory if serialized into a sort buffer instead of holding it as objects on the heap.
+
+
+
+ Occupied Memory
+ Object-on-Heap
+ Flink-Serialized
+ Kryo-Serialized
+
+
+ Sort on Integer
+ approx. 700 MB (heap)
+ 277 MB (sort buffer)
+ 266 MB (sort buffer)
+
+
+ Sort on String
+ approx. 700 MB (heap)
+ 315 MB (sort buffer)
+ 266 MB (sort buffer)
+
+
+
+
+
+To summarize, the experiments verify the previously stated benefits of operating on binary data.
+
+## We’re not done yet!
+
+Apache Flink features quite a bit of advanced techniques to safely and efficiently process huge amounts of data with limited memory resources. However, there are a few points that could make Flink even more efficient. The Flink community is working on moving the managed memory to off-heap memory. This will allow for smaller JVMs, lower garbage collection overhead, and also easier system configuration. With Flink’s Table API, the semantics of all operations such as aggregations and projections are known (in contrast to black-box user-defined functions). Hence we can generate code for Table API operations that directly operates on binary data. Further improvements include serialization layouts which are tailored towards the operations that are applied on the binary data and code generation for serializers and comparators.
+
+The groundwork (and a lot more) for operating on binary data is done but there is still some room for making Flink even better and faster. If you are crazy about performance and like to juggle with lot of bits and bytes, join the Flink community!
+
+## TL;DR; Give me three things to remember!
+
+* Flink’s active memory management avoids nasty `OutOfMemoryErrors` that kill your JVMs and reduces garbage collection overhead.
+* Flink features a highly efficient data de/serialization stack that facilitates operations on binary data and makes more data fit into memory.
+* Flink’s DBMS-style operators operate natively on binary data yielding high performance in-memory and destage gracefully to disk if necessary.
diff --git a/docs/content.tr/posts/2015-05-14-Community-update-April.md b/docs/content.tr/posts/2015-05-14-Community-update-April.md
new file mode 100644
index 0000000000..9fdaf2b9c2
--- /dev/null
+++ b/docs/content.tr/posts/2015-05-14-Community-update-April.md
@@ -0,0 +1,45 @@
+---
+author: Kostas Tzoumas
+author-twitter: kostas_tzoumas
+date: "2015-05-14T10:00:00Z"
+excerpt: The monthly update from the Flink community. Including the availability
+ of a new preview release, lots of meetups and conference talks and a great interview
+ about Flink.
+title: April 2015 in the Flink community
+aliases:
+- /news/2015/05/14/Community-update-April.html
+---
+
+
+April was an packed month for Apache Flink.
+
+### Flink runner for Google Cloud Dataflow
+
+A Flink runner for Google Cloud Dataflow was announced. See the blog
+posts by [data Artisans](http://data-artisans.com/announcing-google-cloud-dataflow-on-flink-and-easy-flink-deployment-on-google-cloud/) and
+the [Google Cloud Platform Blog](http://googlecloudplatform.blogspot.de/2015/03/announcing-Google-Cloud-Dataflow-runner-for-Apache-Flink.html).
+Google Cloud Dataflow programs can be written using and open-source
+SDK and run in multiple backends, either as a managed service inside
+Google's infrastructure, or leveraging open source runners,
+including Apache Flink.
+
+
+## Flink 0.9.0-milestone1 release
+
+The highlight of April was of course the availability of [Flink 0.9-milestone1](/news/2015/04/13/release-0.9.0-milestone1.html). This was a release packed with new features, including, a Python DataSet API, the new SQL-like Table API, FlinkML, a machine learning library on Flink, Gelly, FLink's Graph API, as well as a mode to run Flink on YARN leveraging Tez. In case you missed it, check out the [release announcement blog post](/news/2015/04/13/release-0.9.0-milestone1.html) for details
+
+## Conferences and meetups
+
+April kicked off the conference season. Apache Flink was presented at ApacheCon in Texas ([slides](http://www.slideshare.net/fhueske/apache-flink)), the Hadoop Summit in Brussels featured two talks on Flink (see slides [here](http://www.slideshare.net/AljoschaKrettek/data-analysis-with-apache-flink-hadoop-summit-2015) and [here](http://www.slideshare.net/GyulaFra/flink-streaming-hadoopsummit)), as well as at the Hadoop User Groups of the Netherlands ([slides](http://www.slideshare.net/stephanewen1/apache-flink-overview-and-use-cases-at-prehadoop-summit-meetups)) and Stockholm. The brand new [Apache Flink meetup Stockholm](http://www.meetup.com/Apache-Flink-Stockholm/) was also established.
+
+## Google Summer of Code
+
+Three students will work on Flink during Google's [Summer of Code program](https://www.google-melange.com/gsoc/homepage/google/gsoc2015) on distributed pattern matching, exact and approximate statistics for data streams and windows, as well as asynchronous iterations and updates.
+
+## Flink on the web
+
+Fabian Hueske gave an [interview at InfoQ](http://www.infoq.com/news/2015/04/hueske-apache-flink?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global) on Apache Flink.
+
+## Upcoming events
+
+Stay tuned for a wealth of upcoming events! Two Flink talsk will be presented at [Berlin Buzzwords](http://berlinbuzzwords.de/15/sessions), Flink will be presented at the [Hadoop Summit in San Jose](http://2015.hadoopsummit.org/san-jose/). A [training workshop on Apache Flink](http://www.meetup.com/Apache-Flink-Meetup/events/220557545/) is being organized in Berlin. Finally, [Flink Forward](http://2015.flink-forward.org/), the first conference to bring together the whole Flink community is taking place in Berlin in October 2015.
diff --git a/docs/content.tr/posts/2015-06-24-announcing-apache-flink-0.9.0-release.md b/docs/content.tr/posts/2015-06-24-announcing-apache-flink-0.9.0-release.md
new file mode 100644
index 0000000000..81a5fb4ae1
--- /dev/null
+++ b/docs/content.tr/posts/2015-06-24-announcing-apache-flink-0.9.0-release.md
@@ -0,0 +1,190 @@
+---
+date: "2015-06-24T14:00:00Z"
+title: Announcing Apache Flink 0.9.0
+aliases:
+- /news/2015/06/24/announcing-apache-flink-0.9.0-release.html
+---
+
+The Apache Flink community is pleased to announce the availability of the 0.9.0 release. The release is the result of many months of hard work within the Flink community. It contains many new features and improvements which were previewed in the 0.9.0-milestone1 release and have been polished since then. This is the largest Flink release so far.
+
+[Download the release](http://flink.apache.org/downloads.html) and check out [the documentation]({{< param DocsBaseUrl >}}flink-docs-release-0.9/). Feedback through the Flink[ mailing lists](http://flink.apache.org/community.html#mailing-lists) is, as always, very welcome!
+
+## New Features
+
+### Exactly-once Fault Tolerance for streaming programs
+
+This release introduces a new fault tolerance mechanism for streaming dataflows. The new checkpointing algorithm takes data sources and also user-defined state into account and recovers failures such that all records are reflected exactly once in the operator states.
+
+The checkpointing algorithm is lightweight and driven by barriers that are periodically injected into the data streams at the sources. As such, it has an extremely low coordination overhead and is able to sustain very high throughput rates. User-defined state can be automatically backed up to configurable storage by the fault tolerance mechanism.
+
+Please refer to [the documentation on stateful computation]({{< param DocsBaseUrl >}}flink-docs-release-0.9/apis/streaming_guide.html#stateful-computation) for details in how to use fault tolerant data streams with Flink.
+
+The fault tolerance mechanism requires data sources that can replay recent parts of the stream, such as [Apache Kafka](http://kafka.apache.org). Read more [about how to use the persistent Kafka source]({{< param DocsBaseUrl >}}flink-docs-release-0.9/apis/streaming_guide.html#apache-kafka).
+
+### Table API
+
+Flink’s new Table API offers a higher-level abstraction for interacting with structured data sources. The Table API allows users to execute logical, SQL-like queries on distributed data sets while allowing them to freely mix declarative queries with regular Flink operators. Here is an example that groups and joins two tables:
+
+```scala
+val clickCounts = clicks
+ .groupBy('user).select('userId, 'url.count as 'count)
+
+val activeUsers = users.join(clickCounts)
+ .where('id === 'userId && 'count > 10).select('username, 'count, ...)
+```
+
+Tables consist of logical attributes that can be selected by name rather than physical Java and Scala data types. This alleviates a lot of boilerplate code for common ETL tasks and raises the abstraction for Flink programs. Tables are available for both static and streaming data sources (DataSet and DataStream APIs).
+
+[Check out the Table guide for Java and Scala]({{< param DocsBaseUrl >}}flink-docs-release-0.9/libs/table.html).
+
+### Gelly Graph Processing API
+
+Gelly is a Java Graph API for Flink. It contains a set of utilities for graph analysis, support for iterative graph processing and a library of graph algorithms. Gelly exposes a Graph data structure that wraps DataSets for vertices and edges, as well as methods for creating graphs from DataSets, graph transformations and utilities (e.g., in- and out- degrees of vertices), neighborhood aggregations, iterative vertex-centric graph processing, as well as a library of common graph algorithms, including PageRank, SSSP, label propagation, and community detection.
+
+Gelly internally builds on top of Flink’s[ delta iterations]({{< param DocsBaseUrl >}}flink-docs-release-0.9/apis/iterations.html). Iterative graph algorithms are executed leveraging mutable state, achieving similar performance with specialized graph processing systems.
+
+Gelly will eventually subsume Spargel, Flink’s Pregel-like API.
+
+Note: The Gelly library is still in beta status and subject to improvements and heavy performance tuning.
+
+[Check out the Gelly guide]({{< param DocsBaseUrl >}}flink-docs-release-0.9/libs/gelly_guide.html).
+
+### Flink Machine Learning Library
+
+This release includes the first version of Flink’s Machine Learning library. The library’s pipeline approach, which has been strongly inspired by scikit-learn’s abstraction of transformers and predictors, makes it easy to quickly set up a data processing pipeline and to get your job done.
+
+Flink distinguishes between transformers and predictors. Transformers are components which transform your input data into a new format allowing you to extract features, cleanse your data or to sample from it. Predictors on the other hand constitute the components which take your input data and train a model on it. The model you obtain from the learner can then be evaluated and used to make predictions on unseen data.
+
+Currently, the machine learning library contains transformers and predictors to do multiple tasks. The library supports multiple linear regression using stochastic gradient descent to scale to large data sizes. Furthermore, it includes an alternating least squares (ALS) implementation to factorizes large matrices. The matrix factorization can be used to do collaborative filtering. An implementation of the communication efficient distributed dual coordinate ascent (CoCoA) algorithm is the latest addition to the library. The CoCoA algorithm can be used to train distributed soft-margin SVMs.
+
+Note: The ML library is still in beta status and subject to improvements and heavy performance tuning.
+
+[Check out FlinkML]({{< param DocsBaseUrl >}}flink-docs-release-0.9/libs/ml/)
+
+### Flink on YARN leveraging Apache Tez
+
+We are introducing a new execution mode for Flink to be able to run restricted Flink programs on top of[ Apache Tez](http://tez.apache.org). This mode retains Flink’s APIs, optimizer, as well as Flink’s runtime operators, but instead of wrapping those in Flink tasks that are executed by Flink TaskManagers, it wraps them in Tez runtime tasks and builds a Tez DAG that represents the program.
+
+By using Flink on Tez, users have an additional choice for an execution platform for Flink programs. While Flink’s distributed runtime favors low latency, streaming shuffles, and iterative algorithms, Tez focuses on scalability and elastic resource usage in shared YARN clusters.
+
+[Get started with Flink on Tez]({{< param DocsBaseUrl >}}flink-docs-release-0.9/setup/flink_on_tez.html).
+
+### Reworked Distributed Runtime on Akka
+
+Flink’s RPC system has been replaced by the widely adopted[ Akka](http://akka.io) framework. Akka’s concurrency model offers the right abstraction to develop a fast as well as robust distributed system. By using Akka’s own failure detection mechanism the stability of Flink’s runtime is significantly improved, because the system can now react in proper form to node outages. Furthermore, Akka improves Flink’s scalability by introducing asynchronous messages to the system. These asynchronous messages allow Flink to be run on many more nodes than before.
+
+### Improved YARN support
+
+Flink’s YARN client contains several improvements, such as a detached mode for starting a YARN session in the background, the ability to submit a single Flink job to a YARN cluster without starting a session, including a "fire and forget" mode. Flink is now also able to reallocate failed YARN containers to maintain the size of the requested cluster. This feature allows to implement fault-tolerant setups on top of YARN. There is also an internal Java API to deploy and control a running YARN cluster. This is being used by system integrators to easily control Flink on YARN within their Hadoop 2 cluster.
+
+[See the YARN docs]({{< param DocsBaseUrl >}}flink-docs-release-0.9/setup/yarn_setup.html).
+
+### Static Code Analysis for the Flink Optimizer: Opening the UDF blackboxes
+
+This release introduces a first version of a static code analyzer that pre-interprets functions written by the user to get information about the function’s internal dataflow. The code analyzer can provide useful information about [forwarded fields]({{< param DocsBaseUrl >}}flink-docs-release-0.9/apis/programming_guide.html#semantic-annotations) to Flink's optimizer and thus speedup job executions. It also informs if the code contains obvious mistakes. For stability reasons, the code analyzer is initially disabled by default. It can be activated through
+
+ExecutionEnvironment.getExecutionConfig().setCodeAnalysisMode(...)
+
+either as an assistant that gives hints during the implementation or by directly applying the optimizations that have been found.
+
+## More Improvements and Fixes
+
+* [FLINK-1605](https://issues.apache.org/jira/browse/FLINK-1605): Flink is not exposing its Guava and ASM dependencies to Maven projects depending on Flink. We use the maven-shade-plugin to relocate these dependencies into our own namespace. This allows users to use any Guava or ASM version.
+
+* [FLINK-1417](https://issues.apache.org/jira/browse/FLINK-1605): Automatic recognition and registration of Java Types at Kryo and the internal serializers: Flink has its own type handling and serialization framework falling back to Kryo for types that it cannot handle. To get the best performance Flink is automatically registering all types a user is using in their program with Kryo.Flink also registers serializers for Protocol Buffers, Thrift, Avro and YodaTime automatically. Users can also manually register serializers to Kryo (https://issues.apache.org/jira/browse/FLINK-1399)
+
+* [FLINK-1296](https://issues.apache.org/jira/browse/FLINK-1296): Add support for sorting very large records
+
+* [FLINK-1679](https://issues.apache.org/jira/browse/FLINK-1679): "degreeOfParallelism" methods renamed to “parallelism”
+
+* [FLINK-1501](https://issues.apache.org/jira/browse/FLINK-1501): Add metrics library for monitoring TaskManagers
+
+* [FLINK-1760](https://issues.apache.org/jira/browse/FLINK-1760): Add support for building Flink with Scala 2.11
+
+* [FLINK-1648](https://issues.apache.org/jira/browse/FLINK-1648): Add a mode where the system automatically sets the parallelism to the available task slots
+
+* [FLINK-1622](https://issues.apache.org/jira/browse/FLINK-1622): Add groupCombine operator
+
+* [FLINK-1589](https://issues.apache.org/jira/browse/FLINK-1589): Add option to pass Configuration to LocalExecutor
+
+* [FLINK-1504](https://issues.apache.org/jira/browse/FLINK-1504): Add support for accessing secured HDFS clusters in standalone mode
+
+* [FLINK-1478](https://issues.apache.org/jira/browse/FLINK-1478): Add strictly local input split assignment
+
+* [FLINK-1512](https://issues.apache.org/jira/browse/FLINK-1512): Add CsvReader for reading into POJOs.
+
+* [FLINK-1461](https://issues.apache.org/jira/browse/FLINK-1461): Add sortPartition operator
+
+* [FLINK-1450](https://issues.apache.org/jira/browse/FLINK-1450): Add Fold operator to the Streaming api
+
+* [FLINK-1389](https://issues.apache.org/jira/browse/FLINK-1389): Allow setting custom file extensions for files created by the FileOutputFormat
+
+* [FLINK-1236](https://issues.apache.org/jira/browse/FLINK-1236): Add support for localization of Hadoop Input Splits
+
+* [FLINK-1179](https://issues.apache.org/jira/browse/FLINK-1179): Add button to JobManager web interface to request stack trace of a TaskManager
+
+* [FLINK-1105](https://issues.apache.org/jira/browse/FLINK-1105): Add support for locally sorted output
+
+* [FLINK-1688](https://issues.apache.org/jira/browse/FLINK-1688): Add socket sink
+
+* [FLINK-1436](https://issues.apache.org/jira/browse/FLINK-1436): Improve usability of command line interface
+
+* [FLINK-2174](https://issues.apache.org/jira/browse/FLINK-2174): Allow comments in 'slaves' file
+
+* [FLINK-1698](https://issues.apache.org/jira/browse/FLINK-1698): Add polynomial base feature mapper to ML library
+
+* [FLINK-1697](https://issues.apache.org/jira/browse/FLINK-1697): Add alternating least squares algorithm for matrix factorization to ML library
+
+* [FLINK-1792](https://issues.apache.org/jira/browse/FLINK-1792): FLINK-456 Improve TM Monitoring: CPU utilization, hide graphs by default and show summary only
+
+* [FLINK-1672](https://issues.apache.org/jira/browse/FLINK-1672): Refactor task registration/unregistration
+
+* [FLINK-2001](https://issues.apache.org/jira/browse/FLINK-2001): DistanceMetric cannot be serialized
+
+* [FLINK-1676](https://issues.apache.org/jira/browse/FLINK-1676): enableForceKryo() is not working as expected
+
+* [FLINK-1959](https://issues.apache.org/jira/browse/FLINK-1959): Accumulators BROKEN after Partitioning
+
+* [FLINK-1696](https://issues.apache.org/jira/browse/FLINK-1696): Add multiple linear regression to ML library
+
+* [FLINK-1820](https://issues.apache.org/jira/browse/FLINK-1820): Bug in DoubleParser and FloatParser - empty String is not casted to 0
+
+* [FLINK-1985](https://issues.apache.org/jira/browse/FLINK-1985): Streaming does not correctly forward ExecutionConfig to runtime
+
+* [FLINK-1828](https://issues.apache.org/jira/browse/FLINK-1828): Impossible to output data to an HBase table
+
+* [FLINK-1952](https://issues.apache.org/jira/browse/FLINK-1952): Cannot run ConnectedComponents example: Could not allocate a slot on instance
+
+* [FLINK-1848](https://issues.apache.org/jira/browse/FLINK-1848): Paths containing a Windows drive letter cannot be used in FileOutputFormats
+
+* [FLINK-1954](https://issues.apache.org/jira/browse/FLINK-1954): Task Failures and Error Handling
+
+* [FLINK-2004](https://issues.apache.org/jira/browse/FLINK-2004): Memory leak in presence of failed checkpoints in KafkaSource
+
+* [FLINK-2132](https://issues.apache.org/jira/browse/FLINK-2132): Java version parsing is not working for OpenJDK
+
+* [FLINK-2098](https://issues.apache.org/jira/browse/FLINK-2098): Checkpoint barrier initiation at source is not aligned with snapshotting
+
+* [FLINK-2069](https://issues.apache.org/jira/browse/FLINK-2069): writeAsCSV function in DataStream Scala API creates no file
+
+* [FLINK-2092](https://issues.apache.org/jira/browse/FLINK-2092): Document (new) behavior of print() and execute()
+
+* [FLINK-2177](https://issues.apache.org/jira/browse/FLINK-2177): NullPointer in task resource release
+
+* [FLINK-2054](https://issues.apache.org/jira/browse/FLINK-2054): StreamOperator rework removed copy calls when passing output to a chained operator
+
+* [FLINK-2196](https://issues.apache.org/jira/browse/FLINK-2196): Missplaced Class in flink-java SortPartitionOperator
+
+* [FLINK-2191](https://issues.apache.org/jira/browse/FLINK-2191): Inconsistent use of Closure Cleaner in Streaming API
+
+* [FLINK-2206](https://issues.apache.org/jira/browse/FLINK-2206): JobManager webinterface shows 5 finished jobs at most
+
+* [FLINK-2188](https://issues.apache.org/jira/browse/FLINK-2188): Reading from big HBase Tables
+
+* [FLINK-1781](https://issues.apache.org/jira/browse/FLINK-1781): Quickstarts broken due to Scala Version Variables
+
+## Notice
+
+The 0.9 series of Flink is the last version to support Java 6. If you are still using Java 6, please consider upgrading to Java 8 (Java 7 ended its free support in April 2015).
+
+Flink will require at least Java 7 in major releases after 0.9.0.
diff --git a/docs/content.tr/posts/2015-08-24-introducing-flink-gelly.md b/docs/content.tr/posts/2015-08-24-introducing-flink-gelly.md
new file mode 100644
index 0000000000..87cfe37088
--- /dev/null
+++ b/docs/content.tr/posts/2015-08-24-introducing-flink-gelly.md
@@ -0,0 +1,454 @@
+---
+date: "2015-08-24T00:00:00Z"
+title: 'Introducing Gelly: Graph Processing with Apache Flink'
+aliases:
+- /news/2015/08/24/introducing-flink-gelly.html
+---
+
+This blog post introduces **Gelly**, Apache Flink's *graph-processing API and library*. Flink's native support
+for iterations makes it a suitable platform for large-scale graph analytics.
+By leveraging delta iterations, Gelly is able to map various graph processing models such as
+vertex-centric or gather-sum-apply to Flink dataflows.
+
+Gelly allows Flink users to perform end-to-end data analysis in a single system.
+Gelly can be seamlessly used with Flink's DataSet API,
+which means that pre-processing, graph creation, analysis, and post-processing can be done
+in the same application. At the end of this post, we will go through a step-by-step example
+in order to demonstrate that loading, transformation, filtering, graph creation, and analysis
+can be performed in a single Flink program.
+
+**Overview**
+
+1. [What is Gelly?](#what-is-gelly)
+2. [Graph Representation and Creation](#graph-representation-and-creation)
+3. [Transformations and Utilities](#transformations-and-utilities)
+4. [Iterative Graph Processing](#iterative-graph-processing)
+5. [Library of Graph Algorithms](#library-of-graph-algorithms)
+6. [Use-Case: Music Profiles](#use-case-music-profiles)
+7. [Ongoing and Future Work](#ongoing-and-future-work)
+
+
+
+## What is Gelly?
+
+Gelly is a Graph API for Flink. It is currently supported in both Java and Scala.
+The Scala methods are implemented as wrappers on top of the basic Java operations.
+The API contains a set of utility functions for graph analysis, supports iterative graph
+processing and introduces a library of graph algorithms.
+
+
+
+
+
+[Back to top](#top)
+
+## Graph Representation and Creation
+
+In Gelly, a graph is represented by a DataSet of vertices and a DataSet of edges.
+A vertex is defined by its unique ID and a value, whereas an edge is defined by its source ID,
+target ID, and value. A vertex or edge for which a value is not specified will simply have the
+value type set to `NullValue`.
+
+A graph can be created from:
+
+1. **DataSet of edges** and an optional **DataSet of vertices** using `Graph.fromDataSet()`
+2. **DataSet of Tuple3** and an optional **DataSet of Tuple2** using `Graph.fromTupleDataSet()`
+3. **Collection of edges** and an optional **Collection of vertices** using `Graph.fromCollection()`
+
+In all three cases, if the vertices are not provided,
+Gelly will automatically produce the vertex IDs from the edge source and target IDs.
+
+[Back to top](#top)
+
+## Transformations and Utilities
+
+These are methods of the Graph class and include common graph metrics, transformations
+and mutations as well as neighborhood aggregations.
+
+#### Common Graph Metrics
+These methods can be used to retrieve several graph metrics and properties, such as the number
+of vertices, edges and the node degrees.
+
+#### Transformations
+The transformation methods enable several Graph operations, using high-level functions similar to
+the ones provided by the batch processing API. These transformations can be applied one after the
+other, yielding a new Graph after each step, in a fashion similar to operators on DataSets:
+
+```java
+inputGraph.getUndirected().mapEdges(new CustomEdgeMapper());
+```
+
+Transformations can be applied on:
+
+1. **Vertices**: `mapVertices`, `joinWithVertices`, `filterOnVertices`, `addVertex`, ...
+2. **Edges**: `mapEdges`, `filterOnEdges`, `removeEdge`, ...
+3. **Triplets** (source vertex, target vertex, edge): `getTriplets`
+
+#### Neighborhood Aggregations
+
+Neighborhood methods allow vertices to perform an aggregation on their first-hop neighborhood.
+This provides a vertex-centric view, where each vertex can access its neighboring edges and neighbor values.
+
+`reduceOnEdges()` provides access to the neighboring edges of a vertex,
+i.e. the edge value and the vertex ID of the edge endpoint. In order to also access the
+neighboring vertices’ values, one should call the `reduceOnNeighbors()` function.
+The scope of the neighborhood is defined by the EdgeDirection parameter, which can be IN, OUT or ALL,
+to gather in-coming, out-going or all edges (neighbors) of a vertex.
+
+The two neighborhood
+functions mentioned above can only be used when the aggregation function is associative and commutative.
+In case the function does not comply with these restrictions or if it is desirable to return zero,
+one or more values per vertex, the more general `groupReduceOnEdges()` and
+`groupReduceOnNeighbors()` functions must be called.
+
+Consider the following graph, for instance:
+
+
+
+
+
+Assume you would want to compute the sum of the values of all incoming neighbors for each vertex.
+We will call the `reduceOnNeighbors()` aggregation method since the sum is an associative and commutative operation and the neighbors’ values are needed:
+
+```java
+graph.reduceOnNeighbors(new SumValues(), EdgeDirection.IN);
+```
+
+The vertex with id 1 is the only node that has no incoming edges. The result is therefore:
+
+
+
+
+
+[Back to top](#top)
+
+## Iterative Graph Processing
+
+During the past few years, many different programming models for distributed graph processing
+have been introduced: [vertex-centric](http://delivery.acm.org/10.1145/2490000/2484843/a22-salihoglu.pdf?ip=141.23.53.206&id=2484843&acc=ACTIVE%20SERVICE&key=2BA2C432AB83DA15.0F42380CB8DD3307.4D4702B0C3E38B35.4D4702B0C3E38B35&CFID=706313474&CFTOKEN=60107876&__acm__=1440408958_b131e035942130653e5782409b5c0cde),
+[partition-centric](http://researcher.ibm.com/researcher/files/us-ytian/giraph++.pdf), [gather-apply-scatter](http://www.eecs.harvard.edu/cs261/notes/gonzalez-2012.htm),
+[edge-centric](http://infoscience.epfl.ch/record/188535/files/paper.pdf), [neighborhood-centric](http://www.vldb.org/pvldb/vol7/p1673-quamar.pdf).
+Each one of these models targets a specific class of graph applications and each corresponding
+system implementation optimizes the runtime respectively. In Gelly, we would like to exploit the
+flexible dataflow model and the efficient iterations of Flink, to support multiple distributed
+graph processing models on top of the same system.
+
+Currently, Gelly has methods for writing vertex-centric programs and provides support for programs
+implemented using the gather-sum(accumulate)-apply model. We are also considering to offer support
+for the partition-centric computation model, using Fink’s `mapPartition()` operator.
+This model exposes the partition structure to the user and allows local graph structure exploitation
+inside a partition to avoid unnecessary communication.
+
+#### Vertex-centric
+
+Gelly wraps Flink’s [Spargel APi]({{< param DocsBaseUrl >}}flink-docs-release-0.8/spargel_guide.html) to
+support the vertex-centric, Pregel-like programming model. Gelly’s `runVertexCentricIteration` method accepts two user-defined functions:
+
+1. **MessagingFunction:** defines what messages a vertex sends out for the next superstep.
+2. **VertexUpdateFunction:*** defines how a vertex will update its value based on the received messages.
+
+The method will execute the vertex-centric iteration on the input Graph and return a new Graph, with updated vertex values.
+
+Gelly’s vertex-centric programming model exploits Flink’s efficient delta iteration operators.
+Many iterative graph algorithms expose non-uniform behavior, where some vertices converge to
+their final value faster than others. In such cases, the number of vertices that need to be
+recomputed during an iteration decreases as the algorithm moves towards convergence.
+
+For example, consider a Single Source Shortest Paths problem on the following graph, where S
+is the source node, i is the iteration counter and the edge values represent distances between nodes:
+
+
+
+
+
+In each iteration, a vertex receives distances from its neighbors and adopts the minimum of
+these distances and its current distance as the new value. Then, it propagates its new value
+to its neighbors. If a vertex does not change value during an iteration, there is no need for
+it to propagate its old distance to its neighbors; as they have already taken it into account.
+
+Flink’s `IterateDelta` operator permits exploitation of this property as well as the
+execution of computations solely on the active parts of the graph. The operator receives two inputs:
+
+1. the **Solution Set**, which represents the current state of the input and
+2. the **Workset**, which determines which parts of the graph will be recomputed in the next iteration.
+
+In the SSSP example above, the Workset contains the vertices which update their distances.
+The user-defined iterative function is applied on these inputs to produce state updates.
+These updates are efficiently applied on the state, which is kept in memory.
+
+
+
+
+
+Internally, a vertex-centric iteration is a Flink delta iteration, where the initial Solution Set
+is the vertex set of the input graph and the Workset is created by selecting the active vertices,
+i.e. the ones that updated their value in the previous iteration. The messaging and vertex-update
+functions are user-defined functions wrapped inside coGroup operators. In each superstep,
+the active vertices (Workset) are coGrouped with the edges to generate the neighborhoods for
+each vertex. The messaging function is then applied on each neighborhood. Next, the result of the
+messaging function is coGrouped with the current vertex values (Solution Set) and the user-defined
+vertex-update function is applied on the result. The output of this coGroup operator is finally
+used to update the Solution Set and create the Workset input for the next iteration.
+
+
+
+
+
+#### Gather-Sum-Apply
+
+Gelly supports a variation of the popular Gather-Sum-Apply-Scatter computation model,
+introduced by PowerGraph. In GSA, a vertex pulls information from its neighbors as opposed to the
+vertex-centric approach where the updates are pushed from the incoming neighbors.
+The `runGatherSumApplyIteration()` accepts three user-defined functions:
+
+1. **GatherFunction:** gathers neighboring partial values along in-edges.
+2. **SumFunction:** accumulates/reduces the values into a single one.
+3. **ApplyFunction:** uses the result computed in the sum phase to update the current vertex’s value.
+
+Similarly to vertex-centric, GSA leverages Flink’s delta iteration operators as, in many cases,
+vertex values do not need to be recomputed during an iteration.
+
+Let us reconsider the Single Source Shortest Paths algorithm. In each iteration, a vertex:
+
+1. **Gather** retrieves distances from its neighbors summed up with the corresponding edge values;
+2. **Sum** compares the newly obtained distances in order to extract the minimum;
+3. **Apply** and finally adopts the minimum distance computed in the sum step,
+provided that it is lower than its current value. If a vertex’s value does not change during
+an iteration, it no longer propagates its distance.
+
+Internally, a Gather-Sum-Apply Iteration is a Flink delta iteration where the initial solution
+set is the vertex input set and the workset is created by selecting the active vertices.
+
+The three functions: gather, sum and apply are user-defined functions wrapped in map, reduce
+and join operators respectively. In each superstep, the active vertices are joined with the
+edges in order to create neighborhoods for each vertex. The gather function is then applied on
+the neighborhood values via a map function. Afterwards, the result is grouped by the vertex ID
+and reduced using the sum function. Finally, the outcome of the sum phase is joined with the
+current vertex values (solution set), the values are updated, thus creating a new workset that
+serves as input for the next iteration.
+
+
+
+
+
+[Back to top](#top)
+
+## Library of Graph Algorithms
+
+We are building a library of graph algorithms in Gelly, to easily analyze large-scale graphs.
+These algorithms extend the `GraphAlgorithm` interface and can be simply executed on
+the input graph by calling a `run()` method.
+
+We currently have implementations of the following algorithms:
+
+1. PageRank
+2. Single-Source-Shortest-Paths
+3. Label Propagation
+4. Community Detection (based on [this paper](http://arxiv.org/pdf/0808.2633.pdf))
+5. Connected Components
+6. GSA Connected Components
+7. GSA PageRank
+8. GSA Single-Source-Shortest-Paths
+
+Gelly also offers implementations of common graph algorithms through [examples](https://github.com/apache/flink/tree/master/flink-staging/flink-gelly/src/main/java/org/apache/flink/graph/example).
+Among them, one can find graph weighting schemes, like Jaccard Similarity and Euclidean Distance Weighting,
+as well as computation of common graph metrics.
+
+[Back to top](#top)
+
+## Use-Case: Music Profiles
+
+In the following section, we go through a use-case scenario that combines the Flink DataSet API
+with Gelly in order to process users’ music preferences to suggest additions to their playlist.
+
+First, we read a user’s music profile which is in the form of user-id, song-id and the number of
+plays that each song has. We then filter out the list of songs the users do not wish to see in their
+playlist. Then we compute the top songs per user (i.e. the songs a user listened to the most).
+Finally, as a separate use-case on the same data set, we create a user-user similarity graph based
+on the common songs and use this resulting graph to detect communities by calling Gelly’s Label Propagation
+library method.
+
+For running the example implementation, please use the 0.10-SNAPSHOT version of Flink as a
+dependency. The full example code base can be found [here](https://github.com/apache/flink/blob/master/flink-staging/flink-gelly/src/main/java/org/apache/flink/graph/example/MusicProfiles.java). The public data set used for testing
+can be found [here](http://labrosa.ee.columbia.edu/millionsong/tasteprofile). This data set contains **48,373,586** real user-id, song-id and
+play-count triplets.
+
+**Note:** The code snippets in this post try to reduce verbosity by skipping type parameters of generic functions. Please have a look at [the full example](https://github.com/apache/flink/blob/master/flink-staging/flink-gelly/src/main/java/org/apache/flink/graph/example/MusicProfiles.java) for the correct and complete code.
+
+#### Filtering out Bad Records
+
+After reading the `(user-id, song-id, play-count)` triplets from a CSV file and after parsing a
+text file in order to retrieve the list of songs that a user would not want to include in a
+playlist, we use a coGroup function to filter out the mismatches.
+
+```java
+// read the user-song-play triplets.
+DataSet> triplets =
+ getUserSongTripletsData(env);
+
+// read the mismatches dataset and extract the songIDs
+DataSet> validTriplets = triplets
+ .coGroup(mismatches).where(1).equalTo(0)
+ .with(new CoGroupFunction() {
+ void coGroup(Iterable triplets, Iterable invalidSongs, Collector out) {
+ if (!invalidSongs.iterator().hasNext()) {
+ for (Tuple3 triplet : triplets) { // valid triplet
+ out.collect(triplet);
+ }
+ }
+ }
+ }
+```
+
+The coGroup simply takes the triplets whose song-id (second field) matches the song-id from the
+mismatches list (first field) and if the iterator was empty for a certain triplet, meaning that
+there were no mismatches found, the triplet associated with that song is collected.
+
+#### Compute the Top Songs per User
+
+As a next step, we would like to see which songs a user played more often. To this end, we
+build a user-song weighted, bipartite graph in which edge source vertices are users, edge target
+vertices are songs and where the weight represents the number of times the user listened to that
+certain song.
+
+
+
+
+
+```java
+// create a user -> song weighted bipartite graph where the edge weights
+// correspond to play counts
+Graph userSongGraph = Graph.fromTupleDataSet(validTriplets, env);
+```
+
+Consult the [Gelly guide]({{< param DocsBaseUrl >}}flink-docs-master/dev/libs/gelly/) for guidelines
+on how to create a graph from a given DataSet of edges or from a collection.
+
+To retrieve the top songs per user, we call the groupReduceOnEdges function as it perform an
+aggregation over the first hop neighborhood taking just the edges into consideration. We will
+basically iterate through the edge value and collect the target (song) of the maximum weight edge.
+
+```java
+//get the top track (most listened to) for each user
+DataSet usersWithTopTrack = userSongGraph
+ .groupReduceOnEdges(new GetTopSongPerUser(), EdgeDirection.OUT);
+
+class GetTopSongPerUser implements EdgesFunctionWithVertexValue {
+ void iterateEdges(Vertex vertex, Iterable edges) {
+ int maxPlaycount = 0;
+ String topSong = "";
+
+ for (Edge edge : edges) {
+ if (edge.getValue() > maxPlaycount) {
+ maxPlaycount = edge.getValue();
+ topSong = edge.getTarget();
+ }
+ }
+ return new Tuple2(vertex.getId(), topSong);
+ }
+}
+```
+
+#### Creating a User-User Similarity Graph
+
+Clustering users based on common interests, in this case, common top songs, could prove to be
+very useful for advertisements or for recommending new musical compilations. In a user-user graph,
+two users who listen to the same song will simply be linked together through an edge as depicted
+in the figure below.
+
+
+
+
+
+To form the user-user graph in Flink, we will simply take the edges from the user-song graph
+(left-hand side of the image), group them by song-id, and then add all the users (source vertex ids)
+to an ArrayList.
+
+We then match users who listened to the same song two by two, creating a new edge to mark their
+common interest (right-hand side of the image).
+
+Afterwards, we perform a `distinct()` operation to avoid creation of duplicate data.
+Considering that we now have the DataSet of edges which present interest, creating a graph is as
+straightforward as a call to the `Graph.fromDataSet()` method.
+
+```java
+// create a user-user similarity graph:
+// two users that listen to the same song are connected
+DataSet similarUsers = userSongGraph.getEdges()
+ // filter out user-song edges that are below the playcount threshold
+ .filter(new FilterFunction>() {
+ public boolean filter(Edge edge) {
+ return (edge.getValue() > playcountThreshold);
+ }
+ })
+ .groupBy(1)
+ .reduceGroup(new GroupReduceFunction() {
+ void reduce(Iterable edges, Collector out) {
+ List users = new ArrayList();
+ for (Edge edge : edges) {
+ users.add(edge.getSource());
+ for (int i = 0; i < users.size() - 1; i++) {
+ for (int j = i+1; j < users.size() - 1; j++) {
+ out.collect(new Edge(users.get(i), users.get(j)));
+ }
+ }
+ }
+ }
+ })
+ .distinct();
+
+Graph similarUsersGraph = Graph.fromDataSet(similarUsers).getUndirected();
+```
+
+After having created a user-user graph, it would make sense to detect the various communities
+formed. To do so, we first initialize each vertex with a numeric label using the
+`joinWithVertices()` function that takes a data set of Tuple2 as a parameter and joins
+the id of a vertex with the first element of the tuple, afterwards applying a map function.
+Finally, we call the `run()` method with the LabelPropagation library method passed
+as a parameter. In the end, the vertices will be updated to contain the most frequent label
+among their neighbors.
+
+```java
+// detect user communities using label propagation
+// initialize each vertex with a unique numeric label
+DataSet> idsWithInitialLabels = DataSetUtils
+ .zipWithUniqueId(similarUsersGraph.getVertexIds())
+ .map(new MapFunction, Tuple2>() {
+ @Override
+ public Tuple2 map(Tuple2 tuple2) throws Exception {
+ return new Tuple2(tuple2.f1, tuple2.f0);
+ }
+ });
+
+// update the vertex values and run the label propagation algorithm
+DataSet verticesWithCommunity = similarUsersGraph
+ .joinWithVertices(idsWithlLabels, new MapFunction() {
+ public Long map(Tuple2 idWithLabel) {
+ return idWithLabel.f1;
+ }
+ })
+ .run(new LabelPropagation(numIterations))
+ .getVertices();
+```
+
+[Back to top](#top)
+
+## Ongoing and Future Work
+
+Currently, Gelly matches the basic functionalities provided by most state-of-the-art graph
+processing systems. Our vision is to turn Gelly into more than “yet another library for running
+PageRank-like algorithms” by supporting generic iterations, implementing graph partitioning,
+providing bipartite graph support and by offering numerous other features.
+
+We are also enriching Flink Gelly with a set of operators suitable for highly skewed graphs
+as well as a Graph API built on Flink Streaming.
+
+In the near future, we would like to see how Gelly can be integrated with graph visualization
+tools, graph database systems and sampling techniques.
+
+Curious? Read more about our plans for Gelly in the [roadmap](https://cwiki.apache.org/confluence/display/FLINK/Flink+Gelly).
+
+[Back to top](#top)
+
+## Links
+[Gelly Documentation]({{< param DocsBaseUrl >}}flink-docs-master/dev/libs/gelly/)
\ No newline at end of file
diff --git a/docs/content.tr/posts/2015-09-01-release-0.9.1.md b/docs/content.tr/posts/2015-09-01-release-0.9.1.md
new file mode 100644
index 0000000000..beaa6e5eb5
--- /dev/null
+++ b/docs/content.tr/posts/2015-09-01-release-0.9.1.md
@@ -0,0 +1,58 @@
+---
+date: "2015-09-01T08:00:00Z"
+title: Apache Flink 0.9.1 available
+aliases:
+- /news/2015/09/01/release-0.9.1.html
+---
+
+The Flink community is happy to announce that Flink 0.9.1 is now available.
+
+0.9.1 is a maintenance release, which includes a lot of minor fixes across
+several parts of the system. We suggest all users of Flink to work with this
+latest stable version.
+
+[Download the release](/downloads.html) and [check out the
+documentation]({{ site.docs-stable }}). Feedback through the Flink mailing lists
+is, as always, very welcome!
+
+The following [issues were fixed](https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLINK%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20fixVersion%20%3D%200.9.1)
+for this release:
+
+- [FLINK-1916](https://issues.apache.org/jira/browse/FLINK-1916) EOFException when running delta-iteration job
+- [FLINK-2089](https://issues.apache.org/jira/browse/FLINK-2089) "Buffer recycled" IllegalStateException during cancelling
+- [FLINK-2189](https://issues.apache.org/jira/browse/FLINK-2189) NullPointerException in MutableHashTable
+- [FLINK-2205](https://issues.apache.org/jira/browse/FLINK-2205) Confusing entries in JM Webfrontend Job Configuration section
+- [FLINK-2229](https://issues.apache.org/jira/browse/FLINK-2229) Data sets involving non-primitive arrays cannot be unioned
+- [FLINK-2238](https://issues.apache.org/jira/browse/FLINK-2238) Scala ExecutionEnvironment.fromCollection does not work with Sets
+- [FLINK-2248](https://issues.apache.org/jira/browse/FLINK-2248) Allow disabling of sdtout logging output
+- [FLINK-2257](https://issues.apache.org/jira/browse/FLINK-2257) Open and close of RichWindowFunctions is not called
+- [FLINK-2262](https://issues.apache.org/jira/browse/FLINK-2262) ParameterTool API misnamed function
+- [FLINK-2280](https://issues.apache.org/jira/browse/FLINK-2280) GenericTypeComparator.compare() does not respect ascending flag
+- [FLINK-2285](https://issues.apache.org/jira/browse/FLINK-2285) Active policy emits elements of the last window twice
+- [FLINK-2286](https://issues.apache.org/jira/browse/FLINK-2286) Window ParallelMerge sometimes swallows elements of the last window
+- [FLINK-2293](https://issues.apache.org/jira/browse/FLINK-2293) Division by Zero Exception
+- [FLINK-2298](https://issues.apache.org/jira/browse/FLINK-2298) Allow setting custom YARN application names through the CLI
+- [FLINK-2347](https://issues.apache.org/jira/browse/FLINK-2347) Rendering problem with Documentation website
+- [FLINK-2353](https://issues.apache.org/jira/browse/FLINK-2353) Hadoop mapred IOFormat wrappers do not respect JobConfigurable interface
+- [FLINK-2356](https://issues.apache.org/jira/browse/FLINK-2356) Resource leak in checkpoint coordinator
+- [FLINK-2361](https://issues.apache.org/jira/browse/FLINK-2361) CompactingHashTable loses entries
+- [FLINK-2362](https://issues.apache.org/jira/browse/FLINK-2362) distinct is missing in DataSet API documentation
+- [FLINK-2381](https://issues.apache.org/jira/browse/FLINK-2381) Possible class not found Exception on failed partition producer
+- [FLINK-2384](https://issues.apache.org/jira/browse/FLINK-2384) Deadlock during partition spilling
+- [FLINK-2386](https://issues.apache.org/jira/browse/FLINK-2386) Implement Kafka connector using the new Kafka Consumer API
+- [FLINK-2394](https://issues.apache.org/jira/browse/FLINK-2394) HadoopOutFormat OutputCommitter is default to FileOutputCommiter
+- [FLINK-2412](https://issues.apache.org/jira/browse/FLINK-2412) Race leading to IndexOutOfBoundsException when querying for buffer while releasing SpillablePartition
+- [FLINK-2422](https://issues.apache.org/jira/browse/FLINK-2422) Web client is showing a blank page if "Meta refresh" is disabled in browser
+- [FLINK-2424](https://issues.apache.org/jira/browse/FLINK-2424) InstantiationUtil.serializeObject(Object) does not close output stream
+- [FLINK-2437](https://issues.apache.org/jira/browse/FLINK-2437) TypeExtractor.analyzePojo has some problems around the default constructor detection
+- [FLINK-2442](https://issues.apache.org/jira/browse/FLINK-2442) PojoType fields not supported by field position keys
+- [FLINK-2447](https://issues.apache.org/jira/browse/FLINK-2447) TypeExtractor returns wrong type info when a Tuple has two fields of the same POJO type
+- [FLINK-2450](https://issues.apache.org/jira/browse/FLINK-2450) IndexOutOfBoundsException in KryoSerializer
+- [FLINK-2460](https://issues.apache.org/jira/browse/FLINK-2460) ReduceOnNeighborsWithExceptionITCase failure
+- [FLINK-2527](https://issues.apache.org/jira/browse/FLINK-2527) If a VertexUpdateFunction calls setNewVertexValue more than once, the MessagingFunction will only see the first value set
+- [FLINK-2540](https://issues.apache.org/jira/browse/FLINK-2540) LocalBufferPool.requestBuffer gets into infinite loop
+- [FLINK-2542](https://issues.apache.org/jira/browse/FLINK-2542) It should be documented that it is required from a join key to override hashCode(), when it is not a POJO
+- [FLINK-2555](https://issues.apache.org/jira/browse/FLINK-2555) Hadoop Input/Output Formats are unable to access secured HDFS clusters
+- [FLINK-2560](https://issues.apache.org/jira/browse/FLINK-2560) Flink-Avro Plugin cannot be handled by Eclipse
+- [FLINK-2572](https://issues.apache.org/jira/browse/FLINK-2572) Resolve base path of symlinked executable
+- [FLINK-2584](https://issues.apache.org/jira/browse/FLINK-2584) ASM dependency is not shaded away
diff --git a/docs/content.tr/posts/2015-09-03-flink-forward.md b/docs/content.tr/posts/2015-09-03-flink-forward.md
new file mode 100644
index 0000000000..e4107cdc7b
--- /dev/null
+++ b/docs/content.tr/posts/2015-09-03-flink-forward.md
@@ -0,0 +1,44 @@
+---
+date: "2015-09-03T08:00:00Z"
+title: Announcing Flink Forward 2015
+aliases:
+- /news/2015/09/03/flink-forward.html
+---
+
+[Flink Forward 2015](http://2015.flink-forward.org/) is the first
+conference with Flink at its center that aims to bring together the
+Apache Flink community in a single place. The organizers are starting
+this conference in October 12 and 13 from Berlin, the place where
+Apache Flink started.
+
+
+
+
+
+The [conference program](http://2015.flink-forward.org/?post_type=day) has
+been announced by the organizers and a program committee consisting of
+Flink PMC members. The agenda contains talks from industry and
+academia as well as a dedicated session on hands-on Flink training.
+
+Some highlights of the talks include
+
+- A keynote by [William
+ Vambenepe](http://2015.flink-forward.org/?speaker=william-vambenepe),
+ lead of the product management team responsible for Big Data
+ services on Google Cloud Platform (BigQuery, Dataflow, etc...) on
+ data streaming, Google Cloud Dataflow, and Apache Flink.
+
+- Talks by several practitioners on how they are putting Flink to work
+ in their projects, including ResearchGate, Bouygues Telecom,
+ Amadeus, Telefonica, Capital One, Ericsson, and Otto Group.
+
+- Talks on how open source projects, including Apache Mahout, Apache
+ SAMOA (incubating), Apache Zeppelin (incubating), Apache BigTop, and
+ Apache Storm integrate with Apache Flink.
+
+- Talks by Flink committers on several aspects of the system, such as
+ fault tolerance, the internal runtime architecture, and others.
+
+Check out the [schedule](http://2015.flink-forward.org/?post_type=day) and
+register for the conference.
+
diff --git a/docs/content.tr/posts/2015-09-16-off-heap-memory.md b/docs/content.tr/posts/2015-09-16-off-heap-memory.md
new file mode 100644
index 0000000000..7964d72945
--- /dev/null
+++ b/docs/content.tr/posts/2015-09-16-off-heap-memory.md
@@ -0,0 +1,875 @@
+---
+author: Stephan Ewen
+author-twitter: stephanewen
+date: "2015-09-16T08:00:00Z"
+excerpt: |-
+ Running data-intensive code in the JVM and making it well-behaved is tricky. Systems that put billions of data objects naively onto the JVM heap face unpredictable OutOfMemoryErrors and Garbage Collection stalls. Of course, you still want to to keep your data in memory as much as possible, for speed and responsiveness of the processing applications. In that context, "off-heap" has become almost something like a magic word to solve these problems.
+ In this blog post, we will look at how Flink exploits off-heap memory. The feature is part of the upcoming release, but you can try it out with the latest nightly builds. We will also give a few interesting insights into the behavior for Java's JIT compiler for highly optimized methods and loops.
+title: Off-heap Memory in Apache Flink and the curious JIT compiler
+aliases:
+- /news/2015/09/16/off-heap-memory.html
+---
+
+Running data-intensive code in the JVM and making it well-behaved is tricky. Systems that put billions of data objects naively onto the JVM heap face unpredictable OutOfMemoryErrors and Garbage Collection stalls. Of course, you still want to to keep your data in memory as much as possible, for speed and responsiveness of the processing applications. In that context, "off-heap" has become almost something like a magic word to solve these problems.
+
+In this blog post, we will look at how Flink exploits off-heap memory. The feature is part of the upcoming release, but you can try it out with the latest nightly builds. We will also give a few interesting insights into the behavior for Java's JIT compiler for highly optimized methods and loops.
+
+
+## Recap: Memory Management in Flink
+
+To understand Flink’s approach to off-heap memory, we need to recap Flink’s approach to custom managed memory. We have written an [earlier blog post about how Flink manages JVM memory itself](/news/2015/05/11/Juggling-with-Bits-and-Bytes.html)
+
+As a summary, the core part is that Flink implements its algorithms not against Java objects, arrays, or lists, but actually against a data structure similar to `java.nio.ByteBuffer`. Flink uses its own specialized version, called [`MemorySegment`](https://github.com/apache/flink/blob/release-0.9.1-rc1/flink-core/src/main/java/org/apache/flink/core/memory/MemorySegment.java) on which algorithms put and get at specific positions ints, longs, byte arrays, etc, and compare and copy memory. The memory segments are held and distributed by a central component (called `MemoryManager`) from which algorithms request segments according to their calculated memory budgets.
+
+Don't believe that this can be fast? Have a look at the [benchmarks in the earlier blogpost](/news/2015/05/11/Juggling-with-Bits-and-Bytes.html), which show that it is actually often much faster than working on objects, due to better control over data layout (cache efficiency, data size), and reducing the pressure on Java's Garbage Collector.
+
+This form of memory management has been in Flink for a long time. Anecdotally, the first public demo of Flink's predecessor project *Stratosphere*, at the VLDB conference in 2010, was running its programs with custom managed memory (although I believe few attendees were aware of that).
+
+
+## Why actually bother with off-heap memory?
+
+Given that Flink has a sophisticated level of managing on-heap memory, why do we even bother with off-heap memory? It is true that *"out of memory"* has been much less of a problem for Flink because of its heap memory management techniques. Nonetheless, there are a few good reasons to offer the possibility to move Flink's managed memory out of the JVM heap:
+
+ - Very large JVMs (100s of GBytes heap memory) tend to be tricky. It takes long to start them (allocate and initialize heap) and garbage collection stalls can be huge (minutes). While newer incremental garbage collectors (like G1) mitigate this problem to some extend, an even better solution is to just make the heap much smaller and allocate Flink's managed memory chunks outside the heap.
+
+ - I/O and network efficiency: In many cases, we write MemorySegments to disk (spilling) or to the network (data transfer). Off-heap memory can be written/transferred with zero copies, while heap memory always incurs an additional memory copy.
+
+ - Off-heap memory can actually be owned by other processes. That way, cached data survives process crashes (due to user code exceptions) and can be used for recovery. Flink does not exploit that, yet, but it is interesting future work.
+
+
+The opposite question is also valid. Why should Flink ever not use off-heap memory?
+
+ - On-heap is easier and interplays better with tools. Some container environments and monitoring tools get confused when the monitored heap size does not remotely reflect the amount of memory used by the process.
+
+ - Short lived memory segments are cheaper on the heap. Flink sometimes needs to allocate some short lived buffers, which works cheaper on the heap than off-heap.
+
+ - Some operations are actually a bit faster on heap memory (or the JIT compiler understands them better).
+
+
+## The off-heap Memory Implementation
+
+Given that all memory intensive internal algorithms are already implemented against the `MemorySegment`, our implementation to switch to off-heap memory is actually trivial. You can compare it to replacing all `ByteBuffer.allocate(numBytes)` calls with `ByteBuffer.allocateDirect(numBytes)`. In Flink's case it meant that we made the `MemorySegment` abstract and added the `HeapMemorySegment` and `OffHeapMemorySegment` subclasses. The `OffHeapMemorySegment` takes the off-heap memory pointer from a `java.nio.DirectByteBuffer` and implements its specialized access methods using `sun.misc.Unsafe`. We also made a few adjustments to the startup scripts and the deployment code to make sure that the JVM is permitted enough off-heap memory (direct memory, *-XX:MaxDirectMemorySize*).
+
+In practice we had to go one step further, to make the implementation perform well. While the `ByteBuffer` is used in I/O code paths to compose headers and move bulk memory into place, the MemorySegment is part of the innermost loops of many algorithms (sorting, hash tables, ...). That means that the access methods have to be as fast as possible.
+
+
+## Understanding the JIT and tuning the implementation
+
+The `MemorySegment` was (before our change) a standalone class, it was *final* (had no subclasses). Via *Class Hierarchy Analysis (CHA)*, the JIT compiler was able to determine that all of the accessor method calls go to one specific implementation. That way, all method calls can be perfectly de-virtualized and inlined, which is essential to performance, and the basis for all further optimizations (like vectorization of the calling loop).
+
+With two different memory segments loaded at the same time, the JIT compiler cannot perform the same level of optimization any more, which results in a noticeable difference in performance: A slowdown of about 2.7 x in the following example:
+
+```
+Writing 100000 x 32768 bytes to 32768 bytes segment:
+
+HeapMemorySegment (standalone) : 1,441 msecs
+OffHeapMemorySegment (standalone) : 1,628 msecs
+HeapMemorySegment (subclass) : 3,841 msecs
+OffHeapMemorySegment (subclass) : 3,847 msecs
+```
+
+To get back to the original performance, we explored two approaches:
+
+### Approach 1: Make sure that only one memory segment implementation is ever loaded.
+
+We re-structured the code a bit to make sure that all places that produce long-lived and short-lived memory segments instantiate the same MemorySegment subclass (Heap- or Off-Heap segment). Using factories rather than directly instantiating the memory segment classes, this was straightforward.
+
+Experiments (see appendix) showed that the JIT compiler properly detects this (via hierarchy analysis) and that it can perform the same level of aggressive optimization as before, when there was only one `MemorySegment` class.
+
+
+### Approach 2: Write one segment that handles both heap and off-heap memory
+
+We created a class `HybridMemorySegment` which handles transparently both heap- and off-heap memory. It can be initialized either with a byte array (heap memory), or with a pointer to a memory region outside the heap (off-heap memory).
+
+Fortunately, there is a nice trick to do this without introducing code branches and specialized handling of the two different memory types. The trick is based on the way that the `sun.misc.Unsafe` methods interpret object references. To illustrate this, we take the method that gets a long integer from a memory position:
+
+```
+sun.misc.Unsafe.getLong(Object reference, long offset)
+```
+
+The method accepts an object reference, takes its memory address, and add the offset to obtain a pointer. It then fetches the eight bytes at the address pointed to and interprets them as a long integer. Since the method accepts *null* as the reference (and interprets it a *zero*) one can write a method that fetches a long integer seamlessly from heap and off-heap memory as follows:
+
+```java
+public class HybridMemorySegment {
+
+ private final byte[] heapMemory; // non-null in heap case, null in off-heap case
+ private final long address; // may be absolute, or relative to byte[]
+
+
+ // method of interest
+ public long getLong(int pos) {
+ return UNSAFE.getLong(heapMemory, address + pos);
+ }
+
+
+ // initialize for heap memory
+ public HybridMemorySegment(byte[] heapMemory) {
+ this.heapMemory = heapMemory;
+ this.address = UNSAFE.arrayBaseOffset(byte[].class)
+ }
+
+ // initialize for off-heap memory
+ public HybridMemorySegment(long offheapPointer) {
+ this.heapMemory = null;
+ this.address = offheapPointer
+ }
+}
+```
+
+To check whether both cases (heap and off-heap) really result in the same code paths (no hidden branches inside the `Unsafe.getLong(Object, long)` method) one can check out the C++ source code of `sun.misc.Unsafe`, available here: [http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/share/vm/prims/unsafe.cpp](http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/tip/src/share/vm/prims/unsafe.cpp)
+
+Of particular interest is the macro in line 155, which is the base of all GET methods. Tracing the function calls (many are no-ops), one can see that both variants of Unsafe’s `getLong()` result in the same code:
+Either `0 + absolutePointer` or `objectRefAddress + offset`.
+
+
+## Summary
+
+We ended up choosing a combination of both techniques:
+
+ - For off-heap memory, we use the `HybridMemorySegment` from approach (2) which can represent both heap and off-heap memory. That way, the same class represents the long-lived off-heap memory as the short-lived temporary buffers allocated (or wrapped) on the heap.
+
+ - We follow approach (1) to use factories to make sure that one segment is ever only loaded, which gives peak performance. We can exploit the performance benefits of the `HeapMemorySegment` on individual byte operations, and we have a mechanism in place to add further implementations of `MemorySegments` for the case that Oracle really removes `sun.misc.Unsafe` in future Java versions.
+
+The final code can be found in the Flink repository, under [https://github.com/apache/flink/tree/master/flink-core/src/main/java/org/apache/flink/core/memory](https://github.com/apache/flink/tree/master/flink-core/src/main/java/org/apache/flink/core/memory)
+
+Detailed micro benchmarks are in the appendix. A summary of the findings is as follows:
+
+ - The `HybridMemorySegment` performs equally well in heap and off-heap memory, as is to be expected (the code paths are the same)
+
+ - The `HeapMemorySegment` is quite a bit faster in reading individual bytes, not so much at writing them. Access to a *byte[]* is after all a bit cheaper than an invocation of a `sun.misc.Unsafe` method, even when JIT-ed.
+
+ - The abstract class `MemorySegment` (with its subclasses `HeapMemorySegment` and `HybridMemorySegment`) performs as well as any specialized non-abstract class, as long as only one subclass is loaded. When both are loaded, performance may suffer by a factor of 2.7 x on certain operations.
+
+ - How badly the performance degrades in cases where both MemorySegment subclasses are loaded seems to depend a lot on which subclass is loaded and operated on before and after which. Sometimes, performance is affected more than other times. It seems to be an artifact of the JIT’s code profiling and how heavily it performs optimistic specialization towards certain subclasses.
+
+
+There is still a bit of mystery left, specifically why sometimes code is faster when it performs more checks (has more instructions and an additional branch). Even though the branch is perfectly predictable, this seems counter-intuitive. The only explanation that we could come up with is that the branch optimizations (such as optimistic elimination etc) result in code that does better register allocation (for whatever reason, maybe the intermediate instructions just fit the allocation algorithm better).
+
+## tl;dr
+
+ - Off-heap memory in Flink complements the already very fast on-heap memory management. It improves the scalability to very large heap sizes and reduces memory copies for network and disk I/O.
+
+ - Flink’s already present memory management infrastructure made the addition of off-heap memory simple. Off-heap memory is not only used for caching data, Flink can actually sort data off-heap and build hash tables off-heap.
+
+ - We play a few nice tricks in the implementation to make sure the code is as friendly as possible to the JIT compiler and processor, to make the managed memory accesses are as fast as possible.
+
+ - Understanding the JVM’s JIT compiler is tough - one needs a lot of (randomized) micro benchmarking to examine its behavior.
+
+--------
+
+## Appendix: Detailed Micro Benchmarks
+
+These microbenchmarks test the performance of the different memory segment implementations on various operation.
+
+Each experiments tests the different implementations multiple times in different orders, to balance the advantage/disadvantage of the JIT compiler specializing towards certain code paths. All experiments were run 5x, discarding the fastest and slowest run, and then averaged. This compensated for delay before the JIT kicks in.
+
+My setup:
+
+ - Oracle Java 8 (1.8.0_25)
+ - 4 GBytes JVM heap (the experiments need 1.4 GBytes Heap + 1 GBytes direct memory)
+ - Intel Core i7-4700MQ CPU, 2.40GHz (4 cores, 8 hardware contexts)
+
+The tested implementations are
+
+
+
+
+ Type
+ Description
+
+
+
+
+ HeapMemorySegment
(exclusive)
+ The case where it is the only loaded MemorySegment subclass.
+
+
+ HeapMemorySegment
(mixed)
+ The case where both the HeapMemorySegment and the HybridMemorySegment are loaded.
+
+
+ HybridMemorySegment
(heap-exclusive)
+ Backed by heap memory, and the case where it is the only loaded MemorySegment class.
+
+
+ HybridMemorySegment
(heap-mixed)
+ Backed by heap memory, and the case where both the HeapMemorySegment and the HybridMemorySegment are loaded.
+
+
+ HybridMemorySegment
(off-heap-exclusive)
+ Backed by off-heap memory, and the case where it is the only loaded MemorySegment class.
+
+
+ HybridMemorySegment
(off-heap-mixed)
+ Backed by heap off-memory, and the case where both the HeapMemorySegment and the HybridMemorySegment are loaded.
+
+
+ PureHeapSegment
+ Has no class hierarchy and virtual methods at all.
+
+
+ PureHybridSegment
(heap)
+ Has no class hierarchy and virtual methods at all, backed by heap memory.
+
+
+ PureHybridSegment
(off-heap)
+ Has no class hierarchy and virtual methods at all, backed by off-heap memory.
+
+
+
+
+
+
Byte accesses
+
+
Writing 100000 x 32768 bytes to 32768 bytes segment
+
+
+
+
+ Segment
+ Time
+
+
+
+
+ HeapMemorySegment
, exclusive
+ 1,441 msecs
+
+
+ HeapMemorySegment
, mixed
+ 3,841 msecs
+
+
+ HybridMemorySegment
, heap, exclusive
+ 1,626 msecs
+
+
+ HybridMemorySegment
, off-heap, exclusive
+ 1,628 msecs
+
+
+ HybridMemorySegment
, heap, mixed
+ 3,848 msecs
+
+
+ HybridMemorySegment
, off-heap, mixed
+ 3,847 msecs
+
+
+ PureHeapSegment
+ 1,442 msecs
+
+
+ PureHybridSegment
, heap
+ 1,623 msecs
+
+
+ PureHybridSegment
, off-heap
+ 1,620 msecs
+
+
+
+
+
Reading 100000 x 32768 bytes from 32768 bytes segment
+
+
+
+
+ Segment
+ Time
+
+
+
+
+ HeapMemorySegment
, exclusive
+ 1,326 msecs
+
+
+ HeapMemorySegment
, mixed
+ 1,378 msecs
+
+
+ HybridMemorySegment
, heap, exclusive
+ 2,029 msecs
+
+
+ HybridMemorySegment
, off-heap, exclusive
+ 2,030 msecs
+
+
+ HybridMemorySegment
, heap, mixed
+ 2,047 msecs
+
+
+ HybridMemorySegment
, off-heap, mixed
+ 2,049 msecs
+
+
+ PureHeapSegment
+ 1,331 msecs
+
+
+ PureHybridSegment
, heap
+ 2,030 msecs
+
+
+ PureHybridSegment
, off-heap
+ 2,030 msecs
+
+
+
+
+
Writing 10 x 1073741824 bytes to 1073741824 bytes segment
+
+
+
+
+ Segment
+ Time
+
+
+
+
+ HeapMemorySegment
, exclusive
+ 5,602 msecs
+
+
+ HeapMemorySegment
, mixed
+ 12,570 msecs
+
+
+ HybridMemorySegment
, heap, exclusive
+ 5,691 msecs
+
+
+ HybridMemorySegment
, off-heap, exclusive
+ 5,691 msecs
+
+
+ HybridMemorySegment
, heap, mixed
+ 12,566 msecs
+
+
+ HybridMemorySegment
, off-heap, mixed
+ 12,556 msecs
+
+
+ PureHeapSegment
+ 5,599 msecs
+
+
+ PureHybridSegment
, heap
+ 5,687 msecs
+
+
+ PureHybridSegment
, off-heap
+ 5,681 msecs
+
+
+
+
+
Reading 10 x 1073741824 bytes from 1073741824 bytes segment
+
+
+
+
+ Segment
+ Time
+
+
+
+
+ HeapMemorySegment
, exclusive
+ 4,243 msecs
+
+
+ HeapMemorySegment
, mixed
+ 4,265 msecs
+
+
+ HybridMemorySegment
, heap, exclusive
+ 6,730 msecs
+
+
+ HybridMemorySegment
, off-heap, exclusive
+ 6,725 msecs
+
+
+ HybridMemorySegment
, heap, mixed
+ 6,933 msecs
+
+
+ HybridMemorySegment
, off-heap, mixed
+ 6,926 msecs
+
+
+ PureHeapSegment
+ 4,247 msecs
+
+
+ PureHybridSegment
, heap
+ 6,919 msecs
+
+
+ PureHybridSegment
, off-heap
+ 6,916 msecs
+
+
+
+
+
Byte Array accesses
+
+
Writing 100000 x 32 byte[1024] to 32768 bytes segment
+
+
+
+
+ Segment
+ Time
+
+
+
+
+ HeapMemorySegment
, mixed
+ 164 msecs
+
+
+ HybridMemorySegment
, heap, mixed
+ 163 msecs
+
+
+ HybridMemorySegment
, off-heap, mixed
+ 163 msecs
+
+
+ PureHeapSegment
+ 165 msecs
+
+
+ PureHybridSegment
, heap
+ 182 msecs
+
+
+ PureHybridSegment
, off-heap
+ 176 msecs
+
+
+
+
+
Reading 100000 x 32 byte[1024] from 32768 bytes segment
+
+
+
+
+ Segment
+ Time
+
+
+
+
+ HeapMemorySegment
, mixed
+ 157 msecs
+
+
+ HybridMemorySegment
, heap, mixed
+ 155 msecs
+
+
+ HybridMemorySegment
, off-heap, mixed
+ 162 msecs
+
+
+ PureHeapSegment
+ 161 msecs
+
+
+ PureHybridSegment
, heap
+ 175 msecs
+
+
+ PureHybridSegment
, off-heap
+ 179 msecs
+
+
+
+
+
Writing 10 x 1048576 byte[1024] to 1073741824 bytes segment
+
+
+
+
+ Segment
+ Time
+
+
+
+
+ HeapMemorySegment
, mixed
+ 1,164 msecs
+
+
+ HybridMemorySegment
, heap, mixed
+ 1,173 msecs
+
+
+ HybridMemorySegment
, off-heap, mixed
+ 1,157 msecs
+
+
+ PureHeapSegment
+ 1,169 msecs
+
+
+ PureHybridSegment
, heap
+ 1,174 msecs
+
+
+ PureHybridSegment
, off-heap
+ 1,166 msecs
+
+
+
+
+
Reading 10 x 1048576 byte[1024] from 1073741824 bytes segment
+
+
+
+
+ Segment
+ Time
+
+
+
+
+ HeapMemorySegment
, mixed
+ 854 msecs
+
+
+ HybridMemorySegment
, heap, mixed
+ 853 msecs
+
+
+ HybridMemorySegment
, off-heap, mixed
+ 854 msecs
+
+
+ PureHeapSegment
+ 857 msecs
+
+
+ PureHybridSegment
, heap
+ 896 msecs
+
+
+ PureHybridSegment
, off-heap
+ 887 msecs
+
+
+
+
+
Long integer accesses
+
+
(note that the heap and off-heap segments use the same or comparable code for this)
+
+
Writing 100000 x 4096 longs to 32768 bytes segment
+
+
+
+
+ Segment
+ Time
+
+
+
+
+ HeapMemorySegment
, mixed
+ 221 msecs
+
+
+ HybridMemorySegment
, heap, mixed
+ 222 msecs
+
+
+ HybridMemorySegment
, off-heap, mixed
+ 221 msecs
+
+
+ PureHeapSegment
+ 194 msecs
+
+
+ PureHybridSegment
, heap
+ 220 msecs
+
+
+ PureHybridSegment
, off-heap
+ 221 msecs
+
+
+
+
+
Reading 100000 x 4096 longs from 32768 bytes segment
+
+
+
+
+ Segment
+ Time
+
+
+
+
+ HeapMemorySegment
, mixed
+ 233 msecs
+
+
+ HybridMemorySegment
, heap, mixed
+ 232 msecs
+
+
+ HybridMemorySegment
, off-heap, mixed
+ 231 msecs
+
+
+ PureHeapSegment
+ 232 msecs
+
+
+ PureHybridSegment
, heap
+ 232 msecs
+
+
+ PureHybridSegment
, off-heap
+ 233 msecs
+
+
+
+
+
Writing 10 x 134217728 longs to 1073741824 bytes segment
+
+
+
+
+ Segment
+ Time
+
+
+
+
+ HeapMemorySegment
, mixed
+ 1,120 msecs
+
+
+ HybridMemorySegment
, heap, mixed
+ 1,120 msecs
+
+
+ HybridMemorySegment
, off-heap, mixed
+ 1,115 msecs
+
+
+ PureHeapSegment
+ 1,148 msecs
+
+
+ PureHybridSegment
, heap
+ 1,116 msecs
+
+
+ PureHybridSegment
, off-heap
+ 1,113 msecs
+
+
+
+
+
Reading 10 x 134217728 longs from 1073741824 bytes segment
+
+
+
+
+ Segment
+ Time
+
+
+
+
+ HeapMemorySegment
, mixed
+ 1,097 msecs
+
+
+ HybridMemorySegment
, heap, mixed
+ 1,099 msecs
+
+
+ HybridMemorySegment
, off-heap, mixed
+ 1,093 msecs
+
+
+ PureHeapSegment
+ 917 msecs
+
+
+ PureHybridSegment
, heap
+ 1,105 msecs
+
+
+ PureHybridSegment
, off-heap
+ 1,097 msecs
+
+
+
+
+
Integer accesses
+
+
(note that the heap and off-heap segments use the same or comparable code for this)
+
+
Writing 100000 x 8192 ints to 32768 bytes segment
+
+
+
+
+ Segment
+ Time
+
+
+
+
+ HeapMemorySegment
, mixed
+ 578 msecs
+
+
+ HybridMemorySegment
, heap, mixed
+ 580 msecs
+
+
+ HybridMemorySegment
, off-heap, mixed
+ 576 msecs
+
+
+ PureHeapSegment
+ 624 msecs
+
+
+ PureHybridSegment
, heap
+ 576 msecs
+
+
+ PureHybridSegment
, off-heap
+ 578 msecs
+
+
+
+
+
Reading 100000 x 8192 ints from 32768 bytes segment
+
+
+
+
+ Segment
+ Time
+
+
+
+
+ HeapMemorySegment
, mixed
+ 464 msecs
+
+
+ HybridMemorySegment
, heap, mixed
+ 464 msecs
+
+
+ HybridMemorySegment
, off-heap, mixed
+ 465 msecs
+
+
+ PureHeapSegment
+ 463 msecs
+
+
+ PureHybridSegment
, heap
+ 464 msecs
+
+
+ PureHybridSegment
, off-heap
+ 463 msecs
+
+
+
+
+
Writing 10 x 268435456 ints to 1073741824 bytes segment
+
+
+
+
+ Segment
+ Time
+
+
+
+
+ HeapMemorySegment
, mixed
+ 2,187 msecs
+
+
+ HybridMemorySegment
, heap, mixed
+ 2,161 msecs
+
+
+ HybridMemorySegment
, off-heap, mixed
+ 2,152 msecs
+
+
+ PureHeapSegment
+ 2,770 msecs
+
+
+ PureHybridSegment
, heap
+ 2,161 msecs
+
+
+ PureHybridSegment
, off-heap
+ 2,157 msecs
+
+
+
+
+
Reading 10 x 268435456 ints from 1073741824 bytes segment
+
+
+
+
+ Segment
+ Time
+
+
+
+
+ HeapMemorySegment
, mixed
+ 1,782 msecs
+
+
+ HybridMemorySegment
, heap, mixed
+ 1,783 msecs
+
+
+ HybridMemorySegment
, off-heap, mixed
+ 1,774 msecs
+
+
+ PureHeapSegment
+ 1,501 msecs
+
+
+ PureHybridSegment
, heap
+ 1,774 msecs
+
+
+ PureHybridSegment
, off-heap
+ 1,771 msecs
+
+
+
+
+
+
diff --git a/docs/content.tr/posts/2015-11-16-release-0.10.0.md b/docs/content.tr/posts/2015-11-16-release-0.10.0.md
new file mode 100644
index 0000000000..9339bd496f
--- /dev/null
+++ b/docs/content.tr/posts/2015-11-16-release-0.10.0.md
@@ -0,0 +1,170 @@
+---
+date: "2015-11-16T08:00:00Z"
+title: Announcing Apache Flink 0.10.0
+aliases:
+- /news/2015/11/16/release-0.10.0.html
+---
+
+The Apache Flink community is pleased to announce the availability of the 0.10.0 release. The community put significant effort into improving and extending Apache Flink since the last release, focusing on data stream processing and operational features. About 80 contributors provided bug fixes, improvements, and new features such that in total more than 400 JIRA issues could be resolved.
+
+For Flink 0.10.0, the focus of the community was to graduate the DataStream API from beta and to evolve Apache Flink into a production-ready stream data processor with a competitive feature set. These efforts resulted in support for event-time and out-of-order streams, exactly-once guarantees in the case of failures, a very flexible windowing mechanism, sophisticated operator state management, and a highly-available cluster operation mode. Flink 0.10.0 also brings a new monitoring dashboard with real-time system and job monitoring capabilities. Both batch and streaming modes of Flink benefit from the new high availability and improved monitoring features. Needless to say that Flink 0.10.0 includes many more features, improvements, and bug fixes.
+
+We encourage everyone to [download the release](/downloads.html) and [check out the documentation]({{< param DocsBaseUrl >}}flink-docs-release-0.10/). Feedback through the Flink [mailing lists](/community.html#mailing-lists) is, as always, very welcome!
+
+## New Features
+
+### Event-time Stream Processing
+
+Many stream processing applications consume data from sources that produce events with associated timestamps such as sensor or user-interaction events. Very often, events have to be collected from several sources such that it is usually not guaranteed that events arrive in the exact order of their timestamps at the stream processor. Consequently, stream processors must take out-of-order elements into account in order to produce results which are correct and consistent with respect to the timestamps of the events. With release 0.10.0, Apache Flink supports event-time processing as well as ingestion-time and processing-time processing. See [FLINK-2674](https://issues.apache.org/jira/browse/FLINK-2674) for details.
+
+### Stateful Stream Processing
+
+Operators that maintain and update state are a common pattern in many stream processing applications. Since streaming applications tend to run for a very long time, operator state can become very valuable and impossible to recompute. In order to enable fault-tolerance, operator state must be backed up to persistent storage in regular intervals. Flink 0.10.0 offers flexible interfaces to define, update, and query operator state and hooks to connect various state backends.
+
+### Highly-available Cluster Operations
+
+Stream processing applications may be live for months. Therefore, a production-ready stream processor must be highly-available and continue to process data even in the face of failures. With release 0.10.0, Flink supports high availability modes for standalone cluster and [YARN](https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html) setups, eliminating any single point of failure. In this mode, Flink relies on [Apache Zookeeper](https://zookeeper.apache.org) for leader election and persisting small sized meta-data of running jobs. You can [check out the documentation]({{< param DocsBaseUrl >}}flink-docs-release-0.10/setup/jobmanager_high_availability.html) to see how to enable high availability. See [FLINK-2287](https://issues.apache.org/jira/browse/FLINK-2287) for details.
+
+### Graduated DataStream API
+
+The DataStream API was revised based on user feedback and with foresight for upcoming features and graduated from beta status to fully supported. The most obvious changes are related to the methods for stream partitioning and window operations. The new windowing system is based on the concepts of window assigners, triggers, and evictors, inspired by the [Dataflow Model](http://www.vldb.org/pvldb/vol8/p1792-Akidau.pdf). The new API is fully described in the [DataStream API documentation]({{< param DocsBaseUrl >}}flink-docs-release-0.10/apis/streaming_guide.html). This [migration guide](https://cwiki.apache.org/confluence/display/FLINK/Migration+Guide%3A+0.9.x+to+0.10.x) will help to port your Flink 0.9 DataStream programs to the revised API of Flink 0.10.0. See [FLINK-2674](https://issues.apache.org/jira/browse/FLINK-2674) and [FLINK-2877](https://issues.apache.org/jira/browse/FLINK-2877) for details.
+
+### New Connectors for Data Streams
+
+Apache Flink 0.10.0 features DataStream sources and sinks for many common data producers and stores. This includes an exactly-once rolling file sink which supports any file system, including HDFS, local FS, and S3. We also updated the [Apache Kafka](https://kafka.apache.org) producer to use the new producer API, and added a connectors for [ElasticSearch](https://github.com/elastic/elasticsearch) and [Apache Nifi](https://nifi.apache.org). More connectors for DataStream programs will be added by the community in the future. See the following JIRA issues for details [FLINK-2583](https://issues.apache.org/jira/browse/FLINK-2583), [FLINK-2386](https://issues.apache.org/jira/browse/FLINK-2386), [FLINK-2372](https://issues.apache.org/jira/browse/FLINK-2372), [FLINK-2740](https://issues.apache.org/jira/browse/FLINK-2740), and [FLINK-2558](https://issues.apache.org/jira/browse/FLINK-2558).
+
+### New Web Dashboard & Real-time Monitoring
+
+The 0.10.0 release features a newly designed and significantly improved monitoring dashboard for Apache Flink. The new dashboard visualizes the progress of running jobs and shows real-time statistics of processed data volumes and record counts. Moreover, it gives access to resource usage and JVM statistics of TaskManagers including JVM heap usage and garbage collection details. The following screenshot shows the job view of the new dashboard.
+
+
+
+
+
+The web server that provides all monitoring statistics has been designed with a REST interface allowing other systems to also access the internal system metrics. See [FLINK-2357](https://issues.apache.org/jira/browse/FLINK-2357) for details.
+
+### Off-heap Managed Memory
+
+Flink’s internal operators (such as its sort algorithm and hash tables) write data to and read data from managed memory to achieve memory-safe operations and reduce garbage collection overhead. Until version 0.10.0, managed memory was allocated only from JVM heap memory. With this release, managed memory can also be allocated from off-heap memory. This will facilitate shorter TaskManager start-up times as well as reduce garbage collection pressure. See [the documentation]({{< param DocsBaseUrl >}}flink-docs-release-0.10/setup/config.html#managed-memory) to learn how to configure managed memory on off-heap memory. JIRA issue [FLINK-1320](https://issues.apache.org/jira/browse/FLINK-1320) contains further details.
+
+### Outer Joins
+
+Outer joins have been one of the most frequently requested features for Flink’s [DataSet API]({{< param DocsBaseUrl >}}flink-docs-release-0.10/apis/programming_guide.html). Although there was a workaround to implement outer joins as CoGroup function, it had significant drawbacks including added code complexity and not being fully memory-safe. With release 0.10.0, Flink adds native support for [left, right, and full outer joins]({{< param DocsBaseUrl >}}flink-docs-release-0.10/apis/dataset_transformations.html#outerjoin) to the DataSet API. All outer joins are backed by a memory-safe operator implementation that leverages Flink’s managed memory. See [FLINK-687](https://issues.apache.org/jira/browse/FLINK-687) and [FLINK-2107](https://issues.apache.org/jira/browse/FLINK-2107) for details.
+
+### Gelly: Major Improvements and Scala API
+
+[Gelly]({{< param DocsBaseUrl >}}flink-docs-release-0.10/libs/gelly_guide.html) is Flink’s API and library for processing and analyzing large-scale graphs. Gelly was introduced with release 0.9.0 and has been very well received by users and contributors. Based on user feedback, Gelly has been improved since then. In addition, Flink 0.10.0 introduces a Scala API for Gelly. See [FLINK-2857](https://issues.apache.org/jira/browse/FLINK-2857) and [FLINK-1962](https://issues.apache.org/jira/browse/FLINK-1962) for details.
+
+## More Improvements and Fixes
+
+The Flink community resolved more than 400 issues. The following list is a selection of new features and fixed bugs.
+
+- [FLINK-1851](https://issues.apache.org/jira/browse/FLINK-1851) Java Table API does not support Casting
+- [FLINK-2152](https://issues.apache.org/jira/browse/FLINK-2152) Provide zipWithIndex utility in flink-contrib
+- [FLINK-2158](https://issues.apache.org/jira/browse/FLINK-2158) NullPointerException in DateSerializer.
+- [FLINK-2240](https://issues.apache.org/jira/browse/FLINK-2240) Use BloomFilter to minimize probe side records which are spilled to disk in Hybrid-Hash-Join
+- [FLINK-2533](https://issues.apache.org/jira/browse/FLINK-2533) Gap based random sample optimization
+- [FLINK-2555](https://issues.apache.org/jira/browse/FLINK-2555) Hadoop Input/Output Formats are unable to access secured HDFS clusters
+- [FLINK-2565](https://issues.apache.org/jira/browse/FLINK-2565) Support primitive arrays as keys
+- [FLINK-2582](https://issues.apache.org/jira/browse/FLINK-2582) Document how to build Flink with other Scala versions
+- [FLINK-2584](https://issues.apache.org/jira/browse/FLINK-2584) ASM dependency is not shaded away
+- [FLINK-2689](https://issues.apache.org/jira/browse/FLINK-2689) Reusing null object for joins with SolutionSet
+- [FLINK-2703](https://issues.apache.org/jira/browse/FLINK-2703) Remove log4j classes from fat jar / document how to use Flink with logback
+- [FLINK-2763](https://issues.apache.org/jira/browse/FLINK-2763) Bug in Hybrid Hash Join: Request to spill a partition with less than two buffers.
+- [FLINK-2767](https://issues.apache.org/jira/browse/FLINK-2767) Add support Scala 2.11 to Scala shell
+- [FLINK-2774](https://issues.apache.org/jira/browse/FLINK-2774) Import Java API classes automatically in Flink's Scala shell
+- [FLINK-2782](https://issues.apache.org/jira/browse/FLINK-2782) Remove deprecated features for 0.10
+- [FLINK-2800](https://issues.apache.org/jira/browse/FLINK-2800) kryo serialization problem
+- [FLINK-2834](https://issues.apache.org/jira/browse/FLINK-2834) Global round-robin for temporary directories
+- [FLINK-2842](https://issues.apache.org/jira/browse/FLINK-2842) S3FileSystem is broken
+- [FLINK-2874](https://issues.apache.org/jira/browse/FLINK-2874) Certain Avro generated getters/setters not recognized
+- [FLINK-2895](https://issues.apache.org/jira/browse/FLINK-2895) Duplicate immutable object creation
+- [FLINK-2964](https://issues.apache.org/jira/browse/FLINK-2964) MutableHashTable fails when spilling partitions without overflow segments
+
+## Notice
+
+As previously announced, Flink 0.10.0 no longer supports Java 6. If you are still using Java 6, please consider upgrading to Java 8 (Java 7 ended its free support in April 2015).
+Also note that some methods in the DataStream API had to be renamed as part of the API rework. For example the `groupBy` method has been renamed to `keyBy` and the windowing API changed. This [migration guide](https://cwiki.apache.org/confluence/display/FLINK/Migration+Guide%3A+0.9.x+to+0.10.x) will help to port your Flink 0.9 DataStream programs to the revised API of Flink 0.10.0.
+
+## Contributors
+
+- Alexander Alexandrov
+- Marton Balassi
+- Enrique Bautista
+- Faye Beligianni
+- Bryan Bende
+- Ajay Bhat
+- Chris Brinkman
+- Dmitry Buzdin
+- Kun Cao
+- Paris Carbone
+- Ufuk Celebi
+- Shivani Chandna
+- Liang Chen
+- Felix Cheung
+- Hubert Czerpak
+- Vimal Das
+- Behrouz Derakhshan
+- Suminda Dharmasena
+- Stephan Ewen
+- Fengbin Fang
+- Gyula Fora
+- Lun Gao
+- Gabor Gevay
+- Piotr Godek
+- Sachin Goel
+- Anton Haglund
+- Gábor Hermann
+- Greg Hogan
+- Fabian Hueske
+- Martin Junghanns
+- Vasia Kalavri
+- Ulf Karlsson
+- Frederick F. Kautz
+- Samia Khalid
+- Johannes Kirschnick
+- Kostas Kloudas
+- Alexander Kolb
+- Johann Kovacs
+- Aljoscha Krettek
+- Sebastian Kruse
+- Andreas Kunft
+- Chengxiang Li
+- Chen Liang
+- Andra Lungu
+- Suneel Marthi
+- Tamara Mendt
+- Robert Metzger
+- Maximilian Michels
+- Chiwan Park
+- Sahitya Pavurala
+- Pietro Pinoli
+- Ricky Pogalz
+- Niraj Rai
+- Lokesh Rajaram
+- Johannes Reifferscheid
+- Till Rohrmann
+- Henry Saputra
+- Matthias Sax
+- Shiti Saxena
+- Chesnay Schepler
+- Peter Schrott
+- Saumitra Shahapure
+- Nikolaas Steenbergen
+- Thomas Sun
+- Peter Szabo
+- Viktor Taranenko
+- Kostas Tzoumas
+- Pieter-Jan Van Aeken
+- Theodore Vasiloudis
+- Timo Walther
+- Chengxuan Wang
+- Huang Wei
+- Dawid Wysakowicz
+- Rerngvit Yanggratoke
+- Nezih Yigitbasi
+- Ted Yu
+- Rucong Zhang
+- Vyacheslav Zholudev
+- Zoltán Zvara
+
diff --git a/docs/content.tr/posts/2015-11-27-release-0.10.1.md b/docs/content.tr/posts/2015-11-27-release-0.10.1.md
new file mode 100644
index 0000000000..7116ba44eb
--- /dev/null
+++ b/docs/content.tr/posts/2015-11-27-release-0.10.1.md
@@ -0,0 +1,58 @@
+---
+date: "2015-11-27T08:00:00Z"
+title: Flink 0.10.1 released
+aliases:
+- /news/2015/11/27/release-0.10.1.html
+---
+
+Today, the Flink community released the first bugfix release of the 0.10 series of Flink.
+
+We recommend all users updating to this release, by bumping the version of your Flink dependencies and updating the binaries on the server.
+
+## Issues fixed
+
+
+[FLINK-2879 ] - Links in documentation are broken
+
+[FLINK-2938 ] - Streaming docs not in sync with latest state changes
+
+[FLINK-2942 ] - Dangling operators in web UI's program visualization (non-deterministic)
+
+[FLINK-2967 ] - TM address detection might not always detect the right interface on slow networks / overloaded JMs
+
+[FLINK-2977 ] - Cannot access HBase in a Kerberos secured Yarn cluster
+
+[FLINK-2987 ] - Flink 0.10 fails to start on YARN 2.6.0
+
+[FLINK-2989 ] - Job Cancel button doesn't work on Yarn
+
+[FLINK-3005 ] - Commons-collections object deserialization remote command execution vulnerability
+
+[FLINK-3011 ] - Cannot cancel failing/restarting streaming job from the command line
+
+[FLINK-3019 ] - CLI does not list running/restarting jobs
+
+[FLINK-3020 ] - Local streaming execution: set number of task manager slots to the maximum parallelism
+
+[FLINK-3024 ] - TimestampExtractor Does not Work When returning Long.MIN_VALUE
+
+[FLINK-3032 ] - Flink does not start on Hadoop 2.7.1 (HDP), due to class conflict
+
+[FLINK-3043 ] - Kafka Connector description in Streaming API guide is wrong/outdated
+
+[FLINK-3047 ] - Local batch execution: set number of task manager slots to the maximum parallelism
+
+[FLINK-3052 ] - Optimizer does not push properties out of bulk iterations
+
+[FLINK-2966 ] - Improve the way job duration is reported on web frontend.
+
+[FLINK-2974 ] - Add periodic offset commit to Kafka Consumer if checkpointing is disabled
+
+[FLINK-3028 ] - Cannot cancel restarting job via web frontend
+
+[FLINK-3040 ] - Add docs describing how to configure State Backends
+
+[FLINK-3041 ] - Twitter Streaming Description section of Streaming Programming guide refers to an incorrect example 'TwitterLocal'
+
+
+
diff --git a/docs/content.tr/posts/2015-12-04-Introducing-windows.md b/docs/content.tr/posts/2015-12-04-Introducing-windows.md
new file mode 100644
index 0000000000..536928053c
--- /dev/null
+++ b/docs/content.tr/posts/2015-12-04-Introducing-windows.md
@@ -0,0 +1,175 @@
+---
+author: Fabian Hueske
+author-twitter: fhueske
+date: "2015-12-04T10:00:00Z"
+excerpt: |-
+ The data analysis space is witnessing an evolution from batch to stream processing for many use cases. Although batch can be handled as a special case of stream processing, analyzing never-ending streaming data often requires a shift in the mindset and comes with its own terminology (for example, “windowing” and “at-least-once”/”exactly-once” processing). This shift and the new terminology can be quite confusing for people being new to the space of stream processing. Apache Flink is a production-ready stream processor with an easy-to-use yet very expressive API to define advanced stream analysis programs. Flink's API features very flexible window definitions on data streams which let it stand out among other open source stream processors.
+ In this blog post, we discuss the concept of windows for stream processing, present Flink's built-in windows, and explain its support for custom windowing semantics.
+title: Introducing Stream Windows in Apache Flink
+aliases:
+- /news/2015/12/04/Introducing-windows.html
+---
+
+The data analysis space is witnessing an evolution from batch to stream processing for many use cases. Although batch can be handled as a special case of stream processing, analyzing never-ending streaming data often requires a shift in the mindset and comes with its own terminology (for example, “windowing” and “at-least-once”/”exactly-once” processing). This shift and the new terminology can be quite confusing for people being new to the space of stream processing. Apache Flink is a production-ready stream processor with an easy-to-use yet very expressive API to define advanced stream analysis programs. Flink's API features very flexible window definitions on data streams which let it stand out among other open source stream processors.
+
+In this blog post, we discuss the concept of windows for stream processing, present Flink's built-in windows, and explain its support for custom windowing semantics.
+
+## What are windows and what are they good for?
+
+Consider the example of a traffic sensor that counts every 15 seconds the number of vehicles passing a certain location. The resulting stream could look like:
+
+
+
+
+
+If you would like to know, how many vehicles passed that location, you would simply sum the individual counts. However, the nature of a sensor stream is that it continuously produces data. Such a stream never ends and it is not possible to compute a final sum that can be returned. Instead, it is possible to compute rolling sums, i.e., return for each input event an updated sum record. This would yield a new stream of partial sums.
+
+
+
+
+
+However, a stream of partial sums might not be what we are looking for, because it constantly updates the count and even more important, some information such as variation over time is lost. Hence, we might want to rephrase our question and ask for the number of cars that pass the location every minute. This requires us to group the elements of the stream into finite sets, each set corresponding to sixty seconds. This operation is called a *tumbling windows* operation.
+
+
+
+
+
+Tumbling windows discretize a stream into non-overlapping windows. For certain applications it is important that windows are not disjunct because an application might require smoothed aggregates. For example, we can compute every thirty seconds the number of cars passed in the last minute. Such windows are called *sliding windows*.
+
+
+
+
+
+Defining windows on a data stream as discussed before is a non-parallel operation. This is because each element of a stream must be processed by the same window operator that decides which windows the element should be added to. Windows on a full stream are called *AllWindows* in Flink. For many applications, a data stream needs to be grouped into multiple logical streams on each of which a window operator can be applied. Think for example about a stream of vehicle counts from multiple traffic sensors (instead of only one sensor as in our previous example), where each sensor monitors a different location. By grouping the stream by sensor id, we can compute windowed traffic statistics for each location in parallel. In Flink, we call such partitioned windows simply *Windows*, as they are the common case for distributed streams. The following figure shows tumbling windows that collect two elements over a stream of `(sensorId, count)` pair elements.
+
+
+
+
+
+Generally speaking, a window defines a finite set of elements on an unbounded stream. This set can be based on time (as in our previous examples), element counts, a combination of counts and time, or some custom logic to assign elements to windows. Flink's DataStream API provides concise operators for the most common window operations as well as a generic windowing mechanism that allows users to define very custom windowing logic. In the following we present Flink's time and count windows before discussing its windowing mechanism in detail.
+
+## Time Windows
+
+As their name suggests, time windows group stream elements by time. For example, a tumbling time window of one minute collects elements for one minute and applies a function on all elements in the window after one minute passed.
+
+Defining tumbling and sliding time windows in Apache Flink is very easy:
+
+
+```scala
+// Stream of (sensorId, carCnt)
+val vehicleCnts: DataStream[(Int, Int)] = ...
+
+val tumblingCnts: DataStream[(Int, Int)] = vehicleCnts
+ // key stream by sensorId
+ .keyBy(0)
+ // tumbling time window of 1 minute length
+ .timeWindow(Time.minutes(1))
+ // compute sum over carCnt
+ .sum(1)
+
+val slidingCnts: DataStream[(Int, Int)] = vehicleCnts
+ .keyBy(0)
+ // sliding time window of 1 minute length and 30 secs trigger interval
+ .timeWindow(Time.minutes(1), Time.seconds(30))
+ .sum(1)
+```
+
+
+ There is one aspect that we haven't discussed yet, namely the exact meaning of "*collects elements for one minute*" which boils down to the question, "*How does the stream processor interpret time?*".
+
+Apache Flink features three different notions of time, namely *processing time*, *event time*, and *ingestion time*.
+
+1. In **processing time**, windows are defined with respect to the wall clock of the machine that builds and processes a window, i.e., a one minute processing time window collects elements for exactly one minute.
+1. In **event time**, windows are defined with respect to timestamps that are attached to each event record. This is common for many types of events, such as log entries, sensor data, etc, where the timestamp usually represents the time at which the event occurred. Event time has several benefits over processing time. First of all, it decouples the program semantics from the actual serving speed of the source and the processing performance of system. Hence you can process historic data, which is served at maximum speed, and continuously produced data with the same program. It also prevents semantically incorrect results in case of backpressure or delays due to failure recovery. Second, event time windows compute correct results, even if events arrive out-of-order of their timestamp which is common if a data stream gathers events from distributed sources.
+1. **Ingestion time** is a hybrid of processing and event time. It assigns wall clock timestamps to records as soon as they arrive in the system (at the source) and continues processing with event time semantics based on the attached timestamps.
+
+## Count Windows
+
+Apache Flink also features count windows. A tumbling count window of 100 will collect 100 events in a window and evaluate the window when the 100th element has been added.
+
+In Flink's DataStream API, tumbling and sliding count windows are defined as follows:
+
+```scala
+// Stream of (sensorId, carCnt)
+val vehicleCnts: DataStream[(Int, Int)] = ...
+
+val tumblingCnts: DataStream[(Int, Int)] = vehicleCnts
+ // key stream by sensorId
+ .keyBy(0)
+ // tumbling count window of 100 elements size
+ .countWindow(100)
+ // compute the carCnt sum
+ .sum(1)
+
+val slidingCnts: DataStream[(Int, Int)] = vehicleCnts
+ .keyBy(0)
+ // sliding count window of 100 elements size and 10 elements trigger interval
+ .countWindow(100, 10)
+ .sum(1)
+```
+
+## Dissecting Flink's windowing mechanics
+
+Flink's built-in time and count windows cover a wide range of common window use cases. However, there are of course applications that require custom windowing logic that cannot be addressed by Flink's built-in windows. In order to support also applications that need very specific windowing semantics, the DataStream API exposes interfaces for the internals of its windowing mechanics. These interfaces give very fine-grained control about the way that windows are built and evaluated.
+
+The following figure depicts Flink's windowing mechanism and introduces the components being involved.
+
+
+
+
+
+Elements that arrive at a window operator are handed to a `WindowAssigner`. The WindowAssigner assigns elements to one or more windows, possibly creating new windows. A `Window` itself is just an identifier for a list of elements and may provide some optional meta information, such as begin and end time in case of a `TimeWindow`. Note that an element can be added to multiple windows, which also means that multiple windows can exist at the same time.
+
+Each window owns a `Trigger` that decides when the window is evaluated or purged. The trigger is called for each element that is inserted into the window and when a previously registered timer times out. On each event, a trigger can decide to fire (i.e., evaluate), purge (remove the window and discard its content), or fire and then purge the window. A trigger that just fires evaluates the window and keeps it as it is, i.e., all elements remain in the window and are evaluated again when the triggers fires the next time. A window can be evaluated several times and exists until it is purged. Note that a window consumes memory until it is purged.
+
+When a Trigger fires, the list of window elements can be given to an optional `Evictor`. The evictor can iterate through the list and decide to cut off some elements from the start of the list, i.e., remove some of the elements that entered the window first. The remaining elements are given to an evaluation function. If no Evictor was defined, the Trigger hands all the window elements directly to the evaluation function.
+
+The evaluation function receives the elements of a window (possibly filtered by an Evictor) and computes one or more result elements for the window. The DataStream API accepts different types of evaluation functions, including predefined aggregation functions such as `sum()`, `min()`, `max()`, as well as a `ReduceFunction`, `FoldFunction`, or `WindowFunction`. A WindowFunction is the most generic evaluation function and receives the window object (i.e, the metadata of the window), the list of window elements, and the window key (in case of a keyed window) as parameters.
+
+These are the components that constitute Flink's windowing mechanics. We now show step-by-step how to implement custom windowing logic with the DataStream API. We start with a stream of type `DataStream[IN]` and key it using a key selector function that extracts a key of type `KEY` to obtain a `KeyedStream[IN, KEY]`.
+
+```scala
+val input: DataStream[IN] = ...
+
+// created a keyed stream using a key selector function
+val keyed: KeyedStream[IN, KEY] = input
+ .keyBy(myKeySel: (IN) => KEY)
+```
+
+We apply a `WindowAssigner[IN, WINDOW]` that creates windows of type `WINDOW` resulting in a `WindowedStream[IN, KEY, WINDOW]`. In addition, a `WindowAssigner` also provides a default `Trigger` implementation.
+
+```scala
+// create windowed stream using a WindowAssigner
+var windowed: WindowedStream[IN, KEY, WINDOW] = keyed
+ .window(myAssigner: WindowAssigner[IN, WINDOW])
+```
+
+We can explicitly specify a `Trigger` to overwrite the default `Trigger` provided by the `WindowAssigner`. Note that specifying a triggers does not add an additional trigger condition but replaces the current trigger.
+
+```scala
+// override the default trigger of the WindowAssigner
+windowed = windowed
+ .trigger(myTrigger: Trigger[IN, WINDOW])
+```
+
+We may want to specify an optional `Evictor` as follows.
+
+```scala
+// specify an optional evictor
+windowed = windowed
+ .evictor(myEvictor: Evictor[IN, WINDOW])
+```
+
+Finally, we apply a `WindowFunction` that returns elements of type `OUT` to obtain a `DataStream[OUT]`.
+
+```scala
+// apply window function to windowed stream
+val output: DataStream[OUT] = windowed
+ .apply(myWinFunc: WindowFunction[IN, OUT, KEY, WINDOW])
+```
+
+With Flink's internal windowing mechanics and its exposure through the DataStream API it is possible to implement very custom windowing logic such as session windows or windows that emit early results if the values exceed a certain threshold.
+
+## Conclusion
+
+Support for various types of windows over continuous data streams is a must-have for modern stream processors. Apache Flink is a stream processor with a very strong feature set, including a very flexible mechanism to build and evaluate windows over continuous data streams. Flink provides pre-defined window operators for common uses cases as well as a toolbox that allows to define very custom windowing logic. The Flink community will add more pre-defined window operators as we learn the requirements from our users.
\ No newline at end of file
diff --git a/docs/content.tr/posts/2015-12-11-storm-compatibility.md b/docs/content.tr/posts/2015-12-11-storm-compatibility.md
new file mode 100644
index 0000000000..12e8e45e23
--- /dev/null
+++ b/docs/content.tr/posts/2015-12-11-storm-compatibility.md
@@ -0,0 +1,160 @@
+---
+author: Matthias J. Sax
+author-twitter: MatthiasJSax
+date: "2015-12-11T10:00:00Z"
+excerpt: In this blog post, we describe Flink's compatibility package for Apache
+ Storm that allows to embed Spouts (sources) and Bolts (operators) in a regular
+ Flink streaming job. Furthermore, the compatibility package provides a Storm compatible
+ API in order to execute whole Storm topologies with (almost) no code adaption.
+title: 'Storm Compatibility in Apache Flink: How to run existing Storm topologies
+ on Flink'
+aliases:
+- /news/2015/12/11/storm-compatibility.html
+---
+
+[Apache Storm](https://storm.apache.org) was one of the first distributed and scalable stream processing systems available in the open source space offering (near) real-time tuple-by-tuple processing semantics.
+Initially released by the developers at Backtype in 2011 under the Eclipse open-source license, it became popular very quickly.
+Only shortly afterwards, Twitter acquired Backtype.
+Since then, Storm has been growing in popularity, is used in production at many big companies, and is the de-facto industry standard for big data stream processing.
+In 2013, Storm entered the Apache incubator program, followed by its graduation to top-level in 2014.
+
+Apache Flink is a stream processing engine that improves upon older technologies like Storm in several dimensions,
+including [strong consistency guarantees]({{< param DocsBaseUrl >}}flink-docs-master/internals/stream_checkpointing.html) ("exactly once"),
+a higher level [DataStream API]({{< param DocsBaseUrl >}}flink-docs-master/apis/streaming_guide.html),
+support for [event time and a rich windowing system](http://flink.apache.org/news/2015/12/04/Introducing-windows.html),
+as well as [superior throughput with competitive low latency](https://data-artisans.com/high-throughput-low-latency-and-exactly-once-stream-processing-with-apache-flink/).
+
+While Flink offers several technical benefits over Storm, an existing investment on a codebase of applications developed for Storm often makes it difficult to switch engines.
+For these reasons, as part of the Flink 0.10 release, Flink ships with a Storm compatibility package that allows users to:
+
+* Run **unmodified** Storm topologies using Apache Flink benefiting from superior performance.
+* **Embed** Storm code (spouts and bolts) as operators inside Flink DataStream programs.
+
+Only minor code changes are required in order to submit the program to Flink instead of Storm.
+This minimizes the work for developers to run existing Storm topologies while leveraging Apache Flink’s fast and robust execution engine.
+
+We note that the Storm compatibility package is continuously improving and does not cover the full spectrum of Storm’s API.
+However, it is powerful enough to cover many use cases.
+
+## Executing Storm topologies with Flink
+
+
+
+
+
+The easiest way to use the Storm compatibility package is by executing a whole Storm topology in Flink.
+For this, you only need to replace the dependency `storm-core` by `flink-storm` in your Storm project and **change two lines of code** in your original Storm program.
+
+The following example shows a simple Storm-Word-Count-Program that can be executed in Flink.
+First, the program is assembled the Storm way without any code change to Spouts, Bolts, or the topology itself.
+
+```java
+// assemble topology, the Storm way
+TopologyBuilder builder = new TopologyBuilder();
+builder.setSpout("source", new StormFileSpout(inputFilePath));
+builder.setBolt("tokenizer", new StormBoltTokenizer())
+ .shuffleGrouping("source");
+builder.setBolt("counter", new StormBoltCounter())
+ .fieldsGrouping("tokenizer", new Fields("word"));
+builder.setBolt("sink", new StormBoltFileSink(outputFilePath))
+ .shuffleGrouping("counter");
+```
+
+In order to execute the topology, we need to translate it to a `FlinkTopology` and submit it to a local or remote Flink cluster, very similar to submitting the application to a Storm cluster.1
+
+```java
+// transform Storm topology to Flink program
+// replaces: StormTopology topology = builder.createTopology();
+FlinkTopology topology = FlinkTopology.createTopology(builder);
+
+Config conf = new Config();
+if(runLocal) {
+ // use FlinkLocalCluster instead of LocalCluster
+ FlinkLocalCluster cluster = FlinkLocalCluster.getLocalCluster();
+ cluster.submitTopology("WordCount", conf, topology);
+} else {
+ // use FlinkSubmitter instead of StormSubmitter
+ FlinkSubmitter.submitTopology("WordCount", conf, topology);
+}
+```
+
+As a shorter Flink-style alternative that replaces the Storm-style submission code, you can also use context-based job execution:
+
+```java
+// transform Storm topology to Flink program (as above)
+FlinkTopology topology = FlinkTopology.createTopology(builder);
+
+// executes locally by default or remotely if submitted with Flink's command-line client
+topology.execute()
+```
+
+After the code is packaged in a jar file (e.g., `StormWordCount.jar`), it can be easily submitted to Flink via
+
+```
+bin/flink run StormWordCount.jar
+```
+
+The used Spouts and Bolts as well as the topology assemble code is not changed at all!
+Only the translation and submission step have to be changed to the Storm-API compatible Flink pendants.
+This allows for minimal code changes and easy adaption to Flink.
+
+### Embedding Spouts and Bolts in Flink programs
+
+It is also possible to use Spouts and Bolts within a regular Flink DataStream program.
+The compatibility package provides wrapper classes for Spouts and Bolts which are implemented as a Flink `SourceFunction` and `StreamOperator` respectively.
+Those wrappers automatically translate incoming Flink POJO and `TupleXX` records into Storm's `Tuple` type and emitted `Values` back into either POJOs or `TupleXX` types for further processing by Flink operators.
+As Storm is type agnostic, it is required to specify the output type of embedded Spouts/Bolts manually to get a fully typed Flink streaming program.
+
+```java
+// use regular Flink streaming environment
+StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
+
+// use Spout as source
+DataStream> source =
+ env.addSource(// Flink provided wrapper including original Spout
+ new SpoutWrapper(new FileSpout(localFilePath)),
+ // specify output type manually
+ TypeExtractor.getForObject(new Tuple1("")));
+// FileSpout cannot be parallelized
+DataStream> text = source.setParallelism(1);
+
+// further processing with Flink
+DataStream tokens = text.flatMap(new Tokenizer()).keyBy(0);
+
+// use Bolt for counting
+DataStream counts =
+ tokens.transform("Counter",
+ // specify output type manually
+ TypeExtractor.getForObject(new Tuple2("",0))
+ // Flink provided wrapper including original Bolt
+ new BoltWrapper>(new BoltCounter()));
+
+// write result to file via Flink sink
+counts.writeAsText(outputPath);
+
+// start Flink job
+env.execute("WordCount with Spout source and Bolt counter");
+```
+
+Although some boilerplate code is needed (we plan to address this soon!), the actual embedded Spout and Bolt code can be used unmodified.
+We also note that the resulting program is fully typed, and type errors will be found by Flink's type extractor even if the original Spouts and Bolts are not.
+
+## Outlook
+
+The Storm compatibility package is currently in beta and undergoes continuous development.
+We are currently working on providing consistency guarantees for stateful Bolts.
+Furthermore, we want to provide a better API integration for embedded Spouts and Bolts by providing a "StormExecutionEnvironment" as a special extension of Flink's `StreamExecutionEnvironment`.
+We are also investigating the integration of Storm's higher-level programming API Trident.
+
+## Summary
+
+Flink's compatibility package for Storm allows using unmodified Spouts and Bolts within Flink.
+This enables you to even embed third-party Spouts and Bolts where the source code is not available.
+While you can embed Spouts/Bolts in a Flink program and mix-and-match them with Flink operators, running whole topologies is the easiest way to get started and can be achieved with almost no code changes.
+
+If you want to try out Flink's Storm compatibility package checkout our [Documentation]({{< param DocsBaseUrl >}}flink-docs-master/apis/streaming/storm_compatibility.html).
+
+
+
+1. We confess, there are three lines changed compared to a Storm project ---because the example covers local *and* remote execution. ↩
+
diff --git a/docs/content.tr/posts/2015-12-18-a-year-in-review.md b/docs/content.tr/posts/2015-12-18-a-year-in-review.md
new file mode 100644
index 0000000000..99d9b1a7ce
--- /dev/null
+++ b/docs/content.tr/posts/2015-12-18-a-year-in-review.md
@@ -0,0 +1,215 @@
+---
+author: Robert Metzger
+author-twitter: rmetzger_
+date: "2015-12-18T10:00:00Z"
+excerpt: With 2015 ending, we thought that this would be good time to reflect on
+ the amazing work done by the Flink community over this past year, and how much this
+ community has grown.
+title: 'Flink 2015: A year in review, and a lookout to 2016'
+aliases:
+- /news/2015/12/18/a-year-in-review.html
+---
+
+With 2015 ending, we thought that this would be good time to reflect
+on the amazing work done by the Flink community over this past year,
+and how much this community has grown.
+
+Overall, we have seen Flink grow in terms of functionality from an
+engine to one of the most complete open-source stream processing
+frameworks available. The community grew from a relatively small and
+geographically focused team, to a truly global, and one of the largest
+big data communities in the the Apache Software Foundation.
+
+We will also look at some interesting stats, including that the
+busiest days for Flink are Mondays (who would have thought :-).
+
+# Community growth
+
+Let us start with some simple statistics from [Flink's
+github repository](https://github.com/apache/flink). During 2015, the
+Flink community **doubled** in size, from about 75 contributors to
+over 150. Forks of the repository more than **tripled** from 160 in
+February 2015 to 544 in December 2015, and the number of stars of the
+repository almost tripled from 289 to 813.
+
+
+
+
+
+Although Flink started out geographically in Berlin, Germany, the
+community is by now spread all around the globe, with many
+contributors from North America, Europe, and Asia. A simple search at
+meetup.com for groups that mention Flink as a focus area reveals [16
+meetups around the globe](http://apache-flink.meetup.com/):
+
+
+
+
+
+# Flink Forward 2015
+
+One of the highlights of the year for Flink was undoubtedly the [Flink
+Forward](http://2015.flink-forward.org/) conference, the first conference
+on Apache Flink that was held in October in Berlin. More than 250
+participants (roughly half based outside Germany where the conference
+was held) attended more than 33 technical talks from organizations
+including Google, MongoDB, Bouygues Telecom, NFLabs, Euranova, RedHat,
+IBM, Huawei, Intel, Ericsson, Capital One, Zalando, Amadeus, the Otto
+Group, and ResearchGate. If you have not yet watched their talks,
+check out the [slides](http://2015.flink-forward.org/?post_type=day) and
+[videos](https://www.youtube.com/playlist?list=PLDX4T_cnKjD31JeWR1aMOi9LXPRQ6nyHO)
+from Flink Forward.
+
+
+
+
+
+# Media coverage
+
+And of course, interest in Flink was picked up by the tech
+media. During 2015, articles about Flink appeared in
+[InfoQ](http://www.infoq.com/Apache-Flink/news/),
+[ZDNet](http://www.zdnet.com/article/five-open-source-big-data-projects-to-watch/),
+[Datanami](http://www.datanami.com/tag/apache-flink/),
+[Infoworld](http://www.infoworld.com/article/2919602/hadoop/flink-hadoops-new-contender-for-mapreduce-spark.html)
+(including being one of the [best open source big data tools of
+2015](http://www.infoworld.com/article/2982429/open-source-tools/bossie-awards-2015-the-best-open-source-big-data-tools.html)),
+the [Gartner
+blog](http://blogs.gartner.com/nick-heudecker/apache-flink-offers-a-challenge-to-spark/),
+[Dataconomy](http://dataconomy.com/tag/apache-flink/),
+[SDTimes](http://sdtimes.com/tag/apache-flink/), the [MapR
+blog](https://www.mapr.com/blog/apache-flink-new-way-handle-streaming-data),
+[KDnuggets](http://www.kdnuggets.com/2015/08/apache-flink-stream-processing.html),
+and
+[HadoopSphere](http://www.hadoopsphere.com/2015/02/distributed-data-processing-with-apache.html).
+
+
+
+
+
+It is interesting to see that Hadoop Summit EMEA 2016 had a whopping
+number of 17 (!) talks submitted that are mentioning Flink in their
+title and abstract:
+
+
+
+
+
+# Fun with stats: when do committers commit?
+
+To get some deeper insight on what is happening in the Flink
+community, let us do some analytics on the git log of the project :-)
+The easiest thing we can do is count the number of commits at the
+repository in 2015. Running
+
+```
+git log --pretty=oneline --after=1/1/2015 | wc -l
+```
+
+on the Flink repository yields a total of **2203 commits** in 2015.
+
+To dig deeper, we will use an open source tool called gitstats that
+will give us some interesting statistics on the committer
+behavior. You can create these also yourself and see many more by
+following four easy steps:
+
+1. Download gitstats from the [project homepage](http://gitstats.sourceforge.net/).. E.g., on OS X with homebrew, type
+
+```
+brew install --HEAD homebrew/head-only/gitstats
+```
+
+2. Clone the Apache Flink git repository:
+
+```
+git clone git@github.com:apache/flink.git
+```
+
+3. Generate the statistics
+
+```
+gitstats flink/ flink-stats/
+```
+
+4. View all the statistics as an html page using your favorite browser (e.g., chrome):
+
+```
+chrome flink-stats/index.html
+```
+
+First, we can see a steady growth of lines of code in Flink since the
+initial Apache incubator project. During 2015, the codebase almost
+**doubled** from 500,000 LOC to 900,000 LOC.
+
+
+
+
+
+It is interesting to see when committers commit. For Flink, Monday
+afternoons are by far the most popular times to commit to the
+repository:
+
+
+
+
+
+# Feature timeline
+
+So, what were the major features added to Flink and the Flink
+ecosystem during 2015? Here is a (non-exhaustive) chronological list:
+
+
+
+
+
+# Roadmap for 2016
+
+With 2015 coming to a close, the Flink community has already started
+discussing Flink's roadmap for the future. Some highlights
+are:
+
+* **Runtime scaling of streaming jobs:** streaming jobs are running
+ forever, and need to react to a changing environment. Runtime
+ scaling means dynamically increasing and decreasing the
+ parallelism of a job to sustain certain SLAs, or react to changing
+ input throughput.
+
+* **SQL queries for static data sets and streams:** building on top of
+ Flink's Table API, users should be able to write SQL
+ queries for static data sets, as well as SQL queries on data
+ streams that continuously produce new results.
+
+* **Streaming operators backed by managed memory:** currently,
+ streaming operators like user-defined state and windows are backed
+ by JVM heap objects. Moving those to Flink managed memory will add
+ the ability to spill to disk, GC efficiency, as well as better
+ control over memory utilization.
+
+* **Library for detecting temporal event patterns:** a common use case
+ for stream processing is detecting patterns in an event stream
+ with timestamps. Flink makes this possible with its support for
+ event time, so many of these operators can be surfaced in the form
+ of a library.
+
+* **Support for Apache Mesos, and resource-dynamic YARN support:**
+ support for both Mesos and YARN, including dynamic allocation and
+ release of resource for more resource elasticity (for both batch
+ and stream processing).
+
+* **Security:** encrypt both the messages exchanged between
+ TaskManagers and JobManager, as well as the connections for data
+ exchange between workers.
+
+* **More streaming connectors, more runtime metrics, and continuous
+ DataStream API enhancements:** add support for more sources and
+ sinks (e.g., Amazon Kinesis, Cassandra, Flume, etc), expose more
+ metrics to the user, and provide continuous improvements to the
+ DataStream API.
+
+If you are interested in these features, we highly encourage you to
+take a look at the [current
+draft](https://docs.google.com/document/d/1ExmtVpeVVT3TIhO1JoBpC5JKXm-778DAD7eqw5GANwE/edit),
+and [join the
+discussion](https://mail-archives.apache.org/mod_mbox/flink-dev/201512.mbox/browser)
+on the Flink mailing lists.
+
diff --git a/docs/content.tr/posts/2016-02-11-release-0.10.2.md b/docs/content.tr/posts/2016-02-11-release-0.10.2.md
new file mode 100644
index 0000000000..ef606bfad8
--- /dev/null
+++ b/docs/content.tr/posts/2016-02-11-release-0.10.2.md
@@ -0,0 +1,34 @@
+---
+date: "2016-02-11T08:00:00Z"
+title: Flink 0.10.2 Released
+aliases:
+- /news/2016/02/11/release-0.10.2.html
+---
+
+Today, the Flink community released Flink version **0.10.2**, the second bugfix release of the 0.10 series.
+
+We **recommend all users updating to this release** by bumping the version of your Flink dependencies to `0.10.2` and updating the binaries on the server.
+
+## Issues fixed
+
+* [FLINK-3242](https://issues.apache.org/jira/browse/FLINK-3242): Adjust StateBackendITCase for 0.10 signatures of state backends
+* [FLINK-3236](https://issues.apache.org/jira/browse/FLINK-3236): Flink user code classloader as parent classloader from Flink core classes
+* [FLINK-2962](https://issues.apache.org/jira/browse/FLINK-2962): Cluster startup script refers to unused variable
+* [FLINK-3151](https://issues.apache.org/jira/browse/FLINK-3151): Downgrade to Netty version 4.0.27.Final
+* [FLINK-3224](https://issues.apache.org/jira/browse/FLINK-3224): Call setInputType() on output formats that implement InputTypeConfigurable
+* [FLINK-3218](https://issues.apache.org/jira/browse/FLINK-3218): Fix overriding of user parameters when merging Hadoop configurations
+* [FLINK-3189](https://issues.apache.org/jira/browse/FLINK-3189): Fix argument parsing of CLI client INFO action
+* [FLINK-3176](https://issues.apache.org/jira/browse/FLINK-3176): Improve documentation for window apply
+* [FLINK-3185](https://issues.apache.org/jira/browse/FLINK-3185): Log error on failure during recovery
+* [FLINK-3185](https://issues.apache.org/jira/browse/FLINK-3185): Don't swallow test failure Exception
+* [FLINK-3147](https://issues.apache.org/jira/browse/FLINK-3147): Expose HadoopOutputFormatBase fields as protected
+* [FLINK-3145](https://issues.apache.org/jira/browse/FLINK-3145): Pin Kryo version of transitive dependencies
+* [FLINK-3143](https://issues.apache.org/jira/browse/FLINK-3143): Update Closure Cleaner's ASM references to ASM5
+* [FLINK-3136](https://issues.apache.org/jira/browse/FLINK-3136): Fix shaded imports in ClosureCleaner.scala
+* [FLINK-3108](https://issues.apache.org/jira/browse/FLINK-3108): JoinOperator's with() calls the wrong TypeExtractor method
+* [FLINK-3125](https://issues.apache.org/jira/browse/FLINK-3125): Web server starts also when JobManager log files cannot be accessed.
+* [FLINK-3080](https://issues.apache.org/jira/browse/FLINK-3080): Relax restrictions of DataStream.union()
+* [FLINK-3081](https://issues.apache.org/jira/browse/FLINK-3081): Properly stop periodic Kafka committer
+* [FLINK-3082](https://issues.apache.org/jira/browse/FLINK-3082): Fixed confusing error about an interface that no longer exists
+* [FLINK-3067](https://issues.apache.org/jira/browse/FLINK-3067): Enforce zkclient 0.7 for Kafka
+* [FLINK-3020](https://issues.apache.org/jira/browse/FLINK-3020): Set number of task slots to maximum parallelism in local execution
diff --git a/docs/content.tr/posts/2016-03-08-release-1.0.0.md b/docs/content.tr/posts/2016-03-08-release-1.0.0.md
new file mode 100644
index 0000000000..f598bc9d13
--- /dev/null
+++ b/docs/content.tr/posts/2016-03-08-release-1.0.0.md
@@ -0,0 +1,124 @@
+---
+date: "2016-03-08T13:00:00Z"
+title: Announcing Apache Flink 1.0.0
+aliases:
+- /news/2016/03/08/release-1.0.0.html
+---
+
+The Apache Flink community is pleased to announce the availability of the 1.0.0 release. The community put significant effort into improving and extending Apache Flink since the last release, focusing on improving the experience of writing and executing data stream processing pipelines in production.
+
+
+
+
+
+Flink version 1.0.0 marks the beginning of the 1.X.X series of releases, which will maintain backwards compatibility with 1.0.0. This means that applications written against stable APIs of Flink 1.0.0 will compile and run with all Flink versions in the 1. series. This is the first time we are formally guaranteeing compatibility in Flink's history, and we therefore see this release as a major milestone of the project, perhaps the most important since graduation as a top-level project.
+
+Apart from backwards compatibility, Flink 1.0.0 brings a variety of new user-facing features, as well as tons of bug fixes. About 64 contributors provided bug fixes, improvements, and new features such that in total more than 450 JIRA issues could be resolved.
+
+We encourage everyone to [download the release](http://flink.apache.org/downloads.html) and [check out the documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.0/). Feedback through the Flink [mailing lists](http://flink.apache.org/community.html#mailing-lists) is, as always, very welcome!
+
+## Interface stability annotations
+
+Flink 1.0.0 introduces interface stability annotations for API classes and methods. Interfaces defined as `@Public` are guaranteed to remain stable across all releases of the 1.x series. The `@PublicEvolving` annotation marks API features that may be subject to change in future versions.
+
+Flink's stability annotations will help users to implement applications that compile and execute unchanged against future versions of Flink 1.x. This greatly reduces the complexity for users when upgrading to a newer Flink release.
+
+## Out-of-core state support
+
+Flink 1.0.0 adds a new state backend that uses RocksDB to store state (both windows and user-defined key-value state). [RocksDB](http://rocksdb.org/) is an embedded key/value store database, originally developed by Facebook.
+When using this backend, active state in streaming programs can grow well beyond memory. The RocksDB files are stored in a distributed file system such as HDFS or S3 for backups.
+
+## Savepoints and version upgrades
+
+Savepoints are checkpoints of the state of a running streaming job that can be manually triggered by the user while the job is running. Savepoints solve several production headaches, including code upgrades (both application and framework), cluster maintenance and migration, A/B testing and what-if scenarios, as well as testing and debugging. Read more about savepoints at the [data Artisans blog](http://data-artisans.com/how-apache-flink-enables-new-streaming-applications/).
+
+## Library for Complex Event Processing (CEP)
+
+Complex Event Processing has been one of the oldest and more important use cases from stream processing. The new CEP functionality in Flink allows you to use a distributed general-purpose stream processor instead of a specialized CEP system to detect complex patterns in event streams. Get started with [CEP on Flink]({{< param DocsBaseUrl >}}flink-docs-master/apis/streaming/libs/cep.html).
+
+## Enhanced monitoring interface: job submission, checkpoint statistics and backpressure monitoring
+
+The web interface now allows users to submit jobs. Previous Flink releases had a separate service for submitting jobs. The new interface is part of the JobManager frontend. It also works on YARN now.
+
+Backpressure monitoring allows users to trigger a sampling mechanism which analyzes the time operators are waiting for new network buffers. When senders are spending most of their time for new network buffers, they are experiencing backpressure from their downstream operators. Many users requested this feature for understanding bottlenecks in both batch and streaming applications.
+
+## Improved checkpointing control and monitoring
+
+The checkpointing has been extended by a more fine-grained control mechanism: In previous versions, new checkpoints were triggered independent of the speed at which old checkpoints completed. This can lead to situations where new checkpoints are piling up, because they are triggered too frequently.
+
+The checkpoint coordinator now exposes statistics through our REST monitoring API and the web interface. Users can review the checkpoint size and duration on a per-operator basis and see the last completed checkpoints. This is helpful for identifying performance issues, such as processing slowdown by the checkpoints.
+
+## Improved Kafka connector and support for Kafka 0.9
+
+Flink 1.0 supports both Kafka 0.8 and 0.9. With the new release, Flink exposes Kafka metrics for the producers and the 0.9 consumer through Flink’s accumulator system. We also enhanced the existing connector for Kafka 0.8, allowing users to subscribe to multiple topics in one source.
+
+## Changelog and known issues
+
+This release resolves more than 450 issues, including bug fixes, improvements, and new features. See the [complete changelog](/blog/release_1.0.0-changelog_known_issues.html#changelog) and [known issues](/blog/release_1.0.0-changelog_known_issues.html#known-issues).
+
+## List of contributors
+
+- Abhishek Agarwal
+- Ajay Bhat
+- Aljoscha Krettek
+- Andra Lungu
+- Andrea Sella
+- Chesnay Schepler
+- Chiwan Park
+- Daniel Pape
+- Fabian Hueske
+- Filipe Correia
+- Frederick F. Kautz IV
+- Gabor Gevay
+- Gabor Horvath
+- Georgios Andrianakis
+- Greg Hogan
+- Gyula Fora
+- Henry Saputra
+- Hilmi Yildirim
+- Hubert Czerpak
+- Jark Wu
+- Johannes
+- Jun Aoki
+- Jun Aoki
+- Kostas Kloudas
+- Li Chengxiang
+- Lun Gao
+- Martin Junghanns
+- Martin Liesenberg
+- Matthias J. Sax
+- Maximilian Michels
+- Márton Balassi
+- Nick Dimiduk
+- Niels Basjes
+- Omer Katz
+- Paris Carbone
+- Patrice Freydiere
+- Peter Vandenabeele
+- Piotr Godek
+- Prez Cannady
+- Robert Metzger
+- Romeo Kienzler
+- Sachin Goel
+- Saumitra Shahapure
+- Sebastian Klemke
+- Stefano Baghino
+- Stephan Ewen
+- Stephen Samuel
+- Subhobrata Dey
+- Suneel Marthi
+- Ted Yu
+- Theodore Vasiloudis
+- Till Rohrmann
+- Timo Walther
+- Trevor Grant
+- Ufuk Celebi
+- Ulf Karlsson
+- Vasia Kalavri
+- fversaci
+- madhukar
+- qingmeng.wyh
+- ramkrishna
+- rtudoran
+- sahitya-pavurala
+- zhangminglei
diff --git a/docs/content.tr/posts/2016-04-06-cep-monitoring.md b/docs/content.tr/posts/2016-04-06-cep-monitoring.md
new file mode 100644
index 0000000000..cc9eb7175a
--- /dev/null
+++ b/docs/content.tr/posts/2016-04-06-cep-monitoring.md
@@ -0,0 +1,218 @@
+---
+author: Till Rohrmann
+author-twitter: stsffap
+date: "2016-04-06T10:00:00Z"
+excerpt: In this blog post, we introduce Flink's new CEP
+ library that allows you to do pattern matching on event streams. Through the
+ example of monitoring a data center and generating alerts, we showcase the library's
+ ease of use and its intuitive Pattern API.
+title: Introducing Complex Event Processing (CEP) with Apache Flink
+aliases:
+- /news/2016/04/06/cep-monitoring.html
+---
+
+With the ubiquity of sensor networks and smart devices continuously collecting more and more data, we face the challenge to analyze an ever growing stream of data in near real-time.
+Being able to react quickly to changing trends or to deliver up to date business intelligence can be a decisive factor for a company’s success or failure.
+A key problem in real time processing is the detection of event patterns in data streams.
+
+Complex event processing (CEP) addresses exactly this problem of matching continuously incoming events against a pattern.
+The result of a matching are usually complex events which are derived from the input events.
+In contrast to traditional DBMSs where a query is executed on stored data, CEP executes data on a stored query.
+All data which is not relevant for the query can be immediately discarded.
+The advantages of this approach are obvious, given that CEP queries are applied on a potentially infinite stream of data.
+Furthermore, inputs are processed immediately.
+Once the system has seen all events for a matching sequence, results are emitted straight away.
+This aspect effectively leads to CEP’s real time analytics capability.
+
+Consequently, CEP’s processing paradigm drew significant interest and found application in a wide variety of use cases.
+Most notably, CEP is used nowadays for financial applications such as stock market trend and credit card fraud detection.
+Moreover, it is used in RFID-based tracking and monitoring, for example, to detect thefts in a warehouse where items are not properly checked out.
+CEP can also be used to detect network intrusion by specifying patterns of suspicious user behaviour.
+
+Apache Flink with its true streaming nature and its capabilities for low latency as well as high throughput stream processing is a natural fit for CEP workloads.
+Consequently, the Flink community has introduced the first version of a new [CEP library]({{< param DocsBaseUrl >}}flink-docs-master/apis/streaming/libs/cep.html) with [Flink 1.0](http://flink.apache.org/news/2016/03/08/release-1.0.0.html).
+In the remainder of this blog post, we introduce Flink’s CEP library and we illustrate its ease of use through the example of monitoring a data center.
+
+## Monitoring and alert generation for data centers
+
+
+
+
+
+Assume we have a data center with a number of racks.
+For each rack the power consumption and the temperature are monitored.
+Whenever such a measurement takes place, a new power or temperature event is generated, respectively.
+Based on this monitoring event stream, we want to detect racks that are about to overheat, and dynamically adapt their workload and cooling.
+
+For this scenario we use a two staged approach.
+First, we monitor the temperature events.
+Whenever we see two consecutive events whose temperature exceeds a threshold value, we generate a temperature warning with the current average temperature.
+A temperature warning does not necessarily indicate that a rack is about to overheat.
+But whenever we see two consecutive warnings with increasing temperatures, then we want to issue an alert for this rack.
+This alert can then lead to countermeasures to cool the rack.
+
+### Implementation with Apache Flink
+
+First, we define the messages of the incoming monitoring event stream.
+Every monitoring message contains its originating rack ID.
+The temperature event additionally contains the current temperature and the power consumption event contains the current voltage.
+We model the events as POJOs:
+
+```java
+public abstract class MonitoringEvent {
+ private int rackID;
+ ...
+}
+
+public class TemperatureEvent extends MonitoringEvent {
+ private double temperature;
+ ...
+}
+
+public class PowerEvent extends MonitoringEvent {
+ private double voltage;
+ ...
+}
+```
+
+Now we can ingest the monitoring event stream using one of Flink’s connectors (e.g. Kafka, RabbitMQ, etc.).
+This will give us a `DataStream inputEventStream` which we will use as the input for Flink’s CEP operator.
+But first, we have to define the event pattern to detect temperature warnings.
+The CEP library offers an intuitive [Pattern API]({{< param DocsBaseUrl >}}flink-docs-master/apis/streaming/libs/cep.html#the-pattern-api) to easily define these complex patterns.
+
+Every pattern consists of a sequence of events which can have optional filter conditions assigned.
+A pattern always starts with a first event to which we will assign the name `“First Event”`.
+
+```java
+Pattern.begin("First Event");
+```
+
+This pattern will match every monitoring event.
+Since we are only interested in `TemperatureEvents` whose temperature is above a threshold value, we have to add an additional subtype constraint and a where clause:
+
+```java
+Pattern.begin("First Event")
+ .subtype(TemperatureEvent.class)
+ .where(evt -> evt.getTemperature() >= TEMPERATURE_THRESHOLD);
+```
+
+As stated before, we want to generate a `TemperatureWarning` if and only if we see two consecutive `TemperatureEvents` for the same rack whose temperatures are too high.
+The Pattern API offers the `next` call which allows us to add a new event to our pattern.
+This event has to follow directly the first matching event in order for the whole pattern to match.
+
+```java
+Pattern warningPattern = Pattern.begin("First Event")
+ .subtype(TemperatureEvent.class)
+ .where(evt -> evt.getTemperature() >= TEMPERATURE_THRESHOLD)
+ .next("Second Event")
+ .subtype(TemperatureEvent.class)
+ .where(evt -> evt.getTemperature() >= TEMPERATURE_THRESHOLD)
+ .within(Time.seconds(10));
+```
+
+The final pattern definition also contains the `within` API call which defines that two consecutive `TemperatureEvents` have to occur within a time interval of 10 seconds for the pattern to match.
+Depending on the time characteristic setting, this can either be processing, ingestion or event time.
+
+Having defined the event pattern, we can now apply it on the `inputEventStream`.
+
+```java
+PatternStream tempPatternStream = CEP.pattern(
+ inputEventStream.keyBy("rackID"),
+ warningPattern);
+```
+
+Since we want to generate our warnings for each rack individually, we `keyBy` the input event stream by the `“rackID”` POJO field.
+This enforces that matching events of our pattern will all have the same rack ID.
+
+The `PatternStream` gives us access to successfully matched event sequences.
+They can be accessed using the `select` API call.
+The `select` API call takes a `PatternSelectFunction` which is called for every matching event sequence.
+The event sequence is provided as a `Map` where each `MonitoringEvent` is identified by its assigned event name.
+Our pattern select function generates for each matching pattern a `TemperatureWarning` event.
+
+```java
+public class TemperatureWarning {
+ private int rackID;
+ private double averageTemperature;
+ ...
+}
+
+DataStream warnings = tempPatternStream.select(
+ (Map pattern) -> {
+ TemperatureEvent first = (TemperatureEvent) pattern.get("First Event");
+ TemperatureEvent second = (TemperatureEvent) pattern.get("Second Event");
+
+ return new TemperatureWarning(
+ first.getRackID(),
+ (first.getTemperature() + second.getTemperature()) / 2);
+ }
+);
+```
+
+Now we have generated a new complex event stream `DataStream warnings` from the initial monitoring event stream.
+This complex event stream can again be used as the input for another round of complex event processing.
+We use the `TemperatureWarnings` to generate `TemperatureAlerts` whenever we see two consecutive `TemperatureWarnings` for the same rack with increasing temperatures.
+The `TemperatureAlerts` have the following definition:
+
+```java
+public class TemperatureAlert {
+ private int rackID;
+ ...
+}
+```
+
+At first, we have to define our alert event pattern:
+
+```java
+Pattern alertPattern = Pattern.begin("First Event")
+ .next("Second Event")
+ .within(Time.seconds(20));
+```
+
+This definition says that we want to see two `TemperatureWarnings` within 20 seconds.
+The first event has the name `“First Event”` and the second consecutive event has the name `“Second Event”`.
+The individual events don’t have a where clause assigned, because we need access to both events in order to decide whether the temperature is increasing.
+Therefore, we apply the filter condition in the select clause.
+But first, we obtain again a `PatternStream`.
+
+```java
+PatternStream alertPatternStream = CEP.pattern(
+ warnings.keyBy("rackID"),
+ alertPattern);
+```
+
+Again, we `keyBy` the warnings input stream by the `"rackID"` so that we generate our alerts for each rack individually.
+Next we apply the `flatSelect` method which will give us access to matching event sequences and allows us to output an arbitrary number of complex events.
+Thus, we will only generate a `TemperatureAlert` if and only if the temperature is increasing.
+
+```java
+DataStream alerts = alertPatternStream.flatSelect(
+ (Map pattern, Collector out) -> {
+ TemperatureWarning first = pattern.get("First Event");
+ TemperatureWarning second = pattern.get("Second Event");
+
+ if (first.getAverageTemperature() < second.getAverageTemperature()) {
+ out.collect(new TemperatureAlert(first.getRackID()));
+ }
+ });
+```
+
+The `DataStream alerts` is the data stream of temperature alerts for each rack.
+Based on these alerts we can now adapt the workload or cooling for overheating racks.
+
+The full source code for the presented example as well as an example data source which generates randomly monitoring events can be found in [this repository](https://github.com/tillrohrmann/cep-monitoring).
+
+## Conclusion
+
+In this blog post we have seen how easy it is to reason about event streams using Flink’s CEP library.
+Using the example of monitoring and alert generation for a data center, we have implemented a short program which notifies us when a rack is about to overheat and potentially to fail.
+
+In the future, the Flink community will further extend the CEP library’s functionality and expressiveness.
+Next on the road map is support for a regular expression-like pattern specification, including Kleene star, lower and upper bounds, and negation.
+Furthermore, it is planned to allow the where-clause to access fields of previously matched events.
+This feature will allow to prune unpromising event sequences early.
+
+
+
+*Note:* The example code requires Flink 1.0.1 or higher.
+
diff --git a/docs/content.tr/posts/2016-04-06-release-1.0.1.md b/docs/content.tr/posts/2016-04-06-release-1.0.1.md
new file mode 100644
index 0000000000..5421b89758
--- /dev/null
+++ b/docs/content.tr/posts/2016-04-06-release-1.0.1.md
@@ -0,0 +1,70 @@
+---
+date: "2016-04-06T08:00:00Z"
+title: Flink 1.0.1 Released
+aliases:
+- /news/2016/04/06/release-1.0.1.html
+---
+
+Today, the Flink community released Flink version **1.0.1**, the first bugfix release of the 1.0 series.
+
+We **recommend all users updating to this release** by bumping the version of your Flink dependencies to `1.0.1` and updating the binaries on the server. You can find the binaries on the updated [Downloads page](/downloads.html).
+
+## Fixed Issues
+
+Bug
+
+[FLINK-3179 ] - Combiner is not injected if Reduce or GroupReduce input is explicitly partitioned
+
+[FLINK-3472 ] - JDBCInputFormat.nextRecord(..) has misleading message on NPE
+
+[FLINK-3491 ] - HDFSCopyUtilitiesTest fails on Windows
+
+[FLINK-3495 ] - RocksDB Tests can't run on Windows
+
+[FLINK-3533 ] - Update the Gelly docs wrt examples and cluster execution
+
+[FLINK-3563 ] - .returns() doesn't compile when using .map() with a custom MapFunction
+
+[FLINK-3566 ] - Input type validation often fails on custom TypeInfo implementations
+
+[FLINK-3578 ] - Scala DataStream API does not support Rich Window Functions
+
+[FLINK-3595 ] - Kafka09 consumer thread does not interrupt when stuck in record emission
+
+[FLINK-3602 ] - Recursive Types are not supported / crash TypeExtractor
+
+[FLINK-3621 ] - Misleading documentation of memory configuration parameters
+
+[FLINK-3629 ] - In wikiedits Quick Start example, "The first call, .window()" should be "The first call, .timeWindow()"
+
+[FLINK-3651 ] - Fix faulty RollingSink Restore
+
+[FLINK-3653 ] - recovery.zookeeper.storageDir is not documented on the configuration page
+
+[FLINK-3663 ] - FlinkKafkaConsumerBase.logPartitionInfo is missing a log marker
+
+[FLINK-3681 ] - CEP library does not support Java 8 lambdas as select function
+
+[FLINK-3682 ] - CEP operator does not set the processing timestamp correctly
+
+[FLINK-3684 ] - CEP operator does not forward watermarks properly
+
+
+
+Improvement
+
+[FLINK-3570 ] - Replace random NIC selection heuristic by InetAddress.getLocalHost
+
+[FLINK-3575 ] - Update Working With State Section in Doc
+
+[FLINK-3591 ] - Replace Quickstart K-Means Example by Streaming Example
+
+
+
+Test
+
+[FLINK-2444 ] - Add tests for HadoopInputFormats
+
+[FLINK-2445 ] - Add tests for HadoopOutputFormats
+
+
diff --git a/docs/content.tr/posts/2016-04-14-flink-forward-announce.md b/docs/content.tr/posts/2016-04-14-flink-forward-announce.md
new file mode 100644
index 0000000000..a3c9773162
--- /dev/null
+++ b/docs/content.tr/posts/2016-04-14-flink-forward-announce.md
@@ -0,0 +1,14 @@
+---
+author: Aljoscha Krettek
+author-twitter: aljoscha
+date: "2016-04-14T10:00:00Z"
+title: Flink Forward 2016 Call for Submissions Is Now Open
+aliases:
+- /news/2016/04/14/flink-forward-announce.html
+---
+
+We are happy to announce that the call for submissions for Flink Forward 2016 is now open! The conference will take place September 12-14, 2016 in Berlin, Germany, bringing together the open source stream processing community. Most Apache Flink committers will attend the conference, making it the ideal venue to learn more about the project and its roadmap and connect with the community.
+
+The conference welcomes submissions on everything Flink-related, including experiences with using Flink, products based on Flink, technical talks on extending Flink, as well as connecting Flink with other open source or proprietary software.
+
+Read more [here](http://flink-forward.org/).
\ No newline at end of file
diff --git a/docs/content.tr/posts/2016-04-22-release-1.0.2.md b/docs/content.tr/posts/2016-04-22-release-1.0.2.md
new file mode 100644
index 0000000000..6268b24704
--- /dev/null
+++ b/docs/content.tr/posts/2016-04-22-release-1.0.2.md
@@ -0,0 +1,37 @@
+---
+date: "2016-04-22T08:00:00Z"
+title: Flink 1.0.2 Released
+aliases:
+- /news/2016/04/22/release-1.0.2.html
+---
+
+Today, the Flink community released Flink version **1.0.2**, the second bugfix release of the 1.0 series.
+
+We **recommend all users updating to this release** by bumping the version of your Flink dependencies to `1.0.2` and updating the binaries on the server. You can find the binaries on the updated [Downloads page](/downloads.html).
+
+## Fixed Issues
+
+### Bug
+
+* [[FLINK-3657](https://issues.apache.org/jira/browse/FLINK-3657)] [dataSet] Change access of DataSetUtils.countElements() to 'public'
+* [[FLINK-3762](https://issues.apache.org/jira/browse/FLINK-3762)] [core] Enable Kryo reference tracking
+* [[FLINK-3732](https://issues.apache.org/jira/browse/FLINK-3732)] [core] Fix potential null deference in ExecutionConfig#equals()
+* [[FLINK-3760](https://issues.apache.org/jira/browse/FLINK-3760)] Fix StateDescriptor.readObject
+* [[FLINK-3730](https://issues.apache.org/jira/browse/FLINK-3730)] Fix RocksDB Local Directory Initialization
+* [[FLINK-3712](https://issues.apache.org/jira/browse/FLINK-3712)] Make all dynamic properties available to the CLI frontend
+* [[FLINK-3688](https://issues.apache.org/jira/browse/FLINK-3688)] WindowOperator.trigger() does not emit Watermark anymore
+* [[FLINK-3697](https://issues.apache.org/jira/browse/FLINK-3697)] Properly access type information for nested POJO key selection
+
+### Improvement
+
+- [[FLINK-3654](https://issues.apache.org/jira/browse/FLINK-3654)] Disable Write-Ahead-Log in RocksDB State
+
+### Docs
+- [[FLINK-2544](https://issues.apache.org/jira/browse/FLINK-2544)] [docs] Add Java 8 version for building PowerMock tests to docs
+- [[FLINK-3469](https://issues.apache.org/jira/browse/FLINK-3469)] [docs] Improve documentation for grouping keys
+- [[FLINK-3634](https://issues.apache.org/jira/browse/FLINK-3634)] [docs] Fix documentation for DataSetUtils.zipWithUniqueId()
+- [[FLINK-3711](https://issues.apache.org/jira/browse/FLINK-3711)][docs] Documentation of Scala fold()() uses correct syntax
+
+### Tests
+
+- [[FLINK-3716](https://issues.apache.org/jira/browse/FLINK-3716)] [kafka consumer] Decreasing socket timeout so testFailOnNoBroker() will pass before JUnit timeout
diff --git a/docs/content.tr/posts/2016-05-11-release-1.0.3.md b/docs/content.tr/posts/2016-05-11-release-1.0.3.md
new file mode 100644
index 0000000000..dc04a6edad
--- /dev/null
+++ b/docs/content.tr/posts/2016-05-11-release-1.0.3.md
@@ -0,0 +1,35 @@
+---
+date: "2016-05-11T08:00:00Z"
+title: Flink 1.0.3 Released
+aliases:
+- /news/2016/05/11/release-1.0.3.html
+---
+
+Today, the Flink community released Flink version **1.0.3**, the third bugfix release of the 1.0 series.
+
+We **recommend all users updating to this release** by bumping the version of your Flink dependencies to `1.0.3` and updating the binaries on the server. You can find the binaries on the updated [Downloads page](/downloads.html).
+
+## Fixed Issues
+
+### Bug
+
+* [[FLINK-3790](https://issues.apache.org/jira/browse/FLINK-3790)] [streaming] Use proper hadoop config in rolling sink
+* [[FLINK-3840](https://issues.apache.org/jira/browse/FLINK-3840)] Remove Testing Files in RocksDB Backend
+* [[FLINK-3835](https://issues.apache.org/jira/browse/FLINK-3835)] [optimizer] Add input id to JSON plan to resolve ambiguous input names
+* [hotfix] OptionSerializer.duplicate to respect stateful element serializer
+* [[FLINK-3803](https://issues.apache.org/jira/browse/FLINK-3803)] [runtime] Pass CheckpointStatsTracker to ExecutionGraph
+* [hotfix] [cep] Make cep window border treatment consistent
+
+### Improvement
+
+* [[FLINK-3678](https://issues.apache.org/jira/browse/FLINK-3678)] [dist, docs] Make Flink logs directory configurable
+
+### Docs
+
+* [docs] Add note about S3AFileSystem 'buffer.dir' property
+* [docs] Update AWS S3 docs
+
+### Tests
+
+* [[FLINK-3860](https://issues.apache.org/jira/browse/FLINK-3860)] [connector-wikiedits] Add retry loop to WikipediaEditsSourceTest
+* [streaming-contrib] Fix port clash in DbStateBackend tests
diff --git a/docs/content.tr/posts/2016-05-24-stream-sql.md b/docs/content.tr/posts/2016-05-24-stream-sql.md
new file mode 100644
index 0000000000..3e5839f57f
--- /dev/null
+++ b/docs/content.tr/posts/2016-05-24-stream-sql.md
@@ -0,0 +1,141 @@
+---
+author: Fabian Hueske
+author-twitter: fhueske
+date: "2016-05-24T10:00:00Z"
+excerpt: |-
+ About six months ago, the Apache Flink community started an effort to add a SQL interface for stream data analysis. SQL is the standard language to access and process data. Everybody who occasionally analyzes data is familiar with SQL. Consequently, a SQL interface for stream data processing will make this technology accessible to a much wider audience. Moreover, SQL support for streaming data will also enable new use cases such as interactive and ad-hoc stream analysis and significantly simplify many applications including stream ingestion and simple transformations.
+ In this blog post, we report on the current status, architectural design, and future plans of the Apache Flink community to implement support for SQL as a language for analyzing data streams.
+title: Stream Processing for Everyone with SQL and Apache Flink
+aliases:
+- /news/2016/05/24/stream-sql.html
+---
+
+The capabilities of open source systems for distributed stream processing have evolved significantly over the last years. Initially, the first systems in the field (notably [Apache Storm](https://storm.apache.org)) provided low latency processing, but were limited to at-least-once guarantees, processing-time semantics, and rather low-level APIs. Since then, several new systems emerged and pushed the state of the art of open source stream processing in several dimensions. Today, users of Apache Flink or [Apache Beam](https://beam.incubator.apache.org) can use fluent Scala and Java APIs to implement stream processing jobs that operate in event-time with exactly-once semantics at high throughput and low latency.
+
+In the meantime, stream processing has taken off in the industry. We are witnessing a rapidly growing interest in stream processing which is reflected by prevalent deployments of streaming processing infrastructure such as [Apache Kafka](https://kafka.apache.org) and Apache Flink. The increasing number of available data streams results in a demand for people that can analyze streaming data and turn it into real-time insights. However, stream data analysis requires a special skill set including knowledge of streaming concepts such as the characteristics of unbounded streams, windows, time, and state as well as the skills to implement stream analysis jobs usually against Java or Scala APIs. People with this skill set are rare and hard to find.
+
+About six months ago, the Apache Flink community started an effort to add a SQL interface for stream data analysis. SQL is *the* standard language to access and process data. Everybody who occasionally analyzes data is familiar with SQL. Consequently, a SQL interface for stream data processing will make this technology accessible to a much wider audience. Moreover, SQL support for streaming data will also enable new use cases such as interactive and ad-hoc stream analysis and significantly simplify many applications including stream ingestion and simple transformations. In this blog post, we report on the current status, architectural design, and future plans of the Apache Flink community to implement support for SQL as a language for analyzing data streams.
+
+## Where did we come from?
+
+With the [0.9.0-milestone1](http://flink.apache.org/news/2015/04/13/release-0.9.0-milestone1.html) release, Apache Flink added an API to process relational data with SQL-like expressions called the Table API. The central concept of this API is a Table, a structured data set or stream on which relational operations can be applied. The Table API is tightly integrated with the DataSet and DataStream API. A Table can be easily created from a DataSet or DataStream and can also be converted back into a DataSet or DataStream as the following example shows
+
+```scala
+val execEnv = ExecutionEnvironment.getExecutionEnvironment
+val tableEnv = TableEnvironment.getTableEnvironment(execEnv)
+
+// obtain a DataSet from somewhere
+val tempData: DataSet[(String, Long, Double)] =
+
+// convert the DataSet to a Table
+val tempTable: Table = tempData.toTable(tableEnv, 'location, 'time, 'tempF)
+// compute your result
+val avgTempCTable: Table = tempTable
+ .where('location.like("room%"))
+ .select(
+ ('time / (3600 * 24)) as 'day,
+ 'Location as 'room,
+ (('tempF - 32) * 0.556) as 'tempC
+ )
+ .groupBy('day, 'room)
+ .select('day, 'room, 'tempC.avg as 'avgTempC)
+// convert result Table back into a DataSet and print it
+avgTempCTable.toDataSet[Row].print()
+```
+
+Although the example shows Scala code, there is also an equivalent Java version of the Table API. The following picture depicts the original architecture of the Table API.
+
+
+
+
+
+A Table is created from a DataSet or DataStream and transformed into a new Table by applying relational transformations such as `filter`, `join`, or `select` on them. Internally, a logical table operator tree is constructed from the applied Table transformations. When a Table is translated back into a DataSet or DataStream, the respective translator translates the logical operator tree into DataSet or DataStream operators. Expressions like `'location.like("room%")` are compiled into Flink functions via code generation.
+
+However, the original Table API had a few limitations. First of all, it could not stand alone. Table API queries had to be always embedded into a DataSet or DataStream program. Queries against batch Tables did not support outer joins, sorting, and many scalar functions which are commonly used in SQL queries. Queries against streaming tables only supported filters, union, and projections and no aggregations or joins. Also, the translation process did not leverage query optimization techniques except for the physical optimization that is applied to all DataSet programs.
+
+## Table API joining forces with SQL
+
+The discussion about adding support for SQL came up a few times in the Flink community. With Flink 0.9 and the availability of the Table API, code generation for relational expressions, and runtime operators, the foundation for such an extension seemed to be there and SQL support the next logical step. On the other hand, the community was also well aware of the multitude of dedicated "SQL-on-Hadoop" solutions in the open source landscape ([Apache Hive](https://hive.apache.org), [Apache Drill](https://drill.apache.org), [Apache Impala](http://impala.io), [Apache Tajo](https://tajo.apache.org), just to name a few). Given these alternatives, we figured that time would be better spent improving Flink in other ways than implementing yet another SQL-on-Hadoop solution.
+
+However, with the growing popularity of stream processing and the increasing adoption of Flink in this area, the Flink community saw the need for a simpler API to enable more users to analyze streaming data. About half a year ago, we decided to take the Table API to the next level, extend the stream processing capabilities of the Table API, and add support for SQL on streaming data. What we came up with was a revised architecture for a Table API that supports SQL (and Table API) queries on streaming and static data sources. We did not want to reinvent the wheel and decided to build the new Table API on top of [Apache Calcite](https://calcite.apache.org), a popular SQL parser and optimizer framework. Apache Calcite is used by many projects including Apache Hive, Apache Drill, Cascading, and many [more](https://calcite.apache.org/docs/powered_by.html). Moreover, the Calcite community put [SQL on streams](https://calcite.apache.org/docs/stream.html) on their roadmap which makes it a perfect fit for Flink's SQL interface.
+
+Calcite is central in the new design as the following architecture sketch shows:
+
+
+
+
+
+The new architecture features two integrated APIs to specify relational queries, the Table API and SQL. Queries of both APIs are validated against a catalog of registered tables and converted into Calcite's representation for logical plans. In this representation, stream and batch queries look exactly the same. Next, Calcite's cost-based optimizer applies transformation rules and optimizes the logical plans. Depending on the nature of the sources (streaming or static) we use different rule sets. Finally, the optimized plan is translated into a regular Flink DataStream or DataSet program. This step involves again code generation to compile relational expressions into Flink functions.
+
+The new architecture of the Table API maintains the basic principles of the original Table API and improves it. It keeps a uniform interface for relational queries on streaming and static data. In addition, we take advantage of Calcite's query optimization framework and SQL parser. The design builds upon Flink's established APIs, i.e., the DataStream API that offers low-latency, high-throughput stream processing with exactly-once semantics and consistent results due to event-time processing, and the DataSet API with robust and efficient in-memory operators and pipelined data exchange. Any improvements to Flink's core APIs and engine will automatically improve the execution of Table API and SQL queries.
+
+With this effort, we are adding SQL support for both streaming and static data to Flink. However, we do not want to see this as a competing solution to dedicated, high-performance SQL-on-Hadoop solutions, such as Impala, Drill, and Hive. Instead, we see the sweet spot of Flink's SQL integration primarily in providing access to streaming analytics to a wider audience. In addition, it will facilitate integrated applications that use Flink's API's as well as SQL while being executed on a single runtime engine.
+
+## How will Flink's SQL on streams look like?
+
+So far we discussed the motivation for and architecture of Flink's stream SQL interface, but how will it actually look like? The new SQL interface is integrated into the Table API. DataStreams, DataSets, and external data sources can be registered as tables at the `TableEnvironment` in order to make them queryable with SQL. The `TableEnvironment.sql()` method states a SQL query and returns its result as a Table. The following example shows a complete program that reads a streaming table from a JSON encoded Kafka topic, processes it with a SQL query and writes the resulting stream into another Kafka topic. Please note that the KafkaJsonSource and KafkaJsonSink are under development and not available yet. In the future, TableSources and TableSinks can be persisted to and loaded from files to ease reuse of source and sink definitions and to reduce boilerplate code.
+
+```scala
+// get environments
+val execEnv = StreamExecutionEnvironment.getExecutionEnvironment
+val tableEnv = TableEnvironment.getTableEnvironment(execEnv)
+
+// configure Kafka connection
+val kafkaProps = ...
+// define a JSON encoded Kafka topic as external table
+val sensorSource = new KafkaJsonSource[(String, Long, Double)](
+ "sensorTopic",
+ kafkaProps,
+ ("location", "time", "tempF"))
+
+// register external table
+tableEnv.registerTableSource("sensorData", sensorSource)
+
+// define query in external table
+val roomSensors: Table = tableEnv.sql(
+ "SELECT STREAM time, location AS room, (tempF - 32) * 0.556 AS tempC " +
+ "FROM sensorData " +
+ "WHERE location LIKE 'room%'"
+ )
+
+// define a JSON encoded Kafka topic as external sink
+val roomSensorSink = new KafkaJsonSink(...)
+
+// define sink for room sensor data and execute query
+roomSensors.toSink(roomSensorSink)
+execEnv.execute()
+```
+
+You might have noticed that this example left out the most interesting aspects of stream data processing: window aggregates and joins. How will these operations be expressed in SQL? Well, that is a very good question. The Apache Calcite community put out an excellent proposal that discusses the syntax and semantics of [SQL on streams](https://calcite.apache.org/docs/stream.html). It describes Calcite’s stream SQL as *"an extension to standard SQL, not another ‘SQL-like’ language"*. This has several benefits. First, people who are familiar with standard SQL will be able to analyze data streams without learning a new syntax. Queries on static tables and streams are (almost) identical and can be easily ported. Moreover it is possible to specify queries that reference static and streaming tables at the same time which goes well together with Flink’s vision to handle batch processing as a special case of stream processing, i.e., as processing finite streams. Finally, using standard SQL for stream data analysis means following a well established standard that is supported by many tools.
+
+Although we haven’t completely fleshed out the details of how windows will be defined in Flink’s SQL syntax and Table API, the following examples show how a tumbling window query could look like in SQL and the Table API.
+
+### SQL (following the syntax proposal of Calcite’s streaming SQL document)
+
+```sql
+SELECT STREAM
+ TUMBLE_END(time, INTERVAL '1' DAY) AS day,
+ location AS room,
+ AVG((tempF - 32) * 0.556) AS avgTempC
+FROM sensorData
+WHERE location LIKE 'room%'
+GROUP BY TUMBLE(time, INTERVAL '1' DAY), location
+```
+
+### Table API
+
+```scala
+val avgRoomTemp: Table = tableEnv.ingest("sensorData")
+ .where('location.like("room%"))
+ .partitionBy('location)
+ .window(Tumbling every Days(1) on 'time as 'w)
+ .select('w.end, 'location, , (('tempF - 32) * 0.556).avg as 'avgTempCs)
+```
+
+## What's up next?
+
+The Flink community is actively working on SQL support for the next minor version Flink 1.1.0. In the first version, SQL (and Table API) queries on streams will be limited to selection, filter, and union operators. Compared to Flink 1.0.0, the revised Table API will support many more scalar functions and be able to read tables from external sources and write them back to external sinks. A lot of work went into reworking the architecture of the Table API and integrating Apache Calcite.
+
+In Flink 1.2.0, the feature set of SQL on streams will be significantly extended. Among other things, we plan to support different types of window aggregates and maybe also streaming joins. For this effort, we want to closely collaborate with the Apache Calcite community and help extending Calcite's support for relational operations on streaming data when necessary.
+
+If this post made you curious and you want to try out Flink’s SQL interface and the new Table API, we encourage you to do so! Simply clone the SNAPSHOT [master branch](https://github.com/apache/flink/tree/master) and check out the [Table API documentation for the SNAPSHOT version]({{< param DocsBaseUrl >}}flink-docs-master/apis/table.html). Please note that the branch is under heavy development, and hence some code examples in this blog post might not work. We are looking forward to your feedback and welcome contributions.
\ No newline at end of file
diff --git a/docs/content.tr/posts/2016-08-04-release-1.1.0.md b/docs/content.tr/posts/2016-08-04-release-1.1.0.md
new file mode 100644
index 0000000000..eb85d73414
--- /dev/null
+++ b/docs/content.tr/posts/2016-08-04-release-1.1.0.md
@@ -0,0 +1,235 @@
+---
+date: "2016-08-04T13:00:00Z"
+title: Announcing Apache Flink 1.1.0
+aliases:
+- /news/2016/08/08/release-1.1.0.html
+---
+
+Important : The Maven artifacts published with version 1.1.0 on Maven central have a Hadoop dependency issue. It is highly recommended to use 1.1.1 or 1.1.1-hadoop1 as the Flink version.
+
+The Apache Flink community is pleased to announce the availability of Flink 1.1.0.
+
+This release is the first major release in the 1.X.X series of releases, which maintains API compatibility with 1.0.0. This means that your applications written against stable APIs of Flink 1.0.0 will compile and run with Flink 1.1.0. 95 contributors provided bug fixes, improvements, and new features such that in total more than 450 JIRA issues could be resolved. See the [complete changelog](/blog/release_1.1.0-changelog.html) for more details.
+
+**We encourage everyone to [download the release](http://flink.apache.org/downloads.html) and [check out the documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.1/). Feedback through the Flink [mailing lists](http://flink.apache.org/community.html#mailing-lists) is, as always, very welcome!**
+
+Some highlights of the release are listed in the following sections.
+
+## Connectors
+
+The [streaming connectors]({{< param DocsBaseUrl >}}flink-docs-release-1.1/apis/streaming/connectors/index.html) are a major part of Flink's DataStream API. This release adds support for new external systems and further improves on the available connectors.
+
+### Continuous File System Sources
+
+A frequently requested feature for Flink 1.0 was to be able to monitor directories and process files continuously. Flink 1.1 now adds support for this via `FileProcessingMode`s:
+
+```java
+DataStream stream = env.readFile(
+ textInputFormat,
+ "hdfs:///file-path",
+ FileProcessingMode.PROCESS_CONTINUOUSLY,
+ 5000, // monitoring interval (millis)
+ FilePathFilter.createDefaultFilter()); // file path filter
+```
+
+This will monitor `hdfs:///file-path` every `5000` milliseconds. Check out the [DataSource documentation for more details]({{< param DocsBaseUrl >}}flink-docs-release-1.1/apis/streaming/index.html#data-sources).
+
+### Kinesis Source and Sink
+
+Flink 1.1 adds a Kinesis connector for both consuming (`FlinkKinesisConsumer`) from and producing (`FlinkKinesisProduer`) to [Amazon Kinesis Streams](https://aws.amazon.com/kinesis/), which is a managed service purpose-built to make it easy to work with streaming data on AWS.
+
+```java
+DataStream kinesis = env.addSource(
+ new FlinkKinesisConsumer<>("stream-name", schema, config));
+```
+
+Check out the [Kinesis connector documentation for more details]({{< param DocsBaseUrl >}}flink-docs-release-1.1/apis/streaming/connectors/kinesis.html).
+
+### Cassandra Sink
+
+The [Apache Cassandra](http://wiki.apache.org/cassandra/GettingStarted) sink allows you to write from Flink to Cassandra. Flink can provide exactly-once guarantees if the query is idempotent, meaning it can be applied multiple times without changing the result.
+
+```java
+CassandraSink.addSink(input)
+```
+
+Check out the [Cassandra Sink documentation for more details]({{< param DocsBaseUrl >}}flink-docs-release-1.1/apis/streaming/connectors/cassandra.html).
+
+## Table API and SQL
+
+ The Table API is a SQL-like expression language for relational stream and batch processing that can be easily embedded in Flink’s DataSet and DataStream APIs (for both Java and Scala).
+
+```java
+Table custT = tableEnv
+ .toTable(custDs, "name, zipcode")
+ .where("zipcode = '12345'")
+ .select("name")
+```
+
+An initial version of this API was already available in Flink 1.0. For Flink 1.1, the community put a lot of work into reworking the architecture of the Table API and integrating it with [Apache Calcite](https://calcite.apache.org).
+
+In this first version, SQL (and Table API) queries on streams are limited to selection, filter, and union operators. Compared to Flink 1.0, the revised Table API supports many more scalar functions and is able to read tables from external sources and write them back to external sinks.
+
+```java
+Table result = tableEnv.sql(
+ "SELECT STREAM product, amount FROM Orders WHERE product LIKE '%Rubber%'");
+```
+A more detailed introduction can be found in the [Flink blog](http://flink.apache.org/news/2016/05/24/stream-sql.html) and the [Table API documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.1/apis/table.html).
+
+## DataStream API
+
+The DataStream API now exposes **session windows** and **allowed lateness** as first-class citizens.
+
+### Session Windows
+
+ Session windows are ideal for cases where the window boundaries need to adjust to the incoming data. This enables you to have windows that start at individual points in time for each key and that end once there has been a *certain period of inactivity*. The configuration parameter is the session gap that specifies how long to wait for new data before considering a session as closed.
+
+
+
+
+
+```java
+input.keyBy()
+ .window(EventTimeSessionWindows.withGap(Time.minutes(10)))
+ .();
+```
+
+### Support for Late Elements
+
+You can now specify how a windowed transformation should deal with late elements and how much lateness is allowed. The parameter for this is called *allowed lateness*. This specifies by how much time elements can be late.
+
+```java
+input.keyBy().window()
+ .allowedLateness()
+ .();
+```
+
+Elements that arrive within the allowed lateness are still put into windows and are considered when computing window results. If elements arrive after the allowed lateness they will be dropped. Flink will also make sure that any state held by the windowing operation is garbage collected once the watermark passes the end of a window plus the allowed lateness.
+
+Check out the [Windows documentation for more details]({{< param DocsBaseUrl >}}flink-docs-release-1.1/apis/streaming/windows.html).
+
+## Scala API for Complex Event Processing (CEP)
+
+Flink 1.0 added the initial version of the CEP library. The core of the library is a Pattern API, which allows you to easily specify patterns to match against in your event stream. While in Flink 1.0 this API was only available for Java, Flink 1.1. now exposes the same API for Scala, allowing you to specify your event patterns in a more concise manner.
+
+A more detailed introduction can be found in the [Flink blog]( http://flink.apache.org/news/2016/04/06/cep-monitoring.html) and the [CEP documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.1/apis/streaming/libs/cep.html).
+
+## Graph generators and new Gelly library algorithms
+
+This release includes many enhancements and new features for graph processing. Gelly now provides a collection of scalable graph generators for common graph types, such as complete, cycle, grid, hypercube, and RMat graphs. A variety of new graph algorithms have been added to the Gelly library, including Global and Local Clustering Coefficient, HITS, and similarity measures (Jaccard and Adamic-Adar).
+
+For a full list of new graph processing features, check out the [Gelly documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.1/apis/batch/libs/gelly.html).
+
+## Metrics
+
+Flink’s new metrics system allows you to easily gather and expose metrics from your user application to external systems. You can add counters, gauges, and histograms to your application via the runtime context:
+
+```java
+Counter counter = getRuntimeContext()
+ .getMetricGroup()
+ .counter("my-counter");
+```
+
+All registered metrics will be exposed via reporters. Out of the box, Flinks comes with support for JMX, Ganglia, Graphite, and statsD. In addition to your custom metrics, Flink exposes many internal metrics like checkpoint sizes and JVM stats.
+
+Check out the [Metrics documentation for more details]({{< param DocsBaseUrl >}}flink-docs-release-1.1/apis/metrics.html).
+
+## List of Contributors
+
+The following 95 people contributed to this release:
+
+- Abdullah Ozturk
+- Ajay Bhat
+- Alexey Savartsov
+- Aljoscha Krettek
+- Andrea Sella
+- Andrew Palumbo
+- Chenguang He
+- Chiwan Park
+- David Moravek
+- Dominik Bruhn
+- Dyana Rose
+- Fabian Hueske
+- Flavio Pompermaier
+- Gabor Gevay
+- Gabor Horvath
+- Geoffrey Mon
+- Gordon Tai
+- Greg Hogan
+- Gyula Fora
+- Henry Saputra
+- Ignacio N. Lucero Ascencio
+- Igor Berman
+- Ismaël Mejía
+- Ivan Mushketyk
+- Jark Wu
+- Jiri Simsa
+- Jonas Traub
+- Josh
+- Joshi
+- Joshua Herman
+- Ken Krugler
+- Konstantin Knauf
+- Lasse Dalegaard
+- Li Fanxi
+- MaBiao
+- Mao Wei
+- Mark Reddy
+- Martin Junghanns
+- Martin Liesenberg
+- Maximilian Michels
+- Michal Fijolek
+- Márton Balassi
+- Nathan Howell
+- Niels Basjes
+- Niels Zeilemaker
+- Phetsarath, Sourigna
+- Robert Metzger
+- Scott Kidder
+- Sebastian Klemke
+- Shahin
+- Shannon Carey
+- Shannon Quinn
+- Stefan Richter
+- Stefano Baghino
+- Stefano Bortoli
+- Stephan Ewen
+- Steve Cosenza
+- Sumit Chawla
+- Tatu Saloranta
+- Tianji Li
+- Till Rohrmann
+- Todd Lisonbee
+- Tony Baines
+- Trevor Grant
+- Ufuk Celebi
+- Vasudevan
+- Yijie Shen
+- Zack Pierce
+- Zhai Jia
+- chengxiang li
+- chobeat
+- danielblazevski
+- dawid
+- dawidwys
+- eastcirclek
+- erli ding
+- gallenvara
+- kl0u
+- mans2singh
+- markreddy
+- mjsax
+- nikste
+- omaralvarez
+- philippgrulich
+- ramkrishna
+- sahitya-pavurala
+- samaitra
+- smarthi
+- spkavuly
+- subhankar
+- twalthr
+- vasia
+- xueyan.li
+- zentol
+- 卫乐
diff --git a/docs/content.tr/posts/2016-08-04-release-1.1.1.md b/docs/content.tr/posts/2016-08-04-release-1.1.1.md
new file mode 100644
index 0000000000..c902fe7b2f
--- /dev/null
+++ b/docs/content.tr/posts/2016-08-04-release-1.1.1.md
@@ -0,0 +1,32 @@
+---
+date: "2016-08-04T09:00:00Z"
+title: Flink 1.1.1 Released
+aliases:
+- /news/2016/08/11/release-1.1.1.html
+---
+
+Today, the Flink community released Flink version 1.1.1.
+
+The Maven artifacts published on Maven central for 1.1.0 had a Hadoop dependency issue: No Hadoop 1 specific version (with version 1.1.0-hadoop1) was deployed and 1.1.0 artifacts have a dependency on Hadoop 1 instead of Hadoop 2.
+
+This was fixed with this release and we **highly recommend** all users to use this version of Flink by bumping your Flink dependencies to version 1.1.1:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.1.1
+
+
+ org.apache.flink
+ flink-streaming-java_2.10
+ 1.1.1
+
+
+ org.apache.flink
+ flink-clients_2.10
+ 1.1.1
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
diff --git a/docs/content.tr/posts/2016-08-24-ff16-keynotes-panels.md b/docs/content.tr/posts/2016-08-24-ff16-keynotes-panels.md
new file mode 100644
index 0000000000..83608698ce
--- /dev/null
+++ b/docs/content.tr/posts/2016-08-24-ff16-keynotes-panels.md
@@ -0,0 +1,18 @@
+---
+date: "2016-08-24T09:00:00Z"
+title: 'Flink Forward 2016: Announcing Schedule, Keynotes, and Panel Discussion'
+aliases:
+- /news/2016/08/24/ff16-keynotes-panels.html
+---
+
+An update for the Flink community: the Flink Forward 2016 schedule is now available online. This year's event will include 2 days of talks from stream processing experts at Google, MapR, Alibaba, Netflix, Cloudera, and more. Following the talks is a full day of hands-on Flink training.
+
+Ted Dunning has been announced as a keynote speaker at the event. Ted is the VP of Incubator at Apache Software Foundation , the Chief Application Architect at MapR Technologies , and a mentor on many recent projects. He'll present "How Can We Take Flink Forward?" on the second day of the conference.
+
+Following Ted's keynote there will be a panel discussion on "Large Scale Streaming in Production" . As stream processing systems become more mainstream, companies are looking to empower their users to take advantage of this technology. We welcome leading stream processing experts Xiaowei Jiang (Alibaba) , Monal Daxini (Netflix) , Maxim Fateev (Uber) , and Ted Dunning (MapR Technologies) on stage to talk about the challenges they have faced and the solutions they have discovered while implementing stream processing systems at very large scale. The panel will be moderated by Jamie Grier (data Artisans) .
+
+The welcome keynote on Monday, September 12, will be presented by data Artisans' co-founders Kostas Tzoumas and Stephan Ewen. They will talk about "The maturing data streaming ecosystem and Apache Flink’s accelerated growth" . In this talk, Kostas and Stephan discuss several large-scale stream processing use cases that the data Artisans team has seen over the past year.
+
+And one more recent addition to the program: Maxim Fateev of Uber will present "Beyond the Watermark: On-Demand Backfilling in Flink" . Flink’s time-progress model is built around a single watermark, which is incompatible with Uber’s business need for generating aggregates retroactively. Maxim's talk covers Uber's solution for on-demand backfilling.
+
+We hope to see many community members at Flink Forward 2016. Registration is available online: flink-forward.org/registration
diff --git a/docs/content.tr/posts/2016-09-05-release-1.1.2.md b/docs/content.tr/posts/2016-09-05-release-1.1.2.md
new file mode 100644
index 0000000000..bf127d1fa7
--- /dev/null
+++ b/docs/content.tr/posts/2016-09-05-release-1.1.2.md
@@ -0,0 +1,77 @@
+---
+date: "2016-09-05T09:00:00Z"
+title: Apache Flink 1.1.2 Released
+aliases:
+- /news/2016/09/05/release-1.1.2.html
+---
+
+The Apache Flink community released another bugfix version of the Apache Flink 1.1. series.
+
+We recommend all users to upgrade to Flink 1.1.2.
+
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.1.2
+
+
+ org.apache.flink
+ flink-streaming-java_2.10
+ 1.1.2
+
+
+ org.apache.flink
+ flink-clients_2.10
+ 1.1.2
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+
+
Release Notes - Flink - Version 1.1.2
+
+
+[FLINK-4236 ] - Flink Dashboard stops showing list of uploaded jars if main method cannot be looked up
+
+[FLINK-4309 ] - Potential null pointer dereference in DelegatingConfiguration#keySet()
+
+[FLINK-4334 ] - Shaded Hadoop1 jar not fully excluded in Quickstart
+
+[FLINK-4341 ] - Kinesis connector does not emit maximum watermark properly
+
+[FLINK-4402 ] - Wrong metrics parameter names in documentation
+
+[FLINK-4409 ] - class conflict between jsr305-1.3.9.jar and flink-shaded-hadoop2-1.1.1.jar
+
+[FLINK-4411 ] - [py] Chained dual input children are not properly propagated
+
+[FLINK-4412 ] - [py] Chaining does not properly handle broadcast variables
+
+[FLINK-4425 ] - "Out Of Memory" during savepoint deserialization
+
+[FLINK-4454 ] - Lookups for JobManager address in config
+
+[FLINK-4480 ] - Incorrect link to elastic.co in documentation
+
+[FLINK-4486 ] - JobManager not fully running when yarn-session.sh finishes
+
+[FLINK-4488 ] - Prevent cluster shutdown after job execution for non-detached jobs
+
+[FLINK-4514 ] - ExpiredIteratorException in Kinesis Consumer on long catch-ups to head of stream
+
+[FLINK-4526 ] - ApplicationClient: remove redundant proxy messages
+
+
+[FLINK-3866 ] - StringArraySerializer claims type is immutable; shouldn't
+
+[FLINK-3899 ] - Document window processing with Reduce/FoldFunction + WindowFunction
+
+[FLINK-4302 ] - Add JavaDocs to MetricConfig
+
+[FLINK-4495 ] - Running multiple jobs on yarn (without yarn-session)
+
+
+
diff --git a/docs/content.tr/posts/2016-10-12-release-1.1.3.md b/docs/content.tr/posts/2016-10-12-release-1.1.3.md
new file mode 100644
index 0000000000..ef3db5cd39
--- /dev/null
+++ b/docs/content.tr/posts/2016-10-12-release-1.1.3.md
@@ -0,0 +1,107 @@
+---
+date: "2016-10-12T09:00:00Z"
+title: Apache Flink 1.1.3 Released
+aliases:
+- /news/2016/10/12/release-1.1.3.html
+---
+
+The Apache Flink community released the next bugfix version of the Apache Flink 1.1. series.
+
+We recommend all users to upgrade to Flink 1.1.3.
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.1.3
+
+
+ org.apache.flink
+ flink-streaming-java_2.10
+ 1.1.3
+
+
+ org.apache.flink
+ flink-clients_2.10
+ 1.1.3
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+## Note for RocksDB Backend Users
+
+It is highly recommended to use the "fully async" mode for the RocksDB state backend. The "fully async" mode will most likely allow you to easily upgrade to Flink 1.2 (via [savepoints]({{< param DocsBaseUrl >}}flink-docs-release-1.1/apis/streaming/savepoints.html)) when it is released. The "semi async" mode will no longer be supported by Flink 1.2.
+
+```java
+RocksDBStateBackend backend = new RocksDBStateBackend("...");
+backend.enableFullyAsyncSnapshots();
+```
+
+## Release Notes - Flink - Version 1.1.3
+
+ Bug
+
+
+[FLINK-2662 ] - CompilerException: "Bug: Plan generation for Unions picked a ship strategy between binary plan operators."
+
+[FLINK-4311 ] - TableInputFormat fails when reused on next split
+
+[FLINK-4329 ] - Fix Streaming File Source Timestamps/Watermarks Handling
+
+[FLINK-4485 ] - Finished jobs in yarn session fill /tmp filesystem
+
+[FLINK-4513 ] - Kafka connector documentation refers to Flink 1.1-SNAPSHOT
+
+[FLINK-4514 ] - ExpiredIteratorException in Kinesis Consumer on long catch-ups to head of stream
+
+[FLINK-4540 ] - Detached job execution may prevent cluster shutdown
+
+[FLINK-4544 ] - TaskManager metrics are vulnerable to custom JMX bean installation
+
+[FLINK-4566 ] - ProducerFailedException does not properly preserve Exception causes
+
+[FLINK-4588 ] - Fix Merging of Covering Window in MergingWindowSet
+
+[FLINK-4589 ] - Fix Merging of Covering Window in MergingWindowSet
+
+[FLINK-4616 ] - Kafka consumer doesn't store last emmited watermarks per partition in state
+
+[FLINK-4618 ] - FlinkKafkaConsumer09 should start from the next record on startup from offsets in Kafka
+
+[FLINK-4619 ] - JobManager does not answer to client when restore from savepoint fails
+
+[FLINK-4636 ] - AbstractCEPPatternOperator fails to restore state
+
+[FLINK-4640 ] - Serialization of the initialValue of a Fold on WindowedStream fails
+
+[FLINK-4651 ] - Re-register processing time timers at the WindowOperator upon recovery.
+
+[FLINK-4663 ] - Flink JDBCOutputFormat logs wrong WARN message
+
+[FLINK-4672 ] - TaskManager accidentally decorates Kill messages
+
+[FLINK-4677 ] - Jars with no job executions produces NullPointerException in ClusterClient
+
+[FLINK-4702 ] - Kafka consumer must commit offsets asynchronously
+
+[FLINK-4727 ] - Kafka 0.9 Consumer should also checkpoint auto retrieved offsets even when no data is read
+
+[FLINK-4732 ] - Maven junction plugin security threat
+
+[FLINK-4777 ] - ContinuousFileMonitoringFunction may throw IOException when files are moved
+
+[FLINK-4788 ] - State backend class cannot be loaded, because fully qualified name converted to lower-case
+
+
+
+ Improvement
+
+
+[FLINK-4396 ] - GraphiteReporter class not found at startup of jobmanager
+
+[FLINK-4574 ] - Strengthen fetch interval implementation in Kinesis consumer
+
+[FLINK-4723 ] - Unify behaviour of committed offsets to Kafka / ZK for Kafka 0.8 and 0.9 consumer
+
+
diff --git a/docs/content.tr/posts/2016-12-19-2016-year-in-review.md b/docs/content.tr/posts/2016-12-19-2016-year-in-review.md
new file mode 100644
index 0000000000..e3c092c531
--- /dev/null
+++ b/docs/content.tr/posts/2016-12-19-2016-year-in-review.md
@@ -0,0 +1,172 @@
+---
+author: Mike Winters
+date: "2016-12-19T09:00:00Z"
+excerpt: As 2016 comes to a close, let's take a moment to look back on the Flink
+ community's great work during the past year.
+title: 'Apache Flink in 2016: Year in Review'
+aliases:
+- /news/2016/12/19/2016-year-in-review.html
+---
+2016 was an exciting year for the Apache Flink® community, and the
+ release of Flink 1.0 in March
+ marked the first time in Flink’s history that the community guaranteed API backward compatibility for all
+ versions in a series. This step forward for Flink was followed by many new and exciting production deployments
+ in organizations of all shapes and sizes, all around the globe.
+
+In this post, we’ll look back on the project’s progress over the course of 2016, and
+we’ll also preview what 2017 has in store.
+
+{%toc%}
+
+## Community Growth
+
+### Github
+First, here's a summary of community statistics from GitHub . At the time of writing:
+
+ Contributors have increased from 150 in December 2015 to 258 in December 2016 (up 72% )
+ Stars have increased from 813 in December 2015 to 1830 in December 2016 (up 125% )
+ Forks have increased from 544 in December 2015 to 1255 in December 2016 (up 130% )
+
+
+The community also welcomed 3 new committers in 2016 : Chengxiang Li, Greg Hogan, and Tzu-Li (Gordon) Tai.
+
+
+
+
+
+Next, let's take a look at a few other project stats, starting with number of commits. If we run:
+
+```
+git log --pretty=oneline --after=12/31/2015 | wc -l
+```
+...inside the Flink repository, we'll see a total of **1884** commits so far in 2016, bringing the all-time total commits to **10,015**.
+
+Now, let's go a bit deeper. And here are instructions in case you'd like to take a look at this data yourself.
+
+* Download gitstats from the [project homepage](http://gitstats.sourceforge.net/). Or, on OS X with homebrew, type:
+
+```
+brew install --HEAD homebrew/head-only/gitstats
+```
+
+* Clone the Apache Flink git repository:
+
+```
+git clone git@github.com:apache/flink.git
+```
+
+* Generate the statistics
+
+```
+gitstats flink/ flink-stats/
+```
+
+* View all the statistics as an html page using your defaulf browser:
+
+```
+open flink-stats/index.html
+```
+2016 is the year that Flink surpassed 1 million lines of code, now clocking in at **1,034,137** lines.
+
+
+
+Monday remains the day of the week with the most commits over the project's history:
+
+
+
+And 5pm is still solidly the preferred commit time:
+
+
+
+
+
+
+
+
+### Meetups
+Apache Flink Meetup membership grew by 240%
+this year, and at the time of writing, there are 41 meetups comprised of 16,541 members listing Flink as a topic--up from 16 groups with 4,864 members in December 2015.
+The Flink community is proud to be truly global in nature.
+
+
+
+## Flink Forward 2016
+
+The second annual Flink Forward conference took place in
+Berlin on September 12-14, and over 350 members of the Flink community came together for speaker sessions, training,
+and discussion about Flink. Slides and videos
+ from speaker sessions are available online, and we encourage you to take a look if you’re interested in learning more
+ about how Flink is used in production in a wide range of organizations.
+
+Flink Forward will be expanding to San Francisco in April 2017 , and the third-annual Berlin event
+ is scheduled for September 2017.
+
+
+
+## Features and Ecosystem
+
+### Flink Ecosystem Growth
+
+Flink was added to a selection of distributions during 2016, making it easier
+for an even larger base of users to start working with Flink:
+
+
+
+In addition, the Apache Beam and Flink communities teamed up to build a Flink runner for Beam that, according to the Google team, is "sophisticated enough to be a compelling alternative to Cloud Dataflow when running on premise or on non-Google clouds" .
+
+### Feature Timeline in 2016
+
+Here’s a selection of major features added to Flink over the course of 2016:
+
+
+
+If you spend time in the Apache Flink JIRA project , you’ll see that the Flink community has addressed every single one of the roadmap items identified
+in 2015’s year in review post . Here's to making that an annual tradition. :)
+
+## Looking ahead to 2017
+
+A good source of information about the Flink community's roadmap is the list of
+Flink
+Improvement Proposals (FLIPs) in the project wiki. Below, we'll highlight a selection of FLIPs
+that have been accepted by the community as well as some that are still under discussion.
+
+We should note that work is already underway on a number of these features, and some will even be included in Flink 1.2 at the beginning of 2017.
+
+* **A new Flink deployment and process model**, as described in FLIP-6 . This work ensures that Flink supports a wide
+range of deployment types and cluster managers, making it possible to run Flink smoothly in any environment.
+
+* **Dynamic scaling** for both key-value state (as described in
+this PR) *and* non-partitioned state (as described in FLIP-8) , ensuring that it's always possible to split or merge state when scaling up or down, respectively.
+
+* **Asynchronous I/O**, as described in FLIP-12
+ , which makes I/O access a less time-consuming process without adding complexity or the need for extra checkpoint coordination.
+
+* **Enhancements to the window evictor**, as described in FLIP-4 ,
+to provide users with more control over how elements are evicted from a window.
+
+* **Fined-grained recovery from task failures**, as described in FLIP-1 ,
+to make it possible to restart only what needs to be restarted during recovery, building on cached intermediate results.
+
+* **Unified checkpoints and savepoints**, as described in FLIP-10 , to
+allow savepoints to be triggered automatically--important for program updates for the sake of error handling because savepoints allow the user to modify both
+ the job and Flink version whereas checkpoints can only be recovered with the same job.
+
+* **Table API window aggregations**, as described in FLIP-11 , to support group-window and row-window aggregates on streaming and batch tables.
+
+* **Side inputs**, as described in this design document , to
+enable the joining of a main, high-throughput stream with one more more inputs with static or slowly-changing data.
+
+If you're interested in getting involved with Flink, we encourage you to take a look at the FLIPs and to join the discussion via the [Flink mailing lists](http://flink.apache.org/community.html#mailing-lists).
+
+Lastly, we'd like to extend a sincere thank you to all of the Flink community for making 2016 a great year!
diff --git a/docs/content.tr/posts/2016-12-21-release-1.1.4.md b/docs/content.tr/posts/2016-12-21-release-1.1.4.md
new file mode 100644
index 0000000000..24a5ea712b
--- /dev/null
+++ b/docs/content.tr/posts/2016-12-21-release-1.1.4.md
@@ -0,0 +1,218 @@
+---
+date: "2016-12-21T09:00:00Z"
+title: Apache Flink 1.1.4 Released
+aliases:
+- /news/2016/12/21/release-1.1.4.html
+---
+
+The Apache Flink community released the next bugfix version of the Apache Flink 1.1 series.
+
+This release includes major robustness improvements for checkpoint cleanup on failures and consumption of intermediate streams. We highly recommend all users to upgrade to Flink 1.1.4.
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.1.4
+
+
+ org.apache.flink
+ flink-streaming-java_2.10
+ 1.1.4
+
+
+ org.apache.flink
+ flink-clients_2.10
+ 1.1.4
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+## Note for RocksDB Backend Users
+
+We updated Flink's RocksDB dependency version from `4.5.1` to `4.11.2`. Between these versions some of RocksDB's internal configuration defaults changed that would affect the memory footprint of running Flink with RocksDB. Therefore, we manually reset them to the previous defaults. If you want to run with the new Rocks 4.11.2 defaults, you can do this via:
+
+```java
+RocksDBStateBackend backend = new RocksDBStateBackend("...");
+// Use the new default options. Otherwise, the default for RocksDB 4.5.1
+// `PredefinedOptions.DEFAULT_ROCKS_4_5_1` will be used.
+backend.setPredefinedOptions(PredefinedOptions.DEFAULT);
+```
+
+## Release Notes - Flink - Version 1.1.4
+
+### Sub-task
+
+[FLINK-4510 ] - Always create CheckpointCoordinator
+
+[FLINK-4984 ] - Add Cancellation Barriers to BarrierTracker and BarrierBuffer
+
+[FLINK-4985 ] - Report Declined/Canceled Checkpoints to Checkpoint Coordinator
+
+
+
+### Bug
+
+[FLINK-2662 ] - CompilerException: "Bug: Plan generation for Unions picked a ship strategy between binary plan operators."
+
+[FLINK-3680 ] - Remove or improve (not set) text in the Job Plan UI
+
+[FLINK-3813 ] - YARNSessionFIFOITCase.testDetachedMode failed on Travis
+
+[FLINK-4108 ] - NPE in Row.productArity
+
+[FLINK-4506 ] - CsvOutputFormat defaults allowNullValues to false, even though doc and declaration says true
+
+[FLINK-4581 ] - Table API throws "No suitable driver found for jdbc:calcite"
+
+[FLINK-4586 ] - NumberSequenceIterator and Accumulator threading issue
+
+[FLINK-4619 ] - JobManager does not answer to client when restore from savepoint fails
+
+[FLINK-4727 ] - Kafka 0.9 Consumer should also checkpoint auto retrieved offsets even when no data is read
+
+[FLINK-4862 ] - NPE on EventTimeSessionWindows with ContinuousEventTimeTrigger
+
+[FLINK-4932 ] - Don't let ExecutionGraph fail when in state Restarting
+
+[FLINK-4933 ] - ExecutionGraph.scheduleOrUpdateConsumers can fail the ExecutionGraph
+
+[FLINK-4977 ] - Enum serialization does not work in all cases
+
+[FLINK-4991 ] - TestTask hangs in testWatchDogInterruptsTask
+
+[FLINK-4998 ] - ResourceManager fails when num task slots > Yarn vcores
+
+[FLINK-5013 ] - Flink Kinesis connector doesn't work on old EMR versions
+
+[FLINK-5028 ] - Stream Tasks must not go through clean shutdown logic on cancellation
+
+[FLINK-5038 ] - Errors in the "cancelTask" method prevent closeables from being closed early
+
+[FLINK-5039 ] - Avro GenericRecord support is broken
+
+[FLINK-5040 ] - Set correct input channel types with eager scheduling
+
+[FLINK-5050 ] - JSON.org license is CatX
+
+[FLINK-5057 ] - Cancellation timeouts are picked from wrong config
+
+[FLINK-5058 ] - taskManagerMemory attribute set wrong value in FlinkShell
+
+[FLINK-5063 ] - State handles are not properly cleaned up for declined or expired checkpoints
+
+[FLINK-5073 ] - ZooKeeperCompleteCheckpointStore executes blocking delete operation in ZooKeeper client thread
+
+[FLINK-5075 ] - Kinesis consumer incorrectly determines shards as newly discovered when tested against Kinesalite
+
+[FLINK-5082 ] - Pull ExecutionService lifecycle management out of the JobManager
+
+[FLINK-5085 ] - Execute CheckpointCoodinator's state discard calls asynchronously
+
+[FLINK-5114 ] - PartitionState update with finished execution fails
+
+[FLINK-5142 ] - Resource leak in CheckpointCoordinator
+
+[FLINK-5149 ] - ContinuousEventTimeTrigger doesn't fire at the end of the window
+
+[FLINK-5154 ] - Duplicate TypeSerializer when writing RocksDB Snapshot
+
+[FLINK-5158 ] - Handle ZooKeeperCompletedCheckpointStore exceptions in CheckpointCoordinator
+
+[FLINK-5172 ] - In RocksDBStateBackend, set flink-core and flink-streaming-java to "provided"
+
+[FLINK-5173 ] - Upgrade RocksDB dependency
+
+[FLINK-5184 ] - Error result of compareSerialized in RowComparator class
+
+[FLINK-5193 ] - Recovering all jobs fails completely if a single recovery fails
+
+[FLINK-5197 ] - Late JobStatusChanged messages can interfere with running jobs
+
+[FLINK-5214 ] - Clean up checkpoint files when failing checkpoint operation on TM
+
+[FLINK-5215 ] - Close checkpoint streams upon cancellation
+
+[FLINK-5216 ] - CheckpointCoordinator's 'minPauseBetweenCheckpoints' refers to checkpoint start rather then checkpoint completion
+
+[FLINK-5218 ] - Eagerly close checkpoint streams on cancellation
+
+[FLINK-5228 ] - LocalInputChannel re-trigger request and release deadlock
+
+[FLINK-5229 ] - Cleanup StreamTaskStates if a checkpoint operation of a subsequent operator fails
+
+[FLINK-5246 ] - Don't discard unknown checkpoint messages in the CheckpointCoordinator
+
+[FLINK-5248 ] - SavepointITCase doesn't catch savepoint restore failure
+
+[FLINK-5274 ] - LocalInputChannel throws NPE if partition reader is released
+
+[FLINK-5275 ] - InputChanelDeploymentDescriptors throws misleading Exception if producer failed/cancelled
+
+[FLINK-5276 ] - ExecutionVertex archiving can throw NPE with many previous attempts
+
+[FLINK-5285 ] - CancelCheckpointMarker flood when using at least once mode
+
+[FLINK-5326 ] - IllegalStateException: Bug in Netty consumer logic: reader queue got notified by partition about available data, but none was available
+
+[FLINK-5352 ] - Restore RocksDB 1.1.3 memory behavior
+
+
+
+### Improvement
+
+[FLINK-3347 ] - TaskManager (or its ActorSystem) need to restart in case they notice quarantine
+
+[FLINK-3787 ] - Yarn client does not report unfulfillable container constraints
+
+[FLINK-4445 ] - Ignore unmatched state when restoring from savepoint
+
+[FLINK-4715 ] - TaskManager should commit suicide after cancellation failure
+
+[FLINK-4894 ] - Don't block on buffer request after broadcastEvent
+
+[FLINK-4975 ] - Add a limit for how much data may be buffered during checkpoint alignment
+
+[FLINK-4996 ] - Make CrossHint @Public
+
+[FLINK-5046 ] - Avoid redundant serialization when creating the TaskDeploymentDescriptor
+
+[FLINK-5123 ] - Add description how to do proper shading to Flink docs.
+
+[FLINK-5169 ] - Make consumption of input channels fair
+
+[FLINK-5192 ] - Provide better log config templates
+
+[FLINK-5194 ] - Log heartbeats on TRACE level
+
+[FLINK-5196 ] - Don't log InputChannelDescriptor
+
+[FLINK-5198 ] - Overwrite TaskState toString
+
+[FLINK-5199 ] - Improve logging of submitted job graph actions in HA case
+
+[FLINK-5201 ] - Promote loaded config properties to INFO
+
+[FLINK-5207 ] - Decrease HadoopFileSystem logging
+
+[FLINK-5249 ] - description of datastream rescaling doesn't match the figure
+
+[FLINK-5259 ] - wrong execution environment in retry delays example
+
+[FLINK-5278 ] - Improve Task and checkpoint logging
+
+
+
+### New Feature
+
+[FLINK-4976 ] - Add a way to abort in flight checkpoints
+
+
+
+### Task
+
+[FLINK-4778 ] - Update program example in /docs/setup/cli.md due to the change in FLINK-2021
+
+
+
diff --git a/docs/content.tr/posts/2017-02-06-release-1.2.0.md b/docs/content.tr/posts/2017-02-06-release-1.2.0.md
new file mode 100644
index 0000000000..02534a0e51
--- /dev/null
+++ b/docs/content.tr/posts/2017-02-06-release-1.2.0.md
@@ -0,0 +1,242 @@
+---
+author: Robert Metzger
+date: "2017-02-06T12:00:00Z"
+excerpt: The Apache Flink community is excited to announce the 1.2.0 release.
+title: Announcing Apache Flink 1.2.0
+aliases:
+- /news/2017/02/06/release-1.2.0.html
+---
+
+The Apache Flink community is pleased to announce the 1.2.0 release. Over the past months, the Flink community has been working hard to resolve 650 issues. See the [complete changelog](http://flink.apache.org/blog/release_1.2.0-changelog.html) for more detail.
+
+This is the third major release in the 1.x.y series. It is API compatible with the other 1.x.y releases for APIs annotated with the @Public annotation.
+
+We encourage everyone to download the release and check out the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.2/). Feedback through the [Flink mailing lists](http://flink.apache.org/community.html#mailing-lists) is, as always, gladly encouraged!
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html). Some highlights of the release are listed below.
+
+## Dynamic Scaling / Key Groups
+
+Flink now supports changing the parallelism of a streaming job by restoring it from a savepoint with a different parallelism. Both changing the entire job’s parallelism and operator parallelism is supported.
+In the `StreamExecutionEnvironment`, users can set a new per-job configuration parameter called “max parallelism”. It determines the upper limit for the parallelism.
+
+By default, the value is set to:
+
++ `128` : for all parallelism <= 128
++ `MIN(nextPowerOfTwo(parallelism + (parallelism / 2)), 2^15)`: for all parallelism > 128
+
+The following built-in functions and operators support rescaling:
+
++ Window operator
++ Rolling/Bucketing sink
++ Kafka consumers
++ Continuous File Processing source
+
+The write-ahead log Cassandra sink and the CEP operator are currently not rescalable. Users using the keyed state interfaces can use the dynamic scaling without changing their code.
+
+## Rescalable Non-Partitioned State
+
+As part of the dynamic scaling effort, the community has also added rescalable non-partitioned state for operators like the Kafka consumer that don’t use keyed state but instead use operator state.
+
+In case of rescaling, the operator state needs to be redistributed among the parallel consumer instances. In case of the Kafka consumer, the assigned partitions and their offsets are redistributed.
+
+## ProcessFunction
+
+The `ProcessFunction` is a low-level stream processing operation giving access to the basic building blocks of all (acyclic) streaming applications:
+
++ Events (stream elements)
++ State (fault tolerant, consistent)
++ Timers (event time and processing time)
+
+The ProcessFunction can be thought of as a FlatMapFunction with access to keyed state and timers.
+
+[ProcessFunction documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/stream/process_function.html)
+
+## Async I/O
+
+Flink now has a dedicated Async I/O operator for making blocking calls asynchronously and in a checkpointed fashion. For example, there are many Flink applications that need to query external datastores for each element in a stream. To avoid slowing down the stream to the speed of the external system, the async I/O operator allows requests to overlap.
+
+[Async I/O documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/stream/asyncio.html)
+
+## Run Flink with Apache Mesos
+
+The latest release further extends Flink’s deployment flexibility by adding support for Apache Mesos and DC/OS. In combination with Marathon, it is now possible to run an highly available Flink cluster on Mesos.
+
+[Mesos documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.2/setup/mesos.html)
+
+## Secure Data Access
+
+Flink is now able to authenticate against external services such as Zookeeper, Kafka, HDFS and YARN using Kerberos.
+Also, experimental support for encryption over the wire has been added.
+
+[Kerberos documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.2/ops/security-kerberos.html) and [SSL setup documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.2/setup/security-ssl.html).
+
+## Queryable State
+
+This experimental feature allows users to query the current state of an operator.
+If you have, for example, a flatMap() operator that keeps a running aggregate per key, queryable state allows you to retrieve the current aggregate value at any time by directly connecting to the TaskManager and retrieving that value.
+
+[Queryable State documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/stream/queryable_state.html)
+
+## Backwards compatible savepoints
+
+Flink 1.2.0 allows users to restart a job from an 1.1.4 savepoint. This makes major Flink version upgrades possible without losing application state. The following built-in operators are backwards compatible:
+
++ Window operator
++ Rolling/Bucketing sink
++ Kafka consumers
++ Continuous File Processing source
+
+[Upgrading Flink applications documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.2/ops/upgrading.html)
+
+## Table API & SQL
+
+This release significantly expanded the performance, stability, and coverage of Flink’s Table API and SQL support for batch and streaming tables.
+
+The community added tumbling, sliding, and session group-window aggregations over streaming tables
+ e.g. `table.window(Session withGap 10.minutes on 'rowtime as 'w)`
+
+SQL supports more built-in functions and operations
+ e.g. `EXISTS`, `VALUES`, `LIMIT`, `CURRENT_DATE`, `INITCAP`, `NULLIF`
+
+Both APIs support more data types and are better integrated
+ e.g. access a POJO field `myPojo.get('field')`, `myPojo.flatten()`
+
+Users can now define their own scalar and table functions
+ e.g. `table.select('uid, parse('field) as 'parsed).join(split('parsed) as 'atom)`
+
+[Flink Table API & SQL documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/table_api.html)
+
+## Miscellaneous improvements
++ Metrics in Flink web interface: A metrics system was added in Flink 1.1, and with this release, Flink provides a new tab in the web frontend to see some of the metrics in the web UI.
+
++ Kafka 0.10 support: Flink 1.2 now provides a connector for Apache Kafka 0.10.0.x, including support for consuming and producing messages with a timestamp using Flink’s internal event time ([Kafka Connector Documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/connectors/kafka.html))
+
++ Evictor Semantics: Flink 1.2 ships with more expressive evictor semantics that allow the programmer to evict elements form a window both before and after the application of the window function, and to remove elements arbitrarily ([Evictor Semantics Documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/windows.html#evictors))
+
+## List of Contributors
+
+According to git shortlog, the following 122 people contributed to the 1.2.0 release. Thank you to all contributors!
+
++ Abhishek R. Singh
++ Ahmad Ragab
++ Aleksandr Chermenin
++ Alexander Pivovarov
++ Alexander Shoshin
++ Alexey Diomin
++ Aljoscha Krettek
++ Andrey Melentyev
++ Anton Mushin
++ Bob Thorman
++ Boris Osipov
++ Bram Vogelaar
++ Bruno Aranda
++ David Anderson
++ Dominik
++ Evgeny_Kincharov
++ Fabian Hueske
++ Fokko Driesprong
++ Gabor Gevay
++ George
++ Gordon Tai
++ Greg Hogan
++ Gyula Fora
++ Haohui Mai
++ Holger Frydrych
++ HungUnicorn
++ Ismaël Mejía
++ Ivan Mushketyk
++ Jakub Havlik
++ Jark Wu
++ Jendrik Poloczek
++ Jincheng Sun
++ Josh
++ Joshi
++ Keiji Yoshida
++ Kirill Morozov
++ Kurt Young
++ Liwei Lin
++ Lorenz Buehmann
++ Maciek Próchniak
++ Makman2
++ Markus Müller
++ Martin Junghanns
++ Márton Balassi
++ Max Kuklinski
++ Maximilian Michels
++ Milosz Tanski
++ Nagarjun
++ Neelesh Srinivas Salian
++ Neil Derraugh
++ Nick Chadwick
++ Nico Kruber
++ Niels Basjes
++ Pattarawat Chormai
++ Piotr Godek
++ Raghav
++ Ramkrishna
++ Robert Metzger
++ Rohit Agarwal
++ Roman Maier
++ Sachin
++ Sachin Goel
++ Scott Kidder
++ Shannon Carey
++ Stefan Richter
++ Steffen Hausmann
++ Stephan Epping
++ Stephan Ewen
++ Sunny T
++ Suri
++ Theodore Vasiloudis
++ Till Rohrmann
++ Tony Wei
++ Tzu-Li (Gordon) Tai
++ Ufuk Celebi
++ Vijay Srinivasaraghavan
++ Vishnu Viswanath
++ WangTaoTheTonic
++ William-Sang
++ Yassine Marzougui
++ anton solovev
++ beyond1920
++ biao.liub
++ chobeat
++ danielblazevski
++ f7753
++ fengyelei
++ fengyelei 00406569
++ gallenvara
++ gaolun.gl
++ godfreyhe
++ heytitle
++ hzyuemeng1
++ iteblog
++ kl0u
++ larsbachmann
++ lincoln-lil
++ manuzhang
++ medale
++ miaoever
++ mtunique
++ radekg
++ renkai
++ sergey_sokur
++ shijinkui
++ shuai.xus
++ smarthi
++ swapnil-chougule
++ tedyu
++ tibor.moger
++ tonycox
++ twalthr
++ vasia
++ wenlong.lwl
++ wrighe3
++ xiaogang.sxg
++ yushi.wxg
++ yuzhongliu
++ zentol
++ zhuhaifengleon
++ 淘江
++ 魏偉哲
diff --git a/docs/content.tr/posts/2017-03-23-release-1.1.5.md b/docs/content.tr/posts/2017-03-23-release-1.1.5.md
new file mode 100644
index 0000000000..0f7e8030c0
--- /dev/null
+++ b/docs/content.tr/posts/2017-03-23-release-1.1.5.md
@@ -0,0 +1,74 @@
+---
+date: "2017-03-23T18:00:00Z"
+title: Apache Flink 1.1.5 Released
+aliases:
+- /news/2017/03/23/release-1.1.5.html
+---
+
+The Apache Flink community released the next bugfix version of the Apache Flink 1.1 series.
+
+This release includes critical fixes for HA recovery robustness, fault tolerance
+guarantees of the Flink Kafka Connector, as well as classloading issues with the Kryo serializer.
+We highly recommend all users to upgrade to Flink 1.1.5.
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.1.5
+
+
+ org.apache.flink
+ flink-streaming-java_2.10
+ 1.1.5
+
+
+ org.apache.flink
+ flink-clients_2.10
+ 1.1.5
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+## Release Notes - Flink - Version 1.1.5
+
+### Bug
+
+[FLINK-5701 ] - FlinkKafkaProducer should check asyncException on checkpoints
+
+[FLINK-6006 ] - Kafka Consumer can lose state if queried partition list is incomplete on restore
+
+[FLINK-5940 ] - ZooKeeperCompletedCheckpointStore cannot handle broken state handles
+
+[FLINK-5942 ] - Harden ZooKeeperStateHandleStore to deal with corrupted data
+
+[FLINK-6025 ] - User code ClassLoader not used when KryoSerializer fallbacks to serialization for copying
+
+[FLINK-5945 ] - Close function in OuterJoinOperatorBase#executeOnCollections
+
+[FLINK-5934 ] - Scheduler in ExecutionGraph null if failure happens in ExecutionGraph.restoreLatestCheckpointedState
+
+[FLINK-5771 ] - DelimitedInputFormat does not correctly handle multi-byte delimiters
+
+[FLINK-5647 ] - Fix RocksDB Backend Cleanup
+
+[FLINK-2662 ] - CompilerException: "Bug: Plan generation for Unions picked a ship strategy between binary plan operators."
+
+[FLINK-5585 ] - NullPointer Exception in JobManager.updateAccumulators
+
+[FLINK-5484 ] - Add test for registered Kryo types
+
+[FLINK-5518 ] - HadoopInputFormat throws NPE when close() is called before open()
+
+
+
+### Improvement
+
+[FLINK-5575 ] - in old releases, warn users and guide them to the latest stable docs
+
+[FLINK-5639 ] - Clarify License implications of RabbitMQ Connector
+
+[FLINK-5466 ] - Make production environment default in gulpfile
+
+
diff --git a/docs/content.tr/posts/2017-03-29-table-sql-api-update.md b/docs/content.tr/posts/2017-03-29-table-sql-api-update.md
new file mode 100644
index 0000000000..98efefb3af
--- /dev/null
+++ b/docs/content.tr/posts/2017-03-29-table-sql-api-update.md
@@ -0,0 +1,196 @@
+---
+author: Timo Walther
+author-twitter: twalthr
+date: "2017-03-29T12:00:00Z"
+excerpt: Broadening the user base and unifying batch & streaming with relational
+ APIs
+title: 'From Streams to Tables and Back Again: An Update on Flink''s Table & SQL API'
+aliases:
+- /news/2017/03/29/table-sql-api-update.html
+---
+Stream processing can deliver a lot of value. Many organizations have recognized the benefit of managing large volumes of data in real-time, reacting quickly to trends, and providing customers with live services at scale. Streaming applications with well-defined business logic can deliver a competitive advantage.
+
+Flink's [DataStream]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/datastream_api.html) abstraction is a powerful API which lets you flexibly define both basic and complex streaming pipelines. Additionally, it offers low-level operations such as [Async IO]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/stream/asyncio.html) and [ProcessFunctions]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/stream/process_function.html). However, many users do not need such a deep level of flexibility. They need an API which quickly solves 80% of their use cases where simple tasks can be defined using little code.
+
+To deliver the power of stream processing to a broader set of users, the Apache Flink community is developing APIs that provide simpler abstractions and more concise syntax so that users can focus on their business logic instead of advanced streaming concepts. Along with other APIs (such as [CEP]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/libs/cep.html) for complex event processing on streams), Flink offers a relational API that aims to unify stream and batch processing: the [Table & SQL API]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/table_api.html), often referred to as the Table API.
+
+Recently, contributors working for companies such as Alibaba, Huawei, data Artisans, and more decided to further develop the Table API. Over the past year, the Table API has been rewritten entirely. Since Flink 1.1, its core has been based on [Apache Calcite](http://calcite.apache.org/), which parses SQL and optimizes all relational queries. Today, the Table API can address a wide range of use cases in both batch and stream environments with unified semantics.
+
+This blog post summarizes the current status of Flink’s Table API and showcases some of the recently-added features in Apache Flink. Among the features presented here are the unified access to batch and streaming data, data transformation, and window operators.
+The following paragraphs are not only supposed to give you a general overview of the Table API, but also to illustrate the potential of relational APIs in the future.
+
+Because the Table API is built on top of Flink’s core APIs, [DataStreams]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/datastream_api.html) and [DataSets]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/batch/index.html) can be converted to a Table and vice-versa without much overhead. Hereafter, we show how to create tables from different sources and specify programs that can be executed locally or in a distributed setting. In this post, we will use the Scala version of the Table API, but there is also a Java version as well as a SQL API with an equivalent set of features.
+
+## Data Transformation and ETL
+
+A common task in every data processing pipeline is importing data from one or multiple systems, applying some transformations to it, then exporting the data to another system. The Table API can help to manage these recurring tasks. For reading data, the API provides a set of ready-to-use `TableSources` such as a `CsvTableSource` and `KafkaTableSource`, however, it also allows the implementation of custom `TableSources` that can hide configuration specifics (e.g. watermark generation) from users who are less familiar with streaming concepts.
+
+Let’s assume we have a CSV file that stores customer information. The values are delimited by a “\|”-character and contain a customer identifier, name, timestamp of the last update, and preferences encoded in a comma-separated key-value string:
+
+ 42|Bob Smith|2016-07-23 16:10:11|color=12,length=200,size=200
+
+The following example illustrates how to read a CSV file and perform some data cleansing before converting it to a regular DataStream program.
+
+```scala
+// set up execution environment
+val env = StreamExecutionEnvironment.getExecutionEnvironment
+val tEnv = TableEnvironment.getTableEnvironment(env)
+
+// configure table source
+val customerSource = CsvTableSource.builder()
+ .path("/path/to/customer_data.csv")
+ .ignoreFirstLine()
+ .fieldDelimiter("|")
+ .field("id", Types.LONG)
+ .field("name", Types.STRING)
+ .field("last_update", Types.TIMESTAMP)
+ .field("prefs", Types.STRING)
+ .build()
+
+// name your table source
+tEnv.registerTableSource("customers", customerSource)
+
+// define your table program
+val table = tEnv
+ .scan("customers")
+ .filter('name.isNotNull && 'last_update > "2016-01-01 00:00:00".toTimestamp)
+ .select('id, 'name.lowerCase(), 'prefs)
+
+// convert it to a data stream
+val ds = table.toDataStream[Row]
+
+ds.print()
+env.execute()
+```
+
+The Table API comes with a large set of built-in functions that make it easy to specify business logic using a language integrated query (LINQ) syntax. In the example above, we filter out customers with invalid names and only select those that updated their preferences recently. We convert names to lowercase for normalization. For debugging purposes, we convert the table into a DataStream and print it.
+
+The `CsvTableSource` supports both batch and stream environments. If the programmer wants to execute the program above in a batch application, all he or she has to do is to replace the environment via `ExecutionEnvironment` and change the output conversion from `DataStream` to `DataSet`. The Table API program itself doesn’t change.
+
+In the example, we converted the table program to a data stream of `Row` objects. However, we are not limited to row data types. The Table API supports all types from the underlying APIs such as Java and Scala Tuples, Case Classes, POJOs, or generic types that are serialized using Kryo. Let’s assume that we want to have regular object (POJO) with the following format instead of generic rows:
+
+```scala
+class Customer {
+ var id: Int = _
+ var name: String = _
+ var update: Long = _
+ var prefs: java.util.Properties = _
+}
+```
+We can use the following table program to convert the CSV file into Customer objects. Flink takes care of creating objects and mapping fields for us.
+
+```scala
+val ds = tEnv
+ .scan("customers")
+ .select('id, 'name, 'last_update as 'update, parseProperties('prefs) as 'prefs)
+ .toDataStream[Customer]
+```
+
+You might have noticed that the query above uses a function to parse the preferences field. Even though Flink’s Table API is shipped with a large set of built-in functions, is often necessary to define custom user-defined scalar functions. In the above example we use a user-defined function `parseProperties`. The following code snippet shows how easily we can implement a scalar function.
+
+```scala
+object parseProperties extends ScalarFunction {
+ def eval(str: String): Properties = {
+ val props = new Properties()
+ str
+ .split(",")
+ .map(\_.split("="))
+ .foreach(split => props.setProperty(split(0), split(1)))
+ props
+ }
+}
+```
+
+Scalar functions can be used to deserialize, extract, or convert values (and more). By overwriting the `open()` method we can even have access to runtime information such as distributed cached files or metrics. Even the `open()` method is only called once during the runtime’s [task lifecycle]({{< param DocsBaseUrl >}}flink-docs-release-1.3/internals/task_lifecycle.html).
+
+## Unified Windowing for Static and Streaming Data
+
+Another very common task, especially when working with continuous data, is the definition of windows to split a stream into pieces of finite size, over which we can apply computations. At the moment, the Table API supports three types of windows: sliding windows, tumbling windows, and session windows (for general definitions of the different types of windows, we recommend [Flink’s documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/windows.html)). All three window types work on [event or processing time]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/event_time.html). Session windows can be defined over time intervals, sliding and tumbling windows can be defined over time intervals or a number of rows.
+
+Let’s assume that our customer data from the example above is an event stream of updates generated whenever the customer updated his or her preferences. We assume that events come from a TableSource that has assigned timestamps and watermarks. The definition of a window happens again in a LINQ-style fashion. The following example could be used to count the updates to the preferences during one day.
+
+```scala
+table
+ .window(Tumble over 1.day on 'rowtime as 'w)
+ .groupBy('id, 'w)
+ .select('id, 'w.start as 'from, 'w.end as 'to, 'prefs.count as 'updates)
+```
+
+By using the `on()` parameter, we can specify whether the window is supposed to work on event-time or not. The Table API assumes that timestamps and watermarks are assigned correctly when using event-time. Elements with timestamps smaller than the last received watermark are dropped. Since the extraction of timestamps and generation of watermarks depends on the data source and requires some deeper knowledge of their origin, the TableSource or the upstream DataStream is usually responsible for assigning these properties.
+
+The following code shows how to define other types of windows:
+
+```scala
+// using processing-time
+table.window(Tumble over 100.rows as 'manyRowWindow)
+// using event-time
+table.window(Session withGap 15.minutes on 'rowtime as 'sessionWindow)
+table.window(Slide over 1.day every 1.hour on 'rowtime as 'dailyWindow)
+```
+
+Since batch is just a special case of streaming (where a batch happens to have a defined start and end point), it is also possible to apply all of these windows in a batch execution environment. Without any modification of the table program itself, we can run the code on a DataSet given that we specified a column named “rowtime”. This is particularly interesting if we want to compute exact results from time-to-time, so that late events that are heavily out-of-order can be included in the computation.
+
+At the moment, the Table API only supports so-called “group windows” that also exist in the DataStream API. Other windows such as SQL’s OVER clause windows are in development and [planned for Flink 1.3](https://cwiki.apache.org/confluence/display/FLINK/FLIP-11%3A+Table+API+Stream+Aggregations).
+
+In order to demonstrate the expressiveness and capabilities of the API, here’s a snippet with a more advanced example of an exponentially decaying moving average over a sliding window of one hour which returns aggregated results every second. The table program weighs recent orders more heavily than older orders. This example is borrowed from [Apache Calcite](https://calcite.apache.org/docs/stream.html#hopping-windows) and shows what will be possible in future Flink releases for both the Table API and SQL.
+
+```scala
+table
+ .window(Slide over 1.hour every 1.second as 'w)
+ .groupBy('productId, 'w)
+ .select(
+ 'w.end,
+ 'productId,
+ ('unitPrice * ('rowtime - 'w.start).exp() / 1.hour).sum / (('rowtime - 'w.start).exp() / 1.hour).sum)
+```
+
+## User-defined Table Functions
+
+[User-defined table functions]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/table_api.html#user-defined-table-functions) were added in Flink 1.2. These can be quite useful for table columns containing non-atomic values which need to be extracted and mapped to separate fields before processing. Table functions take an arbitrary number of scalar values and allow for returning an arbitrary number of rows as output instead of a single value, similar to a flatMap function in the DataStream or DataSet API. The output of a table function can then be joined with the original row in the table by using either a left-outer join or cross join.
+
+Using the previously-mentioned customer table, let’s assume we want to produce a table that contains the color and size preferences as separate columns. The table program would look like this:
+
+```scala
+// create an instance of the table function
+val extractPrefs = new PropertiesExtractor()
+
+// derive rows and join them with original row
+table
+ .join(extractPrefs('prefs) as ('color, 'size))
+ .select('id, 'username, 'color, 'size)
+```
+
+The `PropertiesExtractor` is a user-defined table function that extracts the color and size. We are not interested in customers that haven’t set these preferences and thus don’t emit anything if both properties are not present in the string value. Since we are using a (cross) join in the program, customers without a result on the right side of the join will be filtered out.
+
+```scala
+class PropertiesExtractor extends TableFunction[Row] {
+ def eval(prefs: String): Unit = {
+ // split string into (key, value) pairs
+ val pairs = prefs
+ .split(",")
+ .map { kv =>
+ val split = kv.split("=")
+ (split(0), split(1))
+ }
+
+ val color = pairs.find(\_.\_1 == "color").map(\_.\_2)
+ val size = pairs.find(\_.\_1 == "size").map(\_.\_2)
+
+ // emit a row if color and size are specified
+ (color, size) match {
+ case (Some(c), Some(s)) => collect(Row.of(c, s))
+ case _ => // skip
+ }
+ }
+
+ override def getResultType = new RowTypeInfo(Types.STRING, Types.STRING)
+}
+```
+
+## Conclusion
+
+There is significant interest in making streaming more accessible and easier to use. Flink’s Table API development is happening quickly, and we believe that soon, you will be able to implement large batch or streaming pipelines using purely relational APIs or even convert existing Flink jobs to table programs. The Table API is already a very useful tool since you can work around limitations and missing features at any time by switching back-and-forth between the DataSet/DataStream abstraction to the Table abstraction.
+
+Contributions like support of Apache Hive UDFs, external catalogs, more TableSources, additional windows, and more operators will make the Table API an even more useful tool. Particularly, the upcoming introduction of Dynamic Tables, which is worth a blog post of its own, shows that even in 2017, new relational APIs open the door to a number of possibilities.
+
+Try it out, or even better, join the design discussions on the [mailing lists](http://flink.apache.org/community.html#mailing-lists) and [JIRA](https://issues.apache.org/jira/browse/FLINK/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel) and start contributing!
diff --git a/docs/content.tr/posts/2017-03-30-dynamic-tables.md b/docs/content.tr/posts/2017-03-30-dynamic-tables.md
new file mode 100644
index 0000000000..198ccf1ab4
--- /dev/null
+++ b/docs/content.tr/posts/2017-03-30-dynamic-tables.md
@@ -0,0 +1,185 @@
+---
+author: Fabian Hueske, Shaoxuan Wang, and Xiaowei Jiang
+date: "2017-03-30T12:00:00Z"
+excerpt: |-
+ Flink's relational APIs, the Table API and SQL, are unified APIs for stream and batch processing, meaning that a query produces the same result when being evaluated on streaming or static data.
+ In this blog post we discuss the future of these APIs and introduce the concept of Dynamic Tables. Dynamic tables will significantly expand the scope of the Table API and SQL on streams and enable many more advanced use cases. We discuss how streams and dynamic tables relate to each other and explain the semantics of continuously evaluating queries on dynamic tables.
+title: Continuous Queries on Dynamic Tables
+aliases:
+- /news/2017/04/04/dynamic-tables.html
+---
+#### Analyzing Data Streams with SQL
+
+More and more companies are adopting stream processing and are migrating existing batch applications to streaming or implementing streaming solutions for new use cases. Many of those applications focus on analyzing streaming data. The data streams that are analyzed come from a wide variety of sources such as database transactions, clicks, sensor measurements, or IoT devices.
+
+
+
+
+
+Apache Flink is very well suited to power streaming analytics applications because it provides support for event-time semantics, stateful exactly-once processing, and achieves high throughput and low latency at the same time. Due to these features, Flink is able to compute exact and deterministic results from high-volume input streams in near real-time while providing exactly-once semantics in case of failures.
+
+Flink's core API for stream processing, the [DataStream API]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/datastream_api.html), is very expressive and provides primitives for many common operations. Among other features, it offers highly customizable windowing logic, different state primitives with varying performance characteristics, hooks to register and react on timers, and tooling for efficient asynchronous requests to external systems. On the other hand, many stream analytics applications follow similar patterns and do not require the level of expressiveness as provided by the DataStream API. They could be expressed in a more natural and concise way using a domain specific language. As we all know, SQL is the de-facto standard for data analytics. For streaming analytics, SQL would enable a larger pool of people to specify applications on data streams in less time. However, no open source stream processor offers decent SQL support yet.
+
+## Why is SQL on Streams a Big Deal?
+
+SQL is the most widely used language for data analytics for many good reasons:
+
+- SQL is declarative: You specify what you want but not how to compute it.
+- SQL can be effectively optimized: An optimizer figures out an efficient plan to compute your result.
+- SQL can be efficiently evaluated: The processing engine knows exactly what to compute and how to do so efficiently.
+- And finally, everybody knows and many tools speak SQL.
+
+So being able to process and analyze data streams with SQL makes stream processing technology available to many more users. Moreover, it significantly reduces the time and effort to define efficient stream analytics applications due to the SQL's declarative nature and potential to be automatically optimized.
+
+However, SQL (and the relational data model and algebra) were not designed with streaming data in mind. Relations are (multi-)sets and not infinite sequences of tuples. When executing a SQL query, conventional database systems and query engines read and process a data set, which is completely available, and produce a fixed sized result. In contrast, data streams continuously provide new records such that data arrives over time. Hence, streaming queries have to continuously process the arriving data and never "complete".
+
+That being said, processing streams with SQL is not impossible. Some relational database systems feature eager maintenance of materialized views, which is similar to evaluating SQL queries on streams of data. A materialized view is defined as a SQL query just like a regular (virtual) view. However, the result of the query is actually stored (or materialized) in memory or on disk such that the view does not need to be computed on-the-fly when it is queried. In order to prevent that a materialized view becomes stale, the database system needs to update the view whenever its base relations (the tables referenced in its definition query) are modified. If we consider the changes on the view's base relations as a stream of modifications (or as a changelog stream) it becomes obvious that materialized view maintenance and SQL on streams are somehow related.
+
+## Flink's Relational APIs: Table API and SQL
+
+Since version 1.1.0 (released in August 2016), Flink features two semantically equivalent relational APIs, the language-embedded Table API (for Java and Scala) and standard SQL. Both APIs are designed as unified APIs for online streaming and historic batch data. This means that,
+
+***a query produces exactly the same result regardless whether its input is static batch data or streaming data.***
+
+Unified APIs for stream and batch processing are important for several reasons. First of all, users only need to learn a single API to process static and streaming data. Moreover, the same query can be used to analyze batch and streaming data, which allows to jointly analyze historic and live data in the same query. At the current state we haven't achieved complete unification of batch and streaming semantics yet, but the community is making very good progress towards this goal.
+
+The following code snippet shows two equivalent Table API and SQL queries that compute a simple windowed aggregate on a stream of temperature sensor measurements. The syntax of the SQL query is based on [Apache Calcite's](https://calcite.apache.org) syntax for [grouped window functions](https://calcite.apache.org/docs/reference.html#grouped-window-functions) and will be supported in version 1.3.0 of Flink.
+
+```scala
+val env = StreamExecutionEnvironment.getExecutionEnvironment
+env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime)
+
+val tEnv = TableEnvironment.getTableEnvironment(env)
+
+// define a table source to read sensor data (sensorId, time, room, temp)
+val sensorTable = ??? // can be a CSV file, Kafka topic, database, or ...
+// register the table source
+tEnv.registerTableSource("sensors", sensorTable)
+
+// Table API
+val tapiResult: Table = tEnv.scan("sensors") // scan sensors table
+ .window(Tumble over 1.hour on 'rowtime as 'w) // define 1-hour window
+ .groupBy('w, 'room) // group by window and room
+ .select('room, 'w.end, 'temp.avg as 'avgTemp) // compute average temperature
+
+// SQL
+val sqlResult: Table = tEnv.sql("""
+ |SELECT room, TUMBLE_END(rowtime, INTERVAL '1' HOUR), AVG(temp) AS avgTemp
+ |FROM sensors
+ |GROUP BY TUMBLE(rowtime, INTERVAL '1' HOUR), room
+ |""".stripMargin)
+```
+
+As you can see, both APIs are tightly integrated with each other and Flink's primary [DataStream]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/datastream_api.html) and [DataSet]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/batch/index.html) APIs. A `Table` can be generated from and converted to a `DataSet` or `DataStream`. Hence, it is easily possible to scan an external table source such as a database or [Parquet](https://parquet.apache.org) file, do some preprocessing with a Table API query, convert the result into a `DataSet` and run a [Gelly]({{< param DocsBaseUrl >}}flink-docs-release-1.2/dev/libs/gelly/index.html) graph algorithm on it. The queries defined in the example above can also be used to process batch data by changing the execution environment.
+
+Internally, both APIs are translated into the same logical representation, optimized by Apache Calcite, and compiled into DataStream or DataSet programs. In fact, the optimization and translation process does not know whether a query was defined using the Table API or SQL. If you are curious about the details of the optimization process, have a look at [a blog post](http://flink.apache.org/news/2016/05/24/stream-sql.html) that we published last year. Since the Table API and SQL are equivalent in terms of semantics and only differ in syntax, we always refer to both APIs when we talk about SQL in this post.
+
+In its current state (version 1.2.0), Flink's relational APIs support a limited set of relational operators on data streams, including projections, filters, and windowed aggregates. All supported operators have in common that they never update result records which have been emitted. This is clearly not an issue for record-at-a-time operators such as projection and filter. However, it affects operators that collect and process multiple records as for instance windowed aggregates. Since emitted results cannot be updated, input records, which arrive after a result has been emitted, have to be discarded in Flink 1.2.0.
+
+The limitations of the current version are acceptable for applications that emit data to storage systems such as Kafka topics, message queues, or files which only support append operations and no updates or deletes. Common use cases that follow this pattern are for example continuous ETL and stream archiving applications that persist streams to an archive or prepare data for further online (streaming) analysis or later offline analysis. Since it is not possible to update previously emitted results, these kinds of applications have to make sure that the emitted results are correct and will not need to be corrected in the future. The following figure illustrates such applications.
+
+
+
+
+
+While queries that only support appends are useful for some kinds of applications and certain types of storage systems, there are many streaming analytics use cases that need to update results. This includes streaming applications that cannot discard late arriving records, need early results for (long-running) windowed aggregates, or require non-windowed aggregates. In each of these cases, previously emitted result records need to be updated. Result-updating queries often materialize their result to an external database or key-value store in order to make it accessible and queryable for external applications. Applications that implement this pattern are dashboards, reporting applications, or [other applications](http://2016.flink-forward.org/kb_sessions/joining-infinity-windowless-stream-processing-with-flink/), which require timely access to continuously updated results. The following figure illustrates these kind of applications.
+
+
+
+
+
+## Continuous Queries on Dynamic Tables
+
+Support for queries that update previously emitted results is the next big step for Flink's relational APIs. This feature is so important because it vastly increases the scope of the APIs and the range of supported use cases. Moreover, many of the newly supported use cases can be challenging to implement using the DataStream API.
+
+So when adding support for result-updating queries, we must of course preserve the unified semantics for stream and batch inputs. We achieve this by the concept of *Dynamic Tables*. A dynamic table is a table that is continuously updated and can be queried like a regular, static table. However, in contrast to a query on a batch table which terminates and returns a static table as result, a query on a dynamic table runs continuously and produces a table that is continuously updated depending on the modification on the input table. Hence, the resulting table is a dynamic table as well. This concept is very similar to materialized view maintenance as we discussed before.
+
+Assuming we can run queries on dynamic tables which produce new dynamic tables, the next question is, How do streams and dynamic tables relate to each other? The answer is that streams can be converted into dynamic tables and dynamic tables can be converted into streams. The following figure shows the conceptual model of processing a relational query on a stream.
+
+
+
+
+
+First, the stream is converted into a dynamic table. The dynamic table is queried with a continuous query, which produces a new dynamic table. Finally, the resulting table is converted back into a stream. It is important to note that this is only the logical model and does not imply how the query is actually executed. In fact, a continuous query is internally translated into a conventional DataStream program.
+
+In the following, we describe the different steps of this model:
+
+1. Defining a dynamic table on a stream,
+2. Querying a dynamic table, and
+3. Emitting a dynamic table.
+
+## Defining a Dynamic Table on a Stream
+
+The first step of evaluating a SQL query on a dynamic table is to define a dynamic table on a stream. This means we have to specify how the records of a stream modify the dynamic table. The stream must carry records with a schema that is mapped to the relational schema of the table. There are two modes to define a dynamic table on a stream: *Append Mode* and *Update Mode*.
+
+In append mode each stream record is an insert modification to the dynamic table. Hence, all records of a stream are appended to the dynamic table such that it is ever-growing and infinite in size. The following figure illustrates the append mode.
+
+
+
+
+
+In update mode a stream record can represent an insert, update, or delete modification on the dynamic table (append mode is in fact a special case of update mode). When defining a dynamic table on a stream via update mode, we can specify a unique key attribute on the table. In that case, update and delete operations are performed with respect to the key attribute. The update mode is visualized in the following figure.
+
+
+
+
+
+## Querying a Dynamic Table
+
+Once we have defined a dynamic table, we can run a query on it. Since dynamic tables change over time, we have to define what it means to query a dynamic table. Let's imagine we take a snapshot of a dynamic table at a specific point in time. This snapshot can be treated as a regular static batch table. We denote a snapshot of a dynamic table *A* at a point *t* as *A[t]*. The snapshot can be queried with any SQL query. The query produces a regular static table as result. We denote the result of a query *q* on a dynamic table *A* at time *t* as *q(A[t])*. If we repeatedly compute the result of a query on snapshots of a dynamic table for progressing points in time, we obtain many static result tables which are changing over time and effectively constitute a dynamic table. We define the semantics of a query on a dynamic table as follows.
+
+A query *q* on a dynamic table *A* produces a dynamic table *R*, which is at each point in time *t* equivalent to the result of applying *q* on *A[t]*, i.e., *R[t] = q(A[t])*. This definition implies that running the same query on *q* on a batch table and on a streaming table produces the same result. In the following, we show two examples to illustrate the semantics of queries on dynamic tables.
+
+In the figure below, we see a dynamic input table *A* on the left side, which is defined in append mode. At time *t = 8*, *A* consists of six rows (colored in blue). At time *t = 9* and *t = 12*, one row is appended to *A* (visualized in green and orange, respectively). We run a simple query on table *A* which is shown in the center of the figure. The query groups by attribute *k* and counts the records per group. On the right hand side we see the result of query *q* at time *t = 8* (blue), *t = 9* (green), and *t = 12* (orange). At each point in time t, the result table is equivalent to a batch query on the dynamic table *A* at time *t*.
+
+
+
+
+
+The query in this example is a simple grouped (but not windowed) aggregation query. Hence, the size of the result table depends on the number of distinct grouping keys of the input table. Moreover, it is worth noticing that the query continuously updates result rows that it had previously emitted instead of merely adding new rows.
+
+The second example shows a similar query which differs in one important aspect. In addition to grouping on the key attribute *k*, the query also groups records into tumbling windows of five seconds, which means that it computes a count for each value of *k* every five seconds. Again, we use Calcite's [group window functions](https://calcite.apache.org/docs/reference.html#grouped-window-functions) to specify this query. On the left side of the figure we see the input table *A* and how it changes over time in append mode. On the right we see the result table and how it evolves over time.
+
+
+
+
+
+In contrast to the result of the first example, the resulting table grows relative to the time, i.e., every five seconds new result rows are computed (given that the input table received more records in the last five seconds). While the non-windowed query (mostly) updates rows of the result table, the windowed aggregation query only appends new rows to the result table.
+
+Although this blog post focuses on the semantics of SQL queries on dynamic tables and not on how to efficiently process such a query, we'd like to point out that it is not possible to compute the complete result of a query from scratch whenever an input table is updated. Instead, the query is compiled into a streaming program which continuously updates its result based on the changes on its input. This implies that not all valid SQL queries are supported but only those that can be continuously, incrementally, and efficiently computed. We plan discuss details about the evaluation of SQL queries on dynamic tables in a follow up blog post.
+
+## Emitting a Dynamic Table
+
+Querying a dynamic table yields another dynamic table, which represents the query's results. Depending on the query and its input tables, the result table is continuously modified by insert, update, and delete changes just like a regular database table. It might be a table with a single row, which is constantly updated, an insert-only table without update modifications, or anything in between.
+
+Traditional database systems use logs to rebuild tables in case of failures and for replication. There are different logging techniques, such as UNDO, REDO, and UNDO/REDO logging. In a nutshell, UNDO logs record the previous value of a modified element to revert incomplete transactions, REDO logs record the new value of a modified element to redo lost changes of completed transactions, and UNDO/REDO logs record the old and the new value of a changed element to undo incomplete transactions and redo lost changes of completed transactions. Based on the principles of these logging techniques, a dynamic table can be converted into two types of changelog streams, a *REDO Stream* and a *REDO+UNDO Stream*.
+
+A dynamic table is converted into a redo+undo stream by converting the modifications on the table into stream messages. An insert modification is emitted as an insert message with the new row, a delete modification is emitted as a delete message with the old row, and an update modification is emitted as a delete message with the old row and an insert message with the new row. This behavior is illustrated in the following figure.
+
+
+
+
+
+The left shows a dynamic table which is maintained in append mode and serves as input to the query in the center. The result of the query converted into a redo+undo stream which is shown at the bottom. The first record *(1, A)* of the input table results in a new record in the result table and hence in an insert message *+(A, 1)* to the stream. The second input record with *k = 'A'* *(4, A)* produces an update of the *(A, 1)* record in the result table and hence yields a delete message *-(A, 1)* and an insert message for *+(A, 2)*. All downstream operators or data sinks need to be able to correctly handle both types of messages.
+
+A dynamic table can be converted into a redo stream in two cases: either it is an append-only table (i.e., it only has insert modifications) or it has a unique key attribute. Each insert modification on the dynamic table results in an insert message with the new row to the redo stream. Due to the restriction of redo streams, only tables with unique keys can have update and delete modifications. If a key is removed from the keyed dynamic table, either because a row is deleted or because the key attribute of a row was modified, a delete message with the removed key is emitted to the redo stream. An update modification yields an update message with the updating, i.e., new row. Since delete and update modifications are defined with respect to the unique key, the downstream operators need to be able to access previous values by key. The figure below shows how the result table of the same query as above is converted into a redo stream.
+
+
+
+
+
+The row *(1, A)* which yields an insert into the dynamic table results in the *+(A, 1)* insert message. The row *(4, A)* which produces an update yields the **(A, 2)* update message.
+
+Common use cases for redo streams are to write the result of a query to an append-only storage system, like rolling files or a Kafka topic, or to a data store with keyed access, such as Cassandra, a relational DBMS, or a compacted Kafka topic. It is also possible to materialize a dynamic table as keyed state inside of the streaming application that evaluates the continuous query and make it queryable from external systems. With this design Flink itself maintains the result of a continuous SQL query on a stream and serves key lookups on the result table, for instance from a dashboard application.
+
+## What will Change When Switching to Dynamic Tables?
+
+In version 1.2, all streaming operators of Flink's relational APIs, like filter, project, and group window aggregates, only emit new rows and are not capable of updating previously emitted results. In contrast, dynamic table are able to handle update and delete modifications. Now you might ask yourself, How does the processing model of the current version relate to the new dynamic table model? Will the semantics of the APIs completely change and do we need to reimplement the APIs from scratch to achieve the desired semantics?
+
+The answer to all these questions is simple. The current processing model is a subset of the dynamic table model. Using the terminology we introduced in this post, the current model converts a stream into a dynamic table in append mode, i.e., an infinitely growing table. Since all operators only accept insert changes and produce insert changes on their result table (i.e., emit new rows), all supported queries result in dynamic append tables, which are converted back into DataStreams using the redo model for append-only tables. Consequently, the semantics of the current model are completely covered and preserved by the new dynamic table model.
+
+## Conclusion and Outlook
+
+Flink's relational APIs are great to implement stream analytics applications in no time and used in several production settings. In this blog post we discussed the future of the Table API and SQL. This effort will make Flink and stream processing accessible to more people. Moreover, the unified semantics for querying historic and real-time data as well as the concept of querying and maintaining dynamic tables will enable and significantly ease the implementation of many exciting use cases and applications. As this post was focusing on the semantics of relational queries on streams and dynamic tables, we did not discuss the details of how a query will be executed, which includes the internal implementation of retractions, handling of late events, support for early results, and bounding space requirements. We plan to publish a follow up blog post on this topic at a later point in time.
+
+In recent months, many members of the Flink community have been discussing and contributing to the relational APIs. We made great progress so far. While most work has focused on processing streams in append mode, the next steps on the agenda are to work on dynamic tables to support queries that update their results. If you are excited about the idea of processing streams with SQL and would like to contribute to this effort, please give feedback, join the discussions on the mailing list, or grab a JIRA issue to work on.
diff --git a/docs/content.tr/posts/2017-04-26-release-1.2.1.md b/docs/content.tr/posts/2017-04-26-release-1.2.1.md
new file mode 100644
index 0000000000..39f7301cff
--- /dev/null
+++ b/docs/content.tr/posts/2017-04-26-release-1.2.1.md
@@ -0,0 +1,219 @@
+---
+date: "2017-04-26T18:00:00Z"
+title: Apache Flink 1.2.1 Released
+aliases:
+- /news/2017/04/26/release-1.2.1.html
+---
+
+The Apache Flink community released the first bugfix version of the Apache Flink 1.2 series.
+
+This release includes many critical fixes for Flink 1.2.0. The list below includes a detailed list of all fixes.
+
+We highly recommend all users to upgrade to Flink 1.2.1.
+
+Please note that there are two unresolved major issues in Flink 1.2.1 and 1.2.0:
+
+- [FLINK-6353](https://issues.apache.org/jira/browse/FLINK-6353) Restoring using CheckpointedRestoring does not work from 1.2 to 1.2
+- [FLINK-6188](https://issues.apache.org/jira/browse/FLINK-6188) Some setParallelism() methods can't cope with default parallelism
+
+
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.2.1
+
+
+ org.apache.flink
+ flink-streaming-java_2.10
+ 1.2.1
+
+
+ org.apache.flink
+ flink-clients_2.10
+ 1.2.1
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+
+Release Notes - Flink - Version 1.2.1
+
+
+ Sub-task
+
+
+[FLINK-5546 ] - java.io.tmpdir setted as project build directory in surefire plugin
+
+[FLINK-5640 ] - configure the explicit Unit Test file suffix
+
+[FLINK-5723 ] - Use "Used" instead of "Initial" to make taskmanager tag more readable
+
+[FLINK-5825 ] - In yarn mode, a small pic can not be loaded
+
+
+
+ Bug
+
+
+[FLINK-4813 ] - Having flink-test-utils as a dependency outside Flink fails the build
+
+[FLINK-4848 ] - keystoreFilePath should be checked against null in SSLUtils#createSSLServerContext
+
+[FLINK-5628 ] - CheckpointStatsTracker implements Serializable but isn't
+
+[FLINK-5644 ] - Task#lastCheckpointSize metric broken
+
+[FLINK-5650 ] - Flink-python tests executing cost too long time
+
+[FLINK-5652 ] - Memory leak in AsyncDataStream
+
+[FLINK-5669 ] - flink-streaming-contrib DataStreamUtils.collect in local environment mode fails when offline
+
+[FLINK-5678 ] - User-defined TableFunctions do not support all types of parameters
+
+[FLINK-5699 ] - Cancel with savepoint fails with a NPE if savepoint target directory not set
+
+[FLINK-5701 ] - FlinkKafkaProducer should check asyncException on checkpoints
+
+[FLINK-5708 ] - we should remove duplicated configuration options
+
+[FLINK-5732 ] - Java quick start mvn command line is incorrect
+
+[FLINK-5749 ] - unset HADOOP_HOME and HADOOP_CONF_DIR to avoid env in build machine failing the UT and IT
+
+[FLINK-5751 ] - 404 in documentation
+
+[FLINK-5771 ] - DelimitedInputFormat does not correctly handle multi-byte delimiters
+
+[FLINK-5773 ] - Cannot cast scala.util.Failure to org.apache.flink.runtime.messages.Acknowledge
+
+[FLINK-5806 ] - TaskExecutionState toString format have wrong key
+
+[FLINK-5814 ] - flink-dist creates wrong symlink when not used with cleaned before
+
+[FLINK-5817 ] - Fix test concurrent execution failure by test dir conflicts.
+
+[FLINK-5828 ] - BlobServer create cache dir has concurrency safety problem
+
+[FLINK-5885 ] - Java code snippet instead of scala in documentation
+
+[FLINK-5907 ] - RowCsvInputFormat bug on parsing tsv
+
+[FLINK-5934 ] - Scheduler in ExecutionGraph null if failure happens in ExecutionGraph.restoreLatestCheckpointedState
+
+[FLINK-5940 ] - ZooKeeperCompletedCheckpointStore cannot handle broken state handles
+
+[FLINK-5942 ] - Harden ZooKeeperStateHandleStore to deal with corrupted data
+
+[FLINK-5945 ] - Close function in OuterJoinOperatorBase#executeOnCollections
+
+[FLINK-5949 ] - Flink on YARN checks for Kerberos credentials for non-Kerberos authentication methods
+
+[FLINK-5962 ] - Cancel checkpoint canceller tasks in CheckpointCoordinator
+
+[FLINK-5965 ] - Typo on DropWizard wrappers
+
+[FLINK-5972 ] - Don't allow shrinking merging windows
+
+[FLINK-5985 ] - Flink treats every task as stateful (making topology changes impossible)
+
+[FLINK-6000 ] - Can not start HA cluster with start-cluster.sh
+
+[FLINK-6001 ] - NPE on TumblingEventTimeWindows with ContinuousEventTimeTrigger and allowedLateness
+
+[FLINK-6002 ] - Documentation: 'MacOS X' under 'Download and Start Flink' in Quickstart page is not rendered correctly
+
+[FLINK-6006 ] - Kafka Consumer can lose state if queried partition list is incomplete on restore
+
+[FLINK-6025 ] - User code ClassLoader not used when KryoSerializer fallbacks to serialization for copying
+
+[FLINK-6051 ] - Wrong metric scope names in documentation
+
+[FLINK-6084 ] - Cassandra connector does not declare all dependencies
+
+[FLINK-6133 ] - fix build status in README.md
+
+[FLINK-6170 ] - Some checkpoint metrics rely on latest stat snapshot
+
+[FLINK-6181 ] - Zookeeper scripts use invalid regex
+
+[FLINK-6182 ] - Fix possible NPE in SourceStreamTask
+
+[FLINK-6183 ] - TaskMetricGroup may not be cleanup when Task.run() is never called or exits early
+
+[FLINK-6184 ] - Buffer metrics can cause NPE
+
+[FLINK-6203 ] - DataSet Transformations
+
+[FLINK-6207 ] - Duplicate type serializers for async snapshots of CopyOnWriteStateTable
+
+[FLINK-6308 ] - Task managers are not attaching to job manager on macos
+
+
+
+ Improvement
+
+
+[FLINK-4326 ] - Flink start-up scripts should optionally start services on the foreground
+
+[FLINK-5217 ] - Deprecated interface Checkpointed make clear suggestion
+
+[FLINK-5331 ] - PythonPlanBinderTest idling extremely long
+
+[FLINK-5581 ] - Improve Kerberos security related documentation
+
+[FLINK-5639 ] - Clarify License implications of RabbitMQ Connector
+
+[FLINK-5680 ] - Document env.ssh.opts
+
+[FLINK-5681 ] - Make ReaperThread for SafetyNetCloseableRegistry a singleton
+
+[FLINK-5702 ] - Kafka Producer docs should warn if using setLogFailuresOnly, at-least-once is compromised
+
+[FLINK-5705 ] - webmonitor's request/response use UTF-8 explicitly
+
+[FLINK-5713 ] - Protect against NPE in WindowOperator window cleanup
+
+[FLINK-5721 ] - Add FoldingState to State Documentation
+
+[FLINK-5800 ] - Make sure that the CheckpointStreamFactory is instantiated once per operator only
+
+[FLINK-5805 ] - improve docs for ProcessFunction
+
+[FLINK-5807 ] - improved wording for doc home page
+
+[FLINK-5837 ] - improve readability of the queryable state docs
+
+[FLINK-5876 ] - Mention Scala type fallacies for queryable state client serializers
+
+[FLINK-5877 ] - Fix Scala snippet in Async I/O API doc
+
+[FLINK-5894 ] - HA docs are misleading re: state backends
+
+[FLINK-5895 ] - Reduce logging aggressiveness of FileSystemSafetyNet
+
+[FLINK-5938 ] - Replace ExecutionContext by Executor in Scheduler
+
+[FLINK-6212 ] - Missing reference to flink-avro dependency
+
+
+
+ New Feature
+
+
+[FLINK-6139 ] - Documentation for building / preparing Flink for MapR
+
+
+
+ Task
+
+
+[FLINK-2883 ] - Add documentation to forbid key-modifying ReduceFunction
+
+[FLINK-3903 ] - Homebrew Installation
+
+
+
\ No newline at end of file
diff --git a/docs/content.tr/posts/2017-05-16-official-docker-image.md b/docs/content.tr/posts/2017-05-16-official-docker-image.md
new file mode 100644
index 0000000000..ad3777cc29
--- /dev/null
+++ b/docs/content.tr/posts/2017-05-16-official-docker-image.md
@@ -0,0 +1,28 @@
+---
+author: Patrick Lucas (Data Artisans) and Ismaël Mejía (Talend)
+author-twitter: iemejia
+date: "2017-05-16T09:00:00Z"
+title: Introducing Docker Images for Apache Flink
+aliases:
+- /news/2017/05/16/official-docker-image.html
+---
+
+For some time, the Apache Flink community has provided scripts to build a Docker image to run Flink. Now, starting with version 1.2.1, Flink will have a [Docker image](https://hub.docker.com/r/_/flink/) on the Docker Hub. This image is maintained by the Flink community and curated by the [Docker](https://github.com/docker-library/official-images) team to ensure it meets the quality standards for container images of the Docker community.
+
+A community-maintained way to run Apache Flink on Docker and other container runtimes and orchestrators is part of the ongoing effort by the Flink community to make Flink a first-class citizen of the container world.
+
+If you want to use the Docker image today you can get the latest version by running:
+
+ docker pull flink
+
+And to run a local Flink cluster with one TaskManager and the Web UI exposed on port 8081, run:
+
+ docker run -t -p 8081:8081 flink local
+
+With this image there are various ways to start a Flink cluster, both locally and in a distributed environment. Take a look at the [documentation](https://hub.docker.com/r/_/flink/) that shows how to run a Flink cluster with multiple TaskManagers locally using Docker Compose or across multiple machines using Docker Swarm. You can also use the examples as a reference to create configurations for other platforms like Mesos and Kubernetes.
+
+While this announcement is an important milestone, it’s just the first step to help users run containerized Flink in production. There are [improvements](https://issues.apache.org/jira/issues/?jql=project%20%3D%20FLINK%20AND%20component%20%3D%20Docker%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC) to be made in Flink itself and we will continue to improve these Docker images and for the documentation and examples surrounding them.
+
+This is of course a team effort, so any contribution is welcome. The [docker-flink](https://github.com/docker-flink) GitHub organization hosts the source files to [generate the images](https://github.com/docker-flink/docker-flink) and the [documentation](https://github.com/docker-flink/docs/tree/master/flink) that is presented alongside the images on Docker Hub.
+
+*Disclaimer: The docker images are provided as a community project by individuals on a best-effort basis. They are not official releases by the Apache Flink PMC.*
\ No newline at end of file
diff --git a/docs/content.tr/posts/2017-06-01-release-1.3.0.md b/docs/content.tr/posts/2017-06-01-release-1.3.0.md
new file mode 100644
index 0000000000..2c9227542c
--- /dev/null
+++ b/docs/content.tr/posts/2017-06-01-release-1.3.0.md
@@ -0,0 +1,129 @@
+---
+author: Robert Metzger
+author-twitter: rmetzger_
+date: "2017-06-01T12:00:00Z"
+title: Apache Flink 1.3.0 Release Announcement
+aliases:
+- /news/2017/06/01/release-1.3.0.html
+---
+
+
+The Apache Flink community is pleased to announce the 1.3.0 release. Over the past 4 months, the Flink community has been working hard to resolve more than 680 issues. See the [complete changelog](/blog/release_1.3.0-changelog.html) for more detail.
+
+This is the fourth major release in the 1.x.y series. It is API compatible with the other 1.x.y releases for APIs annotated with the @Public annotation.
+
+Users can expect Flink releases now in a 4 month cycle. At the beginning of the 1.3 [release cycle](https://cwiki.apache.org/confluence/display/FLINK/Flink+Release+and+Feature+Plan), the community decided to follow a strict [time-based release model](https://cwiki.apache.org/confluence/display/FLINK/Time-based+releases).
+
+We encourage everyone to download the release and check out the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.3/). Feedback through the [Flink mailing lists](http://flink.apache.org/community.html#mailing-lists) is, as always, gladly encouraged!
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html). Some highlights of the release are listed below.
+
+
+
+# Large State Handling/Recovery
+
+* **Incremental Checkpointing for RocksDB**: It is now possible to checkpoint only the difference from the previous successful checkpoint, rather than checkpointing the entire application state. This speeds up checkpointing and saves disk space, because the individual checkpoints are smaller. ([FLINK-5053](https://issues.apache.org/jira/browse/FLINK-5053)).
+
+* **Asynchronous snapshots for heap-based state backends**: The filesystem and memory statebackends now also support asynchronous snapshots using a copy-on-write HashMap implementation. Asynchronous snapshotting makes Flink more resilient to slow storage systems and expensive serialization. The time an operator blocks on a snapshot is reduced to a minimum ([FLINK-6048](https://issues.apache.org/jira/browse/FLINK-6048), [FLINK-5715](https://issues.apache.org/jira/browse/FLINK-5715)).
+
+* **Allow upgrades to state serializers:** Users can now upgrade serializers, while keeping their application state. One use case of this is upgrading custom serializers used for managed operator state/keyed state. Also, registration order for POJO types/Kryo types is now no longer fixed ([Documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.3/dev/stream/state.html#custom-serialization-for-managed-state), [FLINK-6178](https://issues.apache.org/jira/browse/FLINK-6178)).
+
+* **Recover job state at the granularity of operator**: Before Flink 1.3, operator state was bound to Flink’s internal "Task" representation. This made it hard to change a job’s topology while keeping its state around. With this change, users are allowed to do more topology changes (un-chain operators) by restoring state into logical operators instead of “Tasks” ([FLINK-5892](https://issues.apache.org/jira/browse/FLINK-5892)).
+
+* **Fine-grained recovery** (beta): Instead of restarting the complete ExecutionGraph in case of a task failure, Flink is now able to restart only the affected subgraph and thereby significantly decrease recovery time ([FLINK-4256](https://issues.apache.org/jira/browse/FLINK-4256)).
+
+# DataStream API
+
+* **Side Outputs**: This change allows users to have more than one output stream for an operator. Operator metadata, internal system information (debugging, performance etc.) or rejected/late elements are potential use-cases for this new API feature. **The Window operator is now using this new feature for late window elements** ([Side Outputs Documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.3/dev/stream/side_output.html), [FLINK-4460](https://issues.apache.org/jira/browse/FLINK-4460)).
+
+* **Union Operator State**: Flink 1.2.0 introduced broadcast state functionality, but this had not yet been exposed via a public API. Flink 1.3.0 provides the Union Operator State API for exposing broadcast operator state. The union state will send the entire state across all parallel instances to each instance on restore, giving each operator a full view of the state ([FLINK-5991](https://issues.apache.org/jira/browse/FLINK-5991)).
+
+* **Per-Window State**: Previously, the state that a WindowFunction or ProcessWindowFunction could access was scoped to the key of the window but not the window itself. With this new feature, users can keep window state independent of the key ([FLINK-5929](https://issues.apache.org/jira/browse/FLINK-5929)).
+
+# Deployment and Tooling
+
+* **Flink HistoryServer**: Flink’s [HistoryServer]({{< param DocsBaseUrl >}}flink-docs-release-1.3/monitoring/historyserver.html) now allows you to query the status and statistics of completed jobs that have been archived by a JobManager ([FLINK-1579](https://issues.apache.org/jira/browse/FLINK-1579)).
+
+* **Watermark Monitoring in Web Front-end**: For easier diagnosis of watermark issues, the Flink JobManager front-end now provides a new tab to track the watermark of each operator ([FLINK-3427](https://issues.apache.org/jira/browse/FLINK-3427)).
+
+* **Datadog HTTP Metrics Reporter**: Datadog is a widely-used metrics system, and Flink now offers a [Datadog reporter]({{< param DocsBaseUrl >}}flink-docs-release-1.3/monitoring/metrics.html#datadog-orgapacheflinkmetricsdatadogdatadoghttpreporter) that contacts the Datadog http endpoint directly ([FLINK-6013](https://issues.apache.org/jira/browse/FLINK-6013)).
+
+* **Network Buffer Configuration**: We finally got rid of the tedious network buffer configuration and replaced it with a more generic approach. First of all, you may now follow the idiom "more is better" without any penalty on the latency which could previously occur due to excessive buffering in incoming and outgoing channels. Secondly, instead of defining an absolute number of network buffers, we now use fractions of the available JVM memory (10% by default). This should cover more use cases by default and may also be tweaked by defining a minimum and maximum size.
+
+ → See [Configuring the Network Buffers]({{< param DocsBaseUrl >}}flink-docs-release-1.3/setup/config.html#configuring-the-network-buffers) in the Flink documentation.
+
+# Table API / SQL
+
+* **Support for Retractions in Table API / SQL**: As part of our endeavor to support continuous queries on [Dynamic Tables](http://flink.apache.org/news/2017/04/04/dynamic-tables.html), Retraction is an important building block that will enable a whole range of new applications which require updating previously-emitted results. Examples for such use cases are computation of early results for long-running windows, updates due to late arriving data, or maintaining constantly changing results similar to materialized views in relational database systems. Flink 1.3.0 supports retraction for non-windowed aggregates. Results with updates can be either converted into a DataStream or materialized to external data stores using TableSinks with upsert or retraction support.
+
+* **Extended support for aggregations in Table API / SQL**: With Flink 1.3.0, the Table API and SQL support many more types of aggregations, including
+ * GROUP BY window aggregations in SQL (via the window functions [TUMBLE, HOP, and SESSION windows](https://issues.apache.org/jira/browse/FLINK-6011)) for both batch and streaming.
+
+ * SQL OVER window aggregations (only for streaming)
+
+ * Non-windowed aggregations (in streaming with retractions).
+
+ * User-defined aggregation functions for custom aggregation logic.
+
+* **External catalog support**: The Table API & SQL allows to register external catalogs. Table API and SQL queries can then have access to table sources and their schema from the external catalogs without register those tables one by one.
+
+→ See [the Flink documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.3/dev/table_api.html#group-windows) for details about these features.
+
+
+ The Table API / SQL documentation is currently being reworked. The community plans to publish the updated docs in the week of June 5th.
+
+
+# Connectors
+
+* **ElasticSearch 5.x support**: The ElasticSearch connectors have been restructured to have a common base module and specific modules for ES 1, 2 and 5, similar to how the Kafka connectors are organized. This will make fixes and future improvements available across all ES versions ([FLINK-4988](https://issues.apache.org/jira/browse/FLINK-4988)).
+
+* **Allow rescaling the Kinesis Consumer**: Flink 1.2.0 introduced rescalable state for DataStream programs. With Flink 1.3, the Kinesis Consumer also makes use of that engine feature ([FLINK-4821](https://issues.apache.org/jira/browse/FLINK-4821)).
+
+* **Transparent shard discovery for Kinesis Consumer**: The Kinesis consumer can now discover new shards without failing / restarting jobs when a resharding is happening ([FLINK-4577](https://issues.apache.org/jira/browse/FLINK-4577)).
+
+* **Allow setting custom start positions for the Kafka consumer**: With this change, you can instruct Flink’s Kafka consumer to start reading messages from a specific offset ([FLINK-3123](https://issues.apache.org/jira/browse/FLINK-3123)) or earliest / latest offset ([FLINK-4280](https://issues.apache.org/jira/browse/FLINK-4280)) without respecting committed offsets in Kafka.
+
+* **Allow out-opt from offset committing for the Kafka consumer**: By default, Kafka commits the offsets to the Kafka broker once a checkpoint has been completed. This change allows users to disable this mechanism ([FLINK-3398](https://issues.apache.org/jira/browse/FLINK-3398)).
+
+# CEP Library
+
+The CEP library has been greatly enhanced and is now able to accommodate more use-cases out-of-the-box (expressivity enhancements), make more efficient use of the available resources, adjust to changing runtime conditions--all without breaking backwards compatibility of operator state.
+
+Please note that the API of the CEP library has been updated with this release.
+
+Below are some of the main features of the revamped CEP library:
+
+* **Make CEP operators rescalable**: Flink 1.2.0 introduced rescalable state for DataStream programs. With Flink 1.3, the CEP library also makes use of that engine feature ([FLINK-5420](https://issues.apache.org/jira/browse/FLINK-5420)).
+
+
+* **New operators for the CEP library**:
+
+ * Quantifiers (*,+,?) for the pattern API ([FLINK-3318](https://issues.apache.org/jira/browse/FLINK-3318))
+
+ * Support for different continuity requirements ([FLINK-6208](https://issues.apache.org/jira/browse/FLINK-6208))
+
+ * Support for iterative conditions ([FLINK-6197](https://issues.apache.org/jira/browse/FLINK-6197))
+
+# Gelly Library
+
+* Unified driver for running Gelly examples [FLINK-4949](https://issues.apache.org/jira/browse/FLINK-4949)).
+* PageRank algorithm for directed graphs ([FLINK-4896](https://issues.apache.org/jira/browse/FLINK-4896)).
+* Add Circulant and Echo graph generators ([FLINK-6393](https://issues.apache.org/jira/browse/FLINK-6393)).
+
+# Known Issues
+
+
+ There are two
known issues in Flink 1.3.0. Both will be addressed in the
1.3.1 release.
+
+
+ FLINK-6783 : Wrongly extracted TypeInformations for WindowedStream::aggregate
+ FLINK-6775 : StateDescriptor cannot be shared by multiple subtasks
+
+
+
+# List of Contributors
+
+According to git shortlog, the following 103 people contributed to the 1.3.0 release. Thank you to all contributors!
+
+Addison Higham, Alexey Diomin, Aljoscha Krettek, Andrea Sella, Andrey Melentyev, Anton Mushin, barcahead, biao.liub, Bowen Li, Chen Qin, Chico Sokol, David Anderson, Dawid Wysakowicz, DmytroShkvyra, Fabian Hueske, Fabian Wollert, fengyelei, Flavio Pompermaier, FlorianFan, Fokko Driesprong, Geoffrey Mon, godfreyhe, gosubpl, Greg Hogan, guowei.mgw, hamstah, Haohui Mai, Hequn Cheng, hequn.chq, heytitle, hongyuhong, Jamie Grier, Jark Wu, jingzhang, Jinkui Shi, Jin Mingjian, Joerg Schad, Joshua Griffith, Jürgen Thomann, kaibozhou, Kathleen Sharp, Ken Geis, kkloudas, Kurt Young, lincoln-lil, lingjinjiang, liuyuzhong7, Lorenz Buehmann, manuzhang, Marc Tremblay, Mauro Cortellazzi, Max Kuklinski, mengji.fy, Mike Dias, mtunique, Nico Kruber, Omar Erminy, Patrick Lucas, paul, phoenixjiangnan, rami-alisawi, Ramkrishna, Rick Cox, Robert Metzger, Rodrigo Bonifacio, rtudoran, Seth Wiesman, Shaoxuan Wang, shijinkui, shuai.xus, Shuyi Chen, spkavuly, Stefano Bortoli, Stefan Richter, Stephan Ewen, Stephen Gran, sunjincheng121, tedyu, Till Rohrmann, tonycox, Tony Wei, twalthr, Tzu-Li (Gordon) Tai, Ufuk Celebi, Ventura Del Monte, Vijay Srinivasaraghavan, WangTaoTheTonic, wenlong.lwl, xccui, xiaogang.sxg, Xpray, zcb, zentol, zhangminglei, Zhenghua Gao, Zhijiang, Zhuoluo Yang, zjureel, Zohar Mizrahi, 士远, 槿瑜, 淘江, 金竹
+
diff --git a/docs/content.tr/posts/2017-06-23-release-1.3.1.md b/docs/content.tr/posts/2017-06-23-release-1.3.1.md
new file mode 100644
index 0000000000..832f313b29
--- /dev/null
+++ b/docs/content.tr/posts/2017-06-23-release-1.3.1.md
@@ -0,0 +1,153 @@
+---
+date: "2017-06-23T16:00:00Z"
+title: Apache Flink 1.3.1 Released
+aliases:
+- /news/2017/06/23/release-1.3.1.html
+---
+
+The Apache Flink community released the first bugfix version of the Apache Flink 1.3 series.
+
+This release includes 50 fixes and minor improvements for Flink 1.3.0. The list below includes a detailed list of all fixes.
+
+We highly recommend all users to upgrade to Flink 1.3.1.
+
+
+
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.3.1
+
+
+ org.apache.flink
+ flink-streaming-java_2.10
+ 1.3.1
+
+
+ org.apache.flink
+ flink-clients_2.10
+ 1.3.1
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+
+
+ Bug
+
+
+[FLINK-6492 ] - Unclosed DataOutputViewStream in GenericArraySerializerConfigSnapshot#write()
+
+[FLINK-6602 ] - Table source with defined time attributes allows empty string
+
+[FLINK-6652 ] - Problem with DelimitedInputFormat
+
+[FLINK-6659 ] - RocksDBMergeIteratorTest, SavepointITCase leave temporary directories behind
+
+[FLINK-6669 ] - [Build] Scala style check errror on Windows
+
+[FLINK-6685 ] - SafetyNetCloseableRegistry is closed prematurely in Task::triggerCheckpointBarrier
+
+[FLINK-6772 ] - Incorrect ordering of matched state events in Flink CEP
+
+[FLINK-6775 ] - StateDescriptor cannot be shared by multiple subtasks
+
+[FLINK-6780 ] - ExternalTableSource should add time attributes in the row type
+
+[FLINK-6783 ] - Wrongly extracted TypeInformations for WindowedStream::aggregate
+
+[FLINK-6797 ] - building docs fails with bundler 1.15
+
+[FLINK-6801 ] - PojoSerializerConfigSnapshot cannot deal with missing Pojo fields
+
+[FLINK-6804 ] - Inconsistent state migration behaviour between different state backends
+
+[FLINK-6807 ] - Elasticsearch 5 connector artifact not published to maven
+
+[FLINK-6808 ] - Stream join fails when checkpointing is enabled
+
+[FLINK-6809 ] - side outputs documentation: wrong variable name in java example code
+
+[FLINK-6812 ] - Elasticsearch 5 release artifacts not published to Maven central
+
+[FLINK-6815 ] - Javadocs don't work anymore in Flink 1.4-SNAPSHOT
+
+[FLINK-6816 ] - Fix wrong usage of Scala string interpolation in Table API
+
+[FLINK-6833 ] - Race condition: Asynchronous checkpointing task can fail completed StreamTask
+
+[FLINK-6844 ] - TraversableSerializer should implement compatibility methods
+
+[FLINK-6848 ] - Extend the managed state docs with a Scala example
+
+[FLINK-6853 ] - Migrating from Flink 1.1 fails for FlinkCEP
+
+[FLINK-6869 ] - Scala serializers do not have the serialVersionUID specified
+
+[FLINK-6875 ] - Remote DataSet API job submission timing out
+
+[FLINK-6881 ] - Creating a table from a POJO and defining a time attribute fails
+
+[FLINK-6883 ] - Serializer for collection of Scala case classes are generated with different anonymous class names in 1.3
+
+[FLINK-6886 ] - Fix Timestamp field can not be selected in event time case when toDataStream[T], `T` not a `Row` Type.
+
+[FLINK-6896 ] - Creating a table from a POJO and use table sink to output fail
+
+[FLINK-6899 ] - Wrong state array size in NestedMapsStateTable
+
+[FLINK-6914 ] - TrySerializer#ensureCompatibility causes StackOverflowException
+
+[FLINK-6915 ] - EnumValueSerializer broken
+
+[FLINK-6921 ] - EnumValueSerializer cannot properly handle appended enum values
+
+[FLINK-6922 ] - Enum(Value)SerializerConfigSnapshot uses Java serialization to store enum values
+
+[FLINK-6930 ] - Selecting window start / end on row-based Tumble/Slide window causes NPE
+
+[FLINK-6932 ] - Update the inaccessible Dataflow Model paper link
+
+[FLINK-6941 ] - Selecting window start / end on over window causes field not resolve exception
+
+[FLINK-6948 ] - EnumValueSerializer cannot handle removed enum values
+
+
+
+ Improvement
+
+
+[FLINK-5354 ] - Split up Table API documentation into multiple pages
+
+[FLINK-6038 ] - Add deep links to Apache Bahir Flink streaming connector documentations
+
+[FLINK-6796 ] - Allow setting the user code class loader for AbstractStreamOperatorTestHarness
+
+[FLINK-6803 ] - Add test for PojoSerializer when Pojo changes
+
+[FLINK-6859 ] - StateCleaningCountTrigger should not delete timer
+
+[FLINK-6929 ] - Add documentation for Table API OVER windows
+
+[FLINK-6952 ] - Add link to Javadocs
+
+[FLINK-6748 ] - Table API / SQL Docs: Table API Page
+
+
+
+ Test
+
+
+[FLINK-6830 ] - Add ITTests for savepoint migration from 1.3
+
+[FLINK-6320 ] - Flakey JobManagerHAJobGraphRecoveryITCase
+
+[FLINK-6744 ] - Flaky ExecutionGraphSchedulingTest
+
+[FLINK-6913 ] - Instable StatefulJobSavepointMigrationITCase.testRestoreSavepoint
+
+
+
\ No newline at end of file
diff --git a/docs/content.tr/posts/2017-07-04-flink-rescalable-state.md b/docs/content.tr/posts/2017-07-04-flink-rescalable-state.md
new file mode 100644
index 0000000000..fab4b3c040
--- /dev/null
+++ b/docs/content.tr/posts/2017-07-04-flink-rescalable-state.md
@@ -0,0 +1,171 @@
+---
+author: Stefan Richter
+author-twitter: StefanRRichter
+date: "2017-07-04T09:00:00Z"
+excerpt: A primer on stateful stream processing and an in-depth walkthrough of
+ rescalable state in Apache Flink.
+title: A Deep Dive into Rescalable State in Apache Flink
+aliases:
+- /features/2017/07/04/flink-rescalable-state.html
+---
+ _Apache Flink 1.2.0, released in February 2017, introduced support for rescalable state. This post provides a detailed overview of stateful stream processing and rescalable state in Flink._
+
+
+
+## An Intro to Stateful Stream Processing
+
+At a high level, we can consider state in stream processing as memory in operators that remembers information about past input and can be used to influence the processing of future input.
+
+In contrast, operators in _stateless_ stream processing only consider their current inputs, without further context and knowledge about the past. A simple example to illustrate this difference: let us consider a source stream that emits events with schema `e = {event_id:int, event_value:int}`. Our goal is, for each event, to extract and output the `event_value`. We can easily achieve this with a simple source-map-sink pipeline, where the map function extracts the `event_value` from the event and emits it downstream to an outputting sink. This is an instance of stateless stream processing.
+
+But what if we want to modify our job to output the `event_value` only if it is larger than the value from the previous event? In this case, our map function obviously needs some way to remember the `event_value` from a past event — and so this is an instance of stateful stream processing.
+
+This example should demonstrate that state is a fundamental, enabling concept in stream processing that is required for a majority of interesting use cases.
+
+## State in Apache Flink
+
+Apache Flink is a massively parallel distributed system that allows stateful stream processing at large scale. For scalability, a Flink job is logically decomposed into a graph of operators, and the execution of each operator is physically decomposed into multiple parallel operator instances. Conceptually, each parallel operator instance in Flink is an independent task that can be scheduled on its own machine in a network-connected cluster of shared-nothing machines.
+
+For high throughput and low latency in this setting, network communications among tasks must be minimized. In Flink, network communication for stream processing only happens along the logical edges in the job’s operator graph (vertically), so that the stream data can be transferred from upstream to downstream operators.
+
+However, there is no communication between the parallel instances of an operator (horizontally). To avoid such network communication, data locality is a key principle in Flink and strongly affects how state is stored and accessed.
+
+For the sake of data locality, all state data in Flink is always bound to the task that runs the corresponding parallel operator instance and is co-located on the same machine that runs the task.
+
+Through this design, all state data for a task is local, and no network communication between tasks is required for state access. Avoiding this kind of traffic is crucial for the scalability of a massively parallel distributed system like Flink.
+
+For Flink’s stateful stream processing, we differentiate between two different types of state: operator state and keyed state. Operator state is scoped per parallel instance of an operator (sub-task), and keyed state can be thought of as [“operator state that has been partitioned, or sharded, with exactly one state-partition per key”]({{< param DocsBaseUrl >}}flink-docs-release-1.3/dev/stream/state.html#keyed-state). We could have easily implemented our previous example as operator state: all events that are routed through the operator instance can influence its value.
+
+## Rescaling Stateful Stream Processing Jobs
+
+Changing the parallelism (that is, changing the number of parallel subtasks that perform work for an operator) in stateless streaming is very easy. It requires only starting or stopping parallel instances of stateless operators and dis-/connecting them to/from their upstream and downstream operators as shown in **Figure 1A**.
+
+On the other hand, changing the parallelism of stateful operators is much more involved because we must also (i) redistribute the previous operator state in a (ii) consistent, (iii) meaningful way. Remember that in Flink’s shared-nothing architecture, all state is local to the task that runs the owning parallel operator instance, and there is no communication between parallel operator instances at job runtime.
+
+However, there is already one mechanism in Flink that allows the exchange of operator state between tasks, in a consistent way, with exactly-once guarantees — Flink’s checkpointing!
+
+You can see detail about Flink’s checkpoints in [the documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.3/internals/stream_checkpointing.html). In a nutshell, a checkpoint is triggered when a checkpoint coordinator injects a special event (a so-called checkpoint barrier) into a stream.
+
+Checkpoint barriers flow downstream with the event stream from sources to sinks, and whenever an operator instance receives a barrier, the operator instance immediately snapshots its current state to a distributed storage system, e.g. HDFS.
+
+On restore, the new tasks for the job (which potentially run on different machines now) can again pick up the state data from the distributed storage system.
+
+Figure 1
+
+
+
+
+
+We can piggyback rescaling of stateful jobs on checkpointing, as shown in **Figure 1B**. First, a checkpoint is triggered and sent to a distributed storage system. Next, the job is restarted with a changed parallelism and can access a consistent snapshot of all previous state from the distributed storage. While this solves (i) redistribution of a (ii) consistent state across machines there is still one problem: without a clear 1:1 relationship between previous state and new parallel operator instances, how can we assign the state in a (iii) meaningful way?
+
+We could again assign the state from previous `map_1` and `map_2` to the new `map_1` and `map_2`. But this would leave `map_3` with empty state. Depending on the type of state and concrete semantics of the job, this naive approach could lead to anything from inefficiency to incorrect results.
+
+In the following section, we’ll explain how we solved the problem of efficient, meaningful state reassignment in Flink. Each of Flink state’s two flavours, operator state and keyed state, requires a different approach to state assignment.
+
+## Reassigning Operator State When Rescaling
+
+First, we’ll discuss how state reassignment in rescaling works for operator state. A common real-world use-case of operator state in Flink is to maintain the current offsets for Kafka partitions in Kafka sources. Each Kafka source instance would maintain `` pairs – one pair for each Kafka partition that the source is reading–as operator state. How would we redistribute this operator state in case of rescaling? Ideally, we would like to reassign all `` pairs from the checkpoint in round robin across all parallel operator instances after the rescaling.
+
+As a user, we are aware of the “meaning” of Kafka partition offsets, and we know that we can treat them as independent, redistributable units of state. The problem of how we can we share this domain-specific knowledge with Flink remains.
+
+**Figure 2A** illustrates the previous interface for checkpointing operator state in Flink. On snapshot, each operator instance returned an object that represented its complete state. In the case of a Kafka source, this object was a list of partition offsets.
+
+This snapshot object was then written to the distributed store. On restore, the object was read from distributed storage and passed to the operator instance as a parameter to the restore function.
+
+This approach was problematic for rescaling: how could Flink decompose the operator state into meaningful, redistributable partitions? Even though the Kafka source was actually always a list of partition offsets, the previously-returned state object was a black box to Flink and therefore could not be redistributed.
+
+As a generalized approach to solve this black box problem, we slightly modified the checkpointing interface, called `ListCheckpointed`. **Figure 2B** shows the new checkpointing interface, which returns and receives a list of state partitions. Introducing a list instead of a single object makes the meaningful partitioning of state explicit: each item in the list still remains a black box to Flink, but is considered an atomic, independently re-distributable part of the operator state.
+
+
+Figure 2
+
+
+
+
+
+Our approach provides a simple API with which implementing operators can encode domain-specific knowledge about how to partition and merge units of state. With our new checkpointing interface, the Kafka source makes individual partition offsets explicit, and state reassignment becomes as easy as splitting and merging lists.
+
+```java
+public class FlinkKafkaConsumer extends RichParallelSourceFunction implements CheckpointedFunction {
+ // ...
+
+ private transient ListState> offsetsOperatorState;
+
+ @Override
+ public void initializeState(FunctionInitializationContext context) throws Exception {
+
+ OperatorStateStore stateStore = context.getOperatorStateStore();
+ // register the state with the backend
+ this.offsetsOperatorState = stateStore.getSerializableListState("kafka-offsets");
+
+ // if the job was restarted, we set the restored offsets
+ if (context.isRestored()) {
+ for (Tuple2 kafkaOffset : offsetsOperatorState.get()) {
+ // ... restore logic
+ }
+ }
+ }
+
+ @Override
+ public void snapshotState(FunctionSnapshotContext context) throws Exception {
+
+ this.offsetsOperatorState.clear();
+
+ // write the partition offsets to the list of operator states
+ for (Map.Entry partition : this.subscribedPartitionOffsets.entrySet()) {
+ this.offsetsOperatorState.add(Tuple2.of(partition.getKey(), partition.getValue()));
+ }
+ }
+
+ // ...
+
+}
+```
+
+## Reassigning Keyed State When Rescaling
+The second flavour of state in Flink is keyed state. In contrast to operator state, keyed state is scoped by key, where the key is extracted from each stream event.
+
+To illustrate how keyed state differs from operator state, let’s use the following example. Assume we have a stream of events, where each event has the schema `{customer_id:int, value:int}`. We have already learned that we can use operator state to compute and emit the running sum of values for all customers.
+
+Now assume we want to slightly modify our goal and compute a running sum of values for each individual `customer_id`. This is a use case from keyed state, as one aggregated state must be maintained for each unique key in the stream.
+
+Note that keyed state is only available for keyed streams, which are created through the `keyBy()` operation in Flink. The `keyBy()` operation (i) specifies how to extract a key from each event and (ii) ensures that all events with the same key are always processed by the same parallel operator instance. As a result, all keyed state is transitively also bound to one parallel operator instance, because for each key, exactly one operator instance is responsible. This mapping from key to operator is deterministically computed through hash partitioning on the key.
+
+We can see that keyed state has one clear advantage over operator state when it comes to rescaling: we can easily figure out how to correctly split and redistribute the state across parallel operator instances. State reassignment simply follows the partitioning of the keyed stream. After rescaling, the state for each key must be assigned to the operator instance that is now responsible for that key, as determined by the hash partitioning of the keyed stream.
+
+While this automatically solves the problem of logically remapping the state to sub-tasks after rescaling, there is one more practical problem left to solve: how can we efficiently transfer the state to the subtasks’ local backends?
+
+When we’re not rescaling, each subtask can simply read the whole state as written to the checkpoint by a previous instance in one sequential read.
+
+When rescaling, however, this is no longer possible – the state for each subtask is now potentially scattered across the files written by all subtasks (think about what happens if you change the parallelism in `hash(key) mod parallelism`). We have illustrated this problem in **Figure 3A**. In this example, we show how keys are shuffled when rescaling from parallelism 3 to 4 for a key space of 0, 20, using identity as hash function to keep it easy to follow.
+
+A naive approach might be to read all the previous subtask state from the checkpoint in all sub-tasks and filter out the matching keys for each sub-task. While this approach can benefit from a sequential read pattern, each subtask potentially reads a large fraction of irrelevant state data, and the distributed file system receives a huge number of parallel read requests.
+
+Another approach could be to build an index that tracks the location of the state for each key in the checkpoint. With this approach, all sub-tasks could locate and read the matching keys very selectively. This approach would avoid reading irrelevant data, but it has two major downsides. A materialized index for all keys, i.e. a key-to-read-offset mapping, can potentially grow very large. Furthermore, this approach can also introduce a huge amount of random I/O (when seeking to the data for individual keys, see **Figure 3A**, which typically entails very bad performance in distributed file systems.
+
+Flink’s approach sits in between those two extremes by introducing key-groups as the atomic unit of state assignment. How does this work? The number of key-groups must be determined before the job is started and (currently) cannot be changed after the fact. As key-groups are the atomic unit of state assignment, this also means that the number of key-groups is the upper limit for parallelism. In a nutshell, key-groups give us a way to trade between flexibility in rescaling (by setting an upper limit for parallelism) and the maximum overhead involved in indexing and restoring the state.
+
+We assign key-groups to subtasks as ranges. This makes the reads on restore not only sequential within each key-group, but often also across multiple key-groups. An additional benefit: this also keeps the metadata of key-group-to-subtask assignments very small. We do not maintain explicit lists of key-groups because it is sufficient to track the range boundaries.
+
+We have illustrated rescaling from parallelism 3 to 4 with 10 key-groups in **Figure 3B**. As we can see, introducing key-groups and assigning them as ranges greatly improves the access pattern over the naive approach. Equation 2 and 3 in **Figure 3B** also details how we compute key-groups and the range assignment.
+
+Figure 2
+
+
+
+
+## Wrapping Up
+
+Thanks for staying with us, and we hope you now have a clear idea of how rescalable state works in Apache Flink and how to make use of rescaling in real-world scenarios.
+
+Flink 1.3.0, which was released earlier this month, adds more tooling for state management and fault tolerance in Flink, including incremental checkpoints. And the community is exploring features such as…
+
+• State replication
+• State that isn’t bound to the lifecycle of a Flink job
+• Automatic rescaling (with no savepoints required)
+
+…for Flink 1.4.0 and beyond.
+
+If you’d like to learn more, we recommend starting with the Apache Flink [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.3/dev/stream/state.html).
+
+_This is an excerpt from a post that originally appeared on the data Artisans blog. If you'd like to read the original post in its entirety, you can find it here (external link)._
diff --git a/docs/content.tr/posts/2017-08-05-release-1.3.2.md b/docs/content.tr/posts/2017-08-05-release-1.3.2.md
new file mode 100644
index 0000000000..cadbc9c46b
--- /dev/null
+++ b/docs/content.tr/posts/2017-08-05-release-1.3.2.md
@@ -0,0 +1,212 @@
+---
+date: "2017-08-05T09:00:00Z"
+title: Apache Flink 1.3.2 Released
+aliases:
+- /news/2017/08/05/release-1.3.2.html
+---
+
+The Apache Flink community released the second bugfix version of the Apache Flink 1.3 series.
+
+This release includes more than 60 fixes and minor improvements for Flink 1.3.1. The list below includes a detailed list of all fixes.
+
+We highly recommend all users to upgrade to Flink 1.3.2.
+
+
+
+ Important Notice:
+
+
A user reported a bug in the FlinkKafkaConsumer
+ (FLINK-7143 ) that is causing
+ incorrect partition assignment in large Kafka deployments in the presence of inconsistent broker
+ metadata. In that case multiple parallel instances of the FlinkKafkaConsumer may read from the
+ same topic partition, leading to data duplication. In Flink 1.3.2 this bug is fixed but incorrect
+ assignments from Flink 1.3.0 and 1.3.1 cannot be automatically fixed by upgrading to Flink 1.3.2
+ via a savepoint because the upgraded version would resume the wrong partition assignment from the
+ savepoint. If you believe you are affected by this bug (seeing messages from some partitions
+ duplicated) please refer to the JIRA issue for an upgrade path that works around that.
+
+
Before attempting the more elaborate upgrade path, we would suggest to check if you are
+ actually affected by this bug. We did not manage to reproduce it in various testing clusters and
+ according to the reporting user, it only appeared in rare cases on their very large setup. This
+ leads us to believe that most likely only a minority of setups would be affected by this bug.
+
+
+Notable changes:
+
+ - The default Kafka version for Flink Kafka Consumer 0.10 was bumped from 0.10.0.1 to 0.10.2.1.
+ - Some default values for configurations of AWS API call behaviors in the Flink Kinesis Consumer
+ were adapted for better default consumption performance: 1) `SHARD_GETRECORDS_MAX` default changed
+ to 10,000, and 2) `SHARD_GETRECORDS_INTERVAL_MILLIS` default changed to 200ms.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.3.2
+
+
+ org.apache.flink
+ flink-streaming-java_2.10
+ 1.3.2
+
+
+ org.apache.flink
+ flink-clients_2.10
+ 1.3.2
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-6665 ] - Pass a ScheduledExecutorService to the RestartStrategy
+
+[FLINK-6667 ] - Pass a callback type to the RestartStrategy, rather than the full ExecutionGraph
+
+[FLINK-6680 ] - App & Flink migration guide: updates for the 1.3 release
+
+
+
+ Bug
+
+
+[FLINK-5488 ] - yarnClient should be closed in AbstractYarnClusterDescriptor for error conditions
+
+[FLINK-6376 ] - when deploy flink cluster on the yarn, it is lack of hdfs delegation token.
+
+[FLINK-6541 ] - Jar upload directory not created
+
+[FLINK-6654 ] - missing maven dependency on "flink-shaded-hadoop2-uber" in flink-dist
+
+[FLINK-6655 ] - Misleading error message when HistoryServer path is empty
+
+[FLINK-6742 ] - Improve error message when savepoint migration fails due to task removal
+
+[FLINK-6774 ] - build-helper-maven-plugin version not set
+
+[FLINK-6806 ] - rocksdb is not listed as state backend in doc
+
+[FLINK-6843 ] - ClientConnectionTest fails on travis
+
+[FLINK-6867 ] - Elasticsearch 1.x ITCase still instable due to embedded node instability
+
+[FLINK-6918 ] - Failing tests: ChainLengthDecreaseTest and ChainLengthIncreaseTest
+
+[FLINK-6945 ] - TaskCancelAsyncProducerConsumerITCase.testCancelAsyncProducerAndConsumer instable test case
+
+[FLINK-6964 ] - Fix recovery for incremental checkpoints in StandaloneCompletedCheckpointStore
+
+[FLINK-6965 ] - Avro is missing snappy dependency
+
+[FLINK-6987 ] - TextInputFormatTest fails when run in path containing spaces
+
+[FLINK-6996 ] - FlinkKafkaProducer010 doesn't guarantee at-least-once semantic
+
+[FLINK-7005 ] - Optimization steps are missing for nested registered tables
+
+[FLINK-7011 ] - Instable Kafka testStartFromKafkaCommitOffsets failures on Travis
+
+[FLINK-7025 ] - Using NullByteKeySelector for Unbounded ProcTime NonPartitioned Over
+
+[FLINK-7034 ] - GraphiteReporter cannot recover from lost connection
+
+[FLINK-7038 ] - Several misused "KeyedDataStream" term in docs and Javadocs
+
+[FLINK-7041 ] - Deserialize StateBackend from JobCheckpointingSettings with user classloader
+
+[FLINK-7132 ] - Fix BulkIteration parallelism
+
+[FLINK-7133 ] - Fix Elasticsearch version interference
+
+[FLINK-7137 ] - Flink table API defaults top level fields as nullable and all nested fields within CompositeType as non-nullable
+
+[FLINK-7143 ] - Partition assignment for Kafka consumer is not stable
+
+[FLINK-7154 ] - Missing call to build CsvTableSource example
+
+[FLINK-7158 ] - Wrong test jar dependency in flink-clients
+
+[FLINK-7177 ] - DataSetAggregateWithNullValuesRule fails creating null literal for non-nullable type
+
+[FLINK-7178 ] - Datadog Metric Reporter Jar is Lacking Dependencies
+
+[FLINK-7180 ] - CoGroupStream perform checkpoint failed
+
+[FLINK-7195 ] - FlinkKafkaConsumer should not respect fetched partitions to filter restored partition states
+
+[FLINK-7216 ] - ExecutionGraph can perform concurrent global restarts to scheduling
+
+[FLINK-7225 ] - Cutoff exception message in StateDescriptor
+
+[FLINK-7226 ] - REST responses contain invalid content-encoding header
+
+[FLINK-7231 ] - SlotSharingGroups are not always released in time for new restarts
+
+[FLINK-7234 ] - Fix CombineHint documentation
+
+[FLINK-7241 ] - Fix YARN high availability documentation
+
+[FLINK-7255 ] - ListStateDescriptor example uses wrong constructor
+
+[FLINK-7258 ] - IllegalArgumentException in Netty bootstrap with large memory state segment size
+
+[FLINK-7266 ] - Don't attempt to delete parent directory on S3
+
+[FLINK-7268 ] - Zookeeper Checkpoint Store interacting with Incremental State Handles can lead to loss of handles
+
+[FLINK-7281 ] - Fix various issues in (Maven) release infrastructure
+
+
+
+ Improvement
+
+
+[FLINK-6365 ] - Adapt default values of the Kinesis connector
+
+[FLINK-6575 ] - Disable all tests on Windows that use HDFS
+
+[FLINK-6682 ] - Improve error message in case parallelism exceeds maxParallelism
+
+[FLINK-6789 ] - Remove duplicated test utility reducer in optimizer
+
+[FLINK-6874 ] - Static and transient fields ignored for POJOs
+
+[FLINK-6898 ] - Limit size of operator component in metric name
+
+[FLINK-6937 ] - Fix link markdown in Production Readiness Checklist doc
+
+[FLINK-6940 ] - Clarify the effect of configuring per-job state backend
+
+[FLINK-6998 ] - Kafka connector needs to expose metrics for failed/successful offset commits in the Kafka Consumer callback
+
+[FLINK-7004 ] - Switch to Travis Trusty image
+
+[FLINK-7032 ] - Intellij is constantly changing language level of sub projects back to 1.6
+
+[FLINK-7069 ] - Catch exceptions for each reporter separately
+
+[FLINK-7149 ] - Add checkpoint ID to 'sendValues()' in GenericWriteAheadSink
+
+[FLINK-7164 ] - Extend integration tests for (externalised) checkpoints, checkpoint store
+
+[FLINK-7174 ] - Bump dependency of Kafka 0.10.x to the latest one
+
+[FLINK-7211 ] - Exclude Gelly javadoc jar from release
+
+[FLINK-7224 ] - Incorrect Javadoc description in all Kafka consumer versions
+
+[FLINK-7228 ] - Harden HistoryServerStaticFileHandlerTest
+
+[FLINK-7233 ] - TaskManagerHeapSizeCalculationJavaBashTest failed on Travis
+
+[FLINK-7287 ] - test instability in Kafka010ITCase.testCommitOffsetsToKafka
+
+[FLINK-7290 ] - Make release scripts modular
+
+
\ No newline at end of file
diff --git a/docs/content.tr/posts/2017-11-21-release-1.4-and-1.5-timeline.md b/docs/content.tr/posts/2017-11-21-release-1.4-and-1.5-timeline.md
new file mode 100644
index 0000000000..a938f6c017
--- /dev/null
+++ b/docs/content.tr/posts/2017-11-21-release-1.4-and-1.5-timeline.md
@@ -0,0 +1,138 @@
+---
+authors:
+- name: Stephan Ewen
+ stephan: null
+ twitter: StephanEwen
+- aljoscha: null
+ name: Aljoscha Krettek
+ twitter: aljoscha
+- mike: null
+ name: Mike Winters
+ twitter: wints
+date: "2017-11-21T10:00:00Z"
+title: Looking Ahead to Apache Flink 1.4.0 and 1.5.0
+aliases:
+- /news/2017/11/22/release-1.4-and-1.5-timeline.html
+---
+
+The Apache Flink 1.4.0 release is on track to happen in the next couple of weeks, and for all of the
+readers out there who haven’t been following the release discussion on [Flink’s developer mailing
+list](http://flink.apache.org/community.html#mailing-lists), we’d like to provide some details on
+what’s coming in Flink 1.4.0 as well as a preview of what the Flink community will save for 1.5.0.
+
+Both releases include ambitious features that we believe will move Flink to an entirely new level in
+terms of the types of problems it can solve and applications it can support. The community deserves
+lots of credit for its hard work over the past few months, and we’re excited to see these features
+in the hands of users.
+
+This post will describe how the community plans to get there and the rationale behind the approach.
+
+## Coming soon: Major Changes to Flink’s Runtime
+
+There are 3 significant improvements to the Apache Flink engine that the community has nearly
+completed and that will have a meaningful impact on Flink’s operability and performance.
+
+1. Rework of the deployment model and distributed process
+2. Transition from configurable, fixed-interval network I/O to event-driven network I/O and application-level flow control for better backpressure handling
+3. Faster recovery from failure
+
+Next, we’ll go through each of these improvements in more detail.
+
+## Reworking Flink’s Deployment Model and Distributed Processing
+
+[FLIP-6](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65147077) (FLIP is short for
+FLink Improvement Proposal and FLIPs are proposals for bigger changes to Flink) is an initiative
+that’s been in the works for more than a year and represents a major refactor of Flink’s deployment
+model and distributed process. The underlying motivation for FLIP-6 was the fact that Flink is being
+adopted by a wider range of developer communities--both developers coming from the big data and
+analytics space as well as developers coming from the event-driven applications space.
+
+Modern, stateful stream processing has served as a convergence for these two developer communities.
+Despite a significant overlap of the core concepts in the applications being built, each group of
+developers has its own set of common tools, deployment models, and expected behaviors when working
+with a stream processing framework like Flink.
+
+FLIP-6 will ensure that Flink fits naturally in both of these contexts, behaving as though it’s
+native to each ecosystem and operating seamlessly within a broader technology stack. A few of the
+specific changes in FLIP-6 that will have such an impact:
+
+ - Leveraging cluster management frameworks to support full resource elasticity
+ - First-class support for containerized environments such as Kubernetes and Docker
+ - REST-based client-cluster communication to ease operations and 3rd party integrations
+
+FLIP-6, along with already-introduced features like
+[rescalable state](https://data-artisans.com/blog/apache-flink-at-mediamath-rescaling-stateful-applications),
+lays the groundwork for dynamic scaling in Flink, meaning that Flink programs will be able to scale up or down
+automatically based on required resources--a huge step forward in terms of ease of operability and
+the efficiency of Flink applications.
+
+## Lower Latency via Improvements to the Apache Flink Network Stack
+
+Speed will always be a key consideration for users who build stream processing applications, and
+Flink 1.5 will include a rework of the network stack that will even further improve Flink's latency.
+At the heart of this work is a transition from configurable, fixed-interval network I/O to event-
+driven network I/O and application-level flow control, ensuring that Flink will use all available
+network capacity, as well as credit-based flow control which offers more fine-grained backpressuring
+for improved checkpoint alignments.
+
+In our testing ([see slide 26 here](https://www.slideshare.net/FlinkForward/flink-forward-berlin-2017-nico-kruber-building-a-network-stack-for-optimal-throughput-lowlatency-tradeoffs#26)),
+we’ve seen a substantial improvement in latency using event-driven network I/O, and the community
+is also doing work to make sure we’re able to provide this increase in speed without a measurable
+throughput tradeoff.
+
+## Faster Recovery from Failures
+
+Flink 1.3.0 introduced incremental checkpoints, making it possible to take a checkpoint of state
+updates since the last successfully-completed checkpoint only rather than the previous behavior of
+only taking checkpoints of the entire state of the application. This has led to significant
+performance improvements for users with large state.
+
+Flink 1.5 will introduce task-local recovery, which means that Flink will store a second copy of the
+most recent checkpoint on the local disk (or even in main memory) of a task manager. The primary
+copy still goes to durable storage so that it’s resilient to machine failures.
+
+In case of failover, the scheduler will try to reschedule tasks to their previous task manager (in
+other words, to the same machine again) if this is possible. The task can then recover from the
+locally-kept state. This makes it possible to avoid reading all state from the distributed file
+system (which is remote over the network). Especially in applications with very large state, not
+having to read many gigabytes over the network and instead from local disk will result in
+significant performance gains in recovery.
+
+## The Proposed Timeline for Flink 1.4 and Flink 1.5
+
+The good news is that all 3 of the features described above are well underway, and in fact, much of
+the work is already covered by open pull requests.
+
+But given these features’ importance and the complexity of the work involved, the community expected
+that the QA and testing required would be extensive and would delay the release of the otherwise-
+ready features also on the list for the next release.
+
+And so the community decided to withhold the 3 features above (deployment model rework, improvements
+to the network stack, and faster recovery) to be included a separate Flink 1.5 release that will
+come shortly after the Flink 1.4 release. Flink 1.5 is estimated to come just a couple of months
+after 1.4 rather than the typical 4-month cycle in between major releases.
+
+The soon-to-be-released Flink 1.4 represents the current state of Flink without merging those 3
+features. And Flink 1.4 is a substantial release in its own right, including, but not limited to,
+the following:
+
+- **A significantly improved dependency structure**, removing many of Flink’s dependencies and subtle runtime conflicts. This increases overall stability and removes friction when embedding Flink or calling Flink "library style".
+- **Reversed class loading for dynamically-loaded user code**, allowing for different dependencies than those included in the core framework.
+- **An Apache Kafka 0.11 exactly-once producer**, making it possible to build end-to-end exactly once applications with Flink and Kafka.
+- **Streaming SQL JOIN based on processing time and event time**, which gives users the full advantage of Flink’s time handling while using a SQL JOIN.
+- **Table API / Streaming SQL Source and Sink Additions**, including a Kafka 0.11 source and JDBC sink.
+- **Hadoop-free Flink**, meaning that users who don’t rely on any Hadoop components (such as YARN or HDFS) in their Flink applications can use Flink without Hadoop for the first time.
+- **Improvements to queryable state**, including a more container-friendly architecture, a more user-friendly API that hides configuration parameters, and the groundwork to be able to expose window state (the state of an in-flight window) in the future.
+- **Connector improvements and fixes** for a range of connectors including Kafka, Apache Cassandra, Amazon Kinesis, and more.
+- **Improved RPC performance** for faster recovery from failure
+
+The community decided it was best to get these features into a stable version of Flink as soon as
+possible, and the separation of what could have been a single (and very substantial) Flink 1.4
+release into 1.4 and 1.5 serves that purpose.
+
+We’re excited by what each of these represents for Apache Flink, and we’d like to extend our thanks
+to the Flink community for all of their hard work.
+
+If you’d like to follow along with release discussions, [please subscribe to the dev@ mailing
+list](http://flink.apache.org/community.html#mailing-lists).
+
diff --git a/docs/content.tr/posts/2017-12-12-release-1.4.0.md b/docs/content.tr/posts/2017-12-12-release-1.4.0.md
new file mode 100644
index 0000000000..4ce8266770
--- /dev/null
+++ b/docs/content.tr/posts/2017-12-12-release-1.4.0.md
@@ -0,0 +1,225 @@
+---
+authors:
+- aljoscha: null
+ name: Aljoscha Krettek
+ twitter: aljoscha
+- mike: null
+ name: Mike Winters
+ twitter: wints
+date: "2017-12-12T10:00:00Z"
+title: Apache Flink 1.4.0 Release Announcement
+aliases:
+- /news/2017/12/12/release-1.4.0.html
+---
+
+The Apache Flink community is pleased to announce the 1.4.0 release. Over the past 5 months, the
+Flink community has been working hard to resolve more than 900 issues. See the [complete changelog](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12340533)
+for more detail.
+
+This is the fifth major release in the 1.x.y series. It is API-compatible with the other 1.x.y
+releases for APIs annotated with the @Public annotation.
+
+We encourage everyone to download the release and check out the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.4/).
+
+Feedback through the [Flink mailing lists](http://flink.apache.org/community.html#mailing-lists) is, as always, gladly encouraged!
+
+You can find the binaries on the updated [Downloads](http://flink.apache.org/downloads.html) page on the Flink project site.
+
+The release includes improvements to many different aspects of Flink, including:
+
+ - The ability to build end-to-end exactly-once applications with Flink and popular data sources and sinks such as Apache Kafka.
+ - A more developer-friendly dependency structure as well as Hadoop-free Flink for Flink users who do not have Hadoop dependencies.
+ - Support for JOIN and for new sources and sinks in table API and SQL, expanding the range of logic that can be expressed with these APIs.
+
+A summary of some of the features in the release is available below.
+
+For more background on the Flink 1.4.0 release and the work planned for the Flink 1.5.0 release, please refer to [this blog post](http://flink.apache.org/news/2017/11/22/release-1.4-and-1.5-timeline.html) on the Apache Flink blog.
+
+## New Features and Improvements
+
+### End-to-end Exactly Once Applications with Apache Flink and Apache Kafka and TwoPhaseCommitSinkFunction
+
+Flink 1.4 includes a first version of an exactly-once producer for Apache Kafka 0.11. This producer
+enables developers who build Flink applications with Kafka as a data source and sink to compute
+exactly-once results not just within the Flink program, but truly “end-to-end” in the application.
+
+The common pattern used for exactly-once applications in Kafka and in other sinks--the two-phase
+commit algorithm--has been extracted in Flink 1.4.0 into a common class, the
+TwoPhaseCommitSinkFunction ([FLINK-7210](https://issues.apache.org/jira/browse/FLINK-7210)). This
+will make it easier for users to create their own exactly-once data sinks in the future.
+
+### Table API and Streaming SQL Enhancements
+
+Flink SQL now supports windowed joins based on processing time and event time
+([FLINK-5725](https://issues.apache.org/jira/browse/FLINK-5725)). Users will be able to execute a
+join between 2 streaming tables and compute windowed results according to these 2 different concepts
+of time. The syntax and semantics in Flink are the same as standard SQL with JOIN and with Flink’s
+streaming SQL more broadly.
+
+Flink SQL also now supports “INSERT INTO SELECT” queries, which makes it possible to write results
+from SQL directly into a data sink (an external system that receives data from a Flink application).
+This improves operability and ease-of-use of Flink SQL.
+
+The Table API now supports aggregations on streaming tables; previously, the only supported
+operations on streaming tables were projection, selection, and union
+([FLINK-4557](https://issues.apache.org/jira/browse/FLINK-4557)). This feature was initially discussed in Flink
+Improvement Proposal 11: [FLIP-11](https://cwiki.apache.org/confluence/display/FLINK/FLIP-11%3A+Table+API+Stream+Aggregations).
+
+The release also adds support for new table API and SQL sources and sinks, including a Kafka 0.11
+source and JDBC sink.
+
+Lastly, Flink SQL now uses Apache Calcite 1.14, which was just released in October 2017
+([FLINK-7051](https://issues.apache.org/jira/browse/FLINK-7051)).
+
+### A Significantly-Improved Dependency Structure and Reversed Class Loading
+
+Flink 1.4.0 shades a number of dependences and subtle runtime conflicts, including:
+
+ - ASM
+ - Guava
+ - Jackson
+ - Netty
+ - Apache Zookeeper
+
+These changes improve Flink’s overall stability and removes friction when embedding Flink or calling
+Flink "library style".
+
+The release also introduces default reversed (child-first) class loading for dynamically-loaded user
+code, allowing for different dependencies than those included in the core framework.
+
+For details on those changes please check out the relevant Jira issues:
+
+ - [FLINK-7442](https://issues.apache.org/jira/browse/FLINK-7442)
+ - [FLINK-6529](https://issues.apache.org/jira/browse/FLINK-6529)
+
+### Hadoop-free Flink
+
+Apache Flink users without any Apache Hadoop dependencies can now run Flink without Hadoop. Flink
+programs that do not rely on Hadoop components can now be much smaller, a benefit particularly in a
+container-based setup resulting in less network traffic and better performance.
+
+This includes the addition of Flink’s own Amazon S3 filesystem implementations based on Hadoop's S3a
+and Presto's S3 file system with properly shaded dependencies ([FLINK-5706](https://issues.apache.org/jira/browse/FLINK-5706)).
+
+The details of these changes regarding Hadoop-free Flink are available in the Jira issue:
+[FLINK-2268](https://issues.apache.org/jira/browse/FLINK-2268).
+
+### Improvements to Flink Internals
+
+Flink 1.4.0 introduces a new blob storage architecture that was first discussed in
+[Flink Improvement Proposal 19](https://cwiki.apache.org/confluence/display/FLINK/FLIP-19%3A+Improved+BLOB+storage+architecture) ([FLINK-6916](https://issues.apache.org/jira/browse/FLINK-6916)).
+
+This will enable easier integration with both the work being done in [Flink Improvement Proposal 6](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65147077) in
+the future and with other improvements in the 1.4.0 release, such as support for messages larger
+than the maximum Akka Framesize ([FLINK-6046](https://issues.apache.org/jira/browse/FLINK-6046)).
+
+The improvement also enables Flink to leverage distributed file systems in high availability
+settings for optimized distribution of deployment data to TaskManagers.
+
+### Improvements to the Queryable State Client
+
+Flink’s [queryable state]({{< param DocsBaseUrl >}}flink-docs-release-1.4/dev/stream/state/queryable_state.html) makes it possible for users to access application state directly in Flink
+before the state has been sent to an external database or key-value store.
+
+Flink 1.4.0 introduces a range of improvements to the queryable state client, including a more
+container-friendly architecture, a more user-friendly API that hides configuration parameters, and
+the groundwork to be able to expose window state (the state of an in-flight window) in the future.
+
+For details about the changes to queryable state please refer to the umbrella Jira issue:
+[FLINK-5675](https://issues.apache.org/jira/browse/FLINK-5675).
+
+### Metrics and Monitoring
+
+Flink’s metrics system now also includes support for Prometheus, an increasingly-popular metrics and
+reporting system within the Flink community ([FLINK-6221](https://issues.apache.org/jira/browse/FLINK-6221)).
+
+And the Apache Kafka connector in Flink now exposes metrics for failed and successful offset commits
+in the Kafka consumer callback ([FLINK-6998](https://issues.apache.org/jira/browse/FLINK-6998)).
+
+### Connector improvements and fixes
+
+Flink 1.4.0 introduces an Apache Kafka 0.11 connector and, as described above, support for an
+exactly-once producer for Kafka 0.11 ([FLINK-6988](https://issues.apache.org/jira/browse/FLINK-6988)).
+
+Additionally, the Flink-Kafka consumer now supports dynamic partition discovery & topic discovery
+based on regex. This means that the Flink-Kafka consumer can pick up new Kafka partitions without
+needing to restart the job and while maintaining exactly-once guarantees
+([FLINK-4022](https://issues.apache.org/jira/browse/FLINK-4022)).
+
+Flink’s Apache Kinesis connector now uses an updated version of the Kinesis Consumer Library and
+Kinesis Consumer Library. This introduces improved retry logic to the connector and should
+significantly reduce the number of failures caused by Flink writing too quickly to Kinesis
+([FLINK-7366](https://issues.apache.org/jira/browse/FLINK-7366)).
+
+Flink’s Apache Cassandra connector now supports Scala tuples--previously, only streams of Java
+tuples were supported ([FLINK-4497](https://issues.apache.org/jira/browse/FLINK-4497)). Also, a bug was fixed in
+the Cassandra connector that caused messages to be lost in certain instances
+([FLINK-4500](https://issues.apache.org/jira/browse/FLINK-4500)).
+
+## Release Notes - Please Read
+
+Some of these changes will require updating the configuration or Maven dependencies for existing
+programs. Please read below to see if you might be affected.
+
+### Changes to dynamic class loading of user code
+
+As mentioned above, we changed the way Flink loads user code from the previous default of
+*parent-first class loading* (the default for Java) to *child-first classloading*, which is a common
+practice in Java Application Servers, where this is also referred to as inverted or reversed class
+loading.
+
+This should not affect regular user code but will enable programs to use a different version of
+dependencies that come with Flink -- for example Akka, netty, or Jackson. If you want to change back
+to the previous default, you can use the configuration setting `classloader.resolve-order: parent-first`,
+the new default being `child-first`.
+
+### No more Avro dependency included by default
+
+Flink previously included Avro by default so user programs could simply use Avro and not worry about
+adding any dependencies. This behavior was changed in Flink 1.4 because it can lead to dependency
+clashes.
+
+You now must manually include the Avro dependency (`flink-avro`) with your program jar (or add it to
+the Flink lib folder) if you want to use Avro.
+
+### Hadoop-free Flink
+
+Starting with version 1.4, Flink can run without any Hadoop dependencies present in the Classpath.
+Along with simply running without Hadoop, this enables Flink to dynamically use whatever Hadoop
+version is available in the classpath.
+
+You could, for example, download the Hadoop-free release of Flink but use that to run on any
+supported version of YARN, and Flink would dynamically use the Hadoop dependencies from YARN.
+
+This also means that in cases where you used connectors to HDFS, such as the `BucketingSink` or
+`RollingSink`, you now have to ensure that you either use a Flink distribution with bundled Hadoop
+dependencies or make sure to include Hadoop dependencies when building a jar file for your
+application.
+
+### Bundled S3 FileSystems
+
+Flink 1.4 comes bundled with two different S3 FileSystems based on the Presto S3 FileSystem and
+the Hadoop S3A FileSystem. They don't have dependencies (because all dependencies are
+shaded/relocated) and you can use them by dropping the respective file from the `opt` directory
+into the `lib` directory of your Flink installation. For more information about this, please refer
+to the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.4/ops/filesystems.html#built-in-file-systems).
+
+## List of Contributors
+
+According to git shortlog, the following 106 people contributed to the 1.4.0 release. Thank you to
+all contributors!
+
+Ajay Tripathy, Alejandro Alcalde, Aljoscha Krettek, Bang, Phiradet, Bowen Li, Chris Ward, Cristian,
+Dan Kelley, David Anderson, Dawid Wysakowicz, Dian Fu, Dmitrii Kniazev, DmytroShkvyra, Fabian
+Hueske, FlorianFan, Fokko Driesprong, Gabor Gevay, Gary Yao, Greg Hogan, Haohui Mai, Hequn Cheng,
+James Lafa, Jark Wu, Jie Shen, Jing Fan, JingsongLi, Joerg Schad, Juan Paulo Gutierrez, Ken Geis,
+Kent Murra, Kurt Young, Lim Chee Hau, Maximilian Bode, Michael Fong, Mike Kobit, Mikhail Lipkovich,
+Nico Kruber, Novotnik, Petr, Nycholas de Oliveira e Oliveira, Patrick Lucas, Piotr Nowojski, Robert
+Metzger, Rodrigo Bonifacio, Rong Rong, Scott Kidder, Sebastian Klemke, Shuyi Chen, Stefan Richter,
+Stephan Ewen, Svend Vanderveken, Till Rohrmann, Tony Wei, Tzu-Li (Gordon) Tai, Ufuk Celebi, Usman
+Younas, Vetriselvan1187, Vishnu Viswanath, Wright, Eron, Xingcan Cui, Xpray, Yestin, Yonatan Most,
+Zhenzhong Xu, Zhijiang, adebski, asdf2014, bbayani, biao.liub, cactuslrd.lird, dawidwys, desktop,
+fengyelei, godfreyhe, gosubpl, gyao, hongyuhong, huafengw, kkloudas, kl0u, lincoln-lil,
+lingjinjiang, mengji.fy, minwenjun, mtunique, p1tz, paul, rtudoran, shaoxuan-wang, sirko
+bretschneider, sunjincheng121, tedyu, twalthr, uybhatti, wangmiao1981, yew1eb, z00376786, zentol,
+zhangminglei, zhe li, zhouhai02, zjureel, 付典, 军长, 宝牛, 淘江, 金竹
diff --git a/docs/content.tr/posts/2017-12-21-2017-year-in-review.md b/docs/content.tr/posts/2017-12-21-2017-year-in-review.md
new file mode 100644
index 0000000000..ec38d7316e
--- /dev/null
+++ b/docs/content.tr/posts/2017-12-21-2017-year-in-review.md
@@ -0,0 +1,135 @@
+---
+authors:
+- chris: null
+ name: Chris Ward
+ twitter: chrischinch
+- mike: null
+ name: Mike Winters
+ twitter: wints
+date: "2017-12-21T09:00:00Z"
+excerpt: As 2017 comes to a close, let's take a moment to look back on the Flink community's
+ great work during the past year.
+title: 'Apache Flink in 2017: Year in Review'
+aliases:
+- /news/2017/12/21/2017-year-in-review.html
+---
+
+2017 was another exciting year for the Apache Flink® community, with 3 major version releases ([Flink 1.2.0 in February](http://flink.apache.org/news/2017/02/06/release-1.2.0.html), [Flink 1.3.0 in June](http://flink.apache.org/news/2017/06/01/release-1.3.0.html), and [Flink 1.4.0 in December](http://flink.apache.org/news/2017/12/12/release-1.4.0.html)) and the first-ever [Flink Forward in San Francisco](https://sf-2017.flink-forward.org/), giving Flink community members in another corner of the globe an opportunity to connect. Users shared details about their innovative production deployments, redefining what is possible with a modern stream processing framework like Flink.
+
+In this post, we'll look back on the project's progress over the course of 2017, and we'll also preview what 2018 has in store.
+
+{%toc%}
+
+## Community Growth
+
+### Github
+
+First, here's a summary of community statistics from [GitHub](https://github.com/apache/flink). At the time of writing:
+
+- **Contributors** have increased from 258 in December 2016 to 352 in December 2017 (up **36%**)
+- **Stars** have increased from 1830 in December 2016 to 3036 in December 2017 (up **65%**)
+- **Forks** have increased from 1255 in December 2016 to 2070 in December 2017 (up **65%**)
+
+The community also welcomed **10 new committers in 2017**: Kostas Kloudas, Jark Wu, Stefan Richter, Kurt Young, Theodore Vasiloudis, Xiaogang Shi, Dawid Wysakowicz, Shaoxuan Wang, Jincheng Sun and Haohui Mai.
+
+We also welcomed **3 new members to the [project management committee (PMC)](http://www.apache.org/foundation/governance/pmcs.html)**: Greg Hogan, Tzu-Li (Gordon) Tai and Chesnay Schepler.
+
+
+
+Next, let's take a look at a few other project stats, starting with number of commits. If we run:
+
+```bash
+git log --pretty=oneline --after=12/31/2016 | wc -l
+```
+
+Inside the Flink repository, we'll see a total of **2316** commits so far in 2017, bringing the all-time total commits to **12,532**.
+
+Now, let's go a bit deeper, here are instructions to take a look at this data yourself.
+
+Download and install gitstats from the [project homepage](http://gitstats.sourceforge.net/), then clone the Apache Flink git repository:
+
+```bash
+git clone git@github.com:apache/flink.git
+```
+
+Generate the statistics
+
+```bash
+gitstats flink/ flink-stats/
+```
+
+View all the statistics as an HTML page using your default browser:
+
+```bash
+open flink-stats/index.html
+```
+
+Flink surpassed 1 million lines of code in 2016, and that trend continued in 2017 with the code base now clocking in at **1,257,949** lines.
+
+
+
+Monday remains the day of the week with the most commits over the project's history, but Wednesday is catching up:
+
+
+
+5 pm remains the preferred commit time, closely followed by 4 pm:
+
+
+
+### Meetups
+
+[Apache Flink Meetup membership](https://www.meetup.com/topics/apache-flink/) grew by **20%** this year to a total of **19,767** members at **39** meetups listing Flink as a topic. With meetups on five continents, the Flink community is proud to be truly global.
+
+
+
+## Flink Forward 2017
+
+2017 was the first year we ran a Flink Forward conference in both [Berlin](https://berlin-2017.flink-forward.org) (September 11-13) and [San Francisco](https://sf-2017.flink-forward.org) (April 10-11), and over 350 members of our community attended each event for speaker sessions, training, and discussion about Flink.
+
+[Slides](https://www.slideshare.net/FlinkForward/presentations) and [videos](https://www.youtube.com/channel/UCY8_lgiZLZErZPF47a2hXMA) are available for all speaker sessions, and if you're interested in learning more about how organizations use Flink in production, we encourage you to browse and watch a couple.
+
+For 2018, Flink Forward will be back in [September in Berlin](https://flink-forward.org/), and in [April in San Francisco](https://sf-2018.flink-forward.org/).
+
+
+
+## Features and Ecosystem
+
+### Flink Ecosystem Growth
+
+Flink was added to a selection of distributions and integrations during 2017, making it easier for a wider user base to get started with Flink:
+
+- [Official Docker image](https://hub.docker.com/r/_/flink/)
+- [Official DC/OS and Mesos support]({{< param DocsBaseUrl >}}flink-docs-release-1.3/setup/mesos.html)
+- [A Flink connector](https://data-artisans.com/blog/dellemc-launches-open-source-pravega-complete-apache-flink-connector) for [Pravega](http://pravega.io), Dell/EMC's streaming storage system.
+- Uber announced AthenaX, a streaming SQL platform [powered by Apache Flink](https://data-artisans.com/blog/uber-introduces-open-source-athenax-streaming-sql-platform-apache-flink).
+- dataArtisans announced an early access program of a SaaS product based on Apache Flink, [dA Platform 2](https://data-artisans.com/blog/da-platform-2-stateful-stream-processing-with-apache-flink-made-easier).
+
+### Feature Timeline in 2017
+
+Just in time for the end of the year, our 1.4 release [read the full release announcement](http://flink.apache.org/news/2017/12/12/release-1.4.0.html) landed in mid-December culminating 5 months of work and the resolution of more than 900 issues. This is the fifth major release in the 1.x.y series.
+
+Here's a selection of major features added to Flink over the course of 2017:
+
+
+
+If you take a look at [the resolved issues and enhancements for 2017 on Jira](https://issues.apache.org/jira/browse/FLINK-5016?jql=project%20%3D%20FLINK%20AND%20issuetype%20in%20(Bug%2C%20Improvement%2C%20%22New%20Feature%22)%20AND%20status%20in%20(Resolved%2C%20Closed)%20AND%20resolved%20%3E%3D%202017-01-01%20AND%20resolved%20%3C%3D%202017-12-31%20ORDER%20BY%20resolved%20ASC) you can see that the community resolved over 1,831 issues and feature additions.
+
+[Regarding roadmap commitments from 2016](/news/2016/12/19/2016-year-in-review.html#looking-ahead-to-2017), there is mixed news, with some items a part of current releases, others scheduled for upcoming releases and some that remain under discussion.
+
+## Looking ahead to 2018
+
+A good source of information about the Flink community's roadmap is the list of [Flink Improvement Proposals (FLIPs)](https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals) in the project wiki. Below, we'll highlight a selection of FLIPs accepted by the community as well as some that are still under discussion.
+
+Work is already underway on a number of these features, and some will be included in Flink 1.5 at the beginning of 2018.
+
+- **Improved BLOB storage architecture**, as described in [FLIP-19](https://cwiki.apache.org/confluence/display/FLINK/FLIP-19:+Improved+BLOB+storage+architecture) to consolidate API usage and improve concurrency.
+- **Integration of SQL and CEP**, as described in [FLIP-20](https://cwiki.apache.org/confluence/display/FLINK/FLIP-20:+Integration+of+SQL+and+CEP) to allow developers to create complex event processing (CEP) patterns using SQL statements.
+- **Unified checkpoints and savepoints**, as described in [FLIP-10](https://cwiki.apache.org/confluence/display/FLINK/FLIP-10:+Unify+Checkpoints+and+Savepoints), to allow savepoints to be triggered automatically–important for program updates for the sake of error handling because savepoints allow the user to modify both the job and Flink version whereas checkpoints can only be recovered with the same job.
+- **An improved Flink deployment and process model**, as described in [FLIP-6](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65147077), to allow for better integration with Flink and cluster managers and deployment technologies such as Mesos, Docker, and Kubernetes.
+- **Fine-grained recovery from task failures**, as described in [FLIP-1](https://cwiki.apache.org/confluence/display/FLINK/FLIP-1+:+Fine+Grained+Recovery+from+Task+Failures) to improve recovery efficiency and only re-execute failed tasks, reducing the amount of state that Flink needs to transfer on recovery.
+- **An SQL Client**, as described in [FLIP-24](https://cwiki.apache.org/confluence/display/FLINK/FLIP-24+-+SQL+Client) to add a service and a client to execute SQL queries against batch and streaming tables.
+- **Serving of machine learning models**, as described in [FLIP-23](https://cwiki.apache.org/confluence/display/FLINK/FLIP-23+-+Model+Serving) to add a library that allows users to apply offline-trained machine learning models to data streams.
+
+If you're interested in getting involved with Flink, we encourage you to take a look at the FLIPs and to join the discussion via the [Flink mailing lists](http://flink.apache.org/community.html#mailing-lists).
+
+Lastly, we'd like to extend a sincere thank you to all the Flink community for making 2017 a great year!
diff --git a/docs/content.tr/posts/2018-01-30-incremental-checkpointing.md b/docs/content.tr/posts/2018-01-30-incremental-checkpointing.md
new file mode 100644
index 0000000000..7d15a5f6bb
--- /dev/null
+++ b/docs/content.tr/posts/2018-01-30-incremental-checkpointing.md
@@ -0,0 +1,103 @@
+---
+authors:
+- name: Stefan Ricther
+ stefan: null
+ twitter: StefanRRicther
+- chris: null
+ name: Chris Ward
+ twitter: chrischinch
+date: "2018-01-30T12:00:00Z"
+excerpt: Flink 1.3.0 introduced incremental checkpointing, making it possible for
+ applications with large state to generate checkpoints more efficiently.
+title: 'Managing Large State in Apache Flink: An Intro to Incremental Checkpointing'
+aliases:
+- /features/2018/01/30/incremental-checkpointing.html
+---
+
+Apache Flink was purpose-built for _stateful_ stream processing. However, what is state in a stream processing application? I defined state and stateful stream processing in a [previous blog post](http://flink.apache.org/features/2017/07/04/flink-rescalable-state.html), and in case you need a refresher, _state is defined as memory in an application's operators that stores information about previously-seen events that you can use to influence the processing of future events_.
+
+State is a fundamental, enabling concept in stream processing required for a majority of complex use cases. Some examples highlighted in the [Flink documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.3/dev/stream/state.html):
+
+- When an application searches for certain event patterns, the state stores the sequence of events encountered so far.
+- When aggregating events per minute, the state holds the pending aggregates.
+- When training a machine learning model over a stream of data points, the state holds the current version of the model parameters.
+
+However, stateful stream processing is only useful in production environments if the state is fault tolerant. "Fault tolerance" means that even if there's a software or machine failure, the computed end-result is accurate, with no data loss or double-counting of events.
+
+Flink's fault tolerance has always been a powerful and popular feature, minimizing the impact of software or machine failure on your business and making it possible to guarantee exactly-once results from a Flink application.
+
+Core to this is [checkpointing]({{< param DocsBaseUrl >}}flink-docs-release-1.3/dev/stream/checkpointing.html), which is the mechanism Flink uses to make application state fault tolerant. A checkpoint in Flink is a global, asynchronous snapshot of application state that's taken on a regular interval and sent to durable storage (usually, a distributed file system). In the event of a failure, Flink restarts an application using the most recently completed checkpoint as a starting point. Some Apache Flink users run applications with gigabytes or even terabytes of application state. These users reported that with such large state, creating a checkpoint was often a slow and resource intensive operation, which is why in Flink 1.3 we introduced 'incremental checkpointing.'
+
+Before incremental checkpointing, every single Flink checkpoint consisted of the full state of an application. We created the incremental checkpointing feature after we noticed that writing the full state for every checkpoint was often unnecessary, as the state changes from one checkpoint to the next were rarely that large. Incremental checkpointing instead maintains the differences (or 'delta') between each checkpoint and stores only the differences between the last checkpoint and the current state.
+
+Incremental checkpoints can provide a significant performance improvement for jobs with a very large state. Early testing of the feature by a production user with terabytes of state shows a drop in checkpoint time from more than 3 minutes down to 30 seconds after implementing incremental checkpoints. This is because the checkpoint doesn't need to transfer the full state to durable storage on each checkpoint.
+
+### How to Start
+
+Currently, you can only use incremental checkpointing with a RocksDB state back-end, and Flink uses RocksDB's internal backup mechanism to consolidate checkpoint data over time. As a result, the incremental checkpoint history in Flink does not grow indefinitely, and Flink eventually consumes and prunes old checkpoints automatically.
+
+To enable incremental checkpointing in your application, I recommend you read the [the Apache Flink documentation on checkpointing]({{< param DocsBaseUrl >}}flink-docs-release-1.4/ops/state/large_state_tuning.html#tuning-rocksdb) for full details, but in summary, you enable checkpointing as normal, but enable incremental checkpointing in the constructor by setting the second parameter to `true`.
+
+#### Java Example
+
+```java
+StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
+env.setStateBackend(new RocksDBStateBackend(filebackend, true));
+```
+
+#### Scala Example
+
+```scala
+val env = StreamExecutionEnvironment.getExecutionEnvironment()
+env.setStateBackend(new RocksDBStateBackend(filebackend, true))
+```
+
+By default, Flink retains 1 completed checkpoint, so if you need a higher number, [you can configure it with the following flag]({{< param DocsBaseUrl >}}flink-docs-master/dev/stream/state/checkpointing.html#related-config-options):
+
+```java
+state.checkpoints.num-retained
+```
+
+### How it Works
+
+Flink's incremental checkpointing uses [RocksDB checkpoints](https://github.com/facebook/rocksdb/wiki/Checkpoints) as a foundation. RocksDB is a key-value store based on '[log-structured-merge](https://en.wikipedia.org/wiki/Log-structured_merge-tree)' (LSM) trees that collects all changes in a mutable (changeable) in-memory buffer called a 'memtable'. Any updates to the same key in the memtable replace previous values, and once the memtable is full, RocksDB writes it to disk with all entries sorted by their key and with light compression applied. Once RocksDB writes the memtable to disk it is immutable (unchangeable) and is now called a 'sorted-string-table' (sstable).
+
+A 'compaction' background task merges sstables to consolidate potential duplicates for each key, and over time RocksDB deletes the original sstables, with the merged sstable containing all information from across all the other sstables.
+
+On top of this, Flink tracks which sstable files RocksDB has created and deleted since the previous checkpoint, and as the sstables are immutable, Flink uses this to figure out the state changes. To do this, Flink triggers a flush in RocksDB, forcing all memtables into sstables on disk, and hard-linked in a local temporary directory. This process is synchronous to the processing pipeline, and Flink performs all further steps asynchronously and does not block processing.
+
+Then Flink copies all new sstables to stable storage (e.g., HDFS, S3) to reference in the new checkpoint. Flink doesn't copy all sstables that already existed in the previous checkpoint to stable storage but re-reference them. Any new checkpoints will no longer reference deleted files as deleted sstables in RocksDB are always the result of compaction, and it eventually replaces old tables with an sstable that is the result of a merge. This how in Flink's incremental checkpoints can prune the checkpoint history.
+
+For tracking changes between checkpoints, the uploading of consolidated tables is redundant work. Flink performs the process incrementally, and typically adds only a small overhead, so we consider this worthwhile because it allows Flink to keep a shorter history of checkpoints to consider in a recovery.
+
+#### An Example
+
+
+_Example setup_
+
+Take an example with a subtask of one operator that has a keyed state, and the number of retained checkpoints set at **2**. The columns in the figure above show the state of the local RocksDB instance for each checkpoint, the files it references, and the counts in the shared state registry after the checkpoint completes.
+
+For checkpoint 'CP 1', the local RocksDB directory contains two sstable files, it considers these new and uploads them to stable storage using directory names that match the checkpoint name. When the checkpoint completes, Flink creates the two entries in the shared state registry and sets their counts to '1'. The key in the shared state registry is a composite of an operator, subtask, and the original sstable file name. The registry also keeps a mapping from the key to the file path in stable storage.
+
+For checkpoint 'CP 2', RocksDB has created two new sstable files, and the two older ones still exist. For checkpoint 'CP 2', Flink adds the two new files to stable storage and can reference the previous two files. When the checkpoint completes, Flink increases the counts for all referenced files by 1.
+
+For checkpoint 'CP 3', RocksDB's compaction has merged `sstable-(1)`, `sstable-(2)`, and `sstable-(3)` into `sstable-(1,2,3)` and deleted the original files. This merged file contains the same information as the source files, with all duplicate entries eliminated. In addition to this merged file, `sstable-(4)` still exists and there is now a new `sstable-(5)` file. Flink adds the new `sstable-(1,2,3)` and `sstable-(5)` files to stable storage, `sstable-(4)` is re-referenced from checkpoint 'CP 2' and increases the counts for referenced files by 1. The older 'CP 1' checkpoint is now deleted as the number of retained checkpoints (2) has been reached. As part of this deletion, Flink decreases the counts for all files referenced 'CP 1', (`sstable-(1)` and `sstable-(2)`), by 1.
+
+For checkpoint 'CP-4', RocksDB has merged `sstable-(4)`, `sstable-(5)`, and a new `sstable-(6)` into `sstable-(4,5,6)`. Flink adds this new table to stable storage and references it together with `sstable-(1,2,3)`, it increases the counts for `sstable-(1,2,3)` and `sstable-(4,5,6)` by 1 and then deletes 'CP-2' as the number of retained checkpoints has been reached. As the counts for `sstable-(1)`, `sstable-(2)`, and `sstable-(3)` have now dropped to 0, and Flink deletes them from stable storage.
+
+### Race Conditions and Concurrent Checkpoints
+
+As Flink can execute multiple checkpoints in parallel, sometimes new checkpoints start before confirming previous checkpoints as completed. Because of this, you should consider which the previous checkpoint to use as a basis for a new incremental checkpoint. Flink only references state from a checkpoint confirmed by the checkpoint coordinator so that it doesn't unintentionally reference a deleted shared file.
+
+### Restoring Checkpoints and Performance Considerations
+
+If you enable incremental checkpointing, there are no further configuration steps needed to recover your state in case of failure. If a failure occurs, Flink's `JobManager` tells all tasks to restore from the last completed checkpoint, be it a full or incremental checkpoint. Each `TaskManager` then downloads their share of the state from the checkpoint on the distributed file system.
+
+Though the feature can lead to a substantial improvement in checkpoint time for users with a large state, there are trade-offs to consider with incremental checkpointing. Overall, the process reduces the checkpointing time during normal operations but can lead to a longer recovery time depending on the size of your state. If the cluster failure is particularly severe and the Flink `TaskManager`s have to read from multiple checkpoints, recovery can be a slower operation than when using non-incremental checkpointing. You can also no longer delete old checkpoints as newer checkpoints need them, and the history of differences between checkpoints can grow indefinitely over time. You need to plan for larger distributed storage to maintain the checkpoints and the network overhead to read from it.
+
+There are some strategies for improving the convenience/performance trade-off, and I recommend you read [the Flink documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.4/ops/state/checkpoints.html#basics-of-incremental-checkpoints) for more details.
+
+_This post originally appeared on the data Artisans blog and was contributed to the Flink blog by Stefan Richter and Chris Ward._
+
+
+
diff --git a/docs/content.tr/posts/2018-02-15-release-1.4.1.md b/docs/content.tr/posts/2018-02-15-release-1.4.1.md
new file mode 100644
index 0000000000..306321bb6a
--- /dev/null
+++ b/docs/content.tr/posts/2018-02-15-release-1.4.1.md
@@ -0,0 +1,176 @@
+---
+date: "2018-02-15T12:00:00Z"
+title: Apache Flink 1.4.1 Released
+aliases:
+- /news/2018/02/15/release-1.4.1.html
+---
+
+The Apache Flink community released the first bugfix version of the Apache Flink 1.4 series.
+
+This release includes more than 60 fixes and minor improvements for Flink 1.4.0. The list below includes a detailed list of all fixes.
+
+We highly recommend all users to upgrade to Flink 1.4.1.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.4.1
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.4.1
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.4.1
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-6321 ] - RocksDB state backend Checkpointing is not working with KeyedCEP.
+
+[FLINK-7499 ] - double buffer release in SpillableSubpartitionView
+
+[FLINK-7756 ] - RocksDB state backend Checkpointing (Async and Incremental) is not working with CEP.
+
+[FLINK-7760 ] - Restore failing from external checkpointing metadata.
+
+[FLINK-8323 ] - Fix Mod scala function bug
+
+
+
+ Bug
+
+
+[FLINK-5506 ] - Java 8 - CommunityDetection.java:158 - java.lang.NullPointerException
+
+[FLINK-6951 ] - Incompatible versions of httpcomponents jars for Flink kinesis connector
+
+[FLINK-7949 ] - AsyncWaitOperator is not restarting when queue is full
+
+[FLINK-8145 ] - IOManagerAsync not properly shut down in various tests
+
+[FLINK-8200 ] - RocksDBAsyncSnapshotTest should use temp fold instead of fold with fixed name
+
+[FLINK-8226 ] - Dangling reference generated after NFA clean up timed out SharedBufferEntry
+
+[FLINK-8230 ] - NPE in OrcRowInputFormat on nested structs
+
+[FLINK-8235 ] - Cannot run spotbugs for single module
+
+[FLINK-8242 ] - ClassCastException in OrcTableSource.toOrcPredicate
+
+[FLINK-8248 ] - RocksDB state backend Checkpointing is not working with KeyedCEP in 1.4
+
+[FLINK-8249 ] - Kinesis Producer didnt configure region
+
+[FLINK-8261 ] - Typos in the shading exclusion for jsr305 in the quickstarts
+
+[FLINK-8263 ] - Wrong packaging of flink-core in scala quickstarty
+
+[FLINK-8265 ] - Missing jackson dependency for flink-mesos
+
+[FLINK-8270 ] - TaskManagers do not use correct local path for shipped Keytab files in Yarn deployment modes
+
+[FLINK-8275 ] - Flink YARN deployment with Kerberos enabled not working
+
+[FLINK-8278 ] - Scala examples in Metric documentation do not compile
+
+[FLINK-8283 ] - FlinkKafkaConsumerBase failing on Travis with no output in 10min
+
+[FLINK-8295 ] - Netty shading does not work properly
+
+[FLINK-8306 ] - FlinkKafkaConsumerBaseTest has invalid mocks on final methods
+
+[FLINK-8318 ] - Conflict jackson library with ElasticSearch connector
+
+[FLINK-8325 ] - Add COUNT AGG support constant parameter, i.e. COUNT(*), COUNT(1)
+
+[FLINK-8352 ] - Flink UI Reports No Error on Job Submission Failures
+
+[FLINK-8355 ] - DataSet Should not union a NULL row for AGG without GROUP BY clause.
+
+[FLINK-8371 ] - Buffers are not recycled in a non-spilled SpillableSubpartition upon release
+
+[FLINK-8398 ] - Stabilize flaky KinesisDataFetcherTests
+
+[FLINK-8406 ] - BucketingSink does not detect hadoop file systems
+
+[FLINK-8409 ] - Race condition in KafkaConsumerThread leads to potential NPE
+
+[FLINK-8419 ] - Kafka consumer's offset metrics are not registered for dynamically discovered partitions
+
+[FLINK-8421 ] - HeapInternalTimerService should reconfigure compatible key / namespace serializers on restore
+
+[FLINK-8433 ] - Update code example for "Managed Operator State" documentation
+
+[FLINK-8461 ] - Wrong logger configurations for shaded Netty
+
+[FLINK-8466 ] - ErrorInfo needs to hold Exception as SerializedThrowable
+
+[FLINK-8484 ] - Kinesis consumer re-reads closed shards on job restart
+
+[FLINK-8485 ] - Running Flink inside Intellij no longer works after upgrading from 1.3.2 to 1.4.0
+
+[FLINK-8489 ] - Data is not emitted by second ElasticSearch connector
+
+[FLINK-8496 ] - WebUI does not display TM MemorySegment metrics
+
+[FLINK-8499 ] - Kryo must not be child-first loaded
+
+[FLINK-8522 ] - DefaultOperatorStateBackend writes data in checkpoint that is never read.
+
+[FLINK-8559 ] - Exceptions in RocksDBIncrementalSnapshotOperation#takeSnapshot cause job to get stuck
+
+[FLINK-8561 ] - SharedBuffer line 573 uses == to compare BufferEntries instead of .equals.
+
+
+
+ Improvement
+
+
+[FLINK-8079 ] - Skip remaining E2E tests if one failed
+
+[FLINK-8202 ] - Update queryable section on configuration page
+
+[FLINK-8243 ] - OrcTableSource should recursively read all files in nested directories of the input path.
+
+[FLINK-8260 ] - Document API of Kafka 0.11 Producer
+
+[FLINK-8264 ] - Add Scala to the parent-first loading patterns
+
+[FLINK-8271 ] - upgrade from deprecated classes to AmazonKinesis
+
+[FLINK-8287 ] - Flink Kafka Producer docs should clearly state what partitioner is used by default
+
+[FLINK-8296 ] - Rework FlinkKafkaConsumerBestTest to not use Java reflection for dependency injection
+
+[FLINK-8346 ] - add S3 signature v4 workaround to docs
+
+[FLINK-8362 ] - Shade Elasticsearch dependencies away
+
+[FLINK-8455 ] - Add Hadoop to the parent-first loading patterns
+
+[FLINK-8473 ] - JarListHandler may fail with NPE if directory is deleted
+
+[FLINK-8571 ] - Provide an enhanced KeyedStream implementation to use ForwardPartitioner
+
+
+
+ Test
+
+
+[FLINK-8472 ] - Extend migration tests for Flink 1.4
+
+
diff --git a/docs/content.tr/posts/2018-02-28-end-to-end-exactly-once-apache-flink.md b/docs/content.tr/posts/2018-02-28-end-to-end-exactly-once-apache-flink.md
new file mode 100644
index 0000000000..2044740e0c
--- /dev/null
+++ b/docs/content.tr/posts/2018-02-28-end-to-end-exactly-once-apache-flink.md
@@ -0,0 +1,151 @@
+---
+authors:
+- name: Piotr Nowojski
+ piotr: null
+ twitter: PiotrNowojski
+- mike: null
+ name: Mike Winters
+ twitter: wints
+date: "2018-02-28T12:00:00Z"
+excerpt: Flink 1.4.0 introduced a new feature that makes it possible to build end-to-end
+ exactly-once applications with Flink and data sources and sinks that support transactions.
+title: An Overview of End-to-End Exactly-Once Processing in Apache Flink (with Apache
+ Kafka, too!)
+aliases:
+- /features/2018/03/01/end-to-end-exactly-once-apache-flink.html
+---
+
+*This post is an adaptation of [Piotr Nowojski's presentation from Flink Forward Berlin 2017](https://berlin.flink-forward.org/kb_sessions/hit-me-baby-just-one-time-building-end-to-end-exactly-once-applications-with-flink/). You can find the slides and a recording of the presentation on the Flink Forward Berlin website.*
+
+Apache Flink 1.4.0, released in December 2017, introduced a significant milestone for stream processing with Flink: a new feature called `TwoPhaseCommitSinkFunction` ([relevant Jira here](https://issues.apache.org/jira/browse/FLINK-7210)) that extracts the common logic of the two-phase commit protocol and makes it possible to build end-to-end exactly-once applications with Flink and a selection of data sources and sinks, including Apache Kafka versions 0.11 and beyond. It provides a layer of abstraction and requires a user to implement only a handful of methods to achieve end-to-end exactly-once semantics.
+
+If that's all you need to hear, let us point you [to the relevant place in the Flink documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.4/api/java/org/apache/flink/streaming/api/functions/sink/TwoPhaseCommitSinkFunction.html), where you can read about how to put `TwoPhaseCommitSinkFunction` to use.
+
+But if you'd like to learn more, in this post, we'll share an in-depth overview of the new feature and what is happening behind the scenes in Flink.
+
+Throughout the rest of this post, we'll:
+
+* Describe the role of Flink's checkpoints for guaranteeing exactly-once results within a Flink application.
+* Show how Flink interacts with data sources and data sinks via the two-phase commit protocol to deliver _end-to-end_ exactly-once guarantees.
+* Walk through a simple example on how to use `TwoPhaseCommitSinkFunction` to implement an exactly-once file sink.
+
+## Exactly-once Semantics Within an Apache Flink Application
+
+When we say "exactly-once semantics", what we mean is that each incoming event affects the final results exactly once. Even in case of a machine or software failure, there's no duplicate data and no data that goes unprocessed.
+
+Flink has long provided exactly-once semantics _within_ a Flink application. Over the past few years, we've [written in depth about Flink's checkpointing](https://data-artisans.com/blog/high-throughput-low-latency-and-exactly-once-stream-processing-with-apache-flink), which is at the core of Flink's ability to provide exactly-once semantics. The Flink documentation also [provides a thorough overview of the feature]({{< param DocsBaseUrl >}}flink-docs-release-1.4/ops/state/checkpoints.html).
+
+Before we continue, here's a quick summary of the checkpointing algorithm because understanding checkpoints is necessary for understanding this broader topic.
+
+A checkpoint in Flink is a consistent snapshot of:
+
+1. The current state of an application
+2. The position in an input stream
+
+Flink generates checkpoints on a regular, configurable interval and then writes the checkpoint to a persistent storage system, such as S3 or HDFS. Writing the checkpoint data to the persistent storage happens asynchronously, which means that a Flink application continues to process data during the checkpointing process.
+
+In the event of a machine or software failure and upon restart, a Flink application resumes processing from the most recent successfully-completed checkpoint; Flink restores application state and rolls back to the correct position in the input stream from a checkpoint before processing starts again. This means that Flink computes results as though the failure never occurred.
+
+Before Flink 1.4.0, exactly-once semantics were limited to the scope of _a Flink application only_ and did not extend to most of the external systems to which Flink sends data after processing.
+
+But Flink applications operate in conjunction with a wide range of data sinks, and developers should be able to maintain exactly-once semantics beyond the context of one component.
+
+To provide _end-to-end exactly-once_ semantics--that is, semantics that also apply to the external systems that Flink writes to in addition to the state of the Flink application--these external systems must provide a means to commit or roll back writes that coordinate with Flink's checkpoints.
+
+One common approach for coordinating commits and rollbacks in a distributed system is the [two-phase commit protocol](https://en.wikipedia.org/wiki/Two-phase_commit_protocol). In the next section, we'll go behind the scenes and discuss how Flink's `TwoPhaseCommitSinkFunction `utilizes the two-phase commit protocol to provide end-to-end exactly-once semantics.
+
+## End-to-end Exactly Once Applications with Apache Flink
+
+We'll walk through the two-phase commit protocol and how it enables end-to-end exactly-once semantics in a sample Flink application that reads from and writes to Kafka. Kafka is a popular messaging system to use along with Flink, and Kafka recently added support for transactions with its 0.11 release. [This means that Flink now has the necessary mechanism to provide end-to-end exactly-once semantics]({{< param DocsBaseUrl >}}flink-docs-release-1.4/dev/connectors/kafka.html#kafka-011) in applications when receiving data from and writing data to Kafka.
+
+Flink's support for end-to-end exactly-once semantics is not limited to Kafka and you can use it with any source / sink that provides the necessary coordination mechanism. For example, [Pravega](http://pravega.io/), an open-source streaming storage system from Dell/EMC, also supports end-to-end exactly-once semantics with Flink via the `TwoPhaseCommitSinkFunction`.
+
+
+
+
+
+In the sample Flink application that we'll discuss today, we have:
+
+* A data source that reads from Kafka (in Flink, a [KafkaConsumer]({{< param DocsBaseUrl >}}flink-docs-release-1.4/dev/connectors/kafka.html#kafka-consumer))
+* A windowed aggregation
+* A data sink that writes data back to Kafka (in Flink, a [KafkaProducer]({{< param DocsBaseUrl >}}flink-docs-release-1.4/dev/connectors/kafka.html#kafka-producer))
+
+For the data sink to provide exactly-once guarantees, it must write all data to Kafka within the scope of a transaction. A commit bundles all writes between two checkpoints.
+
+This ensures that writes are rolled back in case of a failure.
+
+However, in a distributed system with multiple, concurrently-running sink tasks, a simple commit or rollback is not sufficient, because all of the components must "agree" together on committing or rolling back to ensure a consistent result. Flink uses the two-phase commit protocol and its pre-commit phase to address this challenge.
+
+The starting of a checkpoint represents the "pre-commit" phase of our two-phase commit protocol. When a checkpoint starts, the Flink JobManager injects a checkpoint barrier (which separates the records in the data stream into the set that goes into the current checkpoint vs. the set that goes into the next checkpoint) into the data stream.
+
+The barrier is passed from operator to operator. For every operator, it triggers the operator's state backend to take a snapshot of its state.
+
+
+
+
+
+The data source stores its Kafka offsets, and after completing this, it passes the checkpoint barrier to the next operator.
+
+This approach works if an operator has internal state _only_. _Internal state_ is everything that is stored and managed by Flink's state backends - for example, the windowed sums in the second operator. When a process has only internal state, there is no need to perform any additional action during pre-commit aside from updating the data in the state backends before it is checkpointed. Flink takes care of correctly committing those writes in case of checkpoint success or aborting them in case of failure.
+
+
+
+
+
+However, when a process has _external_ state, this state must be handled a bit differently. External state usually comes in the form of writes to an external system such as Kafka. In that case, to provide exactly-once guarantees, the external system must provide support for transactions that integrates with a two-phase commit protocol.
+
+We know that the data sink in our example has such external state because it's writing data to Kafka. In this case, in the pre-commit phase, the data sink must pre-commit its external transaction in addition to writing its state to the state backend.
+
+
+
+
+
+The pre-commit phase finishes when the checkpoint barrier passes through all of the operators and the triggered snapshot callbacks complete. At this point the checkpoint completed successfully and consists of the state of the entire application, including pre-committed external state. In case of a failure, we would re-initialize the application from this checkpoint.
+
+The next step is to notify all operators that the checkpoint has succeeded. This is the commit phase of the two-phase commit protocol and the JobManager issues checkpoint-completed callbacks for every operator in the application. The data source and window operator have no external state, and so in the commit phase, these operators don't have to take any action. The data sink does have external state, though, and commits the transaction with the external writes.
+
+
+
+
+
+So let's put all of these different pieces together:
+
+* Once all of the operators complete their pre-commit, they issue a commit.
+* If at least one pre-commit fails, all others are aborted, and we roll back to the previous successfully-completed checkpoint.
+* After a successful pre-commit, the commit _must_ be guaranteed to eventually succeed -- both our operators and our external system need to make this guarantee. If a commit fails (for example, due to an intermittent network issue), the entire Flink application fails, restarts according to the user's restart strategy, and there is another commit attempt. This process is critical because if the commit does not eventually succeed, data loss occurs.
+
+Therefore, we can be sure that all operators agree on the final outcome of the checkpoint: all operators agree that the data is either committed or that the commit is aborted and rolled back.
+
+## Implementing the Two-Phase Commit Operator in Flink
+
+All the logic required to put a two-phase commit protocol together can be a little bit complicated and that's why Flink extracts the common logic of the two-phase commit protocol into the abstract `TwoPhaseCommitSinkFunction` class`. `
+
+Let's discuss how to extend a `TwoPhaseCommitSinkFunction` on a simple file-based example. We need to implement only four methods and present their implementations for an exactly-once file sink:
+
+1. `beginTransaction - `to begin the transaction, we create a temporary file in a temporary directory on our destination file system. Subsequently, we can write data to this file as we process it.
+1. `preCommit - `on pre-commit, we flush the file, close it, and never write to it again. We'll also start a new transaction for any subsequent writes that belong to the next checkpoint.
+1. `commit - `on commit, we atomically move the pre-committed file to the actual destination directory. Please note that this increases the latency in the visibility of the output data.
+1. `abort - `on abort, we delete the temporary file.
+
+As we know, if there's any failure, Flink restores the state of the application to the latest successful checkpoint. One potential catch is in a rare case when the failure occurs after a successful pre-commit but before notification of that fact (a commit) reaches our operator. In that case, Flink restores our operator to the state that has already been pre-committed but not yet committed.
+
+We must save enough information about pre-committed transactions in checkpointed state to be able to either `abort` or `commit` transactions after a restart. In our example, this would be the path to the temporary file and target directory.
+
+The `TwoPhaseCommitSinkFunction` takes this scenario into account, and it always issues a preemptive commit when restoring state from a checkpoint. It is our responsibility to implement a commit in an idempotent way. Generally, this shouldn't be an issue. In our example, we can recognize such a situation: the temporary file is not in the temporary directory, but has already been moved to the target directory.
+
+There are a handful of other edge cases that `TwoPhaseCommitSinkFunction` takes into account, too. [Learn more in the Flink documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.4/api/java/org/apache/flink/streaming/api/functions/sink/TwoPhaseCommitSinkFunction.html).
+
+## Wrapping Up
+
+If you've made it this far, thanks for staying with us through a detailed post. Here are some key points that we covered:
+
+* Flink's checkpointing system serves as Flink's basis for supporting a two-phase commit protocol and providing end-to-end exactly-once semantics.
+* An advantage of this approach is that Flink does not materialize data in transit the way that some other systems do--there's no need to write every stage of the computation to disk as is the case is most batch processing.
+* Flink's new `TwoPhaseCommitSinkFunction` extracts the common logic of the two-phase commit protocol and makes it possible to build end-to-end exactly-once applications with Flink and external systems that support transactions
+* Starting with [Flink 1.4.0](https://data-artisans.com/blog/announcing-the-apache-flink-1-4-0-release), both the Pravega and Kafka 0.11 producers provide exactly-once semantics; Kafka introduced transactions for the first time in Kafka 0.11, which is what made the Kafka exactly-once producer possible in Flink.
+* The [Kafka 0.11 producer]({{< param DocsBaseUrl >}}flink-docs-release-1.4/dev/connectors/kafka.html#kafka-011) is implemented on top of the `TwoPhaseCommitSinkFunction`, and it offers very low overhead compared to the at-least-once Kafka producer.
+
+We're very excited about what this new feature enables, and we look forward to being able to support additional producers with the `TwoPhaseCommitSinkFunction` in the future.
+
+*This post first appeared on the data Artisans blog and was contributed to Apache Flink and the Flink blog by the original authors Piotr Nowojski and Mike Winters.*
+
diff --git a/docs/content.tr/posts/2018-03-08-release-1.4.2.md b/docs/content.tr/posts/2018-03-08-release-1.4.2.md
new file mode 100644
index 0000000000..948e8732eb
--- /dev/null
+++ b/docs/content.tr/posts/2018-03-08-release-1.4.2.md
@@ -0,0 +1,92 @@
+---
+date: "2018-03-08T12:00:00Z"
+title: Apache Flink 1.4.2 Released
+aliases:
+- /news/2018/03/08/release-1.4.2.html
+---
+
+The Apache Flink community released the second bugfix version of the Apache Flink 1.4 series.
+
+This release includes more than 10 fixes and minor improvements for Flink 1.4.1. The list below includes a detailed list of all fixes.
+
+We highly recommend all users to upgrade to Flink 1.4.2.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.4.2
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.4.2
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.4.2
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-6321 ] - RocksDB state backend Checkpointing is not working with KeyedCEP.
+
+[FLINK-7756 ] - RocksDB state backend Checkpointing (Async and Incremental) is not working with CEP.
+
+
+
+ Bug
+
+
+[FLINK-8423 ] - OperatorChain#pushToOperator catch block may fail with NPE
+
+[FLINK-8451 ] - CaseClassSerializer is not backwards compatible in 1.4
+
+[FLINK-8520 ] - CassandraConnectorITCase.testCassandraTableSink unstable on Travis
+
+[FLINK-8621 ] - PrometheusReporterTest.endpointIsUnavailableAfterReporterIsClosed unstable on Travis
+
+[FLINK-8692 ] - Mistake in MyMapFunction code snippet
+
+[FLINK-8735 ] - Add savepoint migration ITCase that covers operator state
+
+[FLINK-8741 ] - KafkaFetcher09/010/011 uses wrong user code classloader
+
+[FLINK-8772 ] - FlinkKafkaConsumerBase partitions discover missing a log parameter
+
+[FLINK-8791 ] - Fix documentation on how to link dependencies
+
+[FLINK-8798 ] - Make commons-logging a parent-first pattern
+
+[FLINK-8849 ] - Wrong link from concepts/runtime to doc on chaining
+
+
+
+ Improvement
+
+
+[FLINK-8202 ] - Update queryable section on configuration page
+
+[FLINK-8574 ] - Add timestamps to travis logging messages
+
+[FLINK-8576 ] - Log message for QueryableState loading failure too verbose
+
+[FLINK-8652 ] - Reduce log level of QueryableStateClient.getKvState() to DEBUG
+
+
+
+ Task
+
+
+[FLINK-8308 ] - Update yajl-ruby dependency to 1.3.1 or higher
+
+
diff --git a/docs/content.tr/posts/2018-03-15-release-1.3.3.md b/docs/content.tr/posts/2018-03-15-release-1.3.3.md
new file mode 100644
index 0000000000..b1c467a464
--- /dev/null
+++ b/docs/content.tr/posts/2018-03-15-release-1.3.3.md
@@ -0,0 +1,61 @@
+---
+date: "2018-03-15T12:00:00Z"
+title: Apache Flink 1.3.3 Released
+aliases:
+- /news/2018/03/15/release-1.3.3.html
+---
+
+The Apache Flink community released the third bugfix version of the Apache Flink 1.3 series.
+
+This release includes 4 critical fixes related to checkpointing and recovery. The list below includes a detailed list of all fixes.
+
+We highly recommend all Flink 1.3 series users to upgrade to Flink 1.3.3.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.3.3
+
+
+ org.apache.flink
+ flink-streaming-java_2.10
+ 1.3.3
+
+
+ org.apache.flink
+ flink-clients_2.10
+ 1.3.3
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-7783 ] - Don't always remove checkpoints in ZooKeeperCompletedCheckpointStore#recover()
+
+
+
+ Bug
+
+
+[FLINK-7283 ] - PythonPlanBinderTest issues with python paths
+
+[FLINK-8487 ] - State loss after multiple restart attempts
+
+[FLINK-8807 ] - ZookeeperCompleted checkpoint store can get stuck in infinite loop
+
+
+
+ Improvement
+
+
+[FLINK-8890 ] - Compare checkpoints with order in CompletedCheckpoint.checkpointsMatch()
+
+
diff --git a/docs/content.tr/posts/2018-05-18-release-1.5.0.md b/docs/content.tr/posts/2018-05-18-release-1.5.0.md
new file mode 100644
index 0000000000..4fd66c0b6b
--- /dev/null
+++ b/docs/content.tr/posts/2018-05-18-release-1.5.0.md
@@ -0,0 +1,114 @@
+---
+authors:
+- fabian: null
+ name: Fabian Hueske
+ twitter: fhueske
+date: "2018-05-18T10:00:00Z"
+title: Apache Flink 1.5.0 Release Announcement
+aliases:
+- /news/2018/05/25/release-1.5.0.html
+---
+
+The Apache Flink community is thrilled to announce the 1.5.0 release. Over the past 5 months, the Flink community has been working hard to resolve more than 780 issues. Please check the [complete changelog](https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12341764&projectId=12315522) for more detail.
+
+Flink 1.5.0 is the sixth major release in the 1.x.y series. As usual, it is API-compatible with previous 1.x.y releases for APIs annotated with the `@Public` annotation.
+
+We encourage everyone to [download the release](http://flink.apache.org/downloads.html) and check out the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.5/).
+Feedback through the Flink [mailing lists](http://flink.apache.org/community.html#mailing-lists) or [JIRA](https://issues.apache.org/jira/projects/FLINK/summary) is, as always, very much appreciated!
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html) on the Flink project site.
+
+## Flink 1.5 - Streaming Evolved
+
+We believe that the field of stream processing, and Apache Flink with it, is taking another major leap at the moment. Stream processing is not just faster analytics and a more principled way of building fast continuous data pipelines. Stream processing is becoming a paradigm to build data-driven and data-intensive applications - it brings together data processing logic and application/business logic.
+
+To help users realize the potential of this change, we spent a lot of effort in this release to rework some fundamental pieces of Flink. We want Flink to feel natural to users who do data engineering / data processing, as well as users who build data/event-driven applications (and of course those who combine both aspects inside their applications). This is an ongoing journey, but here are the first steps on this way:
+
+* We have **redesigned and reimplemented large parts of Flink's process model**. This effort has been tracked under the name [FLIP-6](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65147077). While not all is completed yet, the changes in Flink 1.5 enable more natural Kubernetes deployments and switch to HTTP/REST for all external communication (to naturally interact with service proxies). Simultaneously, Flink 1.5 simplifies deployments on common cluster managers (YARN, Mesos) and features dynamic resource allocation.
+
+* Streaming **broadcast state** ([FLINK-4940](https://issues.apache.org/jira/browse/FLINK-4940)) connects a broadcasted stream (e.g., context data, machine learning models, rules/patterns, triggers, ...) with other streams that may maintain (large) keyed state, such as feature vectors, state machines, etc. Prior to Flink 1.5, such use cases could not be easily built.
+
+* To improve support for real-time applications with tight latency constraints, we made **major improvements to Flink’s network stack** ([FLINK-7315](https://issues.apache.org/jira/browse/FLINK-7315)). Flink 1.5 achieves even lower latencies while maintaining a high throughput. In addition, we improved checkpoint stability under backpressure.
+
+* Streaming SQL is more and more recognized as a simple and powerful way to perform streaming analytics, build data pipelines, do feature engineering, or incrementally keep applications updated on changing data. We added a **SQL CLI for streaming SQL queries** ([FLIP-24](https://cwiki.apache.org/confluence/display/FLINK/FLIP-24+-+SQL+Client)) to make this feature easier to get started with.
+
+## New Features and Improvements
+
+### Rewrite of Flink’s Deployment and Process Model
+
+The rewrite of Flink’s deployment and process model (internally known as [FLIP-6](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65147077)) has been in the works for more than a year and was a substantial effort from the Flink community. Many contributors from several organizations, such as data Artisans, Alibaba, and Dell EMC, collaborated on the design and implementation of this feature, which has been the most significant improvement of a Flink core component since the project’s inception.
+
+In a nutshell, the improvements add support for dynamic resource allocation and dynamic release of resources on YARN and Mesos schedulers for better resource utilization, failure recovery, and also dynamic scaling. Moreover, deployments on container management infrastructures like Kubernetes have been simplified and all requests to the JobManager now happen through REST. This includes job submission, cancellation, requesting job status, taking a savepoint, and so on.
+
+The work also builds the foundation for future improvements of Flink’s integration with Kubernetes. In a later version it will be possible to dockerize jobs and deploy them in a natural way as part of the container deployment, i.e., without starting a Flink cluster first. In addition, the work is a big step towards support for applications that are able to automatically adjust their parallelism.
+
+Note that Flink’s programming APIs are not affected by these improvements.
+
+### Broadcast State
+
+Support for broadcast state, i.e., state that is replicated across all parallel instances of a function, has been an frequently requested feature. Typical use cases for broadcast state involve two streams, a control or configuration stream that serves rules, patterns, or other configuration messages and a regular data stream. The processing of the regular stream is configured by the messages of the control stream. By broadcasting rules or patterns to all parallel instances of a function, they can be applied to all events of the regular stream.
+
+Of course, broadcasted state can checkpointed and restored just like any other state in Flink with exactly-once state consistency guarantees. Moreover, broadcast state unblocks the implementation of the “dynamic patterns” feature for Flink’s CEP library.
+
+### Improvements to Flink’s Network Stack
+
+The performance of a distributed streaming application heavily depends on the component that transfers events from one operator to another via a network connection. In the context of stream processing, two performance metrics, latency and throughput, are important.
+
+For Flink 1.5, the community worked on two efforts to improve Flink’s network stack, credit-based flow control and improving the transfer latency. Credit-based flow control reduces the amount of data “on the wire” to a minimum while preserving high throughput. This significantly reduces the time to complete a checkpoint in back pressure situations. Moreover, Flink is now able to achieve much lower latencies without a reduction in throughput.
+
+### Task-Local State Recovery
+
+Flink’s checkpointing mechanism writes copies of an application’s state to a remote, persistent storage and loads it back in case of a failure. This mechanism ensures that state is not lost when an application fails. However, in case of a failure, it might take a while to load the state from the remote storage to recover the application.
+
+Improving the checkpointing and recovery efficiency is an ongoing effort in the Flink community. Prominent features of previous releases were asynchronous and incremental checkpointing. In this release, we improved the efficiency of failure recovery.
+
+Task-local state recovery leverages the fact that a job typically fails due to a single crashed operator, TaskManager, or machine. When writing the state of operators to the remote storage, Flink can now also keep a copy on the local disk of each machine. In case of failover, the scheduler tries to reschedule tasks to their previous machine and load the state from the local disk instead of the remote storage, resulting in faster recovery.
+
+### Extending Join Support for SQL and Table API
+
+With the 1.5.0 release, Flink adds support for windowed outer equi-joins. Queries like the one shown below allow for joining of tables on bounded time ranges in both event-time and processing-time.
+
+```sql
+SELECT d.rideId, d.departureTime, a.arrivalTime
+FROM Departures d LEFT OUTER JOIN Arrivals a
+ ON d.rideId = a.rideId
+ AND a.arrivalTime BETWEEN
+ d.deptureTime AND d.departureTime + '2' HOURS
+```
+
+For cases where two streaming tables should not be joined within a bounded time interval, Flink SQL also now supports non-windowed inner joins. This enables full-history matching, which is common in many standard SQL statements.
+
+```sql
+SELECT u.name, u.address, o.productId, o.amount
+FROM Users u JOIN Orders o
+ ON u.userId = o.userId
+```
+
+### SQL CLI Client
+
+A few months ago, the community started an effort to add a service to execute streaming and batch SQL queries (FLIP-24). The new SQL CLI client is the first step of this effort and provides a SQL shell to run exploratory queries on data streams. The animation below shows a preview of this features.
+
+
+
+
+
+### Various Other Features and Improvements
+
+* [OpenStack](https://www.openstack.org/) provides software for creating public and private clouds on pools of resources. Flink now supports OpenStack’s S3-like file system, Swift, for checkpoint and savepoint storage. Swift can be used without Hadoop dependencies.
+* Reading and writing JSON messages from and to connectors has been improved. It’s now possible to parse a standard JSON schema in order to configure serializers and deserializers. The SQL CLI Client is able to read JSON records from Kafka.
+* Applications can be rescaled without manually triggering a savepoint. Under the hood, Flink will still take a savepoint, stop the application, and rescale it to the new parallelism.
+* Improved metrics for watermarks and latency. Flink now reports the minimum watermark in all operators, including sources. Moreover, the latency metrics were reworked for better integration with common metrics systems.
+* The `FileInputFormat` (and many derived input formats) now supports reading files from multiple paths.
+* The `BucketingSink` supports the specification of custom extensions for multiple parts.
+* The `CassandraOutputFormat` can be used to emit `Row` objects.
+* The Kinesis consumer allows for more customization.
+
+## Release Notes
+
+Please review the [release notes]({{< param DocsBaseUrl >}}flink-docs-release-1.5/release-notes/flink-1.5.html) if you plan to upgrade your Flink setup to Flink 1.5.
+
+## List of Contributors
+
+According to git shortlog, the following 106 people contributed to the 1.5.0 release. Thanks to all contributors!
+
+Aegeaner, Alejandro Alcalde, Aljoscha Krettek, Andreas Fink, Andrey Zagrebin, Ankit Parashar, Arunan Sugunakumar, Bartłomiej Tartanus, Bowen Li, Cristian, Dan Kelley, David Anderson, Dawid Wysakowicz, Dian Fu, Dmitrii_Kniazev, Dyana Rose, EAlexRojas, Eron Wright, Fabian Hueske, Florian Schmidt, Gabor Gevay, Greg Hogan, Gyula Fora, Jark Wu, Jelmer Kuperus, Joerg Schad, John Eismeier, Kailash HD, Ken Geis, Ken Krugler, Kent Murra, Leonid Ishimnikov, Malcolm Taylor, Matrix42, Michael Fong, Michael Gendelman, Moser Thomas W, Nico Kruber, PJ Fanning, Patrick Lucas, Pavel Shvetsov, Phetsarath, Sourigna, Philip Luppens, Piotr Nowojski, Qiu Congxian/klion26, Razvan, Robert Metzger, Rong Rong, Shuyi Chen, Stefan Richter, Stephan Ewen, Stephen Parente, Steven Langbroek, Thomas Weise, Till Rohrmann, Timo Walther, Tony Wei, Tzu-Li (Gordon) Tai, Ufuk Celebi, Vetriselvan1187, Xingcan Cui, Xpray, Yazdan.JS, Zhijiang, Zohar Mizrahi, aria, biao.liub, binlijin, davidxdh, eastcirclek, eskabetxe, gyao, hequn8128, hzyuqi1, ifndef-SleePy, jparkie, juhoautio, kkloudas, maqingxiang-it, maxbelov, mayyamus, mingleiZhang, neoremind, nichuanlei, okumin, shankarganesh1234, shuai.xus, sihuazhou, summerleafs, sunjincheng121, triones.deng, twalthr, uybhatti, vinoyang, wenlong.lwl, yanghua, yew1eb, yuemeng, zentol, zhangminglei, zhouhai02, zjureel, 军长, 金竹, 王振涛, 陈梓立
diff --git a/docs/content.tr/posts/2018-07-12-release-1.5.1.md b/docs/content.tr/posts/2018-07-12-release-1.5.1.md
new file mode 100644
index 0000000000..91cb513917
--- /dev/null
+++ b/docs/content.tr/posts/2018-07-12-release-1.5.1.md
@@ -0,0 +1,209 @@
+---
+date: "2018-07-12T12:00:00Z"
+title: Apache Flink 1.5.1 Released
+aliases:
+- /news/2018/07/12/release-1.5.1.html
+---
+
+The Apache Flink community released the first bugfix version of the Apache Flink 1.5 series.
+
+This release includes more than 60 fixes and minor improvements for Flink 1.5.0. The list below includes a detailed list of all fixes.
+
+We highly recommend all users to upgrade to Flink 1.5.1.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.5.1
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.5.1
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.5.1
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-8977 ] - End-to-end test: Manually resume job after terminal failure
+
+[FLINK-8982 ] - End-to-end test: Queryable state
+
+[FLINK-8989 ] - End-to-end test: ElasticSearch connector
+
+[FLINK-8996 ] - Include an operator with broadcast and union state
+
+[FLINK-9008 ] - End-to-end test: Quickstarts
+
+[FLINK-9320 ] - Update `test-ha.sh` end-to-end test to use general purpose DataStream job
+
+[FLINK-9322 ] - Add exception throwing map function that simulates failures to the general purpose DataStream job
+
+[FLINK-9394 ] - Let externalized checkpoint resume e2e also test rescaling
+
+
+
+ Bug
+
+
+[FLINK-8785 ] - JobSubmitHandler does not handle JobSubmissionExceptions
+
+[FLINK-8795 ] - Scala shell broken for Flip6
+
+[FLINK-8946 ] - TaskManager stop sending metrics after JobManager failover
+
+[FLINK-9174 ] - The type of state created in ProccessWindowFunction.proccess() is inconsistency
+
+[FLINK-9215 ] - TaskManager Releasing - org.apache.flink.util.FlinkException
+
+[FLINK-9257 ] - End-to-end tests prints "All tests PASS" even if individual test-script returns non-zero exit code
+
+[FLINK-9258 ] - ConcurrentModificationException in ComponentMetricGroup.getAllVariables
+
+[FLINK-9326 ] - TaskManagerOptions.NUM_TASK_SLOTS does not work for local/embedded mode
+
+[FLINK-9374 ] - Flink Kinesis Producer does not backpressure
+
+[FLINK-9398 ] - Flink CLI list running job returns all jobs except in CREATE state
+
+[FLINK-9437 ] - Revert cypher suite update
+
+[FLINK-9458 ] - Unable to recover from job failure on YARN with NPE
+
+[FLINK-9467 ] - No Watermark display on Web UI
+
+[FLINK-9468 ] - Wrong calculation of outputLimit in LimitedConnectionsFileSystem
+
+[FLINK-9493 ] - Forward exception when releasing a TaskManager at the SlotPool
+
+[FLINK-9494 ] - Race condition in Dispatcher with concurrent granting and revoking of leaderhship
+
+[FLINK-9500 ] - FileUploadHandler does not handle EmptyLastHttpContent
+
+[FLINK-9524 ] - NPE from ProcTimeBoundedRangeOver.scala
+
+[FLINK-9530 ] - Task numRecords metrics broken for chains
+
+[FLINK-9554 ] - flink scala shell doesn't work in yarn mode
+
+[FLINK-9567 ] - Flink does not release resource in Yarn Cluster mode
+
+[FLINK-9570 ] - SQL Client merging environments uses AbstractMap
+
+[FLINK-9580 ] - Potentially unclosed ByteBufInputStream in RestClient#readRawResponse
+
+[FLINK-9627 ] - Extending 'KafkaJsonTableSource' according to comments will result in NPE
+
+[FLINK-9629 ] - Datadog metrics reporter does not have shaded dependencies
+
+[FLINK-9633 ] - Flink doesn't use the Savepoint path's filesystem to create the OuptutStream on Task.
+
+[FLINK-9634 ] - Deactivate previous location based scheduling if local recovery is disabled
+
+[FLINK-9636 ] - Network buffer leaks in requesting a batch of segments during canceling
+
+[FLINK-9646 ] - ExecutionGraphCoLocationRestartTest.testConstraintsAfterRestart failed on Travis
+
+[FLINK-9654 ] - Internal error while deserializing custom Scala TypeSerializer instances
+
+[FLINK-9655 ] - Externalized checkpoint E2E test fails on travis
+
+[FLINK-9665 ] - PrometheusReporter does not properly unregister metrics
+
+[FLINK-9676 ] - Deadlock during canceling task and recycling exclusive buffer
+
+[FLINK-9677 ] - RestClient fails for large uploads
+
+[FLINK-9684 ] - HistoryServerArchiveFetcher not working properly with secure hdfs cluster
+
+[FLINK-9693 ] - Possible memory leak in jobmanager retaining archived checkpoints
+
+[FLINK-9708 ] - Network buffer leaks when buffer request fails during buffer redistribution
+
+[FLINK-9769 ] - FileUploads may be shared across requests
+
+[FLINK-9770 ] - UI jar list broken
+
+[FLINK-9789 ] - Watermark metrics for an operator&task shadow each other
+
+
+
+ New Feature
+
+
+[FLINK-9153 ] - TaskManagerRunner should support rpc port range
+
+[FLINK-9280 ] - Extend JobSubmitHandler to accept jar files
+
+[FLINK-9316 ] - Expose operator unique ID to the user defined functions in DataStream .
+
+[FLINK-9564 ] - Expose end-to-end module directory to test scripts
+
+[FLINK-9599 ] - Implement generic mechanism to receive files via rest
+
+[FLINK-9669 ] - Introduce task manager assignment store
+
+[FLINK-9670 ] - Introduce slot manager factory
+
+[FLINK-9671 ] - Add configuration to enable task manager isolation.
+
+
+
+ Improvement
+
+
+[FLINK-4301 ] - Parameterize Flink version in Quickstart bash script
+
+[FLINK-8650 ] - Add tests and documentation for WINDOW clause
+
+[FLINK-8654 ] - Extend quickstart docs on how to submit jobs
+
+[FLINK-9109 ] - Add flink modify command to documentation
+
+[FLINK-9355 ] - Simplify configuration of local recovery to a simple on/off
+
+[FLINK-9372 ] - Typo on Elasticsearch website link (elastic.io --> elastic.co)
+
+[FLINK-9409 ] - Remove flink-avro and flink-json from /opt
+
+[FLINK-9456 ] - Let ResourceManager notify JobManager about failed/killed TaskManagers
+
+[FLINK-9508 ] - General Spell Check on Flink Docs
+
+[FLINK-9517 ] - Fixing broken links on CLI and Upgrade Docs
+
+[FLINK-9518 ] - SSL setup Docs config example has wrong keys password
+
+[FLINK-9549 ] - Fix FlickCEP Docs broken link and minor style changes
+
+[FLINK-9573 ] - Check for leadership with leader session id
+
+[FLINK-9594 ] - Add documentation for e2e test changes introduced with FLINK-9257
+
+[FLINK-9595 ] - Add instructions to docs about ceased support of KPL version used in Kinesis connector
+
+[FLINK-9638 ] - Add helper script to run single e2e test
+
+[FLINK-9672 ] - Fail fatally if we cannot submit job on added JobGraph signal
+
+[FLINK-9707 ] - LocalFileSystem does not support concurrent directory creations
+
+[FLINK-9729 ] - Duplicate lines for "Weekday name (Sunday .. Saturday)"
+
+[FLINK-9734 ] - Typo 'field-deleimiter' in SQL client docs
+
+
+
diff --git a/docs/content.tr/posts/2018-07-31-release-1.5.2.md b/docs/content.tr/posts/2018-07-31-release-1.5.2.md
new file mode 100644
index 0000000000..c13e0128ea
--- /dev/null
+++ b/docs/content.tr/posts/2018-07-31-release-1.5.2.md
@@ -0,0 +1,142 @@
+---
+date: "2018-07-31T12:00:00Z"
+title: Apache Flink 1.5.2 Released
+aliases:
+- /news/2018/07/31/release-1.5.2.html
+---
+
+The Apache Flink community released the second bugfix version of the Apache Flink 1.5 series.
+
+This release includes more than 20 fixes and minor improvements for Flink 1.5.1. The list below includes a detailed list of all fixes.
+
+We highly recommend all users to upgrade to Flink 1.5.2.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.5.2
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.5.2
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.5.2
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-9839 ] - End-to-end test: Streaming job with SSL
+
+
+
+ Bug
+
+
+[FLINK-5750 ] - Incorrect translation of n-ary Union
+
+[FLINK-8161 ] - Flakey YARNSessionCapacitySchedulerITCase on Travis
+
+[FLINK-8731 ] - TwoInputStreamTaskTest flaky on travis
+
+[FLINK-9091 ] - Failure while enforcing releasability in building flink-json module
+
+[FLINK-9380 ] - Failing end-to-end tests should not clean up logs
+
+[FLINK-9439 ] - DispatcherTest#testJobRecovery dead locks
+
+[FLINK-9575 ] - Potential race condition when removing JobGraph in HA
+
+[FLINK-9584 ] - Unclosed streams in Bucketing-/RollingSink
+
+[FLINK-9658 ] - Test data output directories are no longer cleaned up
+
+[FLINK-9706 ] - DispatcherTest#testSubmittedJobGraphListener fails on Travis
+
+[FLINK-9743 ] - PackagedProgram.extractContainedLibraries fails on Windows
+
+[FLINK-9754 ] - Release scripts refers to non-existing profile
+
+[FLINK-9755 ] - Exceptions in RemoteInputChannel#notifyBufferAvailable() are not propagated to the responsible thread
+
+[FLINK-9762 ] - CoreOptions.TMP_DIRS wrongly managed on Yarn
+
+[FLINK-9766 ] - Incomplete/incorrect cleanup in RemoteInputChannelTest
+
+[FLINK-9771 ] - "Show Plan" option under Submit New Job in WebUI not working
+
+[FLINK-9772 ] - Documentation of Hadoop API outdated
+
+[FLINK-9784 ] - Inconsistent use of 'static' in AsyncIOExample.java
+
+[FLINK-9793 ] - When submitting a flink job with yarn-cluster, flink-dist*.jar is repeatedly uploaded
+
+[FLINK-9810 ] - JarListHandler does not close opened jars
+
+[FLINK-9838 ] - Slot request failed Exceptions after completing a job
+
+[FLINK-9841 ] - Web UI only show partial taskmanager log
+
+[FLINK-9842 ] - Job submission fails via CLI with SSL enabled
+
+[FLINK-9847 ] - OneInputStreamTaskTest.testWatermarksNotForwardedWithinChainWhenIdle unstable
+
+[FLINK-9857 ] - Processing-time timers fire too early
+
+[FLINK-9860 ] - Netty resource leak on receiver side
+
+[FLINK-9872 ] - SavepointITCase#testSavepointForJobWithIteration does not properly cancel jobs
+
+[FLINK-9908 ] - Inconsistent state of SlotPool after ExecutionGraph cancellation
+
+[FLINK-9910 ] - Non-queued scheduling failure sometimes does not return the slot
+
+[FLINK-9911 ] - SlotPool#failAllocation is called outside of main thread
+
+
+
+ New Feature
+
+
+[FLINK-9499 ] - Allow REST API for running a job to provide job configuration as body of POST request
+
+
+
+ Improvement
+
+
+[FLINK-9659 ] - Remove hard-coded sleeps in bucketing sink E2E test
+
+[FLINK-9748 ] - create_source_release pollutes flink root directory
+
+[FLINK-9768 ] - Only build flink-dist for binary releases
+
+[FLINK-9785 ] - Add remote addresses to LocalTransportException instances
+
+[FLINK-9801 ] - flink-dist is missing dependency on flink-examples
+
+[FLINK-9804 ] - KeyedStateBackend.getKeys() does not work on RocksDB MapState
+
+[FLINK-9811 ] - Add ITCase for interactions of Jar handlers
+
+[FLINK-9873 ] - Log actual state when aborting checkpoint due to task not running
+
+[FLINK-9881 ] - Typo in a function name in table.scala
+
+[FLINK-9888 ] - Remove unsafe defaults from release scripts
+
+[FLINK-9909 ] - Remove cancellation of input futures from ConjunctFutures
+
+
diff --git a/docs/content.tr/posts/2018-08-09-release-1.6.0.md b/docs/content.tr/posts/2018-08-09-release-1.6.0.md
new file mode 100644
index 0000000000..63c497eff2
--- /dev/null
+++ b/docs/content.tr/posts/2018-08-09-release-1.6.0.md
@@ -0,0 +1,156 @@
+---
+authors:
+- name: Till Rohrmann
+ till: null
+ twitter: stsffap
+date: "2018-08-09T12:00:00Z"
+title: Apache Flink 1.6.0 Release Announcement
+aliases:
+- /news/2018/08/09/release-1.6.0.html
+---
+
+The Apache Flink community is proud to announce the 1.6.0 release. Over the past 2 months, the Flink community has worked hard to resolve more than 360 issues. Please check the [complete changelog](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12342760) for more details.
+
+Flink 1.6.0 is the seventh major release in the 1.x.y series. It is API-compatible with previous 1.x.y releases for APIs annotated with the `@Public` annotation.
+
+We encourage everyone to [download the release](http://flink.apache.org/downloads.html) and check out the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.6/).
+Feedback through the Flink [mailing lists](http://flink.apache.org/community.html#mailing-lists) or [JIRA](https://issues.apache.org/jira/projects/FLINK/summary) is, as always, very much appreciated!
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html) on the Flink project site.
+
+## Flink 1.6 - The next step in stateful stream processing
+
+In Flink 1.6.0 we continue the groundwork we laid out in earlier versions: Enabling Flink users to seamlessly run fast data processing and build data-driven and data-intensive applications effortlessly.
+
+* Flink's state support is one of the key features which makes Flink so versatile and powerful when it comes to implementing all kinds of use cases.
+To make it even easier, the community added **native support for state TTL** ([FLINK-9510](https://issues.apache.org/jira/browse/FLINK-9510), [FLINK-9938](https://issues.apache.org/jira/browse/FLINK-9938)).
+This feature allows to clean up state after it has expired.
+With Flink 1.6.0 **timer state can now go out of core** ([FLINK-9485](https://issues.apache.org/jira/browse/FLINK-9485)) by storing the relevant state in RocksDB.
+Last but not least, we also **improved the deletion of timers** ([FLINK-9423](https://issues.apache.org/jira/browse/FLINK-9423)) significantly.
+
+* With Flink 1.5.0 we reworked Flink's distributed architecture to add support for resource elasticity and different deployment scenarios, most notably a better container integration.
+In Flink 1.6.0 we follow up on some of the unfinished aspects of this work: **All external communication, including job submissions, is now HTTP/REST based** ([FLINK-9280](https://issues.apache.org/jira/browse/FLINK-9280)) which eases container setups considerably.
+Flink 1.6.0 also comes with a **container entrypoint** ([FLINK-9488](https://issues.apache.org/jira/browse/FLINK-9488)) which allows to easily bootstrap a containerized job cluster.
+
+* Streaming SQL is one of the features with the most disruptive potential, because it makes Flink much more accessible.
+In Apache Flink 1.6.0 the community **improved further the SQL CLI** ([FLINK-8863](https://issues.apache.org/jira/browse/FLINK-8863)) making the **executions of streaming and batch queries** ([FLINK-8861](https://issues.apache.org/jira/browse/FLINK-8861)) against a multitude of data sources a piece of cake.
+In addition, the **full Avro support** ([FLINK-9444](https://issues.apache.org/jira/browse/FLINK-9444)) makes reading any kind of Avro data seamless.
+Last but not least, the community **hardened Flink's CEP library** ([FLINK-9418](https://issues.apache.org/jira/browse/FLINK-9418)) that can now handle significantly larger use cases.
+
+* What would be a distributed processing engine without its connectors to talk to the outside world?
+In the latest Flink release we added a **new StreamingFileSink** ([FLINK-9750](https://issues.apache.org/jira/browse/FLINK-9750)) that succeeds the `BucketingSink` as the standard file sink.
+The community also added support for **ElasticSearch 6.x** ([FLINK-7386](https://issues.apache.org/jira/browse/FLINK-7386)) and implemented multiple **AvroDeserializationSchemas** ([FLINK-9338](https://issues.apache.org/jira/browse/FLINK-9338)) to easily ingest Avro data.
+
+## New Features and Improvements
+
+### Improving Flink's State Support
+
+* **Support for State TTL** ([FLINK-9510](https://issues.apache.org/jira/browse/FLINK-9510), [FLINK-9938](https://issues.apache.org/jira/browse/FLINK-9938)):
+This feature allows to specify a time-to-live (TTL) for Flink state.
+Once the time-to-live has been exceeded Flink will no longer give access to the respective state values.
+The expired data is cleaned up on access so that the operator keyed state doesn’t grow infinitely and it won't be included in subsequent checkpoints.
+This feature fully complies with new data protection regulations (e.g. GDPR).
+
+* **Scalable Timers Based on RocksDB** ([FLINK-9485](https://issues.apache.org/jira/browse/FLINK-9485)):
+Flink’s timer state can now be stored in RocksDB, allowing the technology to support significantly bigger timer state since it can go out of core/spill to disk.
+Previously, users were limited to the heap memory size.
+On top of that, snapshots of the timer state are now asynchronous, i.e., they no longer block the processing pipeline during checkpoints and can be incremental.
+
+* **Faster Timer Deletions** ([FLINK-9423](https://issues.apache.org/jira/browse/FLINK-9423)):
+Improving Flink’s internal timer data structure such that the deletion complexity is reduced from O(n) to O(log n).
+This significantly improves Flink jobs using timers.
+Deleting timers is also exposed through a user-facing API now.
+
+### Extending Flink's Deployment Options
+
+* **Job Cluster Container Entrypoint** ([FLINK-9488](https://issues.apache.org/jira/browse/FLINK-9488)):
+Flink 1.6.0 provides an easy-to-use container entrypoint to bootstrap a job cluster.
+Combining this entrypoint with a user-code jar creates a self-contained image which automatically executes the contained Flink job when deployed.
+Since the image already contains the Flink job, client communication is no longer necessary.
+Avoiding additional communication steps with the client reduces the number of moving parts and improves operations in a container environment significantly.
+
+* **Fully RESTified Job Submission** ([FLINK-9280](https://issues.apache.org/jira/browse/FLINK-9280)):
+The Flink client now sends all job-relevant content via a single POST call to the server.
+This allows a much easier integration with cluster management frameworks and container environments, since opening custom ports is no longer necessary.
+
+### Enhancing SQL and Table API
+
+* **User-Defined Function in SQL Client CLI** ([FLINK-8863](https://issues.apache.org/jira/browse/FLINK-8863)):
+The SQL Client CLI now supports the registration of user-defined functions.
+This considerably improves the CLI’s expressiveness, because SQL queries can be enriched with more powerful custom table, aggregate, and scalar functions.
+
+* **Support for Batch Queries in SQL Client CLI** ([FLINK-8861](https://issues.apache.org/jira/browse/FLINK-8861)):
+The SQL Client CLI now supports the execution of batch queries.
+
+* **Support for INSERT INTO Statements in SQL Client CLI** ([FLINK-8858](https://issues.apache.org/jira/browse/FLINK-8858)):
+By supporting SQL’s INSERT INTO statements, the SQL Client CLI can be used to submit long-running SQL queries to Flink that sink their results in external systems.
+The SQL Client itself can be shut down after submission without stopping the job.
+
+* **Unified Table Sinks and Formats** ([FLINK-8866](https://issues.apache.org/jira/browse/FLINK-8866), [FLINK-8558](https://issues.apache.org/jira/browse/FLINK-8558)):
+In the past, table sinks had to be configured programmatically and were tied to a specific format and implementation.
+This release reworked these aspects by decoupling formats from connectors and improving how table sinks are discovered and configured.
+Table sinks can now be defined in a YAML file using string-based properties without having to write a single line of code.
+
+* **New Kafka Table Sink** ([FLINK-9846](https://issues.apache.org/jira/browse/FLINK-9846)):
+The Kafka table sink now uses the new unified APIs and supports both JSON and Avro formats.
+
+* **Full SQL Avro Support** ([FLINK-9444](https://issues.apache.org/jira/browse/FLINK-9444)):
+Flink’s Table & SQL API now understands the full spectrum of Avro types including generic/specific records and logical types.
+The types are automatically mapped from and to Flink-equivalent types allowing to specify end-to-end ETL pipelines in SQL.
+
+* **Improved Expressiveness of SQL and Table API** ([FLINK-5878](https://issues.apache.org/jira/browse/FLINK-5878), [FLINK-8688](https://issues.apache.org/jira/browse/FLINK-8688), [FLINK-6810](https://issues.apache.org/jira/browse/FLINK-6810)):
+Flink’s Table & SQL API supports left, right, and full outer joins that allow for continuous result-updating queries.
+SQL aggregate functions support the `DISTINCT` keyword.
+Queries such as `COUNT(DISTINCT column)` are supported for windowed and non-windowed aggregations.
+Both SQL and Table API now include more built-in functions such as `MD5, SHA1, SHA2, LOG`, and `UNNEST` for multisets.
+
+### More Connectors
+
+* **New StreamingFileSink** ([FLINK-9750](https://issues.apache.org/jira/browse/FLINK-9750)):
+The new `StreamingFileSink` is an exactly-once sink for writing to filesystems which capitalizes on the knowledge acquired from the previous `BucketingSink`.
+Exactly-once is supported through integration of the sink with Flink’s checkpointing mechanism.
+The new sink is built upon Flink’s own `FileSystem` abstraction and it supports local file system and HDFS, with plans for S3 support in the near future.
+It exposes pluggable file rolling and bucketing policies.
+Apart from row-wise encoding formats, the new `StreamingFileSink` comes with support for Parquet.
+Other bulk-encoding formats like ORC can be easily added using the exposed APIs.
+
+* **ElasticSearch 6.x Connector and Improved Support for Older Versions** ([FLINK-7386](https://issues.apache.org/jira/browse/FLINK-7386)):
+Flink now comes with a connector for ElasticSearch 6.x, that is built on top of Elasticsearch’s new [high level REST client](https://www.elastic.co/guide/en/elasticsearch/client/java-rest/master/java-rest-high.html).
+For older ElasticSearch versions which still use the native Java `TransportClient`, Flink's Elasticsearch connectors now support up to Elasticsearch version 5.6.10.
+Some APIs in the `RequestIndexer's` public interface of the ElasticSearch connector have been deprecated.
+Please refer to the Javadoc / documentation for the new preferred API.
+
+* **Avro Deserialization Schemas** ([FLINK-9338](https://issues.apache.org/jira/browse/FLINK-9338)):
+Flink comes now with a `DeserializationSchema` which allows deserializing Avro encoded messages.
+It also adds out-of-the-box integration with Confluent’s schema registry.
+
+### Jepsen Based Distributed Tests Suite
+
+The Flink community added a Jepsen based test suite ([FLINK-9004](https://issues.apache.org/jira/browse/FLINK-9004)) which validates the behavior of Flink’s distributed cluster components under real-world faults.
+It is a first step towards a higher test coverage for Flink's fault tolerance mechanisms.
+The community intends to incrementally improve test coverage with it.
+
+### Various Other Features and Improvements
+
+* **Hardened CEP Library** ([FLINK-9418](https://issues.apache.org/jira/browse/FLINK-9418)):
+The CEP operator’s internal NFA state is now backed by Flink state.
+That way it can go out of core to support much larger use cases.
+
+* **More Expressive DataStream Joins** ([FLINK-8478](https://issues.apache.org/jira/browse/FLINK-8478)):
+Flink 1.6.0 adds support for interval joins in the DataStream API.
+With this feature it is now possible to join together events from different streams where elements from one stream lie in a specified time interval relative to elements from the other stream.
+Check out the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.6/dev/stream/operators/joining.html) for more details.
+
+* **Intra-Cluster Mutual Authentication** ([FLINK-9312](https://issues.apache.org/jira/browse/FLINK-9312)):
+Flink’s cluster components now enforce mutual authentication with their peers.
+This allows only Flink components to talk to each other, making it impossible for malicious actors to impersonate Flink components in order to eavesdrop on the cluster communication.
+
+## Release Notes
+
+Please review the [release notes]({{< param DocsBaseUrl >}}flink-docs-release-1.6/release-notes/flink-1.6.html) if you plan to upgrade your Flink setup to Flink 1.6.
+
+## List of Contributors
+
+According to git shortlog, the following 112 people contributed to the 1.6.0 release. Thanks to all contributors!
+
+Alejandro Alcalde, Alexander Koltsov, Alexey Tsitkin, Aljoscha Krettek, Andreas Fink, Andrey Zagrebin, Arunan Sugunakumar, Ashwin Sinha, Bill Lee, Bowen Li, Chesnay Schepler, Christophe Jolif, Clément Tamisier, Craig Foster, David Anderson, Dawid Wysakowicz, Deepak Sharnma, Dmitrii_Kniazev, EAlexRojas, Elias Levy, Eron Wright, Ethan Li, Fabian Hueske, Florian Schmidt, Franz Thoma, Gabor Gevay, Georgii Gobozov, Haohui Mai, Jamie Grier, Jeff Zhang, Jelmer Kuperus, Jiayi Liao, Jungtaek Lim, Kailash HD, Ken Geis, Ken Krugler, Lakshmi Gururaja Rao, Leonid Ishimnikov, Matrix42, Michael Gendelman, MichealShin, Moser Thomas W, Nico Duldhardt, Nico Kruber, Oleksandr Nitavskyi, PJ Fanning, Patrick Lucas, Pavel Shvetsov, Philippe Duveau, Piotr Nowojski, Qiu Congxian/klion26, Rinat Sharipov, Rong Rong, Rune Skou Larsen, Sayat Satybaldiyev, Shuyi Chen, Stefan Richter, Stephan Ewen, Stephen Parente, Thomas Weise, Till Rohrmann, Timo Walther, Tobii42, Tzu-Li (Gordon) Tai, Viktor Vlasov, Wosin, Xingcan Cui, Xpray, Yan Zhou, Yazdan.JS, Yun Tang, Zhijiang, Zsolt Donca, an4828, aria, binlijin, blueszheng, davidxdh, gyao, hequn8128, hzyuqi1, jerryjzhang, jparkie, juhoautio, kai-chi, kkloudas, klion26, lamber-ken, lincoln-lil, linjun, liurenjie1024, lsy, maqingxiang-it, maxbelov, mayyamus, minwenjun, neoremind, sampathBhat, shankarganesh1234, shuai.xus, sihuazhou, snuyanzin, triones.deng, vinoyang, xueyu, yangshimin, yuemeng, zhangminglei, zhouhai02, zjureel, 军长, 陈梓立
diff --git a/docs/content.tr/posts/2018-08-21-release-1.5.3.md b/docs/content.tr/posts/2018-08-21-release-1.5.3.md
new file mode 100644
index 0000000000..cde1d6aac3
--- /dev/null
+++ b/docs/content.tr/posts/2018-08-21-release-1.5.3.md
@@ -0,0 +1,114 @@
+---
+date: "2018-08-21T12:00:00Z"
+title: Apache Flink 1.5.3 Released
+aliases:
+- /news/2018/08/21/release-1.5.3.html
+---
+
+The Apache Flink community released the third bugfix version of the Apache Flink 1.5 series.
+
+This release includes more than 20 fixes and minor improvements for Flink 1.5.3. The list below includes a detailed list of all fixes.
+
+We highly recommend all users to upgrade to Flink 1.5.3.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.5.3
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.5.3
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.5.3
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-9951 ] - Update scm developerConnection
+
+
+
+ Bug
+
+
+[FLINK-5750 ] - Incorrect translation of n-ary Union
+
+[FLINK-9289 ] - Parallelism of generated operators should have max parallism of input
+
+[FLINK-9546 ] - The heartbeatTimeoutIntervalMs of HeartbeatMonitor should be larger than 0
+
+[FLINK-9655 ] - Externalized checkpoint E2E test fails on travis
+
+[FLINK-9693 ] - Possible memory leak in jobmanager retaining archived checkpoints
+
+[FLINK-9694 ] - Potentially NPE in CompositeTypeSerializerConfigSnapshot constructor
+
+[FLINK-9923 ] - OneInputStreamTaskTest.testWatermarkMetrics fails on Travis
+
+[FLINK-9935 ] - Batch Table API: grouping by window and attribute causes java.lang.ClassCastException:
+
+[FLINK-9936 ] - Mesos resource manager unable to connect to master after failover
+
+[FLINK-9946 ] - Quickstart E2E test archetype version is hard-coded
+
+[FLINK-9969 ] - Unreasonable memory requirements to complete examples/batch/WordCount
+
+[FLINK-9972 ] - Debug memory logging not working
+
+[FLINK-9978 ] - Source release sha contains absolute file path
+
+[FLINK-9985 ] - Incorrect parameter order in document
+
+[FLINK-9988 ] - job manager does not respect property jobmanager.web.address
+
+[FLINK-10013 ] - Fix Kerberos integration for FLIP-6 YarnTaskExecutorRunner
+
+[FLINK-10033 ] - Let Task release reference to Invokable on shutdown
+
+[FLINK-10070 ] - Flink cannot be compiled with maven 3.0.x
+
+
+
+ New Feature
+
+
+[FLINK-10022 ] - Add metrics for input/output buffers
+
+
+
+ Improvement
+
+
+[FLINK-9446 ] - Compatibility table not up-to-date
+
+[FLINK-9765 ] - Improve CLI responsiveness when cluster is not reachable
+
+[FLINK-9806 ] - Add a canonical link element to documentation HTML
+
+[FLINK-9859 ] - More Akka config options
+
+[FLINK-9942 ] - Guard handlers against null fields in requests
+
+[FLINK-9986 ] - Remove unnecessary information from .version.properties file
+
+[FLINK-9987 ] - Rework ClassLoader E2E test to not rely on .version.properties file
+
+[FLINK-10006 ] - Improve logging in BarrierBuffer
+
+[FLINK-10016 ] - Make YARN/Kerberos end-to-end test stricter
+
+
diff --git a/docs/content.tr/posts/2018-09-20-release-1.5.4.md b/docs/content.tr/posts/2018-09-20-release-1.5.4.md
new file mode 100644
index 0000000000..4e20caeb0d
--- /dev/null
+++ b/docs/content.tr/posts/2018-09-20-release-1.5.4.md
@@ -0,0 +1,94 @@
+---
+date: "2018-09-20T12:00:00Z"
+title: Apache Flink 1.5.4 Released
+aliases:
+- /news/2018/09/20/release-1.5.4.html
+---
+
+The Apache Flink community released the fourth bugfix version of the Apache Flink 1.5 series.
+
+This release includes more than 20 fixes and minor improvements for Flink 1.5.4. The list below includes a detailed list of all fixes.
+
+We highly recommend all users to upgrade to Flink 1.5.4.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.5.4
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.5.4
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.5.4
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+List of resolved issues:
+
+ Bug
+
+
+[FLINK-9878 ] - IO worker threads BLOCKED on SSL Session Cache while CMS full gc
+
+[FLINK-10011 ] - Old job resurrected during HA failover
+
+[FLINK-10101 ] - Mesos web ui url is missing.
+
+[FLINK-10115 ] - Content-length limit is also applied to FileUploads
+
+[FLINK-10116 ] - createComparator fails on case class with Unit type fields prior to the join-key
+
+[FLINK-10141 ] - Reduce lock contention introduced with 1.5
+
+[FLINK-10142 ] - Reduce synchronization overhead for credit notifications
+
+[FLINK-10150 ] - Chained batch operators interfere with each other other
+
+[FLINK-10172 ] - Inconsistentcy in ExpressionParser and ExpressionDsl for order by asc/desc
+
+[FLINK-10193 ] - Default RPC timeout is used when triggering savepoint via JobMasterGateway
+
+[FLINK-10204 ] - StreamElementSerializer#copy broken for LatencyMarkers
+
+[FLINK-10255 ] - Standby Dispatcher locks submitted JobGraphs
+
+[FLINK-10261 ] - INSERT INTO does not work with ORDER BY clause
+
+[FLINK-10267 ] - [State] Fix arbitrary iterator access on RocksDBMapIterator
+
+[FLINK-10293 ] - RemoteStreamEnvironment does not forward port to RestClusterClient
+
+[FLINK-10314 ] - Blocking calls in Execution Graph creation bring down cluster
+
+[FLINK-10328 ] - Stopping the ZooKeeperSubmittedJobGraphStore should release all currently held locks
+
+[FLINK-10329 ] - Fail with exception if job cannot be removed by ZooKeeperSubmittedJobGraphStore#removeJobGraph
+
+
+
+ Improvement
+
+
+[FLINK-10082 ] - Initialize StringBuilder in Slf4jReporter with estimated size
+
+[FLINK-10131 ] - Improve logging around ResultSubpartition
+
+[FLINK-10137 ] - YARN: Log completed Containers
+
+[FLINK-10185 ] - Make ZooKeeperStateHandleStore#releaseAndTryRemove synchronous
+
+[FLINK-10223 ] - TaskManagers should log their ResourceID during startup
+
+[FLINK-10301 ] - Allow a custom Configuration in StreamNetworkBenchmarkEnvironment
+
+
\ No newline at end of file
diff --git a/docs/content.tr/posts/2018-09-20-release-1.6.1.md b/docs/content.tr/posts/2018-09-20-release-1.6.1.md
new file mode 100644
index 0000000000..68d95b36c7
--- /dev/null
+++ b/docs/content.tr/posts/2018-09-20-release-1.6.1.md
@@ -0,0 +1,181 @@
+---
+date: "2018-09-20T12:00:00Z"
+title: Apache Flink 1.6.1 Released
+aliases:
+- /news/2018/09/20/release-1.6.1.html
+---
+
+The Apache Flink community released the first bugfix version of the Apache Flink 1.6 series.
+
+This release includes 60 fixes and minor improvements for Flink 1.6.1. The list below includes a detailed list of all fixes.
+
+We highly recommend all users to upgrade to Flink 1.6.1.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.6.1
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.6.1
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.6.1
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-9637 ] - Add public user documentation for TTL feature
+
+[FLINK-10068 ] - Add documentation for async/RocksDB-based timers
+
+[FLINK-10085 ] - Update AbstractOperatorRestoreTestBase
+
+[FLINK-10087 ] - Update BucketingSinkMigrationTest
+
+[FLINK-10089 ] - Update FlinkKafkaConsumerBaseMigrationTest
+
+[FLINK-10090 ] - Update ContinuousFileProcessingMigrationTest
+
+[FLINK-10091 ] - Update WindowOperatorMigrationTest
+
+[FLINK-10092 ] - Update StatefulJobSavepointMigrationITCase
+
+[FLINK-10109 ] - Add documentation for StreamingFileSink
+
+
+
+ Bug
+
+
+[FLINK-9289 ] - Parallelism of generated operators should have max parallism of input
+
+[FLINK-9546 ] - The heartbeatTimeoutIntervalMs of HeartbeatMonitor should be larger than 0
+
+[FLINK-9693 ] - Possible memory leak in jobmanager retaining archived checkpoints
+
+[FLINK-9972 ] - Debug memory logging not working
+
+[FLINK-10011 ] - Old job resurrected during HA failover
+
+[FLINK-10063 ] - Jepsen: Automatically restart Mesos Processes
+
+[FLINK-10101 ] - Mesos web ui url is missing.
+
+[FLINK-10105 ] - Test failure because of jobmanager.execution.failover-strategy is outdated
+
+[FLINK-10115 ] - Content-length limit is also applied to FileUploads
+
+[FLINK-10116 ] - createComparator fails on case class with Unit type fields prior to the join-key
+
+[FLINK-10141 ] - Reduce lock contention introduced with 1.5
+
+[FLINK-10142 ] - Reduce synchronization overhead for credit notifications
+
+[FLINK-10150 ] - Chained batch operators interfere with each other other
+
+[FLINK-10151 ] - [State TTL] Fix false recursion call in TransformingStateTableKeyGroupPartitioner.tryAddToSource
+
+[FLINK-10154 ] - Make sure we always read at least one record in KinesisConnector
+
+[FLINK-10169 ] - RowtimeValidator fails with custom TimestampExtractor
+
+[FLINK-10172 ] - Inconsistentcy in ExpressionParser and ExpressionDsl for order by asc/desc
+
+[FLINK-10192 ] - SQL Client table visualization mode does not update correctly
+
+[FLINK-10193 ] - Default RPC timeout is used when triggering savepoint via JobMasterGateway
+
+[FLINK-10204 ] - StreamElementSerializer#copy broken for LatencyMarkers
+
+[FLINK-10255 ] - Standby Dispatcher locks submitted JobGraphs
+
+[FLINK-10261 ] - INSERT INTO does not work with ORDER BY clause
+
+[FLINK-10267 ] - [State] Fix arbitrary iterator access on RocksDBMapIterator
+
+[FLINK-10269 ] - Elasticsearch 6 UpdateRequest fail because of binary incompatibility
+
+[FLINK-10283 ] - FileCache logs unnecessary warnings
+
+[FLINK-10293 ] - RemoteStreamEnvironment does not forward port to RestClusterClient
+
+[FLINK-10314 ] - Blocking calls in Execution Graph creation bring down cluster
+
+[FLINK-10328 ] - Stopping the ZooKeeperSubmittedJobGraphStore should release all currently held locks
+
+[FLINK-10329 ] - Fail with exception if job cannot be removed by ZooKeeperSubmittedJobGraphStore#removeJobGraph
+
+
+
+ New Feature
+
+
+[FLINK-10022 ] - Add metrics for input/output buffers
+
+
+
+ Improvement
+
+
+[FLINK-9013 ] - Document yarn.containers.vcores only being effective when adapting YARN config
+
+[FLINK-9446 ] - Compatibility table not up-to-date
+
+[FLINK-9795 ] - Update Mesos documentation for flip6
+
+[FLINK-9859 ] - More Akka config options
+
+[FLINK-9899 ] - Add more metrics to the Kinesis source connector
+
+[FLINK-9962 ] - allow users to specify TimeZone in DateTimeBucketer
+
+[FLINK-10001 ] - Improve Kubernetes documentation
+
+[FLINK-10006 ] - Improve logging in BarrierBuffer
+
+[FLINK-10020 ] - Kinesis Consumer listShards should support more recoverable exceptions
+
+[FLINK-10082 ] - Initialize StringBuilder in Slf4jReporter with estimated size
+
+[FLINK-10094 ] - Always backup default config for end-to-end tests
+
+[FLINK-10110 ] - Harden e2e Kafka shutdown
+
+[FLINK-10131 ] - Improve logging around ResultSubpartition
+
+[FLINK-10137 ] - YARN: Log completed Containers
+
+[FLINK-10164 ] - Add support for resuming from savepoints to StandaloneJobClusterEntrypoint
+
+[FLINK-10170 ] - Support string representation for map and array types in descriptor-based Table API
+
+[FLINK-10185 ] - Make ZooKeeperStateHandleStore#releaseAndTryRemove synchronous
+
+[FLINK-10223 ] - TaskManagers should log their ResourceID during startup
+
+[FLINK-10301 ] - Allow a custom Configuration in StreamNetworkBenchmarkEnvironment
+
+[FLINK-10325 ] - [State TTL] Refactor TtlListState to use only loops, no java stream API for performance
+
+
+
+ Test
+
+
+[FLINK-10084 ] - Migration tests weren't updated for 1.5
+
+
\ No newline at end of file
diff --git a/docs/content.tr/posts/2018-10-29-release-1.5.5.md b/docs/content.tr/posts/2018-10-29-release-1.5.5.md
new file mode 100644
index 0000000000..c9325a2fbd
--- /dev/null
+++ b/docs/content.tr/posts/2018-10-29-release-1.5.5.md
@@ -0,0 +1,109 @@
+---
+date: "2018-10-29T12:00:00Z"
+title: Apache Flink 1.5.5 Released
+aliases:
+- /news/2018/10/29/release-1.5.5.html
+---
+
+The Apache Flink community released the fifth bugfix version of the Apache Flink 1.5 series.
+
+This release includes more than 20 fixes and minor improvements for Flink 1.5.4. The list below includes a detailed list of all fixes.
+
+We highly recommend all users to upgrade to Flink 1.5.5.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.5.5
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.5.5
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.5.5
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-10242 ] - Latency marker interval should be configurable
+
+[FLINK-10243 ] - Add option to reduce latency metrics granularity
+
+[FLINK-10331 ] - Reduce number of flush requests to the network stack
+
+[FLINK-10332 ] - Move data available notification in PipelinedSubpartition out of the synchronized block
+
+
+
+ Bug
+
+
+[FLINK-5542 ] - YARN client incorrectly uses local YARN config to check vcore capacity
+
+[FLINK-9567 ] - Flink does not release resource in Yarn Cluster mode
+
+[FLINK-9788 ] - ExecutionGraph Inconsistency prevents Job from recovering
+
+[FLINK-9884 ] - Slot request may not be removed when it has already be assigned in slot manager
+
+[FLINK-9891 ] - Flink cluster is not shutdown in YARN mode when Flink client is stopped
+
+[FLINK-9932 ] - Timed-out TaskExecutor slot-offers to JobMaster leak the slot
+
+[FLINK-10135 ] - Certain cluster-level metrics are no longer exposed
+
+[FLINK-10222 ] - Table scalar function expression parses error when function name equals the exists keyword suffix
+
+[FLINK-10259 ] - Key validation for GroupWindowAggregate is broken
+
+[FLINK-10316 ] - Add check to KinesisProducer that aws.region is set
+
+[FLINK-10354 ] - Savepoints should be counted as retained checkpoints
+
+[FLINK-10400 ] - Return failed JobResult if job terminates in state FAILED or CANCELED
+
+[FLINK-10415 ] - RestClient does not react to lost connection
+
+[FLINK-10451 ] - TableFunctionCollector should handle the life cycle of ScalarFunction
+
+[FLINK-10469 ] - FileChannel may not write the whole buffer in a single call to FileChannel.write(Buffer buffer)
+
+[FLINK-10487 ] - fix invalid Flink SQL example
+
+[FLINK-10516 ] - YarnApplicationMasterRunner does not initialize FileSystem with correct Flink Configuration during setup
+
+[FLINK-10524 ] - MemoryManagerConcurrentModReleaseTest.testConcurrentModificationWhileReleasing failed on travis
+
+[FLINK-10544 ] - Remove custom settings.xml for snapshot deployments
+
+
+
+ Improvement
+
+
+[FLINK-10075 ] - HTTP connections to a secured REST endpoint flood the log
+
+[FLINK-10260 ] - Confusing log messages during TaskManager registration
+
+[FLINK-10282 ] - Provide separate thread-pool for REST endpoint
+
+[FLINK-10312 ] - Wrong / missing exception when submitting job
+
+[FLINK-10375 ] - ExceptionInChainedStubException hides wrapped exception in cause
+
+[FLINK-10582 ] - Make REST executor thread priority configurable
+
+
diff --git a/docs/content.tr/posts/2018-10-29-release-1.6.2.md b/docs/content.tr/posts/2018-10-29-release-1.6.2.md
new file mode 100644
index 0000000000..326f2e5839
--- /dev/null
+++ b/docs/content.tr/posts/2018-10-29-release-1.6.2.md
@@ -0,0 +1,135 @@
+---
+date: "2018-10-29T12:00:00Z"
+title: Apache Flink 1.6.2 Released
+aliases:
+- /news/2018/10/29/release-1.6.2.html
+---
+
+The Apache Flink community released the second bugfix version of the Apache Flink 1.6 series.
+
+This release includes more than 30 fixes and minor improvements for Flink 1.6.1. The list below includes a detailed list of all fixes.
+
+We highly recommend all users to upgrade to Flink 1.6.2.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.6.2
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.6.2
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.6.2
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-10242 ] - Latency marker interval should be configurable
+
+[FLINK-10243 ] - Add option to reduce latency metrics granularity
+
+[FLINK-10331 ] - Reduce number of flush requests to the network stack
+
+[FLINK-10332 ] - Move data available notification in PipelinedSubpartition out of the synchronized block
+
+
+
+ Bug
+
+
+[FLINK-5542 ] - YARN client incorrectly uses local YARN config to check vcore capacity
+
+[FLINK-9567 ] - Flink does not release resource in Yarn Cluster mode
+
+[FLINK-9788 ] - ExecutionGraph Inconsistency prevents Job from recovering
+
+[FLINK-9884 ] - Slot request may not be removed when it has already be assigned in slot manager
+
+[FLINK-9891 ] - Flink cluster is not shutdown in YARN mode when Flink client is stopped
+
+[FLINK-9932 ] - Timed-out TaskExecutor slot-offers to JobMaster leak the slot
+
+[FLINK-10135 ] - Certain cluster-level metrics are no longer exposed
+
+[FLINK-10157 ] - Allow `null` user values in map state with TTL
+
+[FLINK-10222 ] - Table scalar function expression parses error when function name equals the exists keyword suffix
+
+[FLINK-10259 ] - Key validation for GroupWindowAggregate is broken
+
+[FLINK-10263 ] - User-defined function with LITERAL paramters yields CompileException
+
+[FLINK-10316 ] - Add check to KinesisProducer that aws.region is set
+
+[FLINK-10354 ] - Savepoints should be counted as retained checkpoints
+
+[FLINK-10363 ] - S3 FileSystem factory prints secrets into logs
+
+[FLINK-10379 ] - Can not use Table Functions in Java Table API
+
+[FLINK-10383 ] - Hadoop configurations on the classpath seep into the S3 file system configs
+
+[FLINK-10390 ] - DataDog MetricReporter leaks connections
+
+[FLINK-10400 ] - Return failed JobResult if job terminates in state FAILED or CANCELED
+
+[FLINK-10415 ] - RestClient does not react to lost connection
+
+[FLINK-10444 ] - Make S3 entropy injection work with FileSystem safety net
+
+[FLINK-10451 ] - TableFunctionCollector should handle the life cycle of ScalarFunction
+
+[FLINK-10465 ] - Jepsen: runit supervised sshd is stopped on tear down
+
+[FLINK-10469 ] - FileChannel may not write the whole buffer in a single call to FileChannel.write(Buffer buffer)
+
+[FLINK-10487 ] - fix invalid Flink SQL example
+
+[FLINK-10516 ] - YarnApplicationMasterRunner does not initialize FileSystem with correct Flink Configuration during setup
+
+[FLINK-10524 ] - MemoryManagerConcurrentModReleaseTest.testConcurrentModificationWhileReleasing failed on travis
+
+[FLINK-10532 ] - Broken links in documentation
+
+[FLINK-10544 ] - Remove custom settings.xml for snapshot deployments
+
+
+
+ Improvement
+
+
+[FLINK-9061 ] - Add entropy to s3 path for better scalability
+
+[FLINK-10075 ] - HTTP connections to a secured REST endpoint flood the log
+
+[FLINK-10260 ] - Confusing log messages during TaskManager registration
+
+[FLINK-10282 ] - Provide separate thread-pool for REST endpoint
+
+[FLINK-10291 ] - Generate JobGraph with fixed/configurable JobID in StandaloneJobClusterEntrypoint
+
+[FLINK-10311 ] - HA end-to-end/Jepsen tests for standby Dispatchers
+
+[FLINK-10312 ] - Wrong / missing exception when submitting job
+
+[FLINK-10371 ] - Allow to enable SSL mutual authentication on REST endpoints by configuration
+
+[FLINK-10375 ] - ExceptionInChainedStubException hides wrapped exception in cause
+
+[FLINK-10582 ] - Make REST executor thread priority configurable
+
+
diff --git a/docs/content.tr/posts/2018-11-30-release-1.7.0.md b/docs/content.tr/posts/2018-11-30-release-1.7.0.md
new file mode 100644
index 0000000000..b74a159fa4
--- /dev/null
+++ b/docs/content.tr/posts/2018-11-30-release-1.7.0.md
@@ -0,0 +1,103 @@
+---
+authors:
+- name: Till Rohrmann
+ till: null
+ twitter: stsffap
+date: "2018-11-30T12:00:00Z"
+title: Apache Flink 1.7.0 Release Announcement
+aliases:
+- /news/2018/11/30/release-1.7.0.html
+---
+
+The Apache Flink community is pleased to announce Apache Flink 1.7.0.
+The latest release includes more than 420 resolved issues and some exciting additions to Flink that we describe in the following sections of this post.
+Please check the [complete changelog](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12343585) for more details.
+
+
+Flink 1.7.0 is API-compatible with previous 1.x.y releases for APIs annotated with the `@Public` annotation.
+The release is available now and we encourage everyone to [download the release](http://flink.apache.org/downloads.html) and check out the updated [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.7/).
+Feedback through the Flink [mailing lists](http://flink.apache.org/community.html#mailing-lists) or [JIRA](https://issues.apache.org/jira/projects/FLINK/summary) is, as always, very much appreciated!
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html) on the Flink project site.
+
+## Flink 1.7.0 - Extending the reach of Stream Processing
+
+In Flink 1.7.0 we come closer to our goals of enabling fast data processing and building data-intensive applications for the Flink community in a seamless way.
+Our latest release includes some exciting new features and improvements such as support for Scala 2.12, an exactly-once S3 file sink, the integration of complex event processing with streaming SQL and more features that we explain below.
+
+## New Features and Improvements
+
+* **Scala 2.12 Support in Apache Flink** ([FLINK-7811](https://issues.apache.org/jira/browse/FLINK-7811)):
+ Apache Flink 1.7.0 is the first release which comes with full support for Scala 2.12.
+ This allows users to write Flink applications with a newer Scala version and to leverage the Scala 2.12 ecosystem.
+
+* **State Evolution** ([FLINK-9376](https://issues.apache.org/jira/browse/FLINK-9376)):
+ In many cases, a long-running Flink application needs to evolve during its lifetime because of changing requirements.
+ Changing the user state without losing the current application progress in the form of its state is a crucial requirement for application evolution.
+
+ With Flink 1.7.0, the community added state evolution which allows you to flexibly adapt a long-running application's user states schema, while maintaining compatibility with previous savepoints.
+ With state evolution it is possible to add or remove columns to your state schema in order to change which business features will be captured by your application after it has been deployed.
+
+ State schema evolution now works out-of-the-box when using Avro's generated classes as user state, meaning that the schema of the state can be evolved according to Avro's specifications.
+ While Avro types are the only built-in type that supports schema evolution as of Flink 1.7, the community continues working to further extend support to other types in future Flink releases.
+
+* **Exactly-once S3 StreamingFileSink** ([FLINK-9752](https://issues.apache.org/jira/browse/FLINK-9752)):
+ The `StreamingFileSink` which was introduced in Flink 1.6.0 is now extended to also support writing to S3 filesystems with exactly-once processing guarantees.
+ Using this feature allows users to build exactly-once end-to-end pipelines writing to S3.
+
+* **`MATCH_RECOGNIZE` Support in Streaming SQL** ([FLINK-6935](https://issues.apache.org/jira/browse/FLINK-6935)):
+ This is a major addition to Apache Flink 1.7.0 that provides initial support of the [`MATCH_RECOGNIZE`]({{< param DocsBaseUrl >}}flink-docs-release-1.7/dev/table/streaming/match_recognize.html) standard to Flink SQL.
+ This feature combines both complex event processing (CEP) and SQL for easy pattern matching on data streams and, thus, enabling a whole set of new use cases.
+
+ This feature is currently in beta phase so we welcome any feedback and suggestions from the community for future iterations and improvements.
+
+* **Temporal Tables and Temporal Joins in Streaming SQL** ([FLINK-9712](https://issues.apache.org/jira/browse/FLINK-9712)):
+ Temporal Tables is a new concept in Apache Flink that gives a (parameterized) view on a table’s changing history and returns the content of a table at a specific point in time.
+
+ As an example, we can use a table with historical currency exchange rates.
+ Such a table is constantly growing/evolving as time progresses and newly updated exchange rates are added.
+ Temporal Table is a view that can return the actual state of those exchange rates to any given point of time.
+ With such a table it is possible to convert a stream of orders in different currencies to a common currency using the correct exchange rate.
+
+ Temporal Joins allow for memory and computational-efficient joins of Streaming data with an ever-changing/updating table, using either processing time or event time, while being ANSI SQL compliant.
+
+* **Miscellaneous Features for Streaming SQL**:
+ Besides the major features mentioned above, Flink's Table & SQL API has been extended to serve more use cases.
+
+ The following built-in functions were added to the APIs: `TO_BASE64`, `LOG2`, `LTRIM`, `REPEAT`, `REPLACE`, `COSH`, `SINH`, `TANH`
+
+ The SQL Client now supports the [definition of views]({{< param DocsBaseUrl >}}flink-docs-release-1.7/dev/table/sqlClient.html#sql-views) both in an environment file and within a CLI session.
+ Furthermore, basic SQL statement auto-completion has been added to the CLI.
+
+ The community added an [Elasticsearch 6 table sink]({{< param DocsBaseUrl >}}flink-docs-release-1.7/dev/table/connect.html#elasticsearch-connector) which allows to store updating results of a dynamic table.
+
+* **Versioned REST API** ([FLINK-7551](https://issues.apache.org/jira/browse/FLINK-7551)):
+ Beginning with Flink 1.7.0, the REST API is versioned.
+ This guarantees the stability of Flink’s REST API so that third-party applications can be developed against a stable API in Flink.
+ Thus, future Flink upgrades will not require changes to existing third-party integrations.
+
+* **Kafka 2.0 Connector** ([FLINK-10598](https://issues.apache.org/jira/browse/FLINK-10598)):
+ Apache Flink 1.7.0 continues to add more connectors, making it even easier to interact with more external systems.
+ In this release, the community added the Kafka 2.0 connector which allows to read from and write to Kafka 2.0 with exactly-once guarantees.
+
+* **Local Recovery** ([FLINK-9635](https://issues.apache.org/jira/browse/FLINK-9635)):
+ Apache Flink 1.7.0 completes the local recovery feature by extending Flink’s scheduling to take previous deployment locations into account in case of recovery.
+
+ If local recovery is enabled Flink will keep a local copy of the latest checkpoint on the machine where the task is running.
+ By scheduling tasks to their previous locations, Flink will, thus, minimize the network traffic for restoring state by reading checkpoint state from local disk.
+ This feature considerably improves recovery speed.
+
+* **Removal of Flink’s Legacy Mode** ([FLINK-10392](https://issues.apache.org/jira/browse/FLINK-10392)):
+ Apache Flink 1.7.0 marks the release where the Flip-6 effort has been fully completed and reached feature parity with the legacy mode.
+ Consequently, this release removes support for the legacy mode.
+
+## Release Notes
+
+Please review the [release notes]({{< param DocsBaseUrl >}}flink-docs-release-1.7/release-notes/flink-1.7.html) if you plan to upgrade your Flink setup to Flink 1.7.
+
+## List of Contributors
+
+We would like to acknowledge all community members for contributing to this release.
+Special credits go to the following members for contributing to the 1.7.0 release (according to git):
+
+Aitozi, Alex Arkhipov, Alexander Koltsov, Alexey Trenikhin, Alice, Alice Yan, Aljoscha Krettek, Andrei Poluliakh, Andrey Zagrebin, Ashwin Sinha, Barisa Obradovic, Ben La Monica, Benoit Meriaux, Bowen Li, Chesnay Schepler, Christophe Jolif, Congxian Qiu, Craig Foster, David Anderson, Dawid Wysakowicz, Dian Fu, Diego Carvallo, Dimitris Palyvos, Eugen Yushin, Fabian Hueske, Florian Schmidt, Gary Yao, Guibo Pan, Hequn Cheng, Hiroaki Yoshida, Igal Shilman, JIN SUN, Jamie Grier, Jayant Ameta, Jeff Zhang, Jeffrey Chung, Jicaar, Jin Sun, Joe Malt, Johannes Dillmann, Jun Zhang, Kostas Kloudas, Krzysztof Białek, Lakshmi Gururaja Rao, Liu Biao, Mahesh Senniappan, Manuel Hoffmann, Mark Cho, Max Feng, Mike Pedersen, Mododo, Nico Kruber, Oleksandr Nitavskyi, Osman Şamil AKÇELİK, Patrick Lucas, Paul Lam, Piotr Nowojski, Rick Hofstede, Rong R, Rong Rong, Sayat Satybaldiyev, Sebastian Klemke, Seth Wiesman, Shimin Yang, Shuyi Chen, Stefan Richter, Stephan Ewen, Stephen Jason, Thomas Weise, Till Rohrmann, Timo Walther, Tzu-Li "tison" Chen, Tzu-Li (Gordon) Tai, Tzu-Li Chen, Wosin, Xingcan Cui, Xpray, Xue Yu, Yangze Guo, Ying Xu, Yun Tang, Zhijiang, blues Zheng, hequn8128, ifndef-SleePy, jerryjzhang, jrthe42, jyc.jia, kkolman, lihongli, linjun, linzhaoming, liurenjie1024, liuxianjiao, lrl, lsy, lzqdename, maqingxiang, maqingxiang-it, minwenjun, shuai-xu, sihuazhou, snuyanzin, wind, xuewei.linxuewei, xueyu, xuqianjin, yanghua, yangshimin, zhijiang, 谢磊, 陈梓立
\ No newline at end of file
diff --git a/docs/content.tr/posts/2018-12-21-release-1.7.1.md b/docs/content.tr/posts/2018-12-21-release-1.7.1.md
new file mode 100644
index 0000000000..dd23448a04
--- /dev/null
+++ b/docs/content.tr/posts/2018-12-21-release-1.7.1.md
@@ -0,0 +1,105 @@
+---
+date: "2018-12-21T12:00:00Z"
+title: Apache Flink 1.7.1 Released
+aliases:
+- /news/2018/12/21/release-1.7.1.html
+---
+
+The Apache Flink community released the first bugfix version of the Apache Flink 1.7 series.
+
+This release includes 27 fixes and minor improvements for Flink 1.7.0. The list below includes a detailed list of all fixes.
+
+We highly recommend all users to upgrade to Flink 1.7.1.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.7.1
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.7.1
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.7.1
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-10252 ] - Handle oversized metric messages
+
+[FLINK-10367 ] - Avoid recursion stack overflow during releasing SingleInputGate
+
+[FLINK-10522 ] - Check if RecoverableWriter supportsResume and act accordingly.
+
+[FLINK-10963 ] - Cleanup small objects uploaded to S3 as independent objects
+
+
+
+ Bug
+
+
+[FLINK-8336 ] - YarnFileStageTestS3ITCase.testRecursiveUploadForYarnS3 test instability
+
+[FLINK-9646 ] - ExecutionGraphCoLocationRestartTest.testConstraintsAfterRestart failed on Travis
+
+[FLINK-10149 ] - Fink Mesos allocates extra port when not configured to do so.
+
+[FLINK-10359 ] - Scala example in DataSet docs is broken
+
+[FLINK-10482 ] - java.lang.IllegalArgumentException: Negative number of in progress checkpoints
+
+[FLINK-10566 ] - Flink Planning is exponential in the number of stages
+
+[FLINK-10997 ] - Avro-confluent-registry does not bundle any dependency
+
+[FLINK-11011 ] - Elasticsearch 6 sink end-to-end test unstable
+
+[FLINK-11013 ] - Fix distinct aggregates for group window in Table API
+
+[FLINK-11017 ] - Time interval for window aggregations in SQL is wrongly translated if specified with YEAR_MONTH resolution
+
+[FLINK-11029 ] - Incorrect parameter in Working with state doc
+
+[FLINK-11032 ] - Elasticsearch (v6.3.1) sink end-to-end test unstable on Travis
+
+[FLINK-11033 ] - Elasticsearch (v6.3.1) sink end-to-end test unstable on Travis
+
+[FLINK-11041 ] - ReinterpretDataStreamAsKeyedStreamITCase.testReinterpretAsKeyedStream failed on Travis
+
+[FLINK-11044 ] - RegisterTableSink docs incorrect
+
+[FLINK-11045 ] - UserCodeClassLoader has not been set correctly for RuntimeUDFContext in CollectionExecutor
+
+[FLINK-11047 ] - CoGroupGroupSortTranslationTest does not compile with scala 2.12
+
+[FLINK-11085 ] - NoClassDefFoundError in presto-s3 filesystem
+
+[FLINK-11087 ] - Broadcast state migration Incompatibility from 1.5.3 to 1.7.0
+
+[FLINK-11094 ] - Restored state in RocksDBStateBackend that has not been accessed in restored execution causes NPE on snapshot
+
+[FLINK-11123 ] - Missing import in ML quickstart docs
+
+[FLINK-11136 ] - Fix the logical of merge for DISTINCT aggregates
+
+
+
+ Improvement
+
+
+[FLINK-11080 ] - Define flink-connector-elasticsearch6 uber-jar dependencies via artifactSet
+
+
diff --git a/docs/content.tr/posts/2018-12-22-release-1.6.3.md b/docs/content.tr/posts/2018-12-22-release-1.6.3.md
new file mode 100644
index 0000000000..f513cf9096
--- /dev/null
+++ b/docs/content.tr/posts/2018-12-22-release-1.6.3.md
@@ -0,0 +1,225 @@
+---
+date: "2018-12-22T12:00:00Z"
+title: Apache Flink 1.6.3 Released
+aliases:
+- /news/2018/12/22/release-1.6.3.html
+---
+
+The Apache Flink community released the third bugfix version of the Apache Flink 1.6 series.
+
+This release includes more than 80 fixes and minor improvements for Flink 1.6.2. The list below includes a detailed list of all fixes.
+
+We highly recommend all users to upgrade to Flink 1.6.3.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.6.3
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.6.3
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.6.3
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-10097 ] - More tests to increase StreamingFileSink test coverage
+
+[FLINK-10252 ] - Handle oversized metric messages
+
+[FLINK-10367 ] - Avoid recursion stack overflow during releasing SingleInputGate
+
+[FLINK-10863 ] - Assign uids to all operators in general purpose testing job
+
+
+
+ Bug
+
+
+[FLINK-8336 ] - YarnFileStageTestS3ITCase.testRecursiveUploadForYarnS3 test instability
+
+[FLINK-9635 ] - Local recovery scheduling can cause spread out of tasks
+
+[FLINK-9646 ] - ExecutionGraphCoLocationRestartTest.testConstraintsAfterRestart failed on Travis
+
+[FLINK-9878 ] - IO worker threads BLOCKED on SSL Session Cache while CMS full gc
+
+[FLINK-10149 ] - Fink Mesos allocates extra port when not configured to do so.
+
+[FLINK-10166 ] - Dependency problems when executing SQL query in sql-client
+
+[FLINK-10309 ] - Cancel with savepoint fails with java.net.ConnectException when using the per job-mode
+
+[FLINK-10357 ] - Streaming File Sink end-to-end test failed with mismatch
+
+[FLINK-10359 ] - Scala example in DataSet docs is broken
+
+[FLINK-10364 ] - Test instability in NonHAQueryableStateFsBackendITCase#testMapState
+
+[FLINK-10419 ] - ClassNotFoundException while deserializing user exceptions from checkpointing
+
+[FLINK-10425 ] - taskmanager.host is not respected
+
+[FLINK-10455 ] - Potential Kafka producer leak in case of failures
+
+[FLINK-10463 ] - Null literal cannot be properly parsed in Java Table API function call
+
+[FLINK-10481 ] - Wordcount end-to-end test in docker env unstable
+
+[FLINK-10482 ] - java.lang.IllegalArgumentException: Negative number of in progress checkpoints
+
+[FLINK-10491 ] - Deadlock during spilling data in SpillableSubpartition
+
+[FLINK-10566 ] - Flink Planning is exponential in the number of stages
+
+[FLINK-10567 ] - Lost serialize fields when ttl state store with the mutable serializer
+
+[FLINK-10570 ] - State grows unbounded when "within" constraint not applied
+
+[FLINK-10581 ] - YarnConfigurationITCase.testFlinkContainerMemory test instability
+
+[FLINK-10642 ] - CodeGen split fields errors when maxGeneratedCodeLength equals 1
+
+[FLINK-10655 ] - RemoteRpcInvocation not overwriting ObjectInputStream's ClassNotFoundException
+
+[FLINK-10663 ] - Closing StreamingFileSink can cause NPE
+
+[FLINK-10669 ] - Exceptions & errors are not properly checked in logs in e2e tests
+
+[FLINK-10670 ] - Fix Correlate codegen error
+
+[FLINK-10674 ] - Fix handling of retractions after clean up
+
+[FLINK-10681 ] - elasticsearch6.ElasticsearchSinkITCase fails if wrong JNA library installed
+
+[FLINK-10690 ] - Tests leak resources via Files.list
+
+[FLINK-10693 ] - Fix Scala EitherSerializer duplication
+
+[FLINK-10715 ] - E2e tests fail with ConcurrentModificationException in MetricRegistryImpl
+
+[FLINK-10750 ] - SocketClientSinkTest.testRetry fails on Travis
+
+[FLINK-10752 ] - Result of AbstractYarnClusterDescriptor#validateClusterResources is ignored
+
+[FLINK-10753 ] - Propagate and log snapshotting exceptions
+
+[FLINK-10763 ] - Interval join produces wrong result type in Scala API
+
+[FLINK-10770 ] - Some generated functions are not opened properly.
+
+[FLINK-10773 ] - Resume externalized checkpoint end-to-end test fails
+
+[FLINK-10809 ] - Using DataStreamUtils.reinterpretAsKeyedStream produces corrupted keyed state after restore
+
+[FLINK-10816 ] - Fix LockableTypeSerializer.duplicate()
+
+[FLINK-10821 ] - Resuming Externalized Checkpoint E2E test does not resume from Externalized Checkpoint
+
+[FLINK-10839 ] - Fix implementation of PojoSerializer.duplicate() w.r.t. subclass serializer
+
+[FLINK-10842 ] - Waiting loops are broken in e2e/common.sh
+
+[FLINK-10856 ] - Harden resume from externalized checkpoint E2E test
+
+[FLINK-10857 ] - Conflict between JMX and Prometheus Metrics reporter
+
+[FLINK-10880 ] - Failover strategies should not be applied to Batch Execution
+
+[FLINK-10913 ] - ExecutionGraphRestartTest.testRestartAutomatically unstable on Travis
+
+[FLINK-10925 ] - NPE in PythonPlanStreamer
+
+[FLINK-10946 ] - Resuming Externalized Checkpoint (rocks, incremental, scale up) end-to-end test failed on Travis
+
+[FLINK-10990 ] - Enforce minimum timespan in MeterView
+
+[FLINK-10992 ] - Jepsen: Do not use /tmp as HDFS Data Directory
+
+[FLINK-10997 ] - Avro-confluent-registry does not bundle any dependency
+
+[FLINK-10998 ] - flink-metrics-ganglia has LGPL dependency
+
+[FLINK-11011 ] - Elasticsearch 6 sink end-to-end test unstable
+
+[FLINK-11017 ] - Time interval for window aggregations in SQL is wrongly translated if specified with YEAR_MONTH resolution
+
+[FLINK-11029 ] - Incorrect parameter in Working with state doc
+
+[FLINK-11041 ] - ReinterpretDataStreamAsKeyedStreamITCase.testReinterpretAsKeyedStream failed on Travis
+
+[FLINK-11045 ] - UserCodeClassLoader has not been set correctly for RuntimeUDFContext in CollectionExecutor
+
+[FLINK-11083 ] - CRowSerializerConfigSnapshot is not instantiable
+
+[FLINK-11087 ] - Broadcast state migration Incompatibility from 1.5.3 to 1.7.0
+
+[FLINK-11123 ] - Missing import in ML quickstart docs
+
+[FLINK-11136 ] - Fix the logical of merge for DISTINCT aggregates
+
+
+
+ Improvement
+
+
+[FLINK-4173 ] - Replace maven-assembly-plugin by maven-shade-plugin in flink-metrics
+
+[FLINK-10353 ] - Restoring a KafkaProducer with Semantic.EXACTLY_ONCE from a savepoint written with Semantic.AT_LEAST_ONCE fails with NPE
+
+[FLINK-10608 ] - Add avro files generated by datastream-allround-test to RAT exclusions
+
+[FLINK-10613 ] - Remove logger casts in HBaseConnectorITCase
+
+[FLINK-10614 ] - Update test_batch_allround.sh e2e to new testing infrastructure
+
+[FLINK-10637 ] - Start MiniCluster with random REST port
+
+[FLINK-10678 ] - Add a switch to run_test to configure if logs should be checked for errors/excepions
+
+[FLINK-10692 ] - Harden Confluent schema E2E test
+
+[FLINK-10883 ] - Submitting a jobs without enough slots times out due to a unspecified timeout
+
+[FLINK-10906 ] - docker-entrypoint.sh logs credentails during startup
+
+[FLINK-10916 ] - Include duplicated user-specified uid into error message
+
+[FLINK-10951 ] - Disable enforcing of YARN container virtual memory limits in tests
+
+[FLINK-11005 ] - Define flink-sql-client uber-jar dependencies via artifactSet
+
+
+
+ Test
+
+
+[FLINK-10606 ] - Construct NetworkEnvironment simple for tests
+
+[FLINK-10607 ] - Unify to remove duplicated NoOpResultPartitionConsumableNotifier
+
+[FLINK-10827 ] - Add test for duplicate() to SerializerTestBase
+
+
+
+ Wish
+
+
+[FLINK-10793 ] - Change visibility of TtlValue and TtlSerializer to public for external tools
+
+
\ No newline at end of file
diff --git a/docs/content.tr/posts/2018-12-26-release-1.5.6.md b/docs/content.tr/posts/2018-12-26-release-1.5.6.md
new file mode 100644
index 0000000000..31d8cc772b
--- /dev/null
+++ b/docs/content.tr/posts/2018-12-26-release-1.5.6.md
@@ -0,0 +1,150 @@
+---
+date: "2018-12-26T12:00:00Z"
+title: Apache Flink 1.5.6 Released
+aliases:
+- /news/2018/12/26/release-1.5.6.html
+---
+
+The Apache Flink community released the sixth and last bugfix version of the Apache Flink 1.5 series.
+
+This release includes more than 47 fixes and minor improvements for Flink 1.5.5. The list below includes a detailed list of all fixes.
+
+We highly recommend all users to upgrade to Flink 1.5.6.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.5.6
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.5.6
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.5.6
+
+```
+
+You can find the binaries on the updated [Downloads page](http://flink.apache.org/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+
+ Bug
+
+
+[FLINK-8336 ] - YarnFileStageTestS3ITCase.testRecursiveUploadForYarnS3 test instability
+
+[FLINK-9646 ] - ExecutionGraphCoLocationRestartTest.testConstraintsAfterRestart failed on Travis
+
+[FLINK-10166 ] - Dependency problems when executing SQL query in sql-client
+
+[FLINK-10309 ] - Cancel with savepoint fails with java.net.ConnectException when using the per job-mode
+
+[FLINK-10419 ] - ClassNotFoundException while deserializing user exceptions from checkpointing
+
+[FLINK-10455 ] - Potential Kafka producer leak in case of failures
+
+[FLINK-10482 ] - java.lang.IllegalArgumentException: Negative number of in progress checkpoints
+
+[FLINK-10491 ] - Deadlock during spilling data in SpillableSubpartition
+
+[FLINK-10566 ] - Flink Planning is exponential in the number of stages
+
+[FLINK-10581 ] - YarnConfigurationITCase.testFlinkContainerMemory test instability
+
+[FLINK-10642 ] - CodeGen split fields errors when maxGeneratedCodeLength equals 1
+
+[FLINK-10655 ] - RemoteRpcInvocation not overwriting ObjectInputStream's ClassNotFoundException
+
+[FLINK-10669 ] - Exceptions & errors are not properly checked in logs in e2e tests
+
+[FLINK-10670 ] - Fix Correlate codegen error
+
+[FLINK-10674 ] - Fix handling of retractions after clean up
+
+[FLINK-10690 ] - Tests leak resources via Files.list
+
+[FLINK-10693 ] - Fix Scala EitherSerializer duplication
+
+[FLINK-10715 ] - E2e tests fail with ConcurrentModificationException in MetricRegistryImpl
+
+[FLINK-10750 ] - SocketClientSinkTest.testRetry fails on Travis
+
+[FLINK-10752 ] - Result of AbstractYarnClusterDescriptor#validateClusterResources is ignored
+
+[FLINK-10753 ] - Propagate and log snapshotting exceptions
+
+[FLINK-10770 ] - Some generated functions are not opened properly.
+
+[FLINK-10773 ] - Resume externalized checkpoint end-to-end test fails
+
+[FLINK-10821 ] - Resuming Externalized Checkpoint E2E test does not resume from Externalized Checkpoint
+
+[FLINK-10839 ] - Fix implementation of PojoSerializer.duplicate() w.r.t. subclass serializer
+
+[FLINK-10856 ] - Harden resume from externalized checkpoint E2E test
+
+[FLINK-10857 ] - Conflict between JMX and Prometheus Metrics reporter
+
+[FLINK-10880 ] - Failover strategies should not be applied to Batch Execution
+
+[FLINK-10913 ] - ExecutionGraphRestartTest.testRestartAutomatically unstable on Travis
+
+[FLINK-10925 ] - NPE in PythonPlanStreamer
+
+[FLINK-10990 ] - Enforce minimum timespan in MeterView
+
+[FLINK-10998 ] - flink-metrics-ganglia has LGPL dependency
+
+[FLINK-11011 ] - Elasticsearch 6 sink end-to-end test unstable
+
+
+
+ Improvement
+
+
+[FLINK-4173 ] - Replace maven-assembly-plugin by maven-shade-plugin in flink-metrics
+
+[FLINK-9869 ] - Send PartitionInfo in batch to Improve perfornance
+
+[FLINK-10613 ] - Remove logger casts in HBaseConnectorITCase
+
+[FLINK-10614 ] - Update test_batch_allround.sh e2e to new testing infrastructure
+
+[FLINK-10637 ] - Start MiniCluster with random REST port
+
+[FLINK-10678 ] - Add a switch to run_test to configure if logs should be checked for errors/excepions
+
+[FLINK-10906 ] - docker-entrypoint.sh logs credentails during startup
+
+[FLINK-10916 ] - Include duplicated user-specified uid into error message
+
+[FLINK-11005 ] - Define flink-sql-client uber-jar dependencies via artifactSet
+
+
+
+ Test
+
+
+[FLINK-10606 ] - Construct NetworkEnvironment simple for tests
+
+[FLINK-10607 ] - Unify to remove duplicated NoOpResultPartitionConsumableNotifier
+
+[FLINK-10827 ] - Add test for duplicate() to SerializerTestBase
+
+
diff --git a/docs/content.tr/posts/2019-02-13-unified-batch-streaming-blink.md b/docs/content.tr/posts/2019-02-13-unified-batch-streaming-blink.md
new file mode 100644
index 0000000000..5b21887a69
--- /dev/null
+++ b/docs/content.tr/posts/2019-02-13-unified-batch-streaming-blink.md
@@ -0,0 +1,145 @@
+---
+authors:
+- name: Stephan Ewen
+ stephan: null
+ twitter: stephanewen
+- fabian: null
+ name: Fabian Hueske
+ twitter: fhueske
+- name: Xiaowei Jiang
+ twitter: XiaoweiJ
+ xiaowei: null
+date: "2019-02-13T12:00:00Z"
+excerpt: A few weeks ago, Alibaba contributed its Flink-fork 'Blink' back to Apache
+ Flink. In this blog post we discuss how Blink's features will help the Flink community
+ to make a big step towards its vision to build a truly unified system for stream
+ and batch processing.
+title: Batch as a Special Case of Streaming and Alibaba's contribution of Blink
+aliases:
+- /news/2019/02/13/unified-batch-streaming-blink.html
+---
+
+Last week, we [broke the news](https://lists.apache.org/thread.html/2f7330e85d702a53b4a2b361149930b50f2e89d8e8a572f8ee2a0e6d@%3Cdev.flink.apache.org%3E) that Alibaba decided to contribute its Flink-fork, called Blink, back to the Apache Flink project. Why is that a big thing for Flink, what will it mean for users and the community, and how does it fit into Flink’s overall vision? Let's take a step back to understand this better...
+
+## A Unified Approach to Batch and Streaming
+
+Since its early days, Apache Flink has followed the philosophy of taking a unified approach to batch and streaming data processing. The core building block is *"continuous processing of unbounded data streams"*: if you can do that, you can also do offline processing of bounded data sets (batch processing use cases), because these are just streams that happen to end at some point.
+
+
+
+
+
+
+The *"streaming first, with batch as a special case of streaming"* philosophy is supported by various projects (for example [Flink](https://flink.apache.org), [Beam](https://beam.apache.org), etc.) and often been cited as a powerful way to build data applications that [generalize across real-time and offline processing](https://www.oreilly.com/ideas/the-world-beyond-batch-streaming-101) and to help greatly reduce the complexity of data infrastructures.
+
+### Why are there still batch processors?
+
+However, *"batch is just a special case of streaming"* does not mean that any stream processor is now the right tool for your batch processing use cases - the introduction of stream processors did not render batch processors obsolete:
+
+* Pure stream processing systems are very slow at batch processing workloads. No one would consider it a good idea to use a stream processor that shuffles through message queues to analyze large amounts of available data.
+
+* Unified APIs like [Apache Beam](https://beam.apache.org) often delegate to different runtimes depending on whether the data is continuous/unbounded of fix/bounded. For example, the implementations of the batch and streaming runtime of Google Cloud Dataflow are different, to get the desired performance and resilience in each case.
+
+* *Apache Flink* has a streaming API that can do bounded/unbounded use cases, but still offers a separate DataSet API and runtime stack that is faster for batch use cases.
+
+What is the reason for the above? Where did *"batch is just a special case of streaming"* go wrong?
+
+The answer is simple, nothing is wrong with that paradigm. Unifying batch and streaming in the API is one aspect. One needs to also exploit certain characteristics of the special case “bounded data” in the runtime to competitively handle batch processing use cases. After all, batch processors have been built specifically for that special case.
+
+## Batch on top of a Streaming Runtime
+
+We always believed that it is possible to have a runtime that is state-of-the-art for both stream processing and batch processing use cases at the same time. A runtime that is streaming-first, but can exploit just the right amount of special properties of bounded streams to be as fast for batch use cases as dedicated batch processors. **This is the unique approach that Flink takes.**
+
+Apache Flink has a network stack that supports both [low-latency/high-throughput streaming data exchanges](https://www.ververica.com/flink-forward-berlin/resources/improving-throughput-and-latency-with-flinks-network-stack), as well as high-throughput batch shuffles. Flink has streaming runtime operators for many operations, but also specialized operators for bounded inputs, which get used when you choose the DataSet API or select the batch environment in the Table API.
+
+
+
+
+The figure illustrates a streaming join and a batch join. The batch join can read one input fully into a hash table and then probe with the other input. The stream join needs to build tables for both sides, because it needs to continuously process both inputs.
+For data larger than memory, the batch join can partition both data sets into subsets that fit in memory (data hits disk once) whereas the continuous nature of the stream join requires it to always keep all data in the table and repeatedly hit disk on cache misses.
+
+
+
+Because of that, Apache Flink has been actually demonstrating some pretty impressive batch processing performance since its early days. The below benchmark is a bit older, but validated our architectural approach early on.
+
+
+
+
+Time to sort 3.2 TB (80 GB/node), in seconds
+(Presentation by Dongwon Kim, Flink Forward Berlin 2015 .)
+
+
+
+## What is still missing?
+
+To conclude the approach and make Flink's experience on bounded data (batch) state-of-the-art, we need to add a few more enhancements. We believe that these features are key to realizing our vision:
+
+**(1) A truly unified runtime operator stack**: Currently the bounded and unbounded operators have a different network and threading model and don't mix and match. The original reason was that batch operators followed a "pull model" (easier for batch algorithms), while streaming operators followed a "push model" (better latency/throughput characteristics). In a unified stack, continuous streaming operators are the foundation. When operating on bounded data without latency constraints, the API or the query optimizer can select from a larger set of operators. The optimizer can pick, for example, a specialized join operator that first consumes one input stream entirely before reading the second input stream.
+
+**(2) Exploiting bounded streams to reduce the scope of fault tolerance**: When input data is bounded, it is possible to completely buffer data during shuffles (memory or disk) and replay that data after a failure. This makes recovery more fine grained and thus much more efficient.
+
+**(3) Exploiting bounded stream operator properties for scheduling**: A continuous unbounded streaming application needs (by definition) all operators running at the same time. An application on bounded data can schedule operations after another, depending on how the operators consume data (e.g., first build hash table, then probe hash table). This increases resource efficiency.
+
+**(4) Enabling these special case optimizations for the DataStream API**: Currently, only the Table API (which is unified across bounded/unbounded streams) activates these optimizations when working on bounded data.
+
+**(5) Performance and coverage for SQL**: SQL is the de-facto standard data language, and while it is also being rapidly adopted for continuous streaming use cases, there is absolutely no way past it for bounded/batch use cases. To be competitive with the best batch engines, Flink needs more coverage and performance for the SQL query execution. While the core data-plane in Flink is high performance, the speed of SQL execution ultimately depends a lot also on optimizer rules, a rich set of operators, and features like code generation.
+
+## Enter Blink
+
+Blink is a fork of Apache Flink, originally created inside Alibaba to improve Flink’s behavior for internal use cases. Blink adds a series of improvements and integrations (see the [Readme](https://github.com/apache/flink/blob/blink/README.md) for details), many of which fall into the category of improved bounded-data/batch processing and SQL. In fact, of the above list of features for a unified batch/streaming system, Blink implements significant steps forward in all except (4):
+
+**Unified Stream Operators:** Blink extends the Flink streaming runtime operator model to support selectively reading from different inputs, while keeping the push model for very low latency. This control over the inputs helps to now support algorithms like hybrid hash-joins on the same operator and threading model as continuous symmetric joins through RocksDB. These operators also form the basis for future features like [“Side Inputs”](https://cwiki.apache.org/confluence/display/FLINK/FLIP-17+Side+Inputs+for+DataStream+API).
+
+**Table API & SQL Query Processor:** The SQL query processor is the component that evolved the changed most compared to the latest Flink master branch:
+
+- While Flink currently translates queries either into DataSet or DataStream programs (depending on the characteristics of their inputs), Blink translates queries to a data flow of the aforementioned stream operators.
+
+- Blink adds many more runtime operators for common SQL operations like semi-joins, anti-joins, etc.
+
+- The query planner (optimizer) is still based on Apache Calcite, but has many more optimization rules (incl. join reordering) and uses a proper cost model for planning.
+
+- Stream operators are more aggressively chained.
+
+- The common data structures (sorters, hash tables) and serializers are extended to go even further in operating on binary data and saving serialization overhead. Code generation is used for the row serializers.
+
+**Improved Scheduling and Failure Recovery:** Finally, Blink implements several improvements for task scheduling and fault tolerance. The scheduling strategies use resources better by exploiting how the operators process their input data. The failover strategies recover more fine-grained along the boundaries of persistent shuffles. A failed JobManager can be replaced without restarting a running application.
+
+The changes in Blink result in a big improvement in performance. The below numbers were reported by the developers of Blink to give a rough impression of the performance gains.
+
+
+
+
+Relative performance of Blink versus Flink 1.6.0 in the TPC-H benchmark, query by query.
+The performance improvement is in average 10x.
+Presentation by Xiaowei Jiang at Flink Forward Berlin, 2018 .)
+
+
+
+
+
+
+Performance of Blink versus Spark in the TPC-DS benchmark, aggregate time for all queries together.
+Presentation by Xiaowei Jiang at Flink Forward Beijing, 2018 .
+
+
+
+## How do we plan to merge Blink and Flink?
+
+Blink’s code is currently available as a [branch](https://github.com/apache/flink/tree/blink) in the Apache Flink repository. It is a challenge to merge a such big amount of changes, while making the merge process as non-disruptive as possible and keeping public APIs as stable as possible.
+
+The community’s [merge plan](https://lists.apache.org/thread.html/6066abd0f09fc1c41190afad67770ede8efd0bebc36f00938eecc118@%3Cdev.flink.apache.org%3E) focuses initially on the bounded/batch processing features mentioned above and follows the following approach to ensure a smooth integration:
+
+* To merge Blink’s _SQL/Table API query processor_ enhancements, we exploit the fact that both Flink and Blink have the same APIs: SQL and the Table API.
+Following some restructuring of the Table/SQL module ([FLIP-32](https://cwiki.apache.org/confluence/display/FLINK/FLIP-32%3A+Restructure+flink-table+for+future+contributions)) we plan to merge the Blink query planner (optimizer) and runtime (operators) as an additional query processor next to the current SQL runtime. Think of it as two different runners for the same APIs.
+Initially, users will be able to select which query processor to use. After a transition period in which the new query processor will be developed to subsume the current query processor, the current processor will most likely be deprecated and eventually dropped. Given that SQL is such a well defined interface, we anticipate that this transition has little friction for users. Mostly a pleasant surprise to have broader SQL feature coverage and a boost in performance.
+
+* To support the merge of Blink’s _enhancements to scheduling and recovery_ for jobs on bounded data, the Flink community is already working on refactoring its current schedule and adding support for [pluggable scheduling and fail-over strategies](https://issues.apache.org/jira/browse/FLINK-10429).
+Once this effort is finished, we can add Blink’s scheduling and recovery strategies as a new scheduling strategy that is used by the new query processor. Eventually, we plan to use the new scheduling strategy also for bounded DataStream programs.
+
+* The extended catalog support, DDL support, as well as support for Hive’s catalog and integrations is currently going through separate design discussions. We plan to leverage existing code here whenever it makes sense.
+
+## Summary
+
+We believe that the data processing stack of the future is based on stream processing: The elegance of stream processing with its ability to model offline processing (batch), real-time data processing, and event-driven applications in the same way, while offering high performance and consistency is simply too compelling.
+
+Exploiting certain properties of bounded data is important for a stream processor to achieve the same performance as dedicated batch processors. While Flink always supported batch processing, the project is taking the next step in building a unified runtime and towards **becoming a stream processor that is competitive with batch processing systems even on their home turf: OLAP SQL.** The contribution of Alibaba’s Blink code helps the Flink community to pick up the speed on this development.
\ No newline at end of file
diff --git a/docs/content.tr/posts/2019-02-15-release-1.7.2.md b/docs/content.tr/posts/2019-02-15-release-1.7.2.md
new file mode 100644
index 0000000000..a80b55bb6e
--- /dev/null
+++ b/docs/content.tr/posts/2019-02-15-release-1.7.2.md
@@ -0,0 +1,152 @@
+---
+date: "2019-02-15T12:00:00Z"
+title: Apache Flink 1.7.2 Released
+aliases:
+- /news/2019/02/15/release-1.7.2.html
+---
+
+The Apache Flink community released the second bugfix version of the Apache Flink 1.7 series.
+
+This release includes more than 40 fixes and minor improvements for Flink 1.7.1, covering several critical
+recovery issues as well as problems in the Flink streaming connectors.
+
+The list below includes a detailed list of all fixes.
+We highly recommend all users to upgrade to Flink 1.7.2.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.7.2
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.7.2
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.7.2
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-11179 ] - JoinCancelingITCase#testCancelSortMatchWhileDoingHeavySorting test error
+
+[FLINK-11180 ] - ProcessFailureCancelingITCase#testCancelingOnProcessFailure
+
+[FLINK-11181 ] - SimpleRecoveryITCaseBase test error
+
+
+
+ Bug
+
+
+[FLINK-10721 ] - Kafka discovery-loop exceptions may be swallowed
+
+[FLINK-10761 ] - MetricGroup#getAllVariables can deadlock
+
+[FLINK-10774 ] - connection leak when partition discovery is disabled and open throws exception
+
+[FLINK-10848 ] - Flink's Yarn ResourceManager can allocate too many excess containers
+
+[FLINK-11046 ] - ElasticSearch6Connector cause thread blocked when index failed with retry
+
+[FLINK-11071 ] - Dynamic proxy classes cannot be resolved when deserializing job graph
+
+[FLINK-11083 ] - CRowSerializerConfigSnapshot is not instantiable
+
+[FLINK-11084 ] - Incorrect ouput after two consecutive split and select
+
+[FLINK-11100 ] - Presto S3 FileSystem E2E test broken
+
+[FLINK-11119 ] - Incorrect Scala example for Table Function
+
+[FLINK-11134 ] - Invalid REST API request should not log the full exception in Flink logs
+
+[FLINK-11145 ] - Fix Hadoop version handling in binary release script
+
+[FLINK-11151 ] - FileUploadHandler stops working if the upload directory is removed
+
+[FLINK-11168 ] - LargePlanTest times out on Travis
+
+[FLINK-11173 ] - Proctime attribute validation throws an incorrect exception message
+
+[FLINK-11187 ] - StreamingFileSink with S3 backend transient socket timeout issues
+
+[FLINK-11191 ] - Exception in code generation when ambiguous columns in MATCH_RECOGNIZE
+
+[FLINK-11194 ] - missing Scala 2.12 build of HBase connector
+
+[FLINK-11201 ] - Document SBT dependency requirements when using MiniClusterResource
+
+[FLINK-11224 ] - Log is missing in scala-shell
+
+[FLINK-11227 ] - The DescriptorProperties contains some bounds checking errors
+
+[FLINK-11232 ] - Empty Start Time of sub-task on web dashboard
+
+[FLINK-11234 ] - ExternalTableCatalogBuilder unable to build a batch-only table
+
+[FLINK-11235 ] - Elasticsearch connector leaks threads if no connection could be established
+
+[FLINK-11246 ] - Fix distinct AGG visibility issues
+
+[FLINK-11251 ] - Incompatible metric name on prometheus reporter
+
+[FLINK-11279 ] - Invalid week interval parsing in ExpressionParser
+
+[FLINK-11302 ] - FlinkS3FileSystem uses an incorrect path for temporary files.
+
+[FLINK-11389 ] - Incorrectly use job information when call getSerializedTaskInformation in class TaskDeploymentDescriptor
+
+[FLINK-11419 ] - StreamingFileSink fails to recover after taskmanager failure
+
+[FLINK-11436 ] - Java deserialization failure of the AvroSerializer when used in an old CompositeSerializers
+
+
+
+ New Feature
+
+
+[FLINK-10457 ] - Support SequenceFile for StreamingFileSink
+
+
+
+ Improvement
+
+
+[FLINK-10910 ] - Harden Kubernetes e2e test
+
+[FLINK-11023 ] - Update LICENSE and NOTICE files for flink-connectors
+
+[FLINK-11079 ] - Skip deployment for flink-storm-examples
+
+[FLINK-11207 ] - Update Apache commons-compress from 1.4.1 to 1.18
+
+[FLINK-11216 ] - Back to top button is missing in the Joining document and is not properly placed in the Process Function document
+
+[FLINK-11262 ] - Bump jython-standalone to 2.7.1
+
+[FLINK-11289 ] - Rework example module structure to account for licensing
+
+[FLINK-11304 ] - Typo in time attributes doc
+
+[FLINK-11331 ] - Fix errors in tableApi.md and functions.md
+
+[FLINK-11469 ] - fix Tuning Checkpoints and Large State doc
+
+[FLINK-11473 ] - Clarify Documenation on Latency Tracking
+
+[FLINK-11628 ] - Cache maven on travis
+
+
diff --git a/docs/content.tr/posts/2019-02-21-monitoring-best-practices.md b/docs/content.tr/posts/2019-02-21-monitoring-best-practices.md
new file mode 100644
index 0000000000..85d518cbfb
--- /dev/null
+++ b/docs/content.tr/posts/2019-02-21-monitoring-best-practices.md
@@ -0,0 +1,439 @@
+---
+authors:
+- konstantin: null
+ name: Konstantin Knauf
+ twitter: snntrable
+date: "2019-02-21T12:00:00Z"
+excerpt: The monitoring of business-critical applications is a crucial aspect of a
+ production deployment. It ensures that any degradation or downtime is immediately
+ identified and can be resolved as quickly as possible. In this post, we discuss
+ the most important metrics that indicate healthy Flink applications.
+title: Monitoring Apache Flink Applications 101
+aliases:
+- /news/2019/02/25/monitoring-best-practices.html
+---
+
+
+
+
+This blog post provides an introduction to Apache Flink’s built-in monitoring
+and metrics system, that allows developers to effectively monitor their Flink
+jobs. Oftentimes, the task of picking the relevant metrics to monitor a
+Flink application can be overwhelming for a DevOps team that is just starting
+with stream processing and Apache Flink. Having worked with many organizations
+that deploy Flink at scale, I would like to share my experience and some best
+practice with the community.
+
+With business-critical applications running on Apache Flink, performance monitoring
+becomes an increasingly important part of a successful production deployment. It
+ensures that any degradation or downtime is immediately identified and resolved
+as quickly as possible.
+
+Monitoring goes hand-in-hand with observability, which is a prerequisite for
+troubleshooting and performance tuning. Nowadays, with the complexity of modern
+enterprise applications and the speed of delivery increasing, an engineering
+team must understand and have a complete overview of its applications’ status at
+any given point in time.
+
+## Flink’s Metrics System
+
+The foundation for monitoring Flink jobs is its [metrics
+system](<{{< param DocsBaseUrl >}}flink-docs-release-1.7/monitoring/metrics.html>)
+which consists of two components; `Metrics` and `MetricsReporters`.
+
+### Metrics
+
+Flink comes with a comprehensive set of built-in metrics such as:
+
+* Used JVM Heap / NonHeap / Direct Memory (per Task-/JobManager)
+* Number of Job Restarts (per Job)
+* Number of Records Per Second (per Operator)
+* ...
+
+These metrics have different scopes and measure more general (e.g. JVM or
+operating system) as well as Flink-specific aspects.
+
+As a user, you can and should add application-specific metrics to your
+functions. Typically these include counters for the number of invalid records or
+the number of records temporarily buffered in managed state. Besides counters,
+Flink offers additional metrics types like gauges and histograms. For
+instructions on how to register your own metrics with Flink’s metrics system
+please check out [Flink’s
+documentation](<{{< param DocsBaseUrl >}}flink-docs-release-1.7/monitoring/metrics.html#registering-metrics>).
+In this blog post, we will focus on how to get the most out of Flink’s built-in
+metrics.
+
+### MetricsReporters
+
+All metrics can be queried via Flink’s REST API. However, users can configure
+MetricsReporters to send the metrics to external systems. Apache Flink provides
+reporters to the most common monitoring tools out-of-the-box including JMX,
+Prometheus, Datadog, Graphite and InfluxDB. For information about how to
+configure a reporter check out Flink’s [MetricsReporter
+documentation](<{{< param DocsBaseUrl >}}flink-docs-release-1.7/monitoring/metrics.html#reporter>).
+
+In the remaining part of this blog post, we will go over some of the most
+important metrics to monitor your Apache Flink application.
+
+## Monitoring General Health
+
+The first thing you want to monitor is whether your job is actually in a *RUNNING*
+state. In addition, it pays off to monitor the number of restarts and the time
+since the last restart.
+
+Generally speaking, successful checkpointing is a strong indicator of the
+general health of your application. For each checkpoint, checkpoint barriers
+need to flow through the whole topology of your Flink job and events and
+barriers cannot overtake each other. Therefore, a successful checkpoint shows
+that no channel is fully congested.
+
+**Key Metrics**
+
+Metric | Scope | Description |
+------ | ----- | ----------- |
+`uptime` | job | The time that the job has been running without interruption. |
+`fullRestarts` | job | The total number of full restarts since this job was submitted. |
+`numberOfCompletedCheckpoints` | job | The number of successfully completed checkpoints. |
+`numberOfFailedCheckpoints` | job | The number of failed checkpoints. |
+
+
+
+**Example Dashboard Panels**
+
+
+
+
+Uptime (35 minutes), Restarting Time (3 milliseconds) and Number of Full Restarts (7)
+
+
+
+
+
+
+Completed Checkpoints (18336), Failed (14)
+
+
+
+**Possible Alerts**
+
+* `ΔfullRestarts` > `threshold`
+* `ΔnumberOfFailedCheckpoints` > `threshold`
+
+
+## Monitoring Progress & Throughput
+
+Knowing that your application is RUNNING and checkpointing is working fine is good,
+but it does not tell you whether the application is actually making progress and
+keeping up with the upstream systems.
+
+### Throughput
+
+Flink provides multiple metrics to measure the throughput of our application.
+For each operator or task (remember: a task can contain multiple [chained
+tasks](<{{< param DocsBaseUrl >}}flink-docs-release-1.7/dev/stream/operators/#task-chaining-and-resource-groups>)
+Flink counts the number of records and bytes going in and out. Out of those
+metrics, the rate of outgoing records per operator is often the most intuitive
+and easiest to reason about.
+
+**Key Metrics**
+
+Metric | Scope | Description |
+------ | ----- | ----------- |
+`numRecordsOutPerSecond` | task | The number of records this operator/task sends per second. |
+`numRecordsOutPerSecond` | operator | The number of records this operator sends per second. |
+
+
+
+**Example Dashboard Panels**
+
+
+
+
+Mean Records Out per Second per Operator
+
+
+
+**Possible Alerts**
+
+* `recordsOutPerSecond` = `0` (for a non-Sink operator)
+
+_Note_: Source operators always have zero incoming records. Sink operators
+always have zero outgoing records because the metrics only count
+Flink-internal communication. There is a [JIRA
+ticket]() to change this
+behavior.
+
+### Progress
+
+For applications, that use event time semantics, it is important that watermarks
+progress over time. A watermark of time _t_ tells the framework, that it
+should not anymore expect to receive events with a timestamp earlier than _t_,
+and in turn, to trigger all operations that were scheduled for a timestamp < _t_.
+For example, an event time window that ends at _t_ = 30 will be closed and
+evaluated once the watermark passes 30.
+
+As a consequence, you should monitor the watermark at event time-sensitive
+operators in your application, such as process functions and windows. If the
+difference between the current processing time and the watermark, known as
+even-time skew, is unusually high, then it typically implies one of two issues.
+First, it could mean that your are simply processing old events, for example
+during catch-up after a downtime or when your job is simply not able to keep up
+and events are queuing up. Second, it could mean a single upstream sub-task has
+not sent a watermark for a long time (for example because it did not receive any
+events to base the watermark on), which also prevents the watermark in
+downstream operators to progress. This [JIRA
+ticket]() provides further
+information and a work around for the latter.
+
+**Key Metrics**
+
+Metric | Scope | Description |
+------ | ----- | ----------- |
+`currentOutputWatermark` | operator | The last watermark this operator has emitted. |
+
+
+
+**Example Dashboard Panels**
+
+
+
+
+Event Time Lag per Subtask of a single operator in the topology. In this case, the watermark is lagging a few seconds behind for each subtask.
+
+
+
+**Possible Alerts**
+
+* `currentProcessingTime - currentOutputWatermark` > `threshold`
+
+### "Keeping Up"
+
+When consuming from a message queue, there is often a direct way to monitor if
+your application is keeping up. By using connector-specific metrics you can
+monitor how far behind the head of the message queue your current consumer group
+is. Flink forwards the underlying metrics from most sources.
+
+**Key Metrics**
+
+Metric | Scope | Description |
+------ | ----- | ----------- |
+`records-lag-max` | user | applies to `FlinkKafkaConsumer`. The maximum lag in terms of the number of records for any partition in this window. An increasing value over time is your best indication that the consumer group is not keeping up with the producers. |
+`millisBehindLatest` | user | applies to `FlinkKinesisConsumer`. The number of milliseconds a consumer is behind the head of the stream. For any consumer and Kinesis shard, this indicates how far it is behind the current time. |
+
+
+
+**Possible Alerts**
+
+* `records-lag-max` > `threshold`
+* `millisBehindLatest` > `threshold`
+
+## Monitoring Latency
+
+Generally speaking, latency is the delay between the creation of an event and
+the time at which results based on this event become visible. Once the event is
+created it is usually stored in a persistent message queue, before it is
+processed by Apache Flink, which then writes the results to a database or calls
+a downstream system. In such a pipeline, latency can be introduced at each stage
+and for various reasons including the following:
+
+1. It might take a varying amount of time until events are persisted in the
+message queue.
+2. During periods of high load or during recovery, events might spend some time
+in the message queue until they are processed by Flink (see previous section).
+3. Some operators in a streaming topology need to buffer events for some time
+(e.g. in a time window) for functional reasons.
+4. Each computation in your Flink topology (framework or user code), as well as
+each network shuffle, takes time and adds to latency.
+5. If the application emits through a transactional sink, the sink will only
+commit and publish transactions upon successful checkpoints of Flink, adding
+latency usually up to the checkpointing interval for each record.
+
+In practice, it has proven invaluable to add timestamps to your events at
+multiple stages (at least at creation, persistence, ingestion by Flink,
+publication by Flink, possibly sampling those to save bandwidth). The
+differences between these timestamps can be exposed as a user-defined metric in
+your Flink topology to derive the latency distribution of each stage.
+
+In the rest of this section, we will only consider latency, which is introduced
+inside the Flink topology and cannot be attributed to transactional sinks or
+events being buffered for functional reasons (4.).
+
+To this end, Flink comes with a feature called [Latency
+Tracking](<{{< param DocsBaseUrl >}}flink-docs-release-1.7/monitoring/metrics.html#latency-tracking>).
+When enabled, Flink will insert so-called latency markers periodically at all
+sources. For each sub-task, a latency distribution from each source to this
+operator will be reported. The granularity of these histograms can be further
+controlled by setting _metrics.latency.granularity_ as desired.
+
+Due to the potentially high number of histograms (in particular for
+_metrics.latency.granularity: subtask_), enabling latency tracking can
+significantly impact the performance of the cluster. It is recommended to only
+enable it to locate sources of latency during debugging.
+
+**Metrics**
+
+Metric | Scope | Description |
+------ | ----- | ----------- |
+`latency` | operator | The latency from the source operator to this operator. |
+`restartingTime` | job | The time it took to restart the job, or how long the current restart has been in progress. |
+
+
+
+**Example Dashboard Panel**
+
+
+
+
+Latency distribution between a source and a single sink subtask.
+
+
+
+## JVM Metrics
+
+So far we have only looked at Flink-specific metrics. As long as latency &
+throughput of your application are in line with your expectations and it is
+checkpointing consistently, this is probably everything you need. On the other
+hand, if you job’s performance is starting to degrade among the firstmetrics you
+want to look at are memory consumption and CPU load of your Task- & JobManager
+JVMs.
+
+### Memory
+
+Flink reports the usage of Heap, NonHeap, Direct & Mapped memory for JobManagers
+and TaskManagers.
+
+* Heap memory - as with most JVM applications - is the most volatile and important
+metric to watch. This is especially true when using Flink’s filesystem
+statebackend as it keeps all state objects on the JVM Heap. If the size of
+long-living objects on the Heap increases significantly, this can usually be
+attributed to the size of your application state (check the
+[checkpointing metrics](<{{< param DocsBaseUrl >}}flink-docs-release-1.7/monitoring/metrics.html#checkpointing>)
+for an estimated size of the on-heap state). The possible reasons for growing
+state are very application-specific. Typically, an increasing number of keys, a
+large event-time skew between different input streams or simply missing state
+cleanup may cause growing state.
+
+* NonHeap memory is dominated by the metaspace, the size of which is unlimited by default
+and holds class metadata as well as static content. There is a
+[JIRA Ticket]() to limit the size
+to 250 megabyte by default.
+
+* The biggest driver of Direct memory is by far the
+number of Flink’s network buffers, which can be
+[configured](<{{< param DocsBaseUrl >}}flink-docs-release-1.7/ops/config.html#configuring-the-network-buffers>).
+
+* Mapped memory is usually close to zero as Flink does not use memory-mapped files.
+
+In a containerized environment you should additionally monitor the overall
+memory consumption of the Job- and TaskManager containers to ensure they don’t
+exceed their resource limits. This is particularly important, when using the
+RocksDB statebackend, since RocksDB allocates a considerable amount of
+memory off heap. To understand how much memory RocksDB might use, you can
+checkout [this blog
+post]()
+by Stefan Richter.
+
+**Key Metrics**
+
+Metric | Scope | Description |
+------ | ----- | ----------- |
+`Status.JVM.Memory.NonHeap.Committed` | job-/taskmanager | The amount of non-heap memory guaranteed to be available to the JVM (in bytes). |
+`Status.JVM.Memory.Heap.Used` | job-/taskmanager | The amount of heap memory currently used (in bytes). |
+`Status.JVM.Memory.Heap.Committed` | job-/taskmanager | The amount of heap memory guaranteed to be available to the JVM (in bytes). |
+`Status.JVM.Memory.Direct.MemoryUsed` | job-/taskmanager | The amount of memory used by the JVM for the direct buffer pool (in bytes). |
+`Status.JVM.Memory.Mapped.MemoryUsed` | job-/taskmanager | The amount of memory used by the JVM for the mapped buffer pool (in bytes). |
+`Status.JVM.GarbageCollector.G1 Young Generation.Time` | job-/taskmanager | The total time spent performing G1 Young Generation garbage collection. |
+`Status.JVM.GarbageCollector.G1 Old Generation.Time` | job-/taskmanager | The total time spent performing G1 Old Generation garbage collection. |
+
+
+
+**Example Dashboard Panel**
+
+
+
+
+TaskManager memory consumption and garbage collection times.
+
+
+
+
+
+
+JobManager memory consumption and garbage collection times.
+
+
+
+**Possible Alerts**
+
+* `container memory limit` < `container memory + safety margin`
+
+### CPU
+
+Besides memory, you should also monitor the CPU load of the TaskManagers. If
+your TaskManagers are constantly under very high load, you might be able to
+improve the overall performance by decreasing the number of task slots per
+TaskManager (in case of a Standalone setup), by providing more resources to the
+TaskManager (in case of a containerized setup), or by providing more
+TaskManagers. In general, a system already running under very high load during
+normal operations, will need much more time to catch-up after recovering from a
+downtime. During this time you will see a much higher latency (event-time skew) than
+usual.
+
+A sudden increase in the CPU load might also be attributed to high garbage
+collection pressure, which should be visible in the JVM memory metrics as well.
+
+If one or a few TaskManagers are constantly under very high load, this can slow
+down the whole topology due to long checkpoint alignment times and increasing
+event-time skew. A common reason is skew in the partition key of the data, which
+can be mitigated by pre-aggregating before the shuffle or keying on a more
+evenly distributed key.
+
+**Key Metrics**
+
+Metric | Scope | Description |
+------ | ----- | ----------- |
+`Status.JVM.CPU.Load` | job-/taskmanager | The recent CPU usage of the JVM. |
+
+
+
+**Example Dashboard Panel**
+
+
+
+
+TaskManager & JobManager CPU load.
+
+
+
+## System Resources
+
+In addition to the JVM metrics above, it is also possible to use Flink’s metrics
+system to gather insights about system resources, i.e. memory, CPU &
+network-related metrics for the whole machine as opposed to the Flink processes
+alone. System resource monitoring is disabled by default and requires additional
+dependencies on the classpath. Please check out the
+[Flink system resource metrics documentation](<{{< param DocsBaseUrl >}}flink-docs-release-1.7/monitoring/metrics.html#system-resources>) for
+additional guidance and details. System resource monitoring in Flink can be very
+helpful in setups without existing host monitoring capabilities.
+
+## Conclusion
+
+This post tries to shed some light on Flink’s metrics and monitoring system. You
+can utilise it as a starting point when you first think about how to
+successfully monitor your Flink application. I highly recommend to start
+monitoring your Flink application early on in the development phase. This way
+you will be able to improve your dashboards and alerts over time and, more
+importantly, observe the performance impact of the changes to your application
+throughout the development phase. By doing so, you can ask the right questions
+about the runtime behaviour of your application, and learn much more about
+Flink’s internals early on.
+
+Last but not least, this post only scratches the surface of the overall metrics
+and monitoring capabilities of Apache Flink. I highly recommend going over
+[Flink’s metrics documentation](<{{< param DocsBaseUrl >}}flink-docs-release-1.7/monitoring/metrics.html>)
+for a full reference of Flink’s metrics system.
\ No newline at end of file
diff --git a/docs/content.tr/posts/2019-02-25-release-1.6.4.md b/docs/content.tr/posts/2019-02-25-release-1.6.4.md
new file mode 100644
index 0000000000..de48e291d2
--- /dev/null
+++ b/docs/content.tr/posts/2019-02-25-release-1.6.4.md
@@ -0,0 +1,98 @@
+---
+date: "2019-02-25T00:00:00Z"
+title: Apache Flink 1.6.4 Released
+aliases:
+- /news/2019/02/25/release-1.6.4.html
+---
+
+The Apache Flink community released the fourth bugfix version of the Apache Flink 1.6 series.
+
+This release includes more than 25 fixes and minor improvements for Flink 1.6.3. The list below includes a detailed list of all fixes.
+
+We highly recommend all users to upgrade to Flink 1.6.4.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.6.4
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.6.4
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.6.4
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+List of resolved issues:
+
+ Bug
+
+
+[FLINK-10721 ] - Kafka discovery-loop exceptions may be swallowed
+
+[FLINK-10761 ] - MetricGroup#getAllVariables can deadlock
+
+[FLINK-10774 ] - connection leak when partition discovery is disabled and open throws exception
+
+[FLINK-10848 ] - Flink's Yarn ResourceManager can allocate too many excess containers
+
+[FLINK-11022 ] - Update LICENSE and NOTICE files for older releases
+
+[FLINK-11071 ] - Dynamic proxy classes cannot be resolved when deserializing job graph
+
+[FLINK-11084 ] - Incorrect ouput after two consecutive split and select
+
+[FLINK-11119 ] - Incorrect Scala example for Table Function
+
+[FLINK-11134 ] - Invalid REST API request should not log the full exception in Flink logs
+
+[FLINK-11151 ] - FileUploadHandler stops working if the upload directory is removed
+
+[FLINK-11173 ] - Proctime attribute validation throws an incorrect exception message
+
+[FLINK-11224 ] - Log is missing in scala-shell
+
+[FLINK-11232 ] - Empty Start Time of sub-task on web dashboard
+
+[FLINK-11234 ] - ExternalTableCatalogBuilder unable to build a batch-only table
+
+[FLINK-11235 ] - Elasticsearch connector leaks threads if no connection could be established
+
+[FLINK-11251 ] - Incompatible metric name on prometheus reporter
+
+[FLINK-11389 ] - Incorrectly use job information when call getSerializedTaskInformation in class TaskDeploymentDescriptor
+
+[FLINK-11584 ] - ConfigDocsCompletenessITCase fails DescriptionBuilder#linebreak() is used
+
+[FLINK-11585 ] - Prefix matching in ConfigDocsGenerator can result in wrong assignments
+
+
+
+ Improvement
+
+
+[FLINK-10910 ] - Harden Kubernetes e2e test
+
+[FLINK-11079 ] - Skip deployment for flnk-storm-examples
+
+[FLINK-11207 ] - Update Apache commons-compress from 1.4.1 to 1.18
+
+[FLINK-11262 ] - Bump jython-standalone to 2.7.1
+
+[FLINK-11289 ] - Rework example module structure to account for licensing
+
+[FLINK-11304 ] - Typo in time attributes doc
+
+[FLINK-11469 ] - fix Tuning Checkpoints and Large State doc
+
+
diff --git a/docs/content.tr/posts/2019-03-06-ffsf-preview.md b/docs/content.tr/posts/2019-03-06-ffsf-preview.md
new file mode 100644
index 0000000000..b60a03bd94
--- /dev/null
+++ b/docs/content.tr/posts/2019-03-06-ffsf-preview.md
@@ -0,0 +1,42 @@
+---
+authors:
+- fabian: null
+ name: Fabian Hueske
+ twitter: fhueske
+date: "2019-03-06T11:00:00Z"
+excerpt: The third annual Flink Forward conference in San Francisco is just a few
+ weeks away. Let's see what Flink Forward SF 2019 has in store for the Apache Flink
+ and stream processing communities. This post covers some of its highlights!
+title: What to expect from Flink Forward San Francisco 2019
+aliases:
+- /news/2019/03/06/ffsf-preview.html
+---
+
+The third annual Flink Forward San Francisco is just a few weeks away! As always, Flink Forward will be the right place to meet and mingle with experienced Flink users, contributors, and committers. Attendees will hear and chat about the latest developments around Flink and learn from technical deep-dive sessions and exciting use cases that were put into production with Flink. The event will take place on April 1-2, 2019 at Hotel Nikko in San Francisco. The [program committee](https://sf-2019.flink-forward.org/program-committee) assembled an amazing [lineup of speakers](https://sf-2019.flink-forward.org/speakers) who will cover many different aspects of Apache Flink and stream processing.
+
+Some highlights of the program are:
+
+* [Realtime Store Visit Predictions at Scale](https://sf-2019.flink-forward.org/conference-program#realtime-store-visit-predictions-at-scale): Luca Giovagnoli from *Yelp* will talk about a "multidisciplinary" Flink application that combines geospatial clustering algorithms, Machine Learning models, and cutting-edge stream-processing technology.
+
+* [Real-time Processing with Flink for Machine Learning at Netflix](https://sf-2019.flink-forward.org/conference-program#real-time-processing-with-flink-for-machine-learning-at-netflix): Elliot Chow will discuss the practical aspects of using Apache Flink to power Machine Learning algorithms for video recommendations, search results ranking, and selection of artwork images at *Netflix*.
+
+* [Building production Flink jobs with Airstream at Airbnb](https://sf-2019.flink-forward.org/conference-program#building-production-flink-jobs-with-airstream-at-airbnb): Pala Muthiah and Hao Wang will reveal how *Airbnb* builds real time data pipelines with Airstream, Airbnb's computation framework that is powered by Flink SQL.
+
+* [When Table meets AI: Build Flink AI Ecosystem on Table API](https://sf-2019.flink-forward.org/conference-program#when-table-meets-ai--build-flink-ai-ecosystem-on-table-api): Shaoxuan Wang from *Alibaba* will discuss how they are building a solid AI ecosystem for unified batch/streaming Machine Learning data pipelines on top of Flink's Table API.
+
+* [Adventures in Scaling from Zero to 5 Billion Data Points per Day](https://sf-2019.flink-forward.org/conference-program#adventures-in-scaling-from-zero-to-5-billion-data-points-per-day): Dave Torok will take us through *Comcast's* journey in scaling the company's operationalized Machine Learning framework from the very early days in production to processing more than 5 billion data points per day.
+
+If you're new to Apache Flink or want to deepen your knowledge around the framework, Flink Forward features again a full day of training.
+
+You can choose from 3 training tracks:
+
+* [Introduction to Streaming with Apache Flink](https://sf-2019.flink-forward.org/training-program#introduction-to-streaming-with-apache-flink): A hands-on, in-depth introduction to stream processing and Apache Flink, this course emphasizes those features of Flink that make it easy to build and manage accurate, fault tolerant applications on streams.
+
+* [Analyzing Streaming Data with Flink SQL](https://sf-2019.flink-forward.org/training-program#analyzing-streaming-data-with-flink-sql): In this hands-on training, you will learn what it means to run SQL queries on data streams and how to fully leverage the potential of SQL on Flink. We'll also cover some of the more recent features such as time-versioned joins and the MATCH RECOGNIZE clause.
+
+* [Troubleshooting and Operating Flink at large scale](https://sf-2019.flink-forward.org/training-program#apache-flink-troubleshooting---operations): In this training, we will focus on everything you need to run Apache Flink applications reliably and efficiently in production including topics like capacity planning, monitoring, troubleshooting and tuning Apache Flink.
+
+If you haven't done so yet, check out the [full schedule](http://sf-2019.flink-forward.org/conference-program) and [register](https://sf-2019.flink-forward.org/register) your attendance.
+I'm looking forward to meet you at Flink Forward San Francisco.
+
+*Fabian*
\ No newline at end of file
diff --git a/docs/content.tr/posts/2019-03-11-prometheus-monitoring.md b/docs/content.tr/posts/2019-03-11-prometheus-monitoring.md
new file mode 100644
index 0000000000..53deb3d7b5
--- /dev/null
+++ b/docs/content.tr/posts/2019-03-11-prometheus-monitoring.md
@@ -0,0 +1,130 @@
+---
+authors:
+- max: null
+ name: Maximilian Bode, TNG Technology Consulting
+ twitter: mxpbode
+date: "2019-03-11T12:00:00Z"
+excerpt: This blog post describes how developers can leverage Apache Flink's built-in
+ metrics system together with Prometheus to observe and monitor streaming applications
+ in an effective way.
+title: 'Flink and Prometheus: Cloud-native monitoring of streaming applications'
+aliases:
+- /features/2019/03/11/prometheus-monitoring.html
+---
+
+This blog post describes how developers can leverage Apache Flink's built-in [metrics system]({{< param DocsBaseUrl >}}flink-docs-release-1.7/monitoring/metrics.html) together with [Prometheus](https://prometheus.io/) to observe and monitor streaming applications in an effective way. This is a follow-up post from my [Flink Forward](https://flink-forward.org/) Berlin 2018 talk ([slides](https://www.slideshare.net/MaximilianBode1/monitoring-flink-with-prometheus), [video](https://www.ververica.com/flink-forward-berlin/resources/monitoring-flink-with-prometheus)). We will cover some basic Prometheus concepts and why it is a great fit for monitoring Apache Flink stream processing jobs. There is also an example to showcase how you can utilize Prometheus with Flink to gain insights into your applications and be alerted on potential degradations of your Flink jobs.
+
+## Why Prometheus?
+
+Prometheus is a metrics-based monitoring system that was originally created in 2012. The system is completely open-source (under the Apache License 2) with a vibrant community behind it and it has graduated from the Cloud Native Foundation last year – a sign of maturity, stability and production-readiness. As we mentioned, the system is based on metrics and it is designed to measure the overall health, behavior and performance of a service. Prometheus features a multi-dimensional data model as well as a flexible query language. It is designed for reliability and can easily be deployed in traditional or containerized environments. Some of the important Prometheus concepts are:
+
+* **Metrics:** Prometheus defines metrics as floats of information that change in time. These time series have millisecond precision.
+
+* **Labels** are the key-value pairs associated with time series that support Prometheus' flexible and powerful data model – in contrast to hierarchical data structures that one might experience with traditional metrics systems.
+
+* **Scrape:** Prometheus is a pull-based system and fetches ("scrapes") metrics data from specified sources that expose HTTP endpoints with a text-based format.
+
+* **PromQL** is Prometheus' [query language](https://prometheus.io/docs/prometheus/latest/querying/basics/). It can be used for both building dashboards and setting up alert rules that will trigger when specific conditions are met.
+
+When considering metrics and monitoring systems for your Flink jobs, there are many [options]({{< param DocsBaseUrl >}}flink-docs-release-1.7/monitoring/metrics.html). Flink offers native support for exposing data to Prometheus via the `PrometheusReporter` configuration. Setting up this integration is very easy.
+
+Prometheus is a great choice as usually Flink jobs are not running in isolation but in a greater context of microservices. For making metrics available to Prometheus from other parts of a larger system, there are two options: There exist [libraries for all major languages](https://prometheus.io/docs/instrumenting/clientlibs/) to instrument other applications. Additionally, there is a wide variety of [exporters](https://prometheus.io/docs/instrumenting/exporters/), which are tools that expose metrics of third-party systems (like databases or Apache Kafka) as Prometheus metrics.
+
+## Prometheus and Flink in Action
+
+We have provided a [GitHub repository](https://github.com/mbode/flink-prometheus-example) that demonstrates the integration described above. To have a look, clone the repository, make sure [Docker](https://docs.docker.com/install/) is installed and run:
+
+```
+./gradlew composeUp
+```
+
+This builds a Flink job using the build tool [Gradle](https://gradle.org/) and starts up a local environment based on [Docker Compose](https://docs.docker.com/compose/) running the job in a [Flink job cluster]({{< param DocsBaseUrl >}}flink-docs-release-1.7/ops/deployment/docker.html#flink-job-cluster) (reachable at [http://localhost:8081](http://localhost:8081/)) as well as a Prometheus instance ([http://localhost:9090](http://localhost:9090/)).
+
+
+
+
+Job graph and custom metric for example job in Flink web interface.
+
+
+
+The `PrometheusExampleJob` has three operators: Random numbers up to 10,000 are generated, then a map counts the events and creates a histogram of the values passed through. Finally, the events are discarded without further output. The very simple code below is from the second operator. It illustrates how easy it is to add custom metrics relevant to your business logic into your Flink job.
+
+```java
+class FlinkMetricsExposingMapFunction extends RichMapFunction {
+ private transient Counter eventCounter;
+
+ @Override
+ public void open(Configuration parameters) {
+ eventCounter = getRuntimeContext().getMetricGroup().counter("events");
+ }
+
+ @Override
+ public Integer map(Integer value) {
+ eventCounter.inc();
+ return value;
+ }
+}
+```
+Excerpt from FlinkMetricsExposingMapFunction.java demonstrating custom Flink metric.
+
+## Configuring Prometheus with Flink
+
+To start monitoring Flink with Prometheus, the following steps are necessary:
+
+1. Make the `PrometheusReporter` jar available to the classpath of the Flink cluster (it comes with the Flink distribution):
+
+ cp /opt/flink/opt/flink-metrics-prometheus-1.7.2.jar /opt/flink/lib
+
+2. [Configure the reporter]({{< param DocsBaseUrl >}}flink-docs-release-1.7/monitoring/metrics.html#reporter) in Flink's _flink-conf.yaml_. All job managers and task managers will expose the metrics on the configured port.
+
+ metrics.reporters: prom
+ metrics.reporter.prom.class: org.apache.flink.metrics.prometheus.PrometheusReporter
+ metrics.reporter.prom.port: 9999
+
+3. Prometheus needs to know where to scrape metrics. In a static scenario, you can simply [configure Prometheus](https://prometheus.io/docs/prometheus/latest/configuration/configuration/) in _prometheus.yml_ with the following:
+
+ scrape_configs:
+ - job_name: 'flink'
+ static_configs:
+ - targets: ['job-cluster:9999', 'taskmanager1:9999', 'taskmanager2:9999']
+
+ In more dynamic scenarios we recommend using Prometheus' service discovery support for different platforms such as Kubernetes, AWS EC2 and more.
+
+Both custom metrics are now available in Prometheus:
+
+
+
+
+Example metric in Prometheus web UI.
+
+
+
+More technical metrics from the Flink cluster (like checkpoint sizes or duration, Kafka offsets or resource consumption) are also available. If you are interested, you can check out the HTTP endpoints exposing all Prometheus metrics for the job managers and the two task managers on [http://localhost:9249](http://localhost:9249/metrics), [http://localhost:9250](http://localhost:9250/metrics) and [http://localhost:9251](http://localhost:9251/metrics), respectively.
+
+To test Prometheus' alerting feature, kill one of the Flink task managers via
+
+```
+docker kill taskmanager1
+```
+
+Our Flink job can recover from this partial failure via the mechanism of [Checkpointing]({{< param DocsBaseUrl >}}flink-docs-release-1.7/dev/stream/state/checkpointing.html). Nevertheless, after roughly one minute (as configured in the alert rule) the following alert will fire:
+
+
+
+
+Example alert in Prometheus web UI.
+
+
+
+In real-world situations alerts like this one can be routed through a component called [Alertmanager](https://prometheus.io/docs/alerting/alertmanager/) and be grouped into notifications to systems like email, PagerDuty or Slack.
+
+Go ahead and play around with the setup, and check out the [Grafana](https://grafana.com/grafana) instance reachable at [http://localhost:3000](http://localhost:3000/) (credentials _admin:flink_) for visualizing Prometheus metrics. If there are any questions or problems, feel free to [create an issue](https://github.com/mbode/flink-prometheus-example/issues). Once finished, do not forget to tear down the setup via
+
+```
+./gradlew composeDown
+```
+
+
+## Conclusion
+
+Using Prometheus together with Flink provides an easy way for effective monitoring and alerting of your Flink jobs. Both projects have exciting and vibrant communities behind them with new developments and additions scheduled for upcoming releases. We encourage you to try the two technologies together as it has immensely improved our insights into Flink jobs running in production.
diff --git a/docs/content.tr/posts/2019-04-09-release-1.8.0.md b/docs/content.tr/posts/2019-04-09-release-1.8.0.md
new file mode 100644
index 0000000000..b8d5c717f4
--- /dev/null
+++ b/docs/content.tr/posts/2019-04-09-release-1.8.0.md
@@ -0,0 +1,251 @@
+---
+authors:
+- name: Aljoscha Krettek
+ till: null
+ twitter: aljoscha
+date: "2019-04-09T12:00:00Z"
+title: Apache Flink 1.8.0 Release Announcement
+aliases:
+- /news/2019/04/09/release-1.8.0.html
+---
+
+The Apache Flink community is pleased to announce Apache Flink 1.8.0. The
+latest release includes more than 420 resolved issues and some exciting
+additions to Flink that we describe in the following sections of this post.
+Please check the [complete changelog](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12344274)
+for more details.
+
+Flink 1.8.0 is API-compatible with previous 1.x.y releases for APIs annotated
+with the `@Public` annotation. The release is available now and we encourage
+everyone to [download the release](/downloads.html) and
+check out the updated
+[documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.8/).
+Feedback through the Flink [mailing
+lists](/community.html#mailing-lists) or
+[JIRA](https://issues.apache.org/jira/projects/FLINK/summary) is, as always,
+very much appreciated!
+
+You can find the binaries on the updated [Downloads page](/downloads.html) on the Flink project site.
+
+With Flink 1.8.0 we come closer to our goals of enabling fast data processing
+and building data-intensive applications for the Flink community in a seamless
+way. We do this by cleaning up and refactoring Flink under the hood to allow
+more efficient feature development in the future. This includes removal of the
+legacy runtime components that were subsumed in the major rework of Flink's
+underlying distributed system architecture
+([FLIP-6](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65147077))
+as well as refactorings on the Table API that prepare it for the future
+addition of the Blink enhancements
+([FLINK-11439](https://issues.apache.org/jira/browse/FLINK-11439)).
+
+Nevertheless, this release includes some important new features and bug fixes.
+The most interesting of those are highlighted below. Please consult the
+[complete changelog](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12344274)
+and the [release notes]({{< param DocsBaseUrl >}}flink-docs-release-1.8/release-notes/flink-1.8.html)
+for more details.
+
+
+## New Features and Improvements
+
+* **Finalized State Schema Evolution Story**: This release completes
+ the community driven effort to provide a schema evolution story for
+ user state managed by Flink. This has been an effort that spanned 2
+ releases, starting from 1.7.0 with the introduction of support for
+ Avro state schema evolution as well as a revamped serialization
+ compatibility abstraction.
+
+ Flink 1.8.0 finalizes this effort by extending support for schema
+ evolution to POJOs, upgrading all Flink built-in serializers to use
+ the new serialization compatibility abstractions, as well as making it
+ easier for advanced users who use custom state serializers to
+ implement the abstractions. These different aspects for a complete
+ out-of-the-box schema evolution story are explained in detail below:
+
+ 1. Support for POJO state schema evolution: The pool of data types
+ that support state schema evolution has been expanded to include
+ POJOs. For state types that use POJOs, you can now add or remove
+ fields from your POJO while retaining backwards
+ compatibility. For a full overview of the list of data types that
+ now support schema evolution as well as their evolution
+ specifications and limitations, please refer to the State Schema
+ Evolution documentation page.
+
+
+ 2. Upgrade all Flink serializers to use new serialization
+ compatibility asbtractions: Back in 1.7.0, we introduced the new
+ serialization compatibility abstractions `TypeSerializerSnapshot`
+ and `TypeSerializerSchemaCompatibility`. Besides providing a more
+ expressible API to reflect schema compatibility between the data
+ stored in savepoints and the data registered at runtime, another
+ important aspect about the new abstraction is that it avoids the
+ need for Flink to Java-serialize the state serializer as state
+ metadata in savepoints.
+
+ In 1.8.0, all of Flink's built-in serializers have been upgraded to
+ use the new abstractions, and therefore the serializers
+ themselves are no longer Java-serialized into savepoints. This
+ greatly improves interoperability of Flink savepoints, in terms
+ of state schema evolvability. For example, one outcome was the
+ support for POJO schema evolution, as previously mentioned
+ above. Another outcome is that all composite data types supported
+ by Flink (such as `Either`, Scala case classes, Flink Java
+ `Tuple`s, etc.) are generally evolve-able as well when they have
+ a nested evolvable type, such as a POJO. For example, the `MyPojo`
+ type in `ValueState>` or
+ `ListState>`, which is a POJO, is allowed
+ to evolve its schema.
+
+ For users who are using custom `TypeSerializer` implementations
+ for their state serializer and are still using the outdated
+ abstractions (i.e. `TypeSerializerConfigSnapshot` and
+ `CompatiblityResult`), we highly recommend upgrading to the new
+ abstractions to be future proof. Please refer to the Custom State
+ Serialization documentation page for a detailed description on
+ the new abstractions.
+
+ 3. Provide pre-defined snapshot implementations for common
+ serializers: For convenience, Flink 1.8.0 comes with two
+ predefined implementations for the `TypeSerializerSnapshot` that
+ make the task of implementing these new abstractions easier
+ for most implementations of `TypeSerializer`s -
+ `SimpleTypeSerializerSnapshot` and
+ `CompositeTypeSerializerSnapshot`. This section in the
+ documentation provides information on how to use these classes.
+
+* **Continuous cleanup of old state based on TTL
+ ([FLINK-7811](https://issues.apache.org/jira/browse/FLINK-7811))**: We
+ introduced TTL (time-to-live) for Keyed state in Flink 1.6
+ ([FLINK-9510](https://issues.apache.org/jira/browse/FLINK-9510)). This
+ feature enabled cleanup and made keyed state entries inaccessible after a
+ defined timeout. In addition state would now also be cleaned up when
+ writing a savepoint/checkpoint.
+
+ Flink 1.8 introduces continuous cleanup of old entries for both the RocksDB
+ state backend
+ ([FLINK-10471](https://issues.apache.org/jira/browse/FLINK-10471)) and the heap
+ state backend
+ ([FLINK-10473](https://issues.apache.org/jira/browse/FLINK-10473)). This means
+ that old entries (according to the TTL setting) are continuously cleaned up.
+
+* **SQL pattern detection with user-defined functions and
+ aggregations**: The support of the MATCH_RECOGNIZE clause has been
+ extended by multiple features. The addition of user-defined
+ functions allows for custom logic during pattern detection
+ ([FLINK-10597](https://issues.apache.org/jira/browse/FLINK-10597)),
+ while adding aggregations allows for more complex CEP definitions,
+ such as the following
+ ([FLINK-7599](https://issues.apache.org/jira/browse/FLINK-7599)).
+
+ ```
+ SELECT *
+ FROM Ticker
+ MATCH_RECOGNIZE (
+ ORDER BY rowtime
+ MEASURES
+ AVG(A.price) AS avgPrice
+ ONE ROW PER MATCH
+ AFTER MATCH SKIP TO FIRST B
+ PATTERN (A+ B)
+ DEFINE
+ A AS AVG(A.price) < 15
+ ) MR;
+ ```
+
+* **RFC-compliant CSV format ([FLINK-9964](https://issues.apache.org/jira/browse/FLINK-9964))**: The SQL tables can now be read and written in
+ an RFC-4180 standard compliant CSV table format. The format might also be
+ useful for general DataStream API users.
+
+* **New KafkaDeserializationSchema that gives direct access to ConsumerRecord
+ ([FLINK-8354](https://issues.apache.org/jira/browse/FLINK-8354))**: For the
+ Flink `KafkaConsumers`, we introduced a new `KafkaDeserializationSchema` that
+ gives direct access to the Kafka `ConsumerRecord`. This now allows access to
+ all data that Kafka provides for a record, including the headers. This
+ subsumes the `KeyedSerializationSchema` functionality, which is deprecated but
+ still available for now.
+
+* **Per-shard watermarking option in FlinkKinesisConsumer
+ ([FLINK-5697](https://issues.apache.org/jira/browse/FLINK-5697))**: The Kinesis
+ Consumer can now emit periodic watermarks that are derived from per-shard watermarks,
+ for correct event time processing with subtasks that consume multiple Kinesis shards.
+
+* **New consumer for DynamoDB Streams to capture table changes
+ ([FLINK-4582](https://issues.apache.org/jira/browse/FLINK-4582))**: `FlinkDynamoDBStreamsConsumer`
+ is a variant of the Kinesis consumer that supports retrieval of CDC-like streams from DynamoDB tables.
+
+* **Support for global aggregates for subtask coordination
+ ([FLINK-10887](https://issues.apache.org/jira/browse/FLINK-10887))**:
+ Designed as a solution for global source watermark tracking, `GlobalAggregateManager`
+ allows sharing of information between parallel subtasks. This feature will
+ be integrated into streaming connectors for watermark synchronization and
+ can be used for other purposes with a user defined aggregator.
+
+## Important Changes
+
+* **Changes to bundling of Hadoop libraries with Flink
+ ([FLINK-11266](https://issues.apache.org/jira/browse/FLINK-11266))**:
+ Convenience binaries that include hadoop are no longer released.
+
+ If a deployment relies on `flink-shaded-hadoop2` being included in
+ `flink-dist`, then you must manually download a pre-packaged Hadoop
+ jar from the optional components section of the [download
+ page](/downloads.html) and copy it into the
+ `/lib` directory. Alternatively, a Flink distribution that includes
+ hadoop can be built by packaging `flink-dist` and activating the
+ `include-hadoop` maven profile.
+
+ As hadoop is no longer included in `flink-dist` by default, specifying
+ `-DwithoutHadoop` when packaging `flink-dist` no longer impacts the build.
+
+* **FlinkKafkaConsumer will now filter restored partitions based on topic
+ specification
+ ([FLINK-10342](https://issues.apache.org/jira/browse/FLINK-10342))**:
+ Starting from Flink 1.8.0, the `FlinkKafkaConsumer` now always filters out
+ restored partitions that are no longer associated with a specified topic to
+ subscribe to in the restored execution. This behaviour did not exist in
+ previous versions of the `FlinkKafkaConsumer`. If you wish to retain the
+ previous behaviour, please use the
+ `disableFilterRestoredPartitionsWithSubscribedTopics()` configuration method
+ on the `FlinkKafkaConsumer`.
+
+ Consider this example: if you had a Kafka Consumer that was consuming from
+ topic `A`, you did a savepoint, then changed your Kafka consumer to instead
+ consume from topic `B`, and then restarted your job from the savepoint.
+ Before this change, your consumer would now consume from both topic `A` and
+ `B` because it was stored in state that the consumer was consuming from topic
+ `A`. With the change, your consumer would only consume from topic `B` after
+ restore because it now filters the topics that are stored in state using the
+ configured topics.
+
+ * **Change in the Maven modules of Table API
+ ([FLINK-11064](https://issues.apache.org/jira/browse/FLINK-11064))**: Users
+ that had a `flink-table` dependency before, need to update their
+ dependencies to `flink-table-planner` and the correct dependency of
+ `flink-table-api-*`, depending on whether Java or Scala is used: one of
+ `flink-table-api-java-bridge` or `flink-table-api-scala-bridge`.
+
+## Known Issues
+
+* **Discarded checkpoint can cause Tasks to fail
+ ([FLINK-11662](https://issues.apache.org/jira/browse/FLINK-11662))**: There is
+ a race condition that can lead to erroneous checkpoint failures. This mostly
+ occurs when restarting from a savepoint or checkpoint takes a long time at the
+ sources of a job. If you see random checkpointing failures that don't seem to
+ have a good explanation you might be affected. Please see the Jira issue for
+ more details and a workaround for the problem.
+
+
+## Release Notes
+
+Please review the [release
+notes]({{< param DocsBaseUrl >}}flink-docs-release-1.8/release-notes/flink-1.8.html)
+for a more detailed list of changes and new features if you plan to upgrade
+your Flink setup to Flink 1.8.
+
+## List of Contributors
+
+We would like to acknowledge all community members for contributing to this
+release. Special credits go to the following members for contributing to the
+1.8.0 release (according to `git log --pretty="%an" release-1.7.0..release-1.8.0 | sort | uniq` without manual deduplication):
+
+Addison Higham, Aitozi, Aleksey Pak, Alexander Fedulov, Alexey Trenikhin, Aljoscha Krettek, Andrey Zagrebin, Artsem Semianenka, Asura7969, Avi, Barisa Obradovic, Benchao Li, Bo WANG, Chesnay Schepler, Congxian Qiu, Cristian, David Anderson, Dawid Wysakowicz, Dian Fu, DuBin, EAlexRojas, EronWright, Eugen Yushin, Fabian Hueske, Fokko Driesprong, Gary Yao, Hequn Cheng, Igal Shilman, Jamie Grier, JaryZhen, Jeff Zhang, Jihyun Cho, Jinhu Wu, Joerg Schad, KarmaGYZ, Kezhu Wang, Konstantin Knauf, Kostas Kloudas, Lakshmi, Lakshmi Gururaja Rao, Lavkesh Lahngir, Li, Shuangjiang, Mai Nakagawa, Matrix42, Matt, Maximilian Michels, Mododo, Nico Kruber, Paul Lin, Piotr Nowojski, Qi Yu, Qin, Robert, Robert Metzger, Romano Vacca, Rong Rong, Rune Skou Larsen, Seth Wiesman, Shannon Carey, Shimin Yang, Shuyi Chen, Stefan Richter, Stephan Ewen, SuXingLee, TANG Wen-hui, Tao Yang, Thomas Weise, Till Rohrmann, Timo Walther, Tom Goong, Tony Feng, Tony Wei, Tzu-Li (Gordon) Tai, Tzu-Li Chen, Ufuk Celebi, Xingcan Cui, Xpray, XuQianJin-Stars, Xue Yu, Yangze Guo, Ying Xu, Yiqun Lin, Yu Li, Yuanyang Wu, Yun Tang, ZILI CHEN, Zhanchun Zhang, Zhijiang, ZiLi Chen, acqua.csq, alex04.wang, ap, azagrebin, blueszheng, boshu Zheng, chengjie.wu, chensq, chummyhe89, eaglewatcherwb, hequn8128, ifndef-SleePy, intsmaze, jackyyin, jinhu.wjh, jparkie, jrthe42, junsheng.wu, kgorman, kkloudas, kkolman, klion26, lamber-ken, leesf, libenchao, lining, liuzhaokun, lzh3636, maqingxiang, mb-datadome, okidogi, park.yq, sunhaibotb, sunjincheng121, tison, unknown, vinoyang, wenhuitang, wind, xueyu, xuqianjin, yanghua, zentol, zhangzhanchun, zhijiang, zhuzhu.zz, zy, 仲炜, 砚田, 谢磊
+
diff --git a/docs/content.tr/posts/2019-04-17-sod.md b/docs/content.tr/posts/2019-04-17-sod.md
new file mode 100644
index 0000000000..c24b97d0ee
--- /dev/null
+++ b/docs/content.tr/posts/2019-04-17-sod.md
@@ -0,0 +1,58 @@
+---
+authors:
+- konstantin: null
+ name: Konstantin Knauf
+ twitter: snntrable
+date: "2019-04-17T12:00:00Z"
+title: Apache Flink's Application to Season of Docs
+aliases:
+- /news/2019/04/17/sod.html
+---
+
+The Apache Flink community is happy to announce its application to the first edition of [Season of Docs](https://developers.google.com/season-of-docs/) by Google. The program is bringing together Open Source projects and technical writers to raise awareness for and improve documentation of Open Source projects. While the community is continuously looking for new contributors to collaborate on our documentation, we would like to take this chance to work with one or two technical writers to extend and restructure parts of [our documentation]({{< param DocsBaseUrl >}}flink-docs-stable/) (details below).
+
+The community has discussed this opportunity on the [dev mailinglist](https://lists.apache.org/thread.html/3c789b6187da23ad158df59bbc598543b652e3cfc1010a14e294e16a@%3Cdev.flink.apache.org%3E) and agreed on three project ideas to submit to the program. We have a great team of mentors (Stephan, Fabian, David, Jark & Konstantin) lined up and are very much looking forward to the first proposals by potential technical writers (given we are admitted to the program ;)). In case of questions feel free to reach out to the community via [dev@flink.apache.org](../../../../community.html#mailing-lists).
+
+## Project Ideas List
+
+### Project 1: Improve Documentation of Stream Processing Concepts
+
+**Description:** Stream processing is the processing of data in motion―in other words, computing on data directly as it is produced or received. Apache Flink has pioneered the field of distributed, stateful stream processing over the last several years. As the community has pushed the boundaries of stream processing, we have introduced new concepts that users need to become familiar with to develop and operate Apache Flink applications efficiently.
+The Apache Flink documentation \[1\] already contains a “concepts” section, but it is a ) incomplete and b) lacks an overall structure & reading flow. In addition, “concepts”-content is also spread over the development \[2\] & operations \[3\] documentation without references to the “concepts” section. An example of this can be found in \[4\] and \[5\].
+
+In this project, we would like to restructure, consolidate and extend the concepts documentation for Apache Flink to better guide users who want to become productive as quickly as possible. This includes better conceptual introductions to topics such as event time, state, and fault tolerance with proper linking to and from relevant deployment and development guides.
+
+**Related material:**
+
+1. [{{< param DocsBaseUrl >}}flink-docs-release-1.8/]({{< param DocsBaseUrl >}}flink-docs-release-1.8/)
+2. [{{< param DocsBaseUrl >}}flink-docs-release-1.8/dev]({{< param DocsBaseUrl >}}flink-docs-release-1.8/dev)
+3. [{{< param DocsBaseUrl >}}flink-docs-release-1.8/ops]({{< param DocsBaseUrl >}}flink-docs-release-1.8/ops)
+4. [{{< param DocsBaseUrl >}}flink-docs-release-1.8/concepts/programming-model.html#time]({{< param DocsBaseUrl >}}flink-docs-release-1.8/concepts/programming-model.html#time)
+5. [{{< param DocsBaseUrl >}}flink-docs-release-1.8/dev/event_time.html]({{< param DocsBaseUrl >}}flink-docs-release-1.8/dev/event_time.html)
+
+### Project 2: Improve Documentation of Flink Deployments & Operations
+
+**Description:** Stream processing is the processing of data in motion―in other words, computing on data directly as it is produced or received. Apache Flink has pioneered the field of distributed, stateful stream processing for the last few years. As a stateful distributed system in general and a continuously running, low-latency system in particular, Apache Flink deployments are non-trivial to setup and manage.
+Unfortunately, the operations \[1\] and monitoring documentation \[2\] are arguably the weakest spots of the Apache Flink documentation. While it is comprehensive and often goes into a lot of detail, it lacks an overall structure and does not address common overarching concerns of operations teams in an efficient way.
+
+In this project, we would like to restructure this part of the documentation and extend it if possible. Ideas for extension include: discussion of session and per-job clusters, better documentation for containerized deployments (incl. K8s), capacity planning & integration into CI/CD pipelines.
+
+**Related material:**
+
+1. [{{< param DocsBaseUrl >}}flink-docs-release-1.8/ops]({{< param DocsBaseUrl >}}flink-docs-release-1.8/ops/)
+2. [{{< param DocsBaseUrl >}}flink-docs-release-1.8/monitoring]({{< param DocsBaseUrl >}}flink-docs-release-1.8/monitoring)
+
+### Project 3: Improve Documentation for Relational APIs (Table API & SQL)
+
+**Description:** Apache Flink features APIs at different levels of abstraction which enables its users to trade conciseness for expressiveness. Flink’s relational APIs, SQL and the Table API, are “younger” than the DataStream and DataSet APIs, more high-level and focus on data analytics use cases. A core principle of Flink’s SQL and Table API is that they can be used to process static (batch) and continuous (streaming) data and that a program or query produces the same result in both cases.
+The documentation of Flink’s relational APIs has organically grown and can be improved in a few areas. There are several on-going development efforts (e.g. Hive Integration, Python Support or Support for Interactive Programming) that aim to extend the scope of the Table API and SQL.
+
+The existing documentation could be reorganized to prepare for covering the new features. Moreover, it could be improved by adding a concepts section that describes the use cases and internals of the APIs in more detail. Moreover, the documentation of built-in functions could be improved by adding more concrete examples.
+
+**Related material:**
+
+1. [Table API & SQL docs main page]({{< param DocsBaseUrl >}}flink-docs-release-1.8/dev/table)
+2. [Built-in functions]({{< param DocsBaseUrl >}}flink-docs-release-1.8/dev/table/functions.html)
+3. [Concepts]({{< param DocsBaseUrl >}}flink-docs-release-1.8/dev/table/common.html)
+4. [Streaming Concepts]({{< param DocsBaseUrl >}}flink-docs-release-1.8/dev/table/streaming/)
+
diff --git a/docs/content.tr/posts/2019-05-03-pulsar-flink.md b/docs/content.tr/posts/2019-05-03-pulsar-flink.md
new file mode 100644
index 0000000000..d6483747e1
--- /dev/null
+++ b/docs/content.tr/posts/2019-05-03-pulsar-flink.md
@@ -0,0 +1,160 @@
+---
+authors:
+- name: Sijie Guo
+ sijie: null
+ twitter: sijieg
+date: "2019-05-03T12:00:00Z"
+excerpt: Apache Flink and Apache Pulsar are distributed data processing systems. When
+ combined, they offer elastic data processing at large scale. This post describes
+ how Pulsar and Flink can work together to provide a seamless developer experience.
+title: When Flink & Pulsar Come Together
+aliases:
+- /2019/05/03/pulsar-flink.html
+---
+
+The open source data technology frameworks [Apache Flink](https://flink.apache.org/) and [Apache Pulsar](https://pulsar.apache.org/en/) can integrate in different ways to provide elastic data processing at large scale. I recently gave a talk at [Flink Forward](https://www.flink-forward.org/) San Francisco 2019 and presented some of the integrations between the two frameworks for batch and streaming applications. In this post, I will give a short introduction to Apache Pulsar and its differentiating elements from other messaging systems and describe the ways that Pulsar and Flink can work together to provide a seamless developer experience for elastic data processing at scale.
+
+## A brief introduction to Apache Pulsar
+
+[Apache Pulsar](https://pulsar.apache.org/en/) is an open-source distributed pub-sub messaging system under the stewardship of the [Apache Software Foundation](https://www.apache.org/). Pulsar is a multi-tenant, high-performance solution for server-to-server messaging including multiple features such as native support for multiple clusters in a Pulsar instance, with seamless [geo-replication](https://pulsar.apache.org/docs/en/administration-geo) of messages across clusters, very low publish and end-to-end latency, seamless scalability to over a million topics, and guaranteed message delivery with [persistent message storage](https://pulsar.apache.org/docs/en/concepts-architecture-overview#persistent-storage) provided by [Apache BookKeeper](https://bookkeeper.apache.org/) among others. Let’s now discuss the primary differentiators between Pulsar and other pub-sub messaging frameworks:
+
+The first differentiating factor stems from the fact that although Pulsar provides a flexible pub-sub messaging system it is also backed by durable log storage — hence combining both messaging and storage under one framework. Because of that layered architecture, Pulsar provides instant failure recovery, independent scalability and balance-free cluster expansion.
+
+Pulsar’s architecture follows a similar pattern to other pub-sub systems as the framework is organized in topics as the main data entity, with producers sending data to, and consumers receiving data from a topic as shown in the diagram below.
+
+
+
+
+
+
+The second differentiator of Pulsar is that the framework is built from the get-go with [multi-tenancy](https://pulsar.apache.org/docs/en/concepts-multi-tenancy/) in mind. What that means is that each Pulsar topic has a hierarchical management structure making the allocation of resources as well as the resource management and coordination between teams efficient and easy. With Pulsar’s multi-tenancy structure, data platform maintainers can onboard new teams with no friction as Pulsar provides resource isolation at the property (tenant), namespace or topic level, while at the same time data can be shared across the cluster for easy collaboration and coordination.
+
+
+
+
+
+
+Finally, Pulsar’s flexible messaging framework unifies the streaming and queuing data consumption models and provides greater flexibility. As shown in the below diagram, Pulsar holds the data in the topic while multiple teams can consume the data independently depending on their workloads and data consumption patterns.
+
+
+
+
+
+
+## Pulsar’s view on data: Segmented data streams
+
+Apache Flink is a streaming-first computation framework that perceives [batch processing as a special case of streaming](/news/2019/02/13/unified-batch-streaming-blink.html). Flink’s view on data streams distinguishes batch and stream processing between bounded and unbounded data streams, assuming that for batch workloads the data stream is finite, with a beginning and an end.
+
+Apache Pulsar has a similar perspective to that of Apache Flink with regards to the data layer. The framework also uses streams as a unified view on all data, while its layered architecture allows traditional pub-sub messaging for streaming workloads and continuous data processing or usage of *Segmented Streams* and bounded data stream for batch and static workloads.
+
+
+
+
+
+
+With Pulsar, once a producer sends data to a topic, it is partitioned depending on the data traffic and then further segmented under those partitions — using Apache Bookkeeper as segment store — to allow for parallel data processing as illustrated in the diagram below. This allows a combination of traditional pub-sub messaging and distributed parallel computations in one framework.
+
+
+
+
+
+
+## When Flink + Pulsar come together
+
+Apache Flink and Apache Pulsar integrate in multiple ways already. In the following sections, I will present some potential future integrations between the frameworks and share examples of existing ways in which you can utilize the frameworks together.
+
+### Potential Integrations
+
+Pulsar can integrate with Apache Flink in different ways. Some potential integrations include providing support for streaming workloads with the use of *Streaming Connectors* and support for batch workloads with the use of *Batch Source Connectors*. Pulsar also comes with native support for schema that can integrate with Flink and provide structured access to the data, for example by using Flink SQL as a way of querying data in Pulsar. Finally, an alternative way of integrating the technologies could include using Pulsar as a state backend with Flink. Since Pulsar has a layered architecture (*Streams* and *Segmented Streams*, powered by Apache Bookkeeper), it becomes natural to use Pulsar as a storage layer and store Flink state.
+
+From an architecture point of view, we can imagine the integration between the two frameworks as one that uses Apache Pulsar for a unified view of the data layer and Apache Flink as a unified computation and data processing framework and API.
+
+
+### Existing Integrations
+
+Integration between the two frameworks is ongoing and developers can already use Pulsar with Flink in multiple ways. For example, Pulsar can be used as a streaming source and streaming sink in Flink DataStream applications. Developers can ingest data from Pulsar into a Flink job that makes computations and processes real-time data, to then send the data back to a Pulsar topic as a streaming sink. Such an example is shown below:
+
+
+```java
+// create and configure Pulsar consumer
+PulsarSourceBuilderbuilder = PulsarSourceBuilder
+ .builder(new SimpleStringSchema())
+ .serviceUrl(serviceUrl)
+ .topic(inputTopic)
+ .subscriptionName(subscription);
+SourceFunction src = builder.build();
+// ingest DataStream with Pulsar consumer
+DataStream words = env.addSource(src);
+
+// perform computation on DataStream (here a simple WordCount)
+DataStream wc = words
+ .flatMap((FlatMapFunction) (word, collector) -> {
+ collector.collect(new WordWithCount(word, 1));
+ })
+ .returns(WordWithCount.class)
+ .keyBy("word")
+ .timeWindow(Time.seconds(5))
+ .reduce((ReduceFunction) (c1, c2) ->
+ new WordWithCount(c1.word, c1.count + c2.count));
+
+// emit result via Pulsar producer
+wc.addSink(new FlinkPulsarProducer<>(
+ serviceUrl,
+ outputTopic,
+ new AuthenticationDisabled(),
+ wordWithCount -> wordWithCount.toString().getBytes(UTF_8),
+ wordWithCount -> wordWithCount.word)
+);
+```
+
+Another integration between the two frameworks that developers can take advantage of includes using Pulsar as both a streaming source and a streaming table sink for Flink SQL or Table API queries as shown in the example below:
+
+```java
+// obtain a DataStream with words
+DataStream words = ...
+
+// register DataStream as Table "words" with two attributes ("word", "ts").
+// "ts" is an event-time timestamp.
+tableEnvironment.registerDataStream("words", words, "word, ts.rowtime");
+
+// create a TableSink that produces to Pulsar
+TableSink sink = new PulsarJsonTableSink(
+ serviceUrl,
+ outputTopic,
+ new AuthenticationDisabled(),
+ ROUTING_KEY);
+
+// register Pulsar TableSink as table "wc"
+tableEnvironment.registerTableSink(
+ "wc",
+ sink.configure(
+ new String[]{"word", "cnt"},
+ new TypeInformation[]{Types.STRING, Types.LONG}));
+
+// count words per 5 seconds and write result to table "wc"
+tableEnvironment.sqlUpdate(
+ "INSERT INTO wc " +
+ "SELECT word, COUNT(*) AS cnt " +
+ "FROM words " +
+ "GROUP BY word, TUMBLE(ts, INTERVAL '5' SECOND)");
+```
+
+Finally, Flink integrates with Pulsar for batch workloads as a batch sink where all results get pushed to Pulsar after Apache Flink has completed the computation in a static data set. Such an example is shown below:
+
+```java
+// obtain DataSet from arbitrary computation
+DataSet wc = ...
+
+// create PulsarOutputFormat instance
+OutputFormat pulsarOutputFormat = new PulsarOutputFormat(
+ serviceUrl,
+ topic,
+ new AuthenticationDisabled(),
+ wordWithCount -> wordWithCount.toString().getBytes());
+// write DataSet to Pulsar
+wc.output(pulsarOutputFormat);
+```
+
+## Conclusion
+
+Both Pulsar and Flink share a similar view on how the data and the computation level of an application can be *“streaming-first”* with batch as a special case streaming. With Pulsar’s Segmented Streams approach and Flink’s steps to unify batch and stream processing workloads under one framework, there are numerous ways of integrating the two technologies together to provide elastic data processing at massive scale. Subscribe to the [Apache Flink](/community.html#mailing-lists) and [Apache Pulsar](https://lists.apache.org/list.html?dev@pulsar.apache.org) mailing lists to stay up-to-date with the latest developments in this space or share your thoughts and recommendations with both communities.
diff --git a/docs/content.tr/posts/2019-05-14-temporal-tables.md b/docs/content.tr/posts/2019-05-14-temporal-tables.md
new file mode 100644
index 0000000000..6295c972b8
--- /dev/null
+++ b/docs/content.tr/posts/2019-05-14-temporal-tables.md
@@ -0,0 +1,114 @@
+---
+authors:
+- morsapaes: null
+ name: Marta Paes
+ twitter: morsapaes
+date: "2019-05-14T12:00:00Z"
+excerpt: Apache Flink natively supports temporal table joins since the 1.7 release
+ for straightforward temporal data handling. In this blog post, we provide an overview
+ of how this new concept can be leveraged for effective point-in-time analysis in
+ streaming scenarios.
+title: Flux capacitor, huh? Temporal Tables and Joins in Streaming SQL
+aliases:
+- /2019/05/14/temporal-tables.html
+---
+
+Figuring out how to manage and model temporal data for effective point-in-time analysis was a longstanding battle, dating as far back as the early 80’s, that culminated with the introduction of temporal tables in the SQL standard in 2011. Up to that point, users were doomed to implement this as part of the application logic, often hurting the length of the development lifecycle as well as the maintainability of the code. And, although there isn’t a single, commonly accepted definition of **temporal data**, the challenge it represents is one and the same: how do we validate or enrich data against dynamically changing, historical datasets?
+
+
+
+
+
+
+**For example:** given a stream with Taxi Fare events tied to the local currency of the ride location, we might want to convert the fare price to a common currency for further processing. As conversion rates excel at fluctuating over time, each Taxi Fare event would need to be matched to the rate that was valid at the time the event occurred in order to produce a reliable result.
+
+## Modelling Temporal Data with Flink
+
+In the 1.7 release, Flink has introduced the concept of **temporal tables** into its streaming SQL and Table API: parameterized views on append-only tables — or, any table that only allows records to be inserted, never updated or deleted — that are interpreted as a changelog and keep data closely tied to time context, so that it can be interpreted as valid only within a specific period of time. Transforming a stream into a temporal table requires:
+
+* Defining a **primary key** and a **versioning field** that can be used to keep track of the changes that happen over time;
+
+* Exposing the stream as a **temporal table function** that maps each point in time to a static relation.
+
+Going back to our example use case, a temporal table is just what we need to model the conversion rate data such as to make it useful for point-in-time querying. Temporal table functions are implemented as an extension of Flink’s generic [table function]({{< param DocsBaseUrl >}}flink-docs-release-1.8/dev/table/udfs.html#table-functions) class and can be defined in the same straightforward way to be used with the Table API or SQL parser.
+
+```java
+import org.apache.flink.table.functions.TemporalTableFunction;
+
+(...)
+
+// Get the stream and table environments.
+StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
+StreamTableEnvironment tEnv = StreamTableEnvironment.getTableEnvironment(env);
+
+// Provide a sample static data set of the rates history table.
+List >ratesHistoryData =new ArrayList<>();
+
+ratesHistoryData.add(Tuple2.of("USD", 102L));
+ratesHistoryData.add(Tuple2.of("EUR", 114L));
+ratesHistoryData.add(Tuple2.of("YEN", 1L));
+ratesHistoryData.add(Tuple2.of("EUR", 116L));
+ratesHistoryData.add(Tuple2.of("USD", 105L));
+
+// Create and register an example table using the sample data set.
+DataStream> ratesHistoryStream = env.fromCollection(ratesHistoryData);
+
+Table ratesHistory = tEnv.fromDataStream(ratesHistoryStream, "r_currency, r_rate, r_proctime.proctime");
+
+tEnv.registerTable("RatesHistory", ratesHistory);
+
+// Create and register the temporal table function "rates".
+// Define "r_proctime" as the versioning field and "r_currency" as the primary key.
+TemporalTableFunction rates = ratesHistory.createTemporalTableFunction("r_proctime", "r_currency");
+
+tEnv.registerFunction("Rates", rates);
+
+(...)
+```
+
+What does this **Rates** function do, in practice? Imagine we would like to check what the conversion rates looked like at a given time — say, 11:00. We could simply do something like:
+
+```sql
+SELECT * FROM Rates('11:00');
+```
+
+
+
+
+
+
+Even though Flink does not yet support querying temporal table functions with a constant time attribute parameter, these functions can be used to cover a much more interesting scenario: temporal table joins.
+
+## Streaming Joins using Temporal Tables
+
+Temporal tables reach their full potential when used in combination — erm, joined — with streaming data, for instance to power applications that must continuously whitelist against a reference dataset that changes over time for auditing or regulatory compliance. While efficient joins have long been an enduring challenge for query processors due to computational cost and resource consumption, joins over streaming data carry some additional challenges:
+
+* The **unbounded** nature of streams means that inputs are continuously evaluated and intermediate join results can consume memory resources indefinitely. Flink gracefully manages its memory consumption out-of-the-box (even for heavier cases where joins require spilling to disk) and supports time-windowed joins to bound the amount of data that needs to be kept around as state;
+* Streaming data might be **out-of-order** and **late**, so it is not possible to enforce an ordering upfront and time handling requires some thinking to avoid unnecessary outputs and retractions.
+
+In the particular case of temporal data, time-windowed joins are not enough (well, at least not without getting into some expensive tweaking): sooner or later, each reference record will fall outside of the window and be wiped from state, no longer being considered for future join results. To address this limitation, Flink has introduced support for temporal table joins to cover time-varying relations.
+
+
+
+
+
+
+Each record from the append-only table on the probe side (```Taxi Fare```) is joined with the version of the record from the temporal table on the build side (```Conversion Rate```) that most closely matches the probe side record time attribute (```time```) for the same value of the primary key (```currency```). Remember the temporal table function (```Rates```) we registered earlier? It can now be used to express this join as a simple SQL statement that would otherwise require a heavier statement with a subquery.
+
+
+
+
+
+
+Temporal table joins support both [processing]({{< param DocsBaseUrl >}}flink-docs-release-1.8/dev/table/streaming/joins.html#processing-time-temporal-joins) and [event time]({{< param DocsBaseUrl >}}flink-docs-release-1.8/dev/table/streaming/joins.html#event-time-temporal-joins) semantics and effectively limit the amount of data kept in state while also allowing records on the build side to be arbitrarily old, as opposed to time-windowed joins. Probe-side records only need to be kept in state for a very short time to ensure correct semantics in presence of out-of-order records. The challenges mentioned in the beginning of this section are overcome by:
+
+* Narrowing the **scope** of the join: only the time-matching version of ```ratesHistory``` is visible for a given ```taxiFare.time```;
+* Pruning **unneeded records** from state: for cases using event time, records between current time and the [watermark]({{< param DocsBaseUrl >}}flink-docs-release-1.8/dev/event_time.html#event-time-and-watermarks) delay are persisted for both the probe and build side. These are discarded as soon as the watermark arrives and the results are emitted — allowing the join operation to move forward in time and the build table to “refresh” its version in state.
+
+## Conclusion
+
+All this means it is now possible to express continuous stream enrichment in relational and time-varying terms using Flink without dabbling into syntactic patchwork or compromising performance. In other words: stream time-travelling minus the flux capacitor. Extending this syntax to batch processing for enriching historic data with proper (event) time semantics is also part of the Flink roadmap!
+
+If you'd like to get some **hands-on practice in joining streams with Flink SQL** (and Flink SQL in general), checkout this [free training for Flink SQL](https://github.com/ververica/sql-training/wiki). The training environment is based on Docker and set up in just a few minutes.
+
+Subscribe to the [Apache Flink mailing lists](/community.html#mailing-lists) to stay up-to-date with the latest developments in this space.
diff --git a/docs/content.tr/posts/2019-05-17-state-ttl.md b/docs/content.tr/posts/2019-05-17-state-ttl.md
new file mode 100644
index 0000000000..3a98d13752
--- /dev/null
+++ b/docs/content.tr/posts/2019-05-17-state-ttl.md
@@ -0,0 +1,138 @@
+---
+authors:
+- fabian: null
+ name: Fabian Hueske
+ twitter: fhueske
+- andrey: null
+ name: Andrey Zagrebin
+date: "2019-05-17T12:00:00Z"
+excerpt: A common requirement for many stateful streaming applications is to automatically
+ cleanup application state for effective management of your state size, or to control
+ how long the application state can be accessed. State TTL enables application state
+ cleanup and efficient state size management in Apache Flink
+title: 'State TTL in Flink 1.8.0: How to Automatically Cleanup Application State in
+ Apache Flink'
+aliases:
+- /2019/05/19/state-ttl.html
+---
+
+A common requirement for many stateful streaming applications is to automatically cleanup application state for effective management of your state size, or to control how long the application state can be accessed (e.g. due to legal regulations like the GDPR). The state time-to-live (TTL) feature was initiated in Flink 1.6.0 and enabled application state cleanup and efficient state size management in Apache Flink.
+
+In this post, we motivate the State TTL feature and discuss its use cases. Moreover, we show how to use and configure it. We explain how Flink internally manages state with TTL and present some exciting additions to the feature in Flink 1.8.0. The blog post concludes with an outlook on future improvements and extensions.
+
+# The Transient Nature of State
+
+There are two major reasons why state should be maintained only for a limited time. For example, let’s imagine a Flink application that ingests a stream of user login events and stores for each user the time of the last login to improve the experience of frequent visitors.
+
+* **Controlling the size of state.**
+Being able to efficiently manage an ever-growing state size is a primary use case for state TTL. Oftentimes, data needs to be persisted temporarily while there is some user activity around it, e.g. web sessions. When the activity ends there is no longer interest in that data while it still occupies storage. Flink 1.8.0 introduces background cleanup of old state based on TTL that makes the eviction of no-longer-necessary data frictionless. Previously, the application developer had to take extra actions and explicitly remove useless state to free storage space. This manual clean up procedure was not only error prone but also less efficient than the new lazy method to remove state. Following our previous example of storing the time of the last login, this might not be necessary after some time because the user can be treated as “infrequent” later on.
+
+* **Complying with data protection and sensitive data requirements.**
+Recent developments around data privacy regulations, such as the General Data Protection Regulation (GDPR) introduced by the European Union, make compliance with such data requirements or treating sensitive data a top priority for many use cases and applications. An example of such use cases includes applications that require keeping data for a specific timeframe and preventing access to it thereafter. This is a common challenge for companies providing short-term services to their customers. The state TTL feature gives guarantees for how long an application can access state and hence can help to comply with data protection regulations.
+
+Both requirements can be addressed by a feature that periodically, yet continuously, removes the state for a key once it becomes unnecessary or unimportant and there is no requirement to keep it in storage any more.
+
+# State TTL for continuous cleanup of application state
+
+The 1.6.0 release of Apache Flink introduced the State TTL feature. It enabled developers of stream processing applications to configure the state of operators to expire and be cleaned up after a defined timeout (time-to-live). In Flink 1.8.0 the feature was extended, including continuous cleanup of old entries for both the RocksDB and the heap state backends (FSStateBackend and MemoryStateBackend), enabling a continuous cleanup process of old entries (according to the TTL setting).
+
+In Flink’s DataStream API, application state is defined by a [state descriptor]({{< param DocsBaseUrl >}}flink-docs-release-1.8/dev/stream/state/state.html#using-managed-keyed-state). State TTL is configured by passing a `StateTtlConfiguration` object to a state descriptor. The following Java example shows how to create a state TTL configuration and provide it to the state descriptor that holds the last login time of a user as a `Long` value:
+
+```java
+import org.apache.flink.api.common.state.StateTtlConfig;
+import org.apache.flink.api.common.time.Time;
+import org.apache.flink.api.common.state.ValueStateDescriptor;
+
+StateTtlConfig ttlConfig = StateTtlConfig
+ .newBuilder(Time.days(7))
+ .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite)
+ .setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired)
+ .build();
+
+ValueStateDescriptor lastUserLogin =
+ new ValueStateDescriptor<>("lastUserLogin", Long.class);
+
+lastUserLogin.enableTimeToLive(ttlConfig);
+```
+
+Flink provides multiple options to configure the behavior of the state TTL functionality.
+
+* **When is the Time-to-Live reset?**
+By default, the expiration time of a state entry is updated when the state is modified. Optionally, it can also be updated on read access at the cost of an additional write operation to update the timestamp.
+
+* **Can the expired state be accessed one last time?**
+State TTL employs a lazy strategy to clean up expired state. This can lead to the situation that an application attempts to read state which is expired but hasn’t been removed yet. You can configure whether such a read request returns the expired state or not. In either case, the expired state is immediately removed afterwards. While the option of returning expired state favors data availability, not returning expired state can be required for data protection regulations.
+
+* **Which time semantics are used for the Time-to-Live timers?**
+With Flink 1.8.0, users can only define a state TTL in terms of processing time. The support for event time is planned for future Apache Flink releases.
+
+You can read more about how to use state TTL in the [Apache Flink documentation]({{< param DocsBaseUrl >}}flink-docs-stable/dev/stream/state/state.html#state-time-to-live-ttl).
+
+Internally, the State TTL feature is implemented by storing an additional timestamp of the last relevant state access, along with the actual state value. While this approach adds some storage overhead, it allows Flink to check for the expired state during state access, checkpointing, recovery, or dedicated storage cleanup procedures.
+
+# “Taking out the Garbage”
+
+When a state object is accessed in a read operation, Flink will check its timestamp and clear the state if it is expired (depending on the configured state visibility, the expired state is returned or not). Due to this lazy removal, expired state that is never accessed again will forever occupy storage space unless it is garbage collected.
+
+So how can the expired state be removed without the application logic explicitly taking care of it? In general, there are different possible strategies to remove it in the background.
+
+## Keep full state snapshots clean
+
+Flink 1.6.0 already supported automatic eviction of the expired state when a full snapshot for a checkpoint or savepoint is taken. Note that state eviction is not applied for incremental checkpoints. State eviction on full snapshots must be explicitly enabled as shown in the following example:
+
+```java
+StateTtlConfig ttlConfig = StateTtlConfig
+ .newBuilder(Time.days(7))
+ .cleanupFullSnapshot()
+ .build();
+```
+
+The local storage stays untouched but the size of the stored snapshot is reduced. The local state of an operator will only be cleaned up when the operator reloads its state from a snapshot, i.e. in case of recovery or when starting from a savepoint.
+
+Due to these limitations, applications still need to actively remove state after it expired in Flink 1.6.0. To improve the user experience, Flink 1.8.0 introduces two more autonomous cleanup strategies, one for each of Flink’s two state backend types. We describe them below.
+
+## Incremental cleanup in Heap state backends
+
+This approach is specific to the Heap state backends (FSStateBackend and MemoryStateBackend). The idea is that the storage backend keeps a lazy global iterator over all state entries. Certain events, for instance state access, trigger an incremental cleanup. Every time an incremental cleanup is triggered, the iterator is advanced. The traversed state entries are checked and expired once are removed. The following code example shows how to enable incremental cleanup:
+
+```java
+StateTtlConfig ttlConfig = StateTtlConfig
+ .newBuilder(Time.days(7))
+ // check 10 keys for every state access
+ .cleanupIncrementally(10, false)
+ .build();
+```
+
+If enabled, every state access triggers a cleanup step. For every clean up step, a certain number of state entries are checked for expiration. There are two tuning parameters. The first defines the number of state entries to check for each cleanup step. The second parameter is a flag to trigger a cleanup step after each processed record, additionally to each state access.
+
+There are two important caveats about this approach:
+* The first one is that the time spent for the incremental cleanup increases the record processing latency.
+* The second one should be practically negligible but still worth mentioning: if no state is accessed or no records are processed, expired state won’t be removed.
+
+## RocksDB background compaction to filter out expired state
+
+If your application uses the RocksDB state backend, you can enable another cleanup strategy which is based on a Flink specific compaction filter. RocksDB periodically runs asynchronous compactions to merge state updates and reduce storage. The Flink compaction filter checks the expiration timestamp of state entries with TTL and discards all expired values.
+
+The first step to activate this feature is to configure the RocksDB state backend by setting the following Flink configuration option: `state.backend.rocksdb.ttl.compaction.filter.enabled`. Once the RocksDB state backend is configured, the compaction cleanup strategy is enabled for a state as shown in the following code example:
+
+```java
+StateTtlConfig ttlConfig = StateTtlConfig
+ .newBuilder(Time.days(7))
+ .cleanupInRocksdbCompactFilter()
+ .build();
+```
+Keep in mind that calling the Flink TTL filter slows down the RocksDB compaction.
+
+## Eager State Cleanup with Timers
+
+Another way to manually cleanup state is based on Flink timers. This is an idea that the community is currently evaluating for future releases. With this approach, a cleanup timer is registered for every state access. This approach is more predictable because state is eagerly removed as soon as it expires. However, it is more expensive because the timers consume storage along with the original state.
+
+# Future work
+
+Apart from including the timer-based cleanup strategy, mentioned above, the Flink community has plans to further improve the state TTL feature. The possible improvements include adding support of TTL for event time scale (only processing time is supported at the moment) and enabling State TTL for queryable state.
+
+We encourage you to join the conversation and share your thoughts and ideas in the [Apache Flink JIRA board](https://issues.apache.org/jira/projects/FLINK/summary) or by subscribing to the Apache Flink dev mailing list. Feedback or suggestions are always appreciated and we look forward to hearing your thoughts on the Flink mailing lists.
+
+# Summary
+
+Time-based state access restrictions and controlling the size of application state are common challenges in the world of stateful stream processing. Flink’s 1.8.0 release significantly improves the State TTL feature by adding support for continuous background cleanup of expired state objects. The new clean up mechanisms relieve you from manually implementing state cleanup. They are also more efficient due to their lazy nature. State TTL gives you control over the size of your application state so that you can focus on the core logic of your applications.
diff --git a/docs/content.tr/posts/2019-06-05-flink-network-stack.md b/docs/content.tr/posts/2019-06-05-flink-network-stack.md
new file mode 100644
index 0000000000..c3d1b99894
--- /dev/null
+++ b/docs/content.tr/posts/2019-06-05-flink-network-stack.md
@@ -0,0 +1,337 @@
+---
+authors:
+- Nico: null
+ name: Nico Kruber
+date: "2019-06-05T08:45:00Z"
+excerpt: Flink’s network stack is one of the core components that make up Apache Flink's
+ runtime module sitting at the core of every Flink job. In this post, which is the
+ first in a series of posts about the network stack, we look at the abstractions
+ exposed to the stream operators and detail their physical implementation and various
+ optimisations in Apache Flink.
+title: A Deep-Dive into Flink's Network Stack
+aliases:
+- /2019/06/05/flink-network-stack.html
+---
+
+
+
+Flink’s network stack is one of the core components that make up the `flink-runtime` module and sit at the heart of every Flink job. It connects individual work units (subtasks) from all TaskManagers. This is where your streamed-in data flows through and it is therefore crucial to the performance of your Flink job for both the throughput as well as latency you observe. In contrast to the coordination channels between TaskManagers and JobManagers which are using RPCs via Akka, the network stack between TaskManagers relies on a much lower-level API using Netty.
+
+This blog post is the first in a series of posts about the network stack. In the sections below, we will first have a high-level look at what abstractions are exposed to the stream operators and then go into detail on the physical implementation and various optimisations Flink did. We will briefly present the result of these optimisations and Flink’s trade-off between throughput and latency. Future blog posts in this series will elaborate more on monitoring and metrics, tuning parameters, and common anti-patterns.
+
+## Logical View
+
+Flink’s network stack provides the following logical view to the subtasks when communicating with each other, for example during a network shuffle as required by a `keyBy()`.
+
+
+
+
+
+
+It abstracts over the different settings of the following three concepts:
+
+* Subtask output type (`ResultPartitionType`):
+ * **pipelined (bounded or unbounded):**
+ Sending data downstream as soon as it is produced, potentially one-by-one, either as a bounded or unbounded stream of records.
+ * **blocking:**
+ Sending data downstream only when the full result was produced.
+
+* Scheduling type:
+ * **all at once (eager):**
+ Deploy all subtasks of the job at the same time (for streaming applications).
+ * **next stage on first output (lazy):**
+ Deploy downstream tasks as soon as any of their producers generated output.
+ * **next stage on complete output:**
+ Deploy downstream tasks when any or all of their producers have generated their full output set.
+
+* Transport:
+ * **high throughput:**
+ Instead of sending each record one-by-one, Flink buffers a bunch of records into its network buffers and sends them altogether. This reduces the costs per record and leads to higher throughput.
+ * **low latency via buffer timeout:**
+ By reducing the timeout of sending an incompletely filled buffer, you may sacrifice throughput for latency.
+
+We will have a look at the throughput and low latency optimisations in the sections below which look at the physical layers of the network stack. For this part, let us elaborate a bit more on the output and scheduling types. First of all, it is important to know that the subtask output type and the scheduling type are closely intertwined making only specific combinations of the two valid.
+
+Pipelined result partitions are streaming-style outputs which need a live target subtask to send data to. The target can be scheduled before results are produced or at first output. Batch jobs produce bounded result partitions while streaming jobs produce unbounded results.
+
+Batch jobs may also produce results in a blocking fashion, depending on the operator and connection pattern that is used. In that case, the complete result must be produced first before the receiving task can be scheduled. This allows batch jobs to work more efficiently and with lower resource usage.
+
+The following table summarises the valid combinations:
+
+
+
+
+ Output Type
+ Scheduling Type
+ Applies to…
+
+
+ pipelined, unbounded
+ all at once
+ Streaming jobs
+
+
+ next stage on first output
+ n/a¹
+
+
+ pipelined, bounded
+ all at once
+ n/a²
+
+
+ next stage on first output
+ Batch jobs
+
+
+ blocking
+ next stage on complete output
+ Batch jobs
+
+
+
+
+
+
+1 Currently not used by Flink.
+2 This may become applicable to streaming jobs once the [Batch/Streaming unification](/roadmap.html#batch-and-streaming-unification) is done.
+
+
+
+Additionally, for subtasks with more than one input, scheduling start in two ways: after *all* or after *any* input producers to have produced a record/their complete dataset. For tuning the output types and scheduling decisions in batch jobs, please have a look at [ExecutionConfig#setExecutionMode()]({{< param DocsBaseUrl >}}flink-docs-release-1.8/api/java/org/apache/flink/api/common/ExecutionConfig.html#setExecutionMode-org.apache.flink.api.common.ExecutionMode-) - and [ExecutionMode]({{< param DocsBaseUrl >}}flink-docs-release-1.8/api/java/org/apache/flink/api/common/ExecutionMode.html#enum.constant.detail) in particular - as well as [ExecutionConfig#setDefaultInputDependencyConstraint()]({{< param DocsBaseUrl >}}flink-docs-release-1.8/api/java/org/apache/flink/api/common/ExecutionConfig.html#setDefaultInputDependencyConstraint-org.apache.flink.api.common.InputDependencyConstraint-).
+
+
+
+## Physical Transport
+
+In order to understand the physical data connections, please recall that, in Flink, different tasks may share the same slot via [slot sharing groups]({{< param DocsBaseUrl >}}flink-docs-release-1.8/dev/stream/operators/#task-chaining-and-resource-groups). TaskManagers may also provide more than one slot to allow multiple subtasks of the same task to be scheduled onto the same TaskManager.
+
+For the example pictured below, we will assume a parallelism of 4 and a deployment with two task managers offering 2 slots each. TaskManager 1 executes subtasks A.1, A.2, B.1, and B.2 and TaskManager 2 executes subtasks A.3, A.4, B.3, and B.4. In a shuffle-type connection between task A and task B, for example from a `keyBy()`, there are 2x4 logical connections to handle on each TaskManager, some of which are local, some remote:
+
+
+
+
+
+
+ B.1
+ B.2
+ B.3
+ B.4
+
+
+ A.1
+ local
+ remote
+
+
+ A.2
+
+
+ A.3
+ remote
+ local
+
+
+ A.4
+
+
+
+
+
+
+Each (remote) network connection between different tasks will get its own TCP channel in Flink’s network stack. However, if different subtasks of the same task are scheduled onto the same TaskManager, their network connections towards the same TaskManagers will be multiplexed and share a single TCP channel for reduced resource usage. In our example, this would apply to A.1 → B.3, A.1 → B.4, as well as A.2 → B.3, and A.2 → B.4 as pictured below:
+
+
+
+
+
+
+
+The results of each subtask are called [ResultPartition]({{< param DocsBaseUrl >}}flink-docs-release-1.8/api/java/org/apache/flink/runtime/io/network/partition/ResultPartition.html), each split into separate [ResultSubpartitions]({{< param DocsBaseUrl >}}flink-docs-release-1.8/api/java/org/apache/flink/runtime/io/network/partition/ResultSubpartition.html) — one for each logical channel. At this point in the stack, Flink is not dealing with individual records anymore but instead with a group of serialised records assembled together into network buffers. The number of buffers available to each subtask in its own local buffer pool (one per sending and receiving side each) is limited to at most
+
+ #channels * buffers-per-channel + floating-buffers-per-gate
+
+The total number of buffers on a single TaskManager usually does not need configuration. See the [Configuring the Network Buffers]({{< param DocsBaseUrl >}}flink-docs-release-1.8/ops/config.html#configuring-the-network-buffers) documentation for details on how to do so if needed.
+
+### Inflicting Backpressure (1)
+
+Whenever a subtask’s sending buffer pool is exhausted — buffers reside in either a result subpartition's buffer queue or inside the lower, Netty-backed network stack — the producer is blocked, cannot continue, and experiences backpressure. The receiver works in a similar fashion: any incoming Netty buffer in the lower network stack needs to be made available to Flink via a network buffer. If there is no network buffer available in the appropriate subtask's buffer pool, Flink will stop reading from this channel until a buffer becomes available. This would effectively backpressure all sending subtasks on this multiplex and therefore also throttle other receiving subtasks. The following picture illustrates this for an overloaded subtask B.4 which would cause backpressure on the multiplex and also stop subtask B.3 from receiving and processing further buffers, even though it still has capacity.
+
+
+
+
+
+
+
+
+To prevent this situation from even happening, Flink 1.5 introduced its own flow control mechanism.
+
+
+
+## Credit-based Flow Control
+
+Credit-based flow control makes sure that whatever is “on the wire” will have capacity at the receiver to handle. It is based on the availability of network buffers as a natural extension of the mechanisms Flink had before. Instead of only having a shared local buffer pool, each remote input channel now has its own set of **exclusive buffers**. Conversely, buffers in the local buffer pool are called **floating buffers** as they will float around and are available to every input channel.
+
+Receivers will announce the availability of buffers as **credits** to the sender (1 buffer = 1 credit). Each result subpartition will keep track of its **channel credits**. Buffers are only forwarded to the lower network stack if credit is available and each sent buffer reduces the credit score by one. In addition to the buffers, we also send information about the current **backlog** size which specifies how many buffers are waiting in this subpartition’s queue. The receiver will use this to ask for an appropriate number of floating buffers for faster backlog processing. It will try to acquire as many floating buffers as the backlog size but this may not always be possible and we may get some or no buffers at all. The receiver will make use of the retrieved buffers and will listen for further buffers becoming available to continue.
+
+
+
+
+
+
+
+Credit-based flow control will use [buffers-per-channel]({{< param DocsBaseUrl >}}flink-docs-release-1.8/ops/config.html#taskmanager-network-memory-buffers-per-channel) to specify how many buffers are exclusive (mandatory) and [floating-buffers-per-gate]({{< param DocsBaseUrl >}}flink-docs-release-1.8/ops/config.html#taskmanager-network-memory-floating-buffers-per-gate) for the local buffer pool (optional3 ) thus achieving the same buffer limit as without flow control. The default values for these two parameters have been chosen so that the maximum (theoretical) throughput with flow control is at least as good as without flow control, given a healthy network with usual latencies. You may need to adjust these depending on your actual round-trip-time and bandwidth.
+
+
+3 If there are not enough buffers available, each buffer pool will get the same share of the globally available ones (± 1).
+
+### Inflicting Backpressure (2)
+
+As opposed to the receiver's backpressure mechanisms without flow control, credits provide a more direct control: If a receiver cannot keep up, its available credits will eventually hit 0 and stop the sender from forwarding buffers to the lower network stack. There is backpressure on this logical channel only and there is no need to block reading from a multiplexed TCP channel. Other receivers are therefore not affected in processing available buffers.
+
+### What do we Gain? Where is the Catch?
+
+
+
+Since, with flow control, a channel in a multiplex cannot block another of its logical channels, the overall resource utilisation should increase. In addition, by having full control over how much data is “on the wire”, we are also able to improve [checkpoint alignments]({{< param DocsBaseUrl >}}flink-docs-release-1.8/internals/stream_checkpointing.html#checkpointing): without flow control, it would take a while for the channel to fill the network stack’s internal buffers and propagate that the receiver is not reading anymore. During that time, a lot of buffers could be sitting around. Any checkpoint barrier would have to queue up behind these buffers and would thus have to wait until all of those have been processed before it can start (“Barriers never overtake records!”).
+
+However, the additional announce messages from the receiver may come at some additional costs, especially in setup using SSL-encrypted channels. Also, a single input channel cannot make use of all buffers in the buffer pool because exclusive buffers are not shared. It can also not start right away with sending as much data as is available so that during ramp-up (if you are producing data faster than announcing credits in return) it may take longer to send data through. While this may affect your job’s performance, it is usually better to have flow control because of all its advantages. You may want to increase the number of exclusive buffers via [buffers-per-channel]({{< param DocsBaseUrl >}}flink-docs-release-1.8/ops/config.html#taskmanager-network-memory-buffers-per-channel) at the cost of using more memory. The overall memory use compared to the previous implementation, however, may still be lower because lower network stacks do not need to buffer much data any more since we can always transfer that to Flink immediately.
+
+There is one more thing you may notice when using credit-based flow control: since we buffer less data between the sender and receiver, you may experience backpressure earlier. This is, however, desired and you do not really get any advantage by buffering more data. If you want to buffer more but keep flow control, you could consider increasing the number of floating buffers via [floating-buffers-per-gate]({{< param DocsBaseUrl >}}flink-docs-release-1.8/ops/config.html#taskmanager-network-memory-floating-buffers-per-gate).
+
+
+
+
+
+
+ Advantages
+ Disadvantages
+
+
+
+ • better resource utilisation with data skew in multiplexed connections
+ • improved checkpoint alignment
+ • reduced memory use (less data in lower network layers)
+
+ • additional credit-announce messages
+ • additional backlog-announce messages (piggy-backed with buffer messages, almost no overhead)
+ • potential round-trip latency
+
+
+ • backpressure appears earlier
+
+
+
+
+
+
+ Note
+If you need to turn off credit-based flow control, you can add this to your `flink-conf.yaml`:
+
+`taskmanager.network.credit-model: false`
+
+This parameter, however, is deprecated and will eventually be removed along with the non-credit-based flow control code.
+
+
+
+
+## Writing Records into Network Buffers and Reading them again
+
+The following picture extends the slightly more high-level view from above with further details of the network stack and its surrounding components, from the collection of a record in your sending operator to the receiving operator getting it:
+
+
+
+
+
+
+
+After creating a record and passing it along, for example via `Collector#collect()`, it is given to the [RecordWriter]({{< param DocsBaseUrl >}}flink-docs-release-1.8/api/java/org/apache/flink/runtime/io/network/api/writer/RecordWriter.html) which serialises the record from a Java object into a sequence of bytes which eventually ends up in a network buffer that is handed along as described above. The RecordWriter first serialises the record to a flexible on-heap byte array using the [SpanningRecordSerializer]({{< param DocsBaseUrl >}}flink-docs-release-1.8/api/java/org/apache/flink/runtime/io/network/api/serialization/SpanningRecordSerializer.html). Afterwards, it tries to write these bytes into the associated network buffer of the target network channel. We will come back to this last part in the section below.
+
+On the receiver’s side, the lower network stack (netty) is writing received buffers into the appropriate input channels. The (stream) tasks’s thread eventually reads from these queues and tries to deserialise the accumulated bytes into Java objects with the help of the [RecordReader]({{< param DocsBaseUrl >}}flink-docs-release-1.8/api/java/org/apache/flink/runtime/io/network/api/reader/RecordReader.html) and going through the [SpillingAdaptiveSpanningRecordDeserializer]({{< param DocsBaseUrl >}}flink-docs-release-1.8/api/java/org/apache/flink/runtime/io/network/api/serialization/SpillingAdaptiveSpanningRecordDeserializer.html). Similar to the serialiser, this deserialiser must also deal with special cases like records spanning multiple network buffers, either because the record is just bigger than a network buffer (32KiB by default, set via [taskmanager.memory.segment-size]({{< param DocsBaseUrl >}}flink-docs-release-1.8/ops/config.html#taskmanager-memory-segment-size)) or because the serialised record was added to a network buffer which did not have enough remaining bytes. Flink will nevertheless use these bytes and continue writing the rest to a new network buffer.
+
+
+### Flushing Buffers to Netty
+
+In the picture above, the credit-based flow control mechanics actually sit inside the “Netty Server” (and “Netty Client”) components and the buffer the RecordWriter is writing to is always added to the result subpartition in an empty state and then gradually filled with (serialised) records. But when does Netty actually get the buffer? Obviously, it cannot take bytes whenever they become available since that would not only add substantial costs due to cross-thread communication and synchronisation, but also make the whole buffering obsolete.
+
+In Flink, there are three situations that make a buffer available for consumption by the Netty server:
+
+* a buffer becomes full when writing a record to it, or
+* the buffer timeout hits, or
+* a special event such as a checkpoint barrier is sent.
+
+
+#### Flush after Buffer Full
+
+The RecordWriter works with a local serialisation buffer for the current record and will gradually write these bytes to one or more network buffers sitting at the appropriate result subpartition queue. Although a RecordWriter can work on multiple subpartitions, each subpartition has only one RecordWriter writing data to it. The Netty server, on the other hand, is reading from multiple result subpartitions and multiplexing the appropriate ones into a single channel as described above. This is a classical producer-consumer pattern with the network buffers in the middle and as shown by the next picture. After (1) serialising and (2) writing data to the buffer, the RecordWriter updates the buffer’s writer index accordingly. Once the buffer is completely filled, the record writer will (3) acquire a new buffer from its local buffer pool for any remaining bytes of the current record - or for the next one - and add the new one to the subpartition queue. This will (4) notify the Netty server of data being available if it is not aware yet4 . Whenever Netty has capacity to handle this notification, it will (5) take the buffer and send it along the appropriate TCP channel.
+
+
+
+
+
+
+
+4 We can assume it already got the notification if there are more finished buffers in the queue.
+
+
+#### Flush after Buffer Timeout
+
+In order to support low-latency use cases, we cannot only rely on buffers being full in order to send data downstream. There may be cases where a certain communication channel does not have too many records flowing through and unnecessarily increase the latency of the few records you actually have. Therefore, a periodic process will flush whatever data is available down the stack: the output flusher. The periodic interval can be configured via [StreamExecutionEnvironment#setBufferTimeout]({{< param DocsBaseUrl >}}flink-docs-release-1.8/api/java/org/apache/flink/streaming/api/environment/StreamExecutionEnvironment.html#setBufferTimeout-long-) and acts as an upper bound on the latency5 (for low-throughput channels). The following picture shows how it interacts with the other components: the RecordWriter serialises and writes into network buffers as before but concurrently, the output flusher may (3,4) notify the Netty server of data being available if Netty is not already aware (similar to the “buffer full” scenario above). When Netty handles this notification (5) it will consume the available data from the buffer and update the buffer’s reader index. The buffer stays in the queue - any further operation on this buffer from the Netty server side will continue reading from the reader index next time.
+
+
+
+
+
+
+
+5 Strictly speaking, the output flusher does not give any guarantees - it only sends a notification to Netty which can pick it up at will / capacity. This also means that the output flusher has no effect if the channel is backpressured.
+
+
+#### Flush after special event
+
+Some special events also trigger immediate flushes if being sent through the RecordWriter. The most important ones are checkpoint barriers or end-of-partition events which obviously should go quickly and not wait for the output flusher to kick in.
+
+
+#### Further remarks
+
+In contrast to Flink < 1.5, please note that (a) network buffers are now placed in the subpartition queues directly and (b) we are not closing the buffer on each flush. This gives us a few advantages:
+
+* less synchronisation overhead (output flusher and RecordWriter are independent)
+* in high-load scenarios where Netty is the bottleneck (either through backpressure or directly), we can still accumulate data in incomplete buffers
+* significant reduction of Netty notifications
+
+However, you may notice an increased CPU use and TCP packet rate during low load scenarios. This is because, with the changes, Flink will use any *available* CPU cycles to try to maintain the desired latency. Once the load increases, this will self-adjust by buffers filling up more. High load scenarios are not affected and even get a better throughput because of the reduced synchronisation overhead.
+
+
+### Buffer Builder & Buffer Consumer
+
+If you want to dig deeper into how the producer-consumer mechanics are implemented in Flink, please take a closer look at the [BufferBuilder]({{< param DocsBaseUrl >}}flink-docs-release-1.8/api/java/org/apache/flink/runtime/io/network/buffer/BufferBuilder.html) and [BufferConsumer]({{< param DocsBaseUrl >}}flink-docs-release-1.8/api/java/org/apache/flink/runtime/io/network/buffer/BufferConsumer.html) classes which have been introduced in Flink 1.5. While reading is potentially only *per buffer*, writing to it is *per record* and thus on the hot path for all network communication in Flink. Therefore, it was very clear to us that we needed a lightweight connection between the task’s thread and the Netty thread which does not imply too much synchronisation overhead. For further details, we suggest to check out the [source code](https://github.com/apache/flink/tree/release-1.8/flink-runtime/src/main/java/org/apache/flink/runtime/io/network/buffer).
+
+
+
+## Latency vs. Throughput
+
+Network buffers were introduced to get higher resource utilisation and higher throughput at the cost of having some records wait in buffers a little longer. Although an upper limit to this wait time can be given via the buffer timeout, you may be curious to find out more about the trade-off between these two dimensions: latency and throughput, as, obviously, you cannot get both. The following plot shows various values for the buffer timeout starting at 0 (flush with every record) to 100ms (the default) and shows the resulting throughput rates on a cluster with 100 nodes and 8 slots each running a job that has no business logic and thus only tests the network stack. For comparison, we also plot Flink 1.4 before the low-latency improvements (as described above) were added.
+
+
+
+
+
+
+
+As you can see, with Flink 1.5+, even very low buffer timeouts such as 1ms (for low-latency scenarios) provide a maximum throughput as high as 75% of the default timeout where more data is buffered before being sent over the wire.
+
+
+
+## Conclusion
+
+Now you know about result partitions, the different network connections and scheduling types for both batch and streaming. You also know about credit-based flow control and how the network stack works internally, in order to reason about network-related tuning parameters and about certain job behaviours. Future blog posts in this series will build upon this knowledge and go into more operational details including relevant metrics to look at, further network stack tuning, and common antipatterns to avoid. Stay tuned for more.
+
+
diff --git a/docs/content.tr/posts/2019-06-26-broadcast-state.md b/docs/content.tr/posts/2019-06-26-broadcast-state.md
new file mode 100644
index 0000000000..e2bbe65c0f
--- /dev/null
+++ b/docs/content.tr/posts/2019-06-26-broadcast-state.md
@@ -0,0 +1,214 @@
+---
+authors:
+- fabian: null
+ name: Fabian Hueske
+ twitter: fhueske
+date: "2019-06-26T12:00:00Z"
+excerpt: Apache Flink has multiple types of operator state, one of which is called
+ Broadcast State. In this post, we explain what Broadcast State is, and show an example
+ of how it can be applied to an application that evaluates dynamic patterns on an
+ event stream.
+title: A Practical Guide to Broadcast State in Apache Flink
+aliases:
+- /2019/06/26/broadcast-state.html
+---
+
+Since version 1.5.0, Apache Flink features a new type of state which is called Broadcast State. In this post, we explain what Broadcast State is, and show an example of how it can be applied to an application that evaluates dynamic patterns on an event stream. We walk you through the processing steps and the source code to implement this application in practice.
+
+## What is Broadcast State?
+
+The Broadcast State can be used to combine and jointly process two streams of events in a specific way. The events of the first stream are broadcasted to all parallel instances of an operator, which maintains them as state. The events of the other stream are not broadcasted but sent to individual instances of the same operator and processed together with the events of the broadcasted stream.
+The new broadcast state is a natural fit for applications that need to join a low-throughput and a high-throughput stream or need to dynamically update their processing logic. We will use a concrete example of the latter use case to explain the broadcast state and show its API in more detail in the remainder of this post.
+
+## Dynamic Pattern Evaluation with Broadcast State
+
+Imagine an e-commerce website that captures the interactions of all users as a stream of user actions. The company that operates the website is interested in analyzing the interactions to increase revenue, improve the user experience, and detect and prevent malicious behavior.
+The website implements a streaming application that detects a pattern on the stream of user events. However, the company wants to avoid modifying and redeploying the application every time the pattern changes. Instead, the application ingests a second stream of patterns and updates its active pattern when it receives a new pattern from the pattern stream. In the following, we discuss this application step-by-step and show how it leverages the broadcast state feature in Apache Flink.
+
+
+
+
+
+
+Our example application ingests two data streams. The first stream provides user actions on the website and is illustrated on the top left side of the above figure. A user interaction event consists of the type of the action (user login, user logout, add to cart, or complete payment) and the id of the user, which is encoded by color. The user action event stream in our illustration contains a logout action of User 1001 followed by a payment-complete event for User 1003, and an “add-to-cart” action of User 1002.
+
+The second stream provides action patterns that the application will evaluate. A pattern consists of two consecutive actions. In the figure above, the pattern stream contains the following two:
+
+* Pattern #1: A user logs in and immediately logs out without browsing additional pages on the e-commerce website.
+* Pattern #2: A user adds an item to the shopping cart and logs out without completing the purchase.
+
+
+Such patterns help a business in better analyzing user behavior, detecting malicious actions, and improving the website experience. For example, in the case of items being added to a shopping cart with no follow up purchase, the website team can take appropriate actions to understand better the reasons why users don’t complete a purchase and initiate specific programs to improve the website conversion (such as providing discount codes, limited free shipping offers etc.)
+
+On the right-hand side, the figure shows three parallel tasks of an operator that ingest the pattern and user action streams, evaluate the patterns on the action stream, and emit pattern matches downstream. For the sake of simplicity, the operator in our example only evaluates a single pattern with exactly two subsequent actions. The currently active pattern is replaced when a new pattern is received from the pattern stream. In principle, the operator could also be implemented to evaluate more complex patterns or multiple patterns concurrently which could be individually added or removed.
+
+We will describe how the pattern matching application processes the user action and pattern streams.
+
+
+
+
+
+
+First a pattern is sent to the operator. The pattern is broadcasted to all three parallel tasks of the operator. The tasks store the pattern in their broadcast state. Since the broadcast state should only be updated using broadcasted data, the state of all tasks is always expected to be the same.
+
+
+
+
+
+
+Next, the first user actions are partitioned on the user id and shipped to the operator tasks. The partitioning ensures that all actions of the same user are processed by the same task. The figure above shows the state of the application after the first pattern and the first three action events were consumed by the operator tasks.
+
+When a task receives a new user action, it evaluates the currently active pattern by looking at the user’s latest and previous actions. For each user, the operator stores the previous action in the keyed state. Since the tasks in the figure above only received a single action for each user so far (we just started the application), the pattern does not need to be evaluated. Finally, the previous action in the user’s keyed state is updated to the latest action, to be able to look it up when the next action of the same user arrives.
+
+
+
+
+
+
+After the first three actions are processed, the next event, the logout action of User 1001, is shipped to the task that processes the events of User 1001. When the task receives the actions, it looks up the current pattern from the broadcast state and the previous action of User 1001. Since the pattern matches both actions, the task emits a pattern match event. Finally, the task updates its keyed state by overriding the previous event with the latest action.
+
+
+
+
+
+
+When a new pattern arrives in the pattern stream, it is broadcasted to all tasks and each task updates its broadcast state by replacing the current pattern with the new one.
+
+
+
+
+
+
+Once the broadcast state is updated with a new pattern, the matching logic continues as before, i.e., user action events are partitioned by key and evaluated by the responsible task.
+
+
+## How to Implement an Application with Broadcast State?
+
+Until now, we conceptually discussed the application and explained how it uses broadcast state to evaluate dynamic patterns over event streams. Next, we’ll show how to implement the example application with Flink’s DataStream API and the broadcast state feature.
+
+Let’s start with the input data of the application. We have two data streams, actions, and patterns. At this point, we don’t really care where the streams come from. The streams could be ingested from Apache Kafka or Kinesis or any other system. Action and Pattern are Pojos with two fields each:
+
+```java
+DataStream actions = ???
+DataStream patterns = ???
+```
+
+`Action` and `Pattern` are Pojos with two fields each:
+
+- `Action: Long userId, String action`
+
+- `Pattern: String firstAction, String secondAction`
+
+As a first step, we key the action stream on the `userId` attribute.
+
+```java
+KeyedStream actionsByUser = actions
+ .keyBy((KeySelector) action -> action.userId);
+```
+
+Next, we prepare the broadcast state. Broadcast state is always represented as `MapState`, the most versatile state primitive that Flink provides.
+
+```java
+MapStateDescriptor bcStateDescriptor =
+ new MapStateDescriptor<>("patterns", Types.VOID, Types.POJO(Pattern.class));
+```
+
+Since our application only evaluates and stores a single `Pattern` at a time, we configure the broadcast state as a `MapState` with key type `Void` and value type `Pattern`. The `Pattern` is always stored in the `MapState` with `null` as key.
+
+```java
+BroadcastStream bcedPatterns = patterns.broadcast(bcStateDescriptor);
+```
+Using the `MapStateDescriptor` for the broadcast state, we apply the `broadcast()` transformation on the patterns stream and receive a `BroadcastStream bcedPatterns`.
+
+```java
+DataStream> matches = actionsByUser
+ .connect(bcedPatterns)
+ .process(new PatternEvaluator());
+```
+
+After we obtained the keyed `actionsByUser` stream and the broadcasted `bcedPatterns` stream, we `connect()` both streams and apply a `PatternEvaluator` on the connected streams. `PatternEvaluator` is a custom function that implements the `KeyedBroadcastProcessFunction` interface. It applies the pattern matching logic that we discussed before and emits `Tuple2` records which contain the user id and the matched pattern.
+
+```java
+public static class PatternEvaluator
+ extends KeyedBroadcastProcessFunction> {
+
+ // handle for keyed state (per user)
+ ValueState prevActionState;
+ // broadcast state descriptor
+ MapStateDescriptor patternDesc;
+
+ @Override
+ public void open(Configuration conf) {
+ // initialize keyed state
+ prevActionState = getRuntimeContext().getState(
+ new ValueStateDescriptor<>("lastAction", Types.STRING));
+ patternDesc =
+ new MapStateDescriptor<>("patterns", Types.VOID, Types.POJO(Pattern.class));
+ }
+
+ /**
+ * Called for each user action.
+ * Evaluates the current pattern against the previous and
+ * current action of the user.
+ */
+ @Override
+ public void processElement(
+ Action action,
+ ReadOnlyContext ctx,
+ Collector> out) throws Exception {
+ // get current pattern from broadcast state
+ Pattern pattern = ctx
+ .getBroadcastState(this.patternDesc)
+ // access MapState with null as VOID default value
+ .get(null);
+ // get previous action of current user from keyed state
+ String prevAction = prevActionState.value();
+ if (pattern != null && prevAction != null) {
+ // user had an action before, check if pattern matches
+ if (pattern.firstAction.equals(prevAction) &&
+ pattern.secondAction.equals(action.action)) {
+ // MATCH
+ out.collect(new Tuple2<>(ctx.getCurrentKey(), pattern));
+ }
+ }
+ // update keyed state and remember action for next pattern evaluation
+ prevActionState.update(action.action);
+ }
+
+ /**
+ * Called for each new pattern.
+ * Overwrites the current pattern with the new pattern.
+ */
+ @Override
+ public void processBroadcastElement(
+ Pattern pattern,
+ Context ctx,
+ Collector> out) throws Exception {
+ // store the new pattern by updating the broadcast state
+ BroadcastState bcState = ctx.getBroadcastState(patternDesc);
+ // storing in MapState with null as VOID default value
+ bcState.put(null, pattern);
+ }
+}
+```
+
+The `KeyedBroadcastProcessFunction` interface provides three methods to process records and emit results.
+
+- `processBroadcastElement()` is called for each record of the broadcasted stream. In our `PatternEvaluator` function, we simply put the received `Pattern` record in to the broadcast state using the `null` key (remember, we only store a single pattern in the `MapState`).
+- `processElement()` is called for each record of the keyed stream. It provides read-only access to the broadcast state to prevent modification that result in different broadcast states across the parallel instances of the function. The `processElement()` method of the `PatternEvaluator` retrieves the current pattern from the broadcast state and the previous action of the user from the keyed state. If both are present, it checks whether the previous and current action match with the pattern and emits a pattern match record if that is the case. Finally, it updates the keyed state to the current user action.
+- `onTimer()` is called when a previously registered timer fires. Timers can be registered in the `processElement` method and are used to perform computations or to clean up state in the future. We did not implement this method in our example to keep the code concise. However, it could be used to remove the last action of a user when the user was not active for a certain period of time to avoid growing state due to inactive users.
+
+You might have noticed the context objects of the `KeyedBroadcastProcessFunction`’s processing method. The context objects give access to additional functionality such as:
+
+- The broadcast state (read-write or read-only, depending on the method),
+- A `TimerService`, which gives access to the record’s timestamp, the current watermark, and which can register timers,
+- The current key (only available in `processElement()`), and
+- A method to apply a function the keyed state of each registered key (only available in `processBroadcastElement()`)
+
+The `KeyedBroadcastProcessFunction` has full access to Flink state and time features just like any other ProcessFunction and hence can be used to implement sophisticated application logic. Broadcast state was designed to be a versatile feature that adapts to different scenarios and use cases. Although we only discussed a fairly simple and restricted application, you can use broadcast state in many ways to implement the requirements of your application.
+
+## Conclusion
+
+In this blog post, we walked you through an example application to explain what Apache Flink’s broadcast state is and how it can be used to evaluate dynamic patterns on event streams. We’ve also discussed the API and showed the source code of our example application.
+
+We invite you to check the [documentation]({{< param DocsBaseUrl >}}flink-docs-stable/dev/stream/state/broadcast_state.html) of this feature and provide feedback or suggestions for further improvements through our [mailing list](http://mail-archives.apache.org/mod_mbox/flink-community/).
diff --git a/docs/content.tr/posts/2019-07-02-release-1.8.1.md b/docs/content.tr/posts/2019-07-02-release-1.8.1.md
new file mode 100644
index 0000000000..39cd797504
--- /dev/null
+++ b/docs/content.tr/posts/2019-07-02-release-1.8.1.md
@@ -0,0 +1,152 @@
+---
+authors:
+- jincheng: null
+ name: Jincheng Sun
+ twitter: sunjincheng121
+date: "2019-07-02T12:00:00Z"
+title: Apache Flink 1.8.1 Released
+aliases:
+- /news/2019/07/02/release-1.8.1.html
+---
+
+The Apache Flink community released the first bugfix version of the Apache Flink 1.8 series.
+
+This release includes more than 40 fixes and minor improvements for Flink 1.8.1. The list below includes a detailed list of all improvements, sub-tasks and bug fixes.
+
+We highly recommend all users to upgrade to Flink 1.8.1.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.8.1
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.8.1
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.8.1
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-10921 ] - Prioritize shard consumers in Kinesis Consumer by event time
+
+[FLINK-12617 ] - StandaloneJobClusterEntrypoint should default to random JobID for non-HA setups
+
+
+
+ Bug
+
+
+[FLINK-9445 ] - scala-shell uses plain java command
+
+[FLINK-10455 ] - Potential Kafka producer leak in case of failures
+
+[FLINK-10941 ] - Slots prematurely released which still contain unconsumed data
+
+[FLINK-11059 ] - JobMaster may continue using an invalid slot if releasing idle slot meet a timeout
+
+[FLINK-11107 ] - Avoid memory stateBackend to create arbitrary folders under HA path when no checkpoint path configured
+
+[FLINK-11897 ] - ExecutionGraphSuspendTest does not wait for all tasks to be submitted
+
+[FLINK-11915 ] - DataInputViewStream skip returns wrong value
+
+[FLINK-11987 ] - Kafka producer occasionally throws NullpointerException
+
+[FLINK-12009 ] - Wrong check message about heartbeat interval for HeartbeatServices
+
+[FLINK-12042 ] - RocksDBStateBackend mistakenly uses default filesystem
+
+[FLINK-12112 ] - AbstractTaskManagerProcessFailureRecoveryTest process output logging does not work properly
+
+[FLINK-12132 ] - The example in /docs/ops/deployment/yarn_setup.md should be updated due to the change FLINK-2021
+
+[FLINK-12184 ] - HistoryServerArchiveFetcher isn't compatible with old version
+
+[FLINK-12219 ] - Yarn application can't stop when flink job failed in per-job yarn cluster mode
+
+[FLINK-12247 ] - fix NPE when writing an archive file to a FileSystem
+
+[FLINK-12260 ] - Slot allocation failure by taskmanager registration timeout and race
+
+[FLINK-12296 ] - Data loss silently in RocksDBStateBackend when more than one operator(has states) chained in a single task
+
+[FLINK-12297 ] - Make ClosureCleaner recursive
+
+[FLINK-12301 ] - Scala value classes inside case classes cannot be serialized anymore in Flink 1.8.0
+
+[FLINK-12342 ] - Yarn Resource Manager Acquires Too Many Containers
+
+[FLINK-12375 ] - flink-container job jar does not have read permissions
+
+[FLINK-12416 ] - Docker build script fails on symlink creation ln -s
+
+[FLINK-12544 ] - Deadlock while releasing memory and requesting segment concurrent in SpillableSubpartition
+
+[FLINK-12547 ] - Deadlock when the task thread downloads jars using BlobClient
+
+[FLINK-12646 ] - Use reserved IP as unrouteable IP in RestClientTest
+
+[FLINK-12688 ] - Make serializer lazy initialization thread safe in StateDescriptor
+
+[FLINK-12740 ] - SpillableSubpartitionTest deadlocks on Travis
+
+[FLINK-12835 ] - Time conversion is wrong in ManualClock
+
+[FLINK-12863 ] - Race condition between slot offerings and AllocatedSlotReport
+
+[FLINK-12865 ] - State inconsistency between RM and TM on the slot status
+
+[FLINK-12871 ] - Wrong SSL setup examples in docs
+
+[FLINK-12895 ] - TaskManagerProcessFailureBatchRecoveryITCase.testTaskManagerProcessFailure failed on travis
+
+[FLINK-12896 ] - TaskCheckpointStatisticDetailsHandler uses wrong value for JobID when archiving
+
+
+
+ Improvement
+
+
+[FLINK-11126 ] - Filter out AMRMToken in the TaskManager credentials
+
+[FLINK-12137 ] - Add more proper explanation on flink streaming connectors
+
+[FLINK-12169 ] - Improve Javadoc of MessageAcknowledgingSourceBase
+
+[FLINK-12378 ] - Consolidate FileSystem Documentation
+
+[FLINK-12391 ] - Add timeout to transfer.sh
+
+[FLINK-12539 ] - StreamingFileSink: Make the class extendable to customize for different usecases
+
+
+
+ Test
+
+
+[FLINK-12350 ] - RocksDBStateBackendTest doesn't cover the incremental checkpoint code path
+
+
+
+ Task
+
+
+[FLINK-12460 ] - Change taskmanager.tmp.dirs to io.tmp.dirs in configuration docs
+
+
+
\ No newline at end of file
diff --git a/docs/content.tr/posts/2019-07-23-flink-network-stack-2.md b/docs/content.tr/posts/2019-07-23-flink-network-stack-2.md
new file mode 100644
index 0000000000..eb60192eb4
--- /dev/null
+++ b/docs/content.tr/posts/2019-07-23-flink-network-stack-2.md
@@ -0,0 +1,315 @@
+---
+authors:
+- Nico: null
+ name: Nico Kruber
+- Piotr: null
+ name: Piotr Nowojski
+date: "2019-07-23T15:30:00Z"
+excerpt: In a previous blog post, we presented how Flink’s network stack works from
+ the high-level abstractions to the low-level details. This second post discusses
+ monitoring network-related metrics to identify backpressure or bottlenecks in throughput
+ and latency.
+title: 'Flink Network Stack Vol. 2: Monitoring, Metrics, and that Backpressure Thing'
+aliases:
+- /2019/07/23/flink-network-stack-2.html
+---
+
+
+
+In a [previous blog post](/2019/06/05/flink-network-stack.html), we presented how Flink’s network stack works from the high-level abstractions to the low-level details. This second blog post in the series of network stack posts extends on this knowledge and discusses monitoring network-related metrics to identify effects such as backpressure or bottlenecks in throughput and latency. Although this post briefly covers what to do with backpressure, the topic of tuning the network stack will be further examined in a future post. If you are unfamiliar with the network stack we highly recommend reading the [network stack deep-dive](/2019/06/05/flink-network-stack.html) first and then continuing here.
+
+## Monitoring
+
+Probably the most important part of network monitoring is [monitoring backpressure]({{< param DocsBaseUrl >}}flink-docs-release-1.8/monitoring/back_pressure.html), a situation where a system is receiving data at a higher rate than it can process¹. Such behaviour will result in the sender being backpressured and may be caused by two things:
+
+* The receiver is slow.
+ This can happen because the receiver is backpressured itself, is unable to keep processing at the same rate as the sender, or is temporarily blocked by garbage collection, lack of system resources, or I/O.
+
+ * The network channel is slow.
+ Even though in such case the receiver is not (directly) involved, we call the sender backpressured due to a potential oversubscription on network bandwidth shared by all subtasks running on the same machine. Beware that, in addition to Flink’s network stack, there may be more network users, such as sources and sinks, distributed file systems (checkpointing, network-attached storage), logging, and metrics. A previous [capacity planning blog post](https://www.ververica.com/blog/how-to-size-your-apache-flink-cluster-general-guidelines) provides some more insights.
+
+1 In case you are unfamiliar with backpressure and how it interacts with Flink, we recommend reading through [this blog post on backpressure](https://www.ververica.com/blog/how-flink-handles-backpressure) from 2015.
+
+
+
+If backpressure occurs, it will bubble upstream and eventually reach your sources and slow them down. This is not a bad thing per-se and merely states that you lack resources for the current load. However, you may want to improve your job so that it can cope with higher loads without using more resources. In order to do so, you need to find (1) where (at which task/operator) the bottleneck is and (2) what is causing it. Flink offers two mechanisms for identifying where the bottleneck is:
+
+ * directly via Flink’s web UI and its backpressure monitor, or
+ * indirectly through some of the network metrics.
+
+Flink’s web UI is likely the first entry point for a quick troubleshooting but has some disadvantages that we will explain below. On the other hand, Flink’s network metrics are better suited for continuous monitoring and reasoning about the exact nature of the bottleneck causing backpressure. We will cover both in the sections below. In both cases, you need to identify the origin of backpressure from the sources to the sinks. Your starting point for the current and future investigations will most likely be the operator after the last one that is experiencing backpressure. This specific operator is also highly likely to cause the backpressure in the first place.
+
+
+### Backpressure Monitor
+
+The [backpressure monitor]({{< param DocsBaseUrl >}}flink-docs-release-1.8/monitoring/back_pressure.html) is only exposed via Flink’s web UI². Since it's an active component that is only triggered on request, it is currently not available via metrics. The backpressure monitor samples the running tasks' threads on all TaskManagers via `Thread.getStackTrace()` and computes the number of samples where tasks were blocked on a buffer request. These tasks were either unable to send network buffers at the rate they were produced, or the downstream task(s) were slow at processing them and gave no credits for sending. The backpressure monitor will show the ratio of blocked to total requests. Since some backpressure is considered normal / temporary, it will show a status of
+
+* OK for `ratio ≤ 0.10`,
+* LOW for `0.10 < Ratio ≤ 0.5`, and
+* HIGH for `0.5 < Ratio ≤ 1`.
+
+Although you can tune things like the refresh-interval, the number of samples, or the delay between samples, normally, you would not need to touch these since the defaults already give good-enough results.
+
+
+
+
+
+2 You may also access the backpressure monitor via the REST API: `/jobs/:jobid/vertices/:vertexid/backpressure`
+
+
+
+The backpressure monitor can help you find where (at which task/operator) backpressure originates from. However, it does not support you in further reasoning about the causes of it. Additionally, for larger jobs or higher parallelism, the backpressure monitor becomes too crowded to use and may also take some time to gather all information from all TaskManagers. Please also note that sampling may affect your running job’s performance.
+
+## Network Metrics
+
+[Network]({{< param DocsBaseUrl >}}flink-docs-release-1.8/monitoring/metrics.html#network) and [task I/O]({{< param DocsBaseUrl >}}flink-docs-release-1.8/monitoring/metrics.html#io) metrics are more lightweight than the backpressure monitor and are continuously published for each running job. We can leverage those and get even more insights, not only for backpressure monitoring. The most relevant metrics for users are:
+
+
+* **up to Flink 1.8: ** `outPoolUsage`, `inPoolUsage`
+ An estimate on the ratio of buffers used vs. buffers available in the respective local buffer pools.
+ While interpreting `inPoolUsage` in Flink 1.5 - 1.8 with credit-based flow control, please note that this only relates to floating buffers (exclusive buffers are not part of the pool).
+
+* **Flink 1.9 and above: ** `outPoolUsage`, `inPoolUsage`, `floatingBuffersUsage`, `exclusiveBuffersUsage`
+ An estimate on the ratio of buffers used vs. buffers available in the respective local buffer pools.
+ Starting with Flink 1.9, `inPoolUsage` is the sum of `floatingBuffersUsage` and `exclusiveBuffersUsage`.
+
+* `numRecordsOut`, `numRecordsIn`
+ Each metric comes with two scopes: one scoped to the operator and one scoped to the subtask. For network monitoring, the subtask-scoped metric is relevant and shows the total number of records it has sent/received. You may need to further look into these figures to extract the number of records within a certain time span or use the equivalent `…PerSecond` metrics.
+
+* `numBytesOut`, `numBytesInLocal`, `numBytesInRemote`
+ The total number of bytes this subtask has emitted or read from a local/remote source. These are also available as meters via `…PerSecond` metrics.
+
+* `numBuffersOut`, `numBuffersInLocal`, `numBuffersInRemote`
+ Similar to `numBytes…` but counting the number of network buffers.
+
+
+ Warning
+For the sake of completeness and since they have been used in the past, we will briefly look at the `outputQueueLength` and `inputQueueLength` metrics. These are somewhat similar to the `[out,in]PoolUsage` metrics but show the number of buffers sitting in a sender subtask’s output queues and in a receiver subtask’s input queues, respectively. Reasoning about absolute numbers of buffers, however, is difficult and there is also a special subtlety with local channels: since a local input channel does not have its own queue (it works with the output queue directly), its value will always be `0` for that channel (see [FLINK-12576](https://issues.apache.org/jira/browse/FLINK-12576)) and for the case where you only have local input channels, then `inputQueueLength = 0`.
+
+Overall, **we discourage the use of** `outputQueueLength` **and** `inputQueueLength` because their interpretation highly depends on the current parallelism of the operator and the configured numbers of exclusive and floating buffers. Instead, we recommend using the various `*PoolUsage` metrics which even reveal more detailed insight.
+
+
+
+
+ Note
+ If you reason about buffer usage, please keep the following in mind:
+
+* Any outgoing channel which has been used at least once will always occupy one buffer (since Flink 1.5).
+ * **up to Flink 1.8: ** This buffer (even if empty!) was always counted as a backlog of 1 and thus receivers tried to reserve a floating buffer for it.
+ * **Flink 1.9 and above: ** A buffer is only counted in the backlog if it is ready for consumption, i.e. it is full or was flushed (see FLINK-11082)
+* The receiver will only release a received buffer after deserialising the last record in it.
+
+
+The following sections make use of and combine these metrics to reason about backpressure and resource usage / efficiency with respect to throughput. A separate section will detail latency related metrics.
+
+
+### Backpressure
+
+Backpressure may be indicated by two different sets of metrics: (local) buffer pool usages as well as input/output queue lengths. They provide a different level of granularity but, unfortunately, none of these are exhaustive and there is room for interpretation. Because of the inherent problems with interpreting these queue lengths we will focus on the usage of input and output pools below which also provides more detail.
+
+* **If a subtask’s** `outPoolUsage` **is 100%**, it is backpressured. Whether the subtask is already blocking or still writing records into network buffers depends on how full the buffers are, that the `RecordWriters` are currently writing into.
+ This is different to what the backpressure monitor is showing!
+
+* An `inPoolUsage` of 100% means that all floating buffers are assigned to channels and eventually backpressure will be exercised upstream. These floating buffers are in either of the following conditions: they are reserved for future use on a channel due to an exclusive buffer being utilised (remote input channels always try to maintain `#exclusive buffers` credits), they are reserved for a sender’s backlog and wait for data, they may contain data and are enqueued in an input channel, or they may contain data and are being read by the receiver’s subtask (one record at a time).
+
+* **up to Flink 1.8: ** Due to [FLINK-11082](https://issues.apache.org/jira/browse/FLINK-11082), an `inPoolUsage` of 100% is quite common even in normal situations.
+
+* **Flink 1.9 and above: ** If `inPoolUsage` is constantly around 100%, this is a strong indicator for exercising backpressure upstream.
+
+The following table summarises all combinations and their interpretation. Bear in mind, though, that backpressure may be minor or temporary (no need to look into it), on particular channels only, or caused by other JVM processes on a particular TaskManager, such as GC, synchronisation, I/O, resource shortage, instead of a specific subtask.
+
+
+
+
+
+ outPoolUsage
low
+ outPoolUsage
high
+
+
+ inPoolUsage
low
+
+
+
+
+ (backpressured, temporary situation: upstream is not backpressured yet or not anymore)
+
+
+
+ inPoolUsage
high
+ (Flink 1.9+ )
+
+ if all upstream tasks’outPoolUsage
are low:
+ (may eventually cause backpressure)
+
+
+ (backpressured by downstream task(s) or network, probably forwarding backpressure upstream)
+
+
+ if any upstream task’soutPoolUsage
is high:
+ (may exercise backpressure upstream and may be the source of backpressure)
+
+
+
+
+
+We may even reason more about the cause of backpressure by looking at the network metrics of the subtasks of two consecutive tasks:
+
+* If all subtasks of the receiver task have low `inPoolUsage` values and any upstream subtask’s `outPoolUsage` is high, then there may be a network bottleneck causing backpressure.
+Since network is a shared resource among all subtasks of a TaskManager, this may not directly originate from this subtask, but rather from various concurrent operations, e.g. checkpoints, other streams, external connections, or other TaskManagers/processes on the same machine.
+
+Backpressure can also be caused by all parallel instances of a task or by a single task instance. The first usually happens because the task is performing some time consuming operation that applies to all input partitions. The latter is usually the result of some kind of skew, either data skew or resource availability/allocation skew. In either case, you can find some hints on how to handle such situations in the [What to do with backpressure?](#span-classlabel-label-info-styledisplay-inline-blockspan-classglyphicon-glyphicon-info-sign-aria-hiddentruespan-what-to-do-with-backpressurespan) box below.
+
+
+###
Flink 1.9 and above
+{:.no_toc}
+
+* If `floatingBuffersUsage` is not 100%, it is unlikely that there is backpressure. If it is 100% and any upstream task is backpressured, it suggests that this input is exercising backpressure on either a single, some or all input channels. To differentiate between those three situations you can use `exclusiveBuffersUsage`:
+ * Assuming that `floatingBuffersUsage` is around 100%, the higher the `exclusiveBuffersUsage` the more input channels are backpressured. In an extreme case of `exclusiveBuffersUsage` being close to 100%, it means that all channels are backpressured.
+
+
+The relation between `exclusiveBuffersUsage`, `floatingBuffersUsage`, and the upstream tasks' `outPoolUsage` is summarised in the following table and extends on the table above with `inPoolUsage = floatingBuffersUsage + exclusiveBuffersUsage`:
+
+
+
+
+
+ exclusiveBuffersUsage
low
+ exclusiveBuffersUsage
high
+
+
+
+ floatingBuffersUsage
low +
+ all upstream outPoolUsage
low
+
+ -3
+
+
+
+ floatingBuffersUsage
low +
+ any upstream outPoolUsage
high
+
+
+ (potential network bottleneck)
+ -3
+
+
+
+ floatingBuffersUsage
high +
+ all upstream outPoolUsage
low
+
+
+ (backpressure eventually appears on only some of the input channels)
+
+
+ (backpressure eventually appears on most or all of the input channels)
+
+
+
+ floatingBuffersUsage
high +
+ any upstream outPoolUsage
high
+
+
+ (backpressure on only some of the input channels)
+
+
+ (backpressure on most or all of the input channels)
+
+
+
+
+
3 this should not happen
+
+
+
+
+### Resource Usage / Throughput
+
+Besides the obvious use of each individual metric mentioned above, there are also a few combinations providing useful insight into what is happening in the network stack:
+
+* Low throughput with frequent `outPoolUsage` values around 100% but low `inPoolUsage` on all receivers is an indicator that the round-trip-time of our credit-notification (depends on your network’s latency) is too high for the default number of exclusive buffers to make use of your bandwidth. Consider increasing the [buffers-per-channel]({{< param DocsBaseUrl >}}flink-docs-release-1.8/ops/config.html#taskmanager-network-memory-buffers-per-channel) parameter or try disabling credit-based flow control to verify.
+
+* Combining `numRecordsOut` and `numBytesOut` helps identifying average serialised record sizes which supports you in capacity planning for peak scenarios.
+
+* If you want to reason about buffer fill rates and the influence of the output flusher, you may combine `numBytesInRemote` with `numBuffersInRemote`. When tuning for throughput (and not latency!), low buffer fill rates may indicate reduced network efficiency. In such cases, consider increasing the buffer timeout.
+Please note that, as of Flink 1.8 and 1.9, `numBuffersOut` only increases for buffers getting full or for an event cutting off a buffer (e.g. a checkpoint barrier) and may lag behind. Please also note that reasoning about buffer fill rates on local channels is unnecessary since buffering is an optimisation technique for remote channels with limited effect on local channels.
+
+* You may also separate local from remote traffic using numBytesInLocal and numBytesInRemote but in most cases this is unnecessary.
+
+
+### What to do with Backpressure?
+{:.no_toc}
+
+Assuming that you identified where the source of backpressure — a bottleneck — is located, the next step is to analyse why this is happening. Below, we list some potential causes of backpressure from the more basic to the more complex ones. We recommend to check the basic causes first, before diving deeper on the more complex ones and potentially drawing false conclusions.
+
+Please also recall that backpressure might be temporary and the result of a load spike, checkpointing, or a job restart with a data backlog waiting to be processed. In that case, you can often just ignore it. Alternatively, keep in mind that the process of analysing and solving the issue can be affected by the intermittent nature of your bottleneck. Having said that, here are a couple of things to check.
+
+#### System Resources
+
+Firstly, you should check the incriminated machines’ basic resource usage like CPU, network, or disk I/O. If some resource is fully or heavily utilised you can do one of the following:
+
+1. Try to optimise your code. Code profilers are helpful in this case.
+2. Tune Flink for that specific resource.
+3. Scale out by increasing the parallelism and/or increasing the number of machines in the cluster.
+
+#### Garbage Collection
+
+Oftentimes, performance issues arise from long GC pauses. You can verify whether you are in such a situation by either printing debug GC logs (via -`XX:+PrintGCDetails`) or by using some memory/GC profilers. Since dealing with GC issues is highly application-dependent and independent of Flink, we will not go into details here ([Oracle's Garbage Collection Tuning Guide](https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html) or [Plumbr’s Java Garbage Collection handbook](https://plumbr.io/java-garbage-collection-handbook) seem like a good start).
+
+#### CPU/Thread Bottleneck
+
+Sometimes a CPU bottleneck might not be visible at first glance if one or a couple of threads are causing the CPU bottleneck while the CPU usage of the overall machine remains relatively low. For instance, a single CPU-bottlenecked thread on a 48-core machine would result in only 2% CPU use. Consider using code profilers for this as they can identify hot threads by showing each threads' CPU usage, for example.
+
+#### Thread Contention
+
+Similarly to the CPU/thread bottleneck issue above, a subtask may be bottlenecked due to high thread contention on shared resources. Again, CPU profilers are your best friend here! Consider looking for synchronisation overhead / lock contention in user code — although adding synchronisation in user code should be avoided and may even be dangerous! Also consider investigating shared system resources. The default JVM’s SSL implementation, for example, can become contented around the shared `/dev/urandom` resource.
+
+#### Load Imbalance
+
+If your bottleneck is caused by data skew, you can try to remove it or mitigate its impact by changing the data partitioning to separate heavy keys or by implementing local/pre-aggregation.
+
+
+This list is far from exhaustive. Generally, in order to reduce a bottleneck and thus backpressure, first analyse where it is happening and then find out why. The best place to start reasoning about the “why” is by checking what resources are fully utilised.
+
+
+### Latency Tracking
+
+Tracking latencies at the various locations they may occur is a topic of its own. In this section, we will focus on the time records wait inside Flink’s network stack — including the system’s network connections. In low throughput scenarios, these latencies are influenced directly by the output flusher via the buffer timeout parameter or indirectly by any application code latencies. When processing a record takes longer than expected or when (multiple) timers fire at the same time — and block the receiver from processing incoming records — the time inside the network stack for following records is extended dramatically. We highly recommend adding your own metrics to your Flink job for better latency tracking in your job’s components and a broader view on the cause of delays.
+
+Flink offers some support for [tracking the latency]({{< param DocsBaseUrl >}}flink-docs-release-1.8/monitoring/metrics.html#latency-tracking) of records passing through the system (outside of user code). However, this is disabled by default (see below why!) and must be enabled by setting a latency tracking interval either in Flink’s [configuration via `metrics.latency.interval`]({{< param DocsBaseUrl >}}flink-docs-release-1.8/ops/config.html#metrics-latency-interval) or via [ExecutionConfig#setLatencyTrackingInterval()]({{< param DocsBaseUrl >}}flink-docs-release-1.8/api/java/org/apache/flink/api/common/ExecutionConfig.html#setLatencyTrackingInterval-long-). Once enabled, Flink will collect latency histograms based on the [granularity defined via `metrics.latency.granularity`]({{< param DocsBaseUrl >}}flink-docs-release-1.8/ops/config.html#metrics-latency-granularity):
+
+* `single`: one histogram for each operator subtask
+* `operator` (default): one histogram for each combination of source task and operator subtask
+* `subtask`: one histogram for each combination of source subtask and operator subtask (quadratic in the parallelism!)
+
+These metrics are collected through special “latency markers”: each source subtask will periodically emit a special record containing the timestamp of its creation. The latency markers then flow alongside normal records while not overtaking them on the wire or inside a buffer queue. However, _a latency marker does not enter application logic_ and is overtaking records there. Latency markers therefore only measure the waiting time between the user code and not a full “end-to-end” latency. User code indirectly influences these waiting times, though!
+
+Since `LatencyMarkers` sit in network buffers just like normal records, they will also wait for the buffer to be full or flushed due to buffer timeouts. When a channel is on high load, there is no added latency by the network buffering data. However, as soon as one channel is under low load, records and latency markers will experience an expected average delay of at most `buffer_timeout / 2`. This delay will add to each network connection towards a subtask and should be taken into account when analysing a subtask’s latency metric.
+
+By looking at the exposed latency tracking metrics for each subtask, for example at the 95th percentile, you should nevertheless be able to identify subtasks which are adding substantially to the overall source-to-sink latency and continue with optimising there.
+
+
+ Note
+Flink's latency markers assume that the clocks on all machines in the cluster are in sync. We recommend setting up an automated clock synchronisation service (like NTP) to avoid false latency results.
+
+
+
+ Warning
+Enabling latency metrics can significantly impact the performance of the cluster (in particular for `subtask` granularity) due to the sheer amount of metrics being added as well as the use of histograms which are quite expensive to maintain. It is highly recommended to only use them for debugging purposes.
+
+
+
+## Conclusion
+
+In the previous sections we discussed how to monitor Flink's network stack which primarily involves identifying backpressure: where it occurs, where it originates from, and (potentially) why it occurs. This can be executed in two ways: for simple cases and debugging sessions by using the backpressure monitor; for continuous monitoring, more in-depth analysis, and less runtime overhead by using Flink’s task and network stack metrics. Backpressure can be caused by the network layer itself but, in most cases, is caused by some subtask under high load. These two scenarios can be distinguished from one another by analysing the metrics as described above. We also provided some hints at monitoring resource usage and tracking network latencies that may add up from sources to sinks.
+
+Stay tuned for the third blog post in the series of network stack posts that will focus on tuning techniques and anti-patterns to avoid.
+
+
diff --git a/docs/content.tr/posts/2019-08-22-release-1.9.0.md b/docs/content.tr/posts/2019-08-22-release-1.9.0.md
new file mode 100644
index 0000000000..961ad7b68a
--- /dev/null
+++ b/docs/content.tr/posts/2019-08-22-release-1.9.0.md
@@ -0,0 +1,360 @@
+---
+date: "2019-08-22T02:30:00Z"
+title: Apache Flink 1.9.0 Release Announcement
+aliases:
+- /news/2019/08/22/release-1.9.0.html
+---
+
+
+The Apache Flink community is proud to announce the release of Apache Flink
+1.9.0.
+
+The Apache Flink project's goal is to develop a stream processing system to
+unify and power many forms of real-time and offline data processing
+applications as well as event-driven applications. In this release, we have
+made a huge step forward in that effort, by integrating Flink’s stream and
+batch processing capabilities under a single, unified runtime.
+
+Significant features on this path are batch-style recovery for batch jobs and
+a preview of the new Blink-based query engine for Table API and SQL queries.
+We are also excited to announce the availability of the State Processor API,
+which is one of the most frequently requested features and enables users to
+read and write savepoints with Flink DataSet jobs. Finally, Flink 1.9 includes
+a reworked WebUI and previews of Flink’s new Python Table API and its
+integration with the Apache Hive ecosystem.
+
+This blog post describes all major new features and improvements, important
+changes to be aware of and what to expect moving forward. For more details,
+check the [complete release
+changelog](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12344601).
+
+The binary distribution and source artifacts for this release are now
+available via the [Downloads](https://flink.apache.org/downloads.html) page of
+the Flink project, along with the updated
+[documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.9/).
+Flink 1.9 is API-compatible with previous 1.x releases for APIs annotated with
+the `@Public` annotation.
+
+Please feel encouraged to download the release and share your thoughts with
+the community through the Flink [mailing
+lists](https://flink.apache.org/community.html#mailing-lists) or
+[JIRA](https://issues.apache.org/jira/projects/FLINK/summary). As always,
+feedback is very much appreciated!
+
+
+
+## New Features and Improvements
+
+
+### Fine-grained Batch Recovery (FLIP-1)
+
+The time to recover a batch (DataSet, Table API and SQL) job from a task
+failure was significantly reduced. Until Flink 1.9, task failures in batch
+jobs were recovered by canceling all tasks and restarting the whole job, i.e,
+the job was started from scratch and all progress was voided. With this
+release, Flink can be configured to limit the recovery to only those tasks
+that are in the same **failover region**. A failover region is the set of
+tasks that are connected via pipelined data exchanges. Hence, the
+batch-shuffle connections of a job define the boundaries of its failover
+regions. More details are available in
+[FLIP-1](https://cwiki.apache.org/confluence/display/FLINK/FLIP-1+%3A+Fine+Grained+Recovery+from+Task+Failures).
+
+
+To use this new failover strategy, you need to do the following
+settings:
+
+ * Make sure you have the entry `jobmanager.execution.failover-strategy:
+ region` in your `flink-conf.yaml`.
+
+**Note:** The configuration of the 1.9 distribution has that entry by default,
+ but when reusing a configuration file from previous setups, you have to add
+ it manually.
+
+Moreover, you need to set the `ExecutionMode` of batch jobs in the
+`ExecutionConfig` to `BATCH` to configure that data shuffles are not pipelined
+and jobs have more than one failover region.
+
+The "Region" failover strategy also improves the recovery of “embarrassingly
+parallel” streaming jobs, i.e., jobs without any shuffle like keyBy() or
+rebalance. When such a job is recovered, only the tasks of the affected
+pipeline (failover region) are restarted. For all other streaming jobs, the
+recovery behavior is the same as in prior Flink versions.
+
+
+### State Processor API (FLIP-43)
+
+Up to Flink 1.9, accessing the state of a job from the outside was limited to
+the (still) experimental [Queryable
+State]({{< param DocsBaseUrl >}}flink-docs-stable/dev/stream/state/queryable_state.html).
+This release introduces a new, powerful library to read, write and modify
+state snapshots using the batch DataSet API. In practice, this means:
+
+ * Flink job state can be bootstrapped by reading data from external systems,
+ such as external databases, and converting it into a savepoint.
+ * State in savepoints can be queried using any of Flink’s batch APIs
+ (DataSet, Table, SQL), for example to analyze relevant state patterns or
+ check for discrepancies in state that can support application auditing or
+ troubleshooting.
+ * The schema of state in savepoints can be migrated offline, compared to the
+ previous approach requiring online migration on schema access.
+ * Invalid data in savepoints can be identified and corrected.
+
+The new State Processor API covers all variations of snapshots: savepoints,
+full checkpoints and incremental checkpoints. More details are available in
+[FLIP-43](https://cwiki.apache.org/confluence/display/FLINK/FLIP-43%3A+State+Processor+API)
+
+
+### Stop-with-Savepoint (FLIP-34)
+
+[Cancelling with a
+savepoint]({{< param DocsBaseUrl >}}flink-docs-stable/ops/state/savepoints.html#operations)
+is a common operation for stopping/restarting, forking or updating Flink jobs.
+However, the existing implementation did not guarantee output persistence to
+external storage systems for exactly-once sinks. To improve the end-to-end
+semantics when stopping a job, Flink 1.9 introduces a new `SUSPEND` mode to
+stop a job with a savepoint that is consistent with the emitted data.
+You can suspend a job with Flink’s CLI client as follows:
+
+```
+bin/flink stop -p [:targetDirectory] :jobId
+```
+
+The final job state is set to `FINISHED` on success, allowing
+users to detect failures of the requested operation.
+
+More details are available in
+[FLIP-34](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=103090212)
+
+
+
+### Flink WebUI Rework
+
+After a
+[discussion](http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Change-underlying-Frontend-Architecture-for-Flink-Web-Dashboard-td24902.html)
+about modernizing the internals of Flink’s WebUI, this component was
+reconstructed using the latest stable version of Angular — basically, a bump
+from Angular 1.x to 7.x. The redesigned version is the default in 1.9.0,
+however there is a link to switch to the old WebUI.
+
+
+
+**Note:** Moving forward, feature parity for the old version of the WebUI
+will not be guaranteed.
+
+
+### Preview of the new Blink SQL Query Processor
+
+Following the [donation of
+Blink](/news/2019/02/13/unified-batch-streaming-blink.html) to
+Apache Flink, the community worked on integrating Blink’s query optimizer and
+runtime for the Table API and SQL. As a first step, we refactored the
+monolithic `flink-table` module into smaller modules
+([FLIP-32](https://cwiki.apache.org/confluence/display/FLINK/FLIP-32%3A+Restructure+flink-table+for+future+contributions)).
+This resulted in a clear separation of and well-defined interfaces between the
+Java and Scala API modules and the optimizer and runtime modules.
+
+
+
+Next, we extended Blink’s planner to implement the new optimizer interface
+such that there are now two pluggable query processors to execute Table API
+and SQL statements: the pre-1.9 Flink processor and the new Blink-based query
+processor. The Blink-based query processor offers better SQL coverage (full TPC-H
+coverage in 1.9, TPC-DS coverage is planned for the next release) and improved
+performance for batch queries as the result of more extensive query
+optimization (cost-based plan selection and more optimization rules), improved
+code-generation, and tuned operator implementations.
+The Blink-based query processor also provides a more powerful streaming runner,
+with some new features (e.g. dimension table join, TopN, deduplication) and
+optimizations to solve data-skew in aggregation and more useful built-in
+functions.
+
+**Note:** The semantics and set of supported operations of the query
+processors are mostly, but not fully aligned.
+
+However, the integration of Blink’s query processor is not fully completed
+yet. Therefore, the pre-1.9 Flink processor is still the default processor in
+Flink 1.9 and recommended for production settings. You can enable the Blink
+processor by configuring it via the `EnvironmentSettings` when creating a
+`TableEnvironment`. The selected processor must be on the classpath of the
+executing Java process. For cluster setups, both query processors are
+automatically loaded with the default configuration. When running a query from
+your IDE you need to explicitly [add a planner
+dependency]({{< param DocsBaseUrl >}}flink-docs-release-1.9/dev/table/#table-program-dependencies)
+to your project.
+
+
+#### **Other Improvements to the Table API and SQL**
+
+Besides the exciting progress around the Blink planner, the community worked
+on a whole set of other improvements to these interfaces, including:
+
+ * **Scala-free Table API and SQL for Java users
+ ([FLIP-32](https://cwiki.apache.org/confluence/display/FLINK/FLIP-32%3A+Restructure+flink-table+for+future+contributions))**
+
+ As part of the refactoring and splitting of the flink-table module, two
+ separate API modules for Java and Scala were created. For Scala users,
+ nothing really changes, but Java users can use the Table API and/or SQL now
+ without pulling in a Scala dependency.
+
+ * **Rework of the Table API Type System**
+ **([FLIP-37](https://cwiki.apache.org/confluence/display/FLINK/FLIP-37%3A+Rework+of+the+Table+API+Type+System))**
+
+ The community implemented a [new data type
+ system]({{< param DocsBaseUrl >}}flink-docs-release-1.9/dev/table/types.html#data-types)
+ to detach the Table API from Flink’s
+ [TypeInformation]({{< param DocsBaseUrl >}}flink-docs-release-1.9/dev/types_serialization.html#flinks-typeinformation-class)
+ class and improve its compliance with the SQL standard. This is still a
+ work in progress and expected to be completed in the next release. In
+ Flink 1.9, UDFs are―among other things―not ported to the new type system
+ yet.
+
+ * **Multi-column and Multi-row Transformations for Table API**
+ **([FLIP-29](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=97552739))**
+
+ The functionality of the Table API was extended with a set of
+ transformations that support multi-row and/or multi-column inputs and
+ outputs. These transformations significantly ease the implementation of
+ processing logic that would be cumbersome to implement with relational
+ operators.
+
+ * **New, Unified Catalog APIs**
+ **([FLIP-30](https://cwiki.apache.org/confluence/display/FLINK/FLIP-30%3A+Unified+Catalog+APIs))**
+
+ We reworked the catalog APIs to store metadata and unified the handling of
+ internal and external catalogs. This effort was mainly initiated as a
+ prerequisite for the Hive integration (see below), but improves the overall
+ convenience of managing catalog metadata in Flink. Besides improving the
+ catalog interfaces, we also extended their functionality. Previously table
+ definitions for Table API or SQL queries were volatile. With Flink 1.9, the
+ metadata of tables which are registered with a SQL DDL statement can be
+ persisted in a catalog. This means you can add a table that is backed by a
+ Kafka topic to a Metastore catalog and from then on query this table
+ whenever your catalog is connected to Metastore.
+
+ * **DDL Support in the SQL API
+ ([FLINK-10232](https://issues.apache.org/jira/browse/FLINK-10232))**
+
+ Up to this point, Flink SQL only supported DML statements (e.g. `SELECT`,
+ `INSERT`). External tables (table sources and sinks) had to be registered
+ via Java/Scala code or configuration files. For 1.9, we added support for
+ SQL DDL statements to register and remove tables and views (`CREATE TABLE,
+ DROP TABLE)`. However, we did not add
+ stream-specific syntax extensions to define timestamp extraction and
+ watermark generation, yet. Full support for streaming use cases is planned
+ for the next release.
+
+
+### Preview of Full Hive Integration (FLINK-10556)
+
+Apache Hive is widely used in Hadoop’s ecosystem to store and query large
+amounts of structured data. Besides being a query processor, Hive features a
+catalog called Metastore to manage and organize large datasets. A common
+integration point for query processors is to integrate with Hive’s Metastore
+in order to be able to tap into the data managed by Hive.
+
+Recently, the community started implementing an external catalog for Flink’s
+Table API and SQL that connects to Hive’s Metastore. In Flink 1.9, users will
+be able to query and process all data that is stored in Hive. As described
+earlier, you will also be able to persist metadata of Flink tables in Metastore.
+Moreover, the Hive integration includes support to use Hive’s UDFs in Flink
+Table API or SQL queries. More details are available in
+[FLINK-10556](https://issues.apache.org/jira/browse/FLINK-10556).
+
+While, previously, table definitions for Table API or SQL queries were always
+volatile, the new catalog connector additionally allows persisting a table in
+Metastore that is created with a SQL DDL statement (see above). This means
+that you connect to Metastore and register a table that is, for example,
+backed by a Kafka topic. From now on, you can query that table whenever your
+catalog is connected to Metastore.
+
+Please note that the Hive support in Flink 1.9 is experimental. We are
+planning to stabilize these features for the next release and are looking
+forward to your feedback.
+
+
+### Preview of the new Python Table API (FLIP-38)
+
+This release also introduces a first version of a Python Table API
+([FLIP-38](https://cwiki.apache.org/confluence/display/FLINK/FLIP-38%3A+Python+Table+API)).
+This marks the start towards our goal of bringing
+full-fledged Python support to Flink. The feature was designed as a slim
+Python API wrapper around the Table API, basically translating Python Table
+API method calls into Java Table API calls. In the initial version that ships
+with Flink 1.9, the Python Table API does not support UDFs yet, but just
+standard relational operations. Support for UDFs implemented in Python is on
+the roadmap for future releases.
+
+If you’d like to try the new Python API, you have to manually [install
+PyFlink]({{< param DocsBaseUrl >}}flink-docs-release-1.9/flinkDev/building.html#build-pyflink).
+From there, you can have a look at [this
+walkthrough]({{< param DocsBaseUrl >}}flink-docs-release-1.9/tutorials/python_table_api.html)
+or explore it on your own. The [community is currently
+working](http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Publish-the-PyFlink-into-PyPI-td31201.html)
+on preparing a `pyflink` Python package that will be made available for
+installation via `pip`.
+
+
+## Important Changes
+
+ * The Table API and SQL are now part of the default configuration of the
+ Flink distribution. Before, the Table API and SQL had to be enabled by
+ moving the corresponding JAR file from ./opt to ./lib.
+ * The machine learning library (flink-ml) has been removed in preparation for
+ [FLIP-39](https://docs.google.com/document/d/1StObo1DLp8iiy0rbukx8kwAJb0BwDZrQrMWub3DzsEo/edit).
+ * The old DataSet and DataStream Python APIs have been removed in favor of
+ [FLIP-38](https://cwiki.apache.org/confluence/display/FLINK/FLIP-38%3A+Python+Table+API).
+ * Flink can be compiled and run on Java 9. Note that certain components
+ interacting with external systems (connectors, filesystems, reporters) may
+ not work since the respective projects may have skipped Java 9 support.
+
+
+## Release Notes
+
+Please review the [release
+notes]({{< param DocsBaseUrl >}}flink-docs-release-1.9/release-notes/flink-1.9.html)
+for a more detailed list of changes and new features if you plan to upgrade
+your Flink setup to Flink 1.9.0.
+
+
+## List of Contributors
+
+We would like to thank all contributors who have made this release possible:
+
+Abdul Qadeer (abqadeer), Aitozi, Alberto Romero, Aleksey Pak, Alexander
+Fedulov, Alice Yan, Aljoscha Krettek, Aloys, Andrew Duffy, Andrey Zagrebin,
+Ankur, Artsem Semianenka, Benchao Li, Biao Liu, Bo WANG, Bowen L, Chesnay
+Schepler, Clark Yang, Congxian Qiu, Cristian, Danny Chan, David Moravek, Dawid
+Wysakowicz, Dian Fu, EronWright, Fabian Hueske, Fabio Lombardelli, Fokko
+Driesprong, Gao Yun, Gary Yao, Gen Luo, Gyula Fora, Hequn Cheng,
+Hongtao Zhang, Huang Xingbo, HuangXingBo, Hugo Da Cruz Louro, Humberto
+Rodríguez A, Hwanju Kim, Igal Shilman, Jamie Grier, Jark Wu, Jason, Jasper
+Yue, Jeff Zhang, Jiangjie (Becket) Qin, Jiezhi.G, Jincheng Sun, Jing Zhang,
+Jingsong Lee, Juan Gentile, Jungtaek Lim, Kailash Dayanand, Kevin
+Bohinski, Konstantin Knauf, Konstantinos Papadopoulos, Kostas Kloudas, Kurt
+Young, Lakshmi, Lakshmi Gururaja Rao, Leeviiii, LouisXu, Maximilian Michels,
+Nico Kruber, Niels Basjes, Paul Lam, PengFei Li, Peter Huang, Pierre Zemb,
+Piotr Nowojski, Piyush Narang, Richard Deurwaarder, Robert Metzger, Robert
+Stoll, Romano Vacca, Rong Rong, Rui Li, Ryantaocer, Scott Mitchell, Seth
+Wiesman, Shannon Carey, Shimin Yang, Stefan Richter, Stephan Ewen, Stephen
+Connolly, Steven Wu, SuXingLee, TANG Wen-hui, Thomas Weise, Till Rohrmann,
+Timo Walther, Tom Goong, TsReaper, Tzu-Li (Gordon) Tai, Ufuk Celebi,
+Victor Wong, WangHengwei, Wei Zhong, WeiZhong94, Xintong Song, Xpray,
+XuQianJin-Stars, Xuefu Zhang, Xupingyong, Yangze Guo, Yu Li, Yun Gao, Yun
+Tang, Zhanchun Zhang, Zhenghua Gao, Zhijiang, Zhu Zhu, Zili
+Chen, aloys, arganzheng, azagrebin, bd2019us, beyond1920, biao.liub,
+blueszheng, boshu Zheng, chenqi, chummyhe89, chunpinghe, dcadmin,
+dianfu, godfrey he, guanghui01.rong, hehuiyuan, hello, hequn8128,
+jackyyin, joongkeun.yang, klion26, lamber-ken, leesf, liguowei,
+lincoln-lil, liyafan82, luoqi, mans2singh, maqingxiang, maxin, mjl, okidogi,
+ozan, potseluev, qiangsi.lq, qiaoran, robbinli, shaoxuan-wang, shengqian.zhou,
+shenlang.sl, shuai-xu, sunhaibotb, tianchen, tianchen92,
+tison, tom_gong, vinoyang, vthinkxie, wanggeng3, wenhuitang, winifredtamg,
+xl38154, xuyang1706, yangfei5, yanghua, yuzhao.cyz,
+zhangxin516, zhangxinxing, zhaofaxian, zhijiang, zjuwangg, 林小铂,
+黄培松, 时无两丶.
diff --git a/docs/content.tr/posts/2019-09-05-community-update.md b/docs/content.tr/posts/2019-09-05-community-update.md
new file mode 100644
index 0000000000..ea9865d62a
--- /dev/null
+++ b/docs/content.tr/posts/2019-09-05-community-update.md
@@ -0,0 +1,141 @@
+---
+authors:
+- morsapaes: null
+ name: Marta Paes
+ twitter: morsapaes
+date: "2019-09-05T12:00:00Z"
+excerpt: This has been an exciting, fast-paced year for the Apache Flink community.
+ But with over 10k messages across the mailing lists, 3k Jira tickets and 2k pull
+ requests, it is not easy to keep up with the latest state of the project. Plus everything
+ happening around it. With that in mind, we want to bring back regular community
+ updates to the Flink blog.
+title: Flink Community Update - September'19
+aliases:
+- /news/2019/09/10/community-update.html
+---
+
+This has been an exciting, fast-paced year for the Apache Flink community. But with over 10k messages across the mailing lists, 3k Jira tickets and 2k pull requests, it is not easy to keep up with the latest state of the project. Plus everything happening around it. With that in mind, we want to bring back regular community updates to the Flink blog.
+
+The first post in the series takes you on an little detour across the year, to freshen up and make sure you're all up to date.
+
+# The Year (so far) in Flink
+
+Two major versions were released this year: [Flink 1.8](https://flink.apache.org/news/2019/04/09/release-1.8.0.html) and [Flink 1.9](https://flink.apache.org/news/2019/08/22/release-1.9.0.html); paving the way for the goal of making Flink the first framework to seamlessly support stream and batch processing with a single, unified runtime. The [contribution of Blink](https://flink.apache.org/news/2019/02/13/unified-batch-streaming-blink.html) to Apache Flink was key in accelerating the path to this vision and reduced the waiting time for long-pending user requests — such as Hive integration, (better) Python support, the rework of Flink's Machine Learning library and...fine-grained failure recovery ([FLIP-1](https://cwiki.apache.org/confluence/display/FLINK/FLIP-1+%3A+Fine+Grained+Recovery+from+Task+Failures)).
+
+The 1.9 release was the result of the **biggest community effort the project has experienced so far**, with the number of contributors soaring to 190 (see [The Bigger Picture](#the-bigger-picture)). For a quick overview of the upcoming work for Flink 1.10 (and beyond), have a look at the updated [roadmap](https://flink.apache.org/roadmap.html)!
+
+## Integration of the Chinese-speaking community
+
+As the number of Chinese-speaking Flink users rapidly grows, the community is working on translating resources and creating dedicated spaces for discussion to invite and include these users in the wider Flink community. Part of the ongoing work is described in [FLIP-35](https://cwiki.apache.org/confluence/display/FLINK/FLIP-35%3A+Support+Chinese+Documents+and+Website) and has resulted in:
+
+* A new user mailing list (user-zh@f.a.o) dedicated to Chinese-speakers.
+
+* A Chinese translation of the Apache Flink [website](https://flink.apache.org/zh/) and [documentation]({{< param DocsBaseUrl >}}flink-docs-master/zh/).
+
+* Multiple meetups organized all over China, with the biggest one reaching a whopping number of 500+ participants. Some of these meetups were also organized in collaboration with communities from other projects, like Apache Pulsar and Apache Kafka.
+
+
+
+
+
+In case you're interested in knowing more about this work in progress, Robert Metzger and Fabian Hueske will be diving into "Inviting Apache Flink's Chinese User Community" at the upcoming ApacheCon Europe 2019 (see [Upcoming Flink Community Events](#upcoming-flink-community-events)).
+
+## Improving Flink's Documentation
+
+Besides the translation effort, the community has also been working quite hard on a **Flink docs overhaul**. The main goals are to:
+
+ * Organize and clean-up the structure of the docs;
+
+ * Align the content with the overall direction of the project;
+
+ * Improve the _getting-started_ material and make the content more accessible to different levels of Flink experience.
+
+Given that there has been some confusion in the past regarding unclear definition of core Flink concepts, one of the first completed efforts was to introduce a [Glossary]({{< param DocsBaseUrl >}}flink-docs-release-1.9/concepts/glossary.html#glossary) in the docs. To get up to speed with the roadmap for the remainder efforts, you can refer to [FLIP-42](https://cwiki.apache.org/confluence/display/FLINK/FLIP-42%3A+Rework+Flink+Documentation) and the corresponding [umbrella Jira ticket](https://issues.apache.org/jira/browse/FLINK-12639).
+
+## Adjusting the Contribution Process and Experience
+
+The [guidelines](https://flink.apache.org/contributing/how-to-contribute.html) to contribute to Apache Flink have been reworked on the website, in an effort to lower the entry barrier for new contributors and reduce the overall friction in the contribution process. In addition, the Flink community discussed and adopted [bylaws](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026) to help the community collaborate and coordinate more smoothly.
+
+For code contributors, a [Code Style and Quality Guide](https://flink.apache.org/contributing/code-style-and-quality-preamble.html) that captures the expected standards for contributions was also added to the "Contributing" section of the Flink website.
+
+It's important to stress that **contributions are not restricted to code**. Non-code contributions such as mailing list support, documentation work or organization of community events are equally as important to the development of the project and highly encouraged.
+
+## New Committers and PMC Members
+
+The Apache Flink community has welcomed **5 new Committers** and **4 PMC (Project Management Committee) Members** in 2019, so far:
+
+### New PMC Members
+ Jincheng Sun, Kete (Kurt) Young, Kostas Kloudas, Thomas Weise
+
+### New Committers
+ Andrey Zagrebin, Hequn, Jiangjie (Becket) Qin, Rong Rong, Zhijiang Wang
+
+Congratulations and thank you for your hardworking commitment to Flink!
+
+# The Bigger Picture
+
+Flink continues to push the boundaries of (stream) data processing, and the community is proud to see an ever-increasingly diverse set of contributors, users and technologies join the ecosystem.
+
+In the timeframe of three releases, the project jumped from **112 to 190 contributors**, also doubling down on the number of requested changes and improvements. To top it off, the Flink GitHub repository recently reached the milestone of **10k stars**, all the way up from the incubation days in 2014.
+
+
+
+
+
+The activity across the user@ and dev@1 mailing lists shows a healthy heartbeat, and the gradual ramp up of user-zh@ suggests that this was a well-received community effort. Looking at the numbers for the same period in 2018, the dev@ mailing list has seen the biggest surge in activity, with an average growth of **2.5x in the number of messages and distinct users** — a great reflection of the hyperactive pace of development of the Flink codebase.
+
+
+
+In support of these observations, the report for the financial year of 2019 from the Apache Software Foundation (ASF) features Flink as one of the most thriving open source projects, with mentions for:
+
+* Most Active Visits and Downloads
+
+* Most Active Sources: Visits
+
+* Most Active Sources: Clones
+
+* Top Repositories by Number of Commits
+
+* Top Most Active Apache Mailing Lists (user@ and dev@)
+
+Hats off to our fellows at Apache Beam for an astounding year, too! For more detailed insights, check the [full report](https://s3.amazonaws.com/files-dist/AnnualReports/FY2018%20Annual%20Report.pdf).
+
+1. Excluding messages from "jira@apache.org".
+
+# Upcoming Events
+
+As the conference and meetup season ramps up again, here are some events to keep an eye out for talks about Flink and opportunities to mingle with the wider stream processing community.
+
+### North America
+
+* [Conference] **[Strata Data Conference 2019](https://conferences.oreilly.com/strata/strata-ny)**, September 23-26, New York, USA
+
+* [Meetup] **[Apache Flink Bay Area Meetup](https://www.meetup.com/Bay-Area-Apache-Flink-Meetup/events/262680261/)**, September 24, San Francisco, USA
+
+* [Conference] **[Scale By The Bay 2019](https://www.meetup.com/Bay-Area-Apache-Flink-Meetup/events/262680261/)**, November 13-15, San Francisco, USA
+
+### Europe
+
+* [Meetup] **[Apache Flink London Meetup](https://www.meetup.com/Apache-Flink-London-Meetup/events/264123672)**, September 23, London, UK
+
+* [Conference] **[Flink Forward Europe 2019](https://europe-2019.flink-forward.org)**, October 7-9, Berlin, Germany
+
+ * The next edition of Flink Forward Europe is around the corner and the [program](https://europe-2019.flink-forward.org/conference-program) has been announced, featuring 70+ talks as well as panel discussions and interactive "Ask Me Anything" sessions with core Flink committers. If you're looking to learn more about Flink and share your experience with other community members, there really is [no better place]((https://vimeo.com/296403091)) than Flink Forward!
+
+ * **Note:** if you are a **committer for any Apache project**, you can **get a free ticket** by registering with your Apache email address and using the discount code: *FFEU19-ApacheCommitter*.
+
+* [Conference] **[ApacheCon Berlin 2019](https://aceu19.apachecon.com/)**, October 22-24, Berlin, Germany
+
+* [Conference] **[Data2Day 2019](https://www.data2day.de/)**, October 22-24, Ludwigshafen, Germany
+
+* [Conference] **[Big Data Tech Warsaw 2020](https://bigdatatechwarsaw.eu)**, February 7, Warsaw, Poland
+
+ * The Call For Presentations (CFP) is now [open](https://bigdatatechwarsaw.eu/cfp/).
+
+### Asia
+
+* [Conference] **[Flink Forward Asia 2019](https://m.aliyun.com/markets/aliyun/developer/ffa2019)**, November 28-30, Beijing, China
+
+ * The second edition of Flink Forward Asia is also happening later this year, in Beijing, and the CFP is [open](https://developer.aliyun.com/special/ffa2019) until September 20.
+
+If you'd like to keep a closer eye on what’s happening in the community, subscribe to the [community mailing list](https://flink.apache.org/community.html#mailing-lists) to get fine-grained weekly updates, upcoming event announcements and more. Also, please reach out if you're interested in organizing or being part of Flink events in your area!
\ No newline at end of file
diff --git a/docs/content.tr/posts/2019-09-11-release-1.8.2.md b/docs/content.tr/posts/2019-09-11-release-1.8.2.md
new file mode 100644
index 0000000000..9940be3ed6
--- /dev/null
+++ b/docs/content.tr/posts/2019-09-11-release-1.8.2.md
@@ -0,0 +1,96 @@
+---
+authors:
+- jark: null
+ name: Jark Wu
+ twitter: JarkWu
+date: "2019-09-11T12:00:00Z"
+title: Apache Flink 1.8.2 Released
+aliases:
+- /news/2019/09/11/release-1.8.2.html
+---
+
+The Apache Flink community released the second bugfix version of the Apache Flink 1.8 series.
+
+This release includes 23 fixes and minor improvements for Flink 1.8.1. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.8.2.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.8.2
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.8.2
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.8.2
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+List of resolved issues:
+
+ Bug
+
+
+[FLINK-13941 ] - Prevent data-loss by not cleaning up small part files from S3.
+
+[FLINK-9526 ] - BucketingSink end-to-end test failed on Travis
+
+[FLINK-10368 ] - 'Kerberized YARN on Docker test' unstable
+
+[FLINK-12319 ] - StackOverFlowError in cep.nfa.sharedbuffer.SharedBuffer
+
+[FLINK-12736 ] - ResourceManager may release TM with allocated slots
+
+[FLINK-12889 ] - Job keeps in FAILING state
+
+[FLINK-13059 ] - Cassandra Connector leaks Semaphore on Exception; hangs on close
+
+[FLINK-13159 ] - java.lang.ClassNotFoundException when restore job
+
+[FLINK-13367 ] - Make ClosureCleaner detect writeReplace serialization override
+
+[FLINK-13369 ] - Recursive closure cleaner ends up with stackOverflow in case of circular dependency
+
+[FLINK-13394 ] - Use fallback unsafe secure MapR in nightly.sh
+
+[FLINK-13484 ] - ConnectedComponents end-to-end test instable with NoResourceAvailableException
+
+[FLINK-13499 ] - Remove dependency on MapR artifact repository
+
+[FLINK-13508 ] - CommonTestUtils#waitUntilCondition() may attempt to sleep with negative time
+
+[FLINK-13586 ] - Method ClosureCleaner.clean broke backward compatibility between 1.8.0 and 1.8.1
+
+[FLINK-13761 ] - `SplitStream` should be deprecated because `SplitJavaStream` is deprecated
+
+[FLINK-13789 ] - Transactional Id Generation fails due to user code impacting formatting string
+
+[FLINK-13806 ] - Metric Fetcher floods the JM log with errors when TM is lost
+
+[FLINK-13807 ] - Flink-avro unit tests fails if the character encoding in the environment is not default to UTF-8
+
+[FLINK-13897 ] - OSS FS NOTICE file is placed in wrong directory
+
+
+
+ Improvement
+
+
+[FLINK-12578 ] - Use secure URLs for Maven repositories
+
+[FLINK-12741 ] - Update docs about Kafka producer fault tolerance guarantees
+
+[FLINK-12749 ] - Add Flink Operations Playground documentation
+
+
diff --git a/docs/content.tr/posts/2019-09-13-state-processor-api.md b/docs/content.tr/posts/2019-09-13-state-processor-api.md
new file mode 100644
index 0000000000..c6811689b7
--- /dev/null
+++ b/docs/content.tr/posts/2019-09-13-state-processor-api.md
@@ -0,0 +1,66 @@
+---
+authors:
+- Seth: null
+ name: Seth Wiesman
+ twitter: sjwiesman
+- Fabian: null
+ name: Fabian Hueske
+ twitter: fhueske
+date: "2019-09-13T12:00:00Z"
+excerpt: This post explores the State Processor API, introduced with Flink 1.9.0,
+ why this feature is a big step for Flink, what you can use it for, how to use it
+ and explores some future directions that align the feature with Apache Flink's evolution
+ into a system for unified batch and stream processing.
+title: 'The State Processor API: How to Read, write and modify the state of Flink
+ applications'
+aliases:
+- /feature/2019/09/13/state-processor-api.html
+---
+
+Whether you are running Apache FlinkⓇ in production or evaluated Flink as a computation framework in the past, you've probably found yourself asking the question: How can I access, write or update state in a Flink savepoint? Ask no more! [Apache Flink 1.9.0](https://flink.apache.org/news/2019/08/22/release-1.9.0.html) introduces the [State Processor API]({{< param DocsBaseUrl >}}flink-docs-release-1.9/dev/libs/state_processor_api.html), a powerful extension of the DataSet API that allows reading, writing and modifying state in Flink's savepoints and checkpoints.
+
+In this post, we explain why this feature is a big step for Flink, what you can use it for, and how to use it. Finally, we will discuss the future of the State Processor API and how it aligns with our plans to evolve Flink into a system for [unified batch and stream processing](https://flink.apache.org/news/2019/02/13/unified-batch-streaming-blink.html).
+
+## Stateful Stream Processing with Apache Flink until Flink 1.9
+
+All non-trivial stream processing applications are stateful and most of them are designed to run for months or years. Over time, many of them accumulate a lot of valuable state that can be very expensive or even impossible to rebuild if it gets lost due to a failure. In order to guarantee the consistency and durability of application state, Flink featured a sophisticated checkpointing and recovery mechanism from very early on. With every release, the Flink community has added more and more state-related features to improve checkpointing and recovery speed, the maintenance of applications, and practices to manage applications.
+
+However, a feature that was commonly requested by Flink users was the ability to access the state of an application “from the outside”. This request was motivated by the need to validate or debug the state of an application, to migrate the state of an application to another application, to evolve an application from the Heap State Backend to the RocksDB State Backend, or to import the initial state of an application from an external system like a relational database.
+
+Despite all those convincing reasons to expose application state externally, your access options have been fairly limited until now. Flink's Queryable State feature only supports key-lookups (point queries) and does not guarantee the consistency of returned values (the value of a key might be different before and after an application recovered from a failure). Moreover, queryable state cannot be used to add or modify the state of an application. Also, savepoints, which are consistent snapshots of an application's state, were not accessible because the application state is encoded with a custom binary format.
+
+## Reading and Writing Application State with the State Processor API
+
+The State Processor API that comes with Flink 1.9 is a true game-changer in how you can work with application state! In a nutshell, it extends the DataSet API with Input and OutputFormats to read and write savepoint or checkpoint data. Due to the [interoperability of DataSet and Table API]({{< param DocsBaseUrl >}}flink-docs-master/dev/table/common.html#integration-with-datastream-and-dataset-api), you can even use relational Table API or SQL queries to analyze and process state data.
+
+For example, you can take a savepoint of a running stream processing application and analyze it with a DataSet batch program to verify that the application behaves correctly. Or you can read a batch of data from any store, preprocess it, and write the result to a savepoint that you use to bootstrap the state of a streaming application. It's also possible to fix inconsistent state entries now. Finally, the State Processor API opens up many ways to evolve a stateful application that were previously blocked by parameter and design choices that could not be changed without losing all the state of the application after it was started. For example, you can now arbitrarily modify the data types of states, adjust the maximum parallelism of operators, split or merge operator state, re-assign operator UIDs, and so on.
+
+## Mapping Application State to DataSets
+
+The State Processor API maps the state of a streaming application to one or more data sets that can be separately processed. In order to be able to use the API, you need to understand how this mapping works.
+
+But let's first have a look at what a stateful Flink job looks like. A Flink job is composed of operators, typically one or more source operators, a few operators for the actual processing, and one or more sink operators. Each operator runs in parallel in one or more tasks and can work with different types of state. An operator can have zero, one, or more *“operator states”* which are organized as lists that are scoped to the operator's tasks. If the operator is applied on a keyed stream, it can also have zero, one, or more *“keyed states”* which are scoped to a key that is extracted from each processed record. You can think of keyed state as a distributed key-value map.
+
+The following figure shows the application “MyApp” which consists of three operators called “Src”, “Proc”, and “Snk”. Src has one operator state (os1), Proc has one operator state (os2) and two keyed states (ks1, ks2) and Snk is stateless.
+
+
+
+
+
+A savepoint or checkpoint of MyApp consists of the data of all states, organized in a way that the states of each task can be restored. When processing the data of a savepoint (or checkpoint) with a batch job, we need a mental model that maps the data of the individual tasks' states into data sets or tables. In fact, we can think of a savepoint as a database. Every operator (identified by its UID) represents a namespace. Each operator state of an operator is mapped to a dedicated table in the namespace with a single column that holds the state's data of all tasks. All keyed states of an operator are mapped to a single table consisting of a column for the key, and one column for each keyed state. The following figure shows how a savepoint of MyApp is mapped to a database.
+
+
+
+
+
+The figure shows how the values of Src's operator state are mapped to a table with one column and five rows, one row for all list entries across all parallel tasks of Src. Operator state os2 of the operator “Proc” is similarly mapped to an individual table. The keyed states ks1 and ks2 are combined to a single table with three columns, one for the key, one for ks1 and one for ks2. The keyed table holds one row for each distinct key of both keyed states. Since the operator “Snk” does not have any state, its namespace is empty.
+
+The State Processor API now offers methods to create, load, and write a savepoint. You can read a DataSet from a loaded savepoint or convert a DataSet into a state and add it to a savepoint. DataSets can be processed with the full feature set of the DataSet API. With these building blocks, all of the before-mentioned use cases (and more) can be addressed. Please have a look at the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.9/dev/libs/state_processor_api.html) if you'd like to learn how to use the State Processor API in detail.
+
+## Why DataSet API?
+
+In case you are familiar with [Flink's roadmap](https://flink.apache.org/roadmap.html), you might be surprised that the State Processor API is based on the DataSet API. The Flink community plans to extend the DataStream API with the concept of *BoundedStreams* and deprecate the DataSet API. When designing this feature, we also evaluated the DataStream API or Table API but neither could provide the right feature set yet. Since we didn't want to block this feature on the progress of Flink's APIs, we decided to build it on the DataSet API, but kept its dependencies on the DataSet API to a minimum. Hence, migrating it to another API should be fairly easy.
+
+## Summary
+
+Flink users have requested a feature to access and modify the state of streaming applications from the outside for a long time. With the State Processor API, Flink 1.9.0 finally exposes application state as a data format that can be manipulated. This feature opens up many new possibilities for how users can maintain and manage Flink streaming applications, including arbitrary evolution of stream applications and exporting and bootstrapping of application state. To put it concisely, the State Processor API unlocks the black box that savepoints used to be.
diff --git a/docs/content.tr/posts/2019-10-18-release-1.9.1.md b/docs/content.tr/posts/2019-10-18-release-1.9.1.md
new file mode 100644
index 0000000000..f5c8267e43
--- /dev/null
+++ b/docs/content.tr/posts/2019-10-18-release-1.9.1.md
@@ -0,0 +1,232 @@
+---
+authors:
+- jark: null
+ name: Jark Wu
+ twitter: JarkWu
+date: "2019-10-18T12:00:00Z"
+title: Apache Flink 1.9.1 Released
+aliases:
+- /news/2019/10/18/release-1.9.1.html
+---
+
+The Apache Flink community released the first bugfix version of the Apache Flink 1.9 series.
+
+This release includes 96 fixes and minor improvements for Flink 1.9.0. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.9.1.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.9.1
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.9.1
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.9.1
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+List of resolved issues:
+
+ Bug
+
+
+[FLINK-11630 ] - TaskExecutor does not wait for Task termination when terminating itself
+
+[FLINK-13490 ] - Fix if one column value is null when reading JDBC, the following values are all null
+
+[FLINK-13941 ] - Prevent data-loss by not cleaning up small part files from S3.
+
+[FLINK-12501 ] - AvroTypeSerializer does not work with types generated by avrohugger
+
+[FLINK-13386 ] - Fix some frictions in the new default Web UI
+
+[FLINK-13526 ] - Switching to a non existing catalog or database crashes sql-client
+
+[FLINK-13568 ] - DDL create table doesn't allow STRING data type
+
+[FLINK-13805 ] - Bad Error Message when TaskManager is lost
+
+[FLINK-13806 ] - Metric Fetcher floods the JM log with errors when TM is lost
+
+[FLINK-14010 ] - Dispatcher & JobManagers don't give up leadership when AM is shut down
+
+[FLINK-14145 ] - CompletedCheckpointStore#getLatestCheckpoint(true) returns wrong checkpoint
+
+[FLINK-13059 ] - Cassandra Connector leaks Semaphore on Exception and hangs on close
+
+[FLINK-13534 ] - Unable to query Hive table with decimal column
+
+[FLINK-13562 ] - Throws exception when FlinkRelMdColumnInterval meets two stage stream group aggregate
+
+[FLINK-13563 ] - TumblingGroupWindow should implement toString method
+
+[FLINK-13564 ] - Throw exception if constant with YEAR TO MONTH resolution was used for group windows
+
+[FLINK-13588 ] - StreamTask.handleAsyncException throws away the exception cause
+
+[FLINK-13653 ] - ResultStore should avoid using RowTypeInfo when creating a result
+
+[FLINK-13711 ] - Hive array values not properly displayed in SQL CLI
+
+[FLINK-13737 ] - flink-dist should add provided dependency on flink-examples-table
+
+[FLINK-13738 ] - Fix NegativeArraySizeException in LongHybridHashTable
+
+[FLINK-13742 ] - Fix code generation when aggregation contains both distinct aggregate with and without filter
+
+[FLINK-13760 ] - Fix hardcode Scala version dependency in hive connector
+
+[FLINK-13761 ] - `SplitStream` should be deprecated because `SplitJavaStream` is deprecated
+
+[FLINK-13789 ] - Transactional Id Generation fails due to user code impacting formatting string
+
+[FLINK-13823 ] - Incorrect debug log in CompileUtils
+
+[FLINK-13825 ] - The original plugins dir is not restored after e2e test run
+
+[FLINK-13831 ] - Free Slots / All Slots display error
+
+[FLINK-13887 ] - Ensure defaultInputDependencyConstraint to be non-null when setting it in ExecutionConfig
+
+[FLINK-13897 ] - OSS FS NOTICE file is placed in wrong directory
+
+[FLINK-13933 ] - Hive Generic UDTF can not be used in table API both stream and batch mode
+
+[FLINK-13936 ] - NOTICE-binary is outdated
+
+[FLINK-13966 ] - Jar sorting in collect_license_files.sh is locale dependent
+
+[FLINK-14009 ] - Cron jobs broken due to verifying incorrect NOTICE-binary file
+
+[FLINK-14049 ] - Update error message for failed partition updates to include task name
+
+[FLINK-14076 ] - 'ClassNotFoundException: KafkaException' on Flink v1.9 w/ checkpointing
+
+[FLINK-14107 ] - Kinesis consumer record emitter deadlock under event time alignment
+
+[FLINK-14119 ] - Clean idle state for RetractableTopNFunction
+
+[FLINK-14139 ] - Fix potential memory leak of rest server when using session/standalone cluster
+
+[FLINK-14140 ] - The Flink Logo Displayed in Flink Python Shell is Broken
+
+[FLINK-14150 ] - Unnecessary __pycache__ directories appears in pyflink.zip
+
+[FLINK-14288 ] - Add Py4j NOTICE for source release
+
+[FLINK-13892 ] - HistoryServerTest failed on Travis
+
+[FLINK-14043 ] - SavepointMigrationTestBase is super slow
+
+[FLINK-12164 ] - JobMasterTest.testJobFailureWhenTaskExecutorHeartbeatTimeout is unstable
+
+[FLINK-9900 ] - Fix unstable test ZooKeeperHighAvailabilityITCase#testRestoreBehaviourWithFaultyStateHandles
+
+[FLINK-13484 ] - ConnectedComponents end-to-end test instable with NoResourceAvailableException
+
+[FLINK-13489 ] - Heavy deployment end-to-end test fails on Travis with TM heartbeat timeout
+
+[FLINK-13514 ] - StreamTaskTest.testAsyncCheckpointingConcurrentCloseAfterAcknowledge unstable
+
+[FLINK-13530 ] - AbstractServerTest failed on Travis
+
+[FLINK-13585 ] - Fix sporadical deallock in TaskAsyncCallTest#testSetsUserCodeClassLoader()
+
+[FLINK-13599 ] - Kinesis end-to-end test failed on Travis
+
+[FLINK-13663 ] - SQL Client end-to-end test for modern Kafka failed on Travis
+
+[FLINK-13688 ] - HiveCatalogUseBlinkITCase.testBlinkUdf constantly failed
+
+[FLINK-13739 ] - BinaryRowTest.testWriteString() fails in some environments
+
+[FLINK-13746 ] - Elasticsearch (v2.3.5) sink end-to-end test fails on Travis
+
+[FLINK-13769 ] - BatchFineGrainedRecoveryITCase.testProgram failed on Travis
+
+[FLINK-13807 ] - Flink-avro unit tests fails if the character encoding in the environment is not default to UTF-8
+
+
+
+
+ Improvement
+
+
+[FLINK-13965 ] - Keep hasDeprecatedKeys and deprecatedKeys methods in ConfigOption and mark it with @Deprecated annotation
+
+[FLINK-9941 ] - Flush in ScalaCsvOutputFormat before close method
+
+[FLINK-13336 ] - Remove the legacy batch fault tolerance page and redirect it to the new task failure recovery page
+
+[FLINK-13380 ] - Improve the usability of Flink session cluster on Kubernetes
+
+[FLINK-13819 ] - Introduce RpcEndpoint State
+
+[FLINK-13845 ] - Drop all the content of removed "Checkpointed" interface
+
+[FLINK-13957 ] - Log dynamic properties on job submission
+
+[FLINK-13967 ] - Generate full binary licensing via collect_license_files.sh
+
+[FLINK-13968 ] - Add travis check for the correctness of the binary licensing
+
+[FLINK-13449 ] - Add ARM architecture to MemoryArchitecture
+
+
+
+
+ Documentation
+
+
+[FLINK-13105 ] - Add documentation for blink planner's built-in functions
+
+[FLINK-13277 ] - add documentation of Hive source/sink
+
+[FLINK-13354 ] - Add documentation for how to use blink planner
+
+[FLINK-13355 ] - Add documentation for Temporal Table Join in blink planner
+
+[FLINK-13356 ] - Add documentation for TopN and Deduplication in blink planner
+
+[FLINK-13359 ] - Add documentation for DDL introduction
+
+[FLINK-13362 ] - Add documentation for Kafka & ES & FileSystem DDL
+
+[FLINK-13363 ] - Add documentation for streaming aggregate performance tunning.
+
+[FLINK-13706 ] - add documentation of how to use Hive functions in Flink
+
+[FLINK-13942 ] - Add Overview page for Getting Started section
+
+[FLINK-13863 ] - Update Operations Playground to Flink 1.9.0
+
+[FLINK-13937 ] - Fix wrong hive dependency version in documentation
+
+[FLINK-13830 ] - The Document about Cluster on yarn have some problems
+
+[FLINK-14160 ] - Extend Operations Playground with --backpressure option
+
+[FLINK-13388 ] - Update UI screenshots in the documentation to the new default Web Frontend
+
+[FLINK-13415 ] - Document how to use hive connector in scala shell
+
+[FLINK-13517 ] - Restructure Hive Catalog documentation
+
+[FLINK-13643 ] - Document the workaround for users with a different minor Hive version
+
+[FLINK-13757 ] - Fix wrong description of "IS NOT TRUE" function documentation
+
+
+
diff --git a/docs/content.tr/posts/2019-11-06-flink-kubernetes-kudo.md b/docs/content.tr/posts/2019-11-06-flink-kubernetes-kudo.md
new file mode 100644
index 0000000000..9d13329d9f
--- /dev/null
+++ b/docs/content.tr/posts/2019-11-06-flink-kubernetes-kudo.md
@@ -0,0 +1,158 @@
+---
+authors:
+- gerred: null
+ name: Gerred Dillon
+date: "2019-11-06T12:00:00Z"
+excerpt: A common use case for Apache Flink is streaming data analytics together with
+ Apache Kafka, which provides a pub/sub model and durability for data streams. In
+ this post, we demonstrate how to orchestrate Flink and Kafka with KUDO.
+title: Running Apache Flink on Kubernetes with KUDO
+aliases:
+- /news/2019/12/09/flink-kubernetes-kudo.html
+---
+
+A common use case for Apache Flink is streaming data analytics together with Apache Kafka, which provides a pub/sub model and durability for data streams. To achieve elastic scalability, both are typically deployed in clustered environments, and increasingly on top of container orchestration platforms like Kubernetes. The [Operator pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) provides an extension mechanism to Kubernetes that captures human operator knowledge about an application, like Flink, in software to automate its operation. [KUDO](https://kudo.dev) is an open source toolkit for building Operators using declarative YAML specs, with a focus on ease of use for cluster admins and developers.
+
+In this blog post we demonstrate how to orchestrate a streaming data analytics application based on Flink and Kafka with KUDO. It consists of a Flink job that checks financial transactions for fraud, and two microservices that generate and display the transactions. You can find more details about this demo in the [KUDO Operators repository](https://github.com/kudobuilder/operators/tree/master/repository/flink/docs/demo/financial-fraud), including instructions for installing the dependencies.
+
+
+
+
+
+## Prerequisites
+
+You can run this demo on your local machine using [minikube](https://github.com/kubernetes/minikube). The instructions below were tested with minikube v1.5.1 and Kubernetes v1.16.2 but should work on any Kubernetes version above v1.15.0. First, start a minikube cluster with enough capacity:
+
+`minikube start --cpus=6 --memory=9216 --disk-size=10g`
+
+If you’re using a different way to provision Kubernetes, make sure you have at least 6 CPU Cores, 9 GB of RAM and 10 GB of disk space available.
+
+Install the `kubectl` CLI tool. The KUDO CLI is a plugin for the Kubernetes CLI. The official instructions for installing and setting up kubectl are [here](https://kubernetes.io/docs/tasks/tools/install-kubectl/).
+
+Next, let’s install the KUDO CLI. At the time of this writing, the latest KUDO version is v0.10.0. You can find the CLI binaries for download [here](https://github.com/kudobuilder/kudo/releases). Download the `kubectl-kudo` binary for your OS and architecture.
+
+If you’re using Homebrew on MacOS, you can install the CLI via:
+
+```
+$ brew tap kudobuilder/tap
+$ brew install kudo-cli
+```
+
+Now, let’s initialize KUDO on our Kubernetes cluster:
+
+```
+$ kubectl kudo init
+$KUDO_HOME has been configured at /Users/gerred/.kudo
+```
+
+This will create several resources. First, it will create the [Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/), [service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/), and [role bindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) necessary for KUDO to operate. It will also create an instance of the [KUDO controller](https://kudo.dev/docs/architecture.html#components) so that we can begin creating instances of applications.
+
+The KUDO CLI leverages the kubectl plugin system, which gives you all its functionality under `kubectl kudo`. This is a convenient way to install and deal with your KUDO Operators. For our demo, we use Kafka and Flink which depend on ZooKeeper. To make the ZooKeeper Operator available on the cluster, run:
+
+```
+$ kubectl kudo install zookeeper --version=0.3.0 --skip-instance
+```
+
+The --skip-instance flag skips the creation of a ZooKeeper instance. The flink-demo Operator that we’re going to install below will create it as a dependency instead. Now let’s make the Kafka and Flink Operators available the same way:
+
+```
+$ kubectl kudo install kafka --version=1.2.0 --skip-instance
+```
+
+```
+$ kubectl kudo install flink --version=0.2.1 --skip-instance
+```
+
+This installs all the Operator versions needed for our demo.
+
+## Financial Fraud Demo
+
+In our financial fraud demo we have two microservices, called “generator” and “actor”. The generator produces transactions with random amounts and writes them into a Kafka topic. Occasionally, the value will be over 10,000 which is considered fraud for the purpose of this demo. The Flink job subscribes to the Kafka topic and detects fraudulent transactions. When it does, it submits them to another Kafka topic which the actor consumes. The actor simply displays each fraudulent transaction.
+
+The KUDO CLI by default installs Operators from the [official repository](https://github.com/kudobuilder/operators/), but it also supports installation from your local filesystem. This is useful if you want to develop your own Operator, or modify this demo for your own purposes.
+
+First, clone the “kudobuilder/operators” repository via:
+
+```
+$ git clone https://github.com/kudobuilder/operators.git
+```
+
+Next, change into the “operators” directory and install the demo-operator from your local filesystem:
+
+```
+$ cd operators
+$ kubectl kudo install repository/flink/docs/demo/financial-fraud/demo-operator --instance flink-demo
+instance.kudo.dev/v1beta1/flink-demo created
+```
+
+This time we didn’t include the --skip-instance flag, so KUDO will actually deploy all the components, including Flink, Kafka, and ZooKeeper. KUDO orchestrates deployments and other lifecycle operations using [plans](https://kudo.dev/docs/concepts.html#plan) that were defined by the Operator developer. Plans are similar to [runbooks](https://en.wikipedia.org/wiki/Runbook) and encapsulate all the procedures required to operate the software. We can track the status of the deployment using this KUDO command:
+
+```
+$ kubectl kudo plan status --instance flink-demo
+Plan(s) for "flink-demo" in namespace "default":
+.
+└── flink-demo (Operator-Version: "flink-demo-0.1.4" Active-Plan: "deploy")
+ └── Plan deploy (serial strategy) [IN_PROGRESS]
+ ├── Phase dependencies [IN_PROGRESS]
+ │ ├── Step zookeeper (COMPLETE)
+ │ └── Step kafka (IN_PROGRESS)
+ ├── Phase flink-cluster [PENDING]
+ │ └── Step flink (PENDING)
+ ├── Phase demo [PENDING]
+ │ ├── Step gen (PENDING)
+ │ └── Step act (PENDING)
+ └── Phase flink-job [PENDING]
+ └── Step submit (PENDING)
+```
+
+The output shows that the “deploy” plan is in progress and that it consists of 4 phases: “dependencies”, “flink-cluster”, “demo” and “flink-job”. The “dependencies” phase includes steps for “zookeeper” and “kafka”. This is where both dependencies get installed, before KUDO continues to install the Flink cluster and the demo itself. We also see that ZooKeeper installation completed, and that Kafka installation is currently in progress. We can view details about Kafka’s deployment plan via:
+
+```
+$ kubectl kudo plan status --instance flink-demo-kafka
+Plan(s) for "flink-demo-kafka" in namespace "default":
+.
+└── flink-demo-kafka (Operator-Version: "kafka-1.2.0" Active-Plan: "deploy")
+ ├── Plan deploy (serial strategy) [IN_PROGRESS]
+ │ └── Phase deploy-kafka [IN_PROGRESS]
+ │ └── Step deploy (IN_PROGRESS)
+ └── Plan not-allowed (serial strategy) [NOT ACTIVE]
+ └── Phase not-allowed (serial strategy) [NOT ACTIVE]
+ └── Step not-allowed (serial strategy) [NOT ACTIVE]
+ └── not-allowed [NOT ACTIVE]
+```
+
+After Kafka was successfully installed the next phase “flink-cluster” will start and bring up, you guessed it, your flink-cluster. After this is done, the demo phase creates the generator and actor pods that generate and display transactions for this demo. Lastly, we have the flink-job phase in which we submit the actual FinancialFraudJob to the Flink cluster. Once the flink job is submitted, we will be able to see fraud logs in our actor pod shortly after.
+
+After a while, the state of all plans, phases and steps will change to “COMPLETE”. Now we can view the Flink dashboard to verify that our job is running. To access it from outside the Kubernetes cluster, first start the client proxy, then open the URL below in your browser:
+
+```
+$ kubectl proxy
+```
+
+[http://127.0.0.1:8001/api/v1/namespaces/default/services/flink-demo-flink-jobmanager:ui/proxy/#/overview](http://127.0.0.1:8001/api/v1/namespaces/default/services/flink-demo-flink-jobmanager:ui/proxy/#/overview)
+
+It should look similar to this, depending on your local machine and how many cores you have available:
+
+
+
+
+
+The job is up and running and we should now be able to see fraudulent transaction in the logs of the actor pod:
+
+```
+$ kubectl logs $(kubectl get pod -l actor=flink-demo -o jsonpath="{.items[0].metadata.name}")
+Broker: flink-demo-kafka-kafka-0.flink-demo-kafka-svc:9093
+Topic: fraud
+
+Detected Fraud: TransactionAggregate {startTimestamp=0, endTimestamp=1563395831000, totalAmount=19895:
+Transaction{timestamp=1563395778000, origin=1, target='3', amount=8341}
+Transaction{timestamp=1563395813000, origin=1, target='3', amount=8592}
+Transaction{timestamp=1563395817000, origin=1, target='3', amount=2802}
+Transaction{timestamp=1563395831000, origin=1, target='3', amount=160}}
+```
+
+If you add the “-f” flag to the previous command, you can follow along as more transactions are streaming in and are evaluated by our Flink job.
+
+## Conclusion
+
+In this blog post we demonstrated how to easily deploy an end-to-end streaming data application on Kubernetes using KUDO. We deployed a Flink job and two microservices, as well as all the required infrastructure - Flink, Kafka, and ZooKeeper using just a few kubectl commands. To find out more about KUDO, visit the [project website](https://kudo.dev) or join the community on [Slack](https://kubernetes.slack.com/messages/kudo/).
diff --git a/docs/content.tr/posts/2019-11-25-query-pulsar-streams-using-apache-flink.md b/docs/content.tr/posts/2019-11-25-query-pulsar-streams-using-apache-flink.md
new file mode 100644
index 0000000000..aa5ccb409a
--- /dev/null
+++ b/docs/content.tr/posts/2019-11-25-query-pulsar-streams-using-apache-flink.md
@@ -0,0 +1,220 @@
+---
+authors:
+- name: Sijie Guo
+ sijie: null
+ twitter: sijieg
+- marksfik: null
+ name: Markos Sfikas
+ twitter: MarkSfik
+date: "2019-11-25T12:00:00Z"
+excerpt: This blog post discusses the new developments and integrations between Apache
+ Flink and Apache Pulsar and showcases how you can leverage Pulsar’s built-in schema
+ to query Pulsar streams in real time using Apache Flink.
+title: How to query Pulsar Streams using Apache Flink
+aliases:
+- /news/2019/11/25/query-pulsar-streams-using-apache-flink.html
+---
+
+In a previous [story](https://flink.apache.org/2019/05/03/pulsar-flink.html) on the Flink blog, we explained the different ways that [Apache Flink](https://flink.apache.org/) and [Apache Pulsar](https://pulsar.apache.org/) can integrate to provide elastic data processing at large scale. This blog post discusses the new developments and integrations between the two frameworks and showcases how you can leverage Pulsar’s built-in schema to query Pulsar streams in real time using Apache Flink.
+
+
+# A short intro to Apache Pulsar
+
+Apache Pulsar is a flexible pub/sub messaging system, backed by durable log storage. Some of the framework’s highlights include multi-tenancy, a unified message model, structured event streams and a cloud-native architecture that make it a perfect fit for a wide set of use cases, ranging from billing, payments and trading services all the way to the unification of the different messaging architectures in an organization. If you are interested in finding out more about Pulsar, you can visit the [Apache Pulsar documentation](https://pulsar.apache.org/docs/en/standalone/) or get in touch with the Pulsar community on [Slack](https://apache-pulsar.herokuapp.com).
+
+
+# Existing Pulsar & Flink integration (Apache Flink 1.6+)
+
+The existing integration between Pulsar and Flink exploits Pulsar as a message queue in a Flink application. Flink developers can utilize Pulsar as a streaming source and streaming sink for their Flink applications by selecting a specific Pulsar source and connecting to their desired Pulsar cluster and topic:
+
+```java
+// create and configure Pulsar consumer
+PulsarSourceBuilderbuilder = PulsarSourceBuilder
+ .builder(new SimpleStringSchema())
+ .serviceUrl(serviceUrl)
+ .topic(inputTopic)
+ .subsciptionName(subscription);
+SourceFunction src = builder.build();
+// ingest DataStream with Pulsar consumer
+DataStream words = env.addSource(src);
+```
+
+Pulsar streams can then get connected to the Flink processing logic…
+
+```java
+// perform computation on DataStream (here a simple WordCount)
+DataStream wc = words
+ .flatmap((FlatMapFunction) (word, collector) -> {
+ collector.collect(new WordWithCount(word, 1));
+ })
+
+ .returns(WordWithCount.class)
+ .keyBy("word")
+ .timeWindow(Time.seconds(5))
+ .reduce((ReduceFunction) (c1, c2) ->
+ new WordWithCount(c1.word, c1.count + c2.count));
+```
+
+...and then get emitted back to Pulsar (used now as a sink), sending one’s computation results downstream, back to a Pulsar topic:
+
+
+```java
+// emit result via Pulsar producer
+wc.addSink(new FlinkPulsarProducer<>(
+ serviceUrl,
+ outputTopic,
+ new AuthentificationDisabled(),
+ wordWithCount -> wordWithCount.toString().getBytes(UTF_8),
+ wordWithCount -> wordWithCount.word)
+);
+```
+
+Although this is a great first integration step, the existing design is not leveraging the full power of Pulsar. Some shortcomings of the integration with Flink 1.6.0 relate to Pulsar neither being utilized as durable storage nor having schema integration with Flink, resulting in manual input when describing an application’s schema registry.
+
+
+# Pulsar’s integration with Flink 1.9: Using Pulsar as a Flink catalog
+
+The latest integration between [Flink 1.9.0](https://flink.apache.org/downloads.html#apache-flink-191) and Pulsar addresses most of the previously mentioned shortcomings. The [contribution of Alibaba’s Blink to the Flink repository](https://flink.apache.org/news/2019/02/13/unified-batch-streaming-blink.html) adds many enhancements and new features to the processing framework that make the integration with Pulsar significantly more powerful and impactful. Flink 1.9.0 brings Pulsar schema integration into the picture, makes the Table API a first-class citizen and provides an exactly-once streaming source and at-least-once streaming sink with Pulsar. Lastly, with schema integration, Pulsar can now be registered as a Flink catalog, making running Flink queries on top of Pulsar streams a matter of a few commands. In the following sections, we will take a closer look at the new integrations and provide examples of how to query Pulsar streams using Flink SQL.
+
+
+# Leveraging the Flink <> Pulsar Schema Integration
+
+Before delving into the integration details and how you can use Pulsar schema with Flink, let us describe how schema in Pulsar works. Schema in Apache Pulsar already co-exists and serves as the representation of the data on the broker side of the framework, something that makes schema registry with external systems obsolete. Additionally, the data schema in Pulsar is associated with each topic so both producers and consumers send data with predefined schema information, while the broker performs schema validation, and manages schema multi-versioning and evolution in compatibility checks.
+
+Below you can find an example of Pulsar’s schema on both the producer and consumer side. On the producer side, you can specify which schema you want to use and Pulsar then sends a POJO class without the need to perform any serialization/deserialization. Similarly, on the consumer end, you can also specify the data schema and upon receiving the data, Pulsar will automatically validate the schema information, fetch the schema of the given version and then deserialize the data back to a POJO structure. Pulsar stores the schema information in the metadata of a Pulsar topic.
+
+```java
+// Create producer with Struct schema and send messages
+Producer producer = client.newProducer(Schema.AVRO(User.class)).create();
+producer.newMessage()
+ .value(User.builder()
+ .userName(“pulsar-user”)
+ .userId(1L)
+ .build())
+ .send();
+```
+
+```java
+// Create consumer with Struct schema and receive messages
+Consumer consumer = client.newCOnsumer(Schema.AVRO(User.class)).create();
+consumer.receive();
+```
+
+Let’s assume we have an application that specifies a schema to the producer and/or consumer. Upon receiving the schema information, the producer (or consumer) — that is connected to the broker — will transfer such information so that the broker can then perform schema registration, validations and schema compatibility checks before returning or rejecting the schema as illustrated in the diagram below:
+
+
+
+
+
+
+Not only is Pulsar able to handle and store the schema information, but is additionally able to handle any schema evolution — where necessary. Pulsar will effectively manage any schema evolution in the broker, keeping track of all different versions of your schema while performing any necessary compatibility checks.
+
+Moreover, when messages are published on the producer side, Pulsar will tag each message with the schema version as part of each message’s metadata. On the consumer side, when the message is received and the metadata is deserialized, Pulsar will check the schema version associated with this message and will fetch the corresponding schema information from the broker. As a result, when Pulsar integrates with a Flink application it uses the pre-existing schema information and maps individual messages with schema information to a different row in Flink’s type system.
+
+For the cases when Flink users do not interact with schema directly or make use of primitive schema (for example, using a topic to store a string or long number), Pulsar will either convert the message payload into a Flink row, called ‘value’ or — for the cases of structured schema types, like JSON and AVRO — Pulsar will extract the individual fields from the schema information and will map the fields to Flink’s type system. Finally, all metadata information associated with each message, such as the message key, topic, publish time, or event time will be converted into metadata fields in a Flink row. Below we provide two examples of primitive schema and structured schema types and how these will be transformed from a Pulsar topic to Flink’s type system.
+
+
+
+
+
+
+
+Once all the schema information is mapped to Flink’s type system, you can start building a Pulsar source, sink or catalog in Flink based on the specified schema information as illustrated below:
+
+# Flink & Pulsar: Read data from Pulsar
+
+* Create a Pulsar source for streaming queries
+
+```java
+val env = StreamExecutionEnvironment.getExecutionEnvironment
+val props = new Properties()
+props.setProperty("service.url", "pulsar://...")
+props.setProperty("admin.url", "http://...")
+props.setProperty("partitionDiscoveryIntervalMillis", "5000")
+props.setProperty("startingOffsets", "earliest")
+props.setProperty("topic", "test-source-topic")
+val source = new FlinkPulsarSource(props)
+// you don't need to provide a type information to addSource since FlinkPulsarSource is ResultTypeQueryable
+val dataStream = env.addSource(source)(null)
+
+// chain operations on dataStream of Row and sink the output
+// end method chaining
+
+env.execute()
+```
+
+* Register topics in Pulsar as streaming tables
+
+```java
+val env = StreamExecutionEnvironment.getExecutionEnvironment
+val tEnv = StreamTableEnvironment.create(env)
+
+val prop = new Properties()
+prop.setProperty("service.url", serviceUrl)
+prop.setProperty("admin.url", adminUrl)
+prop.setProperty("flushOnCheckpoint", "true")
+prop.setProperty("failOnWrite", "true")
+props.setProperty("topic", "test-sink-topic")
+
+tEnv
+ .connect(new Pulsar().properties(props))
+ .inAppendMode()
+ .registerTableSource("sink-table")
+
+val sql = "INSERT INTO sink-table ....."
+tEnv.sqlUpdate(sql)
+env.execute()
+```
+
+# Flink & Pulsar: Write data to Pulsar
+
+* Create a Pulsar sink for streaming queries
+
+```java
+val env = StreamExecutionEnvironment.getExecutionEnvironment
+val stream = .....
+
+val prop = new Properties()
+prop.setProperty("service.url", serviceUrl)
+prop.setProperty("admin.url", adminUrl)
+prop.setProperty("flushOnCheckpoint", "true")
+prop.setProperty("failOnWrite", "true")
+props.setProperty("topic", "test-sink-topic")
+
+stream.addSink(new FlinkPulsarSink(prop, DummyTopicKeyExtractor))
+env.execute()
+```
+
+* Write a streaming table to Pulsar
+
+```java
+val env = StreamExecutionEnvironment.getExecutionEnvironment
+val tEnv = StreamTableEnvironment.create(env)
+
+val prop = new Properties()
+prop.setProperty("service.url", serviceUrl)
+prop.setProperty("admin.url", adminUrl)
+prop.setProperty("flushOnCheckpoint", "true")
+prop.setProperty("failOnWrite", "true")
+props.setProperty("topic", "test-sink-topic")
+
+tEnv
+ .connect(new Pulsar().properties(props))
+ .inAppendMode()
+ .registerTableSource("sink-table")
+
+val sql = "INSERT INTO sink-table ....."
+tEnv.sqlUpdate(sql)
+env.execute()
+```
+
+In every instance, Flink developers only need to specify the properties of how Flink will connect to a Pulsar cluster without worrying about any schema registry, or serialization/deserialization actions and register the Pulsar cluster as a source, sink or streaming table in Flink. Once all three elements are put together, Pulsar can then be registered as a catalog in Flink, something that drastically simplifies how you process and query data like, for example, writing a program to query data from Pulsar or using the Table API and SQL to query Pulsar data streams.
+
+
+# Next Steps & Future Integration
+
+The goal of the integration between Pulsar and Flink is to simplify how developers use the two frameworks to build a unified data processing stack. As we progress from the classical Lamda architectures — where an online, speeding layer is combined with an offline, batch layer to run data computations — Flink and Pulsar present a great combination in providing a truly unified data processing stack. We see Flink as a unified computation engine, handling both online (streaming) and offline (batch) workloads and Pulsar as the unified data storage layer for a truly unified data processing stack that simplifies developer workloads.
+
+There is still a lot of ongoing work and effort from both communities in getting the integration even better, such as a new source API ([FLIP-27](https://cwiki.apache.org/confluence/display/FLINK/FLIP-27%3A+Refactor+Source+Interface)) that will allow the [contribution of the Pulsar connectors to the Flink community](http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/Discussion-Flink-Pulsar-Connector-td22019.html) as well as a new subscription type called `Key_Shared` subscription type in Pulsar that will allow efficient scaling of the source parallelism. Additional efforts focus around the provision of end-to-end, exactly-once guarantees (currently available only in the source Pulsar connector, and not the sink Pulsar connector) and more efforts around using Pulsar/BookKeeper as a Flink state backend.
+
+You can find a more detailed overview of the integration work between the two communities in this [recording video](https://youtu.be/3sBXXfgl5vs) from Flink Forward Europe 2019 or sign up to the [Flink dev mailing list](https://flink.apache.org/community.html#mailing-lists) for the latest contribution and integration efforts between Flink and Pulsar.
diff --git a/docs/content.tr/posts/2019-12-11-release-1.8.3.md b/docs/content.tr/posts/2019-12-11-release-1.8.3.md
new file mode 100644
index 0000000000..0a6415d306
--- /dev/null
+++ b/docs/content.tr/posts/2019-12-11-release-1.8.3.md
@@ -0,0 +1,144 @@
+---
+authors:
+- hequn: null
+ name: Hequn Cheng
+date: "2019-12-11T12:00:00Z"
+title: Apache Flink 1.8.3 Released
+aliases:
+- /news/2019/12/11/release-1.8.3.html
+---
+
+The Apache Flink community released the third bugfix version of the Apache Flink 1.8 series.
+
+This release includes 45 fixes and minor improvements for Flink 1.8.2. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.8.3.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.8.3
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.8.3
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.8.3
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-13723 ] - Use liquid-c for faster doc generation
+
+[FLINK-13724 ] - Remove unnecessary whitespace from the docs' sidenav
+
+[FLINK-13725 ] - Use sassc for faster doc generation
+
+[FLINK-13726 ] - Build docs with jekyll 4.0.0.pre.beta1
+
+[FLINK-13791 ] - Speed up sidenav by using group_by
+
+
+
+ Bug
+
+
+[FLINK-12342 ] - Yarn Resource Manager Acquires Too Many Containers
+
+[FLINK-13184 ] - Starting a TaskExecutor blocks the YarnResourceManager's main thread
+
+[FLINK-13728 ] - Fix wrong closing tag order in sidenav
+
+[FLINK-13746 ] - Elasticsearch (v2.3.5) sink end-to-end test fails on Travis
+
+[FLINK-13749 ] - Make Flink client respect classloading policy
+
+[FLINK-13892 ] - HistoryServerTest failed on Travis
+
+[FLINK-13936 ] - NOTICE-binary is outdated
+
+[FLINK-13966 ] - Jar sorting in collect_license_files.sh is locale dependent
+
+[FLINK-13995 ] - Fix shading of the licence information of netty
+
+[FLINK-13999 ] - Correct the documentation of MATCH_RECOGNIZE
+
+[FLINK-14009 ] - Cron jobs broken due to verifying incorrect NOTICE-binary file
+
+[FLINK-14010 ] - Dispatcher & JobManagers don't give up leadership when AM is shut down
+
+[FLINK-14043 ] - SavepointMigrationTestBase is super slow
+
+[FLINK-14107 ] - Kinesis consumer record emitter deadlock under event time alignment
+
+[FLINK-14175 ] - Upgrade KPL version in flink-connector-kinesis to fix application OOM
+
+[FLINK-14235 ] - Kafka010ProducerITCase>KafkaProducerTestBase.testOneToOneAtLeastOnceCustomOperator fails on travis
+
+[FLINK-14315 ] - NPE with JobMaster.disconnectTaskManager
+
+[FLINK-14337 ] - HistoryServerTest.testHistoryServerIntegration failed on Travis
+
+[FLINK-14347 ] - YARNSessionFIFOITCase.checkForProhibitedLogContents found a log with prohibited string
+
+[FLINK-14370 ] - KafkaProducerAtLeastOnceITCase>KafkaProducerTestBase.testOneToOneAtLeastOnceRegularSink fails on Travis
+
+[FLINK-14398 ] - Further split input unboxing code into separate methods
+
+[FLINK-14413 ] - shade-plugin ApacheNoticeResourceTransformer uses platform-dependent encoding
+
+[FLINK-14434 ] - Dispatcher#createJobManagerRunner should not start JobManagerRunner
+
+[FLINK-14562 ] - RMQSource leaves idle consumer after closing
+
+[FLINK-14589 ] - Redundant slot requests with the same AllocationID leads to inconsistent slot table
+
+[FLINK-15036 ] - Container startup error will be handled out side of the YarnResourceManager's main thread
+
+
+
+ Improvement
+
+
+[FLINK-12848 ] - Method equals() in RowTypeInfo should consider fieldsNames
+
+[FLINK-13729 ] - Update website generation dependencies
+
+[FLINK-13965 ] - Keep hasDeprecatedKeys and deprecatedKeys methods in ConfigOption and mark it with @Deprecated annotation
+
+[FLINK-13967 ] - Generate full binary licensing via collect_license_files.sh
+
+[FLINK-13968 ] - Add travis check for the correctness of the binary licensing
+
+[FLINK-13991 ] - Add git exclusion for 1.9+ features to 1.8
+
+[FLINK-14008 ] - Auto-generate binary licensing
+
+[FLINK-14104 ] - Bump Jackson to 2.10.1
+
+[FLINK-14123 ] - Lower the default value of taskmanager.memory.fraction
+
+[FLINK-14215 ] - Add Docs for TM and JM Environment Variable Setting
+
+[FLINK-14334 ] - ElasticSearch docs refer to non-existent ExceptionUtils.containsThrowable
+
+[FLINK-14639 ] - Fix the document of Metrics that has an error for `User Scope`
+
+[FLINK-14646 ] - Check non-null for key in KeyGroupStreamPartitioner
+
+[FLINK-14995 ] - Kinesis NOTICE is incorrect
+
+
diff --git a/docs/content.tr/posts/2020-01-15-demo-fraud-detection.md b/docs/content.tr/posts/2020-01-15-demo-fraud-detection.md
new file mode 100644
index 0000000000..5fa993134b
--- /dev/null
+++ b/docs/content.tr/posts/2020-01-15-demo-fraud-detection.md
@@ -0,0 +1,223 @@
+---
+authors:
+- alex: null
+ name: Alexander Fedulov
+ twitter: alex_fedulov
+date: "2020-01-15T12:00:00Z"
+excerpt: In this series of blog posts you will learn about three powerful Flink patterns
+ for building streaming applications.
+title: 'Advanced Flink Application Patterns Vol.1: Case Study of a Fraud Detection
+ System'
+aliases:
+- /news/2020/01/15/demo-fraud-detection.html
+---
+
+In this series of blog posts you will learn about three powerful Flink patterns for building streaming applications:
+
+ - [Dynamic updates of application logic](/news/2020/03/24/demo-fraud-detection-2.html)
+ - Dynamic data partitioning (shuffle), controlled at runtime
+ - [Low latency alerting](/news/2020/07/30/demo-fraud-detection-3.html) based on custom windowing logic (without using the window API)
+
+These patterns expand the possibilities of what is achievable with statically defined data flows and provide the building blocks to fulfill complex business requirements.
+
+**Dynamic updates of application logic** allow Flink jobs to change at runtime, without downtime from stopping and resubmitting the code.
+
+**Dynamic data partitioning** provides the ability to change how events are distributed and grouped by Flink at runtime. Such functionality often becomes a natural requirement when building jobs with dynamically reconfigurable application logic.
+
+**Custom window management** demonstrates how you can utilize the low level [process function API]({{< param DocsBaseUrl >}}flink-docs-stable/dev/stream/operators/process_function.html), when the native [window API]({{< param DocsBaseUrl >}}flink-docs-stable/dev/stream/operators/windows.html) is not exactly matching your requirements. Specifically, you will learn how to implement low latency alerting on windows and how to limit state growth with timers.
+
+These patterns build on top of core Flink functionality, however, they might not be immediately apparent from the framework's documentation as explaining and presenting the motivation behind them is not always trivial without a concrete use case. That is why we will showcase these patterns with a practical example that offers a real-world usage scenario for Apache Flink — a _Fraud Detection_ engine.
+We hope that this series will place these powerful approaches into your tool belt and enable you to take on new and exciting tasks.
+
+In the first blog post of the series we will look at the high-level architecture of the demo application, describe its components and their interactions. We will then deep dive into the implementation details of the first pattern in the series - **dynamic data partitioning**.
+
+
+You will be able to run the full Fraud Detection Demo application locally and look into the details of the implementation by using the accompanying GitHub repository.
+
+### Fraud Detection Demo
+
+The full source code for our fraud detection demo is open source and available online. To run it locally, check out the following repository and follow the steps in the README:
+
+[https://github.com/afedulov/fraud-detection-demo](https://github.com/afedulov/fraud-detection-demo)
+
+You will see the demo is a self-contained application - it only requires `docker` and `docker-compose` to be built from sources and includes the following components:
+
+ - Apache Kafka (message broker) with ZooKeeper
+ - Apache Flink ([application cluster]({{< param DocsBaseUrl >}}flink-docs-stable/concepts/glossary.html#flink-application-cluster))
+ - Fraud Detection Web App
+
+The high-level goal of the Fraud Detection engine is to consume a stream of financial transactions and evaluate them against a set of rules. These rules are subject to frequent changes and tweaks. In a real production system, it is important to be able to add and remove them at runtime, without incurring an expensive penalty of stopping and restarting the job.
+
+When you navigate to the demo URL in your browser, you will be presented with the following UI:
+
+
+
+
+ Figure 1: Fraud Detection Demo UI
+
+
+
+On the left side, you can see a visual representation of financial transactions flowing through the system after you click the "Start" button. The slider at the top allows you to control the number of generated transactions per second. The middle section is devoted to managing the rules evaluated by Flink. From here, you can create new rules as well as issue control commands, such as clearing Flink's state.
+
+The demo out-of-the-box comes with a set of predefined sample rules. You can click the _Start_ button and, after some time, will observe alerts displayed in the right section of the UI. These alerts are the result of Flink evaluating the generated transactions stream against the predefined rules.
+
+ Our sample fraud detection system consists of three main components:
+
+ 1. Frontend (React)
+ 1. Backend (SpringBoot)
+ 1. Fraud Detection application (Apache Flink)
+
+Interactions between the main elements are depicted in _Figure 2_.
+
+
+
+
+ Figure 2: Fraud Detection Demo Components
+
+
+
+ The Backend exposes a REST API to the Frontend for creating/deleting rules as well as issuing control commands for managing the demo execution. It then relays those Frontend actions to Flink by sending them via a "Control" Kafka topic. The Backend additionally includes a _Transactions Generator_ component, which sends an emulated stream of money transfer events to Flink via a separate "Transactions" topic. Alerts generated by Flink are consumed by the Backend from "Alerts" topic and relayed to the UI via WebSockets.
+
+Now that you are familiar with the overall layout and the goal of our Fraud Detection engine, let's now go into the details of what is required to implement such a system.
+
+### Dynamic Data Partitioning
+
+The first pattern we will look into is Dynamic Data Partitioning.
+
+If you have used Flink's DataStream API in the past, you are undoubtedly familiar with the **keyBy** method. Keying a stream shuffles all the records such that elements with the same key are assigned to the same partition. This means all records with the same key are processed by the same physical instance of the next operator.
+
+In a typical streaming application, the choice of key is fixed, determined by some static field within the elements. For instance, when building a simple window-based aggregation of a stream of transactions, we might always group by the transactions account id.
+
+```java
+DataStream input = // [...]
+DataStream<...> windowed = input
+ .keyBy(Transaction::getAccountId)
+ .window(/*window specification*/);
+```
+
+This approach is the main building block for achieving horizontal scalability in a wide range of use cases. However, in the case of an application striving to provide flexibility in business logic at runtime, this is not enough.
+To understand why this is the case, let us start with articulating a realistic sample rule definition for our fraud detection system in the form of a functional requirement:
+
+*"Whenever the **sum** of the accumulated **payment amount** from the same **payer** to the same **beneficiary** within the **duration of a week** is **greater** than **1 000 000 $** - fire an alert."*
+
+In this formulation we can spot a number of parameters that we would like to be able to specify in a newly-submitted rule and possibly even later modify or tweak at runtime:
+
+1. Aggregation field (payment amount)
+1. Grouping fields (payer + beneficiary)
+1. Aggregation function (sum)
+1. Window duration (1 week)
+1. Limit (1 000 000)
+1. Limit operator (greater)
+
+Accordingly, we will use the following simple JSON format to define the aforementioned parameters:
+
+```json
+{
+ "ruleId": 1,
+ "ruleState": "ACTIVE",
+ "groupingKeyNames": ["payerId", "beneficiaryId"],
+ "aggregateFieldName": "paymentAmount",
+ "aggregatorFunctionType": "SUM",
+ "limitOperatorType": "GREATER",
+ "limit": 1000000,
+ "windowMinutes": 10080
+}
+```
+
+At this point, it is important to understand that **`groupingKeyNames`** determine the actual physical grouping of events - all Transactions with the same values of specified parameters (e.g. _payer #25 -> beneficiary #12_) have to be aggregated in the same physical instance of the evaluating operator. Naturally, the process of distributing data in such a way in Flink's API is realised by a `keyBy()` function.
+
+Most examples in Flink's `keyBy()`[documentation]({{< param DocsBaseUrl >}}flink-docs-stable/dev/api_concepts.html#define-keys-using-field-expressions) use a hard-coded `KeySelector`, which extracts specific fixed events' fields. However, to support the desired flexibility, we have to extract them in a more dynamic fashion based on the specifications of the rules. For this, we will have to use one additional operator that prepares every event for dispatching to a correct aggregating instance.
+
+On a high level, our main processing pipeline looks like this:
+
+```java
+DataStream alerts =
+ transactions
+ .process(new DynamicKeyFunction())
+ .keyBy(/* some key selector */);
+ .process(/* actual calculations and alerting */)
+```
+
+We have previously established that each rule defines a **`groupingKeyNames`** parameter that specifies which combination of fields will be used for the incoming events' grouping. Each rule might use an arbitrary combination of these fields. At the same time, every incoming event potentially needs to be evaluated against multiple rules. This implies that events might simultaneously need to be present at multiple parallel instances of evaluating operators that correspond to different rules and hence will need to be forked. Ensuring such events dispatching is the purpose of `DynamicKeyFunction()`.
+
+
+
+
+Figure 3: Forking events with Dynamic Key Function
+
+
+
+ `DynamicKeyFunction` iterates over a set of defined rules and prepares every event to be processed by a `keyBy()` function by extracting the required grouping keys:
+
+```java
+public class DynamicKeyFunction
+ extends ProcessFunction> {
+ ...
+ /* Simplified */
+ List rules = /* Rules that are initialized somehow.
+ Details will be discussed in a future blog post. */;
+
+ @Override
+ public void processElement(
+ Transaction event,
+ Context ctx,
+ Collector> out) {
+
+ for (Rule rule :rules) {
+ out.collect(
+ new Keyed<>(
+ event,
+ KeysExtractor.getKey(rule.getGroupingKeyNames(), event),
+ rule.getRuleId()));
+ }
+ }
+ ...
+}
+```
+ `KeysExtractor.getKey()` uses reflection to extract the required values of `groupingKeyNames` fields from events and combines them as a single concatenated String key, e.g `"{payerId=25;beneficiaryId=12}"`. Flink will calculate the hash of this key and assign the processing of this particular combination to a specific server in the cluster. This will allow tracking all transactions between _payer #25_ and _beneficiary #12_ and evaluating defined rules within the desired time window.
+
+Notice that a wrapper class `Keyed` with the following signature was introduced as the output type of `DynamicKeyFunction`:
+
+```java
+public class Keyed {
+ private IN wrapped;
+ private KEY key;
+ private ID id;
+
+ ...
+ public KEY getKey(){
+ return key;
+ }
+}
+```
+
+Fields of this POJO carry the following information: `wrapped` is the original transaction event, `key` is the result of using `KeysExtractor` and `id` is the ID of the Rule that caused the dispatch of the event (according to the rule-specific grouping logic).
+
+Events of this type will be the input to the `keyBy()` function in the main processing pipeline and allow the use of a simple lambda-expression as a [`KeySelector`]({{< param DocsBaseUrl >}}flink-docs-stable/dev/api_concepts.html#define-keys-using-key-selector-functions) for the final step of implementing dynamic data shuffle.
+
+```java
+DataStream alerts =
+ transactions
+ .process(new DynamicKeyFunction())
+ .keyBy((keyed) -> keyed.getKey());
+ .process(new DynamicAlertFunction())
+```
+
+By applying `DynamicKeyFunction` we are implicitly copying events for performing parallel per-rule evaluation within a Flink cluster. By doing so, we achieve an important property - horizontal scalability of rules' processing. Our system will be capable of handling more rules by adding more servers to the cluster, i.e. increasing the parallelism. This property is achieved at the cost of data duplication, which might become an issue depending on the specific set of parameters, such as incoming data rate, available network bandwidth, event payload size etc. In a real-life scenario, additional optimizations can be applied, such as combined evaluation of rules which have the same `groupingKeyNames`, or a filtering layer, which would strip events of all the fields that are not required for processing of a particular rule.
+
+### Summary:
+
+In this blog post, we have discussed the motivation behind supporting dynamic, runtime changes to a Flink application by looking at a sample use case - a Fraud Detection engine. We have described the overall architecture and interactions between its components as well as provided references for building and running a demo Fraud Detection application in a dockerized setup. We then showed the details of implementing a **dynamic data partitioning pattern** as the first underlying building block to enable flexible runtime configurations.
+
+To remain focused on describing the core mechanics of the pattern, we kept the complexity of the DSL and the underlying rules engine to a minimum. Going forward, it is easy to imagine adding extensions such as allowing more sophisticated rule definitions, including filtering of certain events, logical rules chaining, and other more advanced functionality.
+
+In the second part of this series, we will describe how the rules make their way into the running Fraud Detection engine. Additionally, we will go over the implementation details of the main processing function of the pipeline - _DynamicAlertFunction()_.
+
+
+
+
+Figure 4: End-to-end pipeline
+
+
+
+In the [next article](/news/2020/03/24/demo-fraud-detection-2.html), we will see how Flink's broadcast streams can be utilized to help steer the processing within the Fraud Detection engine at runtime (Dynamic Application Updates pattern).
diff --git a/docs/content.tr/posts/2020-01-29-state-unlocked-interacting-with-state-in-apache-flink.md b/docs/content.tr/posts/2020-01-29-state-unlocked-interacting-with-state-in-apache-flink.md
new file mode 100644
index 0000000000..8b04dc28bd
--- /dev/null
+++ b/docs/content.tr/posts/2020-01-29-state-unlocked-interacting-with-state-in-apache-flink.md
@@ -0,0 +1,253 @@
+---
+authors:
+- name: Seth Wiesman
+ seth: null
+ twitter: sjwiesman
+date: "2020-01-29T12:00:00Z"
+excerpt: This post discusses the efforts of the Flink community as they relate to
+ state management in Apache Flink. We showcase some practical examples of how the
+ different features and APIs can be utilized and cover some future ideas for new
+ and improved ways of managing state in Apache Flink.
+title: 'State Unlocked: Interacting with State in Apache Flink'
+aliases:
+- /news/2020/01/29/state-unlocked-interacting-with-state-in-apache-flink.html
+---
+
+# Introduction
+
+With stateful stream-processing becoming the norm for complex event-driven applications and real-time analytics, [Apache Flink](https://flink.apache.org/) is often the backbone for running business logic and managing an organization’s most valuable asset — its data — as application state in Flink.
+
+In order to provide a state-of-the-art experience to Flink developers, the Apache Flink community makes significant efforts to provide the safety and future-proof guarantees organizations need while managing state in Flink. In particular, Flink developers should have sufficient means to access and modify their state, as well as making bootstrapping state with existing data from external systems a piece-of-cake. These efforts span multiple Flink major releases and consist of the following:
+
+1. Evolvable state schema in Apache Flink
+2. Flexibility in swapping state backends, and
+3. The State processor API, an offline tool to read, write and modify state in Flink
+
+This post discusses the community’s efforts related to state management in Flink, provides some practical examples of how the different features and APIs can be utilized and covers some future ideas for new and improved ways of managing state in Apache Flink.
+
+
+# Stream processing: What is State?
+
+To set the tone for the remaining of the post, let us first try to explain the very definition of state in stream processing. When it comes to stateful stream processing, state comprises of the information that an application or stream processing engine will remember across events and streams as more realtime (unbounded) and/or offline (bounded) data flow through the system. Most trivial applications are inherently stateful; even the example of a simple COUNT operation, whereby when counting up to 10, you essentially need to remember that you have already counted up to 9.
+
+To better understand how Flink manages state, one can think of Flink like a three-layered state abstraction, as illustrated in the diagram below.
+
+
+
+
+
+
+On the top layer, sits the Flink user code, for example, a `KeyedProcessFunction` that contains some value state. This is a simple variable whose value state annotations makes it automatically fault-tolerant, re-scalable and queryable by the runtime. These variables are backed by the configured state backend that sits either on-heap or on-disk (RocksDB State Backend) and provides data locality, proximity to the computation and speed when it comes to per-record computations. Finally, when it comes to upgrades, the introduction of new features or bug fixes, and in order to keep your existing state intact, this is where savepoints come in.
+
+A savepoint is a snapshot of the distributed, global state of an application at a logical point-in-time and is stored in an external distributed file system or blob storage such as HDFS, or S3. Upon upgrading an application or implementing a code change — such as adding a new operator or changing a field — the Flink job can restart by re-loading the application state from the savepoint into the state backend, making it local and available for the computation and continue processing as if nothing had ever happened.
+
+
+
+
+
+
+
+ It is important to remember here that state is one of the most valuable components of a Flink application carrying all the information about both where you are now and where you are going. State is among the most long-lived components in a Flink service since it can be carried across jobs, operators, configurations, new features and bug fixes.
+
+
+# Schema Evolution with Apache Flink
+
+In the previous section, we explained how state is stored and persisted in a Flink application. Let’s now take a look at what happens when evolving state in a stateful Flink streaming application becomes necessary.
+
+Imagine an Apache Flink application that implements a `KeyedProcessFunction` and contains some `ValueState`. As illustrated below, within the state descriptor, when registering the type, Flink users specify their `TypeInformation` that informs Flink about how to serialize the bytes and represents Flink’s internal type system, used to serialize data when shipped across the network or stored in state backends. Flink’s type system has built-in support for all the basic types such as longs, strings, doubles, arrays and basic collection types like lists and maps. Additionally, Flink supports most of the major composite types including Tuples, POJOs, Scala Case Classes and Apache AvroⓇ . Finally, if an application’s type does not match any of the above, developers can either plug in their own serializer or Flink will then fall back to Kryo.
+
+## State registration with built-in serialization in Apache Flink
+
+```java
+public class MyFunction extends KeyedProcessFunction {
+
+ private transient ValueState valueState;
+
+ public void open(Configuration parameters) {
+ ValueStateDescriptor descriptor =
+ new ValueStateDescriptor<>("my-state", TypeInformation.of(MyState.class));
+
+ valueState = getRuntimeContext().getState(descriptor);
+ }
+}
+```
+
+Typically, evolving the schema of an application’s state happens because of some business logic change (adding or dropping fields or changing data types). In all cases, the schema is determined by means of its serializer, and can be thought of in terms of an alter table statement when compared with a database. When a state variable is first introduced it is like running a `CREATE_TABLE` command, there is a lot of freedom with its execution. However, having data in that table (registered rows) limits developers in what they can do and what rules they follow in order to make updates or changes by an `ALTER_TABLE` statement. Schema migration in Apache Flink follows a similar principle since the framework is essentially running an `ALTER_TABLE` statement across savepoints.
+
+[Flink 1.8](https://flink.apache.org/downloads.html#apache-flink-182) comes with built-in support for [Apache Avro](https://avro.apache.org/) (specifically the [1.7.7 specification](https://avro.apache.org/docs/1.7.7/spec.html)) and evolves state schema according to Avro specifications by adding and removing types or even by swapping between generic and specific Avro record types.
+
+In [Flink 1.9](https://flink.apache.org/downloads.html#apache-flink-191) the community added support for schema evolution for POJOs, including the ability to remove existing fields from POJO types or add new fields. The POJO schema evolution tends to be less flexible — when compared to Avro — since it is not possible to change neither the declared field types nor the class name of a POJO type, including its namespace.
+
+With the community’s efforts related to schema evolution, Flink developers can now expect out-of-the-box support for both Avro and POJO formats, with backwards compatibility for all Flink state backends. Future work revolves around adding support for Scala Case Classes, Tuples and other formats. Make sure to subscribe to the [Flink mailing list](https://flink.apache.org/community.html) to contribute and stay on top of any upcoming additions in this space.
+
+## Peeking Under the Hood
+
+Now that we have explained how schema evolution in Flink works, let’s describe the challenges of performing schema serialization with Flink under the hood. Flink considers state as a core part of its API stability, in a way that developers should always be able to take a savepoint from one version of Flink and restart it on the next. With schema evolution, every migration needs to be backwards compatible and also compatible with the different state backends. While in the Flink code the state backends are represented as interfaces detailing how to store and retrieve bytes, in practice, they behave vastly differently, something that adds extra complexity to how schema evolution is executed in Flink.
+
+For instance, the heap state backend supports lazy serialization and eager deserialization, making the per-record code path always working with Java objects, serializing on a background thread. When restoring, Flink will eagerly deserialize all the data and then start the user code. If a developer plugs in a new serializer, the deserialization happens before Flink ever receives the information.
+
+The RocksDB state backend behaves in the exact opposite manner: it supports eager serialization — because of items being stored on disk and RocksDB only consuming byte arrays. RocksDB provides lazy deserialization simply by downloading files to the local disk, making Flink unaware of what the bytes mean until a serializer is registered.
+
+An additional challenge stems from the fact that different versions of user code contain different classes on their classpath making the serializer used to write into a savepoint likely potentially unavailable at runtime.
+
+To overcome the previously mentioned challenges, we introduced what we call `TypeSerializerSnapshot`. The `TypeSerializerSnapshot` stores the configuration of the writer serializer in the snapshot. When restoring it will use that configuration to read back the previous state and check its compatibility with the current version. Using such operation allows Flink to:
+
+* Read the configuration used to write out a snapshot
+* Consume the new user code
+* Check if both items above are compatible
+* Consume the bytes from the snapshot and move forward or alert the user otherwise
+
+```java
+public interface TypeSerializerSnapshot {
+
+ int getCurrentVersion();
+
+ void writeSnapshot(DataOutputView out) throws IOException;
+
+ void readSnapshot(
+ int readVersion,
+ DataInputView in,
+ ClassLoader userCodeClassLoader) throws IOException;
+
+ TypeSerializer restoreSerializer();
+
+ TypeSerializerSchemaCompatibility resolveSchemaCompatibility(
+ TypeSerializer newSerializer);
+}
+```
+
+## Implementing Apache Avro Serialization in Flink
+
+Apache Avro is a data serialization format that has very well-defined schema migration semantics and supports both reader and writer schemas. During normal Flink execution the reader and writer schemas will be the same. However, when upgrading an application they may be different and with schema evolution, Flink will be able to migrate objects with their schemas.
+
+```java
+public class AvroSerializerSnapshot implements TypeSerializerSnapshot {
+ private Schema runtimeSchema;
+ private Schema previousSchema;
+
+ @SuppressWarnings("WeakerAccess")
+ public AvroSerializerSnapshot() { }
+
+ AvroSerializerSnapshot(Schema schema) {
+ this.runtimeSchema = schema;
+ }
+```
+
+This is a sketch of our Avro serializer. It uses the provided schemas and delegates to Apache Avro for all (de)-serialization. Let’s take a look at one possible implementation of a `TypeSerializerSnapshot` that supports schema migration for Avro.
+
+
+# Writing out the snapshot
+
+When serializing out the snapshot, the snapshot configuration will write two pieces of information; the current snapshot configuration version and the serializer configuration.
+
+```java
+ @Override
+ public int getCurrentVersion() {
+ return 1;
+ }
+
+ @Override
+ public void writeSnapshot(DataOutputView out) throws IOException {
+ out.writeUTF(runtimeSchema.toString(false));
+ }
+```
+
+The version is used to version the snapshot configuration object itself while the `writeSnapshot` method writes out all the information we need to understand the current format; the runtime schema.
+
+```java
+ @Override
+ public void readSnapshot(
+ int readVersion,
+ DataInputView in,
+ ClassLoader userCodeClassLoader) throws IOException {
+
+ assert readVersion == 1;
+ final String previousSchemaDefinition = in.readUTF();
+ this.previousSchema = parseAvroSchema(previousSchemaDefinition);
+ this.runtimeType = findClassOrFallbackToGeneric(
+ userCodeClassLoader,
+ previousSchema.getFullName());
+
+ this.runtimeSchema = tryExtractAvroSchema(userCodeClassLoader, runtimeType);
+ }
+```
+Now when Flink restores it is able to read back in the writer schema used to serialize the data. The current runtime schema is discovered on the class path using some Java reflection magic.
+
+Once we have both of these we can compare them for compatibility. Perhaps nothing has changed and the schemas are compatible as is.
+
+```java
+ @Override
+ public TypeSerializerSchemaCompatibility resolveSchemaCompatibility(
+ TypeSerializer newSerializer) {
+
+ if (!(newSerializer instanceof AvroSerializer)) {
+ return TypeSerializerSchemaCompatibility.incompatible();
+ }
+
+ if (Objects.equals(previousSchema, runtimeSchema)) {
+ return TypeSerializerSchemaCompatibility.compatibleAsIs();
+ }
+```
+
+Otherwise, the schemas are compared using Avro’s compatibility checks and they may either be compatible with a migration or incompatible.
+
+```java
+ final SchemaPairCompatibility compatibility = SchemaCompatibility
+ .checkReaderWriterCompatibility(previousSchema, runtimeSchema);
+
+ return avroCompatibilityToFlinkCompatibility(compatibility);
+ }
+```
+
+If they are compatible with migration then Flink will restore a new serializer that can read the old schema and deserialize into the new runtime type which is in effect a migration.
+
+```java
+ @Override
+ public TypeSerializer restoreSerializer() {
+ if (previousSchema != null) {
+ return new AvroSerializer<>(runtimeType, runtimeSchema, previousSchema);
+ } else {
+ return new AvroSerializer<>(runtimeType, runtimeSchema, runtimeSchema);
+ }
+ }
+}
+```
+
+# The State Processor API: Reading, writing and modifying Flink state
+
+The State Processor API allows reading from and writing to Flink savepoints. Some of the interesting use cases it can be used for are:
+
+* Analyzing state for interesting patterns
+* Troubleshooting or auditing jobs by checking for state discrepancies
+* Bootstrapping state for new applications
+* Modifying savepoints such as:
+ * Changing the maximum parallelism of a savepoint after deploying a Flink job
+ * Introducing breaking schema updates to a Flink application
+ * Correcting invalid state in a Flink savepoint
+
+In a [previous blog post](https://flink.apache.org/feature/2019/09/13/state-processor-api.html), we discussed the State Processor API in detail, the community’s motivation behind introducing the feature in Flink 1.9, what you can use the API for and how you can use it. Essentially, the State Processor API is based around a relational model of mapping your Flink job state to a database, as illustrated in the diagram below. We encourage you to [read the previous story](https://flink.apache.org/feature/2019/09/13/state-processor-api.html) for more information on the API and how to use it. In a follow up post, we will provide detailed tutorials on:
+
+* Reading Keyed and Operator State with the State Processor API and
+* Writing and Bootstrapping Keyed and Operator State with the State Processor API
+
+Stay tuned for more details and guidance around this feature of Flink.
+
+
+
+
+
+
+
+
+
+
+
+# Looking ahead: More ways to interact with State in Flink
+
+There is a lot of discussion happening in the community related to extending the way Flink developers interact with state in their Flink applications. Regarding the State Processor API, some thoughts revolve around further broadening the API’s scope beyond its current ability to read from and write to both keyed and operator state. In upcoming releases, the State processor API will be extended to support both reading from and writing to windows and have a first-class integration with Flink’s Table API and SQL.
+
+Beyond widening the scope of the State Processor API, the Flink community is discussing a few additional ways to improve the way developers interact with state in Flink. One of them is the proposal for a Unified Savepoint Format ([FLIP-41](https://cwiki.apache.org/confluence/display/FLINK/FLIP-41%3A+Unify+Binary+format+for+Keyed+State)) for all keyed state backends. Such improvement aims at introducing a unified binary format across all savepoints in all keyed state backends, something that drastically reduces the overhead of swapping the state backend in a Flink application. Such an improvement would allow developers to take a savepoint in their application and restart it in a different state backend — for example, moving it from the heap to disk (RocksDB state backend) and back — depending on the scalability and evolution of the application at different points-in-time.
+
+The community is also discussing the ability to have upgradability dry runs in upcoming Flink releases. Having such functionality in Flink allows developers to detect incompatible updates offline without the need of starting a new Flink job from scratch. For example, Flink users will be able to uncover topology or schema incompatibilities upon upgrading a Flink job, without having to load the state back to a running Flink job in the first place. Additionally, with upgradability dry runs Flink users will be able to get information about the registered state through the streaming graph, without needing to access the state in the state backend.
+
+With all the exciting new functionality added in Flink 1.9 as well as some solid ideas and discussions around bringing state in Flink to the next level, the community is committed to making state in Apache Flink a fundamental element of the framework, something that is ever-present across versions and upgrades of your application and a component that is a true first-class citizen in Apache Flink. We encourage you to sign up to the [mailing list](https://flink.apache.org/community.html) and stay on top of the announcements and new features in upcoming releases.
diff --git a/docs/content.tr/posts/2020-01-30-release-1.9.2.md b/docs/content.tr/posts/2020-01-30-release-1.9.2.md
new file mode 100644
index 0000000000..11544c92c7
--- /dev/null
+++ b/docs/content.tr/posts/2020-01-30-release-1.9.2.md
@@ -0,0 +1,289 @@
+---
+authors:
+- hequn: null
+ name: Hequn Cheng
+ twitter: HequnC
+date: "2020-01-30T12:00:00Z"
+title: Apache Flink 1.9.2 Released
+aliases:
+- /news/2020/01/30/release-1.9.2.html
+---
+
+The Apache Flink community released the second bugfix version of the Apache Flink 1.9 series.
+
+This release includes 117 fixes and minor improvements for Flink 1.9.1. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.9.2.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.9.2
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.9.2
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.9.2
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-12122 ] - Spread out tasks evenly across all available registered TaskManagers
+
+[FLINK-13360 ] - Add documentation for HBase connector for Table API & SQL
+
+[FLINK-13361 ] - Add documentation for JDBC connector for Table API & SQL
+
+[FLINK-13723 ] - Use liquid-c for faster doc generation
+
+[FLINK-13724 ] - Remove unnecessary whitespace from the docs' sidenav
+
+[FLINK-13725 ] - Use sassc for faster doc generation
+
+[FLINK-13726 ] - Build docs with jekyll 4.0.0.pre.beta1
+
+[FLINK-13791 ] - Speed up sidenav by using group_by
+
+[FLINK-13817 ] - Expose whether web submissions are enabled
+
+[FLINK-13818 ] - Check whether web submission are enabled
+
+[FLINK-14535 ] - Cast exception is thrown when count distinct on decimal fields
+
+[FLINK-14735 ] - Improve batch schedule check input consumable performance
+
+
+
+ Bug
+
+
+[FLINK-10377 ] - Remove precondition in TwoPhaseCommitSinkFunction.notifyCheckpointComplete
+
+[FLINK-10435 ] - Client sporadically hangs after Ctrl + C
+
+[FLINK-11120 ] - TIMESTAMPADD function handles TIME incorrectly
+
+[FLINK-11835 ] - ZooKeeperLeaderElectionITCase.testJobExecutionOnClusterWithLeaderChange failed
+
+[FLINK-12342 ] - Yarn Resource Manager Acquires Too Many Containers
+
+[FLINK-12399 ] - FilterableTableSource does not use filters on job run
+
+[FLINK-13184 ] - Starting a TaskExecutor blocks the YarnResourceManager's main thread
+
+[FLINK-13589 ] - DelimitedInputFormat index error on multi-byte delimiters with whole file input splits
+
+[FLINK-13702 ] - BaseMapSerializerTest.testDuplicate fails on Travis
+
+[FLINK-13708 ] - Transformations should be cleared because a table environment could execute multiple job
+
+[FLINK-13740 ] - TableAggregateITCase.testNonkeyedFlatAggregate failed on Travis
+
+[FLINK-13749 ] - Make Flink client respect classloading policy
+
+[FLINK-13758 ] - Failed to submit JobGraph when registered hdfs file in DistributedCache
+
+[FLINK-13799 ] - Web Job Submit Page displays stream of error message when web submit is disables in the config
+
+[FLINK-13827 ] - Shell variable should be escaped in start-scala-shell.sh
+
+[FLINK-13862 ] - Update Execution Plan docs
+
+[FLINK-13945 ] - Instructions for building flink-shaded against vendor repository don't work
+
+[FLINK-13969 ] - Resuming Externalized Checkpoint (rocks, incremental, scale down) end-to-end test fails on Travis
+
+[FLINK-13995 ] - Fix shading of the licence information of netty
+
+[FLINK-13999 ] - Correct the documentation of MATCH_RECOGNIZE
+
+[FLINK-14066 ] - Pyflink building failure in master and 1.9.0 version
+
+[FLINK-14074 ] - MesosResourceManager can't create new taskmanagers in Session Cluster Mode.
+
+[FLINK-14175 ] - Upgrade KPL version in flink-connector-kinesis to fix application OOM
+
+[FLINK-14200 ] - Temporal Table Function Joins do not work on Tables (only TableSources) on the query side
+
+[FLINK-14235 ] - Kafka010ProducerITCase>KafkaProducerTestBase.testOneToOneAtLeastOnceCustomOperator fails on travis
+
+[FLINK-14315 ] - NPE with JobMaster.disconnectTaskManager
+
+[FLINK-14337 ] - HistoryServer does not handle NPE on corruped archives properly
+
+[FLINK-14347 ] - YARNSessionFIFOITCase.checkForProhibitedLogContents found a log with prohibited string
+
+[FLINK-14355 ] - Example code in state processor API docs doesn't compile
+
+[FLINK-14370 ] - KafkaProducerAtLeastOnceITCase>KafkaProducerTestBase.testOneToOneAtLeastOnceRegularSink fails on Travis
+
+[FLINK-14382 ] - Incorrect handling of FLINK_PLUGINS_DIR on Yarn
+
+[FLINK-14398 ] - Further split input unboxing code into separate methods
+
+[FLINK-14413 ] - Shade-plugin ApacheNoticeResourceTransformer uses platform-dependent encoding
+
+[FLINK-14434 ] - Dispatcher#createJobManagerRunner should not start JobManagerRunner
+
+[FLINK-14445 ] - Python module build failed when making sdist
+
+[FLINK-14447 ] - Network metrics doc table render confusion
+
+[FLINK-14459 ] - Python module build hangs
+
+[FLINK-14524 ] - PostgreSQL JDBC sink generates invalid SQL in upsert mode
+
+[FLINK-14547 ] - UDF cannot be in the join condition in blink planner
+
+[FLINK-14561 ] - Don't write FLINK_PLUGINS_DIR ENV variable to Flink configuration
+
+[FLINK-14562 ] - RMQSource leaves idle consumer after closing
+
+[FLINK-14574 ] - flink-s3-fs-hadoop doesn't work with plugins mechanism
+
+[FLINK-14589 ] - Redundant slot requests with the same AllocationID leads to inconsistent slot table
+
+[FLINK-14641 ] - Fix description of metric `fullRestarts`
+
+[FLINK-14673 ] - Shouldn't expect HMS client to throw NoSuchObjectException for non-existing function
+
+[FLINK-14683 ] - RemoteStreamEnvironment's construction function has a wrong method
+
+[FLINK-14701 ] - Slot leaks if SharedSlotOversubscribedException happens
+
+[FLINK-14784 ] - CsvTableSink miss delimiter when row start with null member
+
+[FLINK-14817 ] - "Streaming Aggregation" document contains misleading code examples
+
+[FLINK-14846 ] - Correct the default writerbuffer size documentation of RocksDB
+
+[FLINK-14910 ] - DisableAutoGeneratedUIDs fails on keyBy
+
+[FLINK-14930 ] - OSS Filesystem Uses Wrong Shading Prefix
+
+[FLINK-14949 ] - Task cancellation can be stuck against out-of-thread error
+
+[FLINK-14951 ] - State TTL backend end-to-end test fail when taskManager has multiple slot
+
+[FLINK-14953 ] - Parquet table source should use schema type to build FilterPredicate
+
+[FLINK-14960 ] - Dependency shading of table modules test fails on Travis
+
+[FLINK-14976 ] - Cassandra Connector leaks Semaphore on Throwable; hangs on close
+
+[FLINK-15001 ] - The digest of sub-plan reuse should contain retraction traits for stream physical nodes
+
+[FLINK-15013 ] - Flink (on YARN) sometimes needs too many slots
+
+[FLINK-15030 ] - Potential deadlock for bounded blocking ResultPartition.
+
+[FLINK-15036 ] - Container startup error will be handled out side of the YarnResourceManager's main thread
+
+[FLINK-15063 ] - Input group and output group of the task metric are reversed
+
+[FLINK-15065 ] - RocksDB configurable options doc description error
+
+[FLINK-15076 ] - Source thread should be interrupted during the Task cancellation
+
+[FLINK-15234 ] - Hive table created from flink catalog table shouldn't have null properties in parameters
+
+[FLINK-15240 ] - is_generic key is missing for Flink table stored in HiveCatalog
+
+[FLINK-15259 ] - HiveInspector.toInspectors() should convert Flink constant to Hive constant
+
+[FLINK-15266 ] - NPE in blink planner code gen
+
+[FLINK-15361 ] - ParquetTableSource should pass predicate in projectFields
+
+[FLINK-15412 ] - LocalExecutorITCase#testParameterizedTypes failed in travis
+
+[FLINK-15413 ] - ScalarOperatorsTest failed in travis
+
+[FLINK-15418 ] - StreamExecMatchRule not set FlinkRelDistribution
+
+[FLINK-15421 ] - GroupAggsHandler throws java.time.LocalDateTime cannot be cast to java.sql.Timestamp
+
+[FLINK-15435 ] - ExecutionConfigTests.test_equals_and_hash in pyFlink fails when cpu core numbers is 6
+
+[FLINK-15443 ] - Use JDBC connector write FLOAT value occur ClassCastException
+
+[FLINK-15478 ] - FROM_BASE64 code gen type wrong
+
+[FLINK-15489 ] - WebUI log refresh not working
+
+[FLINK-15522 ] - Misleading root cause exception when cancelling the job
+
+[FLINK-15523 ] - ConfigConstants generally excluded from japicmp
+
+[FLINK-15543 ] - Apache Camel not bundled but listed in flink-dist NOTICE
+
+[FLINK-15549 ] - Integer overflow in SpillingResettableMutableObjectIterator
+
+[FLINK-15577 ] - WindowAggregate RelNodes missing Window specs in digest
+
+[FLINK-15615 ] - Docs: wrong guarantees stated for the file sink
+
+
+
+ Improvement
+
+
+[FLINK-11135 ] - Reorder Hadoop config loading in HadoopUtils
+
+[FLINK-12848 ] - Method equals() in RowTypeInfo should consider fieldsNames
+
+[FLINK-13729 ] - Update website generation dependencies
+
+[FLINK-14008 ] - Auto-generate binary licensing
+
+[FLINK-14104 ] - Bump Jackson to 2.10.1
+
+[FLINK-14123 ] - Lower the default value of taskmanager.memory.fraction
+
+[FLINK-14206 ] - Let fullRestart metric count fine grained restarts as well
+
+[FLINK-14215 ] - Add Docs for TM and JM Environment Variable Setting
+
+[FLINK-14251 ] - Add FutureUtils#forward utility
+
+[FLINK-14334 ] - ElasticSearch docs refer to non-existent ExceptionUtils.containsThrowable
+
+[FLINK-14335 ] - ExampleIntegrationTest in testing docs is incorrect
+
+[FLINK-14408 ] - In OldPlanner, UDF open method can not be invoke when SQL is optimized
+
+[FLINK-14557 ] - Clean up the package of py4j
+
+[FLINK-14639 ] - Metrics User Scope docs refer to wrong class
+
+[FLINK-14646 ] - Check non-null for key in KeyGroupStreamPartitioner
+
+[FLINK-14825 ] - Rework state processor api documentation
+
+[FLINK-14995 ] - Kinesis NOTICE is incorrect
+
+[FLINK-15113 ] - fs.azure.account.key not hidden from global configuration
+
+[FLINK-15554 ] - Bump jetty-util-ajax to 9.3.24
+
+[FLINK-15657 ] - Fix the python table api doc link in Python API tutorial
+
+[FLINK-15700 ] - Improve Python API Tutorial doc
+
+[FLINK-15726 ] - Fixing error message in StreamExecTableSourceScan
+
+
diff --git a/docs/content.tr/posts/2020-02-03-a-guide-for-unit-testing-in-apache-flink.md b/docs/content.tr/posts/2020-02-03-a-guide-for-unit-testing-in-apache-flink.md
new file mode 100644
index 0000000000..02ca23c393
--- /dev/null
+++ b/docs/content.tr/posts/2020-02-03-a-guide-for-unit-testing-in-apache-flink.md
@@ -0,0 +1,250 @@
+---
+authors:
+- kartik: null
+ name: Kartik Khare
+ twitter: khare_khote
+date: "2020-02-03T12:00:00Z"
+excerpt: This post provides a detailed guide for unit testing of Apache Flink applications.
+title: A Guide for Unit Testing in Apache Flink
+aliases:
+- /news/2020/02/07/a-guide-for-unit-testing-in-apache-flink.html
+---
+
+Writing unit tests is one of the essential tasks of designing a production-grade application. Without tests, a single change in code can result in cascades of failure in production. Thus unit tests should be written for all types of applications, be it a simple job cleaning data and training a model or a complex multi-tenant, real-time data processing system. In the following sections, we provide a guide for unit testing of Apache Flink applications.
+Apache Flink provides a robust unit testing framework to make sure your applications behave in production as expected during development. You need to include the following dependencies to utilize the provided framework.
+
+```xml
+
+ org.apache.flink
+ flink-test-utils_${scala.binary.version}
+ ${flink.version}
+ test
+
+
+ org.apache.flink
+ flink-runtime_${scala.binary.version}
+ ${flink.version}
+ test
+ tests
+
+
+ org.apache.flink
+ flink-streaming-java_${scala.binary.version}
+ ${flink.version}
+ test
+ tests
+
+```
+
+The strategy of writing unit tests differs for various operators. You can break down the strategy into the following three buckets:
+
+* Stateless Operators
+* Stateful Operators
+* Timed Process Operators
+
+
+# Stateless Operators
+
+Writing unit tests for a stateless operator is a breeze. You need to follow the basic norm of writing a test case, i.e., create an instance of the function class and test the appropriate methods. Let’s take an example of a simple `Map` operator.
+
+```java
+public class MyStatelessMap implements MapFunction {
+ @Override
+ public String map(String in) throws Exception {
+ String out = "hello " + in;
+ return out;
+ }
+}
+```
+
+The test case for the above operator should look like
+
+```java
+@Test
+public void testMap() throws Exception {
+ MyStatelessMap statelessMap = new MyStatelessMap();
+ String out = statelessMap.map("world");
+ Assert.assertEquals("hello world", out);
+}
+```
+
+Pretty simple, right? Let’s take a look at one for the `FlatMap` operator.
+
+```java
+public class MyStatelessFlatMap implements FlatMapFunction {
+ @Override
+ public void flatMap(String in, Collector collector) throws Exception {
+ String out = "hello " + in;
+ collector.collect(out);
+ }
+}
+```
+
+`FlatMap` operators require a `Collector` object along with the input. For the test case, we have two options:
+
+1. Mock the `Collector` object using Mockito
+2. Use the `ListCollector` provided by Flink
+
+I prefer the second method as it requires fewer lines of code and is suitable for most of the cases.
+
+```java
+@Test
+public void testFlatMap() throws Exception {
+ MyStatelessFlatMap statelessFlatMap = new MyStatelessFlatMap();
+ List out = new ArrayList<>();
+ ListCollector listCollector = new ListCollector<>(out);
+ statelessFlatMap.flatMap("world", listCollector);
+ Assert.assertEquals(Lists.newArrayList("hello world"), out);
+}
+```
+
+
+# Stateful Operators
+
+Writing test cases for stateful operators requires more effort. You need to check whether the operator state is updated correctly and if it is cleaned up properly along with the output of the operator.
+
+Let’s take an example of stateful `FlatMap` function
+
+```java
+public class StatefulFlatMap extends RichFlatMapFunction {
+ ValueState previousInput;
+
+ @Override
+ public void open(Configuration parameters) throws Exception {
+ previousInput = getRuntimeContext().getState(
+ new ValueStateDescriptor("previousInput", Types.STRING));
+ }
+
+ @Override
+ public void flatMap(String in, Collector collector) throws Exception {
+ String out = "hello " + in;
+ if(previousInput.value() != null){
+ out = out + " " + previousInput.value();
+ }
+ previousInput.update(in);
+ collector.collect(out);
+ }
+}
+```
+
+The intricate part of writing tests for the above class is to mock the configuration as well as the runtime context of the application. Flink provides TestHarness classes so that users don’t have to create the mock objects themselves. Using the `KeyedOperatorHarness`, the test looks like:
+
+```java
+import org.apache.flink.streaming.api.operators.StreamFlatMap;
+import org.apache.flink.streaming.runtime.streamrecord.StreamRecord;
+import org.apache.flink.streaming.util.KeyedOneInputStreamOperatorTestHarness;
+import org.apache.flink.streaming.util.OneInputStreamOperatorTestHarness;
+
+@Test
+public void testFlatMap() throws Exception{
+ StatefulFlatMap statefulFlatMap = new StatefulFlatMap();
+
+ // OneInputStreamOperatorTestHarness takes the input and output types as type parameters
+ OneInputStreamOperatorTestHarness testHarness =
+ // KeyedOneInputStreamOperatorTestHarness takes three arguments:
+ // Flink operator object, key selector and key type
+ new KeyedOneInputStreamOperatorTestHarness<>(
+ new StreamFlatMap<>(statefulFlatMap), x -> "1", Types.STRING);
+ testHarness.open();
+
+ // test first record
+ testHarness.processElement("world", 10);
+ ValueState previousInput =
+ statefulFlatMap.getRuntimeContext().getState(
+ new ValueStateDescriptor<>("previousInput", Types.STRING));
+ String stateValue = previousInput.value();
+ Assert.assertEquals(
+ Lists.newArrayList(new StreamRecord<>("hello world", 10)),
+ testHarness.extractOutputStreamRecords());
+ Assert.assertEquals("world", stateValue);
+
+ // test second record
+ testHarness.processElement("parallel", 20);
+ Assert.assertEquals(
+ Lists.newArrayList(
+ new StreamRecord<>("hello world", 10),
+ new StreamRecord<>("hello parallel world", 20)),
+ testHarness.extractOutputStreamRecords());
+ Assert.assertEquals("parallel", previousInput.value());
+}
+```
+
+The test harness provides many helper methods, three of which are being used here:
+
+1. `open`: calls the open of the `FlatMap` function with relevant parameters. It also initializes the context.
+2. `processElement`: allows users to pass an input element as well as the timestamp associated with the element.
+3. `extractOutputStreamRecords`: gets the output records along with their timestamps from the `Collector`.
+
+The test harness simplifies the unit testing for the stateful functions to a large extent.
+
+You might also need to check whether the state value is being set correctly. You can get the state value directly from the operator using a mechanism similar to the one used while creating the state. This is also demonstrated in the previous example.
+
+
+# Timed Process Operators
+
+Writing tests for process functions, that work with time, is quite similar to writing tests for stateful functions because you can also use test harness.
+However, you need to take care of another aspect, which is providing timestamps for events and controlling the current time of the application. By setting the current (processing or event) time, you can trigger registered timers, which will call the `onTimer` method of the function
+
+```java
+public class MyProcessFunction extends KeyedProcessFunction {
+ @Override
+ public void processElement(String in, Context context, Collector collector) throws Exception {
+ context.timerService().registerProcessingTimeTimer(50);
+ String out = "hello " + in;
+ collector.collect(out);
+ }
+
+ @Override
+ public void onTimer(long timestamp, OnTimerContext ctx, Collector out) throws Exception {
+ out.collect(String.format("Timer triggered at timestamp %d", timestamp));
+ }
+}
+```
+
+We need to test both the methods in the `KeyedProcessFunction`, i.e., `processElement` as well as `onTimer`. Using a test harness, we can control the current time of the function. Thus, we can trigger the timer at will rather than waiting for a specific time.
+
+Let’s take a look at the test case
+
+```java
+@Test
+public void testProcessElement() throws Exception{
+ MyProcessFunction myProcessFunction = new MyProcessFunction();
+ OneInputStreamOperatorTestHarness testHarness =
+ new KeyedOneInputStreamOperatorTestHarness<>(
+ new KeyedProcessOperator<>(myProcessFunction), x -> "1", Types.STRING);
+
+ // Function time is initialized to 0
+ testHarness.open();
+ testHarness.processElement("world", 10);
+
+ Assert.assertEquals(
+ Lists.newArrayList(new StreamRecord<>("hello world", 10)),
+ testHarness.extractOutputStreamRecords());
+}
+
+@Test
+public void testOnTimer() throws Exception {
+ MyProcessFunction myProcessFunction = new MyProcessFunction();
+ OneInputStreamOperatorTestHarness testHarness =
+ new KeyedOneInputStreamOperatorTestHarness<>(
+ new KeyedProcessOperator<>(myProcessFunction), x -> "1", Types.STRING);
+
+ testHarness.open();
+ testHarness.processElement("world", 10);
+ Assert.assertEquals(1, testHarness.numProcessingTimeTimers());
+
+ // Function time is set to 50
+ testHarness.setProcessingTime(50);
+ Assert.assertEquals(
+ Lists.newArrayList(
+ new StreamRecord<>("hello world", 10),
+ new StreamRecord<>("Timer triggered at timestamp 50")),
+ testHarness.extractOutputStreamRecords());
+}
+```
+
+The mechanism to test the multi-input stream operators such as CoProcess functions is similar to the ones described in this article. You should use the TwoInput variant of the harness for these operators, such as `TwoInputStreamOperatorTestHarness`.
+
+# Summary
+
+In the previous sections we showcased how unit testing in Apache Flink works for stateless, stateful and times-aware-operators. We hope you found the steps easy to follow and execute while developing your Flink applications. If you have any questions or feedback you can reach out to me [here](https://www.kharekartik.dev/about/) or contact the community on the [Apache Flink user mailing list](https://flink.apache.org/community.html).
diff --git a/docs/content.tr/posts/2020-02-11-release-1.10.0.md b/docs/content.tr/posts/2020-02-11-release-1.10.0.md
new file mode 100644
index 0000000000..bd084185e2
--- /dev/null
+++ b/docs/content.tr/posts/2020-02-11-release-1.10.0.md
@@ -0,0 +1,204 @@
+---
+authors:
+- morsapaes: null
+ name: Marta Paes
+ twitter: morsapaes
+date: "2020-02-11T02:30:00Z"
+title: Apache Flink 1.10.0 Release Announcement
+aliases:
+- /news/2020/02/11/release-1.10.0.html
+---
+
+
+The Apache Flink community is excited to hit the double digits and announce the release of Flink 1.10.0! As a result of the biggest community effort to date, with over 1.2k issues implemented and more than 200 contributors, this release introduces significant improvements to the overall performance and stability of Flink jobs, a preview of native Kubernetes integration and great advances in Python support (PyFlink).
+
+Flink 1.10 also marks the completion of the [Blink integration](https://flink.apache.org/news/2019/08/22/release-1.9.0.html#preview-of-the-new-blink-sql-query-processor), hardening streaming SQL and bringing mature batch processing to Flink with production-ready Hive integration and TPC-DS coverage. This blog post describes all major new features and improvements, important changes to be aware of and what to expect moving forward.
+
+The binary distribution and source artifacts are now available on the updated [Downloads page](/downloads.html) of the Flink website. For more details, check the complete [release changelog](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12345845) and the [updated documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.10/). We encourage you to download the release and share your feedback with the community through the [Flink mailing lists](https://flink.apache.org/community.html#mailing-lists) or [JIRA](https://issues.apache.org/jira/projects/FLINK/summary).
+
+
+## New Features and Improvements
+
+
+### Improved Memory Management and Configuration
+
+The current `TaskExecutor` memory configuration in Flink has some shortcomings that make it hard to reason about or optimize resource utilization, such as:
+
+* Different configuration models for memory footprint in Streaming and Batch execution;
+
+* Complex and user-dependent configuration of off-heap state backends (i.e. RocksDB) in Streaming execution.
+
+To make memory options more explicit and intuitive to users, Flink 1.10 introduces significant changes to the `TaskExecutor` memory model and configuration logic ([FLIP-49](https://cwiki.apache.org/confluence/display/FLINK/FLIP-49%3A+Unified+Memory+Configuration+for+TaskExecutors)). These changes make Flink more adaptable to all kinds of deployment environments (e.g. Kubernetes, Yarn, Mesos), giving users strict control over its memory consumption.
+
+**Managed Memory Extension**
+
+Managed memory was extended to also account for memory usage of `RocksDBStateBackend`. While batch jobs can use either on-heap or off-heap memory, streaming jobs with `RocksDBStateBackend` can use off-heap memory only. Therefore, to allow users to switch between Streaming and Batch execution without having to modify cluster configurations, managed memory is now always off-heap.
+
+**Simplified RocksDB Configuration**
+
+Configuring an off-heap state backend like RocksDB used to involve a good deal of manual tuning, like decreasing the JVM heap size or setting Flink to use off-heap memory. This can now be achieved through Flink's out-of-box configuration, and adjusting the memory budget for `RocksDBStateBackend` is as simple as resizing the managed memory size.
+
+Another important improvement was to allow Flink to bind RocksDB native memory usage ([FLINK-7289](https://issues.apache.org/jira/browse/FLINK-7289)), preventing it from exceeding its total memory budget — this is especially relevant in containerized environments like Kubernetes. For details on how to enable and tune this feature, refer to [Tuning RocksDB]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/state/large_state_tuning.html#tuning-rocksdb).
+
+Note FLIP-49 changes the process of cluster resource configuration, which may require tuning your clusters for upgrades from previous Flink versions. For a comprehensive overview of the changes introduced and tuning guidance, consult [this setup]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/memory/mem_setup.html).
+
+
+### Unified Logic for Job Submission
+
+Prior to this release, job submission was part of the duties of the Execution Environments and closely tied to the different deployment targets (e.g. Yarn, Kubernetes, Mesos). This led to a poor separation of concerns and, over time, to a growing number of customized environments that users needed to configure and manage separately.
+
+In Flink 1.10, job submission logic is abstracted into the generic `Executor` interface ([FLIP-73](https://cwiki.apache.org/confluence/display/FLINK/FLIP-73%3A+Introducing+Executors+for+job+submission)). The addition of the `ExecutorCLI` ([FLIP-81](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=133631524)) introduces a unified way to specify configuration parameters for **any** [execution target]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/cli.html#deployment-targets). To round up this effort, the process of result retrieval was also decoupled from job submission with the introduction of a `JobClient` ([FLINK-74](https://cwiki.apache.org/confluence/display/FLINK/FLIP-74%3A+Flink+JobClient+API)), responsible for fetching the `JobExecutionResult`.
+
+
+
+
+
+
+
+In particular, these changes make it much easier to programmatically use Flink in downstream frameworks — for example, Apache Beam or Zeppelin interactive notebooks — by providing users with a unified entry point to Flink. For users working with Flink across multiple target environments, the transition to a configuration-based execution process also significantly reduces boilerplate code and maintainability overhead.
+
+### Native Kubernetes Integration (Beta)
+
+For users looking to get started with Flink on a containerized environment, deploying and managing a standalone cluster on top of Kubernetes requires some upfront knowledge about containers, operators and environment-specific tools like `kubectl`.
+
+In Flink 1.10, we rolled out the first phase of **Active Kubernetes Integration** ([FLINK-9953](https://jira.apache.org/jira/browse/FLINK-9953)) with support for session clusters (with per-job planned). In this context, “active” means that Flink’s ResourceManager (`K8sResMngr`) natively communicates with Kubernetes to allocate new pods on-demand, similar to Flink’s Yarn and Mesos integration. Users can also leverage namespaces to launch Flink clusters for multi-tenant environments with limited aggregate resource consumption. RBAC roles and service accounts with enough permission should be configured beforehand.
+
+
+
+
+
+
+
+As introduced in [Unified Logic For Job Submission](#unified-logic-for-job-submission), all command-line options in Flink 1.10 are mapped to a unified configuration. For this reason, users can simply refer to the Kubernetes config options and submit a job to an existing Flink session on Kubernetes in the CLI using:
+
+```bash
+./bin/flink run -d -e kubernetes-session -Dkubernetes.cluster-id= examples/streaming/WindowJoin.jar
+```
+
+If you want to try out this preview feature, we encourage you to walk through the [Native Kubernetes setup]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/deployment/native_kubernetes.html), play around with it and share feedback with the community.
+
+### Table API/SQL: Production-ready Hive Integration
+
+Hive integration was announced as a preview feature in Flink 1.9. This preview allowed users to persist Flink-specific metadata (e.g. Kafka tables) in Hive Metastore using SQL DDL, call UDFs defined in Hive and use Flink for reading and writing Hive tables. Flink 1.10 rounds up this effort with further developments that bring production-ready Hive integration to Flink with full compatibility of [most Hive versions]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/table/hive/#supported-hive-versions).
+
+#### Native Partition Support for Batch SQL
+
+So far, only writes to non-partitioned Hive tables were supported. In Flink 1.10, the Flink SQL syntax has been extended with `INSERT OVERWRITE` and `PARTITION` ([FLIP-63](https://cwiki.apache.org/confluence/display/FLINK/FLIP-63%3A+Rework+table+partition+support)), enabling users to write into both static and dynamic partitions in Hive.
+
+**Static Partition Writing**
+
+```sql
+INSERT { INTO | OVERWRITE } TABLE tablename1 [PARTITION (partcol1=val1, partcol2=val2 ...)] select_statement1 FROM from_statement;
+```
+
+**Dynamic Partition Writing**
+
+```sql
+INSERT { INTO | OVERWRITE } TABLE tablename1 select_statement1 FROM from_statement;
+```
+
+Fully supporting partitioned tables allows users to take advantage of partition pruning on read, which significantly increases the performance of these operations by reducing the amount of data that needs to be scanned.
+
+#### Further Optimizations
+
+Besides partition pruning, Flink 1.10 introduces more [read optimizations]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/table/hive/read_write_hive.html#optimizations) to Hive integration, such as:
+
+* **Projection pushdown:** Flink leverages projection pushdown to minimize data transfer between Flink and Hive tables by omitting unnecessary fields from table scans. This is especially beneficial for tables with a large number of columns.
+
+* **LIMIT pushdown:** for queries with the `LIMIT` clause, Flink will limit the number of output records wherever possible to minimize the amount of data transferred across the network.
+
+* **ORC Vectorization on Read:** to boost read performance for ORC files, Flink now uses the native ORC Vectorized Reader by default for Hive versions above 2.0.0 and columns with non-complex data types.
+
+#### Pluggable Modules as Flink System Objects (Beta)
+
+Flink 1.10 introduces a generic mechanism for pluggable modules in the Flink table core, with a first focus on system functions ([FLIP-68](https://cwiki.apache.org/confluence/display/FLINK/FLIP-68%3A+Extend+Core+Table+System+with+Pluggable+Modules)). With modules, users can extend Flink’s system objects — for example use Hive built-in functions that behave like Flink system functions. This release ships with a pre-implemented `HiveModule`, supporting multiple Hive versions, but users are also given the possibility to [write their own pluggable modules]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/table/modules.html).
+
+### Other Improvements to the Table API/SQL
+
+#### Watermarks and Computed Columns in SQL DDL
+
+Flink 1.10 supports stream-specific syntax extensions to define time attributes and watermark generation in Flink SQL DDL ([FLIP-66](https://cwiki.apache.org/confluence/display/FLINK/FLIP-66%3A+Support+Time+Attribute+in+SQL+DDL)). This allows time-based operations, like windowing, and the definition of [watermark strategies]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/table/sql/create.html#create-table) on tables created using DDL statements.
+
+```sql
+CREATE TABLE table_name (
+
+ WATERMARK FOR columnName AS
+
+) WITH (
+ ...
+)
+```
+
+This release also introduces support for virtual computed columns ([FLIP-70](https://cwiki.apache.org/confluence/display/FLINK/FLIP-70%3A+Flink+SQL+Computed+Column+Design)) that can be derived based on other columns in the same table or deterministic expressions (i.e. literal values, UDFs and built-in functions). In Flink, computed columns are useful to define time attributes [upon table creation]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/table/sql/create.html#create-table).
+
+#### Additional Extensions to SQL DDL
+
+There is now a clear distinction between temporary/persistent and system/catalog functions ([FLIP-57](https://cwiki.apache.org/confluence/display/FLINK/FLIP-57%3A+Rework+FunctionCatalog)). This not only eliminates ambiguity in function reference, but also allows for deterministic function resolution order (i.e. in case of naming collision, system functions will precede catalog functions, with temporary functions taking precedence over persistent functions for both dimensions).
+
+Following the groundwork in FLIP-57, we extended the SQL DDL syntax to support the creation of catalog functions, temporary functions and temporary system functions ([FLIP-79](https://cwiki.apache.org/confluence/display/FLINK/FLIP-79+Flink+Function+DDL+Support)):
+
+```sql
+CREATE [TEMPORARY|TEMPORARY SYSTEM] FUNCTION
+
+ [IF NOT EXISTS] [catalog_name.][db_name.]function_name
+
+AS identifier [LANGUAGE JAVA|SCALA]
+```
+
+For a complete overview of the current state of DDL support in Flink SQL, check the [updated documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/table/sql/).
+
+Note In order to correctly handle and guarantee a consistent behavior across meta-objects (tables, views, functions) in the future, some object declaration methods in the Table API have been deprecated in favor of methods that are closer to standard SQL DDL ([FLIP-64](https://cwiki.apache.org/confluence/display/FLINK/FLIP-64%3A+Support+for+Temporary+Objects+in+Table+module)).
+
+#### Full TPC-DS Coverage for Batch
+
+TPC-DS is a widely used industry-standard decision support benchmark to evaluate and measure the performance of SQL-based data processing engines. In Flink 1.10, all TPC-DS queries are supported end-to-end ([FLINK-11491](https://issues.apache.org/jira/browse/FLINK-11491)), reflecting the readiness of its SQL engine to address the needs of modern data warehouse-like workloads.
+
+### PyFlink: Support for Native User Defined Functions (UDFs)
+
+A preview of PyFlink was introduced in the previous release, making headway towards the goal of full Python support in Flink. For this release, the focus was to enable users to register and use Python User-Defined Functions (UDF, with UDTF/UDAF planned) in the Table API/SQL ([FLIP-58](https://cwiki.apache.org/confluence/display/FLINK/FLIP-58%3A+Flink+Python+User-Defined+Stateless+Function+for+Table)).
+
+
+
+
+
+
+
+If you are interested in the underlying implementation — leveraging Apache Beam’s [Portability Framework](https://beam.apache.org/roadmap/portability/) — refer to the “Architecture” section of FLIP-58 and also to [FLIP-78](https://cwiki.apache.org/confluence/display/FLINK/FLIP-78%3A+Flink+Python+UDF+Environment+and+Dependency+Management). These data structures lay the required foundation for Pandas support and for PyFlink to eventually reach the DataStream API.
+
+From Flink 1.10, users can also easily install PyFlink through `pip` using:
+
+```bash
+pip install apache-flink
+```
+
+For a preview of other improvements planned for PyFlink, check [FLINK-14500](https://issues.apache.org/jira/browse/FLINK-14500) and get involved in the [discussion](http://apache-flink.147419.n8.nabble.com/Re-DISCUSS-What-parts-of-the-Python-API-should-we-focus-on-next-td1285.html) for requested user features.
+
+## Important Changes
+
+ * [[FLINK-10725](https://issues.apache.org/jira/browse/FLINK-10725)] Flink can now be compiled and run on Java 11.
+
+ * [[FLINK-15495](https://jira.apache.org/jira/browse/FLINK-15495)] The Blink planner is now the default in the SQL Client, so that users can benefit from all the latest features and improvements. The switch from the old planner in the Table API is also planned for the next release, so we recommend that users start getting familiar with the Blink planner.
+
+ * [[FLINK-13025](https://issues.apache.org/jira/browse/FLINK-13025)] There is a [new Elasticsearch sink connector]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/connectors/elasticsearch.html#elasticsearch-connector), fully supporting Elasticsearch 7.x versions.
+
+ * [[FLINK-15115](https://issues.apache.org/jira/browse/FLINK-15115)] The connectors for Kafka 0.8 and 0.9 have been marked as deprecated and will no longer be actively supported. If you are still using these versions or have any other related concerns, please reach out to the @dev mailing list.
+
+ * [[FLINK-14516](https://issues.apache.org/jira/browse/FLINK-14516)] The non-credit-based network flow control code was removed, along with the configuration option `taskmanager.network.credit.model`. Moving forward, Flink will always use credit-based flow control.
+
+ * [[FLINK-12122](https://issues.apache.org/jira/browse/FLINK-12122)] [FLIP-6](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=65147077) was rolled out with Flink 1.5.0 and introduced a code regression related to the way slots are allocated from `TaskManagers`. To use a scheduling strategy that is closer to the pre-FLIP behavior, where Flink tries to spread out the workload across all currently available `TaskManagers`, users can set `cluster.evenly-spread-out-slots: true` in the `flink-conf.yaml`.
+
+ * [[FLINK-11956](https://issues.apache.org/jira/browse/FLINK-11956)] `s3-hadoop` and `s3-presto` filesystems no longer use class relocations and should be loaded through [plugins]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/filesystems/#pluggable-file-systems), but now seamlessly integrate with all credential providers. Other filesystems are strongly recommended to be used only as plugins, as we will continue to remove relocations.
+
+ * Flink 1.9 shipped with a refactored Web UI, with the legacy one being kept around as backup in case something wasn’t working as expected. No issues have been reported so far, so [the community voted](http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Remove-old-WebUI-td35218.html) to drop the legacy Web UI in Flink 1.10.
+
+
+## Release Notes
+
+Please review the [release notes]({{< param DocsBaseUrl >}}flink-docs-release-1.10/release-notes/flink-1.10.html) carefully for a detailed list of changes and new features if you plan to upgrade your setup to Flink 1.10. This version is API-compatible with previous 1.x releases for APIs annotated with the @Public annotation.
+
+
+## List of Contributors
+
+The Apache Flink community would like to thank all contributors that have made this release possible:
+
+Achyuth Samudrala, Aitozi, Alberto Romero, Alec.Ch, Aleksey Pak, Alexander Fedulov, Alice Yan, Aljoscha Krettek, Aloys, Andrey Zagrebin, Arvid Heise, Benchao Li, Benoit Hanotte, Benoît Paris, Bhagavan Das, Biao Liu, Chesnay Schepler, Congxian Qiu, Cyrille Chépélov, César Soto Valero, David Anderson, David Hrbacek, David Moravek, Dawid Wysakowicz, Dezhi Cai, Dian Fu, Dyana Rose, Eamon Taaffe, Fabian Hueske, Fawad Halim, Fokko Driesprong, Frey Gao, Gabor Gevay, Gao Yun, Gary Yao, GatsbyNewton, GitHub, Grebennikov Roman, GuoWei Ma, Gyula Fora, Haibo Sun, Hao Dang, Henvealf, Hongtao Zhang, HuangXingBo, Hwanju Kim, Igal Shilman, Jacob Sevart, Jark Wu, Jeff Martin, Jeff Yang, Jeff Zhang, Jiangjie (Becket) Qin, Jiayi, Jiayi Liao, Jincheng Sun, Jing Zhang, Jingsong Lee, JingsongLi, Joao Boto, John Lonergan, Kaibo Zhou, Konstantin Knauf, Kostas Kloudas, Kurt Young, Leonard Xu, Ling Wang, Lining Jing, Liupengcheng, LouisXu, Mads Chr. Olesen, Marco Zühlke, Marcos Klein, Matyas Orhidi, Maximilian Bode, Maximilian Michels, Nick Pavlakis, Nico Kruber, Nicolas Deslandes, Pablo Valtuille, Paul Lam, Paul Lin, PengFei Li, Piotr Nowojski, Piotr Przybylski, Piyush Narang, Ricco Chen, Richard Deurwaarder, Robert Metzger, Roman, Roman Grebennikov, Roman Khachatryan, Rong Rong, Rui Li, Ryan Tao, Scott Kidder, Seth Wiesman, Shannon Carey, Shaobin.Ou, Shuo Cheng, Stefan Richter, Stephan Ewen, Steve OU, Steven Wu, Terry Wang, Thesharing, Thomas Weise, Till Rohrmann, Timo Walther, Tony Wei, TsReaper, Tzu-Li (Gordon) Tai, Victor Wong, WangHengwei, Wei Zhong, WeiZhong94, Wind (Jiayi Liao), Xintong Song, XuQianJin-Stars, Xuefu Zhang, Xupingyong, Yadong Xie, Yang Wang, Yangze Guo, Yikun Jiang, Ying, YngwieWang, Yu Li, Yuan Mei, Yun Gao, Yun Tang, Zhanchun Zhang, Zhenghua Gao, Zhijiang, Zhu Zhu, a-suiniaev, azagrebin, beyond1920, biao.liub, blueszheng, bowen.li, caoyingjie, catkint, chendonglin, chenqi, chunpinghe, cyq89051127, danrtsey.wy, dengziming, dianfu, eskabetxe, fanrui, forideal, gentlewang, godfrey he, godfreyhe, haodang, hehuiyuan, hequn8128, hpeter, huangxingbo, huzheng, ifndef-SleePy, jiemotongxue, joe, jrthe42, kevin.cyj, klion26, lamber-ken, libenchao, liketic, lincoln-lil, lining, liuyongvs, liyafan82, lz, mans2singh, mojo, openinx, ouyangwulin, shining-huang, shuai-xu, shuo.cs, stayhsfLee, sunhaibotb, sunjincheng121, tianboxiu, tianchen, tianchen92, tison, tszkitlo40, unknown, vinoyang, vthinkxie, wangpeibin, wangxiaowei, wangxiyuan, wangxlong, wangyang0918, whlwanghailong, xuchao0903, xuyang1706, yanghua, yangjf2019, yongqiang chai, yuzhao.cyz, zentol, zhangzhanchum, zhengcanbin, zhijiang, zhongyong jin, zhuzhu.zz, zjuwangg, zoudaokoulife, 砚田, 谢磊, 张志豪, 曹建华
diff --git a/docs/content.tr/posts/2020-02-20-ddl.md b/docs/content.tr/posts/2020-02-20-ddl.md
new file mode 100644
index 0000000000..439c27e274
--- /dev/null
+++ b/docs/content.tr/posts/2020-02-20-ddl.md
@@ -0,0 +1,126 @@
+---
+authors:
+- name: Seth Wiesman
+ seth: null
+ twitter: sjwiesman
+date: "2020-02-20T12:00:00Z"
+excerpt: This post discusses the efforts of the Flink community as they relate to
+ end to end applications with SQL in Apache Flink.
+title: 'No Java Required: Configuring Sources and Sinks in SQL'
+aliases:
+- /news/2020/02/20/ddl.html
+---
+
+# Introduction
+
+The recent [Apache Flink 1.10 release](https://flink.apache.org/news/2020/02/11/release-1.10.0.html) includes many exciting features.
+In particular, it marks the end of the community's year-long effort to merge in the [Blink SQL contribution](https://flink.apache.org/news/2019/02/13/unified-batch-streaming-blink.html) from Alibaba.
+The reason the community chose to spend so much time on the contribution is that SQL works.
+It allows Flink to offer a truly unified interface over batch and streaming and makes stream processing accessible to a broad audience of developers and analysts.
+Best of all, Flink SQL is ANSI-SQL compliant, which means if you've ever used a database in the past, you already know it[^1]!
+
+A lot of work focused on improving runtime performance and progressively extending its coverage of the SQL standard.
+Flink now supports the full TPC-DS query set for batch queries, reflecting the readiness of its SQL engine to address the needs of modern data warehouse-like workloads.
+Its streaming SQL supports an almost equal set of features - those that are well defined on a streaming runtime - including [complex joins]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/table/streaming/joins.html) and [MATCH_RECOGNIZE]({{< param DocsBaseUrl >}}flink-docs-stable/dev/table/streaming/match_recognize.html).
+
+As important as this work is, the community also strives to make these features generally accessible to the broadest audience possible.
+That is why the Flink community is excited in 1.10 to offer production-ready DDL syntax (e.g., `CREATE TABLE`, `DROP TABLE`) and a refactored catalog interface.
+
+# Accessing Your Data Where It Lives
+
+Flink does not store data at rest; it is a compute engine and requires other systems to consume input from and write its output.
+Those that have used Flink's `DataStream` API in the past will be familiar with connectors that allow for interacting with external systems.
+Flink has a vast connector ecosystem that includes all major message queues, filesystems, and databases.
+
+
+If your favorite system does not have a connector maintained in the central Apache Flink repository, check out the
flink packages website , which has a growing number of community-maintained components.
+
+
+While these connectors are battle-tested and production-ready, they are written in Java and configured in code, which means they are not amenable to pure SQL or Table applications.
+For a holistic SQL experience, not only queries need to be written in SQL, but also table definitions.
+
+# CREATE TABLE Statements
+
+While Flink SQL has long provided table abstractions atop some of Flink's most popular connectors, configurations were not always so straightforward.
+Beginning in 1.10, Flink supports defining tables through `CREATE TABLE` statements.
+With this feature, users can now create logical tables, backed by various external systems, in pure SQL.
+
+By defining tables in SQL, developers can write queries against logical schemas that are abstracted away from the underlying physical data store. Coupled with Flink SQL's unified approach to batch and stream processing, Flink provides a straight line from discovery to production.
+
+Users can define tables over static data sets, anything from a local CSV file to a full-fledged data lake or even Hive.
+Leveraging Flink's efficient batch processing capabilities, they can perform ad-hoc queries searching for exciting insights.
+Once something interesting is identified, businesses can gain real-time and continuous insights by merely altering the table so that it is powered by a message queue such as Kafka.
+Because Flink guarantees SQL queries have unified semantics over batch and streaming, users can be confident that redeploying this query as a continuous streaming application over a message queue will output identical results.
+
+{{< highlight sql >}}
+-- Define a table called orders that is backed by a Kafka topic
+-- The definition includes all relevant Kafka properties,
+-- the underlying format (JSON) and even defines a
+-- watermarking algorithm based on one of the fields
+-- so that this table can be used with event time.
+CREATE TABLE orders (
+ user_id BIGINT,
+ product STRING,
+ order_time TIMESTAMP(3),
+ WATERMARK FOR order_time AS order_time - '5' SECONDS
+) WITH (
+ 'connector.type' = 'kafka',
+ 'connector.version' = 'universal',
+ 'connector.topic' = 'orders',
+ 'connector.startup-mode' = 'earliest-offset',
+ 'connector.properties.bootstrap.servers' = 'localhost:9092',
+ 'format.type' = 'json'
+);
+
+-- Define a table called product_analysis
+-- on top of ElasticSearch 7 where we
+-- can write the results of our query.
+CREATE TABLE product_analysis (
+ product STRING,
+ tracking_time TIMESTAMP(3),
+ units_sold BIGINT
+) WITH (
+ 'connector.type' = 'elasticsearch',
+ 'connector.version' = '7',
+ 'connector.hosts' = 'localhost:9200',
+ 'connector.index' = 'ProductAnalysis',
+ 'connector.document.type' = 'analysis'
+);
+
+-- A simple query that analyzes order data
+-- from Kafka and writes results into
+-- ElasticSearch.
+INSERT INTO product_analysis
+SELECT
+ product_id,
+ TUMBLE_START(order_time, INTERVAL '1' DAY) as tracking_time,
+ COUNT(*) as units_sold
+FROM orders
+GROUP BY
+ product_id,
+ TUMBLE(order_time, INTERVAL '1' DAY);
+{{< / highlight >}}
+
+# Catalogs
+
+While being able to create tables is important, it often isn't enough.
+A business analyst, for example, shouldn't have to know what properties to set for Kafka, or even have to know what the underlying data source is, to be able to write a query.
+
+To solve this problem, Flink 1.10 also ships with a revamped catalog system for managing metadata about tables and user definined functions.
+With catalogs, users can create tables once and reuse them across Jobs and Sessions.
+Now, the team managing a data set can create a table and immediately make it accessible to other groups within their organization.
+
+The most notable catalog that Flink integrates with today is Hive Metastore.
+The Hive catalog allows Flink to fully interoperate with Hive and serve as a more efficient query engine.
+Flink supports reading and writing Hive tables, using Hive UDFs, and even leveraging Hive's metastore catalog to persist Flink specific metadata.
+
+# Looking Ahead
+
+Flink SQL has made enormous strides to democratize stream processing, and 1.10 marks a significant milestone in that development.
+However, we are not ones to rest on our laurels and, the community is committed to raising the bar on standards while lowering the barriers to entry.
+The community is looking to add more catalogs, such as JDBC and Apache Pulsar.
+We encourage you to sign up for the [mailing list](https://flink.apache.org/community.html) and stay on top of the announcements and new features in upcoming releases.
+
+---
+
+[^1]: My colleague Timo, whose worked on Flink SQL from the beginning, has the entire SQL standard printed on his desk and references it before any changes are merged. It's enormous.
diff --git a/docs/content.tr/posts/2020-02-22-apache-beam-how-beam-runs-on-top-of-flink.md b/docs/content.tr/posts/2020-02-22-apache-beam-how-beam-runs-on-top-of-flink.md
new file mode 100644
index 0000000000..62fd30ee69
--- /dev/null
+++ b/docs/content.tr/posts/2020-02-22-apache-beam-how-beam-runs-on-top-of-flink.md
@@ -0,0 +1,164 @@
+---
+authors:
+- maximilian: null
+ name: Maximilian Michels
+ twitter: stadtlegende
+- markos: null
+ name: Markos Sfikas
+ twitter: MarkSfik
+date: "2020-02-22T12:00:00Z"
+excerpt: This blog post discusses the reasons to use Flink together with Beam for
+ your stream processing needs and takes a closer look at how Flink works with Beam
+ under the hood.
+title: 'Apache Beam: How Beam Runs on Top of Flink'
+aliases:
+- /ecosystem/2020/02/22/apache-beam-how-beam-runs-on-top-of-flink.html
+---
+
+Note: This blog post is based on the talk ["Beam on Flink: How Does It Actually Work?"](https://www.youtube.com/watch?v=hxHGLrshnCY).
+
+[Apache Flink](https://flink.apache.org/) and [Apache Beam](https://beam.apache.org/) are open-source frameworks for parallel, distributed data processing at scale. Unlike Flink, Beam does not come with a full-blown execution engine of its own but plugs into other execution engines, such as Apache Flink, Apache Spark, or Google Cloud Dataflow. In this blog post we discuss the reasons to use Flink together with Beam for your batch and stream processing needs. We also take a closer look at how Beam works with Flink to provide an idea of the technical aspects of running Beam pipelines with Flink. We hope you find some useful information on how and why the two frameworks can be utilized in combination. For more information, you can refer to the corresponding [documentation](https://beam.apache.org/documentation/runners/flink/) on the Beam website or contact the community through the [Beam mailing list](https://beam.apache.org/community/contact-us/).
+
+
+# What is Apache Beam
+
+[Apache Beam](https://beam.apache.org/) is an open-source, unified model for defining batch and streaming data-parallel processing pipelines. It is unified in the sense that you use a single API, in contrast to using a separate API for batch and streaming like it is the case in Flink. Beam was originally developed by Google which released it in 2014 as the Cloud Dataflow SDK. In 2016, it was donated to [the Apache Software Foundation](https://www.apache.org/) with the name of Beam. It has been developed by the open-source community ever since. With Apache Beam, developers can write data processing jobs, also known as pipelines, in multiple languages, e.g. Java, Python, Go, SQL. A pipeline is then executed by one of Beam’s Runners. A Runner is responsible for translating Beam pipelines such that they can run on an execution engine. Every supported execution engine has a Runner. The following Runners are available: Apache Flink, Apache Spark, Apache Samza, Hazelcast Jet, Google Cloud Dataflow, and others.
+
+The execution model, as well as the API of Apache Beam, are similar to Flink's. Both frameworks are inspired by the [MapReduce](https://static.googleusercontent.com/media/research.google.com/en//archive/mapreduce-osdi04.pdf), [MillWheel](https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41378.pdf), and [Dataflow](https://research.google/pubs/pub43864/) papers. Like Flink, Beam is designed for parallel, distributed data processing. Both have similar transformations, support for windowing, event/processing time, watermarks, timers, triggers, and much more. However, Beam not being a full runtime focuses on providing the framework for building portable, multi-language batch and stream processing pipelines such that they can be run across several execution engines. The idea is that you write your pipeline once and feed it with either batch or streaming data. When you run it, you just pick one of the supported backends to execute. A large integration test suite in Beam called "ValidatesRunner" ensures that the results will be the same, regardless of which backend you choose for the execution.
+
+One of the most exciting developments in the Beam technology is the framework’s support for multiple programming languages including Java, Python, Go, Scala and SQL. Essentially, developers can write their applications in a programming language of their choice. Beam, with the help of the Runners, translates the program to one of the execution engines, as shown in the diagram below.
+
+
+
+
+
+
+# Reasons to use Beam with Flink
+
+Why would you want to use Beam with Flink instead of directly using Flink? Ultimately, Beam and Flink complement each other and provide additional value to the user. The main reasons for using Beam with Flink are the following:
+
+* Beam provides a unified API for both batch and streaming scenarios.
+* Beam comes with native support for different programming languages, like Python or Go with all their libraries like Numpy, Pandas, Tensorflow, or TFX.
+* You get the power of Apache Flink like its exactly-once semantics, strong memory management and robustness.
+* Beam programs run on your existing Flink infrastructure or infrastructure for other supported Runners, like Spark or Google Cloud Dataflow.
+* You get additional features like side inputs and cross-language pipelines that are not supported natively in Flink but only supported when using Beam with Flink.
+
+
+# The Flink Runner in Beam
+
+The Flink Runner in Beam translates Beam pipelines into Flink jobs. The translation can be parameterized using Beam's pipeline options which are parameters for settings like configuring the job name, parallelism, checkpointing, or metrics reporting.
+
+If you are familiar with a DataSet or a DataStream, you will have no problems understanding what a PCollection is. PCollection stands for parallel collection in Beam and is exactly what DataSet/DataStream would be in Flink. Due to Beam's unified API we only have one type of results of transformation: PCollection.
+
+Beam pipelines are composed of transforms. Transforms are like operators in Flink and come in two flavors: primitive and composite transforms. The beauty of all this is that Beam only comes with a small set of primitive transforms which are:
+
+- `Source` (for loading data)
+- `ParDo` (think of a flat map operator on steroids)
+- `GroupByKey` (think of keyBy() in Flink)
+- `AssignWindows` (windows can be assigned at any point in time in Beam)
+- `Flatten` (like a union() operation in Flink)
+
+Composite transforms are built by combining the above primitive transforms. For example, `Combine = GroupByKey + ParDo`.
+
+
+# Flink Runner Internals
+
+Although using the Flink Runner in Beam has no prerequisite to understanding its internals, we provide more details of how the Flink runner works in Beam to share knowledge of how the two frameworks can integrate and work together to provide state-of-the-art streaming data pipelines.
+
+The Flink Runner has two translation paths. Depending on whether we execute in batch or streaming mode, the Runner either translates into Flink's DataSet or into Flink's DataStream API. Since multi-language support has been added to Beam, another two translation paths have been added. To summarize the four modes:
+
+1. **The Classic Flink Runner for batch jobs:** Executes batch Java pipelines
+2. **The Classic Flink Runner for streaming jobs:** Executes streaming Java pipelines
+3. **The Portable Flink Runner for batch jobs:** Executes Java as well as Python, Go and other supported SDK pipelines for batch scenarios
+4. **The Portable Flink Runner for streaming jobs:** Executes Java as well as Python, Go and other supported SDK pipelines for streaming scenarios
+
+
+
+
+
+
+## The “Classic” Flink Runner in Beam
+
+The classic Flink Runner was the initial version of the Runner, hence the "classic" name. Beam pipelines are represented as a graph in Java which is composed of the aforementioned composite and primitive transforms. Beam provides translators which traverse the graph in topological order. Topological order means that we start from all the sources first as we iterate through the graph. Presented with a transform from the graph, the Flink Runner generates the API calls as you would normally when writing a Flink job.
+
+
+
+
+
+While Beam and Flink share very similar concepts, there are enough differences between the two frameworks that make Beam pipelines impossible to be translated 1:1 into a Flink program. In the following sections, we will present the key differences:
+
+### Serializers vs Coders
+
+When data is transferred over the wire in Flink, it has to be turned into bytes. This is done with the help of serializers. Flink has a type system to instantiate the correct coder for a given type, e.g. `StringTypeSerializer` for a String. Apache Beam also has its own type system which is similar to Flink's but uses slightly different interfaces. Serializers are called Coders in Beam. In order to make a Beam Coder run in Flink, we have to make the two serializer types compatible. This is done by creating a special Flink type information that looks like the one in Flink but calls the appropriate Beam coder. That way, we can use Beam's coders although we are executing the Beam job with Flink. Flink operators expect a TypeInformation, e.g. `StringTypeInformation`, for which we use a `CoderTypeInformation` in Beam. The type information returns the serializer for which we return a `CoderTypeSerializer`, which calls the underlying Beam Coder.
+
+
+
+
+
+### Read
+
+The `Read` transform provides a way to read data into your pipeline in Beam. The Read transform is supported by two wrappers in Beam, the `SourceInputFormat` for batch processing and the `UnboundedSourceWrapper` for stream processing.
+
+### ParDo
+
+`ParDo` is the swiss army knife of Beam and can be compared to a `RichFlatMapFunction` in Flink with additional features such as `SideInputs`, `SideOutputs`, State and Timers. `ParDo` is essentially translated by the Flink runner using the `FlinkDoFnFunction` for batch processing or the `FlinkStatefulDoFnFunction`, while for streaming scenarios the translation is executed with the `DoFnOperator` that takes care of checkpointing and buffering of data during checkpoints, watermark emissions and maintenance of state and timers. This is all executed by Beam’s interface, called the `DoFnRunner`, that encapsulates Beam-specific execution logic, like retrieving state, executing state and timers, or reporting metrics.
+
+### Side Inputs
+
+In addition to the main input, ParDo transforms can have a number of side inputs. A side input can be a static set of data that you want to have available at all parallel instances. However, it is more flexible than that. You can have keyed and even windowed side input which updates based on the window size. This is a very powerful concept which does not exist in Flink but is added on top of Flink using Beam.
+
+### AssignWindows
+
+In Flink, windows are assigned by the `WindowOperator` when you use the `window()` in the API. In Beam, windows can be assigned at any point in time. Any element is implicitly part of a window. If no window is assigned explicitly, the element is part of the `GlobalWindow`. Window information is stored for each element in a wrapper called `WindowedValue`. The window information is only used once we issue a `GroupByKey`.
+
+### GroupByKey
+
+Most of the time it is useful to partition the data by a key. In Flink, this is done via the `keyBy()` API call. In Beam the `GroupByKey` transform can only be applied if the input is of the form `KV`. Unlike Flink where the key can even be nested inside the data, Beam enforces the key to always be explicit. The `GroupByKey` transform then groups the data by key and by window which is similar to what `keyBy(..).window(..)` would give us in Flink. Beam has its own set of libraries to do that because Beam has its own set of window functions and triggers. Essentially, GroupByKey is very similar to what the WindowOperator does in Flink.
+
+### Flatten
+
+The Flatten operator takes multiple DataSet/DataStreams, called P[arallel]Collections in Beam, and combines them into one collection. This is equivalent to Flink's `union()` operation.
+
+
+## The “Portable” Flink Runner in Beam
+
+The portable Flink Runner in Beam is the evolution of the classic Runner. Classic Runners are tied to the JVM ecosystem, but the Beam community wanted to move past this and also execute Python, Go and other languages. This adds another dimension to Beam in terms of portability because, like previously mentioned, Beam already had portability across execution engines. It was necessary to change the translation logic of the Runner to be able to support language portability.
+
+There are two important building blocks for portable Runners:
+
+1. A common pipeline format across all the languages: The Runner API
+2. A common interface during execution for the communication between the Runner and the code written in any language: The Fn API
+
+The Runner API provides a universal representation of the pipeline as Protobuf which contains the transforms, types, and user code. Protobuf was chosen as the format because every language has libraries available for it. Similarly, for the execution part, Beam introduced the Fn API interface to handle the communication between the Runner/execution engine and the user code that may be written in a different language and executes in a different process. Fn API is pronounced "fun API", you may guess why.
+
+
+
+
+
+
+## How Are Beam Programs Translated In Language Portability?
+
+Users write their Beam pipelines in one language, but they may get executed in an environment based on a completely different language. How does that work? To explain that, let's follow the lifecycle of a pipeline. Let's suppose we use the Python SDK to write the pipeline. Before submitting the pipeline via the Job API to Beam's JobServer, Beam would convert it to the Runner API, the language-agnostic format we described before. The JobServer is also a Beam component that handles the staging of the required dependencies during execution. The JobServer will then kick-off the translation which is similar to the classic Runner. However, an important change is the so-called `ExecutableStage` transform. It is essentially a ParDo transform that we already know but designed for holding language-dependent code. Beam tries to combine as many of these transforms into one "executable stage". The result again is a Flink program which is then sent to the Flink cluster and executed there. The major difference compared to the classic Runner is that during execution we will start _environments_ to execute the aforementioned _ExecutableStages_. The following environments are available:
+
+- Docker-based (the default)
+- Process-based (a simple process is started)
+- Externally-provided (K8s or other schedulers)
+- Embedded (intended for testing and only works with Java)
+
+Environments hold the _SDK Harness_ which is the code that handles the execution and the communication with the Runner over the Fn API. For example, when Flink executes Python code, it sends the data to the Python environment containing the Python SDK Harness. Sending data to an external process involves a minor overhead which we have measured to be 5-10% slower than the classic Java pipelines. However, Beam uses a fusion of transforms to execute as many transforms as possible in the same environment which share the same input or output. That's why in real-world scenarios the overhead could be much lower.
+
+
+
+
+
+
+Environments can be present for many languages. This opens up an entirely new type of pipelines: cross-language pipelines. In cross-language pipelines we can combine transforms of two or more languages, e.g. a machine learning pipeline with the feature generation written in Java and the learning written in Python. All this can be run on top of Flink.
+
+
+## Conclusion
+
+Using Apache Beam with Apache Flink combines (a.) the power of Flink with (b.) the flexibility of Beam. All it takes to run Beam is a Flink cluster, which you may already have. Apache Beam's fully-fledged Python API is probably the most compelling argument for using Beam with Flink, but the unified API which allows to "write-once" and "execute-anywhere" is also very appealing to Beam users. On top of this, features like side inputs and a rich connector ecosystem are also reasons why people like Beam.
+
+With the introduction of schemas, a new format for handling type information, Beam is heading in a similar direction as Flink with its type system which is essential for the Table API or SQL. Speaking of, the next Flink release will include a Python version of the Table API which is based on the language portability of Beam. Looking ahead, the Beam community plans to extend the support for interactive programs like notebooks. TFX, which is built with Beam, is a very powerful way to solve many problems around training and validating machine learning models.
+
+For many years, Beam and Flink have inspired and learned from each other. With the Python support being based on Beam in Flink, they only seem to come closer to each other. That's all the better for the community, and also users have more options and functionality to choose from.
diff --git a/docs/content.tr/posts/2020-03-24-demo-fraud-detection-2.md b/docs/content.tr/posts/2020-03-24-demo-fraud-detection-2.md
new file mode 100644
index 0000000000..c632c8b613
--- /dev/null
+++ b/docs/content.tr/posts/2020-03-24-demo-fraud-detection-2.md
@@ -0,0 +1,201 @@
+---
+authors:
+- alex: null
+ name: Alexander Fedulov
+ twitter: alex_fedulov
+date: "2020-03-24T12:00:00Z"
+excerpt: In this series of blog posts you will learn about powerful Flink patterns
+ for building streaming applications.
+title: 'Advanced Flink Application Patterns Vol.2: Dynamic Updates of Application
+ Logic'
+aliases:
+- /news/2020/03/24/demo-fraud-detection-2.html
+---
+
+In the [first article](https://flink.apache.org/news/2020/01/15/demo-fraud-detection.html) of the series, we gave a high-level description of the objectives and required functionality of a Fraud Detection engine. We also described how to make data partitioning in Apache Flink customizable based on modifiable rules instead of using a hardcoded `KeysExtractor` implementation.
+
+We intentionally omitted details of how the applied rules are initialized and what possibilities exist for updating them at runtime. In this post, we will address exactly these details. You will learn how the approach to data partitioning described in [Part 1](https://flink.apache.org/news/2020/01/15/demo-fraud-detection.html) can be applied in combination with a dynamic configuration. These two patterns, when used together, can eliminate the need to recompile the code and redeploy your Flink job for a wide range of modifications of the business logic.
+
+## Rules Broadcasting
+
+Let's first have a look at the [previously-defined](https://flink.apache.org/news/2020/01/15/demo-fraud-detection.html#dynamic-data-partitioning) data-processing pipeline:
+
+```java
+DataStream alerts =
+ transactions
+ .process(new DynamicKeyFunction())
+ .keyBy((keyed) -> keyed.getKey());
+ .process(new DynamicAlertFunction())
+```
+
+`DynamicKeyFunction` provides dynamic data partitioning while `DynamicAlertFunction` is responsible for executing the main logic of processing transactions and sending alert messages according to defined rules.
+
+Vol.1 of this series simplified the use case and assumed that the applied set of rules is pre-initialized and accessible via the `List` within `DynamicKeyFunction`.
+
+```java
+public class DynamicKeyFunction
+ extends ProcessFunction> {
+
+ /* Simplified */
+ List rules = /* Rules that are initialized somehow.*/;
+ ...
+}
+```
+
+Adding rules to this list is obviously possible directly inside the code of the Flink Job at the stage of its initialization (Create a `List` object; use it's `add` method). A major drawback of doing so is that it will require recompilation of the job with each rule modification. In a real Fraud Detection system, rules are expected to change on a frequent basis, making this approach unacceptable from the point of view of business and operational requirements. A different approach is needed.
+
+Next, let's take a look at a sample rule definition that we introduced in the previous post of the series:
+
+
+
+
+Figure 1: Rule definition
+
+
+
+The previous post covered use of `groupingKeyNames` by `DynamicKeyFunction` to extract message keys. Parameters from the second part of this rule are used by `DynamicAlertFunction`: they define the actual logic of the performed operations and their parameters (such as the alert-triggering limit). This means that the same rule must be present in both `DynamicKeyFunction` and `DynamicAlertFunction`. To achieve this result, we will use the [broadcast data distribution mechanism]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/stream/state/broadcast_state.html) of Apache Flink.
+
+Figure 2 presents the final job graph of the system that we are building:
+
+
+
+
+Figure 2: Job Graph of the Fraud Detection Flink Job
+
+
+
+The main blocks of the Transactions processing pipeline are:
+
+* **Transaction Source** that consumes transaction messages from Kafka partitions in parallel.
+
+* **Dynamic Key Function** that performs data enrichment with a dynamic key. The subsequent `keyBy` hashes this dynamic key and partitions the data accordingly among all parallel instances of the following operator.
+
+* **Dynamic Alert Function** that accumulates a data window and creates Alerts based on it.
+
+## Data Exchange inside Apache Flink
+
+The job graph above also indicates various data exchange patterns between the operators. In order to understand how the broadcast pattern works, let's take a short detour and discuss what methods of message propagation exist in Apache Flink's distributed runtime.
+
+* The __FORWARD__ connection after the Transaction Source means that all data consumed by one of the parallel instances of the Transaction Source operator is transferred to exactly one instance of the subsequent `DynamicKeyFunction` operator. It also indicates the same level of parallelism of the two connected operators (12 in the above case). This communication pattern is illustrated in Figure 3. Orange circles represent transactions, and dotted rectangles depict parallel instances of the conjoined operators.
+
+
+
+
+Figure 3: FORWARD message passing across operator instances
+
+
+
+* The __HASH__ connection between `DynamicKeyFunction` and `DynamicAlertFunction` means that for each message a hash code is calculated and messages are evenly distributed among available parallel instances of the next operator. Such a connection needs to be explicitly "requested" from Flink by using `keyBy`.
+
+
+
+
+Figure 4: HASHED message passing across operator instances (via `keyBy`)
+
+
+
+* A __REBALANCE__ distribution is either caused by an explicit call to `rebalance()` or by a change of parallelism (12 -> 1 in the case of the job graph from Figure 2). Calling `rebalance()` causes data to be repartitioned in a round-robin fashion and can help to mitigate data skew in certain scenarios.
+
+
+
+
+Figure 5: REBALANCE message passing across operator instances
+
+
+
+The Fraud Detection job graph in Figure 2 contains an additional data source: _Rules Source_. It also consumes from Kafka. Rules are "mixed into" the main processing data flow through the __BROADCAST__ channel. Unlike other methods of transmitting data between operators, such as `forward`, `hash` or `rebalance` that make each message available for processing in only one of the parallel instances of the receiving operator, `broadcast` makes each message available at the input of all of the parallel instances of the operator to which the _broadcast stream_ is connected. This makes `broadcast` applicable to a wide range of tasks that need to affect the processing of all messages, regardless of their key or source partition.
+
+
+
+
+ Figure 6: BROADCAST message passing across operator instances
+
+
+
+
+ Note
+There are actually a few more specialized data partitioning schemes in Flink which we did not mention here. If you want to find out more, please refer to Flink's documentation on __[stream partitioning]({{< param DocsBaseUrl >}}flink-docs-stable/dev/stream/operators/#physical-partitioning)__.
+
+
+## Broadcast State Pattern
+
+In order to make use of the Rules Source, we need to "connect" it to the main data stream:
+
+```java
+// Streams setup
+DataStream transactions = [...]
+DataStream rulesUpdateStream = [...]
+
+BroadcastStream rulesStream = rulesUpdateStream.broadcast(RULES_STATE_DESCRIPTOR);
+
+// Processing pipeline setup
+ DataStream alerts =
+ transactions
+ .connect(rulesStream)
+ .process(new DynamicKeyFunction())
+ .keyBy((keyed) -> keyed.getKey())
+ .connect(rulesStream)
+ .process(new DynamicAlertFunction())
+```
+
+As you can see, the broadcast stream can be created from any regular stream by calling the `broadcast` method and specifying a state descriptor. Flink assumes that broadcasted data needs to be stored and retrieved while processing events of the main data flow and, therefore, always automatically creates a corresponding _broadcast state_ from this state descriptor. This is different from any other Apache Flink state type in which you need to initialize it in the `open()` method of the processing function. Also note that broadcast state always has a key-value format (`MapState`).
+
+```java
+public static final MapStateDescriptor RULES_STATE_DESCRIPTOR =
+ new MapStateDescriptor<>("rules", Integer.class, Rule.class);
+```
+
+Connecting to `rulesStream` causes some changes in the signature of the processing functions. The previous article presented it in a slightly simplified way as a `ProcessFunction`. However, `DynamicKeyFunction` is actually a `BroadcastProcessFunction`.
+
+```java
+public abstract class BroadcastProcessFunction {
+
+ public abstract void processElement(IN1 value,
+ ReadOnlyContext ctx,
+ Collector out) throws Exception;
+
+ public abstract void processBroadcastElement(IN2 value,
+ Context ctx,
+ Collector out) throws Exception;
+
+}
+```
+
+The difference is the addition of the `processBroadcastElement` method through which messages of the rules stream will arrive. The following new version of `DynamicKeyFunction` allows modifying the list of data-distribution keys at runtime through this stream:
+
+```java
+public class DynamicKeyFunction
+ extends BroadcastProcessFunction> {
+
+
+ @Override
+ public void processBroadcastElement(Rule rule,
+ Context ctx,
+ Collector> out) {
+ BroadcastState broadcastState = ctx.getBroadcastState(RULES_STATE_DESCRIPTOR);
+ broadcastState.put(rule.getRuleId(), rule);
+ }
+
+ @Override
+ public void processElement(Transaction event,
+ ReadOnlyContext ctx,
+ Collector> out){
+ ReadOnlyBroadcastState rulesState =
+ ctx.getBroadcastState(RULES_STATE_DESCRIPTOR);
+ for (Map.Entry entry : rulesState.immutableEntries()) {
+ final Rule rule = entry.getValue();
+ out.collect(
+ new Keyed<>(
+ event, KeysExtractor.getKey(rule.getGroupingKeyNames(), event), rule.getRuleId()));
+ }
+ }
+}
+```
+
+In the above code, `processElement()` receives Transactions, and `processBroadcastElement()` receives Rule updates. When a new rule is created, it is distributed as depicted in Figure 6 and saved in all parallel instances of the operator using `processBroadcastState`. We use a Rule's ID as the key to store and reference individual rules. Instead of iterating over a hardcoded `List`, we iterate over entries in the dynamically-updated broadcast state.
+
+`DynamicAlertFunction` follows the same logic with respect to storing the rules in the broadcast `MapState`. As described in [Part 1](https://flink.apache.org/news/2020/01/15/demo-fraud-detection.html), each message in the `processElement` input is intended to be processed by one specific rule and comes "pre-marked" with a corresponding ID by `DynamicKeyFunction`. All we need to do is retrieve the definition of the corresponding rule from `BroadcastState` by using the provided ID and process it according to the logic required by that rule. At this stage, we will also add messages to the internal function state in order to perform calculations on the required time window of data. We will consider how this is done in the [final blog](/news/2020/07/30/demo-fraud-detection-3.html) of the series about Fraud Detection.
+
+# Summary
+
+In this blog post, we continued our investigation of the use case of a Fraud Detection System built with Apache Flink. We looked into different ways in which data can be distributed between parallel operator instances and, most importantly, examined broadcast state. We demonstrated how dynamic partitioning — a pattern described in the [first part](https://flink.apache.org/news/2020/01/15/demo-fraud-detection.html) of the series — can be combined and enhanced by the functionality provided by the broadcast state pattern. The ability to send dynamic updates at runtime is a powerful feature of Apache Flink that is applicable in a variety of other use cases, such as controlling state (cleanup/insert/fix), running A/B experiments or executing updates of ML model coefficients.
diff --git a/docs/content.tr/posts/2020-03-27-flink-for-data-warehouse.md b/docs/content.tr/posts/2020-03-27-flink-for-data-warehouse.md
new file mode 100644
index 0000000000..68e11d1c37
--- /dev/null
+++ b/docs/content.tr/posts/2020-03-27-flink-for-data-warehouse.md
@@ -0,0 +1,115 @@
+---
+authors:
+- bowen: null
+ name: Bowen Li
+ twitter: Bowen__Li
+date: "2020-03-27T02:30:00Z"
+title: 'Flink as Unified Engine for Modern Data Warehousing: Production-Ready Hive
+ Integration'
+aliases:
+- /features/2020/03/27/flink-for-data-warehouse.html
+---
+
+In this blog post, you will learn our motivation behind the Flink-Hive integration, and how Flink 1.10 can help modernize your data warehouse.
+
+## Introduction
+
+What are some of the latest requirements for your data warehouse and data infrastructure in 2020?
+
+We’ve came up with some for you.
+
+Firstly, today’s business is shifting to a more real-time fashion, and thus demands abilities to process online streaming data with low latency for near-real-time or even real-time analytics. People become less and less tolerant of delays between when data is generated and when it arrives at their hands, ready to use. Hours or even days of delay is not acceptable anymore. Users are expecting minutes, or even seconds, of end-to-end latency for data in their warehouse, to get quicker-than-ever insights.
+
+Secondly, the infrastructure should be able to handle both offline batch data for offline analytics and exploration, and online streaming data for more timely analytics. Both are indispensable as they both have very valid use cases. Apart from the real time processing mentioned above, batch processing would still exist as it’s good for ad hoc queries and explorations, and full-size calculations. Your modern infrastructure should not force users to choose between one or the other, it should offer users both options for a world-class data infrastructure.
+
+Thirdly, the data players, including data engineers, data scientists, analysts, and operations, urge a more unified infrastructure than ever before for easier ramp-up and higher working efficiency. The big data landscape has been fragmented for years - companies may have one set of infrastructure for real time processing, one set for batch, one set for OLAP, etc. That, oftentimes, comes as a result of the legacy of lambda architecture, which was popular in the era when stream processors were not as mature as today and users had to periodically run batch processing as a way to correct streaming pipelines. Well, it's a different era now! As stream processing becomes mainstream and dominant, end users no longer want to learn shattered pieces of skills and maintain many moving parts with all kinds of tools and pipelines. Instead, what they really need is a unified analytics platform that can be mastered easily, and simplify any operational complexity.
+
+If any of these resonate with you, you just found the right post to read: we have never been this close to the vision by strengthening Flink’s integration with Hive to a production grade.
+
+
+## Flink and Its Integration With Hive Comes into the Scene
+
+Apache Flink has been a proven scalable system to handle extremely high workload of streaming data in super low latency in many giant tech companies.
+
+Despite its huge success in the real time processing domain, at its deep root, Flink has been faithfully following its inborn philosophy of being [a unified data processing engine for both batch and streaming](https://flink.apache.org/news/2019/02/13/unified-batch-streaming-blink.html), and taking a streaming-first approach in its architecture to do batch processing. By making batch a special case for streaming, Flink really leverages its cutting edge streaming capabilities and applies them to batch scenarios to gain the best offline performance. Flink’s batch performance has been quite outstanding in the early days and has become even more impressive, as the community started merging Blink, Alibaba’s fork of Flink, back to Flink in 1.9 and finished it in 1.10.
+
+On the other hand, Apache Hive has established itself as a focal point of the data warehousing ecosystem. It serves as not only a SQL engine for big data analytics and ETL, but also a data management platform, where data is discovered and defined. As business evolves, it puts new requirements on data warehouse.
+
+Thus we started integrating Flink and Hive as a beta version in Flink 1.9. Over the past few months, we have been listening to users’ requests and feedback, extensively enhancing our product, and running rigorous benchmarks (which will be published soon separately). I’m glad to announce that the integration between Flink and Hive is at production grade in [Flink 1.10](https://flink.apache.org/news/2020/02/11/release-1.10.0.html) and we can’t wait to walk you through the details.
+
+
+### Unified Metadata Management
+
+Hive Metastore has evolved into the de facto metadata hub over the years in the Hadoop, or even the cloud, ecosystem. Many companies have a single Hive Metastore service instance in production to manage all of their schemas, either Hive or non-Hive metadata, as the single source of truth.
+
+In 1.9 we introduced Flink’s [HiveCatalog]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/table/hive/hive_catalog.html), connecting Flink to users’ rich metadata pool. The meaning of `HiveCatalog` is two-fold here. First, it allows Apache Flink users to utilize Hive Metastore to store and manage Flink’s metadata, including tables, UDFs, and statistics of data. Second, it enables Flink to access Hive’s existing metadata, so that Flink itself can read and write Hive tables.
+
+In Flink 1.10, users can store Flink's own tables, views, UDFs, statistics in Hive Metastore on all of the compatible Hive versions mentioned above. [Here’s an end-to-end example]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/table/hive/hive_catalog.html#example) of how to store a Flink’s Kafka source table in Hive Metastore and later query the table in Flink SQL.
+
+
+### Stream Processing
+
+The Hive integration feature in Flink 1.10 empowers users to re-imagine what they can accomplish with their Hive data and unlock stream processing use cases:
+
+- join real-time streaming data in Flink with offline Hive data for more complex data processing
+- backfill Hive data with Flink directly in a unified fashion
+- leverage Flink to move real-time data into Hive more quickly, greatly shortening the end-to-end latency between when data is generated and when it arrives at your data warehouse for analytics, from hours — or even days — to minutes
+
+
+### Compatible with More Hive Versions
+
+In Flink 1.10, we brought full coverage to most Hive versions including 1.0, 1.1, 1.2, 2.0, 2.1, 2.2, 2.3, and 3.1. Take a look [here]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/table/hive/#supported-hive-versions).
+
+
+### Reuse Hive User Defined Functions (UDFs)
+
+Users can [reuse all kinds of Hive UDFs in Flink]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/table/hive/hive_functions.html#hive-user-defined-functions) since Flink 1.9.
+
+This is a great win for Flink users with past history with the Hive ecosystem, as they may have developed custom business logic in their Hive UDFs. Being able to run these functions without any rewrite saves users a lot of time and brings them a much smoother experience when they migrate to Flink.
+
+To take it a step further, Flink 1.10 introduces [compatibility of Hive built-in functions via HiveModule]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/table/hive/hive_functions.html#use-hive-built-in-functions-via-hivemodule). Over the years, the Hive community has developed a few hundreds of built-in functions that are super handy for users. For those built-in functions that don't exist in Flink yet, users are now able to leverage the existing Hive built-in functions that they are familiar with and complete their jobs seamlessly.
+
+
+### Enhanced Read and Write on Hive Data
+
+Flink 1.10 extends its read and write capabilities on Hive data to all the common use cases with better performance.
+
+On the reading side, Flink now can read Hive regular tables, partitioned tables, and views. Lots of optimization techniques are developed around reading, including partition pruning and projection pushdown to transport less data from file storage, limit pushdown for faster experiment and exploration, and vectorized reader for ORC files.
+
+On the writing side, Flink 1.10 introduces “INSERT INTO” and “INSERT OVERWRITE” to its syntax, and can write to not only Hive’s regular tables, but also partitioned tables with either static or dynamic partitions.
+
+### Formats
+
+Your engine should be able to handle all common types of file formats to give you the freedom of choosing one over another in order to fit your business needs. It’s no exception for Flink. We have tested the following table storage formats: text, csv, SequenceFile, ORC, and Parquet.
+
+### More Data Types
+
+In Flink 1.10, we added support for a few more frequently-used Hive data types that were not covered by Flink 1.9. Flink users now should have a full, smooth experience to query and manipulate Hive data from Flink.
+
+
+### Roadmap
+
+Integration between any two systems is a never-ending story.
+
+We are constantly improving Flink itself and the Flink-Hive integration also gets improved by collecting user feedback and working with folks in this vibrant community.
+
+After careful consideration and prioritization of the feedback we received, we have prioritize many of the below requests for the next Flink release of 1.11.
+
+- Hive streaming sink so that Flink can stream data into Hive tables, bringing a real streaming experience to Hive
+- Native Parquet reader for better performance
+- Additional interoperability - support creating Hive tables, views, functions in Flink
+- Better out-of-box experience with built-in dependencies, including documentations
+- JDBC driver so that users can reuse their existing toolings to run SQL jobs on Flink
+- Hive syntax and semantic compatible mode
+
+If you have more feature requests or discover bugs, please reach out to the community through mailing list and JIRAs.
+
+
+## Summary
+
+Data warehousing is shifting to a more real-time fashion, and Apache Flink can make a difference for your organization in this space.
+
+Flink 1.10 brings production-ready Hive integration and empowers users to achieve more in both metadata management and unified/batch data processing.
+
+We encourage all our users to get their hands on Flink 1.10. You are very welcome to join the community in development, discussions, and all other kinds of collaborations in this topic.
+
diff --git a/docs/content.tr/posts/2020-03-30-community-update.md b/docs/content.tr/posts/2020-03-30-community-update.md
new file mode 100644
index 0000000000..e710dbfa89
--- /dev/null
+++ b/docs/content.tr/posts/2020-03-30-community-update.md
@@ -0,0 +1,131 @@
+---
+authors:
+- morsapaes: null
+ name: Marta Paes
+ twitter: morsapaes
+date: "2020-03-30T08:00:00Z"
+excerpt: While things slow down around us, the Apache Flink community is privileged
+ to remain as active as ever. This blogpost combs through the past few months to
+ give you an update on the state of things in Flink — from core releases to Stateful
+ Functions; from some good old community stats to a new development blog.
+title: Flink Community Update - April'20
+aliases:
+- /news/2020/04/01/community-update.html
+---
+
+While things slow down around us, the Apache Flink community is privileged to remain as active as ever. This blogpost combs through the past few months to give you an update on the state of things in Flink — from core releases to Stateful Functions; from some good old community stats to a new development blog.
+
+And since now it's more important than ever to keep up the spirits, we’d like to invite you to join the [Flink Forward Virtual Conference](https://www.flink-forward.org/sf-2020), on April 22-24 (see [Upcoming Events](#upcoming-events)). Hope to see you there!
+
+# The Year (so far) in Flink
+
+## Flink 1.10 Release
+
+To kick off the new year, the Flink community [released Flink 1.10](https://flink.apache.org/news/2020/02/11/release-1.10.0.html) with the record contribution of over 200 engineers. This release introduced significant improvements to the overall performance and stability of Flink jobs, a preview of native Kubernetes integration and advances in Python support (PyFlink). Flink 1.10 also marked the completion of the [Blink integration](https://flink.apache.org/news/2019/08/22/release-1.9.0.html#preview-of-the-new-blink-sql-query-processor), hardening streaming SQL and bringing mature batch processing to Flink with production-ready Hive integration and TPC-DS coverage.
+
+The community is now discussing the [release of Flink 1.10.1](http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Releasing-Flink-1-10-1-td38689.html#a38690), covering some outstanding bugs from Flink 1.10.
+
+## Stateful Functions Contribution and 2.0 Release
+
+Last January, the first version of Stateful Functions ([statefun.io](https://statefun.io/)) code was pushed to the [Flink repository](https://github.com/apache/flink-statefun). Stateful Functions started out as an API to build general purpose event-driven applications on Flink, taking advantage of its advanced state management mechanism to cut the “middleman” that usually handles state coordination in such applications (e.g. a database).
+
+In a [recent update](http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Update-on-Flink-Stateful-Functions-what-are-the-next-steps-tp38646.html), some new features were announced, like multi-language support (including a Python SDK), function unit testing and Stateful Functions’ own flavor of the [State Processor API]({{< param DocsBaseUrl >}}flink-docs-stable/dev/libs/state_processor_api.html). The release cycle will be independent from core Flink releases and the Release Candidate (RC) has been created — so, **you can expect Stateful Functions 2.0 to be released very soon!**
+
+## Building up to Flink 1.11
+
+Amidst the usual outpour of discussion threads, JIRA tickets and FLIPs, the community is working full steam on bringing Flink 1.11 to life in the next few months. The feature freeze is currently scheduled for late April, so the release is expected around mid May.
+The upcoming release will focus on new features and integrations that broaden the scope of Flink use cases, as well as core runtime enhancements to streamline the operations of complex deployments.
+
+Some of the plans on the use case side include support for changelog streams in the Table API/SQL ([FLIP-105](https://cwiki.apache.org/confluence/display/FLINK/FLIP-105%3A+Support+to+Interpret+and+Emit+Changelog+in+Flink+SQL)), easy streaming data ingestion into Apache Hive ([FLIP-115](https://cwiki.apache.org/confluence/display/FLINK/FLIP-115%3A+Filesystem+connector+in+Table)) and support for Pandas DataFrames in PyFlink. On the operational side, the much anticipated new Source API ([FLIP-27](https://cwiki.apache.org/confluence/display/FLINK/FLIP-27%3A+Refactor+Source+Interface)) will unify batch and streaming sources, and improve out-of-the-box event-time behavior; while unaligned checkpoints ([FLIP-76](https://cwiki.apache.org/confluence/display/FLINK/FLIP-76%3A+Unaligned+Checkpoints)) and some changes to network memory management will allow to speed up checkpointing under backpressure.
+
+Throw into the mix improvements around type systems, the WebUI, metrics reporting and supported formats, this release is bound to keep the community busy. For a complete overview of the ongoing development, check [this discussion](http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Features-of-Apache-Flink-1-11-td38724.html#a38793) and follow the weekly updates on the Flink [@community mailing list](https://flink.apache.org/community.html#mailing-lists).
+
+## New Committers and PMC Members
+
+The Apache Flink community has welcomed **1 PMC (Project Management Committee) Member** and **5 new Committers** since the last update (September 2019):
+
+### New PMC Members
+ Jark Wu
+
+### New Committers
+ Zili Chen, Jingsong Lee, Yu Li, Dian Fu, Zhu Zhu
+
+Congratulations to all and thank you for your hardworking commitment to Flink!
+
+# The Bigger Picture
+
+## A Look into the Flink Repository
+
+In the [last update](https://flink.apache.org/news/2019/09/10/community-update.html), we shared some numbers around Flink releases and mailing list activity. This time, we’re looking into the activity in the Flink repository and how it’s evolving.
+
+
+
+
+
+There is a clear upward trend in the number of contributions to the repository, based on the number of commits. This reflects the **fast pace of development** the project is experiencing and also the **successful integration of the China-based Flink contributors** started early last year. To complement these observations, the repository registered a **1.5x increase in the number of individual contributors in 2019**, compared to the previous year.
+
+But did this increase in capacity produce any other measurable benefits?
+
+
+
+
+
+If we look at the average time of Pull Request (PR) “resolution”, it seems like it did: **the average time it takes to close a PR these days has been steadily decreasing** since last year, sitting between 5-6 days for the past few months.
+
+These are great indicators of the health of Flink as an open source project!
+
+## Flink Community Packages
+
+If you missed the launch of [flink-packages.org](http://flink-packages.org/), here’s a reminder! Ververica has [created (and open sourced)](https://www.ververica.com/blog/announcing-flink-community-packages) a website that showcases the work of the community to push forward the ecosystem surrounding Flink. There, you can explore existing packages (like the Pravega and Pulsar Flink connectors, or the Flink Kubernetes operators developed by Google and Lyft) and also submit your own contributions to the ecosystem.
+
+## Flink "Engine Room"
+
+The community has recently launched the [“Engine Room”](https://cwiki.apache.org/confluence/pages/viewrecentblogposts.action?key=FLINK), a dedicated space in Flink’s Wiki for knowledge sharing between contributors. The goal of this initiative is to make ongoing development on Flink internals more transparent across different work streams, and also to help new contributors get on board with best practices. The first blogpost is already up and sheds light on the [migration of Flink’s CI infrastructure from Travis to Azure Pipelines](https://cwiki.apache.org/confluence/display/FLINK/2020/03/22/Migrating+Flink%27s+CI+Infrastructure+from+Travis+CI+to+Azure+Pipelines).
+
+# Upcoming Events
+
+## Flink Forward Virtual Conference
+
+The organization of Flink Forward had to make the hard decision of cancelling this year’s event in San Francisco. But all is not lost! **Flink Forward SF will be held online on April 22-24 and you can register (for free)** [here](https://www.flink-forward.org/sf-2020). Join the community for interactive talks and Q&A sessions with core Flink contributors and companies like Splunk, Lyft, Netflix or Google.
+
+## Others
+
+Events across the globe have come to a halt due to the growing concerns around COVID-19, so this time we’ll leave you with some interesting content to read instead. In addition to this written content, you can also recap last year’s sessions from [Flink Forward Berlin](https://www.youtube.com/playlist?list=PLDX4T_cnKjD207Aa8b5CsZjc7Z_KRezGz) and [Flink Forward China](https://www.youtube.com/playlist?list=PLDX4T_cnKjD3ANoNinSx3Au-poZTHvbF5)!
+
+
+
+
+ Type
+ Links
+
+
+
+
+ Blogposts
+
+
+
+
+
+ Tutorials
+
+
+
+
+
+
+If you’d like to keep a closer eye on what’s happening in the community, subscribe to the Flink [@community mailing list](https://flink.apache.org/community.html#mailing-lists) to get fine-grained weekly updates, upcoming event announcements and more.
diff --git a/docs/content.tr/posts/2020-04-07-release-statefun-2.0.0.md b/docs/content.tr/posts/2020-04-07-release-statefun-2.0.0.md
new file mode 100644
index 0000000000..873e28170d
--- /dev/null
+++ b/docs/content.tr/posts/2020-04-07-release-statefun-2.0.0.md
@@ -0,0 +1,239 @@
+---
+authors:
+- name: Stephan Ewen
+ stephan: null
+ twitter: stephanewen
+date: "2020-04-07T08:00:00Z"
+subtitle: Making the Stream Processor for Event-driven Applications what the Database
+ was to CRUD Applications
+title: Stateful Functions 2.0 - An Event-driven Database on Apache Flink
+aliases:
+- /news/2020/04/07/release-statefun-2.0.0.html
+---
+
+Today, we are announcing the release of Stateful Functions (StateFun) 2.0 — the first release of Stateful Functions as part of the Apache Flink project.
+This release marks a big milestone: Stateful Functions 2.0 is not only an API update, but the **first version of an event-driven database** that is built on Apache Flink.
+
+Stateful Functions 2.0 makes it possible to combine StateFun’s powerful approach to state and composition with the elasticity, rapid scaling/scale-to-zero and rolling upgrade capabilities of FaaS implementations like AWS Lambda and modern resource orchestration frameworks like Kubernetes.
+
+With these features, Stateful Functions 2.0 addresses [two of the most cited shortcomings](https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf) of many FaaS setups today: consistent state and efficient messaging between functions.
+
+## An Event-driven Database
+
+When Stateful Functions joined Apache Flink at the beginning of this year, the project had started as a library on top of Flink to build general-purpose event-driven applications. Users would implement _functions_ that receive and send messages, and maintain state in persistent variables. Flink provided the runtime with efficient exactly-once state and messaging. Stateful Functions 1.0 was a FaaS-inspired mix between stream processing and actor programming — on steroids.
+
+
+
+
+
+
+
+
+
+ Fig.1: A ride-sharing app as a Stateful Functions example.
+
+
+
+
+
+
+
+In version 2.0, Stateful Functions now physically decouples the functions from Flink and the JVM, to invoke them through simple services. That makes it possible to execute functions on a FaaS platform, a Kubernetes deployment or behind a (micro) service.
+
+Flink invokes the functions through a service endpoint via HTTP or gRPC based on incoming events, and supplies state access. The system makes sure that only one invocation per entity (`type`+`ID`) is ongoing at any point in time, thus guaranteeing consistency through isolation.
+By supplying state access as part of the function invocation, the functions themselves behave like stateless applications and can be managed with the same simplicity and benefits: rapid scalability, scale-to-zero, rolling/zero-downtime upgrades and so on.
+
+
+
+
+
+ Fig.2: In Stateful Functions 2.0, functions are stateless and state access is part of the function invocation.
+
+
+
+
+
+
+
+The functions can be implemented in any programming language that can handle HTTP requests or bring up a gRPC server. The [StateFun project](https://github.com/apache/flink-statefun) includes a very slim SDK for Python, taking requests and dispatching them to annotated functions. We aim to provide similar SDKs for other languages, such as Go, JavaScript or Rust. Users do not need to write any Flink code (or JVM code) at all; data ingresses/egresses and function endpoints can be defined in a compact YAML spec.
+
+
+
+
+
+
+
+
+
+
+
+ Fig.3: A module declaring a remote endpoint and a function type.
+
+
+
+
+
+
+
+
+
+
+
+ Fig.4: A Python implementation of a simple classifier function.
+
+
+
+
+
+
+
+
+
+The Flink processes (and the JVM) are not executing any user-code at all — though this is possible, for performance reasons (see [Embedded Functions](#embedded-functions)). Rather than running application-specific dataflows, Flink here stores the state of the functions and provides the dynamic messaging plane through which functions message each other, carefully dispatching messages/invocations to the event-driven functions/services to maintain consistency guarantees.
+
+> _Effectively, Flink takes the role of the database, but tailored towards event-driven functions and services.
+> It integrates state storage with the messaging between (and the invocations of) functions and services.
+> Because of this, Stateful Functions 2.0 can be thought of as an “Event-driven Database” on Apache Flink._
+
+## “Event-driven Database” vs. “Request/Response Database”
+
+In the case of a traditional database or key/value store (let’s call them request/response databases), the application issues queries to the database (e.g. SQL via JDBC, GET/PUT via HTTP). In contrast, an event-driven database like StateFun **_inverts_** that relationship between database and application: the database invokes the functions/services based on arriving messages. This fits very naturally with FaaS and many event-driven application architectures.
+
+
+
+
+
+
+
+
+
+ Fig.5: Stateful Functions 2.0 inverts the relationship between database and application.
+
+
+
+
+
+
+
+In the case of applications built on request/response databases, the database is responsible only for the state. Communication between different functions/services is a separate concern handled within the application layer. In contrast to that, an event-driven database takes care of both state storage and message transport, in a tightly integrated manner.
+
+Similar to [Actor Programming](https://www.brianstorti.com/the-actor-model/), Stateful Functions uses the idea of _addressable entities_ - here, the entity is a function ``type`` with an invocation scoped to an ``ID``. These addressable entities own the state and are the targets of messages. Different to actor systems is that the application logic is external and the addressable entities are not physical objects in memory (i.e. actors), but rows in Flink's managed state, together with the entities’ mailboxes.
+
+### State and Consistency
+
+Besides matching the needs of serverless applications and FaaS well, the event-driven database approach also helps with simplifying consistent state management.
+
+Consider the example below, with two entities of an application — for example two microservices (_Service 1_, _Service 2_). _Service 1_ is invoked, updates the state in the database, and sends a request to _Service 2_. Assume that this request fails. There is, in general, no way for _Service 1_ to know whether _Service 2_ processed the request and updated its state or not (c.f. [Two Generals Problem](https://en.wikipedia.org/wiki/Two_Generals%27_Problem)). To work around that, many techniques exist — making requests idempotent and retrying, commit/rollback protocols, or external transaction coordinators, for example. Solving this in the application layer is complex enough, and including the database into these approaches only adds more complexity.
+
+In the scenario where the event-driven database takes care of state and messaging, we have a much easier problem to solve. Assume one shard of the database receives the initial message, updates its state, invokes _Service 1_, and routes the message produced by the function to another shard, to be delivered to _Service 2_. Now assume message transport errored — it may have failed or not, we cannot know for certain. Because the database is in charge of state and messaging, it can offer a generic solution to make sure that either both go through or none does, for example through transactions or [consistent snapshots](https://dl.acm.org/doi/abs/10.14778/3137765.3137777). The application functions are stateless and their invocations without side effects, which means they can be re-invoked again without implications on consistency.
+
+
+
+
+
+
+
+
+
+ Fig.6: The event-driven database integrates state access and messaging, guaranteeing consistency.
+
+
+
+
+
+
+
+That is the big lesson we learned from working on stream processing technology in the past years: **state access/updates and messaging need to be integrated**. This gives you consistency, scalable behavior and backpressures well based on both state access and compute bottlenecks.
+
+Despite state and computation being physically separated here, the scheduling/dispatching of function invocations is still integrated and physically co-located with state access, preserving the consistency guarantees given by physical state/compute co-location.
+
+## Remote, Co-located or Embedded Functions
+
+Functions can be deployed in various ways that trade off loose coupling and independent scaling with performance overhead. Each module of functions can be of a different kind, so some functions can run remote, while others could run embedded.
+
+### Remote Functions
+
+_Remote Functions_ are the mechanism described so far, where functions are deployed separately from the Flink StateFun cluster. The state/messaging tier (i.e. the Flink processes) and the function tier can be deployed and scaled independently. All function invocations are remote and have to go through the endpoint service.
+
+
+
+
+
+
+
+
+
+
+
+
+
+In a similar way as databases are accessed via a standardized protocol (e.g. ODBC/JDBC for relational databases, REST for many key/value stores), StateFun 2.0 invokes functions and services through a standardized protocol: HTTP or gRPC with data in a well-defined ProtoBuf schema.
+
+### Co-located Functions
+
+An alternative way of deploying functions is _co-location_ with the Flink JVM processes. In such a setup, each Flink TaskManager would talk to one function process sitting “next to it”. A common way to do this is to use a system like Kubernetes and deploy pods consisting of a Flink container and the function container that communicate via the pod-local network.
+
+This mode supports different languages while avoiding to route invocations through a Service/Gateway/LoadBalancer, but it cannot scale the state and compute parts independently.
+
+
+
+
+
+
+
+
+
+
+
+
+
+This style of deployment is similar to how [Apache Beam’s portability layer](https://beam.apache.org/roadmap/portability/) and [Flink’s Python API]({{ site.docs-stable }}/tutorials/python_table_api.html) deploy their non-JVM language SDKs.
+
+### Embedded Functions
+
+_Embedded Functions_ are the mode of Stateful Functions 1.0 and Flink’s Java/Scala stream processing APIs. Functions are deployed into the JVM and are directly invoked with the messages and state access. This is the most performant way, though at the cost of only supporting JVM languages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Following the database analogy, embedded functions are a bit like _stored procedures_, but in a principled way: the functions here are normal Java/Scala/Kotlin functions implementing standard interfaces and can be developed or tested in any IDE.
+
+## Loading Data into the Database
+
+When building a new stateful application, you usually don’t start from a completely blank slate. Often, the application has initial state, such as initial “bootstrap” state, or state from previous versions of the application. When using a database, one could simply bulk load the data to prepare the application.
+
+The equivalent step for Flink would be to write a [savepoint]({{ site.docs-stable }}/ops/state/savepoints.html) that contains the initial state. Savepoints are snapshots of the state of the distributed stream processing application and can be passed to Flink to start processing from that state. Think of them as a database dump, but of a distributed streaming database. In the case of StateFun, the savepoint would contain the state of the functions.
+
+To create a savepoint for a Stateful Functions program, check out the [State Bootstrapping API]({{< param DocsBaseUrl >}}flink-statefun-docs-release-2.0/deployment-and-operations/state-bootstrap.html) that is part of StateFun 2.0. The State Bootstrapping API uses Flink’s [DataSet API]({{ site.docs-stable }}/dev/batch/), but we plan to expand this to use SQL in the next versions.
+
+## Try it out and get involved!
+
+We hope that we could convey some of the excitement we feel about Stateful Functions. If we managed to pique your curiosity, try it out — for example, starting with [this walkthrough]({{< param DocsBaseUrl >}}flink-statefun-docs-release-2.0/getting-started/python_walkthrough.html).
+
+The project is still in a comparatively early stage, so if you want to get involved, there is lots to work on: SDKs for other languages (e.g. Go, JavaScript, Rust), ingresses/egresses and tools for testing, among others.
+
+To follow the project and learn more, please check out these resources:
+
+* Code: [https://github.com/apache/flink-statefun](https://github.com/apache/flink-statefun)
+* Docs: [{{< param DocsBaseUrl >}}flink-statefun-docs-release-2.0/]({{< param DocsBaseUrl >}}flink-statefun-docs-release-2.0/)
+* Apache Flink project site: [https://flink.apache.org/](https://flink.apache.org/)
+* Apache Flink on Twitter: [@ApacheFlink](https://twitter.com/apacheflink)
+* Stateful Functions Webpage: [https://statefun.io](https://statefun.io)
+* Stateful Functions on Twitter: [@StateFun_IO](https://twitter.com/statefun_io)
+
+## Thank you!
+
+The Apache Flink community would like to thank all contributors that have made this release possible:
+
+David Anderson, Dian Fu, Igal Shilman, Seth Wiesman, Stephan Ewen, Tzu-Li (Gordon) Tai, hequn8128
+
+
diff --git a/docs/content.tr/posts/2020-04-09-pyflink-udf-support-flink.md b/docs/content.tr/posts/2020-04-09-pyflink-udf-support-flink.md
new file mode 100644
index 0000000000..a1b5a4a78e
--- /dev/null
+++ b/docs/content.tr/posts/2020-04-09-pyflink-udf-support-flink.md
@@ -0,0 +1,197 @@
+---
+authors:
+- Jincheng: null
+ name: Jincheng Sun
+ twitter: sunjincheng121
+- markos: null
+ name: Markos Sfikas
+ twitter: MarkSfik
+date: "2020-04-09T12:00:00Z"
+excerpt: Flink 1.10 extends its support for Python by adding Python UDFs in PyFlink.
+ This post explains how UDFs work in PyFlink and gives some practical examples of
+ how to use UDFs in PyFlink.
+title: 'PyFlink: Introducing Python Support for UDFs in Flink''s Table API'
+aliases:
+- /2020/04/09/pyflink-udf-support-flink.html
+---
+
+Flink 1.9 introduced the Python Table API, allowing developers and data engineers to write Python Table API jobs for Table transformations and analysis, such as Python ETL or aggregate jobs. However, Python users faced some limitations when it came to support for Python UDFs in Flink 1.9, preventing them from extending the system’s built-in functionality.
+
+In Flink 1.10, the community further extended the support for Python by adding Python UDFs in PyFlink. Additionally, both the Python UDF environment and dependency management are now supported, allowing users to import third-party libraries in the UDFs, leveraging Python's rich set of third-party libraries.
+
+
+# Python Support for UDFs in Flink 1.10
+
+Before diving into how you can define and use Python UDFs, we explain the motivation and background behind how UDFs work in PyFlink and provide some additional context about the implementation of our approach. Below we give a brief introduction on the PyFlink architecture from job submission, all the way to executing the Python UDF.
+
+The PyFlink architecture mainly includes two parts — local and cluster — as shown in the architecture visual below. The local phase is the compilation of the job, and the cluster is the execution of the job.
+
+
+
+
+
+
+For the local part, the Python API is a mapping of the Java API: each time Python executes a method in the figure above, it will synchronously call the method corresponding to Java through Py4J, and finally generate a Java JobGraph, before submitting it to the cluster.
+
+For the cluster part, just like ordinary Java jobs, the JobMaster schedules tasks to TaskManagers. The tasks that include Python UDF in a TaskManager involve the execution of Java and Python operators. In the Python UDF operator, various gRPC services are used to provide different communications between the Java VM and the Python VM, such as DataService for data transmissions, StateService for state requirements, and Logging and Metrics Services. These services are built on Beam's Fn API. While currently only Process mode is supported for Python workers, support for Docker mode and External service mode is also considered for future Flink releases.
+
+# How to use PyFlink with UDFs in Flink 1.10
+
+This section provides some Python user defined function (UDF) examples, including how to install PyFlink, how to define/register/invoke UDFs in PyFlink and how to execute the job.
+
+
+## Install PyFlink
+Using Python in Apache Flink requires installing PyFlink. PyFlink is available through PyPI and can be easily installed using pip:
+
+```bash
+$ python -m pip install apache-flink
+```
+
+ Note
+Please note that Python 3.5 or higher is required to install and run PyFlink
+
+
+
+
+## Define a Python UDF
+
+There are many ways to define a Python scalar function, besides extending the base class `ScalarFunction`. The following example shows the different ways of defining a Python scalar function that takes two columns of `BIGINT` as input parameters and returns the sum of them as the result.
+
+```python
+# option 1: extending the base class `ScalarFunction`
+class Add(ScalarFunction):
+ def eval(self, i, j):
+ return i + j
+
+add = udf(Add(), [DataTypes.BIGINT(), DataTypes.BIGINT()], DataTypes.BIGINT())
+
+# option 2: Python function
+@udf(input_types=[DataTypes.BIGINT(), DataTypes.BIGINT()], result_type=DataTypes.BIGINT())
+def add(i, j):
+ return i + j
+
+# option 3: lambda function
+add = udf(lambda i, j: i + j, [DataTypes.BIGINT(), DataTypes.BIGINT()], DataTypes.BIGINT())
+
+# option 4: callable function
+class CallableAdd(object):
+ def __call__(self, i, j):
+ return i + j
+
+add = udf(CallableAdd(), [DataTypes.BIGINT(), DataTypes.BIGINT()], DataTypes.BIGINT())
+
+# option 5: partial function
+def partial_add(i, j, k):
+ return i + j + k
+
+add = udf(functools.partial(partial_add, k=1), [DataTypes.BIGINT(), DataTypes.BIGINT()],
+ DataTypes.BIGINT())
+```
+
+## Register a Python UDF
+
+```python
+# register the Python function
+table_env.register_function("add", add)
+```
+
+## Invoke a Python UDF
+
+```python
+# use the function in Python Table API
+my_table.select("add(a, b)")
+```
+
+Below, you can find a complete example of using Python UDF.
+
+```python
+from pyflink.datastream import StreamExecutionEnvironment
+from pyflink.table import StreamTableEnvironment, DataTypes
+from pyflink.table.descriptors import Schema, OldCsv, FileSystem
+from pyflink.table.udf import udf
+
+env = StreamExecutionEnvironment.get_execution_environment()
+env.set_parallelism(1)
+t_env = StreamTableEnvironment.create(env)
+
+add = udf(lambda i, j: i + j, [DataTypes.BIGINT(), DataTypes.BIGINT()], DataTypes.BIGINT())
+
+t_env.register_function("add", add)
+
+t_env.connect(FileSystem().path('/tmp/input')) \
+ .with_format(OldCsv()
+ .field('a', DataTypes.BIGINT())
+ .field('b', DataTypes.BIGINT())) \
+ .with_schema(Schema()
+ .field('a', DataTypes.BIGINT())
+ .field('b', DataTypes.BIGINT())) \
+ .create_temporary_table('mySource')
+
+t_env.connect(FileSystem().path('/tmp/output')) \
+ .with_format(OldCsv()
+ .field('sum', DataTypes.BIGINT())) \
+ .with_schema(Schema()
+ .field('sum', DataTypes.BIGINT())) \
+ .create_temporary_table('mySink')
+
+t_env.from_path('mySource')\
+ .select("add(a, b)") \
+ .insert_into('mySink')
+
+t_env.execute("tutorial_job")
+```
+
+## Submit the job
+
+Firstly, you need to prepare the input data in the “/tmp/input” file. For example,
+
+`$ echo "1,2" > /tmp/input`
+
+Next, you can run this example on the command line,
+
+`$ python python_udf_sum.py`
+
+The command builds and runs the Python Table API program in a local mini-cluster. You can also submit the Python Table API program to a remote cluster using different command lines, (see more details [here]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/cli.html#job-submission-examples)).
+
+Finally, you can see the execution result on the command line:
+
+`$ cat /tmp/output
+ 3`
+
+
+## Python UDF dependency management
+
+In many cases, you would like to import third-party dependencies in the Python UDF. The example below provides detailed guidance on how to manage such dependencies.
+
+Suppose you want to use the `mpmath` to perform the sum of the example above. The Python UDF may look like:
+
+```python
+@udf(input_types=[DataTypes.BIGINT(), DataTypes.BIGINT()], result_type=DataTypes.BIGINT())
+def add(i, j):
+ from mpmath import fadd # add third-party dependency
+ return int(fadd(i, j))
+```
+
+To make it available on the worker node that does not contain the dependency, you can specify the dependencies with the following commands and API:
+
+```bash
+$ cd /tmp
+$ echo mpmath==1.1.0 > requirements.txt
+$ pip download -d cached_dir -r requirements.txt --no-binary :all:
+```
+
+```python
+t_env.set_python_requirements("/tmp/requirements.txt", "/tmp/cached_dir")
+```
+
+A `requirements.txt` file that defines the third-party dependencies is used. If the dependencies cannot be accessed in the cluster, then you can specify a directory containing the installation packages of these dependencies by using the parameter "`requirements_cached_dir`", as illustrated in the example above. The dependencies will be uploaded to the cluster and installed offline.
+
+
+# Conclusion & Upcoming work
+
+In this blog post, we introduced the architecture of Python UDFs in PyFlink and provided some examples on how to define, register and invoke UDFs. Flink 1.10 brings Python support in the framework to new levels, allowing Python users to write even more magic with their preferred language. The community is actively working towards continuously improving the functionality and performance of PyFlink. Future work in upcoming releases will introduce support for Pandas UDFs in scalar and aggregate functions, add support to use Python UDFs through the SQL client to further expand the usage scope of Python UDFs, provide support for a Python ML Pipeline API and finally work towards even more performance improvements. The picture below provides more details on the roadmap for succeeding releases.
+
+
+
+
+
diff --git a/docs/content.tr/posts/2020-04-15-flink-serialization-tuning-vol-1.md b/docs/content.tr/posts/2020-04-15-flink-serialization-tuning-vol-1.md
new file mode 100644
index 0000000000..70c0f5e040
--- /dev/null
+++ b/docs/content.tr/posts/2020-04-15-flink-serialization-tuning-vol-1.md
@@ -0,0 +1,275 @@
+---
+authors:
+- Nico Kruber: null
+ name: Nico Kruber
+date: "2020-04-15T08:00:00Z"
+excerpt: Serialization is a crucial element of your Flink job. This article is the
+ first in a series of posts that will highlight Flink’s serialization stack, and
+ looks at the different ways Flink can serialize your data types.
+title: 'Flink Serialization Tuning Vol. 1: Choosing your Serializer — if you can'
+aliases:
+- /news/2020/04/15/flink-serialization-tuning-vol-1.html
+---
+
+Almost every Flink job has to exchange data between its operators and since these records may not only be sent to another instance in the same JVM but instead to a separate process, records need to be serialized to bytes first. Similarly, Flink’s off-heap state-backend is based on a local embedded RocksDB instance which is implemented in native C++ code and thus also needs transformation into bytes on every state access. Wire and state serialization alone can easily cost a lot of your job’s performance if not executed correctly and thus, whenever you look into the profiler output of your Flink job, you will most likely see serialization in the top places for using CPU cycles.
+
+Since serialization is so crucial to your Flink job, we would like to highlight Flink’s serialization stack in a series of blog posts starting with looking at the different ways Flink can serialize your data types.
+
+# Recap: Flink Serialization
+
+Flink handles [data types and serialization]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/types_serialization.html) with its own type descriptors, generic type extraction, and type serialization framework. We recommend reading through the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/types_serialization.html) first in order to be able to follow the arguments we present below. In essence, Flink tries to infer information about your job’s data types for wire and state serialization, and to be able to use grouping, joining, and aggregation operations by referring to individual field names, e.g.
+`stream.keyBy(“ruleId”)` or
+`dataSet.join(another).where("name").equalTo("personName")`. It also allows optimizations in the serialization format as well as reducing unnecessary de/serializations (mainly in certain Batch operations as well as in the SQL/Table APIs).
+
+
+# Choice of Serializer
+
+Apache Flink's out-of-the-box serialization can be roughly divided into the following groups:
+
+- **Flink-provided special serializers** for basic types (Java primitives and their boxed form), arrays, composite types (tuples, Scala case classes, Rows), and a few auxiliary types (Option, Either, Lists, Maps, …),
+
+- **POJOs**; a public, standalone class with a public no-argument constructor and all non-static, non-transient fields in the class hierarchy either public or with a public getter- and a setter-method; see [POJO Rules]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/types_serialization.html#rules-for-pojo-types),
+
+- **Generic types**; user-defined data types that are not recognized as a POJO and then serialized via [Kryo](https://github.com/EsotericSoftware/kryo).
+
+Alternatively, you can also register [custom serializers]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/custom_serializers.html) for user-defined data types. This includes writing your own serializers or integrating other serialization systems like [Google Protobuf](https://developers.google.com/protocol-buffers/) or [Apache Thrift](https://thrift.apache.org/) via [Kryo](https://github.com/EsotericSoftware/kryo). Overall, this gives quite a number of different options of serializing user-defined data types and we will elaborate seven of them in the sections below.
+
+
+## PojoSerializer
+
+As outlined above, if your data type is not covered by a specialized serializer but follows the [POJO Rules]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/types_serialization.html#rules-for-pojo-types), it will be serialized with the [PojoSerializer](https://github.com/apache/flink/blob/release-1.10.0/flink-core/src/main/java/org/apache/flink/api/java/typeutils/runtime/PojoSerializer.java) which uses Java reflection to access an object’s fields. It is fast, generic, Flink-specific, and supports [state schema evolution]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/stream/state/schema_evolution.html) out of the box. If a composite data type cannot be serialized as a POJO, you will find the following message (or similar) in your cluster logs:
+
+> 15:45:51,460 INFO org.apache.flink.api.java.typeutils.TypeExtractor - Class … cannot be used as a POJO type because not all fields are valid POJO fields, and must be processed as GenericType. Please read the Flink documentation on "Data Types & Serialization" for details of the effect on performance.
+
+
+This means, that the PojoSerializer will not be used, but instead Flink will fall back to Kryo for serialization (see below). We will have a more detailed look into a few (more) situations that can lead to unexpected Kryo fallbacks in the second part of this blog post series.
+
+
+## Tuple Data Types
+
+Flink comes with a predefined set of tuple types which all have a fixed length and contain a set of strongly-typed fields of potentially different types. There are implementations for `Tuple0`, `Tuple1`, …, `Tuple25` and they may serve as easy-to-use wrappers that spare the creation of POJOs for each and every combination of objects you need to pass between computations. With the exception of `Tuple0`, these are serialized and deserialized with the [TupleSerializer](https://github.com/apache/flink/blob/release-1.10.0/flink-core/src/main/java/org/apache/flink/api/java/typeutils/runtime/TupleSerializer.java) and the according fields’ serializers. Since tuple classes are completely under the control of Flink, both actions can be performed without reflection by accessing the appropriate fields directly. This certainly is a (performance) advantage when working with tuples instead of POJOs. Tuples, however, are not as flexible and certainly less descriptive in code.
+
+
+
+ Note
+ Since `Tuple0` does not contain any data and therefore is probably a bit special anyway, it will use a special serializer implementation: [Tuple0Serializer](https://github.com/apache/flink/blob/release-1.10.0/flink-core/src/main/java/org/apache/flink/api/java/typeutils/runtime/Tuple0Serializer.java).
+
+
+## Row Data Types
+
+Row types are mainly used by the Table and SQL APIs of Flink. A `Row` groups an arbitrary number of objects together similar to the tuples above. These fields are not strongly typed and may all be of different types. Because field types are missing, Flink’s type extraction cannot automatically extract type information and users of a `Row` need to manually tell Flink about the row's field types. The [RowSerializer](https://github.com/apache/flink/blob/release-1.10.0/flink-core/src/main/java/org/apache/flink/api/java/typeutils/runtime/RowSerializer.java) will then make use of these types for efficient serialization.
+
+Row type information can be provided in two ways:
+
+- you can have your source or operator implement `ResultTypeQueryable`:
+
+```java
+public static class RowSource implements SourceFunction, ResultTypeQueryable {
+ // ...
+
+ @Override
+ public TypeInformation getProducedType() {
+ return Types.ROW(Types.INT, Types.STRING, Types.OBJECT_ARRAY(Types.STRING));
+ }
+}
+```
+
+- you can provide the types when building the job graph by using `SingleOutputStreamOperator#returns()`
+
+```java
+DataStream sourceStream =
+ env.addSource(new RowSource())
+ .returns(Types.ROW(Types.INT, Types.STRING, Types.OBJECT_ARRAY(Types.STRING)));
+```
+
+
+ Warning
+If you fail to provide the type information for a `Row`, Flink identifies that `Row` is not a valid POJO type according to the rules above and falls back to Kryo serialization (see below) which you will also see in the logs as:
+
+`13:10:11,148 INFO org.apache.flink.api.java.typeutils.TypeExtractor - Class class org.apache.flink.types.Row cannot be used as a POJO type because not all fields are valid POJO fields, and must be processed as GenericType. Please read the Flink documentation on "Data Types & Serialization" for details of the effect on performance.`
+
+
+## Avro
+
+Flink offers built-in support for the [Apache Avro](http://avro.apache.org/) serialization framework (currently using version 1.8.2) by adding the `org.apache.flink:flink-avro` dependency into your job. Flink’s [AvroSerializer](https://github.com/apache/flink/blob/release-1.10.0/flink-formats/flink-avro/src/main/java/org/apache/flink/formats/avro/typeutils/AvroSerializer.java) can then use Avro’s specific, generic, and reflective data serialization and make use of Avro’s performance and flexibility, especially in terms of [evolving the schema](https://avro.apache.org/docs/current/spec.html#Schema+Resolution) when the classes change over time.
+
+### Avro Specific
+
+Avro specific records will be automatically detected by checking that the given type’s type hierarchy contains the `SpecificRecordBase` class. You can either specify your concrete Avro type, or—if you want to be more generic and allow different types in your operator—use the `SpecificRecordBase` type (or a subtype) in your user functions, in `ResultTypeQueryable#getProducedType()`, or in `SingleOutputStreamOperator#returns()`. Since specific records use generated Java code, they are strongly typed and allow direct access to the fields via known getters and setters.
+
+
+ Warning If you specify the Flink type as `SpecificRecord` and not `SpecificRecordBase`, Flink will not see this as an Avro type. Instead, it will use Kryo to de/serialize any objects which may be considerably slower.
+
+
+### Avro Generic
+
+Avro’s `GenericRecord` types cannot, unfortunately, be used automatically since they require the user to [specify a schema](https://avro.apache.org/docs/1.8.2/gettingstartedjava.html#Serializing+and+deserializing+without+code+generation) (either manually or by retrieving it from some schema registry). With that schema, you can provide the right type information by either of the following options just like for the Row Types above:
+
+- implement `ResultTypeQueryable`:
+
+```java
+public static class AvroGenericSource implements SourceFunction, ResultTypeQueryable {
+ private final GenericRecordAvroTypeInfo producedType;
+
+ public AvroGenericSource(Schema schema) {
+ this.producedType = new GenericRecordAvroTypeInfo(schema);
+ }
+
+ @Override
+ public TypeInformation getProducedType() {
+ return producedType;
+ }
+}
+```
+- provide type information when building the job graph by using `SingleOutputStreamOperator#returns()`
+
+```java
+DataStream sourceStream =
+ env.addSource(new AvroGenericSource())
+ .returns(new GenericRecordAvroTypeInfo(schema));
+```
+Without this type information, Flink will fall back to Kryo for serialization which would serialize the schema into every record, over and over again. As a result, the serialized form will be bigger and more costly to create.
+
+
+ Note
+ Since Avro’s `Schema` class is not serializable, it can not be sent around as is. You can work around this by converting it to a String and parsing it back when needed. If you only do this once on initialization, there is practically no difference to sending it directly.
+
+
+### Avro Reflect
+
+The third way of using Avro is to exchange Flink’s PojoSerializer (for POJOs according to the rules above) for Avro’s reflection-based serializer. This can be enabled by calling
+
+```java
+env.getConfig().enableForceAvro();
+```
+
+## Kryo
+
+Any class or object which does not fall into the categories above or is covered by a Flink-provided special serializer is de/serialized with a fallback to [Kryo](https://github.com/EsotericSoftware/kryo) (currently version 2.24.0) which is a powerful and generic serialization framework in Java. Flink calls such a type a *generic type* and you may stumble upon `GenericTypeInfo` when debugging code. If you are using Kryo serialization, make sure to register your types with kryo:
+
+```java
+env.getConfig().registerKryoType(MyCustomType.class);
+```
+Registering types adds them to an internal map of classes to tags so that, during serialization, Kryo does not have to add the fully qualified class names as a prefix into the serialized form. Instead, Kryo uses these (integer) tags to identify the underlying classes and reduce serialization overhead.
+
+
+ Note
+Flink will store Kryo serializer mappings from type registrations in its checkpoints and savepoints and will retain them across job (re)starts.
+
+
+### Disabling Kryo
+
+If desired, you can disable the Kryo fallback, i.e. the ability to serialize generic types, by calling
+
+```java
+env.getConfig().disableGenericTypes();
+```
+
+This is mostly useful for finding out where these fallbacks are applied and replacing them with better serializers. If your job has any generic types with this configuration, it will fail with
+
+> Exception in thread "main" java.lang.UnsupportedOperationException: Generic types have been disabled in the ExecutionConfig and type … is treated as a generic type.
+
+If you cannot immediately see from the type where it is being used, this log message also gives you a stacktrace that can be used to set breakpoints and find out more details in your IDE.
+
+
+## Apache Thrift (via Kryo)
+
+In addition to the variants above, Flink also allows you to [register other type serialization frameworks]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/custom_serializers.html#register-a-custom-serializer-for-your-flink-program) with Kryo. After adding the appropriate dependencies from the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/custom_serializers.html#register-a-custom-serializer-for-your-flink-program) (`com.twitter:chill-thrift` and `org.apache.thrift:libthrift`), you can use [Apache Thrift](https://thrift.apache.org/) like the following:
+
+```java
+env.getConfig().addDefaultKryoSerializer(MyCustomType.class, TBaseSerializer.class);
+```
+
+This only works if generic types are not disabled and `MyCustomType` is a Thrift-generated data type. If the data type is not generated by Thrift, Flink will fail at runtime with an exception like this:
+
+> java.lang.ClassCastException: class MyCustomType cannot be cast to class org.apache.thrift.TBase (MyCustomType and org.apache.thrift.TBase are in unnamed module of loader 'app')
+
+
+ Note
+Please note that `TBaseSerializer` can be registered as a default Kryo serializer as above (and as specified in [its documentation](https://github.com/twitter/chill/blob/v0.7.6/chill-thrift/src/main/java/com/twitter/chill/thrift/TBaseSerializer.java)) or via `registerTypeWithKryoSerializer`. In practice, we found both ways working. We also saw no difference between registering Thrift classes in addition to the call above. Both may be different in your scenario.
+
+
+## Protobuf (via Kryo)
+
+In a way similar to Apache Thrift, [Google Protobuf](https://developers.google.com/protocol-buffers/) may be [registered as a custom serializer]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/custom_serializers.html#register-a-custom-serializer-for-your-flink-program) after adding the right dependencies (`com.twitter:chill-protobuf` and `com.google.protobuf:protobuf-java`):
+
+```java
+env.getConfig().registerTypeWithKryoSerializer(MyCustomType.class, ProtobufSerializer.class);
+```
+This will work as long as generic types have not been disabled (this would disable Kryo for good). If `MyCustomType` is not a Protobuf-generated class, your Flink job will fail at runtime with the following exception:
+
+> java.lang.ClassCastException: class `MyCustomType` cannot be cast to class com.google.protobuf.Message (`MyCustomType` and com.google.protobuf.Message are in unnamed module of loader 'app')
+
+
+ Note
+Please note that `ProtobufSerializer` can be registered as a default Kryo serializer (as specified in the [Protobuf documentation](https://github.com/twitter/chill/blob/v0.7.6/chill-thrift/src/main/java/com/twitter/chill/thrift/TBaseSerializer.java)) or via `registerTypeWithKryoSerializer` (as presented here). In practice, we found both ways working. We also saw no difference between registering your Protobuf classes in addition to the call above. Both may be different in your scenario.
+
+
+# State Schema Evolution
+
+Before taking a closer look at the performance of each of the serializers described above, we would like to emphasize that performance is not everything that counts inside a real-world Flink job. Types for storing state, for example, should be able to evolve their schema (add/remove/change fields) throughout the lifetime of the job without losing previous state. This is what Flink calls [State Schema Evolution]({{< param DocsBaseUrl >}}flink-docs-stable/dev/stream/state/schema_evolution.html). Currently, as of Flink 1.10, there are only two serializers that support out-of-the-box schema evolution: POJO and Avro. For anything else, if you want to change the state schema, you will have to either implement your own [custom serializers]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/stream/state/custom_serialization.html) or use the [State Processor API]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/libs/state_processor_api.html) to modify your state for the new code.
+
+# Performance Comparison
+
+With so many options for serialization, it is actually not easy to make the right choice. We already saw some technical advantages and disadvantages of each of them outlined above. Since serializers are at the core of your Flink jobs and usually also sit on the hot path (per record invocations), let us actually take a deeper look into their performance with the help of the Flink benchmarks project at [https://github.com/dataArtisans/flink-benchmarks](https://github.com/dataArtisans/flink-benchmarks). This project adds a few micro-benchmarks on top of Flink (some more low-level than others) to track performance regressions and improvements. Flink’s continuous benchmarks for monitoring the serialization stack’s performance are implemented in [SerializationFrameworkMiniBenchmarks.java](https://github.com/dataArtisans/flink-benchmarks/blob/master/src/main/java/org/apache/flink/benchmark/SerializationFrameworkMiniBenchmarks.java). This is only a subset of all available serialization benchmarks though and you will find the complete set in [SerializationFrameworkAllBenchmarks.java](https://github.com/dataArtisans/flink-benchmarks/blob/master/src/main/java/org/apache/flink/benchmark/full/SerializationFrameworkAllBenchmarks.java). All of these use the same definition of a small POJO that may cover average use cases. Essentially (without constructors, getters, and setters), these are the data types that it uses for evaluating performance:
+
+```java
+public class MyPojo {
+ public int id;
+ private String name;
+ private String[] operationNames;
+ private MyOperation[] operations;
+ private int otherId1;
+ private int otherId2;
+ private int otherId3;
+ private Object someObject;
+}
+public class MyOperation {
+ int id;
+ protected String name;
+}
+```
+
+This is mapped to tuples, rows, Avro specific records, Thrift and Protobuf representations appropriately and sent through a simple Flink job at parallelism 4 where the data type is used during network communication like this:
+
+```java
+env.setParallelism(4);
+env.addSource(new PojoSource(RECORDS_PER_INVOCATION, 10))
+ .rebalance()
+ .addSink(new DiscardingSink<>());
+```
+After running this through the [jmh](http://openjdk.java.net/projects/code-tools/jmh/) micro-benchmarks defined in [SerializationFrameworkAllBenchmarks.java](https://github.com/dataArtisans/flink-benchmarks/blob/master/src/main/java/org/apache/flink/benchmark/full/SerializationFrameworkAllBenchmarks.java), I retrieved the following performance results for Flink 1.10 on my machine (in number of operations per millisecond):
+
+
+
+
+
+
+
+A few takeaways from these numbers:
+
+- The default fallback from POJO to Kryo reduces performance by 75%.
+ Registering types with Kryo significantly improves its performance with only 64% fewer operations than by using a POJO.
+
+- Avro GenericRecord and SpecificRecord are roughly serialized at the same speed.
+
+- Avro Reflect serialization is even slower than Kryo default (-45%).
+
+- Tuples are the fastest, closely followed by Rows. Both leverage fast specialized serialization code based on direct access without Java reflection.
+
+- Using a (nested) Tuple instead of a POJO may speed up your job by 42% (but is less flexible!).
+ Having code-generation for the PojoSerializer ([FLINK-3599](https://jira.apache.org/jira/browse/FLINK-3599)) may actually close that gap (or at least move closer to the RowSerializer). If you feel like giving the implementation a go, please give the Flink community a note and we will see whether we can make that happen.
+
+- If you cannot use POJOs, try to define your data type with one of the serialization frameworks that generate specific code for it: Protobuf, Avro, Thrift (in that order, performance-wise).
+
+
+ Note As with all benchmarks, please bear in mind that these numbers only give a hint on Flink’s serializer performance in a specific scenario. They may be different with your data types but the rough classification is probably the same. If you want to be sure, please verify the results with your data types. You should be able to copy from `SerializationFrameworkAllBenchmarks.java` to set up your own micro-benchmarks or integrate different serialization benchmarks into your own tooling.
+
+
+# Conclusion
+
+In the sections above, we looked at how Flink performs serialization for different sorts of data types and elaborated the technical advantages and disadvantages. For data types used in Flink state, you probably want to leverage either POJO or Avro types which, currently, are the only ones supporting state evolution out of the box and allow your stateful application to develop over time. POJOs are usually faster in the de/serialization while Avro may support more flexible schema evolution and may integrate better with external systems. Please note, however, that you can use different serializers for external vs. internal components or even state vs. network communication.
+
+The fastest de/serialization is achieved with Flink’s internal tuple and row serializers which can access these types' fields directly without going via reflection. With roughly 30% decreased throughput as compared to tuples, Protobuf and POJO types do not perform too badly on their own and are more flexible and maintainable. Avro (specific and generic) records as well as Thrift data types further reduce performance by 20% and 30%, respectively. You definitely want to avoid Kryo as that reduces throughput further by around 50% and more!
+
+The next article in this series will use this finding as a starting point to look into a few common pitfalls and obstacles of avoiding Kryo, how to get the most out of the PojoSerializer, and a few more tuning techniques with respect to serialization. Stay tuned for more.
diff --git a/docs/content.tr/posts/2020-04-21-memory-management-improvements-flink-1.10.md b/docs/content.tr/posts/2020-04-21-memory-management-improvements-flink-1.10.md
new file mode 100644
index 0000000000..9c66161e0a
--- /dev/null
+++ b/docs/content.tr/posts/2020-04-21-memory-management-improvements-flink-1.10.md
@@ -0,0 +1,88 @@
+---
+authors:
+- andrey: null
+ name: Andrey Zagrebin
+date: "2020-04-21T12:00:00Z"
+excerpt: This post discusses the recent changes to the memory model of the Task Managers
+ and configuration options for your Flink applications in Flink 1.10.
+title: Memory Management Improvements with Apache Flink 1.10
+aliases:
+- /news/2020/04/21/memory-management-improvements-flink-1.10.html
+---
+
+Apache Flink 1.10 comes with significant changes to the memory model of the Task Managers and configuration options for your Flink applications. These recently-introduced changes make Flink more adaptable to all kinds of deployment environments (e.g. Kubernetes, Yarn, Mesos), providing strict control over its memory consumption. In this post, we describe Flink’s memory model, as it stands in Flink 1.10, how to set up and manage memory consumption of your Flink applications and the recent changes the community implemented in the latest Apache Flink release.
+
+## Introduction to Flink’s memory model
+
+Having a clear understanding of Apache Flink’s memory model allows you to manage resources for the various workloads more efficiently. The following diagram illustrates the main memory components in Flink:
+
+
+
+
+Flink: Total Process Memory
+
+
+
+The Task Manager process is a JVM process. On a high level, its memory consists of the *JVM Heap* and *Off-Heap* memory. These types of memory are consumed by Flink directly or by JVM for its specific purposes (i.e. metaspace etc.). There are two major memory consumers within Flink: the user code of job operator tasks and the framework itself consuming memory for internal data structures, network buffers, etc.
+
+**Please note that** the user code has direct access to all memory types: *JVM Heap, Direct* and *Native memory*. Therefore, Flink cannot really control its allocation and usage. There are however two types of Off-Heap memory which are consumed by tasks and controlled explicitly by Flink:
+
+- *Managed Memory* (Off-Heap)
+- *Network Buffers*
+
+The latter is part of the *JVM Direct Memory*, allocated for user record data exchange between operator tasks.
+
+## How to set up Flink memory
+
+With the latest release of Flink 1.10 and in order to provide better user experience, the framework comes with both high-level and fine-grained tuning of memory components. There are essentially three alternatives to setting up memory in Task Managers.
+
+The first two — and simplest — alternatives are configuring one of the two following options for total memory available for the JVM process of the Task Manager:
+
+- *Total Process Memory*: total memory consumed by the Flink Java application (including user code) and by the JVM to run the whole process.
+- *Total Flink Memory*: only memory consumed by the Flink Java application, including user code but excluding memory allocated by JVM to run it
+
+It is advisable to configure the *Total Flink Memory* for standalone deployments where explicitly declaring how much memory is given to Flink is a common practice, while the outer *JVM overhead* is of little interest. For the cases of deploying Flink in containerized environments (such as [Kubernetes]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/deployment/kubernetes.html), [Yarn]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/deployment/yarn_setup.html) or [Mesos]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/deployment/mesos.html)), the *Total Process Memory* option is recommended instead, because it becomes the size for the total memory of the requested container. Containerized environments usually strictly enforce this memory limit.
+
+If you want more fine-grained control over the size of *JVM Heap* and *Managed Memory* (Off-Heap), there is also a second alternative to configure both *[Task Heap]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/memory/mem_setup.html#task-operator-heap-memory)* and *[Managed Memory]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/memory/mem_setup.html#managed-memory)*. This alternative gives a clear separation between the heap memory and any other memory types.
+
+In line with the community’s efforts to [unify batch and stream processing](https://flink.apache.org/news/2019/02/13/unified-batch-streaming-blink.html), this model works universally for both scenarios. It allows sharing the *JVM Heap* memory between the user code of operator tasks in any workload and the heap state backend in stream processing scenarios. In a similar way, the *Managed Memory* can be used for batch spilling and for the RocksDB state backend in streaming.
+
+The remaining memory components are automatically adjusted either based on their default values or additionally configured parameters. Flink also checks the overall consistency. You can find more information about the different memory components in the corresponding [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/memory/mem_detail.html). Additionally, you can try different configuration options with the [configuration spreadsheet](https://docs.google.com/spreadsheets/d/1mJaMkMPfDJJ-w6nMXALYmTc4XxiV30P5U7DzgwLkSoE/edit#gid=0) of [FLIP-49](https://cwiki.apache.org/confluence/display/FLINK/FLIP-49%3A+Unified+Memory+Configuration+for+TaskExecutors) and check the corresponding results for your individual case.
+
+If you are migrating from a Flink version older than 1.10, we suggest following the steps in the [migration guide]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/memory/mem_migration.html) of the Flink documentation.
+
+## Other components
+
+While configuring Flink’s memory, the size of different memory components can either be fixed with the value of the respective option or tuned using multiple options. Below we provide some more insight about the memory setup.
+
+### Fractions of the Total Flink Memory
+
+This method allows a proportional breakdown of the *Total Flink Memory* where the [Managed Memory]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/memory/mem_setup.html#managed-memory) (if not set explicitly) and [Network Buffers]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/memory/mem_detail.html#capped-fractionated-components) can take certain fractions of it. The remaining memory is then assigned to the [Task Heap]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/memory/mem_setup.html#task-operator-heap-memory) (if not set explicitly) and other fixed *JVM Heap* and *Off-Heap components*. The following picture represents an example of such a setup:
+
+
+
+
+Flink: Example of Memory Setup
+
+
+
+**Please note that**
+
+- Flink will verify that the size of the derived *Network Memory* is between its minimum and maximum value, otherwise Flink’s startup will fail. The maximum and minimum limits have default values which can be overwritten by the respective configuration options.
+- In general, the configured fractions are treated by Flink as hints. Under certain scenarios, the derived value might not match the fraction. For example, if the *Total Flink Memory* and the *Task Heap* are configured to fixed values, the *Managed Memory* will get a certain fraction and the *Network Memory* will get the remaining memory which might not exactly match its fraction.
+
+### More hints to control the container memory limit
+
+The heap and direct memory usage are managed by the JVM. There are also many other possible sources of native memory consumption in Apache Flink or its user applications which are not managed by Flink or the JVM. Controlling their limits is often difficult which complicates debugging of potential memory leaks. If Flink’s process allocates too much memory in an unmanaged way, it can often result in killing Task Manager containers in containerized environments. In this case, it may be hard to understand which type of memory consumption has exceeded its limit. Flink 1.10 introduces some specific tuning options to clearly represent such components. Although Flink cannot always enforce strict limits and borders among them, the idea here is to explicitly plan the memory usage. Below we provide some examples of how memory setup can prevent containers exceeding their memory limit:
+
+- [RocksDB state cannot grow too big]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/memory/mem_tuning.html#rocksdb-state-backend). The memory consumption of RocksDB state backend is accounted for in the *Managed Memory*. RocksDB respects its limit by default (only since Flink 1.10). You can increase the *Managed Memory* size to improve RocksDB’s performance or decrease it to save resources.
+
+- [User code or its dependencies consume significant off-heap memory]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/memory/mem_setup.html#configure-off-heap-memory-direct-or-native). Tuning the *Task Off-Heap* option can assign additional direct or native memory to the user code or any of its dependencies. Flink cannot control native allocations but it sets the limit for *JVM Direct* memory allocations. The *Direct* memory limit is enforced by the JVM.
+
+- [JVM metaspace requires additional memory]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/memory/mem_detail.html#jvm-parameters). If you encounter `OutOfMemoryError: Metaspace`, Flink provides an option to increase its limit and the JVM will ensure that it is not exceeded.
+
+- [JVM requires more internal memory]({{< param DocsBaseUrl >}}flink-docs-release-1.10/ops/memory/mem_detail.html#capped-fractionated-components). There is no direct control over certain types of JVM process allocations but Flink provides *JVM Overhead* options. The options allow declaring an additional amount of memory, anticipated for those allocations and not covered by other options.
+
+## Conclusion
+
+The latest Flink release (Flink 1.10) introduces some significant changes to Flink’s memory configuration, making it possible to manage your application memory and debug Flink significantly better than before. Future developments in this area also include adopting a similar memory model for the job manager process in [FLIP-116](https://cwiki.apache.org/confluence/display/FLINK/FLIP+116%3A+Unified+Memory+Configuration+for+Job+Managers), so stay tuned for more additions and features in upcoming releases. If you have any suggestions or questions for the community, we encourage you to sign up to the Apache Flink [mailing lists](https://flink.apache.org/community.html#mailing-lists) and become part of the discussion there.
diff --git a/docs/content.tr/posts/2020-04-24-release-1.9.3.md b/docs/content.tr/posts/2020-04-24-release-1.9.3.md
new file mode 100644
index 0000000000..301d6e73f9
--- /dev/null
+++ b/docs/content.tr/posts/2020-04-24-release-1.9.3.md
@@ -0,0 +1,136 @@
+---
+authors:
+- Dian Fu: null
+ name: Dian Fu
+ twitter: DianFu11
+date: "2020-04-24T12:00:00Z"
+title: Apache Flink 1.9.3 Released
+aliases:
+- /news/2020/04/24/release-1.9.3.html
+---
+
+The Apache Flink community released the third bugfix version of the Apache Flink 1.9 series.
+
+This release includes 38 fixes and minor improvements for Flink 1.9.2. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.9.3.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.9.3
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.9.3
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.9.3
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-15143 ] - Create document for FLIP-49 TM memory model and configuration guide
+
+[FLINK-16389 ] - Bump Kafka 0.10 to 0.10.2.2
+
+
+
+ Bug
+
+
+[FLINK-11193 ] - Rocksdb timer service factory configuration option is not settable per job
+
+[FLINK-14316 ] - Stuck in "Job leader ... lost leadership" error
+
+[FLINK-14560 ] - The value of taskmanager.memory.size in flink-conf.yaml is set to zero will cause taskmanager not to work
+
+[FLINK-15010 ] - Temp directories flink-netty-shuffle-* are not cleaned up
+
+[FLINK-15085 ] - HistoryServer dashboard config json out of sync
+
+[FLINK-15386 ] - SingleJobSubmittedJobGraphStore.putJobGraph has a logic error
+
+[FLINK-15575 ] - Azure Filesystem Shades Wrong Package "httpcomponents"
+
+[FLINK-15638 ] - releasing/create_release_branch.sh does not set version in flink-python/pyflink/version.py
+
+[FLINK-15812 ] - HistoryServer archiving is done in Dispatcher main thread
+
+[FLINK-15844 ] - Removal of JobWithJars.buildUserCodeClassLoader method without Configuration breaks backwards compatibility
+
+[FLINK-15863 ] - Fix docs stating that savepoints are relocatable
+
+[FLINK-16047 ] - Blink planner produces wrong aggregate results with state clean up
+
+[FLINK-16242 ] - BinaryGeneric serialization error cause checkpoint failure
+
+[FLINK-16308 ] - SQL connector download links are broken
+
+[FLINK-16373 ] - EmbeddedLeaderService: IllegalStateException: The RPC connection is already closed
+
+[FLINK-16573 ] - Kinesis consumer does not properly shutdown RecordFetcher threads
+
+[FLINK-16576 ] - State inconsistency on restore with memory state backends
+
+[FLINK-16696 ] - Savepoint trigger documentation is insufficient
+
+[FLINK-16703 ] - AkkaRpcActor state machine does not record transition to terminating state.
+
+[FLINK-16836 ] - Losing leadership does not clear rpc connection in JobManagerLeaderListener
+
+[FLINK-16860 ] - Failed to push filter into OrcTableSource when upgrading to 1.9.2
+
+[FLINK-16916 ] - The logic of NullableSerializer#copy is wrong
+
+[FLINK-17062 ] - Fix the conversion from Java row type to Python row type
+
+
+
+ Improvement
+
+
+[FLINK-14278 ] - Pass in ioExecutor into AbstractDispatcherResourceManagerComponentFactory
+
+[FLINK-15908 ] - Add description of support 'pip install' to 1.9.x documents
+
+[FLINK-15909 ] - Add PyPI release process into the subsequent release of 1.9.x
+
+[FLINK-15938 ] - Idle state not cleaned in StreamingJoinOperator and StreamingSemiAntiJoinOperator
+
+[FLINK-16018 ] - Improve error reporting when submitting batch job (instead of AskTimeoutException)
+
+[FLINK-16031 ] - Improve the description in the README file of PyFlink 1.9.x
+
+[FLINK-16167 ] - Update documentation about python shell execution
+
+[FLINK-16280 ] - Fix sample code errors in the documentation about elasticsearch connector
+
+[FLINK-16697 ] - Disable JMX rebinding
+
+[FLINK-16862 ] - Remove example url in quickstarts
+
+[FLINK-16942 ] - ES 5 sink should allow users to select netty transport client
+
+
+
+ Task
+
+
+[FLINK-11767 ] - Introduce new TypeSerializerUpgradeTestBase, new PojoSerializerUpgradeTest
+
+[FLINK-16454 ] - Update the copyright year in NOTICE files
+
+
diff --git a/docs/content.tr/posts/2020-05-04-season-of-docs.md b/docs/content.tr/posts/2020-05-04-season-of-docs.md
new file mode 100644
index 0000000000..c7d27f3f4e
--- /dev/null
+++ b/docs/content.tr/posts/2020-05-04-season-of-docs.md
@@ -0,0 +1,82 @@
+---
+authors:
+- morsapaes: null
+ name: Marta Paes
+ twitter: morsapaes
+date: "2020-05-04T06:00:00Z"
+excerpt: The Flink community is thrilled to share that the project is applying again
+ to Google Season of Docs (GSoD) this year! If you’re unfamiliar with the program,
+ GSoD is a great initiative organized by Google Open Source to pair technical writers
+ with mentors to work on documentation for open source projects. Does working shoulder
+ to shoulder with the Flink community on documentation sound exciting? We’d love
+ to hear from you!
+title: Applying to Google Season of Docs 2020
+aliases:
+- /news/2020/05/04/season-of-docs.html
+---
+
+The Flink community is thrilled to share that the project is applying again to [Google Season of Docs](https://developers.google.com/season-of-docs/) (GSoD) this year! If you’re unfamiliar with the program, GSoD is a great initiative organized by [Google Open Source](https://opensource.google.com/) to pair technical writers with mentors to work on documentation for open source projects. The [first edition](https://developers.google.com/season-of-docs/docs/2019/participants) supported over 40 projects, including some other cool Apache Software Foundation (ASF) members like Apache Airflow and Apache Cassandra.
+
+# Why Apply?
+
+As one of the most active projects in the ASF, Flink is experiencing a boom in contributions and some major changes to its codebase. And, while the project has also seen a significant increase in activity when it comes to writing, reviewing and translating documentation, it’s hard to keep up with the pace.
+
+
+
+
+
+
+
+
+
+Since last year, the community has been working on [FLIP-42](https://cwiki.apache.org/confluence/display/FLINK/FLIP-42%3A+Rework+Flink+Documentation) to improve the documentation experience and bring a more accessible information architecture to Flink. After [some discussion](https://www.mail-archive.com/dev@flink.apache.org/msg36987.html), we agreed that GSoD would be a valuable opportunity to double down on this effort and collaborate with someone who is passionate about technical writing...and Flink!
+
+# How can you contribute?
+
+If working shoulder to shoulder with the Flink community on documentation sounds exciting, we’d love to hear from you! You can read more about our idea for this year’s project below and, depending on whether it is accepted, [apply](https://developers.google.com/season-of-docs/docs/tech-writer-guide) as a technical writer. If you have any questions or just want to know more about the project idea, ping us at [dev@flink.apache.org](https://flink.apache.org/community.html#mailing-lists)!
+
+
+ Please
subscribe to the Apache Flink mailing list before reaching out.
+ If you are not subscribed then responses to your message will not go through.
+ You can always
unsubscribe at any time.
+
+
+## Project: Improve the Table API & SQL Documentation
+
+[Apache Flink](https://flink.apache.org/) is a stateful stream processor supporting a broad set of use cases and featuring APIs at different levels of abstraction that allow users to trade off expressiveness and usability, as well as work with their language of choice (Java/Scala, SQL or Python). The Table API & SQL are Flink’s high-level relational abstractions and focus on data analytics use cases. A core principle is that either API can be used to process static (batch) and continuous (streaming) data with the same syntax and yielding the same results.
+
+As the Flink community works on extending the scope of the Table API & SQL, a lot of new features are being added and some underlying structures are also being refactored. At the same time, the documentation for these APIs is growing onto a somewhat unruly structure and has potential for improvement in some areas.
+
+The project has two main workstreams: restructuring and extending the Table API & SQL documentation. These can be worked on by one person as a bigger effort or assigned to different technical writers.
+
+**1) Restructure the Table API & SQL Documentation**
+
+Reworking the current documentation structure would allow to:
+
+* Lower the entry barrier to Flink for non-programmatic (i.e. SQL) users.
+* Make the available features more easily discoverable.
+* Improve the flow and logical correlation of topics.
+
+[FLIP-60](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=127405685) contains a detailed proposal on how to reorganize the existing documentation, which can be used as a starting point.
+
+
+**2) Extend the Table API & SQL Documentation**
+
+Some areas of the documentation have insufficient detail or are not [accessible](https://flink.apache.org/contributing/docs-style.html#general-guiding-principles) for new Flink users. Examples of topics and sections that require attention are: planners, built-in functions, connectors, overview and concepts sections. There is a lot of work to be done and the technical writer could choose what areas to focus on — these improvements could then be added to the documentation rework umbrella issue ([FLINK-12639](https://issues.apache.org/jira/browse/FLINK-12639)).
+
+### Project Mentors
+
+* [Aljoscha Krettek](https://twitter.com/aljoscha) (Apache Flink and Apache Beam PMC Member)
+* [Seth Wiesman](https://twitter.com/sjwiesman) (Apache Flink Committer)
+
+### Related Resources
+
+* FLIP-60: [https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=127405685](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=127405685)
+
+* Table API & SQL Documentation: [{{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/table/]({{< param DocsBaseUrl >}}flink-docs-release-1.10/dev/table/)
+
+* How to Contribute Documentation: [https://flink.apache.org/contributing/contribute-documentation.html](https://flink.apache.org/contributing/contribute-documentation.html)
+
+* Documentation Style Guide: [https://flink.apache.org/contributing/docs-style.html](https://flink.apache.org/contributing/docs-style.html)
+
+We look forward to receiving feedback on this GSoD application and also to continue improving the documentation experience for Flink users. Join us!
diff --git a/docs/content.tr/posts/2020-05-06-community-update.md b/docs/content.tr/posts/2020-05-06-community-update.md
new file mode 100644
index 0000000000..5d1a52da35
--- /dev/null
+++ b/docs/content.tr/posts/2020-05-06-community-update.md
@@ -0,0 +1,205 @@
+---
+authors:
+- morsapaes: null
+ name: Marta Paes
+ twitter: morsapaes
+date: "2020-05-06T08:00:00Z"
+excerpt: Can you smell it? It’s release month! This time around, we’re warming up
+ for Flink 1.11 and peeping back to the past month in the Flink community — with
+ the release of Stateful Functions 2.0, a new self-paced Flink training and some
+ efforts to improve the Flink documentation experience.
+title: Flink Community Update - May'20
+aliases:
+- /news/2020/05/07/community-update.html
+---
+
+Can you smell it? It’s release month! It took a while, but now that we’re [all caught up with the past](https://flink.apache.org/news/2020/04/01/community-update.html), the Community Update is here to stay. This time around, we’re warming up for Flink 1.11 and peeping back to the month of April in the Flink community — with the release of Stateful Functions 2.0, a new self-paced Flink training and some efforts to improve the Flink documentation experience.
+
+Last month also marked the debut of Flink Forward Virtual Conference 2020: what did you think? If you missed it altogether or just want to recap some of the sessions, the [videos](https://www.youtube.com/playlist?list=PLDX4T_cnKjD0ngnBSU-bYGfgVv17MiwA7) and [slides](https://www.slideshare.net/FlinkForward) are now available!
+
+# The Past Month in Flink
+
+## Flink Stateful Functions 2.0 is out!
+
+In the beginning of April, the Flink community announced the [release of Stateful Functions 2.0](https://flink.apache.org/news/2020/04/07/release-statefun-2.0.0.html) — the first as part of the Apache Flink project. From this release, you can use Flink as the base of a (stateful) serverless platform with out-of-the-box consistent and scalable state, and efficient messaging between functions. You can even run your stateful functions on platforms like AWS Lambda, as Gordon ([@tzulitai](https://twitter.com/tzulitai)) demonstrated in [his Flink Forward talk](https://www.youtube.com/watch?v=tuSylBadNSo&list=PLDX4T_cnKjD0ngnBSU-bYGfgVv17MiwA7&index=27&t=8s).
+
+
+
+
+
+
+
+
+
+
+
+
+
+It’s been encouraging to see so many questions about Stateful Functions popping up in the [mailing list](https://lists.apache.org/list.html?user@flink.apache.org:lte=3M:statefun) and Stack Overflow! If you’d like to get involved, we’re always [looking for new contributors](https://github.com/apache/flink-statefun#contributing) — especially around SDKs for other languages like Go, Javascript and Rust.
+
+
+
+## Warming up for Flink 1.11
+
+The final preparations for the release of Flink 1.11 are well underway, with the feature freeze scheduled for May 15th, and there’s a lot of new features and improvements to look out for:
+
+* On the **usability** side, you can expect a big focus on smoothing data ingestion with contributions like support for Change Data Capture (CDC) in the Table API/SQL ([FLIP-105](https://cwiki.apache.org/confluence/display/FLINK/FLIP-105%3A+Support+to+Interpret+and+Emit+Changelog+in+Flink+SQL)), easy streaming data ingestion into Apache Hive ([FLIP-115](https://cwiki.apache.org/confluence/display/FLINK/FLIP-115%3A+Filesystem+connector+in+Table)) or support for Pandas DataFrames in PyFlink ([FLIP-120](https://cwiki.apache.org/confluence/display/FLINK/FLIP-120%3A+Support+conversion+between+PyFlink+Table+and+Pandas+DataFrame)). A great deal of effort has also gone into maturing PyFlink, with the introduction of user defined metrics in Python UDFs ([FLIP-112](https://cwiki.apache.org/confluence/display/FLINK/FLIP-112%3A+Support+User-Defined+Metrics+in++Python+UDF)) and the extension of Python UDF support beyond the Python Table API ([FLIP-106](https://cwiki.apache.org/confluence/display/FLINK/FLIP-106%3A+Support+Python+UDF+in+SQL+Function+DDL),[FLIP-114](https://cwiki.apache.org/confluence/display/FLINK/FLIP-114%3A+Support+Python+UDF+in+SQL+Client)).
+
+* On the **operational** side, the much anticipated new Source API ([FLIP-27](https://cwiki.apache.org/confluence/display/FLINK/FLIP-27%3A+Refactor+Source+Interface)) will unify batch and streaming sources, and improve out-of-the-box event-time behavior; while unaligned checkpoints ([FLIP-76](https://cwiki.apache.org/confluence/display/FLINK/FLIP-76%3A+Unaligned+Checkpoints)) and changes to network memory management will allow to speed up checkpointing under backpressure — this is part of a bigger effort to rethink fault tolerance that will introduce many other non-trivial changes to Flink. You can learn more about it in [this](https://youtu.be/ssEmeLcL5Uk) recent Flink Forward talk!
+
+Throw into the mix improvements around type systems, the WebUI, metrics reporting, supported formats and...we can't wait! To get an overview of the ongoing developments, have a look at [this thread](http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/ANNOUNCE-Development-progress-of-Apache-Flink-1-11-tp40718.html). We encourage the community to get involved in testing once an RC (Release Candidate) is out. Keep an eye on the [@dev mailing list](https://flink.apache.org/community.html#mailing-lists) for updates!
+
+
+
+## Flink Minor Releases
+
+### Flink 1.9.3
+
+The community released Flink 1.9.3, covering some outstanding bugs from Flink 1.9! You can find more in the [announcement blogpost]((https://flink.apache.org/news/2020/04/24/release-1.9.3.html)).
+
+### Flink 1.10.1
+
+Also in the pipeline is the release of Flink 1.10.1, already in the [RC voting](http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Release-1-10-1-release-candidate-2-td41019.html) phase. So, you can expect Flink 1.10.1 to be released soon!
+
+
+
+## New Committers and PMC Members
+
+The Apache Flink community has welcomed **3 PMC Members** and **2 new Committers** since the last update. Congratulations!
+
+### New PMC Members
+
+
+
+
+
+
+
+
Zhijiang Wang
+
+
+
+
+### New Committers
+
+
+
+
+
+# The Bigger Picture
+
+## A new self-paced Apache Flink training
+
+
+
+
+
+This week, the Flink website received the invaluable contribution of a self-paced training course curated by David ([@alpinegizmo](https://twitter.com/alpinegizmo)) — or, what used to be the entire training materials under [training.ververica.com](training.ververica.com). The new materials guide you through the very basics of Flink and the DataStream API, and round off every concepts section with hands-on exercises to help you better assimilate what you learned.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Whether you're new to Flink or just looking to strengthen your foundations, this training is the most comprehensive way to get started and is now completely open source: [https://flink.apache.org/training.html](https://flink.apache.org/training.html). For now, the materials are only available in English, but the community intends to also provide a Chinese translation in the future.
+
+
+
+## Google Season of Docs 2020
+
+Google Season of Docs (GSOD) is a great initiative organized by [Google Open Source](https://opensource.google.com/) to pair technical writers with mentors to work on documentation for open source projects. Last year, the Flink community submitted [an application](https://flink.apache.org/news/2019/04/17/sod.html) that unfortunately didn’t make the cut — but we are trying again! This time, with a project idea to improve the Table API & SQL documentation:
+
+**1) Restructure the Table API & SQL Documentation**
+
+Reworking the current documentation structure would allow to:
+
+* Lower the entry barrier to Flink for non-programmatic (i.e. SQL) users.
+
+* Make the available features more easily discoverable.
+
+* Improve the flow and logical correlation of topics.
+
+[FLIP-60](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=127405685) contains a detailed proposal on how to reorganize the existing documentation, which can be used as a starting point.
+
+**2) Extend the Table API & SQL Documentation**
+
+Some areas of the documentation have insufficient detail or are not [accessible](https://flink.apache.org/contributing/docs-style.html#general-guiding-principles) for new Flink users. Examples of topics and sections that require attention are: planners, built-in functions, connectors, overview and concepts sections. There is a lot of work to be done and the technical writer could choose what areas to focus on — these improvements could then be added to the documentation rework umbrella issue ([FLINK-12639](https://issues.apache.org/jira/browse/FLINK-12639)).
+
+If you’re interested in learning more about this project idea or want to get involved in GSoD as a technical writer, check out the [announcement blogpost](https://flink.apache.org/news/2020/05/04/season-of-docs.html).
+
+
+
+# ...and something to read!
+
+Events across the globe have pretty much come to a halt, so we’ll leave you with some interesting resources to read and explore instead. In addition to this written content, you can also recap the sessions from the [Flink Forward Virtual Conference](https://www.youtube.com/playlist?list=PLDX4T_cnKjD0ngnBSU-bYGfgVv17MiwA7)!
+
+
+
+
+ Type
+ Links
+
+
+
+
+ Blogposts
+
+
+
+
+
+ Tutorials
+
+
+
+
+ Flink Packages
+
+
+
+
+
+
+If you’d like to keep a closer eye on what’s happening in the community, subscribe to the Flink [@community mailing list](https://flink.apache.org/community.html#mailing-lists) to get fine-grained weekly updates, upcoming event announcements and more.
\ No newline at end of file
diff --git a/docs/content.tr/posts/2020-05-12-release-1.10.1.md b/docs/content.tr/posts/2020-05-12-release-1.10.1.md
new file mode 100644
index 0000000000..4d2be3d899
--- /dev/null
+++ b/docs/content.tr/posts/2020-05-12-release-1.10.1.md
@@ -0,0 +1,392 @@
+---
+authors:
+- liyu: null
+ name: Yu Li
+ twitter: LiyuApache
+date: "2020-05-12T12:00:00Z"
+title: Apache Flink 1.10.1 Released
+aliases:
+- /news/2020/05/12/release-1.10.1.html
+---
+
+The Apache Flink community released the first bugfix version of the Apache Flink 1.10 series.
+
+This release includes 158 fixes and minor improvements for Flink 1.10.0. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.10.1.
+
+
+ Note
+FLINK-16684 changed the builders of the StreamingFileSink to make them compilable in Scala. This change is source compatible but binary incompatible. If using the StreamingFileSink, please recompile your user code against 1.10.1 before upgrading.
+
+
+
+ Note
+FLINK-16683 Flink no longer supports starting clusters with .bat scripts. Users should instead use environments like WSL or Cygwin and work with the .sh scripts.
+
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.10.1
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.10.1
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.10.1
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-14126 ] - Elasticsearch Xpack Machine Learning doesn't support ARM
+
+[FLINK-15143 ] - Create document for FLIP-49 TM memory model and configuration guide
+
+[FLINK-15561 ] - Unify Kerberos credentials checking
+
+[FLINK-15790 ] - Make FlinkKubeClient and its implementations asynchronous
+
+[FLINK-15817 ] - Kubernetes Resource leak while deployment exception happens
+
+[FLINK-16049 ] - Remove outdated "Best Practices" section from Application Development Section
+
+[FLINK-16131 ] - Translate "Amazon S3" page of "File Systems" into Chinese
+
+[FLINK-16389 ] - Bump Kafka 0.10 to 0.10.2.2
+
+
+
+ Bug
+
+
+[FLINK-2336 ] - ArrayIndexOufOBoundsException in TypeExtractor when mapping
+
+[FLINK-10918 ] - incremental Keyed state with RocksDB throws cannot create directory error in windows
+
+[FLINK-11193 ] - Rocksdb timer service factory configuration option is not settable per job
+
+[FLINK-13483 ] - PrestoS3FileSystemITCase.testDirectoryListing fails on Travis
+
+[FLINK-14038 ] - ExecutionGraph deploy failed due to akka timeout
+
+[FLINK-14311 ] - Streaming File Sink end-to-end test failed on Travis
+
+[FLINK-14316 ] - Stuck in "Job leader ... lost leadership" error
+
+[FLINK-15417 ] - Remove the docker volume or mount when starting Mesos e2e cluster
+
+[FLINK-15669 ] - SQL client can't cancel flink job
+
+[FLINK-15772 ] - Shaded Hadoop S3A with credentials provider end-to-end test fails on travis
+
+[FLINK-15811 ] - StreamSourceOperatorWatermarksTest.testNoMaxWatermarkOnAsyncCancel fails on Travis
+
+[FLINK-15812 ] - HistoryServer archiving is done in Dispatcher main thread
+
+[FLINK-15838 ] - Dangling CountDownLatch.await(timeout)
+
+[FLINK-15852 ] - Job is submitted to the wrong session cluster
+
+[FLINK-15904 ] - Make Kafka Consumer work with activated "disableGenericTypes()"
+
+[FLINK-15936 ] - TaskExecutorTest#testSlotAcceptance deadlocks
+
+[FLINK-15953 ] - Job Status is hard to read for some Statuses
+
+[FLINK-16013 ] - List and map config options could not be parsed correctly
+
+[FLINK-16014 ] - S3 plugin ClassNotFoundException SAXParser
+
+[FLINK-16025 ] - Service could expose blob server port mismatched with JM Container
+
+[FLINK-16026 ] - Travis failed due to python setup
+
+[FLINK-16047 ] - Blink planner produces wrong aggregate results with state clean up
+
+[FLINK-16067 ] - Flink's CalciteParser swallows error position information
+
+[FLINK-16068 ] - table with keyword-escaped columns and computed_column_expression columns
+
+[FLINK-16070 ] - Blink planner can not extract correct unique key for UpsertStreamTableSink
+
+[FLINK-16108 ] - StreamSQLExample is failed if running in blink planner
+
+[FLINK-16111 ] - Kubernetes deployment does not respect "taskmanager.cpu.cores".
+
+[FLINK-16113 ] - ExpressionReducer shouldn't escape the reduced string value
+
+[FLINK-16115 ] - Aliyun oss filesystem could not work with plugin mechanism
+
+[FLINK-16139 ] - Co-location constraints are not reset on task recovery in DefaultScheduler
+
+[FLINK-16161 ] - Statistics zero should be unknown in HiveCatalog
+
+[FLINK-16170 ] - SearchTemplateRequest ClassNotFoundException when use flink-sql-connector-elasticsearch7
+
+[FLINK-16220 ] - JsonRowSerializationSchema throws cast exception : NullNode cannot be cast to ArrayNode
+
+[FLINK-16231 ] - Hive connector is missing jdk.tools exclusion against Hive 2.x.x
+
+[FLINK-16234 ] - Fix unstable cases in StreamingJobGraphGeneratorTest
+
+[FLINK-16241 ] - Remove the license and notice file in flink-ml-lib module on release-1.10 branch
+
+[FLINK-16242 ] - BinaryGeneric serialization error cause checkpoint failure
+
+[FLINK-16262 ] - Class loader problem with FlinkKafkaProducer.Semantic.EXACTLY_ONCE and usrlib directory
+
+[FLINK-16269 ] - Generic type can not be matched when convert table to stream.
+
+[FLINK-16281 ] - parameter 'maxRetryTimes' can not work in JDBCUpsertTableSink
+
+[FLINK-16301 ] - Annoying "Cannot find FunctionDefinition" messages with SQL for f_proctime or =
+
+[FLINK-16308 ] - SQL connector download links are broken
+
+[FLINK-16313 ] - flink-state-processor-api: surefire execution unstable on Azure
+
+[FLINK-16331 ] - Remove source licenses for old WebUI
+
+[FLINK-16345 ] - Computed column can not refer time attribute column
+
+[FLINK-16360 ] - connector on hive 2.0.1 don't support type conversion from STRING to VARCHAR
+
+[FLINK-16371 ] - HadoopCompressionBulkWriter fails with 'java.io.NotSerializableException'
+
+[FLINK-16373 ] - EmbeddedLeaderService: IllegalStateException: The RPC connection is already closed
+
+[FLINK-16413 ] - Reduce hive source parallelism when limit push down
+
+[FLINK-16414 ] - create udaf/udtf function using sql casuing ValidationException: SQL validation failed. null
+
+[FLINK-16433 ] - TableEnvironmentImpl doesn't clear buffered operations when it fails to translate the operation
+
+[FLINK-16435 ] - Replace since decorator with versionadd to mark the version an API was introduced
+
+[FLINK-16467 ] - MemorySizeTest#testToHumanReadableString() is not portable
+
+[FLINK-16526 ] - Fix exception when computed column expression references a keyword column name
+
+[FLINK-16541 ] - Document of table.exec.shuffle-mode is incorrect
+
+[FLINK-16550 ] - HadoopS3* tests fail with NullPointerException exceptions
+
+[FLINK-16560 ] - Forward Configuration in PackagedProgramUtils#getPipelineFromProgram
+
+[FLINK-16567 ] - Get the API error of the StreamQueryConfig on Page "Query Configuration"
+
+[FLINK-16573 ] - Kinesis consumer does not properly shutdown RecordFetcher threads
+
+[FLINK-16576 ] - State inconsistency on restore with memory state backends
+
+[FLINK-16626 ] - Prevent REST handler from being closed more than once
+
+[FLINK-16632 ] - SqlDateTimeUtils#toSqlTimestamp(String, String) may yield incorrect result
+
+[FLINK-16635 ] - Incompatible okio dependency in flink-metrics-influxdb module
+
+[FLINK-16646 ] - flink read orc file throw a NullPointerException
+
+[FLINK-16647 ] - Miss file extension when inserting to hive table with compression
+
+[FLINK-16652 ] - BytesColumnVector should init buffer in Hive 3.x
+
+[FLINK-16662 ] - Blink Planner failed to generate JobGraph for POJO DataStream converting to Table (Cannot determine simple type name)
+
+[FLINK-16664 ] - Unable to set DataStreamSource parallelism to default (-1)
+
+[FLINK-16675 ] - TableEnvironmentITCase. testClearOperation fails on travis nightly build
+
+[FLINK-16684 ] - StreamingFileSink builder does not work with Scala
+
+[FLINK-16696 ] - Savepoint trigger documentation is insufficient
+
+[FLINK-16703 ] - AkkaRpcActor state machine does not record transition to terminating state.
+
+[FLINK-16705 ] - LocalExecutor tears down MiniCluster before client can retrieve JobResult
+
+[FLINK-16718 ] - KvStateServerHandlerTest leaks Netty ByteBufs
+
+[FLINK-16727 ] - Fix cast exception when having time point literal as parameters
+
+[FLINK-16732 ] - Failed to call Hive UDF with constant return value
+
+[FLINK-16740 ] - OrcSplitReaderUtil::logicalTypeToOrcType fails to create decimal type with precision < 10
+
+[FLINK-16759 ] - HiveModuleTest failed to compile on release-1.10
+
+[FLINK-16767 ] - Failed to read Hive table with RegexSerDe
+
+[FLINK-16771 ] - NPE when filtering by decimal column
+
+[FLINK-16821 ] - Run Kubernetes test failed with invalid named "minikube"
+
+[FLINK-16822 ] - The config set by SET command does not work
+
+[FLINK-16825 ] - PrometheusReporterEndToEndITCase should rely on path returned by DownloadCache
+
+[FLINK-16836 ] - Losing leadership does not clear rpc connection in JobManagerLeaderListener
+
+[FLINK-16860 ] - Failed to push filter into OrcTableSource when upgrading to 1.9.2
+
+[FLINK-16888 ] - Re-add jquery license file under "/licenses"
+
+[FLINK-16901 ] - Flink Kinesis connector NOTICE should have contents of AWS KPL's THIRD_PARTY_NOTICES file manually merged in
+
+[FLINK-16913 ] - ReadableConfigToConfigurationAdapter#getEnum throws UnsupportedOperationException
+
+[FLINK-16916 ] - The logic of NullableSerializer#copy is wrong
+
+[FLINK-16944 ] - Compile error in. DumpCompiledPlanTest and PreviewPlanDumpTest
+
+[FLINK-16980 ] - Python UDF doesn't work with protobuf 3.6.1
+
+[FLINK-16981 ] - flink-runtime tests are crashing the JVM on Java11 because of PowerMock
+
+[FLINK-17062 ] - Fix the conversion from Java row type to Python row type
+
+[FLINK-17066 ] - Update pyarrow version bounds less than 0.14.0
+
+[FLINK-17093 ] - Python UDF doesn't work when the input column is from composite field
+
+[FLINK-17107 ] - CheckpointCoordinatorConfiguration#isExactlyOnce() is inconsistent with StreamConfig#getCheckpointMode()
+
+[FLINK-17114 ] - When the pyflink job runs in local mode and the command "python" points to Python 2.7, the startup of the Python UDF worker will fail.
+
+[FLINK-17124 ] - The PyFlink Job runs into infinite loop if the Python UDF imports job code
+
+[FLINK-17152 ] - FunctionDefinitionUtil generate wrong resultType and acc type of AggregateFunctionDefinition
+
+[FLINK-17308 ] - ExecutionGraphCache cachedExecutionGraphs not cleanup cause OOM Bug
+
+[FLINK-17313 ] - Validation error when insert decimal/varchar with precision into sink using TypeInformation of row
+
+[FLINK-17334 ] - Flink does not support HIVE UDFs with primitive return types
+
+[FLINK-17338 ] - LocalExecutorITCase.testBatchQueryCancel test timeout
+
+[FLINK-17359 ] - Entropy key is not resolved if flink-s3-fs-hadoop is added as a plugin
+
+[FLINK-17403 ] - Fix invalid classpath in BashJavaUtilsITCase
+
+[FLINK-17471 ] - Move LICENSE and NOTICE files to root directory of python distribution
+
+[FLINK-17483 ] - Update flink-sql-connector-elasticsearch7 NOTICE file to correctly reflect bundled dependencies
+
+[FLINK-17496 ] - Performance regression with amazon-kinesis-producer 0.13.1 in Flink 1.10.x
+
+[FLINK-17499 ] - LazyTimerService used to register timers via State Processing API incorrectly mixes event time timers with processing time timers
+
+[FLINK-17514 ] - TaskCancelerWatchdog does not kill TaskManager
+
+
+
+ New Feature
+
+
+
+ Improvement
+
+
+[FLINK-9656 ] - Environment java opts for flink run
+
+[FLINK-15094 ] - Warning about using private constructor of java.nio.DirectByteBuffer in Java 11
+
+[FLINK-15584 ] - Give nested data type of ROWs in ValidationException
+
+[FLINK-15616 ] - Move boot error messages from python-udf-boot.log to taskmanager's log file
+
+[FLINK-15989 ] - Rewrap OutOfMemoryError in allocateUnpooledOffHeap with better message
+
+[FLINK-16018 ] - Improve error reporting when submitting batch job (instead of AskTimeoutException)
+
+[FLINK-16125 ] - Make zookeeper.connect optional for Kafka connectors
+
+[FLINK-16167 ] - Update documentation about python shell execution
+
+[FLINK-16191 ] - Improve error message on Windows when RocksDB Paths are too long
+
+[FLINK-16280 ] - Fix sample code errors in the documentation about elasticsearch connector
+
+[FLINK-16288 ] - Setting the TTL for discarding task pods on Kubernetes.
+
+[FLINK-16293 ] - Document using plugins in Kubernetes
+
+[FLINK-16343 ] - Improve exception message when reading an unbounded source in batch mode
+
+[FLINK-16406 ] - Increase default value for JVM Metaspace to minimise its OutOfMemoryError
+
+[FLINK-16538 ] - Restructure Python Table API documentation
+
+[FLINK-16604 ] - Column key in JM configuration is too narrow
+
+[FLINK-16683 ] - Remove scripts for starting Flink on Windows
+
+[FLINK-16697 ] - Disable JMX rebinding
+
+[FLINK-16763 ] - Should not use BatchTableEnvironment for Python UDF in the document of flink-1.10
+
+[FLINK-16772 ] - Bump derby to 10.12.1.1+ or exclude it
+
+[FLINK-16790 ] - enables the interpretation of backslash escapes
+
+[FLINK-16862 ] - Remove example url in quickstarts
+
+[FLINK-16874 ] - Respect the dynamic options when calculating memory options in taskmanager.sh
+
+[FLINK-16942 ] - ES 5 sink should allow users to select netty transport client
+
+[FLINK-17065 ] - Add documentation about the Python versions supported for PyFlink
+
+[FLINK-17125 ] - Add a Usage Notes Page to Answer Common Questions Encountered by PyFlink Users
+
+[FLINK-17254 ] - Improve the PyFlink documentation and examples to use SQL DDL for source/sink definition
+
+[FLINK-17276 ] - Add checkstyle to training exercises
+
+[FLINK-17277 ] - Apply IntelliJ recommendations to training exercises
+
+[FLINK-17278 ] - Add Travis to the training exercises
+
+[FLINK-17279 ] - Use gradle build scans for training exercises
+
+[FLINK-17316 ] - Have HourlyTips solutions use TumblingEventTimeWindows.of
+
+
+
+ Task
+
+
+[FLINK-15741 ] - Fix TTL docs after enabling RocksDB compaction filter by default (needs Chinese translation)
+
+[FLINK-15933 ] - update content of how generic table schema is stored in hive via HiveCatalog
+
+[FLINK-15991 ] - Create Chinese documentation for FLIP-49 TM memory model
+
+[FLINK-16004 ] - Exclude flink-rocksdb-state-memory-control-test jars from the dist
+
+[FLINK-16454 ] - Update the copyright year in NOTICE files
+
+[FLINK-16530 ] - Add documentation about "GROUPING SETS" and "CUBE" support in streaming mode
+
+[FLINK-16592 ] - The doc of Streaming File Sink has a mistake of grammar
+
+
+
diff --git a/docs/content.tr/posts/2020-06-09-release-statefun-2.1.0.md b/docs/content.tr/posts/2020-06-09-release-statefun-2.1.0.md
new file mode 100644
index 0000000000..56845f3bc1
--- /dev/null
+++ b/docs/content.tr/posts/2020-06-09-release-statefun-2.1.0.md
@@ -0,0 +1,80 @@
+---
+authors:
+- morsapaes: null
+ name: Marta Paes
+ twitter: morsapaes
+date: "2020-06-09T08:00:00Z"
+title: Stateful Functions 2.1.0 Release Announcement
+aliases:
+- /news/2020/06/09/release-statefun-2.1.0.html
+---
+
+The Apache Flink community is happy to announce the release of Stateful Functions (StateFun) 2.1.0! This release introduces new features around state expiration and performance improvements for co-located deployments, as well as other important changes that improve the stability and testability of the project. As the community around StateFun grows, the release cycle will follow this pattern of smaller and more frequent releases to incorporate user feedback and allow for faster iteration.
+
+The binary distribution and source artifacts are now available on the updated [Downloads](https://flink.apache.org/downloads.html) page of the Flink website, and the most recent Python SDK distribution is available on [PyPI](https://pypi.org/project/apache-flink-statefun/). For more details, check the complete [release changelog](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12347861) and the [updated documentation]({{< param DocsBaseUrl >}}flink-statefun-docs-release-2.1/). We encourage you to download the release and share your feedback with the community through the [Flink mailing lists](https://flink.apache.org/community.html#mailing-lists) or [JIRA](https://issues.apache.org/jira/browse/FLINK-18016?jql=project%20%3D%20FLINK%20AND%20component%20%3D%20%22Stateful%20Functions%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC)!
+
+## New Features and Improvements
+
+### Support for State Time-To-Live (TTL)
+
+Being able to define state expiration and a state cleanup strategy is a useful feature for stateful applications — for example, to keep state size from growing indefinitely or to work with sensitive data. In previous StateFun versions, users could implement this behavior manually using [delayed messages]({{< param DocsBaseUrl >}}flink-statefun-docs-release-2.0/sdk/java.html#sending-delayed-messages) as state expiration callbacks. For StateFun 2.1, the community has worked on enabling users to configure any persisted state to expire and be purged after a given duration (i.e. the state time-to-live) ([FLINK-17644](https://issues.apache.org/jira/browse/FLINK-17644), [FLINK-17875](https://issues.apache.org/jira/browse/FLINK-17875)).
+
+Persisted state can be configured to expire after the last _write_ operation (``AFTER_WRITE``) or after the last _read or write_ operation (``AFTER_READ_AND_WRITE``). For the [Java SDK]({{< param DocsBaseUrl >}}flink-statefun-docs-release-2.1/sdk/java.html#state-expiration), users can configure State TTL in the definition of their persisted fields:
+
+```java
+@Persisted
+PersistedValue table = PersistedValue.of(
+ "my-value",
+ Integer.class,
+ Expiration.expireAfterWriting(Duration.ofHours(1)));
+```
+
+For [remote functions]({{< param DocsBaseUrl >}}flink-statefun-docs-release-2.1/concepts/distributed_architecture.html#remote-functions) using e.g. the Python SDK, users can configure State TTL in their ``module.yaml``:
+
+```
+functions:
+ - function:
+ states:
+ - name: xxxx
+ expireAfter: 5min # optional key
+```
+
+
+
Note:
+ The state expiration mode for remote functions is currently restricted to AFTER_READ_AND_WRITE, and the actual TTL being set is the longest duration across all registered state, not for each individual state entry. This is planned to be improved in upcoming releases (
FLINK-17954 ).
+
+
+### Improved Performance with UNIX Domain Sockets (UDS)
+
+Stateful functions can be [deployed in multiple ways]({{< param DocsBaseUrl >}}flink-statefun-docs-release-2.1/concepts/distributed_architecture.html#deployment-styles-for-functions), even within the same application. For deployments where functions are [co-located]({{< param DocsBaseUrl >}}flink-statefun-docs-release-2.1/concepts/distributed_architecture.html#co-located-functions) with the Flink StateFun workers, it’s common to use Kubernetes to deploy pods consisting of a Flink StateFun container and the function sidecar container, communicating via the pod-local network. To improve the performance of such deployments, StateFun 2.1 allows using [Unix Domain Sockets](https://troydhanson.github.io/network/Unix_domain_sockets.html) (UDS) to communicate between containers in the same pod (i.e. the same machine) ([FLINK-17611](https://issues.apache.org/jira/browse/FLINK-17611)), which drastically reduces the overhead of going through the network stack.
+
+Users can [enable transport via UDS]({{< param DocsBaseUrl >}}flink-statefun-docs-master/sdk/modules.html#defining-functions) in a remote module by specifying the following in their ``module.yaml``:
+
+```
+functions:
+ - function:
+ spec:
+ - endpoint: http(s)+unix:///
+```
+
+## Important Changes
+
+* [[FLINK-17712](https://issues.apache.org/jira/browse/FLINK-17712)] The Flink version in StateFun 2.1 has been upgraded to 1.10.1, the most recent patch version.
+
+* [[FLINK-17533](https://issues.apache.org/jira/browse/FLINK-17533)] StateFun 2.1 now supports concurrent checkpoints, which means applications will no longer fail on savepoints that are triggered concurrently to a checkpoint.
+
+* [[FLINK-16928](https://issues.apache.org/jira/browse/FLINK-16928)] StateFun 2.0 was using the Flink legacy scheduler due to a [bug in Flink 1.10](https://issues.apache.org/jira/browse/FLINK-16927). In 2.1, this change is reverted to using the new Flink scheduler again.
+
+* [[FLINK-17516](https://issues.apache.org/jira/browse/FLINK-17516)] The coverage for end-to-end StateFun tests has been extended to also include exactly-once semantics verification (with failure recovery).
+
+## Release Notes
+
+Please review the [release notes](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12347861) for a detailed list of changes and new features if you plan to upgrade your setup to Stateful Functions 2.1.
+
+## List of Contributors
+
+The Apache Flink community would like to thank all contributors that have made this release possible:
+
+abc863377, Authuir, Chesnay Schepler, Congxian Qiu, David Anderson, Dian Fu, Francesco Guardiani, Igal Shilman, Marta Paes Moreira, Patrick Wiener, Rafi Aroch, Seth Wiesman, Stephan Ewen, Tzu-Li (Gordon) Tai
+
+If you’d like to get involved, we’re always [looking for new contributors](https://github.com/apache/flink-statefun#contributing) — especially around SDKs for other languages like Go, Rust or Javascript.
\ No newline at end of file
diff --git a/docs/content.tr/posts/2020-06-10-community-update.md b/docs/content.tr/posts/2020-06-10-community-update.md
new file mode 100644
index 0000000000..d0d4da1ee5
--- /dev/null
+++ b/docs/content.tr/posts/2020-06-10-community-update.md
@@ -0,0 +1,107 @@
+---
+authors:
+- morsapaes: null
+ name: Marta Paes
+ twitter: morsapaes
+date: "2020-06-10T08:00:00Z"
+excerpt: And suddenly it’s June. The previous month has been calm on the surface,
+ but quite hectic underneath — the final testing phase for Flink 1.11 is moving at
+ full speed, Stateful Functions 2.1 is out in the wild and Flink has made it into
+ Google Season of Docs 2020.
+title: Flink Community Update - June'20
+aliases:
+- /news/2020/06/11/community-update.html
+---
+
+And suddenly it’s June. The previous month has been calm on the surface, but quite hectic underneath — the final testing phase for Flink 1.11 is moving at full speed, Stateful Functions 2.1 is out in the wild and Flink has made it into Google Season of Docs 2020.
+
+To top it off, a piece of good news: [Flink Forward](https://www.flink-forward.org/global-2020) is back on October 19-22 as a free virtual event!
+
+# The Past Month in Flink
+
+## Flink Stateful Functions 2.1 Release
+
+It might seem like [Stateful Functions 2.0 was announced](https://flink.apache.org/news/2020/04/07/release-statefun-2.0.0.html) only a handful of weeks ago (and it was!), but the Flink community has just released Stateful Functions 2.1! This release introduces two new features: state expiration for any kind of persisted state and support for UNIX Domain Sockets (UDS) to improve the performance of inter-container communication in co-located deployments; as well as other important changes that improve the overall stability and testability of the project. You can read the [announcement blogpost](https://flink.apache.org/news/2020/06/09/release-statefun-2.1.0.html) for more details on the release!
+
+As the community around StateFun grows, the release cycle will follow this pattern of smaller and more frequent releases to incorporate user feedback and allow for faster iteration. If you’d like to get involved, we’re always [looking for new contributors](https://github.com/apache/flink-statefun#contributing) — especially around SDKs for other languages (e.g. Go, Rust, Javascript).
+
+
+
+## Testing is ON for Flink 1.11
+
+Things have been pretty quiet in the Flink community, as all efforts shifted to testing the newest features shipping with Flink 1.11. While we wait for a voting Release Candidate (RC) to be out, you can check the progress of testing in [this JIRA burndown board](https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=364&projectKey=FLINK) and learn more about some of the [upcoming features](https://flink.apache.org/news/2020/05/07/community-update.html#warming-up-for-flink-111) in these Flink Forward videos:
+
+* [Rethinking of fault tolerance in Flink: what lies ahead?](https://www.youtube.com/watch?v=ssEmeLcL5Uk)
+
+* [It’s finally here: Python on Flink & Flink on Zeppelin](https://www.youtube.com/watch?v=t7fAN3xNJ3Q)
+
+* [A deep dive into Flink SQL](https://www.youtube.com/watch?v=KDD8e4GE12w)
+
+* [Production-Ready Flink and Hive Integration - what story you can tell now?](https://www.youtube.com/watch?v=4ce1H9CRyEc)
+
+We encourage the wider community to also get involved in testing once the voting RC is out. Keep an eye on the [@dev mailing list](https://flink.apache.org/community.html#mailing-lists) for updates!
+
+
+
+## Flink Minor Releases
+
+### Flink 1.10.1
+
+The community released Flink 1.10.1, covering some outstanding bugs in Flink 1.10. You can find more in the [announcement blogpost](https://flink.apache.org/news/2020/05/12/release-1.10.1.html)!
+
+
+
+## New Committers and PMC Members
+
+The Apache Flink community has welcomed **2 new Committers** since the last update. Congratulations!
+
+### New Committers
+
+
+
+
+
+
Benchao Li
+
+
+
+
+
+
Xintong Song
+
+
+
+
+
+
+# The Bigger Picture
+
+## Flink Forward Global Virtual Conference 2020
+
+After a first successful [virtual conference](https://www.youtube.com/playlist?list=PLDX4T_cnKjD0ngnBSU-bYGfgVv17MiwA7) last April, Flink Forward will be hosting a second free virtual edition on October 19-22. This time around, the conference will feature two days of hands-on training and two full days of conference talks!
+
+Got a Flink story to share? Maybe your recent adventures with Stateful Functions? The [Call for Presentations is now open](https://www.flink-forward.org/global-2020/call-for-presentations) and accepting submissions from the community until **June 19th, 11:59 PM CEST**.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## Google Season of Docs 2020
+
+In the last update, we announced that Flink was applying to [Google Season of Docs (GSoD)](https://developers.google.com/season-of-docs) again this year. The good news: we’ve made it into the shortlist of accepted projects! This represents an invaluable opportunity for the Flink community to collaborate with technical writers to improve the Table API & SQL documentation. We’re honored to have seen a great number of people reach out over the last couple of weeks, and look forward to receiving applications from this week on!
+
+If you’re interested in learning more about our project idea or want to get involved in GSoD as a technical writer, check out the [announcement blogpost](https://flink.apache.org/news/2020/05/04/season-of-docs.html) and [submit your application](https://developers.google.com/season-of-docs/docs/tech-writer-application-hints). The deadline for GSoD applications is **July 9th, 18:00 UTC**.
+
+
+
+If you’d like to keep a closer eye on what’s happening in the community, subscribe to the Flink [@community mailing list](https://flink.apache.org/community.html#mailing-lists) to get fine-grained weekly updates, upcoming event announcements and more.
\ No newline at end of file
diff --git a/docs/content.tr/posts/2020-06-15-flink-on-zeppelin-part1.md b/docs/content.tr/posts/2020-06-15-flink-on-zeppelin-part1.md
new file mode 100644
index 0000000000..780f5c1903
--- /dev/null
+++ b/docs/content.tr/posts/2020-06-15-flink-on-zeppelin-part1.md
@@ -0,0 +1,88 @@
+---
+authors:
+- name: Jeff Zhang
+ twitter: zjffdu
+ zjffdu: null
+date: "2020-06-15T08:00:00Z"
+title: Flink on Zeppelin Notebooks for Interactive Data Analysis - Part 1
+aliases:
+- /news/2020/06/15/flink-on-zeppelin-part1.html
+---
+
+The latest release of [Apache Zeppelin](https://zeppelin.apache.org/) comes with a redesigned interpreter for Apache Flink (version Flink 1.10+ is only supported moving forward)
+that allows developers to use Flink directly on Zeppelin notebooks for interactive data analysis. I wrote 2 posts about how to use Flink in Zeppelin. This is part-1 where I explain how the Flink interpreter in Zeppelin works,
+and provide a tutorial for running Streaming ETL with Flink on Zeppelin.
+
+# The Flink Interpreter in Zeppelin 0.9
+
+The Flink interpreter can be accessed and configured from Zeppelin’s interpreter settings page.
+The interpreter has been refactored so that Flink users can now take advantage of Zeppelin to write Flink applications in three languages,
+namely Scala, Python (PyFlink) and SQL (for both batch & streaming executions).
+Zeppelin 0.9 now comes with the Flink interpreter group, consisting of the below five interpreters:
+
+* %flink - Provides a Scala environment
+* %flink.pyflink - Provides a python environment
+* %flink.ipyflink - Provides an ipython environment
+* %flink.ssql - Provides a stream sql environment
+* %flink.bsql - Provides a batch sql environment
+
+Not only has the interpreter been extended to support writing Flink applications in three languages, but it has also extended the available execution modes for Flink that now include:
+
+* Running Flink in Local Mode
+* Running Flink in Remote Mode
+* Running Flink in Yarn Mode
+
+
+You can find more information about how to get started with Zeppelin and all the execution modes for Flink applications in [Zeppelin notebooks](https://github.com/apache/zeppelin/tree/master/notebook/Flink%20Tutorial) in this post.
+
+
+# Flink on Zeppelin for Stream processing
+
+Performing stream processing jobs with Apache Flink on Zeppelin allows you to run most major streaming cases,
+such as streaming ETL and real time data analytics, with the use of Flink SQL and specific UDFs.
+Below we showcase how you can execute streaming ETL using Flink on Zeppelin:
+
+You can use Flink SQL to perform streaming ETL by following the steps below
+(for the full tutorial, please refer to the [Flink Tutorial/Streaming ETL tutorial](https://github.com/apache/zeppelin/blob/master/notebook/Flink%20Tutorial/4.%20Streaming%20ETL_2EYD56B9B.zpln) of the Zeppelin distribution):
+
+* Step 1. Create source table to represent the source data.
+
+
+
+
+
+* Step 2. Create a sink table to represent the processed data.
+
+
+
+
+
+* Step 3. After creating the source and sink table, we can insert them to our statement to trigger the stream processing job as the following:
+
+
+
+
+
+* Step 4. After initiating the streaming job, you can use another SQL statement to query the sink table to verify the results of your job. Here you can see the top 10 records which will be refreshed every 3 seconds.
+
+
+
+
+
+# Summary
+
+In this post, we explained how the redesigned Flink interpreter works in Zeppelin 0.9.0 and provided some examples for performing streaming ETL jobs with
+Flink and Zeppelin. In the next post, I will talk about how to do streaming data visualization via Flink on Zeppelin.
+Besides that, you can find an additional [tutorial for batch processing with Flink on Zeppelin](https://medium.com/@zjffdu/flink-on-zeppelin-part-2-batch-711731df5ad9) as well as using Flink on Zeppelin for
+more advance operations like resource isolation, job concurrency & parallelism, multiple Hadoop & Hive environments and more on our series of posts on Medium.
+And here's a list of [Flink on Zeppelin tutorial videos](https://www.youtube.com/watch?v=YxPo0Fosjjg&list=PL4oy12nnS7FFtg3KV1iS5vDb0pTz12VcX) for your reference.
+
+
+# References
+
+* [Apache Zeppelin official website](http://zeppelin.apache.org)
+* Flink on Zeppelin tutorials - [Part 1](https://medium.com/@zjffdu/flink-on-zeppelin-part-1-get-started-2591aaa6aa47)
+* Flink on Zeppelin tutorials - [Part 2](https://medium.com/@zjffdu/flink-on-zeppelin-part-2-batch-711731df5ad9)
+* Flink on Zeppelin tutorials - [Part 3](https://medium.com/@zjffdu/flink-on-zeppelin-part-3-streaming-5fca1e16754)
+* Flink on Zeppelin tutorials - [Part 4](https://medium.com/@zjffdu/flink-on-zeppelin-part-4-advanced-usage-998b74908cd9)
+* [Flink on Zeppelin tutorial videos](https://www.youtube.com/watch?v=YxPo0Fosjjg&list=PL4oy12nnS7FFtg3KV1iS5vDb0pTz12VcX)
diff --git a/docs/content.tr/posts/2020-06-23-flink-on-zeppelin-part2.md b/docs/content.tr/posts/2020-06-23-flink-on-zeppelin-part2.md
new file mode 100644
index 0000000000..b96b84226e
--- /dev/null
+++ b/docs/content.tr/posts/2020-06-23-flink-on-zeppelin-part2.md
@@ -0,0 +1,109 @@
+---
+authors:
+- name: Jeff Zhang
+ twitter: zjffdu
+ zjffdu: null
+date: "2020-06-23T08:00:00Z"
+title: Flink on Zeppelin Notebooks for Interactive Data Analysis - Part 2
+aliases:
+- /ecosystem/2020/06/23/flink-on-zeppelin-part2.html
+---
+
+In a previous post, we introduced the basics of Flink on Zeppelin and how to do Streaming ETL. In this second part of the "Flink on Zeppelin" series of posts, I will share how to
+perform streaming data visualization via Flink on Zeppelin and how to use Apache Flink UDFs in Zeppelin.
+
+# Streaming Data Visualization
+
+With [Zeppelin](https://zeppelin.apache.org/), you can build a real time streaming dashboard without writing any line of javascript/html/css code.
+
+Overall, Zeppelin supports 3 kinds of streaming data analytics:
+
+* Single Mode
+* Update Mode
+* Append Mode
+
+### Single Mode
+Single mode is used for cases when the result of a SQL statement is always one row, such as the following example.
+The output format is translated in HTML, and you can specify a paragraph local property template for the final output content template.
+And you can use `{i}` as placeholder for the {i}th column of the result.
+
+
+
+
+
+### Update Mode
+Update mode is suitable for the cases when the output format is more than one row,
+and will always be continuously updated. Here’s one example where we use ``GROUP BY``.
+
+
+
+
+
+### Append Mode
+Append mode is suitable for the cases when the output data is always appended.
+For instance, the example below uses a tumble window.
+
+
+
+
+
+# UDF
+
+SQL is a very powerful language, especially in expressing data flow. But most of the time, you need to handle complicated business logic that cannot be expressed by SQL.
+In these cases UDFs (user-defined functions) come particularly handy. In Zeppelin, you can write Scala or Python UDFs, while you can also import Scala, Python and Java UDFs.
+Here are 2 examples of Scala and Python UDFs:
+
+* Scala UDF
+
+```scala
+%flink
+
+class ScalaUpper extends ScalarFunction {
+def eval(str: String) = str.toUpperCase
+}
+btenv.registerFunction("scala_upper", new ScalaUpper())
+
+```
+
+* Python UDF
+
+```python
+
+%flink.pyflink
+
+class PythonUpper(ScalarFunction):
+def eval(self, s):
+ return s.upper()
+
+bt_env.register_function("python_upper", udf(PythonUpper(), DataTypes.STRING(), DataTypes.STRING()))
+
+```
+
+After you define the UDFs, you can use them directly in SQL:
+
+* Use Scala UDF in SQL
+
+
+
+
+
+* Use Python UDF in SQL
+
+
+
+
+
+# Summary
+
+In this post, we explained how to perform streaming data visualization via Flink on Zeppelin and how to use UDFs.
+Besides that, you can do more in Zeppelin with Flink, such as batch processing, Hive integration and more.
+You can check the following articles for more details and here's a list of [Flink on Zeppelin tutorial videos](https://www.youtube.com/watch?v=YxPo0Fosjjg&list=PL4oy12nnS7FFtg3KV1iS5vDb0pTz12VcX) for your reference.
+
+# References
+
+* [Apache Zeppelin official website](http://zeppelin.apache.org)
+* Flink on Zeppelin tutorials - [Part 1](https://medium.com/@zjffdu/flink-on-zeppelin-part-1-get-started-2591aaa6aa47)
+* Flink on Zeppelin tutorials - [Part 2](https://medium.com/@zjffdu/flink-on-zeppelin-part-2-batch-711731df5ad9)
+* Flink on Zeppelin tutorials - [Part 3](https://medium.com/@zjffdu/flink-on-zeppelin-part-3-streaming-5fca1e16754)
+* Flink on Zeppelin tutorials - [Part 4](https://medium.com/@zjffdu/flink-on-zeppelin-part-4-advanced-usage-998b74908cd9)
+* [Flink on Zeppelin tutorial videos](https://www.youtube.com/watch?v=YxPo0Fosjjg&list=PL4oy12nnS7FFtg3KV1iS5vDb0pTz12VcX)
diff --git a/docs/content.tr/posts/2020-07-06-release-1.11.0.md b/docs/content.tr/posts/2020-07-06-release-1.11.0.md
new file mode 100644
index 0000000000..30ec33a771
--- /dev/null
+++ b/docs/content.tr/posts/2020-07-06-release-1.11.0.md
@@ -0,0 +1,313 @@
+---
+authors:
+- morsapaes: null
+ name: Marta Paes
+ twitter: morsapaes
+date: "2020-07-06T08:00:00Z"
+excerpt: The Apache Flink community is proud to announce the release of Flink 1.11.0!
+ More than 200 contributors worked on over 1.3k issues to bring significant improvements
+ to usability as well as new features to Flink users across the whole API stack.
+ We're particularly excited about unaligned checkpoints to cope with high backpressure
+ scenarios, a new source API that simplifies and unifies the implementation of (custom)
+ sources, and support for Change Data Capture (CDC) and other common use cases in
+ the Table API/SQL. Read on for all major new features and improvements, important
+ changes to be aware of and what to expect moving forward!
+title: Apache Flink 1.11.0 Release Announcement
+aliases:
+- /news/2020/07/06/release-1.11.0.html
+---
+
+The Apache Flink community is proud to announce the release of Flink 1.11.0! More than 200 contributors worked on over 1.3k issues to bring significant improvements to usability as well as new features to Flink users across the whole API stack. Some highlights that we're particularly excited about are:
+
+* The core engine is introducing **unaligned checkpoints**, a major change to Flink's fault tolerance mechanism that improves checkpointing performance under heavy backpressure.
+
+* A **new Source API** that simplifies the implementation of (custom) sources by unifying batch and streaming execution, as well as offloading internals such as event-time handling, watermark generation or idleness detection to Flink.
+
+* Flink SQL is introducing **Support for Change Data Capture (CDC)** to easily consume and interpret database changelogs from tools like Debezium. The renewed **FileSystem Connector** also expands the set of use cases and formats supported in the Table API/SQL, enabling scenarios like streaming data directly from Kafka to Hive.
+
+* Multiple performance optimizations to PyFlink, including support for **vectorized User-defined Functions (Pandas UDFs)**. This improves interoperability with libraries like Pandas and NumPy, making Flink more powerful for data science and ML workloads.
+
+Read on for all major new features and improvements, important changes to be aware of and what to expect moving forward!
+
+The binary distribution and source artifacts are now available on the updated [Downloads page](/downloads.html) of the Flink website, and the most recent distribution of PyFlink is available on [PyPI](https://pypi.org/project/apache-flink/). Please review the [release notes]({{< param DocsBaseUrl >}}flink-docs-release-1.11/release-notes/flink-1.11.html) carefully, and check the complete [release changelog](https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12346364&styleName=Html&projectId=12315522) and [updated documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.11/flink-docs-release-1.11/) for more details.
+
+We encourage you to download the release and share your feedback with the community through the [Flink mailing lists](https://flink.apache.org/community.html#mailing-lists) or [JIRA](https://issues.apache.org/jira/projects/FLINK/summary).
+
+## New Features and Improvements
+
+### Unaligned Checkpoints (Beta)
+
+Triggering a checkpoint in Flink will cause a [checkpoint barrier]({{< param DocsBaseUrl >}}flink-docs-release-1.11/internals/stream_checkpointing.html#barriers) to flow from the sources of your topology all the way towards the sinks. For operators that receive more than one input stream, the barriers flowing through each channel need to be aligned before the operator can snapshot its state and forward the checkpoint barrier — typically, this alignment will take just a few milliseconds to complete, but it can become a bottleneck in backpressured pipelines as:
+
+ * Checkpoint barriers will flow much slower through backpressured channels, effectively blocking the remaining channels and their upstream operators during checkpointing;
+
+ * Slow checkpoint barrier propagation leads to longer checkpointing times and can, worst case, result in little to no progress in the application.
+
+To improve the performance of checkpointing under backpressure scenarios, the community is rolling out the first iteration of unaligned checkpoints ([FLIP-76](https://cwiki.apache.org/confluence/display/FLINK/FLIP-76%3A+Unaligned+Checkpoints)) with Flink 1.11. Compared to the original checkpointing mechanism (Fig. 1), this approach doesn’t wait for barrier alignment across input channels, instead allowing barriers to overtake in-flight records (i.e., data stored in buffers) and forwarding them downstream before the synchronous part of the checkpoint takes place (Fig. 2).
+
+
+
+
+
+
+
+
+
+
+
+ Fig.1: Aligned Checkpoints
+
+
+
+
+
+
+
+
+ Fig.2: Unaligned Checkpoints
+
+
+
+
+
+
+
+
+
+Because in-flight records have to be persisted as part of the snapshot, unaligned checkpoints will lead to increased checkpoints sizes. On the upside, **checkpointing times are heavily reduced**, so users will see more progress (even in unstable environments) as more up-to-date checkpoints will lighten the recovery process. You can learn more about the current limitations of unaligned checkpoints in the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/state/checkpoints.html#unaligned-checkpoints), and track the improvement work planned for this feature in [FLINK-14551](https://issues.apache.org/jira/browse/FLINK-14551).
+
+As with any beta feature, we appreciate early feedback that you might want to share with the community after giving unaligned checkpoints a try!
+
+Info To enable this feature, you need to configure the [``enableUnalignedCheckpoints``]({{< param DocsBaseUrl >}}flink-docs-release-1.11/api/java/org/apache/flink/streaming/api/environment/CheckpointConfig.html) option in your [checkpoint config]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/stream/state/checkpointing.html#enabling-and-configuring-checkpointing). Please note that unaligned checkpoints can only be enabled if ``checkpointingMode`` is set to ``CheckpointingMode.EXACTLY_ONCE``.
+
+### Unified Watermark Generators
+
+So far, watermark generation (prev. also called _assignment_) relied on two different interfaces: [``AssignerWithPunctuatedWatermarks``]({{< param DocsBaseUrl >}}flink-docs-release-1.11/api/java/org/apache/flink/streaming/api/functions/AssignerWithPunctuatedWatermarks.html) and [``AssignerWithPeriodicWatermarks``]({{< param DocsBaseUrl >}}flink-docs-release-1.11/api/java/org/apache/flink/streaming/api/functions/AssignerWithPeriodicWatermarks.html); that were closely intertwined with timestamp extraction. This made it difficult to implement long-requested features like support for idleness detection, besides leading to code duplication and maintenance burden. With [FLIP-126](https://cwiki.apache.org/confluence/display/FLINK/FLIP-126%3A+Unify+%28and+separate%29+Watermark+Assigners), the legacy watermark assigners are unified into a single interface: the [``WatermarkGenerator``]({{< param DocsBaseUrl >}}flink-docs-release-1.11/api/java/org/apache/flink/api/common/eventtime/WatermarkGenerator.html); and detached from the [``TimestampAssigner``]({{< param DocsBaseUrl >}}flink-docs-release-1.11/api/java/org/apache/flink/api/common/eventtime/TimestampAssigner.html).
+
+This gives users more control over watermark emission and simplifies the implementation of new connectors that need to support watermark assignment and timestamp extraction at the source (see _[New Data Source API](#new-data-source-api-beta)_). Multiple [strategies for watermarking]({{< param DocsBaseUrl >}}flink-docs-release-1.11//dev/event_timestamps_watermarks.html#introduction-to-watermark-strategies) are available out-of-the-box as convenience methods in Flink 1.11 (e.g. [``forBoundedOutOfOrderness``]({{< param DocsBaseUrl >}}flink-docs-release-1.11/api/java/org/apache/flink/api/common/eventtime/WatermarkStrategy.html#forBoundedOutOfOrderness-java.time.Duration-), [``forMonotonousTimestamps``]({{< param DocsBaseUrl >}}flink-docs-release-1.11/api/java/org/apache/flink/api/common/eventtime/WatermarkStrategy.html#forMonotonousTimestamps--)), though you can also choose to customize your own.
+
+**Support for Watermark Idleness Detection**
+
+The [``WatermarkStrategy.withIdleness()``]({{< param DocsBaseUrl >}}flink-docs-release-1.11/api/java/org/apache/flink/api/common/eventtime/WatermarkStrategy.html#withIdleness-java.time.Duration-) method allows you to mark a stream as idle if no events arrive within a configured time (i.e. a timeout duration), which in turn allows handling event time skew properly and preventing idle partitions from holding back the event time progress of the entire application. Users can already benefit from **per-partition idleness detection** in the Kafka connector, which has been adapted to use the new interfaces ([FLINK-17669](https://issues.apache.org/jira/browse/FLINK-17669)).
+
+Note [FLIP-126](https://cwiki.apache.org/confluence/display/FLINK/FLIP-126%3A+Unify+%28and+separate%29+Watermark+Assigners) introduces no breaking changes, but we recommend that users give preference to the new ``WatermarkGenerator`` interface moving forward, in preparation for the deprecation of the legacy watermark assigners in future releases.
+
+### New Data Source API (Beta)
+
+Up to this point, writing a production-grade source connector for Flink was a non-trivial task that required users to be somewhat familiar with Flink internals and account for implementation details like event time assignment, watermark generation or idleness detection in their code. Flink 1.11 introduces a new Data Source API ([FLIP-27](https://cwiki.apache.org/confluence/display/FLINK/FLIP-27%3A+Refactor+Source+Interface)) to overcome these limitations, as well as the need to rewrite separate code for batch and streaming execution.
+
+
+
+
+
+
+
+
+
+
+
+Separating the work of split discovery and the actual reading of the consumed data (i.e. the [_splits_]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/stream/sources.html#data-source-concepts)) in different components — resp. the ``SplitEnumerator`` and ``SourceReader`` — allows mixing and matching different enumeration strategies and split readers.
+
+As an example, the existing Kafka connector has multiple strategies for partition discovery that are intermingled with the rest of the code. With the new interfaces in place, it would only need a single reader implementation and there could be several split enumerators for the different partition discovery strategies.
+
+**Batch and Streaming Unification**
+
+Source connectors implemented using the Data Source API will be able to work both as a bounded (_batch_) and unbounded (_streaming_) source. The difference between both cases is minimal: for bounded input, the ``SplitEnumerator`` will generate a fixed set of splits and each split is finite; for unbounded input, either the splits are not finite or the ``SplitEnumerator`` keeps generating new splits.
+
+**Implicit Watermark and Event Time Handling**
+
+The ``TimestampAssigner`` and ``WatermarkGenerator`` run transparently as part of the ``SourceReader`` component, so users also don’t have to implement any timestamp extraction or watermark generation code.
+
+Note The existing source connectors have not yet been reimplemented using the Data Source API — this is planned for upcoming releases. If you’re looking to implement a new source, please refer to the [Data Source documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/stream/sources.html#data-sources) and [the tips on source development]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/stream/sources.html#the-data-source-api).
+
+### Application Mode Deployments
+
+Prior to Flink 1.11, jobs in a Flink application could either be submitted to a long-running [Flink Session Cluster]({{< param DocsBaseUrl >}}flink-docs-release-1.11/concepts/flink-architecture.html#flink-session-cluster) (_session mode_) or a dedicated [Flink Job Cluster]({{< param DocsBaseUrl >}}flink-docs-release-1.11/concepts/flink-architecture.html#flink-job-cluster) (_job mode_). For both these modes, the ``main()`` method of user programs runs on the _client_ side. This presents some challenges: on one hand, if the client is part of a large installation, it can easily become a bottleneck for ``JobGraph`` generation; and on the other, it’s not a good fit for containerized environments like Docker or Kubernetes.
+
+From this release on, Flink gets an additional deployment mode: [Application Mode]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/deployment/#application-mode) ([FLIP-85](https://cwiki.apache.org/confluence/display/FLINK/FLIP-85+Flink+Application+Mode)); where the ``main()`` method runs on the cluster, rather than the client. The job submission becomes a one-step process: you package your application logic and dependencies into an executable job JAR and the cluster entrypoint ([``ApplicationClusterEntryPoint``]({{< param DocsBaseUrl >}}flink-docs-release-1.11/api/java/org/apache/flink/client/deployment/application/ApplicationClusterEntryPoint.html)) is responsible for calling the ``main()`` method to extract the ``JobGraph``.
+
+In Flink 1.11, the community worked to already support _application mode_ in Kubernetes ([FLINK-10934](https://issues.apache.org/jira/browse/FLINK-10934)).
+
+### Other Improvements
+
+**Unified Memory Configuration for JobManagers ([FLIP-116](https://jira.apache.org/jira/browse/FLINK-16614))**
+
+Following the work started in Flink 1.10 to improve memory management and configuration, this release introduces a new memory model that aligns the [JobManagers’ configuration options]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/memory/mem_setup_jobmanager.html) and terminology with that introduced in [FLIP-49](https://cwiki.apache.org/confluence/display/FLINK/FLIP-49%3A+Unified+Memory+Configuration+for+TaskExecutors) for TaskManagers. This affects all deployment types: standalone, YARN, Mesos and the new active Kubernetes integration.
+
+Attention Reusing a previous Flink configuration without any adjustments can result in differently computed memory parameters for the JVM and, as a result, performance changes or even failures. Make sure to check the [migration guide]({{< param DocsBaseUrl >}}flink-docs-master/ops/memory/mem_migration.html#migrate-job-manager-memory-configuration) if you’re planning to update to the latest version.
+
+**Improvements to the Flink WebUI ([FLIP-75](https://cwiki.apache.org/confluence/display/FLINK/FLIP-75%3A+Flink+Web+UI+Improvement+Proposal))**
+
+In Flink 1.11, the community kicked off a series of improvements to the Flink WebUI. The first to roll out are better TaskManager and JobManager log display ([FLIP-103](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=147427143)), as well as a new thread dump utility ([FLINK-14816](https://issues.apache.org/jira/browse/FLINK-14816)). Some additional work planned for upcoming releases includes better backpressure detection, more flexible and configurable exception display and support for displaying the history of subtask failure attempts.
+
+**Docker Image Unification ([FLIP-111](https://cwiki.apache.org/confluence/display/FLINK/FLIP-111%3A+Docker+image+unification))**
+
+With this release, all Docker-related resources have been consolidated into [apache/flink-docker](https://github.com/apache/flink-docker) and the entry point script has been extended to allow users to run the default Docker image in different modes without the need to create a custom image. The [updated documentation]({{< param DocsBaseUrl >}}flink-docs-master/ops/deployment/docker.html#customize-flink-image) describes in detail how to use and customize the official Flink Docker image for different environments and deployment modes.
+
+
+
+### Table API/SQL: Support for Change Data Capture (CDC)
+
+Change Data Capture (CDC) has become a popular pattern to capture committed changes from a database and propagate those changes to downstream consumers, for example to keep multiple datastores in sync and avoid common pitfalls such as [dual writes](https://thorben-janssen.com/dual-writes/). Being able to easily ingest and interpret these changelogs into the Table API/SQL has been a highly demanded feature in the Flink community — and it’s now possible with Flink 1.11.
+
+To extend the scope of the Table API/SQL to use cases like CDC, Flink 1.11 introduces new table source and sink interfaces with **changelog mode** (see _[New TableSource and TableSink Interfaces](#other-improvements-to-the-table-apisql)_) and support for the [Debezium](https://debezium.io/) and [Canal](https://github.com/alibaba/canal) formats ([FLIP-105](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=147427289)). This means that dynamic tables sources are no longer limited to append-only operations and can ingest these external changelogs (``INSERT`` events), interpret them into change operations (``INSERT``, ``UPDATE``, ``DELETE`` events) and emit them downstream with the change type.
+
+
+
+
+
+
+
+
+
+
+
+Users have to specify either ``“format=debezium-json”`` or ``“format=canal-json”`` in their ``CREATE TABLE`` statement to consume changelogs using SQL DDL.
+
+```sql
+CREATE TABLE my_table (
+ ...
+) WITH (
+ 'connector'='...', -- e.g. 'kafka'
+ 'format'='debezium-json',
+ 'debezium-json.schema-include'='true' -- default: false (Debezium can be configured to include or exclude the message schema)
+ 'debezium-json.ignore-parse-errors'='true' -- default: false
+);
+```
+
+Flink 1.11 only supports Kafka as a changelog source out-of-the-box and JSON-encoded changelogs, with Avro (Debezium) and Protobuf (Canal) planned for future releases. There are also plans to support MySQL binlogs and Kafka compacted topics as sources, as well as to extend changelog support to batch execution.
+
+Attention There is a known issue ([FLINK-18461](https://issues.apache.org/jira/browse/FLINK-18461)) that prevents changelog sources from being used to write to upsert sinks (e.g. MySQL, HBase, Elasticsearch). This will be fixed in the next patch release (1.11.1).
+
+### Table API/SQL: JDBC Catalog Interface and Postgres Catalog
+
+Flink 1.11 introduces a generic JDBC catalog interface ([FLIP-93](https://cwiki.apache.org/confluence/display/FLINK/FLIP-93%3A+JDBC+catalog+and+Postgres+catalog)) that enables users of the Table API/SQL to **derive table schemas automatically** from connections to relational databases over [JDBC]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/connect.html#jdbc-connector). This eliminates the previous need for manual schema definition and type conversion, and also allows to check for schema errors at compile time instead of runtime.
+
+The first implementation, rolling out with the new release, is the [Postgres catalog]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/catalogs.html#postgrescatalog).
+
+### Table API/SQL: FileSystem Connector with Support for Avro, ORC and Parquet
+
+To improve the user experience for end-to-end streaming ETL use cases, the Flink community worked on a new FileSystem Connector for the Table API/SQL ([FLIP-115](https://cwiki.apache.org/confluence/display/FLINK/FLIP-115%3A+Filesystem+connector+in+Table)). The implementation is based on Flink’s [FileSystem abstraction]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/filesystems/index.html) and reuses [StreamingFileSink]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/connectors/streamfile_sink.html) to ensure the same set of capabilities and consistent behaviour with the DataStream API.
+
+This also means that Table API/SQL users can now make use of all formats already supported by StreamingFileSink, like (Avro) Parquet, as well as the new formats introduced with this release, like Avro ([FLINK-11395](https://issues.apache.org/jira/browse/FLINK-11395)) and Orc ([FLINK-10114](https://issues.apache.org/jira/browse/FLINK-10114)).
+
+```sql
+CREATE TABLE my_table (
+ column_name1 INT,
+ column_name2 STRING,
+ ...
+ part_name1 INT,
+ part_name2 STRING
+) PARTITIONED BY (part_name1, part_name2) WITH (
+ 'connector' = 'filesystem',
+ 'path' = 'file:///path/to/file,
+ 'format' = '...', -- supported formats: Avro, ORC, Parquet, CSV, JSON
+ ...
+);
+
+```
+
+The new all-rounder FileSystem Connector transparently handles batch and streaming execution, provides exactly-once guarantees and has full partition support, greatly expanding the scope of usage of the [legacy connector]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/connect.html#file-system-connector). This allows users to easily implement common use cases like **directly streaming data from Kafka to Hive**.
+
+You can track the upcoming improvements to the FileSystem Connector in [FLINK-17778](https://issues.apache.org/jira/browse/FLINK-17778).
+
+### Table API/SQL: Support for Python UDFs
+
+Prior to this release, users of the Table API/SQL were limited to defining UDFs in either Java or Scala. In Flink 1.11, the community worked on expanding the usage scope of the Python language beyond PyFlink and providing support for Python UDFs in the SQL DDL syntax ([FLIP-106](https://cwiki.apache.org/confluence/display/FLINK/FLIP-106%3A+Support+Python+UDF+in+SQL+Function+DDL)), as well as the SQL Client ([FLIP-114](https://cwiki.apache.org/confluence/display/FLINK/FLIP-114%3A+Support+Python+UDF+in+SQL+Client)). Users can also register Python UDFs in the system catalog via SQL DDL or the Java Catalog API, so that functions can be shared between jobs.
+
+### Other Improvements to the Table API/SQL
+
+**DDL and DML Compatibility for the Hive Connector ([FLIP-123](https://cwiki.apache.org/confluence/display/FLINK/FLIP-123%3A+DDL+and+DML+compatibility+for+Hive+connector))**
+
+Starting from Flink 1.11, users can write SQL statements directly using Hive syntax (HiveQL) in the Table API/SQL and the SQL Client. For this purpose, an additional dialect was introduced and users can now dynamically switch between Flink (``default``) and Hive (``hive``) on a per-statement basis. For a complete list of supported DDL and DML statements, check the Hive dialect [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/hive/hive_dialect.html#hive-dialect).
+
+**Extensions and Improvements to the Flink SQL Syntax**
+
+* Flink 1.11 introduces the concept of [primary key constraints]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/sql/create.html#create-table) to leverage runtime optimizations in Flink SQL DDL ([FLIP-87](https://cwiki.apache.org/confluence/display/FLINK/FLIP+87%3A+Primary+key+constraints+in+Table+API));
+
+* View objects are now fully supported in SQL DDL using the ``CREATE``/``ALTER``/``DROP VIEW`` statements ([FLIP-71](https://cwiki.apache.org/confluence/display/FLINK/FLIP-71%3A+E2E+View+support+in+FLINK+SQL));
+
+* Users can now specify or override table options in their DQL/DML statements using [dynamic table options]({{< param DocsBaseUrl >}}flink-docs-master/dev/table/sql/hints.html#dynamic-table-options) ([FLIP-113](https://cwiki.apache.org/confluence/display/FLINK/FLIP-113%3A+Supports+Dynamic+Table+Options+for+Flink+SQL)).
+
+* To make connector properties less verbose and improve exception handling, some key properties have been refactored ([FLIP-122](https://cwiki.apache.org/confluence/display/FLINK/FLIP-122%3A+New+Connector+Property+Keys+for+New+Factory)). This change does not break compatibility, so users can still use the old property keys.
+
+**New TableSource and TableSink Interfaces ([FLIP-95](https://cwiki.apache.org/confluence/display/FLINK/FLIP-95%3A+New+TableSource+and+TableSink+interfaces))**
+
+Flink 1.11 introduces new table source and sink interfaces (resp. [``DynamicTableSource``]({{< param DocsBaseUrl >}}flink-docs-release-1.11/api/java/org/apache/flink/table/connector/source/DynamicTableSource.html) and [``DynamicTableSink``]({{< param DocsBaseUrl >}}flink-docs-release-1.11/api/java/org/apache/flink/table/connector/sink/DynamicTableSink.html)) that unify batch and streaming execution, provide more efficient data processing with the Blink planner and offer support for handling changelogs (see _[Support for Change Data Capture (CDC)](#table-apisql-support-for-change-data-capture-cdc)_). The new interfaces also make it easier for users to [implement custom connectors]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/sourceSinks.html#full-stack-example) or modify existing ones. For an end-to-end example on how to implement a custom scan table source with a decoding format that supports changelog semantics, check out the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/sourceSinks.html#full-stack-example).
+
+Note Although compatibility is not immediately affected, we recommend that Table API/SQL users update any sources and sinks to the new interface stack.
+
+**Refactored TableEnvironment Interface ([FLIP-84](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=134745878))**
+
+The semantics to describe similar behaviours in the ``TableEnvironment`` and ``Table`` interfaces have diverged over time, leading to an inconsistent and sometimes unclear user experience. To improve this and make programming more fluent in the Table API/SQL, Flink 1.11 introduces new methods that unify behaviours like execution triggering (e.g. ``executeSql()``) and result representation (e.g. [``print()``]({{< param DocsBaseUrl >}}flink-docs-release-1.11/api/java/org/apache/flink/table/api/TableResult.html#print--), [``collect()``]({{< param DocsBaseUrl >}}flink-docs-release-1.11/api/java/org/apache/flink/table/api/TableResult.html#collect--)), and also lay the groundwork for important features like [multi-statement execution support](https://lists.apache.org/thread.html/r076e63bf6c8ed42d1b9ed2b406029696274a3a90cc360bc3a03e65d2%40%3Cdev.flink.apache.org%3E) in future releases.
+
+Note The methods deprecated with FLIP-84 will not be immediately removed, but we recommend that users adopt the newly introduced methods. For a complete list of new and deprecated methods, check the “Summary” section of [FLIP-84](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=134745878).
+
+**New Type Inference for Table API UDFs ([FLIP-65](https://cwiki.apache.org/confluence/display/FLINK/FLIP-65%3A+New+type+inference+for+Table+API+UDFs))**
+
+In Flink 1.9, the community started working on a [new data type system]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/types.html#data-types) for the Table API to improve its compliance with the SQL standard ([FLIP-37](https://cwiki.apache.org/confluence/display/FLINK/FLIP-37%3A+Rework+of+the+Table+API+Type+System)). This work is now close to being completed in Flink 1.11, with the exposure of Table API UDFs to the new type system (scalar and table functions, with aggregate functions planned for the next release).
+
+
+
+### PyFlink: Support for Pandas UDFs
+
+Up to this release, Python UDFs in PyFlink only supported scalar values of standard Python types. This presented some limitations:
+
+ * High serialization/deserialization overhead in the process of transferring data between the JVM and the Python processes;
+
+ * Hard to integrate with common Python libraries for high-performance numerical processing like pandas and NumPy.
+
+To overcome these limitations, the community introduced support for (scalar) **vectorized Python UDFs** based on [pandas](https://pandas.pydata.org/pandas-docs/stable/getting_started/overview.html) in Flink 1.11 ([FLIP-97](https://cwiki.apache.org/confluence/display/FLINK/FLIP-97%3A+Support+Scalar+Vectorized+Python+UDF+in+PyFlink)). The performance of vectorized UDFs is usually much higher, as the serialization/deserialization overhead is minimized by falling back to [Apache Arrow](https://arrow.apache.org/); and handling ``pandas.Series`` as input/output allows to take full advantage of the pandas and NumPy libraries. This makes Pandas UDFs a popular solution to parallelize Machine Learning and other large-scale, distributed data science workloads (e.g. feature engineering, distributed model application).
+
+```python
+@udf(input_types=[DataTypes.BIGINT(), DataTypes.BIGINT()], result_type=DataTypes.BIGINT(), udf_type="pandas")
+def add(i, j):
+ return i + j
+```
+
+To mark a UDF as a Pandas UDF, you only need to add an extra parameter ``udf_type=”pandas”`` in the udf decorator, as described in the [documentation]({{< param DocsBaseUrl >}}flink-docs-master/dev/table/python/vectorized_python_udfs.html#vectorized-user-defined-functions).
+
+### Other Improvements to PyFlink
+
+**Conversion fromPandas/toPandas ([FLIP-120](https://cwiki.apache.org/confluence/display/FLINK/FLIP-120%3A+Support+conversion+between+PyFlink+Table+and+Pandas+DataFrame))**
+
+Arrow is also supported as an optimization to convert between PyFlink tables and [``pandas.DataFrames``](https://pandas.pydata.org/pandas-docs/stable/reference/api/pandas.DataFrame.html), enabling users to switch processing engines seamlessly without the need for an intermediate connector. For examples on how to use the new ``fromPandas()`` and ``toPandas()`` methods in PyFlink, check out the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/python/conversion_of_pandas.html#conversions-between-pyflink-table-and-pandas-dataframe).
+
+**Support for User-defined Table Functions (UDTFs) ([FLINK-14500](https://jira.apache.org/jira/browse/FLINK-14500))**
+
+From Flink 1.11, you can define and register custom [UDTFs]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/python/python_udfs.html#table-functions) in PyFlink. Similar to a Python UDF, a UDTF takes zero, one or multiple scalar values as input, but can return an arbitrary number of rows as output instead of a single value.
+
+**Cython Performance Optimization for UDFs ([FLIP-121](https://cwiki.apache.org/confluence/display/FLINK/FLIP-121%3A+Support+Cython+Optimizing+Python+User+Defined+Function))**
+
+[Cython](https://cython.readthedocs.io/en/latest/src/quickstart/cythonize.html) is a compiled superset of the Python language that is often used to improve the performance of large-scale numeric processing in Python, as it optimizes execution to machine code-level speed and pairs well with popular C-based libraries like NumPy. From Flink 1.11, you can build [PyFlink with Cython support]({{< param DocsBaseUrl >}}flink-docs-release-1.11/flinkDev/building.html#build-pyflink) and “Cythonize” your Python UDFs to substantially improve code execution speed (up to 30x faster, compared to Python UDFs in Flink 1.10).
+
+**User-defined Metrics in Python UDFs ([FLIP-112](https://cwiki.apache.org/confluence/display/FLINK/FLIP-112%3A+Support+User-Defined+Metrics+in++Python+UDF))**
+
+To make it easier for users to monitor and debug the execution of Python UDFs, PyFlink now allows gathering and exposing metrics to external systems, as well as defining user scopes and variables. You can access the metrics system from a UDF by calling ``function_context.get_metric_group()`` in the open method, as described in the [documentation]({{< param DocsBaseUrl >}}flink-docs-master/dev/table/python/metrics.html#registering-metrics).
+
+
+
+## Important Changes
+
+ * [[FLINK-17339](https://jira.apache.org/jira/browse/FLINK-17339)] The Blink planner is the **default** in the Table API/SQL starting from Flink 1.11. This was already the case for the SQL Client since Flink 1.10. The old Flink planner is still supported, but not actively developed.
+
+ * [[FLINK-5763](https://issues.apache.org/jira/browse/FLINK-5763)] Savepoints now contain all their state inside a single directory (both metadata and program state). This makes it straightforward to figure out which files make up the state of a savepoint and allows users to **relocate savepoints** by simply moving a directory.
+
+ * [[FLINK-16408](https://issues.apache.org/jira/browse/FLINK-16408)] To reduce pressure on the JVM metaspace, the user code class loader is being reused by a ``TaskExecutor`` as long as there is at least a single slot allocated for the respective job. This changes Flink's recovery behaviour slightly, so that it will not reload static fields.
+
+* [[FLINK-11086](https://issues.apache.org/jira/browse/FLINK-11086)] Flink now supports Hadoop versions above **Hadoop 3.0.0**. Note that the Flink project does not provide any updated "flink-shaded-hadoop-\*" jars. Users need to provide Hadoop dependencies through the ``HADOOP_CLASSPATH`` environment variable (recommended) or the lib/ folder.
+
+* [[FLINK-16963](https://issues.apache.org/jira/browse/FLINK-16963)] All ``MetricReporters`` that come with Flink have been converted to plugins. These should no longer be placed into ``/lib`` (which may result in dependency conflicts), but ``/plugins/`` instead.
+
+* [[FLINK-12639](https://issues.apache.org/jira/browse/FLINK-12639)] The Flink **documentation** is undergoing some **rework**, so you might notice that the navigation and organization of content look slightly different starting from Flink 1.11.
+
+
+## Release Notes
+
+Please review the [release notes]({{< param DocsBaseUrl >}}flink-docs-release-1.11/release-notes/flink-1.11.html) carefully for a detailed list of changes and new features if you plan to upgrade your setup to Flink 1.11. This version is API-compatible with previous 1.x releases for APIs annotated with the @Public annotation.
+
+## List of Contributors
+
+The Apache Flink community would like to thank all the 200+ contributors that have made this release possible:
+
+Aitozi, Alexander Fedulov, Alexey Trenikhin, Aljoscha Krettek, Andrey Zagrebin, Arvid Heise, Ayush Saxena, Bairos, Bartosz Krasinski, Benchao Li, Benoit Hanotte, Benoît Paris, Bhagavan Das, Canbin Zheng, Cedric Chen, Chesnay Schepler, Colm O hEigeartaigh, Congxian Qiu, CrazyTomatoOo, Danish Amjad, Danny Chan, David Anderson, Dawid Wysakowicz, Dian Fu, Dominik Wosiński, Echo Lee, Ethan Marsh, Etienne Chauchot, Fabian Hueske, Fabian Paul, Flavio Pompermaier, Gao Yun, Gary Yao, Ghildiyal, Grebennikov Roman, GuoWei Ma, Guru Prasad, Gyula Fora, Hequn Cheng, Hu Guang, HuFeiHu, HuangXingBo, Igal Shilman, Ismael Juma, Jacob Sevart, Jark Wu, Jaskaran Bindra, Jason K, Jeff Yang, Jeff Zhang, Jerry Wang, Jiangjie (Becket) Qin, Jiayi, Jiayi Liao, Jiayi-Liao, Jincheng Sun, Jing Zhang, Jingsong Lee, JingsongLi, Jun Qin, JunZhang, Jörn Kottmann, Kevin Bohinski, Konstantin Knauf, Kostas Kloudas, Kurt Young, Leonard Xu, Lining Jing, Liupengcheng, LululuAlu, Marta Paes Moreira, Matt Welke, Max Kuklinski, Maximilian Michels, Nico Kruber, Niels Basjes, Oleksandr Nitavskyi, Paul Lam, Paul Lin, PengFei Li, PengchengLiu, Piotr Nowojski, Prem Santosh, Qingsheng Ren, Rafi Aroch, Raymond Farrelly, Richard Deurwaarder, Robert Metzger, RocMarshal, Roey Shem Tov, Roman, Roman Khachatryan, Rong Rong, RoyRuan, Rui Li, Seth Wiesman, Shaobin.Ou, Shengkai, Shuiqiang Chen, Shuo Cheng, Sivaprasanna, Sivaprasanna S, SteNicholas, Stefan Richter, Stephan Ewen, Steve OU, Steve Whelan, Tartarus, Terry Wang, Thomas Weise, Till Rohrmann, Timo Walther, TsReaper, Tzu-Li (Gordon) Tai, Victor Wong, Wei Zhong, Weike DONG, Xiaogang Zhou, Xintong Song, Xu Bai, Xuannan, Yadong Xie, Yang Wang, Yangze Guo, Yichao Yang, Ying, Yu Li, Yuan Mei, Yun Gao, Yun Tang, Yuval Itzchakov, Zakelly, Zhao, Zhenghua Gao, Zhijiang, Zhu Zhu, acqua.csq, austin ce, azagrebin, bdine, bowen.li, caoyingjie, caozhen, caozhen1937, chaojianok, chen, chendonglin, comsir, cpugputpu, czhang2, dianfu, edu05, eduardowt, fangliang, felixzheng, fmyblack, gauss, gk0916, godfrey he, godfreyhe, guliziduo, guowei.mgw, hehuiyuan, hequn8128, hpeter, huangxingbo, huzheng, ifndef-SleePy, jingwen-ywb, jrthe42, kevin.cyj, klion26, lamber-ken, leesf, libenchao, lijiewang.wlj, liuyongvs, lsy, lumen, machinedoll, mans2singh, molsionmo, oliveryunchang, openinx, paul8263, ptmagic, qqibrow, sev7e0, shuai-xu, shuai.xu, shuiqiangchen, snuyanzin, spafka, sunhaibotb, sunjincheng121, testfixer, tison, vinoyang, vthinkxie, wangtong, wangxianghu, wangxiyuan, wangxlong, wangyang0918, wenlong.lwl, whlwanghailong, william, windWheel, wooplevip, wuxuyang, xushiwei, xuyang1706, yanghua, yangyichao-mango, yuzhao.cyz, zentol, zhanglibing, zhangmang, zhangzhanchun, zhengcanbin, zhengshuli, zhenxianyimeng, zhijiang, zhongyong jin, zhule, zhuxiaoshang, zjuwangg, zoudan, zoudaokoulife, zzchun, “lzh576177775”, 骚sir, 厉颖, 张军, 曹建华, 漫步云端
diff --git a/docs/content.tr/posts/2020-07-14-application-mode.md b/docs/content.tr/posts/2020-07-14-application-mode.md
new file mode 100644
index 0000000000..fcb376d5c0
--- /dev/null
+++ b/docs/content.tr/posts/2020-07-14-application-mode.md
@@ -0,0 +1,282 @@
+---
+authors:
+- kostas: null
+ name: Kostas Kloudas
+ twitter: kkloudas
+date: "2020-07-14T08:00:00Z"
+title: 'Application Deployment in Flink: Current State and the new Application Mode'
+aliases:
+- /news/2020/07/14/application-mode.html
+---
+
+With the rise of stream processing and real-time analytics as a critical tool for modern
+businesses, an increasing number of organizations build platforms with Apache Flink at their
+core and offer it internally as a service. Many talks with related topics from companies
+like [Uber](https://www.youtube.com/watch?v=VX3S9POGAdU), [Netflix](https://www.youtube.com/watch?v=VX3S9POGAdU)
+and [Alibaba](https://www.youtube.com/watch?v=cH9UdK0yYjc) in the latest editions of Flink Forward further
+illustrate this trend.
+
+These platforms aim at simplifying application submission internally by lifting all the
+operational burden from the end user. To submit Flink applications, these platforms
+usually expose only a centralized or low-parallelism endpoint (*e.g.* a Web frontend)
+for application submission that we will call the *Deployer*.
+
+One of the roadblocks that platform developers and maintainers often mention is that the
+Deployer can be a heavy resource consumer that is difficult to provision for. Provisioning
+for average load can lead to the Deployer service being overwhelmed with deployment
+requests (in the worst case, for all production applications in a short period of time),
+while planning based on top load leads to unnecessary costs. Building on this observation,
+Flink 1.11 introduces the [Application Mode]({{< param DocsBaseUrl >}}flink-docs-stable/ops/deployment/#application-mode)
+as a deployment option, which allows for a lightweight, more scalable application
+submission process that manages to spread more evenly the application deployment load
+across the nodes in the cluster.
+
+In order to understand the problem and how the Application Mode solves it, we start by
+describing briefly the current status of application execution in Flink, before
+describing the architectural changes introduced by the new deployment mode and how to
+leverage them.
+
+# Application Execution in Flink
+
+The execution of an application in Flink mainly involves three entities: the *Client*,
+the *JobManager* and the *TaskManagers*. The Client is responsible for submitting the application to the
+cluster, the JobManager is responsible for the necessary bookkeeping during execution,
+and the TaskManagers are the ones doing the actual computation. For more details please
+refer to [Flink's Architecture]({{< param DocsBaseUrl >}}flink-docs-stable/concepts/flink-architecture.html)
+documentation page.
+
+## Current Deployment Modes
+
+Before the introduction of the Application Mode in version 1.11, Flink allowed users to execute an application either on a
+*Session* or a *Per-Job Cluster*. The differences between the two have to do with the cluster
+lifecycle and the resource isolation guarantees they provide.
+
+### Session Mode
+
+Session Mode assumes an already running cluster and uses the resources of that cluster to
+execute any submitted application. Applications executed in the same (session) cluster use,
+and consequently compete for, the same resources. This has the advantage that you do not
+pay the resource overhead of spinning up a full cluster for every submitted job. But, if
+one of the jobs misbehaves or brings down a TaskManager, then all jobs running on that
+TaskManager will be affected by the failure. Apart from a negative impact on the job that
+caused the failure, this implies a potential massive recovery process with all the
+restarting jobs accessing the file system concurrently and making it unavailable to other
+services. Additionally, having a single cluster running multiple jobs implies more load
+for the JobManager, which is responsible for the bookkeeping of all the jobs in the
+cluster. This mode is ideal for short jobs where startup latency is of high importance,
+*e.g.* interactive queries.
+
+### Per-Job Mode
+
+In Per-Job Mode, the available cluster manager framework (*e.g.* YARN or Kubernetes) is
+used to spin up a Flink cluster for each submitted job, which is available to that job
+only. When the job finishes, the cluster is shut down and any lingering resources
+(*e.g.* files) are cleaned up. This mode allows for better resource isolation, as a
+misbehaving job cannot affect any other job. In addition, it spreads the load of
+bookkeeping across multiple entities, as each application has its own JobManager.
+Given the aforementioned resource isolation concerns of the Session Mode, users often
+opt for the Per-Job Mode for long-running jobs which are willing to accept some increase
+in startup latency in favor of resilience.
+
+To summarize, in Session Mode, the cluster lifecycle is independent of any job running on
+the cluster and all jobs running on the cluster share its resources. The per-job mode
+chooses to pay the price of spinning up a cluster for every submitted job, in order to
+provide better resource isolation guarantees as the resources are not shared across jobs.
+In this case, the lifecycle of the cluster is bound to that of the job.
+
+## Application Submission
+
+Flink application execution consists of two stages: *pre-flight*, when the users’ `main()`
+method is called; and *runtime*, which is triggered as soon as the user code calls `execute()`.
+The `main()` method constructs the user program using one of Flink’s APIs
+(DataStream API, Table API, DataSet API). When the `main()` method calls `env.execute()`,
+the user-defined pipeline is translated into a form that Flink's runtime can understand,
+called the *job graph*, and it is shipped to the cluster.
+
+Despite their differences, both session and per-job modes execute the application’s `main()`
+method, *i.e.* the *pre-flight* phase, on the client side.[^1]
+
+[^1]: The only exceptions are the Web Submission and the Standalone per-job implementation.
+
+This is usually not a problem for individual users who already have all the dependencies
+of their jobs locally, and then submit their applications through a client running on
+their machine. But in the case of submission through a remote entity like the Deployer,
+this process includes:
+
+ * downloading the application’s dependencies locally,
+
+ * executing the main()method to extract the job graph,
+
+ * ship the job graph and its dependencies to the cluster for execution and,
+
+ * potentially, wait for the result.
+
+This makes the Client a heavy resource consumer as it may need substantial network
+bandwidth to download dependencies and ship binaries to the cluster, and CPU cycles to
+execute the `main()` method. This problem is even more pronounced as more users share
+the same Client.
+
+
+
+
+
+
+
+
+
+
+
+
+
+The figure above illustrates the two deployment modes using 3 applications depicted in
+red , blue and green .
+Each one has a parallelism of 3. The black rectangles represent
+different processes: TaskManagers, JobManagers and the Deployer; and we assume a single
+Deployer process in all scenarios. The colored triangles represent the load of the
+submission process, while the colored rectangles represent the load of the TaskManager
+and JobManager processes. As shown in the figure, the Deployer in both per-job and
+session mode share the same load. Their difference lies in the distribution of the
+tasks and the JobManager load. In the Session Mode, there is a single JobManager for
+all the jobs in the cluster while in the per-job mode, there is one for each job. In
+addition, tasks in Session Mode are assigned randomly to TaskManagers while in Per-Job
+Mode, each TaskManager can only have tasks of a single job.
+
+# Application Mode
+
+
+
+The Application Mode builds on the above observations and tries to combine the resource
+isolation of the per-job mode with a lightweight and scalable application submission
+process. To achieve this, it creates a cluster *per submitted application*, but this
+time, the `main()` method of the application is executed on the JobManager.
+
+Creating a cluster per application can be seen as creating a session cluster shared
+only among the jobs of a particular application and torn down when the application
+finishes. With this architecture, the Application Mode provides the same resource
+isolation and load balancing guarantees as the Per-Job Mode, but at the granularity of
+a whole application. This makes sense, as jobs belonging to the same application are
+expected to be correlated and treated as a unit.
+
+Executing the `main()` method on the JobManager allows saving the CPU cycles required
+for extracting the job graph, but also the bandwidth required on the client for
+downloading the dependencies locally and shipping the job graph and its dependencies
+to the cluster. Furthermore, it spreads the network load more evenly, as there is one
+JobManager per application. This is illustrated in the figure above, where we have the
+same scenario as in the session and per-job deployment mode section, but this time
+the client load has shifted to the JobManager of each application.
+
+
+ Note
+In the Application Mode, the main() method is executed on the cluster and not on the Client, as in the other modes.
+This may have implications for your code as, for example, any paths you register in your
+environment using the registerCachedFile() must be accessible by the JobManager of
+your application.
+
+
+Compared to the Per-Job Mode, the Application Mode allows the submission of applications
+consisting of multiple jobs. The order of job execution is not affected by the deployment
+mode but by the call used to launch the job. Using the blocking `execute()` method
+establishes an order and will lead to the execution of the “next” job being postponed
+until “this” job finishes. In contrast, the non-blocking `executeAsync()` method will
+immediately continue to submit the “next” job as soon as the current job is submitted.
+
+## Reducing Network Requirements
+
+As described above, by executing the application's `main()` method on the JobManager,
+the Application Mode manages to save a lot of the resources previously required during
+job submission. But there is still room for improvement.
+
+Focusing on YARN, which already supports all the optimizations mentioned here[^2], and
+even with the Application Mode in place, the Client is still required to send the user
+jar to the JobManager. In addition, *for each application*, the Client has to ship to
+the cluster the "flink-dist" directory which contains the binaries of the framework
+itself, including the `flink-dist.jar`, `lib/` and `plugin/` directories. These two can
+account for a substantial amount of bandwidth on the client side. Furthermore, shipping
+the same flink-dist binaries on every submission is both a waste of bandwidth but also
+of storage space which can be alleviated by simply allowing applications to share the
+same binaries.
+
+[^2]: Support for Kubernetes will come soon.
+
+In Flink 1.11, we introduce options that allow the user to:
+
+ 1. Specify a remote path to a directory where YARN can find the Flink distribution binaries, and
+
+ 2. Specify a remote path where YARN can find the user jar.
+
+For 1., we leverage YARN’s distributed cache and allow applications to share these
+binaries. So, if an application happens to find copies of Flink on the local storage
+of its TaskManager due to a previous application that was executed on the same
+TaskManager, it will not even have to download it internally.
+
+
+ Note
+Both optimizations are available to all deployment modes on YARN, and not only the Application Mode.
+
+
+# Example: Application Mode on Yarn
+
+For a full description, please refer to the official Flink documentation and more
+specifically to the page that refers to your cluster management framework, *e.g.*
+[YARN]({{< param DocsBaseUrl >}}flink-docs-stable/ops/deployment/yarn_setup.html#run-an-application-in-application-mode)
+or [Kubernetes]({{< param DocsBaseUrl >}}flink-docs-stable/ops/deployment/native_kubernetes.html#flink-kubernetes-application).
+Here we will give some examples around YARN, where all the above features are available.
+
+To launch an application in Application Mode, you can use:
+
+./bin/flink run-application -t yarn-application ./MyApplication.jar
+
+With this command, all configuration parameters, such as the path to a savepoint to
+be used to bootstrap the application’s state or the required JobManager/TaskManager
+memory sizes, can be specified by their configuration option, prefixed by `-D`. For
+a catalog of the available configuration options, please refer to Flink’s
+[configuration page]({{< param DocsBaseUrl >}}flink-docs-stable/ops/config.html).
+
+As an example, the command to specify the memory sizes of the JobManager and the
+TaskManager would look like:
+
+./bin/flink run-application -t yarn-application \
+ -Djobmanager.memory.process.size=2048m \
+ -Dtaskmanager.memory.process.size=4096m \
+ ./MyApplication.jar
+
+
+As discussed earlier, the above will make sure that your application’s `main()` method
+will be executed on the JobManager.
+
+To further save the bandwidth of shipping the Flink distribution to the cluster, consider
+pre-uploading the Flink distribution to a location accessible by YARN and using the
+`yarn.provided.lib.dirs` configuration option, as shown below:
+
+./bin/flink run-application -t yarn-application \
+ -Djobmanager.memory.process.size=2048m \
+ -Dtaskmanager.memory.process.size=4096m \
+ -Dyarn.provided.lib.dirs="hdfs://myhdfs/remote-flink-dist-dir" \
+ ./MyApplication.jar
+
+
+Finally, in order to further save the bandwidth required to submit your application jar,
+you can pre-upload it to HDFS, and specify the remote path that points to
+`./MyApplication.jar`, as shown below:
+
+./bin/flink run-application -t yarn-application \
+ -Djobmanager.memory.process.size=2048m \
+ -Dtaskmanager.memory.process.size=4096m \
+ -Dyarn.provided.lib.dirs="hdfs://myhdfs/remote-flink-dist-dir" \
+ hdfs://myhdfs/jars/MyApplication.jar
+
+
+This will make the job submission extra lightweight as the needed Flink jars and the
+application jar are going to be picked up from the specified remote locations rather
+than be shipped to the cluster by the Client. The only thing the Client will ship to
+the cluster is the configuration of your application which includes all the
+aforementioned paths.
+
+# Conclusion
+
+We hope that this discussion helped you understand the differences between the various
+deployment modes offered by Flink and will help you to make informed decisions about
+which one is suitable in your own setup. Feel free to play around with them and report
+any issues you may find. If you have any questions or requests, do not hesitate to post
+them in the [mailing lists](https://wints.github.io/flink-web//community.html#mailing-lists)
+and, hopefully, see you (virtually) at one of our conferences or meetups soon!
diff --git a/docs/content.tr/posts/2020-07-21-release-1.11.1.md b/docs/content.tr/posts/2020-07-21-release-1.11.1.md
new file mode 100644
index 0000000000..0766282409
--- /dev/null
+++ b/docs/content.tr/posts/2020-07-21-release-1.11.1.md
@@ -0,0 +1,153 @@
+---
+authors:
+- Dian Fu: null
+ name: Dian Fu
+ twitter: DianFu11
+date: "2020-07-21T18:00:00Z"
+title: Apache Flink 1.11.1 Released
+aliases:
+- /news/2020/07/21/release-1.11.1.html
+---
+
+The Apache Flink community released the first bugfix version of the Apache Flink 1.11 series.
+
+This release includes 44 fixes and minor improvements for Flink 1.11.0. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.11.1.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.11.1
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.11.1
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.11.1
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-15794 ] - Rethink default value of kubernetes.container.image
+
+[FLINK-18324 ] - Translate updated data type and function page into Chinese
+
+[FLINK-18387 ] - Translate "BlackHole SQL Connector" page into Chinese
+
+[FLINK-18388 ] - Translate "CSV Format" page into Chinese
+
+[FLINK-18391 ] - Translate "Avro Format" page into Chinese
+
+[FLINK-18395 ] - Translate "ORC Format" page into Chinese
+
+[FLINK-18469 ] - Add Application Mode to release notes.
+
+[FLINK-18524 ] - Scala varargs cause exception for new inference
+
+
+
+ Bug
+
+
+[FLINK-15414 ] - KafkaITCase#prepare failed in travis
+
+[FLINK-16181 ] - IfCallGen will throw NPE for primitive types in blink
+
+[FLINK-16572 ] - CheckPubSubEmulatorTest is flaky on Azure
+
+[FLINK-17543 ] - Rerunning failed azure jobs fails when uploading logs
+
+[FLINK-17636 ] - SingleInputGateTest.testConcurrentReadStateAndProcessAndClose: Trying to read from released RecoveredInputChannel
+
+[FLINK-18097 ] - History server doesn't clean all job json files
+
+[FLINK-18419 ] - Can not create a catalog from user jar
+
+[FLINK-18434 ] - Can not select fields with JdbcCatalog
+
+[FLINK-18440 ] - ROW_NUMBER function: ROW/RANGE not allowed with RANK, DENSE_RANK or ROW_NUMBER functions
+
+[FLINK-18461 ] - Changelog source can't be insert into upsert sink
+
+[FLINK-18470 ] - Tests RocksKeyGroupsRocksSingleStateIteratorTest#testMergeIteratorByte & RocksKeyGroupsRocksSingleStateIteratorTest#testMergeIteratorShort fail locally
+
+[FLINK-18471 ] - flink-runtime lists "org.uncommons.maths:uncommons-maths:1.2.2a" as a bundled dependency, but it isn't
+
+[FLINK-18477 ] - ChangelogSocketExample does not work
+
+[FLINK-18478 ] - AvroDeserializationSchema does not work with types generated by avrohugger
+
+[FLINK-18485 ] - Kerberized YARN per-job on Docker test failed during unzip jce_policy-8.zip
+
+[FLINK-18519 ] - Propagate exception to client when execution fails for REST submission
+
+[FLINK-18520 ] - New Table Function type inference fails
+
+[FLINK-18529 ] - Query Hive table and filter by timestamp partition can fail
+
+[FLINK-18539 ] - StreamExecutionEnvironment#addSource(SourceFunction, TypeInformation) doesn't use the user defined type information
+
+[FLINK-18573 ] - InfluxDB reporter cannot be loaded as plugin
+
+[FLINK-18583 ] - The _id field is incorrectly set to index in Elasticsearch6 DynamicTableSink
+
+[FLINK-18585 ] - Dynamic index can not work in new DynamicTableSink
+
+[FLINK-18591 ] - Fix the format issue for metrics web page
+
+
+
+ Improvement
+
+
+[FLINK-18186 ] - Various updates on Kubernetes standalone document
+
+[FLINK-18422 ] - Update Prefer tag in documentation 'Fault Tolerance training lesson'
+
+[FLINK-18457 ] - Fix invalid links in "Detecting Patterns" page of "Streaming Concepts"
+
+[FLINK-18472 ] - Local Installation Getting Started Guide
+
+[FLINK-18484 ] - RowSerializer arity error does not provide specific information about the mismatch
+
+[FLINK-18501 ] - Mapping of Pluggable Filesystems to scheme is not properly logged
+
+[FLINK-18526 ] - Add the configuration of Python UDF using Managed Memory in the doc of Pyflink
+
+[FLINK-18532 ] - Remove Beta tag from MATCH_RECOGNIZE docs
+
+[FLINK-18561 ] - Build manylinux1 with better compatibility instead of manylinux2014 Python Wheel Packages
+
+[FLINK-18593 ] - Hive bundle jar URLs are broken
+
+
+
+ Test
+
+
+[FLINK-18534 ] - KafkaTableITCase.testKafkaDebeziumChangelogSource failed with "Topic 'changelog_topic' already exists"
+
+
+
+ Task
+
+
+[FLINK-18502 ] - Add the page 'legacySourceSinks.zh.md' into the directory 'docs/dev/table'
+
+[FLINK-18505 ] - Correct the content of 'sourceSinks.zh.md'
+
+
diff --git a/docs/content.tr/posts/2020-07-23-catalogs.md b/docs/content.tr/posts/2020-07-23-catalogs.md
new file mode 100644
index 0000000000..1c0ad6ebae
--- /dev/null
+++ b/docs/content.tr/posts/2020-07-23-catalogs.md
@@ -0,0 +1,200 @@
+---
+authors:
+- dawid: null
+ name: Dawid Wysakowicz
+ twitter: dwysakowicz
+date: "2020-07-23T08:00:00Z"
+title: Sharing is caring - Catalogs in Flink SQL
+aliases:
+- /2020/07/23/catalogs.html
+---
+
+With an ever-growing number of people working with data, it's a common practice for companies to build self-service platforms with the goal of democratizing their access across different teams and — especially — to enable users from any background to be independent in their data needs. In such environments, metadata management becomes a crucial aspect. Without it, users often work blindly, spending too much time searching for datasets and their location, figuring out data formats and similar cumbersome tasks.
+
+In this blog post, we want to give you a high level overview of catalogs in Flink. We'll describe why you should consider using them and what you can achieve with one in place. To round it up, we'll also showcase how simple it is to combine catalogs and Flink, in the form of an end-to-end example that you can try out yourself.
+
+## Why do I need a catalog?
+
+Frequently, companies start building a data platform with a metastore, catalog, or schema registry of some sort already in place. Those let you clearly separate making the data available from consuming it. That separation has a few benefits:
+
+* **Improved productivity** - The most obvious one. Making data reusable and shifting the focus on building new models/pipelines rather than data cleansing and discovery.
+* **Security** - You can control the access to certain features of the data. For example, you can make the schema of the dataset publicly available, but limit the actual access to the underlying data only to particular teams.
+* **Compliance** - If you have all the metadata in a central entity, it's much easier to ensure compliance with GDPR and similar regulations and legal requirements.
+
+## What is stored in a catalog?
+
+Almost all data sets can be described by certain properties that must be known in order to consume them. Those include:
+
+* **Schema** - It describes the actual contents of the data, what columns it has, what are the constraints (e.g. keys) on which the updates should be performed, which fields can act as time attributes, what are the rules for watermark generation and so on.
+
+* **Location** - Does the data come from Kafka or a file in a filesystem? How do you connect to the external system? Which topic or file name do you use?
+
+* **Format** - Is the data serialized as JSON, CSV, or maybe Avro records?
+
+* **Statistics** - You can also store additional information that can be useful when creating an execution plan of your query. For example, you can choose the best join algorithm, based on the number of rows in joined datasets.
+
+Catalogs don’t have to be limited to the metadata of datasets. You can usually store other objects that can be reused in different scenarios, such as:
+
+* **Functions** - It's very common to have domain specific functions that can be helpful in different use cases. Instead of having to create them in each place separately, you can just create them once and share them with others.
+
+* **Queries** - Those can be useful when you don’t want to persist a data set, but want to provide a recipe for creating it from other sources instead.
+
+## Catalogs support in Flink SQL
+Starting from version 1.9, Flink has a set of Catalog APIs that allows to integrate Flink with various catalog implementations. With the help of those APIs, you can query tables in Flink that were created in your external catalogs (e.g. Hive Metastore). Additionally, depending on the catalog implementation, you can create new objects such as tables or views from Flink, reuse them across different jobs, and possibly even use them in other tools compatible with that catalog. In other words, you can see catalogs as having a two-fold purpose:
+
+ * Provide an out-of-the box integration with ecosystems such as RDBMSs or Hive that allows you to query external objects like tables, views, or functions with no additional connector configuration. The connector properties are automatically derived from the catalog itself.
+
+ * Act as a persistent store for Flink-specific metadata. In this mode, we additionally store connector properties alongside the logical metadata (e.g. schema, object name). That approach enables you to, for example, store a full definition of a Kafka-backed table with records serialized with Avro in Hive that can be later on used by Flink. However, as it incorporates Flink-specific properties, it can not be used by other tools that leverage Hive Metastore.
+
+As of Flink 1.11, there are two catalog implementations supported by the community:
+
+ 1. A comprehensive Hive catalog
+
+ 2. A Postgres catalog (preview, read-only, for now)
+
+
+ Note
+Flink does not store data at rest; it is a compute engine and requires other systems to consume input from and write its output. This means that Flink does not own the lifecycle of the data. Integration with Catalogs does not change that. Flink uses catalogs for metadata management only.
+
+
+All you need to do to start querying your tables defined in either of these metastores is to create the corresponding catalogs with connection parameters. Once this is done, you can use them the way you would in any relational database management system.
+
+```sql
+-- create a catalog which gives access to the backing Postgres installation
+CREATE CATALOG postgres WITH (
+ 'type'='jdbc',
+ 'property-version'='1',
+ 'base-url'='jdbc:postgresql://postgres:5432/',
+ 'default-database'='postgres',
+ 'username'='postgres',
+ 'password'='example'
+);
+
+-- create a catalog which gives access to the backing Hive installation
+CREATE CATALOG hive WITH (
+ 'type'='hive',
+ 'property-version'='1',
+ 'hive-version'='2.3.6',
+ 'hive-conf-dir'='/opt/hive-conf'
+);
+```
+
+After creating the catalogs, you can confirm that they are available to Flink and also list the databases or tables in each of these catalogs:
+
+```sql
+> show catalogs;
+default_catalog
+hive
+postgres
+
+-- switch the default catalog to Hive
+> use catalog hive;
+> show databases;
+default -- hive's default database
+
+> show tables;
+dev_orders
+
+> use catalog postgres;
+> show tables;
+prod_customer
+prod_nation
+prod_rates
+prod_region
+region_stats
+
+-- desribe a schema of a table in Postgres, the Postgres types are automatically mapped to
+-- Flink's type system
+> describe prod_customer
+root
+ |-- c_custkey: INT NOT NULL
+ |-- c_name: VARCHAR(25) NOT NULL
+ |-- c_address: VARCHAR(40) NOT NULL
+ |-- c_nationkey: INT NOT NULL
+ |-- c_phone: CHAR(15) NOT NULL
+ |-- c_acctbal: DOUBLE NOT NULL
+ |-- c_mktsegment: CHAR(10) NOT NULL
+ |-- c_comment: VARCHAR(117) NOT NULL
+```
+
+Now that you know which tables are available, you can write your first query.
+In this scenario, we keep customer orders in Hive (``dev_orders``) because of their volume, and reference customer data in Postgres (``prod_customer``) to be able to easily update it. Let’s write a query that shows customers and their orders by region and order priority for a specific day.
+
+```sql
+USE CATALOG postgres;
+SELECT
+ r_name AS `region`,
+ o_orderpriority AS `priority`,
+ COUNT(DISTINCT c_custkey) AS `number_of_customers`,
+ COUNT(o_orderkey) AS `number_of_orders`
+FROM `hive`.`default`.dev_orders -- we need to fully qualify the table in hive because we set the
+ -- current catalog to Postgres
+JOIN prod_customer ON o_custkey = c_custkey
+JOIN prod_nation ON c_nationkey = n_nationkey
+JOIN prod_region ON n_regionkey = r_regionkey
+WHERE
+ FLOOR(o_ordertime TO DAY) = TIMESTAMP '2020-04-01 0:00:00.000'
+ AND NOT o_orderpriority = '4-NOT SPECIFIED'
+GROUP BY r_name, o_orderpriority
+ORDER BY r_name, o_orderpriority;
+```
+
+Flink's catalog support also covers storing Flink-specific objects in external catalogs that might not be fully usable by the corresponding external tools. The most notable use case for this is, for example, storing a table that describes a Kafka topic in a Hive catalog. Take the following DDL statement, that contains a watermark declaration as well as a set of connector properties that are not recognizable by Hive. You won't be able to query the table with Hive, but it will be persisted and can be reused by different Flink jobs.
+
+```sql
+USE CATALOG hive;
+CREATE TABLE prod_lineitem (
+ l_orderkey INTEGER,
+ l_partkey INTEGER,
+ l_suppkey INTEGER,
+ l_linenumber INTEGER,
+ l_quantity DOUBLE,
+ l_extendedprice DOUBLE,
+ l_discount DOUBLE,
+ l_tax DOUBLE,
+ l_currency STRING,
+ l_returnflag STRING,
+ l_linestatus STRING,
+ l_ordertime TIMESTAMP(3),
+ l_shipinstruct STRING,
+ l_shipmode STRING,
+ l_comment STRING,
+ l_proctime AS PROCTIME(),
+ WATERMARK FOR l_ordertime AS l_ordertime - INTERVAL '5' SECONDS
+) WITH (
+ 'connector'='kafka',
+ 'topic'='lineitem',
+ 'scan.startup.mode'='earliest-offset',
+ 'properties.bootstrap.servers'='kafka:9092',
+ 'properties.group.id'='testGroup',
+ 'format'='csv',
+ 'csv.field-delimiter'='|'
+);
+```
+
+With ``prod_lineitem`` stored in Hive, you can now write a query that will enrich the incoming stream with static data kept in Postgres. To illustrate how this works, let's calculate the item prices based on the current currency rates:
+
+```sql
+USE CATALOG postgres;
+SELECT
+ l_proctime AS `querytime`,
+ l_orderkey AS `order`,
+ l_linenumber AS `linenumber`,
+ l_currency AS `currency`,
+ rs_rate AS `cur_rate`,
+ (l_extendedprice * (1 - l_discount) * (1 + l_tax)) / rs_rate AS `open_in_euro`
+FROM hive.`default`.prod_lineitem
+JOIN prod_rates FOR SYSTEM_TIME AS OF l_proctime ON rs_symbol = l_currency
+WHERE
+ l_linestatus = 'O';
+```
+
+The query above uses a `SYSTEM AS OF` [clause]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/streaming/temporal_tables.html#temporal-table) for executing a temporal join. If you'd like to learn more about the different kind of joins you can do in Flink I highly encourage you to check [this documentation page]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/sql/queries.html#joins).
+
+## Conclusion
+
+Catalogs can be extremely powerful when building data platforms aimed at reusing the work of different teams in an organization. Centralizing the metadata is a common practice for improving productivity, security, and compliance when working with data.
+
+Flink provides flexible metadata management capabilities, that aim at reducing the cumbersome, repetitive work needed before querying the data such as defining schemas, connection properties etc. As of version 1.11, Flink provides a native, comprehensive integration with Hive Metastore and a read-only version for Postgres catalogs.
+
+You can get started with Flink and catalogs by reading [the docs]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/catalogs.html). If you want to play around with Flink SQL (e.g. try out how catalogs work in Flink yourself), you can check [this demo](https://github.com/fhueske/flink-sql-demo) prepared by our colleagues Fabian and Timo — it runs in a dockerized environment, and we used it for the examples in this blog post.
diff --git a/docs/content.tr/posts/2020-07-28-flink-sql-demo-building-e2e-streaming-application.md b/docs/content.tr/posts/2020-07-28-flink-sql-demo-building-e2e-streaming-application.md
new file mode 100644
index 0000000000..b8d58fbee3
--- /dev/null
+++ b/docs/content.tr/posts/2020-07-28-flink-sql-demo-building-e2e-streaming-application.md
@@ -0,0 +1,309 @@
+---
+authors:
+- jark: null
+ name: Jark Wu
+ twitter: JarkWu
+date: "2020-07-28T12:00:00Z"
+excerpt: Apache Flink 1.11 has released many exciting new features, including many
+ developments in Flink SQL which is evolving at a fast pace. This article takes a
+ closer look at how to quickly build streaming applications with Flink SQL from a
+ practical point of view.
+title: 'Flink SQL Demo: Building an End-to-End Streaming Application'
+aliases:
+- /2020/07/28/flink-sql-demo-building-e2e-streaming-application.html
+---
+
+Apache Flink 1.11 has released many exciting new features, including many developments in Flink SQL which is evolving at a fast pace. This article takes a closer look at how to quickly build streaming applications with Flink SQL from a practical point of view.
+
+In the following sections, we describe how to integrate Kafka, MySQL, Elasticsearch, and Kibana with Flink SQL to analyze e-commerce user behavior in real-time. All exercises in this blogpost are performed in the Flink SQL CLI, and the entire process uses standard SQL syntax, without a single line of Java/Scala code or IDE installation. The final result of this demo is shown in the following figure:
+
+
+
+
+
+
+# Preparation
+
+Prepare a Linux or MacOS computer with Docker installed.
+
+## Starting the Demo Environment
+
+The components required in this demo are all managed in containers, so we will use `docker-compose` to start them. First, download the `docker-compose.yml` file that defines the demo environment, for example by running the following commands:
+
+```
+mkdir flink-sql-demo; cd flink-sql-demo;
+wget https://raw.githubusercontent.com/wuchong/flink-sql-demo/v1.11-EN/docker-compose.yml
+```
+
+The Docker Compose environment consists of the following containers:
+
+- **Flink SQL CLI:** used to submit queries and visualize their results.
+- **Flink Cluster:** a Flink JobManager and a Flink TaskManager container to execute queries.
+- **MySQL:** MySQL 5.7 and a pre-populated `category` table in the database. The `category` table will be joined with data in Kafka to enrich the real-time data.
+- **Kafka:** mainly used as a data source. The DataGen component automatically writes data into a Kafka topic.
+- **Zookeeper:** this component is required by Kafka.
+- **Elasticsearch:** mainly used as a data sink.
+- **Kibana:** used to visualize the data in Elasticsearch.
+- **DataGen:** the data generator. After the container is started, user behavior data is automatically generated and sent to the Kafka topic. By default, 2000 data entries are generated each second for about 1.5 hours. You can modify DataGen's `speedup` parameter in `docker-compose.yml` to adjust the generation rate (which takes effect after Docker Compose is restarted).
+
+
+ Note
+Before starting the containers, we recommend configuring Docker so that sufficient resources are available and the environment does not become unresponsive. We suggest running Docker at 3-4 GB memory and 3-4 CPU cores.
+
+
+To start all containers, run the following command in the directory that contains the `docker-compose.yml` file.
+
+```
+docker-compose up -d
+```
+
+This command automatically starts all the containers defined in the Docker Compose configuration in a detached mode. Run `docker ps` to check whether the 9 containers are running properly. You can also visit [http://localhost:5601/](http://localhost:5601/) to see if Kibana is running normally.
+
+Don’t forget to run the following command to stop all containers after you finished the tutorial:
+
+```
+docker-compose down
+```
+
+## Entering the Flink SQL CLI client
+
+To enter the SQL CLI client run:
+
+```bash
+docker-compose exec sql-client ./sql-client.sh
+```
+
+The command starts the SQL CLI client in the container.
+You should see the welcome screen of the CLI client.
+
+
+
+
+
+
+## Creating a Kafka table using DDL
+
+The DataGen container continuously writes events into the Kafka `user_behavior` topic. This data contains the user behavior on the day of November 27, 2017 (behaviors include “click”, “like”, “purchase” and “add to shopping cart” events). Each row represents a user behavior event, with the user ID, product ID, product category ID, event type, and timestamp in JSON format. Note that the dataset is from the [Alibaba Cloud Tianchi public dataset](https://tianchi.aliyun.com/dataset/dataDetail?dataId=649).
+
+In the directory that contains `docker-compose.yml`, run the following command to view the first 10 data entries generated in the Kafka topic:
+
+```
+docker-compose exec kafka bash -c 'kafka-console-consumer.sh --topic user_behavior --bootstrap-server kafka:9094 --from-beginning --max-messages 10'
+
+{"user_id": "952483", "item_id":"310884", "category_id": "4580532", "behavior": "pv", "ts": "2017-11-27T00:00:00Z"}
+{"user_id": "794777", "item_id":"5119439", "category_id": "982926", "behavior": "pv", "ts": "2017-11-27T00:00:00Z"}
+...
+```
+
+In order to make the events in the Kafka topic accessible to Flink SQL, we run the following DDL statement in SQL CLI to create a table that connects to the topic in the Kafka cluster:
+
+```sql
+CREATE TABLE user_behavior (
+ user_id BIGINT,
+ item_id BIGINT,
+ category_id BIGINT,
+ behavior STRING,
+ ts TIMESTAMP(3),
+ proctime AS PROCTIME(), -- generates processing-time attribute using computed column
+ WATERMARK FOR ts AS ts - INTERVAL '5' SECOND -- defines watermark on ts column, marks ts as event-time attribute
+) WITH (
+ 'connector' = 'kafka', -- using kafka connector
+ 'topic' = 'user_behavior', -- kafka topic
+ 'scan.startup.mode' = 'earliest-offset', -- reading from the beginning
+ 'properties.bootstrap.servers' = 'kafka:9094', -- kafka broker address
+ 'format' = 'json' -- the data format is json
+);
+```
+
+The above snippet declares five fields based on the data format. In addition, it uses the computed column syntax and built-in `PROCTIME()` function to declare a virtual column that generates the processing-time attribute. It also uses the `WATERMARK` syntax to declare the watermark strategy on the `ts` field (tolerate 5-seconds out-of-order). Therefore, the `ts` field becomes an event-time attribute. For more information about time attributes and DDL syntax, see the following official documents:
+
+- [Time attributes in Flink’s Table API & SQL]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/streaming/time_attributes.html)
+- [DDL Syntax in Flink SQL]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/sql/create.html#create-table)
+
+After creating the `user_behavior` table in the SQL CLI, run `SHOW TABLES;` and `DESCRIBE user_behavior;` to see registered tables and table details. Also, run the command `SELECT * FROM user_behavior;` directly in the SQL CLI to preview the data (press `q` to exit).
+
+Next, we discover more about Flink SQL through three real-world scenarios.
+
+# Hourly Trading Volume
+
+## Creating an Elasticsearch table using DDL
+
+Let’s create an Elasticsearch result table in the SQL CLI. We need two columns in this case: `hour_of_day` and `buy_cnt` (trading volume).
+
+```sql
+CREATE TABLE buy_cnt_per_hour (
+ hour_of_day BIGINT,
+ buy_cnt BIGINT
+) WITH (
+ 'connector' = 'elasticsearch-7', -- using elasticsearch connector
+ 'hosts' = 'http://elasticsearch:9200', -- elasticsearch address
+ 'index' = 'buy_cnt_per_hour' -- elasticsearch index name, similar to database table name
+);
+```
+
+There is no need to create the `buy_cnt_per_hour` index in Elasticsearch in advance since Elasticsearch will automatically create the index if it does not exist.
+
+## Submitting a Query
+
+The hourly trading volume is the number of "buy" behaviors completed each hour. Therefore, we can use a `TUMBLE` window function to assign data into hourly windows. Then, we count the number of “buy” records in each window. To implement this, we can filter out the "buy" data first and then apply `COUNT(*)`.
+
+```sql
+INSERT INTO buy_cnt_per_hour
+SELECT HOUR(TUMBLE_START(ts, INTERVAL '1' HOUR)), COUNT(*)
+FROM user_behavior
+WHERE behavior = 'buy'
+GROUP BY TUMBLE(ts, INTERVAL '1' HOUR);
+```
+
+Here, we use the built-in `HOUR` function to extract the value for each hour in the day from a `TIMESTAMP` column. Use `INSERT INTO` to start a Flink SQL job that continuously writes results into the Elasticsearch `buy_cnt_per_hour` index. The Elasticearch result table can be seen as a materialized view of the query. You can find more information about Flink’s window aggregation in the [Apache Flink documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/sql/queries.html#group-windows).
+
+After running the previous query in the Flink SQL CLI, we can observe the submitted task on the [Flink Web UI](http://localhost:8081). This task is a streaming task and therefore runs continuously.
+
+
+
+
+
+
+## Using Kibana to Visualize Results
+
+Access Kibana at [http://localhost:5601](http://localhost:5601). First, configure an index pattern by clicking "Management" in the left-side toolbar and find "Index Patterns". Next, click "Create Index Pattern" and enter the full index name `buy_cnt_per_hour` to create the index pattern. After creating the index pattern, we can explore data in Kibana.
+
+
+ Note
+Since we are using the TUMBLE window of one hour here, it might take about four minutes between the time that containers started and until the first row is emitted. Until then the index does not exist and Kibana is unable to find the index.
+
+
+Click "Discover" in the left-side toolbar. Kibana lists the content of the created index.
+
+
+
+
+
+
+Next, create a dashboard to display various views. Click "Dashboard" on the left side of the page to create a dashboard named "User Behavior Analysis". Then, click "Create New" to create a new view. Select "Area" (area graph), then select the `buy_cnt_per_hour` index, and draw the trading volume area chart as illustrated in the configuration on the left side of the following diagram. Apply the changes by clicking the “▶” play button. Then, save it as "Hourly Trading Volume".
+
+
+
+
+
+
+You can see that during the early morning hours the number of transactions have the lowest value for the entire day.
+
+As real-time data is added into the indices, you can enable auto-refresh in Kibana to see real-time visualization changes and updates. You can do so by clicking the time picker and entering a refresh interval (e.g. 3 seconds) in the “Refresh every” field.
+
+# Cumulative number of Unique Visitors every 10-min
+
+Another interesting visualization is the cumulative number of unique visitors (UV). For example, the number of UV at 10:00 represents the total number of UV from 00:00 to 10:00. Therefore, the curve is monotonically increasing.
+
+Let’s create another Elasticsearch table in the SQL CLI to store the UV results. This table contains 3 columns: date, time and cumulative UVs.
+The `date_str` and `time_str` column are defined as primary key, Elasticsearch sink will use them to calculate the document ID and work in upsert mode to update UV values under the document ID.
+
+```sql
+CREATE TABLE cumulative_uv (
+ date_str STRING,
+ time_str STRING,
+ uv BIGINT,
+ PRIMARY KEY (date_str, time_str) NOT ENFORCED
+) WITH (
+ 'connector' = 'elasticsearch-7',
+ 'hosts' = 'http://elasticsearch:9200',
+ 'index' = 'cumulative_uv'
+);
+```
+
+We can extract the date and time using `DATE_FORMAT` function based on the `ts` field. As the section title describes, we only need to report every 10 minutes. So, we can use `SUBSTR` and the string concat function `||` to convert the time value into a 10-minute interval time string, such as `12:00`, `12:10`.
+Next, we group data by `date_str` and perform a `COUNT DISTINCT` aggregation on `user_id` to get the current cumulative UV in this day. Additionally, we perform a `MAX` aggregation on `time_str` field to get the current stream time: the maximum event time observed so far.
+As the maximum time is also a part of the primary key of the sink, the final result is that we will insert a new point into the elasticsearch every 10 minute. And every latest point will be updated continuously until the next 10-minute point is generated.
+
+```sql
+INSERT INTO cumulative_uv
+SELECT date_str, MAX(time_str), COUNT(DISTINCT user_id) as uv
+FROM (
+ SELECT
+ DATE_FORMAT(ts, 'yyyy-MM-dd') as date_str,
+ SUBSTR(DATE_FORMAT(ts, 'HH:mm'),1,4) || '0' as time_str,
+ user_id
+ FROM user_behavior)
+GROUP BY date_str;
+```
+
+After submitting this query, we create a `cumulative_uv` index pattern in Kibana. We then create a "Line" (line graph) on the dashboard, by selecting the `cumulative_uv` index, and drawing the cumulative UV curve according to the configuration on the left side of the following figure before finally saving the curve.
+
+
+
+
+
+
+# Top Categories
+
+The last visualization represents the category rankings to inform us on the most popular categories in our e-commerce site. Since our data source offers events for more than 5,000 categories without providing any additional significance to our analytics, we would like to reduce it so that it only includes the top-level categories. We will use the data in our MySQL database by joining it as a dimension table with our Kafka events to map sub-categories to top-level categories.
+
+Create a table in the SQL CLI to make the data in MySQL accessible to Flink SQL.
+
+```sql
+CREATE TABLE category_dim (
+ sub_category_id BIGINT,
+ parent_category_name STRING
+) WITH (
+ 'connector' = 'jdbc',
+ 'url' = 'jdbc:mysql://mysql:3306/flink',
+ 'table-name' = 'category',
+ 'username' = 'root',
+ 'password' = '123456',
+ 'lookup.cache.max-rows' = '5000',
+ 'lookup.cache.ttl' = '10min'
+);
+```
+
+The underlying JDBC connector implements the `LookupTableSource` interface, so the created JDBC table `category_dim` can be used as a temporal table (i.e. lookup table) out-of-the-box in the data enrichment.
+
+In addition, create an Elasticsearch table to store the category statistics.
+
+```sql
+CREATE TABLE top_category (
+ category_name STRING PRIMARY KEY NOT ENFORCED,
+ buy_cnt BIGINT
+) WITH (
+ 'connector' = 'elasticsearch-7',
+ 'hosts' = 'http://elasticsearch:9200',
+ 'index' = 'top_category'
+);
+```
+
+In order to enrich the category names, we use Flink SQL’s temporal table joins to join a dimension table. You can access more information about [temporal joins]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/table/streaming/joins.html#join-with-a-temporal-table) in the Flink documentation.
+
+Additionally, we use the `CREATE VIEW` syntax to register the query as a logical view, allowing us to easily reference this query in subsequent queries and simplify nested queries. Please note that creating a logical view does not trigger the execution of the job and the view results are not persisted. Therefore, this statement is lightweight and does not have additional overhead.
+
+```sql
+CREATE VIEW rich_user_behavior AS
+SELECT U.user_id, U.item_id, U.behavior, C.parent_category_name as category_name
+FROM user_behavior AS U LEFT JOIN category_dim FOR SYSTEM_TIME AS OF U.proctime AS C
+ON U.category_id = C.sub_category_id;
+```
+
+Finally, we group the dimensional table by category name to count the number of `buy` events and write the result to Elasticsearch’s `top_category` index.
+
+```sql
+INSERT INTO top_category
+SELECT category_name, COUNT(*) buy_cnt
+FROM rich_user_behavior
+WHERE behavior = 'buy'
+GROUP BY category_name;
+```
+
+After submitting the query, we create a `top_category` index pattern in Kibana. We then create a "Horizontal Bar" (bar graph) on the dashboard, by selecting the `top_category` index and drawing the category ranking according to the configuration on the left side of the following diagram before finally saving the list.
+
+
+
+
+
+
+As illustrated in the diagram, the categories of clothing and shoes exceed by far other categories on the e-commerce website.
+
+
+
+We have now implemented three practical applications and created charts for them. We can now return to the dashboard page and drag-and-drop each view to give our dashboard a more formal and intuitive style, as illustrated in the beginning of the blogpost. Of course, Kibana also provides a rich set of graphics and visualization features, and the user_behavior logs contain a lot more interesting information to explore. Using Flink SQL, you can analyze data in more dimensions, while using Kibana allows you to display more views and observe real-time changes in its charts!
+
+# Summary
+
+In the previous sections, we described how to use Flink SQL to integrate Kafka, MySQL, Elasticsearch, and Kibana to quickly build a real-time analytics application. The entire process can be completed using standard SQL syntax, without a line of Java or Scala code. We hope that this article provides some clear and practical examples of the convenience and power of Flink SQL, featuring an easy connection to various external systems, native support for event time and out-of-order handling, dimension table joins and a wide range of built-in functions. We hope you have fun following the examples in this blogpost!
diff --git a/docs/content.tr/posts/2020-07-29-community-update.md b/docs/content.tr/posts/2020-07-29-community-update.md
new file mode 100644
index 0000000000..177c122a5a
--- /dev/null
+++ b/docs/content.tr/posts/2020-07-29-community-update.md
@@ -0,0 +1,209 @@
+---
+authors:
+- morsapaes: null
+ name: Marta Paes
+ twitter: morsapaes
+date: "2020-07-29T08:00:00Z"
+excerpt: As July draws to an end, we look back at a monthful of activity in the Flink
+ community, including two releases (!) and some work around improving the first-time
+ contribution experience in the project. Also, events are starting to pick up again,
+ so we've put together a list of some great events you can (virtually) attend in
+ August!
+title: Flink Community Update - July'20
+aliases:
+- /news/2020/07/27/community-update.html
+---
+
+As July draws to an end, we look back at a monthful of activity in the Flink community, including two releases (!) and some work around improving the first-time contribution experience in the project.
+
+Also, events are starting to pick up again, so we've put together a list of some great ones you can (virtually) attend in August!
+
+# The Past Month in Flink
+
+## Flink Releases
+
+### Flink 1.11
+
+A couple of weeks ago, Flink 1.11 was announced in what was (again) the biggest Flink release to date (_see ["A Look Into the Evolution of Flink Releases"](#a-look-into-the-evolution-of-flink-releases)_)! The new release brought significant improvements to usability as well as new features to Flink users across the API stack. Some highlights of Flink 1.11 are:
+
+ * Unaligned checkpoints to cope with high backpressure scenarios;
+
+ * The new source API, that simplifies and unifies the implementation of (custom) sources;
+
+ * Support for Change Data Capture (CDC) and other common use cases in the Table API/SQL;
+
+ * Pandas UDFs and other performance optimizations in PyFlink, making it more powerful for data science and ML workloads.
+
+For a more detailed look into the release, you can recap the [announcement blogpost](https://flink.apache.org/news/2020/07/06/release-1.11.0.html) and join the upcoming meetup on [“What’s new in Flink 1.11?”](https://www.meetup.com/seattle-flink/events/271922632/), where you’ll be able to ask anything release-related to Aljoscha Krettek (Flink PMC Member). The community has also been working on a series of blogposts that deep-dive into the most significant features and improvements in 1.11, so keep an eye on the [Flink blog](https://flink.apache.org/blog/)!
+
+### Flink 1.11.1
+
+Shortly after releasing Flink 1.11, the community announced the first patch version to cover some outstanding issues in the major release. This version is **particularly important for users of the Table API/SQL**, as it addresses known limitations that affect the usability of new features like changelog sources and support for JDBC catalogs.
+
+You can find a detailed list with all the improvements and bugfixes that went into Flink 1.11.1 in the [announcement blogpost](https://flink.apache.org/news/2020/07/21/release-1.11.1.html).
+
+
+
+## Gearing up for Flink 1.12
+
+The Flink 1.12 release cycle has been kicked-off last week and a discussion about what features will go into the upcoming release is underway in [this @dev Mailing List thread](https://lists.apache.org/thread.html/rb01160c7c9c26304a7665f9a252d4ed1583173620df307015c095fcf%40%3Cdev.flink.apache.org%3E). While we wait for more of these ideas to turn into proposals and JIRA issues, here are some recent FLIPs that are already being discussed in the Flink community:
+
+
+
+
+ FLIP
+
+
+
+
+
+ FLIP-130
+
+ Support Python DataStream API
+ Python support in Flink has so far been bounded to the Table API/SQL. These APIs are high-level and convenient, but have some limitations for more complex stream processing use cases. To expand the usability of PyFlink to a broader set of use cases, FLIP-130 proposes to support it also in the DataStream API, starting with stateless operations.
+
+
+
+
+ FLIP-132
+
+ Temporal Table DDL
+ Flink SQL users can't currently create temporal tables using SQL DDL, which forces them to change context frequently for use cases that require them. FLIP-132 proposes to extend the DDL syntax to support temporal tables, which in turn will allow to also bring temporal joins with changelog sources to Flink SQL.
+
+
+
+
+
+
+
+
+## New Committers and PMC Members
+
+The Apache Flink community has welcomed **2 new PMC Members** since the last update. Congratulations!
+
+### New PMC Members
+
+
+
+
+
+# The Bigger Picture
+
+## A Look Into the Evolution of Flink Releases
+
+It’s [been a while](https://flink.apache.org/news/2020/04/01/community-update.html#a-look-into-the-flink-repository) since we had a look at community numbers, so this time we’d like to shed some light on the evolution of contributors and, well, work across releases. Let’s have a look at some _git_ data:
+
+
+
+
+
+
+
+
+
+
+
+
+
+If we consider Flink 1.8 (Apr. 2019) as the baseline, the Flink community more than **tripled** the number of implemented and/or resolved issues in a single release with the support of an **additional ~100 contributors** in Flink 1.11. This is pretty impressive on its own, and even more so if you consider that Flink contributors are distributed around the globe, working across different locations and timezones!
+
+
+
+## First-time Contributor Guide
+
+Flink has an extensive guide for [code and non-code contributions](https://flink.apache.org/contributing/how-to-contribute.html) that helps new community members navigate the project and get familiar with existing contribution guidelines. In particular for code contributions, knowing where to start can be difficult, given the sheer size of the Flink codebase and the pace of development of the project.
+
+To better guide new contributors, a brief section was added to the guide on [how to look for what to contribute](https://flink.apache.org/contributing/contribute-code.html#looking-for-what-to-contribute) and the [_starter_ label](https://issues.apache.org/jira/browse/FLINK-18704?filter=12349196) has been revived in Jira to highlight issues that are suitable for first-time contributors.
+
+
+
Note
+As a reminder, you no longer need to ask for contributor permissions to start contributing to Flink. Once you’ve found something you’d like to work on, read the
contribution guide carefully and reach out to a Flink Committer, who will be able to help you get started.
+
+
+## Replacing “charged” words in the Flink repo
+
+The community is working on gradually replacing words that are outdated and carry a negative connotation in the Flink codebase, such as “master/slave” and “whitelist/blacklist”. The progress of this work can be tracked in [FLINK-18209](https://issues.apache.org/jira/browse/FLINK-18209).
+
+
+
+# Upcoming Events (and More!)
+
+We're happy to see the "high season" of virtual events approaching, with a lot of great conferences taking place in the coming month, as well as some meetups. Here, we highlight some of the Flink talks happening in those events, but we recommend checking out the complete event programs!
+
+As usual, we also leave you with some resources to read and explore.
+
+
+
+
+ Category
+
+
+
+
+
+ Events
+
+
+
+
+
+
+
+
+ Blogposts
+
+
+
+ Flink Packages
+
+
+
+
+
+
+
+
+If you’d like to keep a closer eye on what’s happening in the community, subscribe to the Flink [@community mailing list](https://flink.apache.org/community.html#mailing-lists) to get fine-grained weekly updates, upcoming event announcements and more.
diff --git a/docs/content.tr/posts/2020-07-30-demo-fraud-detection-3.md b/docs/content.tr/posts/2020-07-30-demo-fraud-detection-3.md
new file mode 100644
index 0000000000..957622d644
--- /dev/null
+++ b/docs/content.tr/posts/2020-07-30-demo-fraud-detection-3.md
@@ -0,0 +1,661 @@
+---
+authors:
+- alex: null
+ name: Alexander Fedulov
+ twitter: alex_fedulov
+date: "2020-07-30T12:00:00Z"
+excerpt: In this series of blog posts you will learn about powerful Flink patterns
+ for building streaming applications.
+title: 'Advanced Flink Application Patterns Vol.3: Custom Window Processing'
+aliases:
+- /news/2020/07/30/demo-fraud-detection-3.html
+---
+
+
+
+## Introduction
+
+In the previous articles of the series, we described how you can achieve
+flexible stream partitioning based on dynamically-updated configurations
+(a set of fraud-detection rules) and how you can utilize Flink\'s
+Broadcast mechanism to distribute processing configuration at runtime
+among the relevant operators.
+
+Following up directly where we left the discussion of the end-to-end
+solution last time, in this article we will describe how you can use the
+\"Swiss knife\" of Flink - the [*Process Function*]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/stream/operators/process_function.html) to create an
+implementation that is tailor-made to match your streaming business
+logic requirements. Our discussion will continue in the context of the
+[Fraud Detection engine](/news/2020/01/15/demo-fraud-detection.html#fraud-detection-demo). We will also demonstrate how you can
+implement your own **custom replacement for time windows** for cases
+where the out-of-the-box windowing available from the DataStream API
+does not satisfy your requirements. In particular, we will look at the
+trade-offs that you can make when designing a solution which requires
+low-latency reactions to individual events.
+
+This article will describe some high-level concepts that can be applied
+independently, but it is recommended that you review the material in
+[part one](/news/2020/01/15/demo-fraud-detection.html) and
+[part two](/news/2020/03/24/demo-fraud-detection-2.html) of the series as well as checkout the [code
+base](https://github.com/afedulov/fraud-detection-demo) in order to make
+it easier to follow along.
+
+## ProcessFunction as a "Window"
+
+### Low Latency
+
+Let's start with a reminder of the type of fraud detection rule that we
+would like to support:
+
+*"Whenever the **sum** of **payments** from the same **payer** to the
+same **beneficiary** within **a 24 hour
+period** is **greater** than **200 000 \$** - trigger an alert."*
+
+In other words, given a stream of transactions partitioned by a key that
+combines the payer and the beneficiary fields, we would like to look
+back in time and determine, for each incoming transaction, if the sum of
+all previous payments between the two specific participants exceeds the
+defined threshold. In effect, the computation window is always moved
+along to the position of the last observed event for a particular data
+partitioning key.
+
+
+
+
+Figure 1: Time Windows
+
+
+
+
+One of the common key requirements for a fraud detection system is *low
+response time*. The sooner the fraudulent action gets detected, the
+higher the chances that it can be blocked and its negative consequences
+mitigated. This requirement is especially prominent in the financial
+domain, where you have one important constraint - any time spent
+evaluating a fraud detection model is time that a law-abiding user of
+your system will spend waiting for a response. Swiftness of processing
+often becomes a competitive advantage between various payment systems
+and the time limit for producing an alert could lie as low as *300-500
+ms*. This is all the time you get from the moment of ingestion of a
+transaction event into a fraud detection system until an alert has to
+become available to downstream systems.
+
+As you might know, Flink provides a powerful [Window
+API]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/stream/operators/windows.html)
+that is applicable for a wide range of use cases. However, if you go
+over all of the available types of supported windows, you will realize
+that none of them exactly match our main requirement for this use case -
+the low-latency evaluation of *each* incoming transaction. There is
+no type of window in Flink that can express the *"x minutes/hours/days
+back from the current event "* semantic. In the Window API, events
+fall into windows (as defined by the window
+[assigners]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/stream/operators/windows.html#window-assigners)),
+but they cannot themselves individually control the creation and
+evaluation of windows\*. As described above, our goal for the fraud
+detection engine is to achieve immediate evaluation of the previous
+relevant data points as soon as the new event is received. This raises
+the question of feasibility of applying the Window API in this case. The Window API offers some options for defining custom triggers, evictors, and window assigners, which may get to the required result. However, it is usually difficult to get this right (and easy to break). Moreover, this approach does not provide access to broadcast state, which is required for implementing dynamic reconfiguration of business rules.
+
+\*) apart from the session windows, but they are limited to assignments
+based on the session [gaps]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/stream/operators/windows.html#session-windows)
+
+
+
+
+Figure 2: Evaluation Delays
+
+
+
+Let's take an example of using a [sliding
+window]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/stream/operators/windows.html#sliding-windows)
+from Flink's Window API. Using sliding windows with the slide of *S*
+translates into an expected value of evaluation delay equal to *S/2.*
+This means that you would need to define a window slide of 600-1000 ms
+to fulfill the low-latency requirement of 300-500 ms delay, even before
+taking any actual computation time into account. The fact that Flink
+stores a separate window state for each sliding window pane renders this
+approach unfeasible under any moderately high load conditions.
+
+In order to satisfy the requirements, we need to create our own
+low-latency window implementation. Luckily, Flink gives us all the tools
+required to do so. `ProcessFunction` is a low-level, but powerful
+building block in Flink\'s API. It has a simple contract:
+
+```java
+public class SomeProcessFunction extends KeyedProcessFunction {
+
+ public void processElement(InputType event, Context ctx, Collector out){}
+
+ public void onTimer(long timestamp, OnTimerContext ctx, Collector out) {}
+
+ public void open(Configuration parameters){}
+}
+```
+
+- `processElement()` receives input events one by one. You can react to
+ each input by producing one or more output events to the next
+ operator by calling `out.collect(someOutput)`. You can also pass data
+ to a [side
+ output]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/stream/side_output.html)
+ or ignore a particular input altogether.
+
+- `onTimer()` is called by Flink when a previously-registered timer
+ fires. Both event time and processing time timers are supported.
+
+- `open()` is equivalent to a constructor. It is called inside of the
+ [TaskManager's]({{< param DocsBaseUrl >}}flink-docs-release-1.11/concepts/glossary.html#flink-taskmanager)
+ JVM, and is used for initialization, such as registering
+ Flink-managed state. It is also the right place to initialize fields
+ that are not serializable and cannot be transferred from the
+ JobManager's JVM.
+
+Most importantly, `ProcessFunction` also has access to the fault-tolerant
+state, handled by Flink. This combination, together with Flink\'s
+message processing and delivery guarantees, makes it possible to build
+resilient event-driven applications with almost arbitrarily
+sophisticated business logic. This includes creation and processing of
+custom windows with state.
+
+### Implementation
+
+#### State and Clean-up
+
+In order to be able to process time windows, we need to keep track of
+data belonging to the window inside of our program. To ensure that this
+data is fault-tolerant and can survive failures in a distributed system,
+we should store it inside of Flink-managed state. As the time
+progresses, we do not need to keep all previous transactions. According
+to the sample rule, all events that are older than 24 hours become
+irrelevant. We are looking at a window of data that constantly moves and
+where stale transactions need to be constantly moved out of scope (in
+other words, cleaned up from state).
+
+
+
+
+
+Figure 3: Window Clean-up
+
+
+
+
+We will
+[use]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/stream/state/state.html#using-keyed-state)
+`MapState` to store the individual events of the window. In order to allow
+efficient clean-up of the out-of-scope events, we will utilize event
+timestamps as the `MapState` keys.
+
+In a general case, we have to take into account the fact that there
+might be different events with exactly the same timestamp, therefore
+instead of individual Transaction per key(timestamp) we will store sets.
+
+```java
+MapState> windowState;
+```
+
+
+
Side Note
+when any Flink-managed state is used inside a
+`KeyedProcessFunction`, the data returned by the `state.value()` call is
+automatically scoped by the key of the *currently-processed event*
+- see Figure 4. If `MapState` is used, the same principle applies, with
+the difference that a `Map` is returned instead of `MyObject`. If you are
+compelled to do something like
+`mapState.value().get(inputEvent.getKey())`, you should probably be using
+`ValueState` instead of the `MapState`. As we want to store *multiple values
+per event key*, in our case, `MapState` is the right choice.
+
+
+
+
+
+
+Figure 4: Keyed State Scoping
+
+
+
+
+
+As described in the [first blog of the series](/news/2020/01/15/demo-fraud-detection.html), we are dispatching events based on the keys
+specified in the active fraud detection rules. Multiple distinct rules
+can be based on the same grouping key. This means that our alerting
+function can potentially receive transactions scoped by the same key
+(e.g. `{payerId=25;beneficiaryId=12}`), but destined to be evaluated
+according to different rules, which implies potentially different
+lengths of the time windows. This raises the question of how can we best
+store fault-tolerant window state within the `KeyedProcessFunction`. One
+approach would be to create and manage separate `MapStates` per rule. Such
+an approach, however, would be wasteful - we would separately hold state
+for overlapping time windows, and therefore unnecessarily store
+duplicate events. A better approach is to always store just enough data
+to be able to estimate all currently active rules which are scoped by
+the same key. In order to achieve that, whenever a new rule is added, we
+will determine if its time window has the largest span and store it in
+the broadcast state under the special reserved `WIDEST_RULE_KEY`. This
+information will later be used during the state clean-up procedure, as
+described later in this section.
+
+```java
+@Override
+public void processBroadcastElement(Rule rule, Context ctx, Collector out){
+ ...
+ updateWidestWindowRule(rule, broadcastState);
+}
+
+private void updateWidestWindowRule(Rule rule, BroadcastState broadcastState){
+ Rule widestWindowRule = broadcastState.get(WIDEST_RULE_KEY);
+
+ if (widestWindowRule == null) {
+ broadcastState.put(WIDEST_RULE_KEY, rule);
+ return;
+ }
+
+ if (widestWindowRule.getWindowMillis() < rule.getWindowMillis()) {
+ broadcastState.put(WIDEST_RULE_KEY, rule);
+ }
+}
+```
+
+Let's now look at the implementation of the main method,
+`processElement()`, in some detail.
+
+In the [previous blog post](/news/2020/01/15/demo-fraud-detection.html#dynamic-data-partitioning), we described how `DynamicKeyFunction` allowed
+us to perform dynamic data partitioning based on the `groupingKeyNames`
+parameter in the rule definition. The subsequent description is focused
+around the `DynamicAlertFunction`, which makes use of the remaining rule
+settings.
+
+
+
+
+Figure 5: Sample Rule Definition
+
+
+
+
+As described in the previous parts of the blog post
+series, our alerting process function receives events of type
+`Keyed`, where `Transaction` is the main
+"wrapped" event, String is the key (*payer \#x - beneficiary \#y* in
+Figure 1), and `Integer` is the ID of the rule that caused the dispatch of
+this event. This rule was previously [stored in the broadcast state](/news/2020/03/24/demo-fraud-detection-2.html#broadcast-state-pattern) and has to be retrieved from that state by the ID. Here is the
+outline of the implementation:
+
+```java
+public class DynamicAlertFunction
+ extends KeyedBroadcastProcessFunction<
+ String, Keyed, Rule, Alert> {
+
+ private transient MapState> windowState;
+
+ @Override
+ public void processElement(
+ Keyed value, ReadOnlyContext ctx, Collector out){
+
+ // Add Transaction to state
+ long currentEventTime = value.getWrapped().getEventTime(); // <--- (1)
+ addToStateValuesSet(windowState, currentEventTime, value.getWrapped());
+
+ // Calculate the aggregate value
+ Rule rule = ctx.getBroadcastState(Descriptors.rulesDescriptor).get(value.getId()); // <--- (2)
+ Long windowStartTimestampForEvent = rule.getWindowStartTimestampFor(currentEventTime);// <--- (3)
+
+ SimpleAccumulator aggregator = RuleHelper.getAggregator(rule); // <--- (4)
+ for (Long stateEventTime : windowState.keys()) {
+ if (isStateValueInWindow(stateEventTime, windowStartForEvent, currentEventTime)) {
+ aggregateValuesInState(stateEventTime, aggregator, rule);
+ }
+ }
+
+ // Evaluate the rule and trigger an alert if violated
+ BigDecimal aggregateResult = aggregator.getLocalValue(); // <--- (5)
+ boolean isRuleViolated = rule.apply(aggregateResult);
+ if (isRuleViolated) {
+ long decisionTime = System.currentTimeMillis();
+ out.collect(new Alert<>(rule.getRuleId(),
+ rule,
+ value.getKey(),
+ decisionTime,
+ value.getWrapped(),
+ aggregateResult));
+ }
+
+ // Register timers to ensure state cleanup
+ long cleanupTime = (currentEventTime / 1000) * 1000; // <--- (6)
+ ctx.timerService().registerEventTimeTimer(cleanupTime);
+ }
+```
+
+
+Here are the details of the steps:
+1) We first add each new event to our window state:
+
+```java
+static Set addToStateValuesSet(MapState> mapState, K key, V value)
+ throws Exception {
+ Set valuesSet = mapState.get(key);
+ if (valuesSet != null) {
+ valuesSet.add(value);
+ } else {
+ valuesSet = new HashSet<>();
+ valuesSet.add(value);
+ }
+ mapState.put(key, valuesSet);
+ return valuesSet;
+}
+```
+
+2) Next, we retrieve the previously-broadcasted rule, according to
+ which the incoming transaction needs to be evaluated.
+
+3) `getWindowStartTimestampFor` determines, given the window span defined
+ in the rule, and the current transaction timestamp, how far back in
+ time our evaluation should span.
+
+4) The aggregate value is calculated by iterating over all window state
+ entries and applying an aggregate function. It could be an *average,
+ max, min* or, as in the example rule from the beginning of this
+ section, a *sum*.
+
+```java
+private boolean isStateValueInWindow(
+ Long stateEventTime, Long windowStartForEvent, long currentEventTime) {
+ return stateEventTime >= windowStartForEvent && stateEventTime <= currentEventTime;
+}
+
+private void aggregateValuesInState(
+ Long stateEventTime, SimpleAccumulator aggregator, Rule rule) throws Exception {
+ Set inWindow = windowState.get(stateEventTime);
+ for (Transaction event : inWindow) {
+ BigDecimal aggregatedValue =
+ FieldsExtractor.getBigDecimalByName(rule.getAggregateFieldName(), event);
+ aggregator.add(aggregatedValue);
+ }
+}
+```
+
+5) Having an aggregate value, we can compare it to the threshold value
+ that is specified in the rule definition and fire an alert, if
+ necessary.
+
+6) At the end, we register a clean-up timer using
+`ctx.timerService().registerEventTimeTimer()`. This timer will be
+ responsible for removing the current transaction when it is going to
+ move out of scope.
+
+
+ Note
+Notice the rounding during timer creation. It is an important technique
+which enables a reasonable trade-off between the precision with which
+the timers will be triggered, and the number of timers being used.
+Timers are stored in Flink's fault-tolerant state, and managing them
+with millisecond-level precision can be wasteful. In our case, with this
+rounding, we will create at most one timer per key in any given second. Flink documentation provides some additional [details ]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/stream/operators/process_function.html#timer-coalescing).
+
+
+7) The `onTimer` method will trigger the clean-up of the window state.
+
+As previously described, we are always keeping as many events in the
+state as required for the evaluation of an active rule with the widest
+window span. This means that during the clean-up, we only need to remove
+the state which is out of scope of this widest window.
+
+
+
+
+Figure 6: Widest Window
+
+
+
+This is how the clean-up procedure can be implemented:
+
+```java
+@Override
+public void onTimer(final long timestamp, final OnTimerContext ctx, final Collector out)
+ throws Exception {
+
+ Rule widestWindowRule = ctx.getBroadcastState(Descriptors.rulesDescriptor).get(WIDEST_RULE_KEY);
+
+ Optional cleanupEventTimeWindow =
+ Optional.ofNullable(widestWindowRule).map(Rule::getWindowMillis);
+ Optional cleanupEventTimeThreshold =
+ cleanupEventTimeWindow.map(window -> timestamp - window);
+ // Remove events that are older than (timestamp - widestWindowSpan)ms
+ cleanupEventTimeThreshold.ifPresent(this::evictOutOfScopeElementsFromWindow);
+}
+
+private void evictOutOfScopeElementsFromWindow(Long threshold) {
+ try {
+ Iterator keys = windowState.keys().iterator();
+ while (keys.hasNext()) {
+ Long stateEventTime = keys.next();
+ if (stateEventTime < threshold) {
+ keys.remove();
+ }
+ }
+ } catch (Exception ex) {
+ throw new RuntimeException(ex);
+ }
+}
+```
+
+
+ Note
+You might be wondering why we did not use `ListState` , as we are always
+iterating over all of the values of the window state? This is actually
+an optimization for the case when `RocksDBStateBackend`
+[is used]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/state/state_backends.html#the-rocksdbstatebackend). Iterating over a `ListState` would cause all of the `Transaction`
+objects to be deserialized. Using `MapState`\'s keys iterator only causes
+deserialization of the keys (type `long`), and therefore reduces the
+computational overhead.
+
+
+This concludes the description of the implementation details. Our
+approach triggers evaluation of a time window as soon as a new
+transaction arrives. It therefore fulfills the main requirement that we
+have targeted - low delay for potentially issuing an alert. For the
+complete implementation, please have a look at
+[the project on github](https://github.com/afedulov/fraud-detection-demo).
+
+## Improvements and Optimizations
+
+What are the pros and cons of the described approach?
+
+**Pros:**
+
+- Low latency capabilities
+
+- Tailored solution with potential use-case specific optimizations
+
+- Efficient state reuse (shared state for the rules with the same key)
+
+**Cons:**
+
+- Cannot make use of potential future optimizations in the existing
+ Window API
+
+- No late event handling, which is available out of the box in the
+ Window API
+
+- Quadratic computation complexity and potentially large state
+
+Let's now look at the latter two drawbacks and see if we can address
+them.
+
+#### Late events:
+
+Processing late events poses a certain question - is it still meaningful
+to re-evaluate the window in case of a late event arrival? In case this
+is required, you would need to extend the widest window used for the
+clean-up by your maximum expected out-of-orderness. This would avoid
+having potentially incomplete time window data for such late firings
+(see Figure 7).
+
+
+
+
+Figure 7: Late Events Handling
+
+
+
+It can be argued, however, that for a use case that puts emphasis on low
+latency processing, such late triggering would be meaningless. In this
+case, we could keep track of the most recent timestamp that we have
+observed so far, and for events that do not monotonically increase this
+value, only add them to the state and skip the aggregate calculation and
+the alert triggering logic.
+
+#### Redundant Re-computations and State Size:
+
+In our described implementation we keep individual transactions in state
+and go over them to calculate the aggregate again and again on every new
+event. This is obviously not optimal in terms of wasting computational
+resources on repeated calculations.
+
+What is the main reason to keep the individual transactions in state?
+The granularity of stored events directly corresponds to the precision
+of the time window calculation. Because we store transactions
+individually, we can precisely ignore individual transactions as soon as
+they leave the exact 2592000000 ms time window (30 days in ms). At this
+point, it is worth raising the question - do we really need this
+milliseconds precision when estimating such a long time window, or is it
+OK to accept potential false positives in exceptional cases? If the
+answer for your use case is that such precision is not needed, you could
+implement additional optimization based on bucketing and
+pre-aggregation. The idea of this optimization can be broken down as
+follows:
+
+- Instead of storing individual events, create a parent class that can
+ either contain fields of a single transaction, or combined values,
+ calculated based on applying an aggregate function to a set of
+ transactions.
+
+- Instead of using timestamps in milliseconds as `MapState` keys, round
+ them to the level of "resolution" that you are willing to accept
+ (for instance, a full minute). Each entry therefore represents a
+ bucket.
+
+- Whenever a window is evaluated, append the new transaction's data to
+ the bucket aggregate instead of storing individual data points per
+ transaction.
+
+
+
+
+Figure 8: Pre-aggregation
+
+
+
+#### State Data and Serializers
+
+Another question that we can ask ourselves in order to further optimize
+the implementation is how probable is it to get different events with
+exactly the same timestamp. In the described implementation, we
+demonstrated one way of approaching this question by storing sets of
+transactions per timestamp in `MapState>`. Such
+a choice, however, might have a more significant effect on performance
+than might be anticipated. The reason is that Flink does not currently
+provide a native `Set` serializer and will enforce a fallback to the less
+efficient [Kryo
+serializer]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/types_serialization.html#general-class-types)
+instead
+([FLINK-16729](https://issues.apache.org/jira/browse/FLINK-16729)). A
+meaningful alternative strategy is to assume that, in a normal scenario,
+no two discrepant events can have exactly the same timestamp and to turn
+the window state into a `MapState` type. You can use
+[side-outputs]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/stream/side_output.html)
+to collect and monitor any unexpected occurrences which contradict your
+assumption. During performance optimizations, I generally recommend you
+to [disable the fallback to
+Kryo](https://flink.apache.org/news/2020/04/15/flink-serialization-tuning-vol-1.html#disabling-kryo)
+and verify where your application might be further optimized by ensuring
+that [more efficient
+serializers](https://flink.apache.org/news/2020/04/15/flink-serialization-tuning-vol-1.html#performance-comparison)
+are being used.
+
+
+
Tip:
+You can quickly determine which serializer is going to be
+used for your classes by setting a breakpoint and verifying the type of
+the returned TypeInformation.
+
+
+
+
+
+
+
+
+ PojoTypeInfo indicates that an efficient Flink POJO serializer will be used.
+
+
+
+
+
+ GenericTypeInfo indicates the fallback to a Kryo serializer.
+
+
+
+
+
+
+
+
+
+**Event pruning**: Instead of storing complete events and putting
+additional stress on the ser/de machinery, we can reduce individual
+events data to only relevant information. This would potentially require
+"unpacking" individual events as fields, and storing those fields into a
+generic `Map` data structure, based on the
+configurations of active rules.
+
+While this adjustment could potentially produce significant improvements
+for objects of large size, it should not be your first pick as it can
+easily turn into a premature optimization.
+
+## Summary:
+
+This article concludes the description of the implementation of the
+fraud detection engine that we started in [part one](/news/2020/01/15/demo-fraud-detection.html). In this blog
+post we demonstrated how `ProcessFunction` can be utilized to
+\"impersonate\" a window with a sophisticated custom logic. We have
+discussed the pros and cons of such approach and elaborated how custom
+use-case-specific optimizations can be applied - something that would
+not be directly possible with the Window API.
+
+The goal of this blog post was to illustrate the power and flexibility
+of Apache Flink's APIs. At the core of it are the pillars of Flink, that
+spare you, as a developer, very significant amounts of work and
+generalize well to a wide range of use cases by providing:
+
+- Efficient data exchange in a distributed cluster
+
+- Horizontal scalability via data partitioning
+
+- Fault-tolerant state with quick, local access
+
+- Convenient abstraction for working with this state, which is as simple as using a
+ local variable
+
+- Multi-threaded, parallel execution engine. `ProcessFunction` code runs
+ in a single thread, without the need for synchronization. Flink
+ handles all the parallel execution aspects and correct access to the
+ shared state, without you, as a developer, having to think about it
+ (concurrency is hard).
+
+All these aspects make it possible to build applications with Flink that
+go well beyond trivial streaming ETL use cases and enable implementation
+of arbitrarily-sophisticated, distributed event-driven applications.
+With Flink, you can rethink approaches to a wide range of use cases
+which normally would rely on using stateless parallel execution nodes
+and "pushing" the concerns of state fault tolerance to a database, an
+approach that is often destined to run into scalability issues in the
+face of ever-increasing data volumes.
diff --git a/docs/content.tr/posts/2020-08-04-pyflink-pandas-udf-support-flink.md b/docs/content.tr/posts/2020-08-04-pyflink-pandas-udf-support-flink.md
new file mode 100644
index 0000000000..5fb546f659
--- /dev/null
+++ b/docs/content.tr/posts/2020-08-04-pyflink-pandas-udf-support-flink.md
@@ -0,0 +1,243 @@
+---
+authors:
+- Jincheng: null
+ name: Jincheng Sun
+ twitter: sunjincheng121
+- markos: null
+ name: Markos Sfikas
+ twitter: MarkSfik
+date: "2020-08-04T00:00:00Z"
+excerpt: The Apache Flink community put some great effort into integrating Pandas
+ with PyFlink in the latest Flink version 1.11. Some of the added features include
+ support for Pandas UDF and the conversion between Pandas DataFrame and Table. In
+ this article, we will introduce how these functionalities work and how to use them
+ with a step-by-step example.
+title: 'PyFlink: The integration of Pandas into PyFlink'
+aliases:
+- /2020/08/04/pyflink-pandas-udf-support-flink.html
+---
+
+Python has evolved into one of the most important programming languages for many fields of data processing. So big has been Python’s popularity, that it has pretty much become the default data processing language for data scientists. On top of that, there is a plethora of Python-based data processing tools such as NumPy, Pandas, and Scikit-learn that have gained additional popularity due to their flexibility or powerful functionalities.
+
+
+
+
+
+ Pic source: VanderPlas 2017, slide 52.
+
+
+
+In an effort to meet the user needs and demands, the Flink community hopes to leverage and make better use of these tools. Along this direction, the Flink community put some great effort in integrating Pandas into PyFlink with the latest Flink version 1.11. Some of the added features include **support for Pandas UDF** and the **conversion between Pandas DataFrame and Table**. Pandas UDF not only greatly improve the execution performance of Python UDF, but also make it more convenient for users to leverage libraries such as Pandas and NumPy in Python UDF. Additionally, providing support for the conversion between Pandas DataFrame and Table enables users to switch processing engines seamlessly without the need for an intermediate connector. In the remainder of this article, we will introduce how these functionalities work and how to use them with a step-by-step example.
+
+
+ Note
+Currently, only Scalar Pandas UDFs are supported in PyFlink.
+
+
+# Pandas UDF in Flink 1.11
+
+Using scalar Python UDF was already possible in Flink 1.10 as described in a [previous article on the Flink blog](https://flink.apache.org/2020/04/09/pyflink-udf-support-flink.html). Scalar Python UDFs work based on three primary steps:
+
+ - the Java operator serializes one input row to bytes and sends them to the Python worker;
+
+ - the Python worker deserializes the input row and evaluates the Python UDF with it;
+
+ - the resulting row is serialized and sent back to the Java operator
+
+
+While providing support for Python UDFs in PyFlink greatly improved the user experience, it had some drawbacks, namely resulting in:
+
+ - High serialization/deserialization overhead
+
+ - Difficulty when leveraging popular Python libraries used by data scientists — such as Pandas or NumPy — that provide high-performance data structure and functions.
+
+
+The introduction of Pandas UDF is used to address these drawbacks. For Pandas UDF, a batch of rows is transferred between the JVM and PVM in a columnar format ([Arrow memory format](https://arrow.apache.org/docs/format/Columnar.html)). The batch of rows will be converted into a collection of Pandas Series and will be transferred to the Pandas UDF to then leverage popular Python libraries (such as Pandas, or NumPy) for the Python UDF implementation.
+
+
+
+
+
+
+The performance of vectorized UDFs is usually much higher when compared to the normal Python UDF, as the serialization/deserialization overhead is minimized by falling back to [Apache Arrow](https://arrow.apache.org/), while handling `pandas.Series` as input/output allows us to take full advantage of the Pandas and NumPy libraries, making it a popular solution to parallelize Machine Learning and other large-scale, distributed data science workloads (e.g. feature engineering, distributed model application).
+
+
+# Conversion between PyFlink Table and Pandas DataFrame
+
+Pandas DataFrame is the de-facto standard for working with tabular data in the Python community while PyFlink Table is Flink’s representation of the tabular data in Python. Enabling the conversion between PyFlink Table and Pandas DataFrame allows switching between PyFlink and Pandas seamlessly when processing data in Python. Users can process data by utilizing one execution engine and switch to a different one effortlessly. For example, in case users already have a Pandas DataFrame at hand and want to perform some expensive transformation, they can easily convert it to a PyFlink Table and leverage the power of the Flink engine. On the other hand, users can also convert a PyFlink Table to a Pandas DataFrame and perform the same transformation with the rich functionalities provided by the Pandas ecosystem.
+
+
+# Examples
+
+Using Python in Apache Flink requires installing PyFlink, which is available on [PyPI](https://pypi.org/project/apache-flink/) and can be easily installed using `pip`. Before installing PyFlink, check the working version of Python running in your system using:
+
+```bash
+$ python --version
+Python 3.7.6
+```
+
+
+ Note
+Please note that Python 3.5 or higher is required to install and run PyFlink
+
+
+```bash
+
+$ python -m pip install apache-flink
+
+```
+
+## Using Pandas UDF
+
+Pandas UDFs take `pandas.Series` as the input and return a `pandas.Series` of the same length as the output. Pandas UDFs can be used at the exact same place where non-Pandas functions are currently being utilized. To mark a UDF as a Pandas UDF, you only need to add an extra parameter udf_type="pandas" in the udf decorator:
+
+
+```python
+
+@udf(input_types=[DataTypes.STRING(), DataTypes.FLOAT()],
+ result_type=DataTypes.FLOAT(), udf_type='pandas')
+def interpolate(id, temperature):
+ # takes id: pandas.Series and temperature: pandas.Series as input
+ df = pd.DataFrame({'id': id, 'temperature': temperature})
+
+ # use interpolate() to interpolate the missing temperature
+ interpolated_df = df.groupby('id').apply(
+ lambda group: group.interpolate(limit_direction='both'))
+
+ # output temperature: pandas.Series
+ return interpolated_df['temperature']
+
+```
+
+The Pandas UDF above uses the Pandas `dataframe.interpolate()` function to interpolate the missing temperature data for each equipment id. This is a common IoT scenario whereby each equipment/device reports it’s id and temperature to be analyzed, but the temperature field may be null due to various reasons.
+With the function, you can register and use it in the same way as the [normal Python UDF](https://flink.apache.org/2020/04/09/pyflink-udf-support-flink.html). Below is a complete example of how to use the Pandas UDF in PyFlink.
+
+```python
+
+from pyflink.datastream import StreamExecutionEnvironment
+from pyflink.table import StreamTableEnvironment, DataTypes
+from pyflink.table.udf import udf
+import pandas as pd
+
+env = StreamExecutionEnvironment.get_execution_environment()
+env.set_parallelism(1)
+t_env = StreamTableEnvironment.create(env)
+t_env.get_config().get_configuration().set_boolean("python.fn-execution.memory.managed", True)
+
+@udf(input_types=[DataTypes.STRING(), DataTypes.FLOAT()],
+ result_type=DataTypes.FLOAT(), udf_type='pandas')
+def interpolate(id, temperature):
+ # takes id: pandas.Series and temperature: pandas.Series as input
+ df = pd.DataFrame({'id': id, 'temperature': temperature})
+
+ # use interpolate() to interpolate the missing temperature
+ interpolated_df = df.groupby('id').apply(
+ lambda group: group.interpolate(limit_direction='both'))
+
+ # output temperature: pandas.Series
+ return interpolated_df['temperature']
+
+t_env.register_function("interpolate", interpolate)
+
+my_source_ddl = """
+ create table mySource (
+ id INT,
+ temperature FLOAT
+ ) with (
+ 'connector.type' = 'filesystem',
+ 'format.type' = 'csv',
+ 'connector.path' = '/tmp/input'
+ )
+"""
+
+my_sink_ddl = """
+ create table mySink (
+ id INT,
+ temperature FLOAT
+ ) with (
+ 'connector.type' = 'filesystem',
+ 'format.type' = 'csv',
+ 'connector.path' = '/tmp/output'
+ )
+"""
+
+t_env.execute_sql(my_source_ddl)
+t_env.execute_sql(my_sink_ddl)
+
+t_env.from_path('mySource')\
+ .select("id, interpolate(id, temperature) as temperature") \
+ .insert_into('mySink')
+
+t_env.execute("pandas_udf_demo")
+
+```
+
+To submit the job:
+
+- Firstly, you need to prepare the input data in the "/tmp/input" file. For example,
+
+```bash
+
+$ echo -e "1,98.0\n1,\n1,100.0\n2,99.0" > /tmp/input
+
+```
+
+- Next, you can run this example on the command line,
+
+
+```bash
+
+$ python pandas_udf_demo.py
+
+```
+
+The command builds and runs the Python Table API program in a local mini-cluster. You can also submit the Python Table API program to a remote cluster using different command lines, see more details [here]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/cli.html#job-submission-examples).
+
+- Finally, you can see the execution result on the command line. As you can see, all the temperature data with an empty value has been interpolated:
+
+
+```bash
+
+$ cat /tmp/output
+1,98.0
+1,99.0
+1,100.0
+2,99.0
+
+```
+
+## Conversion between PyFlink Table and Pandas DataFrame
+
+You can use the `from_pandas()` method to create a PyFlink Table from a Pandas DataFrame or use the `to_pandas()` method to convert a PyFlink Table to a Pandas DataFrame.
+
+
+```python
+
+from pyflink.datastream import StreamExecutionEnvironment
+from pyflink.table import StreamTableEnvironment
+import pandas as pd
+import numpy as np
+
+env = StreamExecutionEnvironment.get_execution_environment()
+t_env = StreamTableEnvironment.create(env)
+
+# Create a PyFlink Table
+pdf = pd.DataFrame(np.random.rand(1000, 2))
+table = t_env.from_pandas(pdf, ["a", "b"]).filter("a > 0.5")
+
+# Convert the PyFlink Table to a Pandas DataFrame
+pdf = table.to_pandas()
+print(pdf)
+
+
+```
+
+# Conclusion & Upcoming work
+
+In this article, we introduce the integration of Pandas in Flink 1.11, including Pandas UDF and the conversion between Table and Pandas. In fact, in the latest Apache Flink release, there are many excellent features added to PyFlink, such as support of User-defined Table functions and User-defined Metrics for Python UDFs. What’s more, from Flink 1.11, you can build PyFlink with Cython support and "Cythonize" your Python UDFs to substantially improve code execution speed (up to 30x faster, compared to Python UDFs in Flink 1.10).
+
+Future work by the community will focus on adding more features and bringing additional optimizations with follow up releases. Such optimizations and additions include a Python DataStream API and more integration with the Python ecosystem, such as support for distributed Pandas in Flink. Stay tuned for more information and updates with the upcoming releases!
+
+
+
+
diff --git a/docs/content.tr/posts/2020-08-06-external-resource.md b/docs/content.tr/posts/2020-08-06-external-resource.md
new file mode 100644
index 0000000000..8e4c3c89a5
--- /dev/null
+++ b/docs/content.tr/posts/2020-08-06-external-resource.md
@@ -0,0 +1,143 @@
+---
+authors:
+- name: Yangze Guo
+ yangze: null
+date: "2020-08-06T08:00:00Z"
+excerpt: This post introduces the new External Resource Framework in Flink 1.11 and
+ take GPU as an example to show how to accelerate your workload with external resources.
+title: Accelerating your workload with GPU and other external resources
+aliases:
+- /news/2020/08/06/external-resource.html
+---
+
+Apache Flink 1.11 introduces a new [External Resource Framework]({{< param DocsBaseUrl >}}flink-docs-master/ops/external_resources.html),
+which allows you to request external resources from the underlying resource management systems (e.g., Kubernetes) and accelerate your workload with
+those resources. As Flink provides a first-party GPU plugin at the moment, we will take GPU as an example and show how it affects Flink applications
+in the AI field. Other external resources (e.g. RDMA and SSD) can also be supported [in a pluggable manner]({{< param DocsBaseUrl >}}flink-docs-master/ops/external_resources.html#implement-a-plugin-for-your-custom-resource-type).
+
+# End-to-end real-time AI with GPU
+
+Recently, AI and Machine Learning have gained additional popularity and have been widely used in various scenarios, such
+as personalized recommendation and image recognition. [Flink](https://flink.apache.org/), with the ability to support GPU
+allocation, can be used to build an end-to-end real-time AI workflow.
+
+## Why Flink
+
+Typical AI workloads fall into two categories: training and inference.
+
+
+
+
+Typical AI Workflow
+
+
+
+The training workload is usually a batch task, in which we train a model from a bounded dataset. On the other hand, the inference
+workload tends to be a streaming job. It consumes an unbounded data stream, which contains image data, for example, and uses a model
+to produce the output of predictions. Both workloads need to do data preprocessing first. Flink, as a
+[unified batch and stream processing engine](https://flink.apache.org/news/2019/02/13/unified-batch-streaming-blink.html), can be used to build an end-to-end AI workflow naturally.
+
+In many cases, the training and inference workload can benefit a lot by leveraging GPUs. [Research](https://azure.microsoft.com/en-us/blog/gpus-vs-cpus-for-deployment-of-deep-learning-models/)
+shows that CPU cluster is outperformed by GPU cluster, which is of similar cost, by about 400 percent. As training datasets
+are getting bigger and models more complex, supporting GPUs has become mandatory for running AI workloads.
+
+With the [External Resource Framework]({{< param DocsBaseUrl >}}flink-docs-master/ops/external_resources.html)
+and its [GPU plugin]({{< param DocsBaseUrl >}}flink-docs-master/ops/external_resources.html#plugin-for-gpu-resources), Flink
+can now request GPU resources from the external resource management system and expose GPU information to operators. With this
+feature, users can now easily build end-to-end training and real-time inference pipelines with GPU support on Flink.
+
+## Example: MNIST Inference with Flink
+
+We take the MNIST inference task as an example to show how to use the [External Resource Framework]({{< param DocsBaseUrl >}}flink-docs-master/ops/external_resources.html)
+and how to leverage GPUs in Flink. MNIST is a database of handwritten digits, which is usually viewed as the HelloWorld of AI.
+The goal is to recognize a 28px*28px picture of a number from 0 to 9.
+
+First, you need to set configurations for the external resource framework to enable GPU support:
+
+```bash
+external-resources: gpu
+# Define the driver factory class of gpu resource.
+external-resource.gpu.driver-factory.class: org.apache.flink.externalresource.gpu.GPUDriverFactory
+# Define the amount of gpu resource per TaskManager.
+external-resource.gpu.amount: 1
+# Enable the coordination mode if you run it in standalone mode
+external-resource.gpu.param.discovery-script.args: --enable-coordination
+
+
+# If you run it on Yarn
+external-resource.gpu.yarn.config-key: yarn.io/gpu
+# If you run it on Kubernetes
+external-resource.gpu.kubernetes.config-key: nvidia.com/gpu
+```
+
+For more details of the configuration, please refer to the [official documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/external_resources.html#configurations-1).
+
+In the MNIST inference task, we first need to read the images and do data preprocessing. You can download [training](http://yann.lecun.com/exdb/mnist/train-images-idx3-ubyte.gz)
+or [testing](http://yann.lecun.com/exdb/mnist/t10k-images-idx3-ubyte.gz) data from [this site](http://yann.lecun.com/exdb/mnist/).
+We provide a simple [MNISTReader](https://github.com/KarmaGYZ/flink-mnist/blob/master/src/main/java/org/apache/flink/MNISTReader.java).
+It will read the image data located in the provided file path and transform each image into a list of floating point numbers.
+
+Then, we need a classifier to recognize those images. A one-layer pre-trained neural network, whose prediction accuracy is 92.14%,
+is used in our classify operator. To leverage GPUs in order to accelerate the matrix-matrix multiplication, we use [JCuda](https://github.com/jcuda/jcuda)
+to call the native Cuda API. The prediction logic of the [MNISTClassifier](https://github.com/KarmaGYZ/flink-mnist/blob/master/src/main/java/org/apache/flink/MNISTClassifier.java) is shown below.
+
+```java
+class MNISTClassifier extends RichMapFunction, Integer> {
+ @Override
+ public void open(Configuration parameters) {
+ // Get the GPU information and select the first GPU.
+ final Set externalResourceInfos = getRuntimeContext().getExternalResourceInfos(resourceName);
+ final Optional firstIndexOptional = externalResourceInfos.iterator().next().getProperty("index");
+
+ // Initialize JCublas with the selected GPU
+ JCuda.cudaSetDevice(Integer.parseInt(firstIndexOptional.get()));
+ JCublas.cublasInit();
+ }
+
+ @Override
+ public Integer map(List value) {
+ // Performs multiplication using JCublas. The matrixPointer points to our pre-trained model.
+ JCublas.cublasSgemv('n', DIMENSIONS.f1, DIMENSIONS.f0, 1.0f,
+ matrixPointer, DIMENSIONS.f1, inputPointer, 1, 0.0f, outputPointer, 1);
+
+ // Read the result back from GPU.
+ JCublas.cublasGetVector(DIMENSIONS.f1, Sizeof.FLOAT, outputPointer, 1, Pointer.to(output), 1);
+ int result = 0;
+ for (int i = 0; i < DIMENSIONS.f1; ++i) {
+ result = output[i] > output[result] ? i : result;
+ }
+ return result;
+ }
+}
+```
+
+The complete MNIST inference project can be found [here](https://github.com/KarmaGYZ/flink-mnist). In this project, we simply
+print the inference result to **STDOUT**. In the actual production environment, you could also write the result to Elasticsearch or Kafka, for example.
+
+The MNIST inference task is just a simple case that shows you how the external resource framework works and what Flink can
+do with GPU support. With Flink’s open source extension [Alink](https://github.com/alibaba/Alink), which contains a lot of
+pre-built algorithms based on Flink, and [Tensorflow on Flink](https://github.com/alibaba/flink-ai-extended), some complex
+AI workloads, e.g. online learning, real-time inference service, could be easily implemented as well.
+
+# Other external resources
+
+In addition to GPU support, there are many other external resources that can be used to accelerate jobs in some specific scenarios.
+E.g. FPGA, for AI workloads, is supported by both Yarn and Kubernetes. Some low-latency network devices, like RDMA and Solarflare, also
+provide their device plugin for Kubernetes. Currently, Yarn supports GPUs and FPGAs, while the list of Kubernetes’ device plugins can be found [here](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#examples).
+
+With the external resource framework, you only need to implement a plugin that enables the operator to get the information
+for these external resources; see [Custom Plugin]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/external_resources.html#implement-a-plugin-for-your-custom-resource-type)
+for more details. If you just want to ensure that an external resource exists in the TaskManager, then you only need to find the
+configuration key of that resource in the underlying resource management system and configure the external resource framework accordingly.
+
+# Conclusion
+
+In the latest Flink release (Flink 1.11), an external resource framework has been introduced to support requesting various types of
+resources from the underlying resource management systems, and supply all the necessary information for using these resources to the
+operators. The first-party GPU plugin expands the application prospects of Flink in the AI domain. Different resource types can be supported
+in a pluggable way. You can also implement your own plugins for custom resource types.
+
+Future developments in this area include implementing operator level resource isolation and fine-grained external resource scheduling.
+The community may kick this work off once [FLIP-56](https://cwiki.apache.org/confluence/display/FLINK/FLIP-56%3A+Dynamic+Slot+Allocation)
+is finished. If you have any suggestions or questions for the community, we encourage you to sign up to the Apache Flink
+[mailing lists](https://flink.apache.org/community.html#mailing-lists) and join the discussion there.
diff --git a/docs/content.tr/posts/2020-08-18-statefun.md b/docs/content.tr/posts/2020-08-18-statefun.md
new file mode 100644
index 0000000000..36e3abd23e
--- /dev/null
+++ b/docs/content.tr/posts/2020-08-18-statefun.md
@@ -0,0 +1,188 @@
+---
+authors:
+- igal: null
+ name: Igal Shilman
+ twitter: IgalShilman
+date: "2020-08-18T08:00:00Z"
+title: Monitoring and Controlling Networks of IoT Devices with Flink Stateful Functions
+aliases:
+- /2020/08/19/statefun.html
+---
+
+In this blog post, we'll take a look at a class of use cases that is a natural fit for [Flink Stateful Functions](https://flink.apache.org/stateful-functions.html): monitoring and controlling networks of connected devices (often called the “Internet of Things” (IoT)).
+
+IoT networks are composed of many individual, but interconnected components, which makes getting some kind of high-level insight into the status, problems, or optimization opportunities in these networks not trivial. Each individual device “sees” only its own state, which means that the status of groups of devices, or even the network as a whole, is often a complex aggregation of the individual devices’ state. Diagnosing, controlling, or optimizing these groups of devices thus requires distributed logic that analyzes the "bigger picture" and then acts upon it.
+
+A powerful approach to implement this is using _[digital twins](https://en.wikipedia.org/wiki/Digital_twin)_: each device has a corresponding virtual entity (i.e. the digital twin), which also captures their relationships and interactions. The digital twins track the status of their corresponding devices and send updates to other twins, representing groups (such as geographical regions) of devices. Those, in turn, handle the logic to obtain the network's aggregated view, or this "bigger picture" we mentioned before.
+
+# Our Scenario: Datacenter Monitoring and Alerting
+
+
+
+ Fig.1 An oversimplified view of a data center.
+
+
+There are many examples of the digital twins approach in the real world, such as [smart grids of batteries](https://www.infoq.com/presentations/tesla-vpp/), [smart cities](https://www.alibabacloud.com/solutions/intelligence-brain/city), or [monitoring infrastructure software clusters](https://www.youtube.com/watch?v=9y27FJgz5-M). In this blogpost, we'll use the example of data center monitoring and alert correlation implemented with Stateful Functions.
+
+Consider a very simplified view of a data center, consisting of many thousands of commodity servers arranged in server racks. Each server rack typically contains up to 40 servers, with a ToR (Top of the Rack) network switch connected to each server. The switches from all the racks connect through a larger switch (**Fig. 1**).
+
+In this datacenter, many things can go wrong: a disk in a server can stop working, network cards can start dropping packets, or ToR switches might cease to function. The entire data center might also be affected by power supply degradation, causing servers to operate at reduced capacity. On-site engineers must be able to identify these incidents quickly and fix them promptly.
+
+Diagnosing individual server failures is rather straightforward: take a recent history of metric reports from that particular server, analyse it and pinpoint the anomaly. On the other hand, other incidents only make sense "together", because they share a common root cause. Diagnosing or predicting causes of networking degradation at a rack or datacenter level requires an aggregate view of metrics (such as package drop rates) from the individual machines and racks, and possibly some prediction model or diagnosis code that runs under certain conditions.
+
+## Monitoring a Virtual Datacenter via Digital Twins
+
+For the sake of this blog post, our oversimplified data center has some servers and racks, each with a unique ID. Each server has a metrics-collecting daemon that publishes metrics to a message queue, and there is a provisioning service that operators will use to ask for server commission- and decommissioning.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Our application will consume these server metrics and commission/decommission events, and produce server/rack/datacenter alerts. There will also be an operator consuming any alerts triggered by the monitoring system. In the next section, we'll show how this use case can be naturally modeled with Stateful Functions (StateFun).
+
+## Implementing the use case with Flink StateFun
+
+
+
+The basic building block for modeling a StateFun application is a [_stateful function_]({{< param DocsBaseUrl >}}flink-statefun-docs-release-2.1/concepts/application-building-blocks.html#stateful-functions), which has the following properties:
+
+* It has a logical unique address; and persisted, fault tolerant state, scoped to that address.
+
+* It can _react_ to messages, both internal (or, sent from other stateful functions) and external (e.g. a message from Kafka).
+
+* Invocations of a specific function are serializable, so messages sent to a specific address are **not** executed concurrently.
+
+* There can be many billions of function instances in a single StateFun cluster.
+
+To model our use case, we'll define three functions: **ServerFun**, **RackFun** and **DataCenterFun**.
+
+**ServerFun**
+
+Each physical server is represented with its _digital twin_ stateful function. This function is responsible for:
+
+1. Maintaining a sliding window of incoming metrics.
+
+2. Applying a model that decides whether or not to trigger an alert.
+
+3. Alerting if metrics are missing for too long.
+
+4. Notifying its containing **RackFun** about any open incidents.
+
+**RackFun**
+
+While the _ServerFun_ is responsible for identifying server-local incidents, we need a function that correlates incidents happening on the different servers deployed in the same rack and:
+
+1. Collects open incidents reported by the **ServerFun** functions.
+
+2. Maintains an histogram of currently opened incidents on this rack.
+
+3. Applies a correlation model to the individual incidents sent by the **ServerFun**, and reports high-level, related incidents as a single incident to the **DataCenterFun**.
+
+**DataCenterFun**
+
+This function maintains a view of incidents across different racks in our datacenter.
+
+
+
+
+
+
+
+
+
+
+
+
+
+To summarize our plan:
+
+* Leaf functions ingest raw metric data (blue lines), and apply localized logic to trigger an alert.
+
+* Intermediate functions operate on already summarized events (orange lines) and correlate them into high-level events.
+
+* A root function correlates the high-level events across the intermediate functions and into a single _healthy/not healthy_ value.
+
+## How does it really look?
+
+### ServerFun
+
+
+
+
+
+
+
+
+
+1. This section associates a behaviour for every message that the function expects to be invoked with.
+2. The `metricsHistory` buffer is our sliding window of the last 15 minutes worth of `ServerMetricReports`. Note that this buffer is configured to expire entries 15 minutes after they were written.
+3. `serverHealthState` represents the current physical server state, open incidents and so on.
+
+Let's take a look at what happens when a `ServerMetricReport` message arrives:
+
+
+
+
+
+
+
+
+
+1. Retrieve the previously computed `serverHealthState` that is kept in state.
+2. Evaluate a model on the sliding window of the previous metric reports + the current metric reported + the previously computed server state to obtain an assessment of the current server health.
+3. If the server is not believed to be healthy, emit an alert via an alerts topic, and also send a message to our containing rack with all the open incidents that this server currently has.
+
+
+We'll omit the other handlers for brevity, but it's important to mention that onTimer makes sure that metric reports are coming in periodically, otherwise it'd trigger an alert stating that we didn’t hear from that server for a long time.
+
+
+### RackFun
+
+
+
+
+
+
+
+
+
+1. This function keeps a mapping between a `ServerId` and a set of open incidents on that server.
+2. When new alerts are received, this function tries to correlate the alert with any other open alerts on that rack. If a correlated rack alert is present, this function notifies the **DataCenterFun** about it.
+
+### DataCenterFun
+
+
+
+
+
+
+
+
+
+1. A persisted mapping between a `RackId` and the latest alert that rack reported.
+2. Throughout the usage of ingress/egress pairs, this function can report back its current view of the world of what racks are currently known to be unhealthy.
+3. An operator (via a front-end) can send a `GetUnhealthyRacks` message addressed to that **DataCenterFun**, and wait for the corresponding response `message(UnhealthyRacks)`. Whenever a rack reports _OK_, it'll be removed from the unhealthy racks map.
+
+## Conclusion
+
+This pattern — where each layer of functions performs a stateful aggregation of events sent from the previous layer (or the input) — is useful for a whole class of problems. And, although we used connected devices to motivate this use case, it's not limited to the IoT domain.
+
+
+
+
+
+
+
+
+
+Stateful Functions provides the building blocks necessary for building complex distributed applications (here the digital twins that support analysis and interactions of the physical entities), while removing common complexities of distributed systems like service discovery, retires, circuit breakers, state management, scalability and similar challenges. If you'd like to learn more about Stateful Functions, head over to the official [documentation]({{< param DocsBaseUrl >}}flink-statefun-docs-master/), where you can also find more hands-on tutorials to try out yourself!
\ No newline at end of file
diff --git a/docs/content.tr/posts/2020-08-20-flink-docker.md b/docs/content.tr/posts/2020-08-20-flink-docker.md
new file mode 100644
index 0000000000..b16898fcec
--- /dev/null
+++ b/docs/content.tr/posts/2020-08-20-flink-docker.md
@@ -0,0 +1,98 @@
+---
+authors:
+- name: Robert Metzger
+ rmetzger: null
+ twitter: rmetzger_
+date: "2020-08-20T00:00:00Z"
+excerpt: This blog post gives an update on the recent developments of Flink's support
+ for Docker.
+title: The State of Flink on Docker
+aliases:
+- /news/2020/08/20/flink-docker.html
+---
+
+With over 50 million downloads from Docker Hub, the Flink docker images are a very popular deployment option.
+
+The Flink community recently put some effort into improving the Docker experience for our users with the goal to reduce confusion and improve usability.
+
+
+Let's quickly break down the recent improvements:
+
+- Reduce confusion: Flink used to have 2 Dockerfiles and a 3rd file maintained outside of the official repository — all with different features and varying stability. Now, we have one central place for all images: [apache/flink-docker](https://github.com/apache/flink-docker).
+
+ Here, we keep all the Dockerfiles for the different releases. Check out the [detailed readme](https://github.com/apache/flink-docker/blob/master/README.md) of that repository for further explanation on the different branches, as well as the [Flink Improvement Proposal (FLIP-111)](https://cwiki.apache.org/confluence/display/FLINK/FLIP-111%3A+Docker+image+unification) that contains the detailed planning.
+
+ The `apache/flink-docker` repository also seeds the [official Flink image on Docker Hub](https://hub.docker.com/_/flink).
+
+- Improve Usability: The Dockerfiles are used for various purposes: [Native Docker deployments]({{< param DocsBaseUrl >}}flink-docs-master/ops/deployment/docker.html), [Flink on Kubernetes]({{< param DocsBaseUrl >}}flink-docs-master/ops/deployment/native_kubernetes.html), the (unofficial) [Flink helm example](https://github.com/docker-flink/examples) and the project's [internal end to end tests](https://github.com/apache/flink/tree/master/flink-end-to-end-tests). With one unified image, all these consumers of the images benefit from the same set of features, documentation and testing.
+
+ The new images support [passing configuration variables]({{< param DocsBaseUrl >}}flink-docs-master/ops/deployment/docker.html#configure-options) via a `FLINK_PROPERTIES` environment variable. Users can [enable default plugins]({{< param DocsBaseUrl >}}flink-docs-master/ops/deployment/docker.html#using-plugins) with the `ENABLE_BUILT_IN_PLUGINS` environment variable. The images also allow loading custom jar paths and configuration files.
+
+Looking into the future, there are already some interesting potential improvements lined up:
+
+- [Java 11 Docker images](https://issues.apache.org/jira/browse/FLINK-16260) (already completed)
+- [Use vanilla docker-entrypoint with flink-kubernetes](https://issues.apache.org/jira/browse/FLINK-15793) (in progress)
+- [History server support](https://issues.apache.org/jira/browse/FLINK-17167)
+- [Support for OpenShift](https://issues.apache.org/jira/browse/FLINK-15587)
+
+## How do I get started?
+
+This is a short tutorial on [how to start a Flink Session Cluster]({{< param DocsBaseUrl >}}flink-docs-master/ops/deployment/docker.html#start-a-session-cluster) with Docker.
+
+A *Flink Session cluster* can be used to run multiple jobs. Each job needs to be submitted to the cluster after it has been deployed. To deploy a *Flink Session cluster* with Docker, you need to start a *JobManager* container. To enable communication between the containers, we first set a required Flink configuration property and create a network:
+
+```
+FLINK_PROPERTIES="jobmanager.rpc.address: jobmanager"
+docker network create flink-network
+```
+
+Then we launch the JobManager:
+
+```
+docker run \
+ --rm \
+ --name=jobmanager \
+ --network flink-network \
+ -p 8081:8081 \
+ --env FLINK_PROPERTIES="${FLINK_PROPERTIES}" \
+ flink:1.11.1 jobmanager
+```
+and one or more *TaskManager* containers:
+
+```
+docker run \
+ --rm \
+ --name=taskmanager \
+ --network flink-network \
+ --env FLINK_PROPERTIES="${FLINK_PROPERTIES}" \
+ flink:1.11.1 taskmanager
+```
+
+You now have a fully functional Flink cluster running! You can access the the web front end here: [localhost:8081](http://localhost:8081/).
+
+Let's now submit one of Flink's example jobs:
+
+```bash
+# 1: (optional) Download the Flink distribution, and unpack it
+wget https://archive.apache.org/dist/flink/flink-1.11.1/flink-1.11.1-bin-scala_2.12.tgz
+tar xf flink-1.11.1-bin-scala_2.12.tgz
+cd flink-1.11.1
+
+# 2: Start the Flink job
+./bin/flink run ./examples/streaming/TopSpeedWindowing.jar
+```
+
+The main steps of the tutorial are also recorded in this short screencast:
+
+
+
+
+
+
+**Next steps**: Now that you've successfully completed this tutorial, we recommend you checking out the full [Flink on Docker documentation]({{< param DocsBaseUrl >}}flink-docs-master/ops/deployment/docker.html) for implementing more advanced deployment scenarios, such as Job Clusters, Docker Compose or our native Kubernetes integration.
+
+
+## Conclusion
+
+We encourage all readers to try out Flink on Docker to provide the community with feedback to further improve the experience.
+Please refer to the user@flink.apache.org ([remember to subscribe first](https://flink.apache.org/community.html#how-to-subscribe-to-a-mailing-list)) for general questions and our [issue tracker](https://issues.apache.org/jira/issues/?jql=project+%3D+FLINK+AND+component+%3D+flink-docker) for specific bugs or improvements, or [ideas for contributions](https://flink.apache.org/contributing/how-to-contribute.html)!
diff --git a/docs/content.tr/posts/2020-08-25-release-1.10.2.md b/docs/content.tr/posts/2020-08-25-release-1.10.2.md
new file mode 100644
index 0000000000..ccc6200069
--- /dev/null
+++ b/docs/content.tr/posts/2020-08-25-release-1.10.2.md
@@ -0,0 +1,217 @@
+---
+authors:
+- name: Zhu Zhu
+ twitter: zhuzhv
+ zhuzhu: null
+date: "2020-08-25T00:00:00Z"
+title: Apache Flink 1.10.2 Released
+aliases:
+- /news/2020/08/25/release-1.10.2.html
+---
+
+The Apache Flink community released the second bugfix version of the Apache Flink 1.10 series.
+
+This release includes 73 fixes and minor improvements for Flink 1.10.1. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.10.2.
+
+
+ Note
+After FLINK-18242, the deprecated `OptionsFactory` and `ConfigurableOptionsFactory` classes are removed (not applicable for release-1.10), please use `RocksDBOptionsFactory` and `ConfigurableRocksDBOptionsFactory` instead. Please also recompile your application codes if any class extending `DefaultConfigurableOptionsFactory`
+
+
+
+ Note
+After FLINK-17800 by default we will set `setTotalOrderSeek` to true for RocksDB's `ReadOptions`, to prevent user from miss using `optimizeForPointLookup`. Meantime we support customizing `ReadOptions` through `RocksDBOptionsFactory`. Please set `setTotalOrderSeek` back to false if any performance regression observed (normally won't happen according to our testing).
+
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.10.2
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.10.2
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.10.2
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-15836 ] - Throw fatal error in KubernetesResourceManager when the pods watcher is closed with exception
+
+[FLINK-16160 ] - Schema#proctime and Schema#rowtime don't work in TableEnvironment#connect code path
+
+
+
+ Bug
+
+
+[FLINK-13689 ] - Rest High Level Client for Elasticsearch6.x connector leaks threads if no connection could be established
+
+[FLINK-14369 ] - KafkaProducerAtLeastOnceITCase>KafkaProducerTestBase.testOneToOneAtLeastOnceCustomOperator fails on Travis
+
+[FLINK-14836 ] - Unable to set yarn container number for scala shell in yarn mode
+
+[FLINK-14894 ] - HybridOffHeapUnsafeMemorySegmentTest#testByteBufferWrap failed on Travis
+
+[FLINK-15758 ] - Investigate potential out-of-memory problems due to managed unsafe memory allocation
+
+[FLINK-15849 ] - Update SQL-CLIENT document from type to data-type
+
+[FLINK-16309 ] - ElasticSearch 7 connector is missing in SQL connector list
+
+[FLINK-16346 ] - BlobsCleanupITCase.testBlobServerCleanupCancelledJob fails on Travis
+
+[FLINK-16432 ] - Building Hive connector gives problems
+
+[FLINK-16451 ] - Fix IndexOutOfBoundsException for DISTINCT AGG with constants
+
+[FLINK-16510 ] - Task manager safeguard shutdown may not be reliable
+
+[FLINK-17092 ] - Pyflink test BlinkStreamDependencyTests is instable
+
+[FLINK-17322 ] - Enable latency tracker would corrupt the broadcast state
+
+[FLINK-17420 ] - Cannot alias Tuple and Row fields when converting DataStream to Table
+
+[FLINK-17466 ] - toRetractStream doesn't work correctly with Pojo conversion class
+
+[FLINK-17555 ] - docstring of pyflink.table.descriptors.FileSystem:1:duplicate object description of pyflink.table.descriptors.FileSystem
+
+[FLINK-17558 ] - Partitions are released in TaskExecutor Main Thread
+
+[FLINK-17562 ] - POST /jars/:jarid/plan is not working
+
+[FLINK-17578 ] - Union of 2 SideOutputs behaviour incorrect
+
+[FLINK-17639 ] - Document which FileSystems are supported by the StreamingFileSink
+
+[FLINK-17643 ] - LaunchCoordinatorTest fails
+
+[FLINK-17700 ] - The callback client of JavaGatewayServer should run in a daemon thread
+
+[FLINK-17744 ] - StreamContextEnvironment#execute cannot be call JobListener#onJobExecuted
+
+[FLINK-17763 ] - No log files when starting scala-shell
+
+[FLINK-17788 ] - scala shell in yarn mode is broken
+
+[FLINK-17800 ] - RocksDB optimizeForPointLookup results in missing time windows
+
+[FLINK-17801 ] - TaskExecutorTest.testHeartbeatTimeoutWithResourceManager timeout
+
+[FLINK-17809 ] - BashJavaUtil script logic does not work for paths with spaces
+
+[FLINK-17822 ] - Nightly Flink CLI end-to-end test failed with "JavaGcCleanerWrapper$PendingCleanersRunner cannot access class jdk.internal.misc.SharedSecrets" in Java 11
+
+[FLINK-17870 ] - dependent jars are missing to be shipped to cluster in scala shell
+
+[FLINK-17891 ] - FlinkYarnSessionCli sets wrong execution.target type
+
+[FLINK-17959 ] - Exception: "CANCELLED: call already cancelled" is thrown when run python udf
+
+[FLINK-18008 ] - HistoryServer does not log environment information on startup
+
+[FLINK-18012 ] - Deactivate slot timeout if TaskSlotTable.tryMarkSlotActive is called
+
+[FLINK-18035 ] - Executors#newCachedThreadPool could not work as expected
+
+[FLINK-18045 ] - Fix Kerberos credentials checking to unblock Flink on secured MapR
+
+[FLINK-18048 ] - "--host" option could not take effect for standalone application cluster
+
+[FLINK-18097 ] - History server doesn't clean all job json files
+
+[FLINK-18168 ] - Error results when use UDAF with Object Array return type
+
+[FLINK-18223 ] - AvroSerializer does not correctly instantiate GenericRecord
+
+[FLINK-18241 ] - Custom OptionsFactory in user code not working when configured via flink-conf.yaml
+
+[FLINK-18242 ] - Custom OptionsFactory settings seem to have no effect on RocksDB
+
+[FLINK-18297 ] - SQL client: setting execution.type to invalid value shuts down the session
+
+[FLINK-18329 ] - Dist NOTICE issues
+
+[FLINK-18352 ] - org.apache.flink.core.execution.DefaultExecutorServiceLoader not thread safe
+
+[FLINK-18517 ] - kubernetes session test failed with "java.net.SocketException: Broken pipe"
+
+[FLINK-18539 ] - StreamExecutionEnvironment#addSource(SourceFunction, TypeInformation) doesn't use the user defined type information
+
+[FLINK-18595 ] - Deadlock during job shutdown
+
+[FLINK-18646 ] - Managed memory released check can block RPC thread
+
+[FLINK-18663 ] - RestServerEndpoint may prevent server shutdown
+
+[FLINK-18677 ] - ZooKeeperLeaderRetrievalService does not invalidate leader in case of SUSPENDED connection
+
+[FLINK-18702 ] - Flink elasticsearch connector leaks threads and classloaders thereof
+
+[FLINK-18815 ] - AbstractCloseableRegistryTest.testClose unstable
+
+[FLINK-18821 ] - Netty client retry mechanism may cause PartitionRequestClientFactory#createPartitionRequestClient to wait infinitely
+
+[FLINK-18859 ] - ExecutionGraphNotEnoughResourceTest.testRestartWithSlotSharingAndNotEnoughResources failed with "Condition was not met in given timeout."
+
+[FLINK-18902 ] - Cannot serve results of asynchronous REST operations in per-job mode
+
+
+
+ New Feature
+
+
+[FLINK-17844 ] - Activate japicmp-maven-plugin checks for @PublicEvolving between bug fix releases (x.y.u -> x.y.v)
+
+
+
+ Improvement
+
+
+[FLINK-16217 ] - SQL Client crashed when any uncatched exception is thrown
+
+[FLINK-16225 ] - Metaspace Out Of Memory should be handled as Fatal Error in TaskManager
+
+[FLINK-16619 ] - Misleading SlotManagerImpl logging for slot reports of unknown task manager
+
+[FLINK-16717 ] - Use headless service for rpc and blob port when flink on K8S
+
+[FLINK-17248 ] - Make the thread nums of io executor of ClusterEntrypoint and MiniCluster configurable
+
+[FLINK-17503 ] - Make memory configuration logging more user-friendly
+
+[FLINK-17819 ] - Yarn error unhelpful when forgetting HADOOP_CLASSPATH
+
+[FLINK-17920 ] - Add the Python example of Interval Join in Table API doc
+
+[FLINK-17945 ] - Improve error reporting of Python CI tests
+
+[FLINK-17970 ] - Increase default value of IO pool executor to 4 * #cores
+
+[FLINK-18010 ] - Add more logging to HistoryServer
+
+[FLINK-18501 ] - Mapping of Pluggable Filesystems to scheme is not properly logged
+
+[FLINK-18644 ] - Remove obsolete doc for hive connector
+
+[FLINK-18772 ] - Hide submit job web ui elements when running in per-job/application mode
+
+
+
diff --git a/docs/content.tr/posts/2020-09-01-flink-1.11-memory-management-improvements.md b/docs/content.tr/posts/2020-09-01-flink-1.11-memory-management-improvements.md
new file mode 100644
index 0000000000..035aee4676
--- /dev/null
+++ b/docs/content.tr/posts/2020-09-01-flink-1.11-memory-management-improvements.md
@@ -0,0 +1,109 @@
+---
+authors:
+- Andrey: null
+ name: Andrey Zagrebin
+date: "2020-09-01T15:30:00Z"
+excerpt: In a previous blog post, we focused on the memory model of the TaskManagers
+ and its improvements with the Apache Flink 1.10 release. This blog post addresses
+ the same topic but for Flink's JobManager instead.
+title: Memory Management improvements for Flink’s JobManager in Apache Flink 1.11
+aliases:
+- /2020/09/01/flink-1.11-memory-management-improvements.html
+---
+
+Apache Flink 1.11 comes with significant changes to the memory model of Flink’s JobManager and configuration options for your Flink clusters.
+These recently-introduced changes make Flink adaptable to all kinds of deployment environments (e.g. Kubernetes, Yarn, Mesos),
+providing better control over its memory consumption.
+
+The [previous blog post](https://flink.apache.org/news/2020/04/21/memory-management-improvements-flink-1.10.html)
+focused on the memory model of the TaskManagers and how it was improved in Flink 1.10. This post addresses the same topic but for the JobManager instead.
+Flink 1.11 unifies the memory model of Flink’s processes. The newly-introduced memory model of the JobManager follows a similar approach to that of the TaskManagers;
+it is simpler and has fewer components and tuning knobs. This post might consequently seem very similar to our previous story on Flink’s memory
+but aims at providing a complete overview of Flink’s JobManager memory model as of Flink 1.11. Read on for a full list of updates and changes below!
+
+## Introduction to Flink’s process memory model
+
+Having a clear understanding of Apache Flink’s process memory model allows you to manage resources for the various workloads more efficiently.
+The following diagram illustrates the main memory components of a Flink process:
+
+
+
+
+Flink: Total Process Memory
+
+
+
+The JobManager process is a JVM process. On a high level, its memory consists of the JVM Heap and Off-Heap memory.
+These types of memory are consumed by Flink directly or by the JVM for its specific purposes (i.e. metaspace).
+There are two major memory consumers within the JobManager process: the framework itself consuming memory for internal data structures, network communication, etc.
+and the user code which runs within the JobManager process, e.g. in certain batch sources or during checkpoint completion callbacks.
+
+
+ Note
+Please note that the user code has direct access to all memory types: JVM Heap, Direct and Native memory. Therefore, Flink cannot really control its allocation and usage.
+
+
+## How to set up JobManager memory
+
+With the release of Flink 1.11 and in order to provide better user experience, the Flink community introduced three alternatives to setting up memory in JobManagers.
+
+The first two — and simplest — alternatives are configuring one of the two following options for total memory available for the JVM process of the JobManager:
+
+* **_Total Process Memory:_** total memory consumed by the Flink Java application (including user code) and by the JVM to run the whole process.
+* **_Total Flink Memory:_** only the memory consumed by the Flink Java application, including user code but excluding any memory allocated by the JVM to run it.
+
+It is advisable to configure the _Total Flink Memory_ for standalone deployments where explicitly declaring how much memory is given to Flink is a common practice,
+while the outer JVM overhead is of little interest. For the cases of deploying Flink in containerized environments
+(such as [Kubernetes]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/deployment/kubernetes.html),
+[Yarn]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/deployment/yarn_setup.html) or
+[Mesos]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/deployment/mesos.html)),
+the _Total Process Memory_ option is recommended instead, because it becomes the size for the total memory of the requested container.
+Containerized environments usually strictly enforce this memory limit.
+
+If you want more fine-grained control over the size of the _JVM Heap_, there is also the third alternative of configuring it directly.
+This alternative gives a clear separation between the heap memory and any other memory types.
+
+The remaining memory components will be automatically adjusted either based on their default values or additionally-configured parameters.
+Apache Flink also checks the overall consistency. You can find more information about the different memory components in the corresponding
+[documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/memory/mem_setup_jobmanager.html).
+You can try different configuration options with the [configuration spreadsheet](https://docs.google.com/spreadsheets/d/1mJaMkMPfDJJ-w6nMXALYmTc4XxiV30P5U7DzgwLkSoE/edit#gid=605121894)
+(you have to make a copy of the spreadsheet to edit it) of [FLIP-116](https://cwiki.apache.org/confluence/display/FLINK/FLIP-116%3A+Unified+Memory+Configuration+for+Job+Managers)
+and check the corresponding results for your individual case.
+
+If you are migrating from a Flink version older than 1.11, we suggest following the steps in the
+[migration guide]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/memory/mem_migration.html#migrate-job-manager-memory-configuration) of the Flink documentation.
+
+Additionally, you can configure separately the [Off-heap memory]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/memory/mem_setup_jobmanager.html#configure-off-heap-memory)
+(_JVM direct and non-direct memory_) as well as the [JVM metaspace & overhead]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/memory/mem_setup_jobmanager.html#detailed-configuration).
+The _JVM overhead_ is a [fraction]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/memory/mem_setup.html#capped-fractionated-components) of the _Total Process Memory_.
+The _JVM overhead_ can be configured in a similar way as other fractions described in [our previous blog post](https://flink.apache.org/news/2020/04/21/memory-management-improvements-flink-1.10.html#fractions-of-the-total-flink-memory)
+about the TaskManager’s memory model.
+
+## More hints to control the container memory limit
+
+The heap and direct memory usage are managed by the JVM. There are also many other possible sources of native memory consumption in Apache Flink or its user applications
+which are not managed directly by Flink or the JVM. Controlling their limits is often difficult which complicates debugging of potential memory leaks.
+If Flink’s process allocates too much memory in an unmanaged way, it can often result in killing its containers for containerized environments.
+In this case, understanding which type of memory consumption has exceeded its limit might be difficult to grasp and resolve.
+Flink 1.11 introduces some specific tuning options to clearly represent such components for the JobManager’s process.
+Although Flink cannot always enforce strict limits and borders among them, the idea here is to explicitly plan the memory usage.
+Below we provide some examples of how memory setup can prevent containers from exceeding their memory limit:
+
+* **[User code or its dependencies consume significant off-heap memory]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/memory/mem_setup_jobmanager.html#configure-off-heap-memory).**
+Tuning the _Off-heap_ option can assign additional direct or native memory to the user code or any of its dependencies.
+Flink cannot control native allocations but it sets the limit for _JVM Direct_ memory allocations. The Direct memory limit is enforced by the JVM.
+
+* **[JVM metaspace requires additional memory]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/memory/mem_setup_jobmanager.html#detailed-configuration).**
+If you encounter `OutOfMemoryError: Metaspace`, Flink provides an option to increase its default limit and the JVM will ensure that it is not exceeded.
+The metaspace size of a Flink JVM process is always explicitly set in contrast to the default JVM settings where it is not limited.
+
+* **[JVM requires more internal memory]({{< param DocsBaseUrl >}}flink-docs-release-1.11/ops/memory/mem_setup_jobmanager.html#detailed-configuration).**
+There is no direct control over certain types of JVM process allocations but Flink provides _JVM Overhead_ options.
+The _JVM Overhead_ options allow declaring an additional amount of memory, anticipated for those allocations and not covered by other options.
+
+## Conclusion
+
+The latest Flink release ([Flink 1.11](https://flink.apache.org/downloads.html#apache-flink-1111)) introduces some notable changes to the memory configuration of Flink’s JobManager,
+making its memory management significantly easier than before. Stay tuned for more additions and features in upcoming releases.
+If you have any suggestions or questions for the Flink community, we encourage you to sign up to the Apache Flink [mailing lists](https://flink.apache.org/community.html#mailing-lists)
+and become part of the discussion.
diff --git a/docs/content.tr/posts/2020-09-04-community-update.md b/docs/content.tr/posts/2020-09-04-community-update.md
new file mode 100644
index 0000000000..ebe1087c1e
--- /dev/null
+++ b/docs/content.tr/posts/2020-09-04-community-update.md
@@ -0,0 +1,221 @@
+---
+authors:
+- morsapaes: null
+ name: Marta Paes
+ twitter: morsapaes
+date: "2020-09-04T08:00:00Z"
+excerpt: Ah, so much for a quiet August month. This time around, we bring you some
+ new Flink Improvement Proposals (FLIPs), a preview of the upcoming Flink Stateful
+ Functions 2.2 release and a look into how far Flink has come in comparison to 2019.
+title: Flink Community Update - August'20
+aliases:
+- /news/2020/09/04/community-update.html
+---
+
+Ah, so much for a quiet August month. This time around, we bring you some new Flink Improvement Proposals (FLIPs), a preview of the upcoming [Flink Stateful Functions]({{< param DocsBaseUrl >}}flink-statefun-docs-master/) 2.2 release and a look into how far Flink has come in comparison to 2019.
+
+# The Past Month in Flink
+
+## Flink Releases
+
+### Getting Ready for Flink Stateful Functions 2.2
+
+The details of the next release of [Stateful Functions]({{< param DocsBaseUrl >}}flink-statefun-docs-master/) are under discussion in [this @dev mailing list thread](http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/Next-Stateful-Functions-Release-td44063.html), and the feature freeze is set for **September 10th** — so, you can expect Stateful Functions 2.2 to be released soon after! Some of the most relevant features in the upcoming release are:
+
+* **DataStream API interoperability**, allowing users to embed Stateful Functions pipelines in regular [DataStream API]({{< param DocsBaseUrl >}}flink-docs-stable/dev/datastream_api.html) programs with `DataStream` ingress/egress.
+
+* **Fine-grained control over state** for remote functions, including the ability to configure different state expiration modes for each individual function.
+
+As the community around StateFun grows, the release cycle will follow this pattern of smaller and more frequent releases to incorporate user feedback and allow for faster iteration. If you’d like to get involved, we’re always looking for [new contributors](https://github.com/apache/flink-statefun#contributing)!
+
+### Flink 1.10.2
+
+The community has announced the second patch version to cover some outstanding issues in Flink 1.10. You can find a detailed list with all the improvements and bugfixes that went into Flink 1.10.2 in the [announcement blogpost](https://flink.apache.org/news/2020/08/25/release-1.10.2.html).
+
+
+
+## New Flink Improvement Proposals (FLIPs)
+
+The number of FLIPs being created and discussed in the @dev mailing list is growing week over week, as the Flink 1.12 release takes form and some longer-term efforts are kicked-off. Below are some of the new FLIPs to keep an eye out for!
+
+
+
+
+ #
+
+
+
+
+
+ FLIP-131
+
+ Consolidate User-Facing APIs and Deprecate the DataSet API
+ The community proposes to deprecate the DataSet API in favor of the Table API/SQL and the DataStream API, in the long run. For this to be feasible, both APIs first need to be adapted and expanded to support the additional use cases currently covered by the DataSet API.
+ The first discussion to branch out of this "umbrella" FLIP is around support for a batch execution mode in the DataStream API (FLIP-134 ).
+
+
+
+
+ FLIP-135
+
+ Approximate Task-Local Recovery
+ To better accommodate recovery scenarios where a certain amount of data loss is tolerable, but a full pipeline restart is not desirable, the community plans to introduce a new failover strategy that allows to restart only the failed task(s). Approximate task-local recovery will allow users to trade consistency for fast failure recovery, which is handy for use cases like online training.
+
+
+
+
+ FLIP-136
+
+ Improve the interoperability between DataStream and Table API
+ The Table API has seen a great deal of refactoring and new features in recent releases, but the interfaces to and from the DataStream API haven't been updated accordingly. The work in this FLIP will cover multiple known gaps to improve interoperability and expose important functionality also to the DataStream API (e.g. changelog handling).
+
+
+
+
+ FLIP-139
+
+ Support Stateful Python UDFs
+ Python UDFs have been supported in PyFlink since 1.10 , but were so far limited to stateless functions. The community is now looking to introduce stateful aggregate functions (UDAFs) in the Python Table API.
+ Note: Pandas UDAFs are covered in a separate proposal (FLIP-137 ).
+
+
+
+
+
+
+For a complete overview of the development threads coming up in the project, check the [Flink 1.12 Release Wiki](https://cwiki.apache.org/confluence/display/FLINK/1.12+Release) and follow the feature discussions in the [@dev mailing list](https://lists.apache.org/list.html?dev@flink.apache.org).
+
+## New Committers and PMC Members
+
+The Apache Flink community has welcomed **1 new PMC Member** and **1 new Committer** since the last update. Congratulations!
+
+### New PMC Members
+
+
+
+### New Committers
+
+
+
+
+
+# The Bigger Picture
+
+## Flink in 2019: the Aftermath
+
+Roughly a year ago, we did a [roundup of community stats](https://flink.apache.org/news/2019/09/10/community-update.html#the-bigger-picture) to understand how far Flink (and the Flink community) had come in 2019. Where does Flink stand now? What changed?
+
+Perhaps the most impressive result this time around is the surge in activity in the @user-zh mailing list. What started as an effort to better support the chinese-speaking users early in 2019 is now even **exceeding** the level of activity of the (already very active) main @user mailing list. Also @dev1 registered the highest ever peaks in activity in the months leading to the release of Flink 1.11!
+
+For what it's worth, the Flink GitHub repository is now headed to **15k stars**, after reaching the 10k milestone last year. If you consider some other numbers we gathered previously on [repository activity](https://flink.apache.org/news/2020/04/01/community-update.html#a-look-into-the-flink-repository) and [releases over time](https://flink.apache.org/news/2020/07/27/community-update.html#a-look-into-the-evolution-of-flink-releases), 2020 is looking like one for the books in the Flink community.
+
+
+
+
+
+1. Excluding messages from "jira@apache.org".
+
+
+
+
+
+To put these numbers into perspective, the report for the financial year of 2020 from the Apache Software Foundation (ASF) features Flink as **one of the most active open source projects**, with mentions for:
+
+* Most Active Sources: Visits (#2)
+
+* Top Repositories by Number of Commits (#2)
+
+* Top Most Active Apache Mailing Lists (@user (#1) and @dev (#2))
+
+For more details on where Flink and other open source projects stand in the bigger ASF picture, check out the [full report](https://www.apache.org/foundation/docs/FY2020AnnualReport.pdf).
+
+## Google Season of Docs 2020 Results
+
+In a [previous update](https://flink.apache.org/news/2020/06/11/community-update.html#google-season-of-docs-2020), we announced that Flink had been selected for [Google Season of Docs (GSoD)](https://developers.google.com/season-of-docs) 2020, an initiative to pair technical writers with mentors to work on documentation for open source projects. Today, we'd like to welcome the two technical writers that will be working with the Flink community to improve the Table API/SQL documentation: **Kartik Khare** and **Muhammad Haseeb Asif**!
+
+* [Kartik](https://github.com/KKcorps) is a software engineer at Walmart Labs and a regular contributor to multiple Apache projects. He is also a prolific writer on [Medium](https://medium.com/@kharekartik) and has previously published on the [Flink blog](https://flink.apache.org/news/2020/02/07/a-guide-for-unit-testing-in-apache-flink.html). Last year, he contributed to Apache Airflow as part of GSoD and he's currently revamping the Apache Pinot documentation.
+
+* [Muhammad](https://www.linkedin.com/in/haseebasif/) is a dual degree master student at KTH and TU Berlin, with a focus on distributed systems and data intensive processing (in particular, performance optimization of state backends). He writes frequently about Flink on [Medium](https://medium.com/@haseeb1431) and you can catch him at [Flink Forward](https://www.flink-forward.org/global-2020/conference-program#flinkndb---skyrocketing-stateful-capabilities-of-apache-flink) later this year!
+
+We're looking forward to the next 3 months of collaboration, and would like to thank again all the applicants that invested time into their applications for GSoD with Flink.
+
+
+
+# Upcoming Events (and More!)
+
+With conference season in full swing, we're glad to see some great Flink content coming up in September! Here, we highlight some of the Flink talks happening soon in virtual events.
+
+As usual, we also leave you with some resources to read and explore.
+
+
+
+
+ Category
+
+
+
+
+
+ Events
+
+
+
+
+
+
+ Blogposts
+
+
+
+ Flink Packages
+
+
+
+
+
+
+
+
+If you’d like to keep a closer eye on what’s happening in the community, subscribe to the Flink [@community mailing list](https://flink.apache.org/community.html#mailing-lists) to get fine-grained weekly updates, upcoming event announcements and more.
diff --git a/docs/content.tr/posts/2020-09-17-release-1.11.2.md b/docs/content.tr/posts/2020-09-17-release-1.11.2.md
new file mode 100644
index 0000000000..2931dcffb7
--- /dev/null
+++ b/docs/content.tr/posts/2020-09-17-release-1.11.2.md
@@ -0,0 +1,252 @@
+---
+authors:
+- name: Zhu Zhu
+ twitter: zhuzhv
+ zhuzhu: null
+date: "2020-09-17T00:00:00Z"
+title: Apache Flink 1.11.2 Released
+aliases:
+- /news/2020/09/17/release-1.11.2.html
+---
+
+The Apache Flink community released the second bugfix version of the Apache Flink 1.11 series.
+
+This release includes 96 fixes and minor improvements for Flink 1.11.1. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.11.2.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.11.2
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.11.2
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.11.2
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-16087 ] - Translate "Detecting Patterns" page of "Streaming Concepts" into Chinese
+
+[FLINK-18264 ] - Translate the "External Resource Framework" page into Chinese
+
+[FLINK-18628 ] - Invalid error message for overloaded methods with same parameter name
+
+[FLINK-18801 ] - Add a "10 minutes to Table API" document under the "Python API" -> "User Guide" -> "Table API" section
+
+[FLINK-18910 ] - Create the new document structure for Python documentation according to FLIP-133
+
+[FLINK-18912 ] - Add a Table API tutorial link(linked to try-flink/python_table_api.md) under the "Python API" -> "GettingStart" -> "Tutorial" section
+
+[FLINK-18913 ] - Add a "TableEnvironment" document under the "Python API" -> "User Guide" -> "Table API" section
+
+[FLINK-18917 ] - Add a "Built-in Functions" link (linked to dev/table/functions/systemFunctions.md) under the "Python API" -> "User Guide" -> "Table API" section
+
+[FLINK-19110 ] - Flatten current PyFlink documentation structure
+
+
+
+ Bug
+
+
+[FLINK-14087 ] - throws java.lang.ArrayIndexOutOfBoundsException when emiting the data using RebalancePartitioner.
+
+[FLINK-15467 ] - Should wait for the end of the source thread during the Task cancellation
+
+[FLINK-16510 ] - Task manager safeguard shutdown may not be reliable
+
+[FLINK-16827 ] - StreamExecTemporalSort should require a distribution trait in StreamExecTemporalSortRule
+
+[FLINK-18081 ] - Fix broken links in "Kerberos Authentication Setup and Configuration" doc
+
+[FLINK-18212 ] - Init lookup join failed when use udf on lookup table
+
+[FLINK-18341 ] - Building Flink Walkthrough Table Java 0.1 COMPILATION ERROR
+
+[FLINK-18421 ] - Elasticsearch (v6.3.1) sink end-to-end test instable
+
+[FLINK-18468 ] - TaskExecutorITCase.testJobReExecutionAfterTaskExecutorTermination fails with DuplicateJobSubmissionException
+
+[FLINK-18552 ] - Update migration tests in master to cover migration from release-1.11
+
+[FLINK-18581 ] - Cannot find GC cleaner with java version previous jdk8u72(-b01)
+
+[FLINK-18588 ] - hive ddl create table should support 'if not exists'
+
+[FLINK-18595 ] - Deadlock during job shutdown
+
+[FLINK-18600 ] - Kerberized YARN per-job on Docker test failed to download JDK 8u251
+
+[FLINK-18608 ] - CustomizedConvertRule#convertCast drops nullability
+
+[FLINK-18612 ] - WordCount example failure when setting relative output path
+
+[FLINK-18632 ] - RowData's row kind do not assigned from input row data when sink code generate and physical type info is pojo type
+
+[FLINK-18639 ] - Error messages from BashJavaUtils are eaten
+
+[FLINK-18641 ] - "Failure to finalize checkpoint" error in MasterTriggerRestoreHook
+
+[FLINK-18646 ] - Managed memory released check can block RPC thread
+
+[FLINK-18650 ] - The description of dispatcher in Flink Architecture document is not accurate
+
+[FLINK-18655 ] - Set failOnUnableToExtractRepoInfo to false for git-commit-id-plugin in module flink-runtime
+
+[FLINK-18656 ] - Start Delay metric is always zero for unaligned checkpoints
+
+[FLINK-18659 ] - FileNotFoundException when writing Hive orc tables
+
+[FLINK-18663 ] - RestServerEndpoint may prevent server shutdown
+
+[FLINK-18665 ] - Filesystem connector should use TableSchema exclude computed columns
+
+[FLINK-18672 ] - Fix Scala code examples for UDF type inference annotations
+
+[FLINK-18677 ] - ZooKeeperLeaderRetrievalService does not invalidate leader in case of SUSPENDED connection
+
+[FLINK-18682 ] - Vector orc reader cannot read Hive 2.0.0 table
+
+[FLINK-18697 ] - Adding flink-table-api-java-bridge_2.11 to a Flink job kills the IDE logging
+
+[FLINK-18700 ] - Debezium-json format throws Exception when PG table's IDENTITY config is not FULL
+
+[FLINK-18705 ] - Debezium-JSON throws NPE when tombstone message is received
+
+[FLINK-18708 ] - The links of the connector sql jar of Kafka 0.10 and 0.11 are extinct
+
+[FLINK-18710 ] - ResourceProfileInfo is not serializable
+
+[FLINK-18748 ] - Savepoint would be queued unexpected if pendingCheckpoints less than maxConcurrentCheckpoints
+
+[FLINK-18749 ] - Correct dependencies in Kubernetes pom
+
+[FLINK-18750 ] - SqlValidatorException thrown when select from a view which contains a UDTF call
+
+[FLINK-18769 ] - MiniBatch doesn't work with FLIP-95 source
+
+[FLINK-18821 ] - Netty client retry mechanism may cause PartitionRequestClientFactory#createPartitionRequestClient to wait infinitely
+
+[FLINK-18832 ] - BoundedBlockingSubpartition does not work with StreamTask
+
+[FLINK-18856 ] - CheckpointCoordinator ignores checkpointing.min-pause
+
+[FLINK-18859 ] - ExecutionGraphNotEnoughResourceTest.testRestartWithSlotSharingAndNotEnoughResources failed with "Condition was not met in given timeout."
+
+[FLINK-18862 ] - Fix LISTAGG throws BinaryRawValueData cannot be cast to StringData exception in runtime
+
+[FLINK-18867 ] - Generic table stored in Hive catalog is incompatible between 1.10 and 1.11
+
+[FLINK-18900 ] - HiveCatalog should error out when listing partitions with an invalid spec
+
+[FLINK-18902 ] - Cannot serve results of asynchronous REST operations in per-job mode
+
+[FLINK-18941 ] - There are some typos in "Set up JobManager Memory"
+
+[FLINK-18942 ] - HiveTableSink shouldn't try to create BulkWriter factory when using MR writer
+
+[FLINK-18956 ] - StreamTask.invoke should catch Throwable instead of Exception
+
+[FLINK-18959 ] - Fail to archiveExecutionGraph because job is not finished when dispatcher close
+
+[FLINK-18992 ] - Table API renameColumns method annotation error
+
+[FLINK-18993 ] - Invoke sanityCheckTotalFlinkMemory method incorrectly in JobManagerFlinkMemoryUtils.java
+
+[FLINK-18994 ] - There is one typo in "Set up TaskManager Memory"
+
+[FLINK-19040 ] - SourceOperator is not closing SourceReader
+
+[FLINK-19061 ] - HiveCatalog fails to get partition column stats if partition value contains special characters
+
+[FLINK-19094 ] - Revise the description of watermark strategy in Flink Table document
+
+[FLINK-19108 ] - Stop expanding the identifiers with scope aliased by the system with 'EXPR$' prefix
+
+[FLINK-19109 ] - Split Reader eats chained periodic watermarks
+
+[FLINK-19121 ] - Avoid accessing HDFS frequently in HiveBulkWriterFactory
+
+[FLINK-19133 ] - User provided kafka partitioners are not initialized correctly
+
+[FLINK-19148 ] - Table crashed in Flink Table API & SQL Docs
+
+[FLINK-19166 ] - StreamingFileWriter should register Listener before the initialization of buckets
+
+
+
+ Improvement
+
+
+[FLINK-16619 ] - Misleading SlotManagerImpl logging for slot reports of unknown task manager
+
+[FLINK-17075 ] - Add task status reconciliation between TM and JM
+
+[FLINK-17285 ] - Translate "Python Table API" page into Chinese
+
+[FLINK-17503 ] - Make memory configuration logging more user-friendly
+
+[FLINK-18598 ] - Add instructions for asynchronous execute in PyFlink doc
+
+[FLINK-18618 ] - Docker e2e tests are failing on CI
+
+[FLINK-18619 ] - Update training to use WatermarkStrategy
+
+[FLINK-18635 ] - Typo in 'concepts/timely stream processing' part of the website
+
+[FLINK-18643 ] - Migrate Jenkins jobs to ci-builds.apache.org
+
+[FLINK-18644 ] - Remove obsolete doc for hive connector
+
+[FLINK-18730 ] - Remove Beta tag from SQL Client docs
+
+[FLINK-18772 ] - Hide submit job web ui elements when running in per-job/application mode
+
+[FLINK-18793 ] - Fix Typo for api.common.eventtime.WatermarkStrategy Description
+
+[FLINK-18797 ] - docs and examples use deprecated forms of keyBy
+
+[FLINK-18816 ] - Correct API usage in Pyflink Dependency Management page
+
+[FLINK-18831 ] - Improve the Python documentation about the operations in Table
+
+[FLINK-18839 ] - Add documentation about how to use catalog in Python Table API
+
+[FLINK-18847 ] - Add documentation about data types in Python Table API
+
+[FLINK-18849 ] - Improve the code tabs of the Flink documents
+
+[FLINK-18881 ] - Modify the Access Broken Link
+
+[FLINK-19055 ] - MemoryManagerSharedResourcesTest contains three tests running extraordinary long
+
+[FLINK-19105 ] - Table API Sample Code Error
+
+
+
+ Task
+
+
+[FLINK-18666 ] - Update japicmp configuration for 1.11.1
+
+[FLINK-18667 ] - Data Types documentation misunderstand users
+
+[FLINK-18678 ] - Hive connector fails to create vector orc reader if user specifies incorrect hive version
+
+
diff --git a/docs/content.tr/posts/2020-09-28-release-statefun-2.2.0.md b/docs/content.tr/posts/2020-09-28-release-statefun-2.2.0.md
new file mode 100644
index 0000000000..91dc4091a5
--- /dev/null
+++ b/docs/content.tr/posts/2020-09-28-release-statefun-2.2.0.md
@@ -0,0 +1,177 @@
+---
+authors:
+- name: Tzu-Li (Gordon) Tai
+ twitter: tzulitai
+ tzulitai: null
+- igalshilman: null
+ name: Igal Shilman
+ twitter: IgalShilman
+date: "2020-09-28T08:00:00Z"
+title: Stateful Functions 2.2.0 Release Announcement
+aliases:
+- /news/2020/09/28/release-statefun-2.2.0.html
+---
+
+The Apache Flink community is happy to announce the release of Stateful Functions (StateFun) 2.2.0! This release
+introduces major features that extend the SDKs, such as support for asynchronous functions in the Python SDK, new
+persisted state constructs, and a new SDK that allows embedding StateFun functions within a Flink DataStream job.
+Moreover, we've also included important changes that improve out-of-the-box stability for common workloads,
+as well as increased observability for operational purposes.
+
+We've also seen new 3rd party SDKs for StateFun being developed since the last release. While they are not part of the
+release artifacts, it's great seeing these community-driven additions! We've highlighted these efforts below
+in this announcement.
+
+The binary distribution and source artifacts are now available on the updated [Downloads](https://flink.apache.org/downloads.html)
+page of the Flink website, and the most recent Python SDK distribution is available on [PyPI](https://pypi.org/project/apache-flink-statefun/).
+For more details, check the complete [release changelog](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12348350)
+and the [updated documentation]({{< param DocsBaseUrl >}}flink-statefun-docs-release-2.2/).
+We encourage you to download the release and share your feedback with the community through the [Flink mailing lists](https://flink.apache.org/community.html#mailing-lists)
+or [JIRA](https://issues.apache.org/jira/browse/)!
+
+## New Features
+
+### Asynchronous functions in Python SDK
+
+This release enables registering asynchronous Python functions as stateful functions by introducing a new handler
+in the [Python SDK]({{< param DocsBaseUrl >}}flink-statefun-docs-release-2.2/sdk/python.html): ``AsyncRequestReplyHandler``.
+This allows serving StateFun functions with Python web frameworks that support asynchronous IO natively (for example,
+[aiohttp](https://pypi.org/project/aiohttp/)):
+
+```python
+from statefun import StatefulFunctions
+from statefun import AsyncRequestReplyHandler
+
+functions = StatefulFunctions()
+
+@functions.bind("example/greeter")
+async def greeter(context, message):
+ html = await fetch(session, 'http://....')
+ context.pack_and_reply(SomeProtobufMessage(html))
+
+# expose this handler via an async web framework
+handler = AsyncRequestReplyHandler(functions)
+```
+
+For more details, please see the docs on [exposing Python functions]({{< param DocsBaseUrl >}}flink-statefun-docs-release-2.2/sdk/python.html#exposing-functions).
+
+### Flink DataStream Integration SDK
+
+Using this SDK, you may combine pipelines written with the Flink ``DataStream`` API or higher-level libraries
+(such as Table API, CEP etc., basically anything that can consume or produce a ``DataStream``) with the programming constructs
+provided by Stateful Functions, as demonstrated below:
+
+```java
+StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
+
+DataStream namesIngress = ...
+
+StatefulFunctionEgressStreams egresses =
+ StatefulFunctionDataStreamBuilder.builder("example")
+ .withDataStreamAsIngress(namesIngress)
+ .withRequestReplyRemoteFunction(
+ RequestReplyFunctionBuilder.requestReplyFunctionBuilder(
+ REMOTE_GREET, URI.create("http://..."))
+ .withPersistedState("seen_count")
+ .withFunctionProvider(GREET, unused -> new MyFunction())
+ .withEgressId(GREETINGS)
+ .build(env);
+
+DataStream responsesEgress = getDataStreamForEgressId(GREETINGS);
+```
+
+Events from ``DataStream`` ingresses are being routed to bound functions, and events sent to
+egresses are captured as ``DataStream`` egresses. This opens up the possibility of building complex streaming
+applications.
+
+### Construct for Dynamic State Registration
+
+Prior to this release, the persisted state constructs in the Java SDK, such as ``PersistedValue``, ``PersistedTable`` etc.,
+had to be eagerly defined in a stateful function's class. In certain scenarios, what state a function requires is not
+known in advance, and may only be dynamically registered at runtime (e.g., when a function is invoked).
+
+This release enables that by providing a new ``PersistedStateRegistry`` construct:
+
+```java
+public class MyFunction implements StatefulFunction {
+ @Persisted
+ private final PersistedStateRegistry registry = new PersistedStateRegistry();
+ private final PersistedValue myValue;
+
+ public void invoke(Context context, Object input) {
+ if (myValue == null) {
+ myValue = registry.registerValue(PersistedValue.of("my-value", String.class));
+ }
+ ...
+ }
+}
+```
+
+## Improvements
+
+### Remote Functions Communication Stability
+
+After observing common workloads, a few configurations for communicating with remote functions were adjusted for a better
+out-of-the-box connection stability. This includes the following:
+
+* The underlying connection pool was tuned for low latency, high throughput workloads. This allows StateFun to reuse
+ existing connections much more aggressively and avoid re-establishing a connection for each request.
+* StateFun applies backpressure once the total number of uncompleted requests reaches a per JVM threshold (``statefun.async.max-per-task``),
+ but observing typical workloads we have discovered that the default value is set too high. In this release the default
+ was reduced to improve stability and resource consumption, in the face of a slow-responding remote function.
+
+### Operational observability of a StateFun Application
+
+One major goal of this release was to take a necessary step towards supporting auto-scaling of remote functions. Towards that end,
+we've exposed several metrics related to workload of remote functions and resulting backpressure applied by the function
+dispatchers. This includes the following:
+
+* Per function type invocation duration / latency histograms
+* Per function type backlog size
+* Per JVM (StateFun worker) and per function type number of in-flight invocations
+
+The full list of metrics and their descriptions can be found [here]({{< param DocsBaseUrl >}}flink-statefun-docs-release-2.2/deployment-and-operations/metrics.html).
+
+### Fine-grained control over remote connection lifecycle
+
+With this release, it's possible to set individual timeouts for overall duration and individual read and write IO operations
+of HTTP requests with remote functions. You can find the corresponding field names in a function spec that defines
+these timeout values [here]({{< param DocsBaseUrl >}}flink-statefun-docs-release-2.2/sdk/index.html#defining-functions).
+
+## 3rd Party SDKs
+
+Since the last release, we've seen new 3rd party SDKs for different languages being implemented on top of StateFun's
+remote function HTTP request-reply protocol, including [Go](https://github.com/sjwiesman/statefun-go/) and [Rust](https://github.com/aljoscha/statefun-rust) implementations. While these SDKs are not
+endorsed or maintained by the Apache Flink PMC and currently not part of the current releases, it is great to see these
+new additions that demonstrate the extensibility of the framework.
+
+For that reason, we've added
+a new [page in the documentation]({{< param DocsBaseUrl >}}flink-statefun-docs-release-2.2/sdk/external.html)
+to list the 3rd party SDKs that the community is aware of. If you've also worked on a new language SDK for StateFun that
+is stable and you plan to continue maintaining, please consider letting the community know of your work by
+submitting a pull request to add your project to the list!
+
+## Important Patch Notes
+
+Below is a list of user-facing interface and configuration changes, dependency version upgrades, or removal of supported versions that would be
+important to be aware of when upgrading your StateFun applications to this version:
+
+* [[FLINK-18812](https://issues.apache.org/jira/browse/FLINK-18812)] The Flink version in StateFun 2.2 has been upgraded to 1.11.1.
+* [[FLINK-19203](https://issues.apache.org/jira/browse/FLINK-19203)] Upgraded Scala version to 2.12, and dropped support for 2.11.
+* [[FLINK-19190](https://issues.apache.org/jira/browse/FLINK-19190)] All existing metric names have been renamed to be camel-cased instead of snake-cased, to conform with the Flink metric naming conventions. **This breaks existing deployments if you depended on previous metrics**.
+* [[FLINK-19192](https://issues.apache.org/jira/browse/FLINK-19192)] The connection pool size for remote function HTTP requests have been increased to 1024, with a stale TTL of 1 minute.
+* [[FLINK-19191](https://issues.apache.org/jira/browse/FLINK-19191)] The default max number of asynchronous operations per JVM (StateFun worker) has been decreased to 1024.
+
+## Release Notes
+
+Please review the [release notes](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12348350)
+for a detailed list of changes and new features if you plan to upgrade your setup to Stateful Functions 2.2.0.
+
+## List of Contributors
+
+The Apache Flink community would like to thank all contributors that have made this release possible:
+
+abc863377, Authuir, Chesnay Schepler, Congxian Qiu, David Anderson, Dian Fu, Francesco Guardiani, Igal Shilman, Marta Paes Moreira, Patrick Wiener, Rafi Aroch, Seth Wiesman, Stephan Ewen, Tzu-Li (Gordon) Tai, Ufuk Celebi
+
+If you’d like to get involved, we’re always [looking for new contributors](https://github.com/apache/flink-statefun#contributing).
+
diff --git a/docs/content.tr/posts/2020-10-13-stateful-serverless-internals.md b/docs/content.tr/posts/2020-10-13-stateful-serverless-internals.md
new file mode 100644
index 0000000000..32993e16ed
--- /dev/null
+++ b/docs/content.tr/posts/2020-10-13-stateful-serverless-internals.md
@@ -0,0 +1,212 @@
+---
+authors:
+- name: Tzu-Li (Gordon) Tai
+ twitter: tzulitai
+ tzulitai: null
+date: "2020-10-13T00:00:00Z"
+excerpt: This blog post dives deep into the internals of the StateFun runtime, taking
+ a look at how it enables consistent and fault-tolerant stateful serverless applications.
+subtitle: A look at how Apache Flink Stateful Functions' runtime enables consistent
+ and fault-tolerant stateful serverless applications
+title: 'Stateful Functions Internals: Behind the scenes of Stateful Serverless'
+aliases:
+- /news/2020/10/13/stateful-serverless-internals.html
+---
+
+Stateful Functions (StateFun) simplifies the building of distributed stateful applications by combining the best of two worlds:
+the strong messaging and state consistency guarantees of stateful stream processing, and the elasticity and serverless experience of today's cloud-native architectures and
+popular event-driven FaaS platforms. Typical StateFun applications consist of functions deployed behind simple services
+using these modern platforms, with a separate StateFun cluster playing the role of an “[event-driven database](https://flink.apache.org/news/2020/04/07/release-statefun-2.0.0.html)”
+that provides consistency and fault-tolerance for the functions' state and messaging.
+
+But how exactly does StateFun achieve that? How does the StateFun cluster communicate with the functions?
+
+This blog dives deep into the internals of the StateFun runtime. The entire walkthrough is complemented by a
+[demo application](https://github.com/tzulitai/statefun-aws-demo/) which can be completely deployed on AWS services.
+Most significantly, in the demo, the stateful functions are deployed and serviced using [AWS Lambda](https://aws.amazon.com/lambda/),
+a popular FaaS platform among many others. The goal here is to allow readers to have a good grasp of the interaction between
+the StateFun runtime and the functions, how that works cohesively to provide a Stateful Serverless experience, and how they can apply
+what they've learnt to deploy their StateFun applications on other public cloud offerings such as GCP or Microsoft Azure.
+
+## Introducing the example: Shopping Cart
+
+
+ Note
+You can find the full code [here](https://github.com/tzulitai/statefun-aws-demo/blob/master/app/shopping_cart.py), which
+uses StateFun's [Python SDK]({{< param DocsBaseUrl >}}flink-statefun-docs-master/sdk/python.html). Alternatively, if you are
+unfamiliar with StateFun's API, you can check out this [earlier blog](https://flink.apache.org/2020/08/19/statefun.html)
+on modeling applications and stateful entities using [StateFun's programming constructs]({{< param DocsBaseUrl >}}flink-statefun-docs-master/concepts/application-building-blocks.html).
+
+
+Let’s first take a look at a high-level overview of the motivating demo for this blog post: a shopping cart application.
+The diagram below covers the functions that build up the application, the state that the functions would keep, and the messages
+that flow between them. We’ll be referencing this example throughout the blog post.
+
+
+
+
+ Fig.1: An overly simplified shopping cart application.
+
+
+
+
+The application consists of two function types: a `cart` function and an `inventory` function.
+Each instance of the `cart` function is associated with a single user entity, with its state being the items in the cart
+for that user (`ItemsInCart`). In the same way, each instance of the `inventory` function represents a single inventory,
+maintaining as state the number of items in stock (`NumInStock`) as well as the number of items reserved across all
+user carts (`NumReserved`). Messages can be sent to function instances using their logical addresses, which consists
+of the function type and the instance's entity ID, e.g. `(cart:Kim)` or `(inventory:socks)`.
+
+There are two external messages being sent to and from the shopping cart application via ingresses and egresses:
+`AddToCart`, which is sent to the ingress when an item is added to a user’s cart (e.g. sent by a front-end web application),
+and `AddToCartResult`, which is sent back from our application to acknowledge the action.
+
+`AddToCart` messages are handled by the `cart` function, which in turn invokes other functions to form the main logic of the application.
+To keep things simple, only two messages between functions are demonstrated: `RequestItem`, sent from the `cart` function to the `inventory`
+function, representing a request to reserve an item, and `ItemReserved`, which is a response from the inventory function to acknowledge the request.
+
+## What happens in the Stateful Functions runtime?
+
+Now that we understand the business logic of the shopping cart application, let's take a closer look at what keeps the state
+of the functions and messages sent between them consistent and fault-tolerant: the StateFun cluster.
+
+
+
+ Fig.2: Simplified view of a StateFun app deployment.
+
+
+The StateFun runtime is built on-top of Apache Flink, and applies the same battle-tested technique that Flink uses as the
+basis for strongly consistent stateful streaming applications - co-location of state and messaging .
+In a StateFun application, all messages are routed through the StateFun cluster, including messages sent from ingresses,
+messages sent between functions, and messages sent from functions to egresses. Moreover, the state of all functions is
+maintained in the StateFun cluster as well. Like Flink, the message streams flowing through the StateFun cluster and
+function state are co-partitioned so that compute has local state access, and any updates to the state can be handled
+atomically with computed side-effects, i.e. messages to send to other functions.
+
+In more solid terms, take for example a message that is targeted for the logical address `(cart, "Kim")` being routed
+through StateFun. Logical addresses are used in StateFun as the partitioning key for both message streams and state, so
+that the resulting StateFun cluster partition that this message ends up in will have the state for `(cart, "Kim")`
+locally available.
+
+The only difference here for StateFun, compared to Flink, is that the actual compute doesn't happen within the StateFun
+cluster partitions - computation happens remotely in the function services . So how does StateFun
+route input messages to the remote function services and provide them with state access, all the while
+preserving the same consistency guarantees as if state and compute were co-located?
+
+### Remote Invocation Request-Reply Protocol
+
+A StateFun cluster partition communicates with the functions using a slim and well-defined request-reply protocol, as
+illustrated in **Fig. 3**. Upon receiving an input message, the cluster partition invokes the target functions via their
+HTTP service endpoint. The service request body carries input events and current state for the functions, retrieved from
+local state. Any outgoing messages and state mutations as a result of invocations are sent back through StateFun as part
+of the service response. When the StateFun cluster partition receives the response, all state mutations are written back
+to local state and outgoing messages are routed to other cluster partitions, which in turn invokes other function
+services.
+
+
+
+
+ Fig.3: The remote invocation request/reply protocol.
+
+
+
+
+Under the hood, StateFun SDKs like the Python SDK and other [3rd party SDKs for other languages]({{< param DocsBaseUrl >}}flink-statefun-docs-master/sdk/external.html)
+all implement this protocol. From the user's perspective, they are programming with state local to their function deployment,
+whereas in reality, state is maintained in StateFun and supplied through this protocol. It is easy to add more language SDKs,
+as long as the language can handle HTTP requests and responses.
+
+### Function state consistency and fault-tolerance
+
+The runtime makes sure that only one invocation per function instance (e.g. `(cart, "Kim")`) is ongoing at any point in
+time (i.e. invocations per entity are serial). If an invocation is ongoing while new messages for the same function
+instance arrives, the messages are buffered in state and sent as a single batch as soon as the ongoing invocation completes.
+
+In addition, since each request happens in complete isolation and all relevant information is encapsulated in each
+request and response, function invocations are effectively idempotent
+(i.e. results depend purely on the provided context of the invocation) and can be retried. This naturally avoids
+violating consistency in case any function service hiccups occur.
+
+For fault tolerance, all function state managed in the StateFun cluster is periodically and asynchronously checkpointed
+to a blob storage (e.g. HDFS, S3, GCS) using Flink’s [original distributed snapshot mechanism]({{< param DocsBaseUrl >}}flink-docs-master/concepts/stateful-stream-processing.html#checkpointing).
+These checkpoints contain a globally consistent view of state across all functions of the application ,
+including the offset positions in ingresses and the ongoing transaction state in egresses. In the case of an abrupt failure,
+the system may restore from the latest available checkpoint: all function states will be restored and all events between
+the checkpoint and the crash will be re-processed (and the functions re-invoked) with identical routing, all as if the failure
+never happened.
+
+### Step-by-step walkthrough of function invocations
+
+Let's conclude this section by going through the actual messages that flow between StateFun and the functions in our shopping
+cart demo application!
+
+Customer "Kim" puts 2 socks into his shopping cart (Fig. 4):
+
+
+
+
+ Fig.4: Message flow walkthrough.
+
+
+
+
+* An event `AddToCart("Kim", "socks", 2)` comes through one of the ingress partitions `(1)` . The ingress event router is
+configured to route `AddToCart` events to the function type `cart`, taking the user ID (`"Kim"`) as the instance ID. The
+function type and instance ID together define the logical address of the target function instance for the event `(cart:Kim)`.
+
+* Let's assume the event is read by StateFun partition B, but the `(cart:Kim)` address is owned by partition A.
+The event is thus routed to partition A `(2)` .
+
+* StateFun Partition A receives the event and processes it:
+ - First, the runtime fetches the state for `(cart:Kim)` from the local state store, i.e. the existing items in Kim’s cart `(3)` .
+ - Next, it marks `(cart:Kim)` as "busy" , meaning an invocation is happening. This buffers other messages targeted for
+ `(cart:Kim)` in state until this invocation is completed.
+ - The runtime grabs a free HTTP client connection and sends a request to the `cart` function type's service endpoint.
+ The request contains the `AddToCart("Kim", "socks", 2)` message and the current state for `(cart:Kim)` `(4)` .
+ - The remote `cart` function service receives the event and attempts to reserve socks with the `inventory` function.
+ Therefore, it replies to the invocation with a new message `RequestItem("socks", 2)` targeted at the address `(inventory:socks)`.
+ Any state modifications will be included in the response as well, but in this case there aren’t any state modifications yet
+ (i.e. Kim’s cart is still empty until a reservation acknowledgement is received from the inventory service) `(5)` .
+ - The StateFun runtime receives the response, routes the `RequestItem` message to other partitions,
+ and marks `(cart:Kim)` as "available" again for invocation.
+
+
+* Assuming that the `(inventory:socks)` address is owned by partition B, the message is routed to partition B `(6)` .
+
+* Once partition B receives the `RequestItem` message, the runtime invokes the function `(inventory:socks)` in the same
+way as described above, and receives a reply with a modification of the state of the inventory (the number of reserved socks is now increased by 2).
+`(inventory:socks)` now also wants to reply reservation of 2 socks for Kim, so an `ItemReserved("socks", 2)`
+message targeted for `(cart:Kim)` is also included in the response `(7)` , which will again be routed by the StateFun runtime.
+
+## Stateful Serverless in the Cloud with FaaS and StateFun
+
+We'd like to wrap up this blog by re-emphasizing how the StateFun runtime works well with cloud-native
+architectures, and provide an overview of what your complete StateFun application deployment would look like
+using public cloud services.
+
+As you've already learnt in previous sections, invocation requests themselves are stateless, with all necessary information
+for an invocation included in the HTTP request (i.e. input events and state access), and all side-effects of the invocation
+included in the HTTP response (i.e. outgoing messages and state modifications).
+
+
+
+ Fig.5: Complete deployment example on AWS.
+
+
+A natural consequence of this characteristic is that there is no session-related dependency between individual HTTP
+requests, making it very easy to horizontally scale the function deployments. This makes it very easy to deploy your
+stateful functions using FaaS platforms solutions, allowing them to rapidly scale out, scale to zero, or be upgraded
+with zero-downtime.
+
+In our complementary demo code, you can find [here](https://github.com/tzulitai/statefun-aws-demo/blob/master/app/shopping_cart.py#L49)
+the exact code on how to expose and service StateFun functions through AWS Lambda. Likewise, this is possible for any other
+FaaS platform that supports triggering the functions using HTTP endpoints (and other transports as well in the future).
+
+**Fig. 5** on the right illustrates what a complete AWS deployment of a StateFun application would look like, with functions
+serviced via AWS Lambda, AWS Kinesis streams as ingresses and egresses, AWS EKS managed Kubernetes cluster to run the
+StateFun cluster, and an AWS S3 bucket to store the periodic checkpoints. You can also follow the
+[instructions](https://github.com/tzulitai/statefun-aws-demo#running-the-demo) in the demo code to try it out and deploy this yourself right away!
+
+---
+
+If you’d like to learn more about Stateful Functions, head over to the [official documentation]({{< param DocsBaseUrl >}}flink-statefun-docs-master/), where you can also find more hands-on tutorials to try out yourself!
diff --git a/docs/content.tr/posts/2020-10-15-from-aligned-to-unaligned-checkpoints-part-1.md b/docs/content.tr/posts/2020-10-15-from-aligned-to-unaligned-checkpoints-part-1.md
new file mode 100644
index 0000000000..9565ede1be
--- /dev/null
+++ b/docs/content.tr/posts/2020-10-15-from-aligned-to-unaligned-checkpoints-part-1.md
@@ -0,0 +1,134 @@
+---
+authors:
+- Arvid Heise: null
+ name: Arvid Heise
+- Stephan Ewen: null
+ name: Stephan Ewen
+date: "2020-10-15T03:00:00Z"
+excerpt: Apache Flink’s checkpoint-based fault tolerance mechanism is one of its defining
+ features. Because of that design, Flink unifies batch and stream processing, can
+ easily scale to both very small and extremely large scenarios and provides support
+ for many operational features. In this post we recap the original checkpointing
+ process in Flink, its core properties and issues under backpressure.
+title: 'From Aligned to Unaligned Checkpoints - Part 1: Checkpoints, Alignment, and
+ Backpressure'
+aliases:
+- /2020/10/15/from-aligned-to-unaligned-checkpoints-part-1.html
+---
+
+Apache Flink’s checkpoint-based fault tolerance mechanism is one of its defining features. Because of that design, Flink unifies batch and stream processing, can easily scale to both [very small](https://hal.inria.fr/hal-02463206/document) and [extremely large](https://102.alibaba.com/detail?id=35) scenarios and provides support for many operational features like stateful upgrades with [state evolution]({{< param DocsBaseUrl >}}flink-docs-stable/dev/stream/state/schema_evolution.html) or [roll-backs and time-travel]({{< param DocsBaseUrl >}}flink-docs-stable/ops/state/savepoints.html).
+
+Despite all these great properties, Flink's checkpointing method has an Achilles Heel: the speed of a completed checkpoint is determined by the speed at which data flows through the application. When the application backpressures, the processing of checkpoints is backpressured as well ([Appendix 1](#appendix-1---on-backpressure) recaps what is backpressure and why it can be a good thing). In such cases, checkpoints may take longer to complete or even time out completely.
+
+In Flink 1.11, the community introduced a first version of a new feature called "[unaligned checkpoints]({{< param DocsBaseUrl >}}flink-docs-stable/ops/state/checkpoints.html#unaligned-checkpoints)" that aims at solving this issue, while Flink 1.12 plans to further expand its functionality. In this two-series blog post, we discuss how Flink’s checkpointing mechanism has been modified to support unaligned checkpoints, how unaligned checkpoints work, and how this new mode impacts Flink users. In the first of the two posts, we start with a recap of the original checkpointing process in Flink, its core properties and issues under backpressure.
+
+
+# State in Streaming Applications
+
+Simply put, state is the information that you need to remember across events. Even the most trivial streaming applications are typically stateful because of their need to “remember” the exact position they are processing data from, for example in the form of a Kafka Partition Offset or a File Offset.
+In addition, many applications hold state internally as a way to support their internal operations, such as windows, aggregations, joins, or state machines.
+
+For the remainder of this article, we'll use the following example showing a streaming application consisting of **four operators**, each one holding some state.
+
+
+
+
+
+
+
+## State Persistence through Checkpoints
+
+Streaming applications are long-lived. They inevitably experience hardware and software failures but should, ideally, look from the outside as if no failure ever happened. Since applications are long-lived — and can potentially accumulate very large state —, recomputing partial results after failures can take quite some time, and so a way to persist and recover this (potentially very large) application state is necessary.
+
+Flink relies on its **state checkpointing and recovery mechanism** to implement such behavior, as shown in the figure below. Periodic checkpoints store a snapshot of the application’s state on some Checkpoint Storage (commonly an Object Store or Distributed File System, like S3, HDFS, GCS, Azure Blob Storage, etc.). When a failure is detected, the affected parts of the application are reset to the state of the latest checkpoint (either by a local reset or by loading the state from the checkpoint storage).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Flink’s checkpoint-based approach differs from the approach taken by other stream processing systems that keep state in a distributed database or write state changes to a log, for example. The checkpoint-based approach has some nice properties, described below, which make it a great option for Flink.
+
+- **Checkpointing has very simple external dependencies**: An _Object Storage_ or a _Distributed FileSystem_ are probably the most available and easiest-to-administer services. Because these are available on all public cloud providers and among the first systems to provide on-premises, Flink becomes well-suited for a _cloud-native_ stack. In addition, these storage systems are cheaper by an order of magnitude (GB/month) when compared to distributed databases, key/value stores, or event brokers.
+
+- **Checkpoints are immutable and versioned**: Together with immutable and versioned inputs (as input streams are, by nature), checkpoints support storing immutable application snapshots that can be used for rollbacks, debugging, testing, or as a cheap alternative to analyze application state outside the production setup.
+
+
+- **Checkpoints decouple the “stream transport” from the persistence mechanism**: “Stream transport” refers to how data is being exchanged between operators (e.g. during a shuffle). This decoupling is key to Flink’s batch <-> streaming unification in one system, because it allows Flink to implement a data transport that can take the shape of both a low-latency streaming exchange or a decoupled batch data exchange.
+
+# The Checkpointing Mechanism
+
+The fundamental challenge solved by the checkpointing algorithm (details in [this paper](https://pdfs.semanticscholar.org/6fa0/917417d3c213b0e130ae01b7b440b1868dde.pdf)) is drawing a snapshot out of the ever-changing state of a streaming application without suspending the continuous processing of events. Because there are always events in-flight (on the network, in I/O buffers, etc.), up- and downstream operators can be processing events from different times: the sink may write data from 11:04, while the source already ingests events from 11:06. Ideally, all snapshotted data should belong to the same point-in-time, as if the input was paused and we waited until all in-flight data was drained (i.e. the pipeline becoming idle) before taking the snapshot.
+
+To achieve that, Flink injects *checkpoint barriers* into the streams at the sources, which travel through the entire topology and eventually reach the sinks. These barriers divide the stream into a *pre-checkpoint epoch* (all events that are persisted in state or emitted into sinks) and a *post-checkpoint epoch* (events not reflected in the state, to be re-processed when resuming from the checkpoint).
+
+The following figure shows what happens when a barrier reaches an operator.
+
+
+
+
+
+
+
+Operators need to make sure that they take the checkpoint exactly when all pre-checkpoint events are processed and no post-checkpoint events have yet been processed. When the first barrier reaches the head of the input buffer queue and is consumed by the operator, the operator starts the so-called *alignment phase*. During that phase, the operator will not consume any data from the channels where it already received a barrier, until it has received a barrier from all input channels.
+
+Once all barriers are received, the operator snapshots its state, forwards the barrier to the output, and ends the alignment phase, which unblocks all inputs. An operator state snapshot is written into the checkpoint storage, typically asynchronously while data processing continues. Once all operators have successfully written their state snapshot to the checkpoint storage, the checkpoint is successfully completed and can be used for recovery.
+
+One important thing to note here is that the barriers flow with the events, strictly in line. In a healthy setup without backpressure, barriers flow and align in milliseconds. The checkpoint duration is dominated by the time it takes to write the state snapshots to the checkpoint storage, which becomes faster with [incremental checkpoints]({{< param DocsBaseUrl >}}flink-docs-stable/ops/state/large_state_tuning.html#incremental-checkpoints). If the events flow slowly under backpressure, so will the barriers. That means that barriers can take long to travel from sources to sinks resulting in the alignment phase to take even longer to complete.
+
+## Recovery
+
+When operators restart from a checkpoint (automatically during recovery or manually during deployment from a savepoint), the operators first restore their state from the checkpoint storage before resuming the event stream processing.
+
+
+
+
+
+
+
+Since sources are bound to the offsets persisted in the checkpoint, recovery time is often calculated as the sum of the time of the recovery process — outlined in the previous figure — and any additional time needed to process any remaining data up to the point right before the system failure. When an application experiences backpressure, recovery time can also include the total time from the very start of the recovery process until backpressure is fully eliminated.
+
+## Consistency Guarantees
+
+The alignment phase is only necessary for checkpoints with __exactly-once__ processing semantics, which is the default setting in Flink. If an application runs with __at-least-once__ processing semantics, checkpoints will not block any channels with barriers during alignment, which has an additional cost from the duplication of the then-not-blocked events when recovering the operator.
+
+This is not to be confused with having at-least-once semantics only in the sinks — something that many Flink users choose over transactional sinks — because many sink operations are idempotent or converge to the same result (like inputs/outputs to key/value stores). Having at-least-once semantics in an intermediate operator state is often not idempotent (for example a simple count aggregation) and hence using exactly-once checkpoints is advisable for the majority of Flink users.
+
+# Conclusion
+
+This blog post recaps how Flink’s fault tolerance mechanism (based on aligned checkpoints) works, and why checkpointing is a fitting mechanism for a fault-tolerant stream processor. The checkpointing mechanism has been optimized over time to make checkpoints faster and cheaper (with both asynchronous and incremental checkpoints) and faster-to-recover (local caching), but the basic concepts (barriers, alignment, operator state snapshots) are still the same as in the original version.
+
+The next part will dig into a major break with the original mechanism that avoids the alignment phase — the recently-introduced "unaligned checkpoints". Stay tuned for the second part, which explains how unaligned checkpoints work and how they guarantee consistent checkpointing times under backpressure.
+
+
+
+## Appendix 1 - On Backpressure
+
+Backpressure refers to the behavior where a slow receiver (e.g. of data/requests) makes the senders slow down in order to not overwhelm the receiver, something that can result in possibly dropping some of the processed data or requests. This is a crucial and very much desirable behavior for systems where completeness/correctness is important. Backpressure is implicitly implemented in many of the most basic building blocks of distributed communication, such as TCP Flow Control, bounded (blocking) I/O queues, poll-based consumers, etc.
+
+Apache Flink implements backpressure across the entire data flow graph. A sink that (temporarily) cannot keep up with the data rate will result in the source connectors slowing down and pulling data out of the source systems more slowly. We believe that this is a good and desirable behavior, because backpressure is not only necessary in order to avoid overwhelming the memory of a receiver (thread), but can also prevent different stages of the streaming application from drifting apart too far.
+
+Consider the example below:
+- We have a source (let’s say reading data from Apache Kafka), parsing data, grouping and aggregating data by a key, and writing it to a sink system (some database).
+- The application needs to re-group data by key between the parsing and the grouping/aggregation step.
+
+
+
+
+
+
+
+Let’s assume we use a __non-backpressure approach__, like writing the data to a log/MQ for the data re-grouping over the network (the approach used by [Kafka Streams](https://docs.confluent.io/current/streams/architecture.html#backpressure)). If the sink is now slower than the remaining parts of the streaming application (which can easily happen), the first stage (source and parse) will still work as fast as possible to pull data out of the source, parse it, and put it into the log for the shuffle. That intermediate log will accumulate a lot of data, meaning it needs significant capacity, so that in a worst case scenario can hold a full copy of the input data or otherwise result in data loss (when the drift is greater than the retention time).
+
+__With backpressure__, the source/parse stage slows down to match the speed of the sink, keeping both parts of the application closer together in their progress through the data, and avoiding the need to provision a lot of intermediate storage capacity.
+
+
+
+We'd like to thank Marta Paes Moreira and Markos Sfikas for the wonderful review process.
diff --git a/docs/content.tr/posts/2020-11-11-release-statefun-2.2.1.md b/docs/content.tr/posts/2020-11-11-release-statefun-2.2.1.md
new file mode 100644
index 0000000000..fd33a82b48
--- /dev/null
+++ b/docs/content.tr/posts/2020-11-11-release-statefun-2.2.1.md
@@ -0,0 +1,66 @@
+---
+authors:
+- name: Tzu-Li (Gordon) Tai
+ twitter: tzulitai
+ tzulitai: null
+date: "2020-11-11T00:00:00Z"
+title: Stateful Functions 2.2.1 Release Announcement
+aliases:
+- /news/2020/11/11/release-statefun-2.2.1.html
+---
+
+The Apache Flink community released the first bugfix release of the Stateful Functions (StateFun) 2.2 series, version 2.2.1.
+
+This release fixes a critical bug that causes restoring the Stateful Functions cluster from snapshots (checkpoints or
+savepoints) to fail under certain conditions. Starting from this release, StateFun now creates snapshots with a more
+robust format that allows it to be restored safely going forward.
+
+We strongly recommend all users to upgrade to 2.2.1 . Please see the following sections on instructions and things to
+keep in mind for this upgrade.
+
+## For new users just starting out with Stateful Functions
+
+We strongly recommend to skip all previous versions and start using StateFun from version 2.2.1.
+This guarantees that failure recovery from checkpoints, or application upgrades using savepoints will work as expected for you.
+
+## For existing users on versions <= 2.2.0
+
+Users that are currently using older versions of StateFun may or may not be able to directly upgrade to 2.2.1 using
+savepoints taken with the older versions. The Flink community is working hard on a follow-up hotfix release, 2.2.2,
+that would guarantee that you can perform the upgrade smoothly . For the meantime, you may still try to upgrade to 2.2.1
+first, but may encounter [FLINK-19741](https://issues.apache.org/jira/browse/FLINK-19741) or
+[FLINK-19748](https://issues.apache.org/jira/browse/FLINK-19748). If you do encounter this, do not worry about data
+loss; this simply means that the restore failed, and you’d have to wait until 2.2.2 is out in order to upgrade.
+
+The follow-up hotfix release 2.2.2 is expected to be ready within another 2~3 weeks, as it [requires a new hotfix release
+from Flink core](http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-Releasing-Apache-Flink-1-11-3-td45989.html),
+and ultimately an upgrade of the Flink dependency in StateFun. We’ll update the community via the Flink
+mailing lists as soon as this is ready, so please subscribe to the mailing lists for important updates for this!
+
+---
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+This release includes 6 fixes and minor improvements since StateFun 2.2.0. Below is a detailed list of all fixes and improvements:
+
+ Bug
+
+
+[FLINK-19515 ] - Async RequestReply handler concurrency bug
+
+[FLINK-19692 ] - Can't restore feedback channel from savepoint
+
+[FLINK-19866 ] - FunctionsStateBootstrapOperator.createStateAccessor fails due to uninitialized runtimeContext
+
+
+
+ Improvement
+
+
+[FLINK-19826 ] - StateFun Dockerfile copies plugins with a specific version instead of a wildcard
+
+[FLINK-19827 ] - Allow the harness to start with a user provided Flink configuration
+
+[FLINK-19840 ] - Add a rocksdb and heap timers configuration validation
+
+
diff --git a/docs/content.tr/posts/2020-12-02-pipelined-region-sheduling.md b/docs/content.tr/posts/2020-12-02-pipelined-region-sheduling.md
new file mode 100644
index 0000000000..be06ebb860
--- /dev/null
+++ b/docs/content.tr/posts/2020-12-02-pipelined-region-sheduling.md
@@ -0,0 +1,285 @@
+---
+authors:
+- Andrey: null
+ name: Andrey Zagrebin
+date: "2020-12-02T08:00:00Z"
+excerpt: In this blogpost, we’ll take a closer look at how far the community has come
+ in improving task scheduling for batch workloads, why this matters and what you
+ can expect in Flink 1.12 with the new pipelined region scheduler.
+title: Improvements in task scheduling for batch workloads in Apache Flink 1.12
+aliases:
+- /2020/12/15/pipelined-region-sheduling.html
+---
+
+The Flink community has been working for some time on making Flink a
+[truly unified batch and stream processing system](https://flink.apache.org/news/2019/02/13/unified-batch-streaming-blink.html).
+Achieving this involves touching a lot of different components of the Flink stack, from the user-facing APIs all the way
+to low-level operator processes such as task scheduling. In this blogpost, we’ll take a closer look at how far
+the community has come in improving scheduling for batch workloads, why this matters and what you can expect in the
+Flink 1.12 release with the new _pipelined region scheduler_.
+
+# Towards unified scheduling
+
+Flink has an internal [scheduler](#what-is-scheduling) to distribute work to all available cluster nodes, taking resource utilization, state locality and recovery into account.
+How do you write a scheduler for a unified batch and streaming system? To answer this question,
+let's first have a look into the high-level differences between batch and streaming scheduling requirements.
+
+#### Streaming
+
+_Streaming_ jobs usually require that all _[operator subtasks](#executiongraph)_ are running in parallel at the same time, for an indefinite time.
+Therefore, all the required resources to run these jobs have to be provided upfront, and all _operator subtasks_ must be deployed at once.
+
+
+
+
+Flink: Streaming job example
+
+
+
+Because there are no finite intermediate results, a _streaming job_ always has to be restarted fully from a checkpoint or a savepoint in case of failure.
+
+
+ Note
+A _streaming job_ may generally consist of multiple disjoint pipelines which can be restarted independently.
+Hence, the full job restart is not required in this case but you can think of each disjoint pipeline as if it were a separate job.
+
+
+#### Batch
+
+In contrast to _streaming_ jobs, _batch_ jobs usually consist of one or more stages that can have dependencies between them.
+Each stage will only run for a finite amount of time and produce some finite output (i.e. at some point, the batch job will be _finished_).
+Independent stages can run in parallel to improve execution time, but for cases where there are dependencies between stages,
+a stage may have to wait for upstream results to be produced before it can run.
+These are called _[blocking results](#intermediate-results)_, and in this case stages cannot run in parallel.
+
+
+
+
+Flink: Batch job example
+
+
+
+As an example, in the figure above **Stage 0** and **Stage 1** can run simultaneously, as there is no dependency between them.
+**Stage 3**, on the other hand, can only be scheduled once both its inputs are available. There are a few implications from this:
+
+* **(a)** You can use available resources more efficiently by only scheduling stages that have data to perform work;
+
+* **(b)** You can use this mechanism also for failover: if a stage fails, it can be restarted individually, without recomputing the results of other stages.
+
+### Scheduling Strategies in Flink before 1.12
+
+Given these differences, a unified scheduler would have to be good at resource management for each individual stage,
+be it finite (_batch_) or infinite (_streaming_), and also across multiple stages.
+The existing [scheduling strategies](#scheduling-strategy) in older Flink versions up to 1.11 have been largely designed to address these concerns separately.
+
+**“All at once (Eager)”**
+
+This strategy is the simplest: Flink just tries to allocate resources and deploy all _subtasks_ at once.
+Up to Flink 1.11, this is the scheduling strategy used for all _streaming_ jobs.
+For _batch_ jobs, using “all at once” scheduling would lead to suboptimal resource utilization,
+since it’s unlikely that such jobs would require all resources upfront, and any resources allocated to subtasks
+that could not run at a given moment would be idle and therefore wasted.
+
+**“Lazy from sources”**
+
+To account for _blocking results_ and make sure that no consumer is deployed before their respective producers are finished,
+Flink provides a different scheduling strategy for _batch_ workloads.
+“Lazy from sources” scheduling deploys subtasks only once all their inputs are ready.
+This strategy operates on each _subtask_ individually; it does not identify all _subtasks_ which can (or have to) run at the same time.
+
+### A practical example
+
+Let’s take a closer look at the specific case of _batch_ jobs, using as motivation a simple SQL query:
+
+```SQL
+CREATE TABLE customers (
+ customerId int,
+ name varchar(255)
+);
+
+CREATE TABLE orders (
+ orderId int,
+ orderCustomerId int
+);
+
+--fill tables with data
+
+SELECT customerId, name
+FROM customers, orders
+WHERE customerId = orderCustomerId
+```
+
+Assume that two tables were created in some database: the `customers` table is relatively small and fits into the local memory (or also on disk). The `orders` table is bigger, as it contains all orders created by customers, and doesn’t fit in memory. To enrich the orders with the customer name, you have to join these two tables. There are basically two stages in this _batch_ job:
+
+1. Load the complete `customers` table into a local map: `(customerId, name)`; because this table is smaller,
+2. Process the `orders` table record by record, enriching it with the `name` value from the map.
+
+#### Executing the job
+
+The batch job described above will have three operators. For simplicity, each operator is represented with a parallelism of 1,
+so the resulting _[ExecutionGraph](#executiongraph)_ will consist of three _subtasks_: A, B and C.
+
+* **A**: load full `customers` table
+* **B**: load `orders` table record by record in a _streaming_ (pipelined) fashion
+* **C**: join order table records with the loaded customer table
+
+This translates into **A** and **C** being connected with a _blocking_ data exchange,
+because the `customers` table needs to be loaded locally (**A**) before we start processing the order table (**B**).
+**B** and **C** are connected with a _[pipelined](#intermediate-results)_ data exchange,
+because the consumer (**C**) can run as soon as the first result records from **B** have been produced.
+You can think of **B->C** as a _finite streaming_ job. It’s then possible to identify two separate stages within the _ExecutionGraph_: **A** and **B->C**.
+
+
+
+
+Flink: SQL Join job example
+
+
+
+#### Scheduling Limitations
+
+Imagine that the cluster this job will run in has only one _[slot](#slots-and-resources)_ and can therefore only execute one _subtask_.
+If Flink deploys **B** _[chained](#slots-and-resources)_ with **C** first into this one _slot_ (as **B** and **C** are connected with a _[pipelined](#intermediate-results)_ edge),
+**C** cannot run because A has not produced its _blocking result_ yet. Flink will try to deploy **A** and the job will fail, because there are no more _slots_.
+If there were two _slots_ available, Flink would be able to deploy **A** and the job would eventually succeed.
+Nonetheless, the resources of the first _slot_ occupied by **B** and **C** would be wasted while **A** was running.
+
+Both scheduling strategies available as of Flink 1.11 (_“all at once”_ and _“lazy from source”_) would be affected by these limitations.
+What would be the optimal approach? In this case, if **A** was deployed first, then **B** and **C** could also complete afterwards using the same _slot_.
+The job would succeed even if only a single _slot_ was available.
+
+
+ Note
+If we could load the `orders` table into local memory (making B -> C blocking), then the previous strategy would also succeed with one slot.
+Nonetheless, we would have to allocate a lot of resources to accommodate the table locally, which may not be required.
+
+
+Last but not least, let’s consider what happens in the case of _failover_: if the processing of the `orders` table fails (**B->C**),
+then we do not have to reload the customer table (**A**); we only need to restart **B->C**. This did not work prior to Flink 1.9.
+
+To satisfy the scheduling requirements for _batch_ and _streaming_ and overcome these limitations,
+the Flink community has worked on a new unified scheduling and failover strategy that is suitable for both types of workloads: _pipelined region scheduling_.
+
+# The new pipelined region scheduling
+
+As you read in the previous introductory sections, an optimal [scheduler](#what-is-scheduling) should efficiently allocate resources
+for the sub-stages of the pipeline, finite or infinite, running in a _streaming_ fashion. Those stages are called _pipelined regions_ in Flink.
+In this section, we will take a deeper dive into _pipelined region scheduling and failover_.
+
+## Pipelined regions
+
+The new scheduling strategy analyses the _[ExecutionGraph](#executiongraph)_ before starting the _subtask_ deployment in order to identify its _pipelined regions_.
+A _pipelined region_ is a subset of _subtasks_ in the _ExecutionGraph_ connected by _[pipelined](#intermediate-results)_ data exchanges.
+_Subtasks_ from different _pipelined regions_ are connected only by _[blocking](#intermediate-results)_ data exchanges.
+The depicted example of an _ExecutionGraph_ has four _pipelined regions_ and _subtasks_, A to H:
+
+
+
+
+Flink: Pipelined regions
+
+
+
+Why do we need the _pipelined region_? Within the _pipelined region_ all consumers have to constantly consume the produced results
+to not block the producers and avoid backpressure. Hence, all _subtasks_ of a _pipelined region_ have to be scheduled, restarted in case of failure and run at the same time.
+
+
+ Note (out of scope)
+In certain cases the _subtasks_ can be connected by _[blocking](#intermediate-results)_ data exchanges within one region.
+Check [FLINK-17330](https://issues.apache.org/jira/browse/FLINK-17330) for details.
+
+
+## Pipelined region scheduling strategy
+
+Once the _pipelined regions_ are identified, each region is scheduled only when all the regions it depends on (i.e. its inputs),
+have produced their _[blocking](#intermediate-results)_ results (for the depicted graph: R2 and R3 after R1; R4 after R2 and R3).
+If the _JobManager_ has enough resources available, it will try to run as many schedulable _pipelined regions_ in parallel as possible.
+The _subtasks_ of a _pipelined region_ are either successfully deployed all at once or none at all.
+The job fails if there are not enough resources to run any of its _pipelined regions_.
+You can read more about this effort in the original [FLIP-119 proposal](https://cwiki.apache.org/confluence/display/FLINK/FLIP-119+Pipelined+Region+Scheduling#FLIP119PipelinedRegionScheduling-BulkSlotAllocation).
+
+## Failover strategy
+
+As mentioned before, only certain regions are running at the same time. Others have already produced their _[blocking](#intermediate-results)_ results.
+The results are stored locally in _TaskManagers_ where the corresponding _subtasks_ run.
+If a currently running region fails, it gets restarted to consume its inputs again.
+If some input results got lost (e.g. the hosting _TaskManager_ failed as well), Flink will rerun their producing regions.
+You can read more about this effort in the [user documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/task_failure_recovery.html#failover-strategies)
+and the original [FLIP-1 proposal](https://cwiki.apache.org/confluence/display/FLINK/FLIP-1+%3A+Fine+Grained+Recovery+from+Task+Failures).
+
+## Benefits
+
+**Run any batch job, possibly with limited resources**
+
+The _subtasks_ of a _pipelined region_ are deployed only when all necessary conditions for their success are fulfilled:
+inputs are ready and all needed resources are allocated. Hence, the _batch_ job never gets stuck without notifying the user.
+The job either eventually finishes or fails after a timeout.
+
+Depending on how the _subtasks_ are allowed to [share slots]({{< param DocsBaseUrl >}}flink-docs-release-1.11/dev/stream/operators/#task-chaining-and-resource-groups),
+it is often the case that the whole _pipelined region_ can run within one _slot_,
+making it generally possible to run the whole _batch_ job with only a single _slot_.
+At the same time, if the cluster provides more resources, Flink will run as many regions as possible in parallel to improve the overall job performance.
+
+**No resource waste**
+
+As mentioned in the definition of _pipelined region_, all its _subtasks_ have to run simultaneously.
+The _subtasks_ of other regions either cannot or do not have to run at the same time.
+This means that a _pipelined region_ is the minimum subgraph of a _batch_ job’s _ExecutionGraph_ that has to be scheduled at once.
+There is no way to run the job with fewer resources than needed to run the largest region, and so there can be no resource waste.
+
+
+ Note (out of scope)
+The amount of resources required to run a region can be further optimized separately.
+It depends on _co-location constraints_ and _slot sharing groups_ of the region’s _subtasks_.
+Check [FLINK-18689](https://issues.apache.org/jira/browse/FLINK-18689) for details.
+
+
+# Conclusion
+
+Scheduling is a fundamental component of the Flink stack. In this blogpost, we recapped how scheduling affects resource utilization and failover as a part of the user experience.
+We described the limitations of Flink’s old scheduler and introduced a new approach to tackle them: the _pipelined region scheduler_, which ships with Flink 1.12.
+The blogpost also explained how _pipelined region failover_ (introduced in Flink 1.11) works.
+
+Stay tuned for more improvements to scheduling in upcoming releases. If you have any suggestions or questions for the community,
+we encourage you to sign up to the Apache Flink [mailing lists](https://flink.apache.org/community.html#mailing-lists) and become part of the discussion.
+
+# Appendix
+
+## What is scheduling?
+
+### ExecutionGraph
+
+A Flink _job_ is a pipeline of connected _operators_ to process data.
+Together, the operators form a _[JobGraph]({{< param DocsBaseUrl >}}flink-docs-release-1.11/internals/job_scheduling.html#jobmanager-data-structures)_.
+Each _operator_ has a certain number of _subtasks_ executed in parallel. The _subtask_ is the actual execution unit in Flink.
+Each subtask can consume user records from other subtasks (inputs), process them and produce records for further consumption by other _subtasks_ (outputs) down the stream.
+There are _source subtasks_ without inputs and _sink subtasks_ without outputs. Hence, the _subtasks_ form the nodes of the
+_[ExecutionGraph]({{< param DocsBaseUrl >}}flink-docs-release-1.11/internals/job_scheduling.html#jobmanager-data-structures)_.
+
+
+### Intermediate results
+
+There are also two major data-exchange types to produce and consume results by _operators_ and their _subtasks_: _pipelined_ and _blocking_.
+They are basically types of edges in the _ExecutionGraph_.
+
+A _pipelined_ result can be consumed record by record. This means that the consumer can already run once the first result records have been produced.
+A _pipelined_ result can be a never ending output of records, e.g. in case of a _streaming job_.
+
+A _blocking_ result can be consumed only when its _production_ is done. Hence, the _blocking_ result is always finite
+and the consumer of the _blocking_ result can run only when the producer has finished its execution.
+
+### Slots and resources
+
+A _[TaskManager]({{< param DocsBaseUrl >}}flink-docs-release-1.11/concepts/flink-architecture.html#anatomy-of-a-flink-cluster)_
+instance has a certain number of virtual _[slots]({{< param DocsBaseUrl >}}flink-docs-release-1.11/concepts/flink-architecture.html#task-slots-and-resources)_.
+Each _slot_ represents a certain part of the _TaskManager’s physical resources_ to run the operator _subtasks_, and each _subtask_ is deployed into a _slot_ of the _TaskManager_.
+A _slot_ can run multiple _[subtasks]({{< param DocsBaseUrl >}}flink-docs-release-1.11/internals/job_scheduling.html#scheduling)_ from different _operators_ at the same time, usually [chained]({{< param DocsBaseUrl >}}flink-docs-release-1.11/concepts/flink-architecture.html#tasks-and-operator-chains) together.
+
+### Scheduling strategy
+
+_[Scheduling]({{< param DocsBaseUrl >}}flink-docs-release-1.11/internals/job_scheduling.html#scheduling)_
+in Flink is a process of searching for and allocating appropriate resources (_slots_) from the _TaskManagers_ to run the _subtasks_ and produce results.
+The _scheduling strategy_ reacts on scheduling events (like start job, _subtask_ failed or finished etc) to decide which _subtask_ to deploy next.
+
+For instance, it does not make sense to schedule _subtasks_ whose inputs are not ready to consume yet to avoid wasting resources.
+Another example is to schedule _subtasks_ which are connected with _pipelined_ edges together, to avoid deadlocks caused by backpressure.
diff --git a/docs/content.tr/posts/2020-12-10-release-1.12.0.md b/docs/content.tr/posts/2020-12-10-release-1.12.0.md
new file mode 100644
index 0000000000..8664184e5a
--- /dev/null
+++ b/docs/content.tr/posts/2020-12-10-release-1.12.0.md
@@ -0,0 +1,346 @@
+---
+authors:
+- morsapaes: null
+ name: Marta Paes
+ twitter: morsapaes
+- aljoscha: null
+ name: Aljoscha Krettek
+ twitter: aljoscha
+date: "2020-12-10T08:00:00Z"
+excerpt: The Apache Flink community is excited to announce the release of Flink 1.12.0!
+ Close to 300 contributors worked on over 1k threads to bring significant improvements
+ to usability as well as new features to Flink users across the whole API stack.
+ We're particularly excited about adding efficient batch execution to the DataStream
+ API, Kubernetes HA as an alternative to ZooKeeper, support for upsert mode in the
+ Kafka SQL connector and the new Python DataStream API! Read on for all major new
+ features and improvements, important changes to be aware of and what to expect moving
+ forward!
+title: Apache Flink 1.12.0 Release Announcement
+aliases:
+- /news/2020/12/10/release-1.12.0.html
+---
+
+The Apache Flink community is excited to announce the release of Flink 1.12.0! Close to 300 contributors worked on over 1k threads to bring significant improvements to usability as well as new features that simplify (and unify) Flink handling across the API stack.
+
+**Release Highlights**
+
+* The community has added support for **efficient batch execution** in the DataStream API. This is the next major milestone towards achieving a truly unified runtime for both batch and stream processing.
+
+* **Kubernetes-based High Availability (HA)** was implemented as an alternative to ZooKeeper for highly available production setups.
+
+* The Kafka SQL connector has been extended to work in **upsert mode**, supported by the ability to handle **connector metadata** in SQL DDL. **Temporal table joins** can now also be fully expressed in SQL, no longer depending on the Table API.
+
+* Support for the **DataStream API in PyFlink** expands its usage to more complex scenarios that require fine-grained control over state and time, and it’s now possible to deploy PyFlink jobs natively on **Kubernetes**.
+
+This blog post describes all major new features and improvements, important changes to be aware of and what to expect moving forward.
+
+The binary distribution and source artifacts are now available on the updated [Downloads page](/downloads.html) of the Flink website, and the most recent distribution of PyFlink is available on [PyPI](https://pypi.org/project/apache-flink/). Please review the [release notes]({{< param DocsBaseUrl >}}flink-docs-release-1.12/release-notes/flink-1.12.html) carefully, and check the complete [release changelog](https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12348263&styleName=Html&projectId=12315522) and [updated documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.12/) for more details.
+
+We encourage you to download the release and share your feedback with the community through the [Flink mailing lists](https://flink.apache.org/community.html#mailing-lists) or [JIRA](https://issues.apache.org/jira/projects/FLINK/summary).
+
+## New Features and Improvements
+
+### Batch Execution Mode in the DataStream API
+
+Flink’s core APIs have developed organically over the lifetime of the project, and were initially designed with specific use cases in mind. And while the Table API/SQL already has unified operators, using lower-level abstractions still requires you to choose between two semantically different APIs for batch (DataSet API) and streaming (DataStream API). Since _a batch is a subset of an unbounded stream_, there are some clear advantages to consolidating them under a single API:
+
+* **Reusability:** efficient batch and stream processing under the same API would allow you to easily switch between both execution modes without rewriting any code. So, a job could be easily reused to process real-time and historical data.
+
+* **Operational simplicity:** providing a unified API would mean using a single set of connectors, maintaining a single codebase and being able to easily implement mixed execution pipelines _e.g._ for use cases like backfilling.
+
+With these advantages in mind, the community has taken the first step towards the unification of the DataStream API: supporting efficient batch execution ([FLIP-134](https://cwiki.apache.org/confluence/display/FLINK/FLIP-134%3A+Batch+execution+for+the+DataStream+API)). This means that, in the long run, the DataSet API will be deprecated and subsumed by the DataStream API and the Table API/SQL ([FLIP-131](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=158866741)). For an overview of the unification effort, refer to [this](https://youtu.be/z9ye4jzp4DQ) recent Flink Forward talk.
+
+**Batch for Bounded Streams**
+
+You could already use the DataStream API to process bounded streams (_e.g._ files), with the limitation that the runtime is not “aware” that the job is bounded. To optimize the runtime for bounded input, the new `BATCH` mode execution uses sort-based shuffles with aggregations purely in-memory and an improved scheduling strategy (_see [Pipelined Region Scheduling](#pipelined-region-scheduling-flip-119)_). As a result, `BATCH` mode execution in the DataStream API already comes very close to the performance of the DataSet API in Flink 1.12. For more details on the performance benchmark, check the original proposal ([FLIP-140](https://cwiki.apache.org/confluence/display/FLINK/FLIP-140%3A+Introduce+batch-style+execution+for+bounded+keyed+streams)).
+
+
+
+
+
+
+
+
+
+
+
+In Flink 1.12, the default execution mode is `STREAMING`. To configure a job to run in `BATCH` mode, you can set the configuration when submitting a job:
+
+```bash
+bin/flink run -Dexecution.runtime-mode=BATCH examples/streaming/WordCount.jar
+```
+
+, or do it programmatically:
+
+```java
+StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
+
+env.setRuntimeMode(RuntimeMode.BATCH);
+```
+
+
+
+
+
+
+Note: Although the DataSet API has not been deprecated yet, we recommend that users give preference to the DataStream API with BATCH
execution mode for new batch jobs, and consider migrating existing DataSet jobs.
+
+
+### New Data Sink API (Beta)
+
+Ensuring that connectors can work for both execution modes has already been covered for data sources in the [previous release](https://flink.apache.org/news/2020/07/06/release-1.11.0.html#new-data-source-api-beta), so in Flink 1.12 the community focused on implementing a unified Data Sink API ([FLIP-143](https://cwiki.apache.org/confluence/display/FLINK/FLIP-143%3A+Unified+Sink+API)). The new abstraction introduces a write/commit protocol and a more modular interface where the individual components are transparently exposed to the framework.
+
+A _Sink_ implementor will have to provide the **what** and **how**: a [_SinkWriter_]({{< param DocsBaseUrl >}}flink-docs-release-1.12/api/java/org/apache/flink/api/connector/sink/SinkWriter.html) that writes data and outputs what needs to be committed (i.e. committables); and a [_Committer_]({{< param DocsBaseUrl >}}flink-docs-release-1.12/api/java/org/apache/flink/api/connector/sink/Committer.html) and [_GlobalCommitter_]({{< param DocsBaseUrl >}}flink-docs-release-1.12/api/java/org/apache/flink/api/connector/sink/GlobalCommitter.html) that encapsulate how to handle the committables. The framework is responsible for the **when** and **where**: at what time and on which machine or process to commit.
+
+
+
+
+
+
+
+
+
+
+
+This more modular abstraction allowed to support different runtime implementations for the `BATCH` and `STREAMING` execution modes that are efficient for their intended purpose, but use just one, unified sink implementation. In Flink 1.12, the [FileSink connector]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/connectors/file_sink.html) is the unified drop-in replacement for StreamingFileSink ([FLINK-19758](https://issues.apache.org/jira/browse/FLINK-19758)). The remaining connectors will be ported to the new interfaces in future releases.
+
+### Kubernetes High Availability (HA) Service
+
+Kubernetes provides built-in functionalities that Flink can leverage for JobManager failover, instead of relying on [ZooKeeper](https://zookeeper.apache.org/). To enable a “ZooKeeperless” HA setup, the community implemented a Kubernetes HA service in Flink 1.12 ([FLIP-144](https://cwiki.apache.org/confluence/x/H0V4CQ)). The service is built on the same [base interface]({{< param DocsBaseUrl >}}flink-docs-release-1.12/api/java/org/apache/flink/runtime/highavailability/HighAvailabilityServices.html) as the ZooKeeper implementation and uses Kubernetes’ [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/) objects to handle all the metadata needed to recover from a JobManager failure. For more details and examples on how to configure a highly available Kubernetes cluster, check out the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.12/deployment/ha/kubernetes_ha.html).
+
+
+Note: This does not mean that the ZooKeeper dependency will be dropped, just that there will be an alternative for users of Flink on Kubernetes.
+
+
+
+
+### Other Improvements
+
+**Migration of existing connectors to the new Data Source API**
+
+The previous release introduced a new Data Source API ([FLIP-27](https://cwiki.apache.org/confluence/display/FLINK/FLIP-27%3A+Refactor+Source+Interface)), allowing to implement connectors that work both as bounded (batch) and unbounded (streaming) sources. In Flink 1.12, the community started porting existing source connectors to the new interfaces, starting with the FileSystem connector ([FLINK-19161](https://issues.apache.org/jira/browse/FLINK-19161)).
+
+
+Attention: The unified source implementations will be completely separate connectors that are not snapshot-compatible with their legacy counterparts.
+
+
+**Pipelined Region Scheduling ([FLIP-119](https://cwiki.apache.org/confluence/display/FLINK/FLIP-119+Pipelined+Region+Scheduling#FLIP119PipelinedRegionScheduling-BulkSlotAllocation))**
+
+Flink’s scheduler has been largely designed to address batch and streaming workloads separately. This release introduces a **unified** scheduling strategy that identifies blocking data exchanges to break down the execution graph into _pipelined regions_. This allows to schedule each region only when there’s data to perform work and only deploy it once all the required resources are available; as well as to restart failed regions independently. In particular for batch jobs, the new strategy leads to more efficient resource utilization and eliminates deadlocks.
+
+**Support for Sort-Merge Shuffles ([FLIP-148](https://cwiki.apache.org/confluence/display/FLINK/FLIP-148%3A+Introduce+Sort-Merge+Based+Blocking+Shuffle+to+Flink))**
+
+To improve the stability, performance and resource utilization of large-scale batch jobs, the community introduced sort-merge shuffle as an alternative to the original shuffle implementation that Flink already used. This approach can reduce shuffle time [significantly](https://www.mail-archive.com/dev@flink.apache.org/msg42472.html), and uses fewer file handles and file write buffers (which is problematic for large-scale jobs). Further optimizations will be implemented in upcoming releases ([FLINK-19614](https://issues.apache.org/jira/browse/FLINK-19614)).
+
+
+
Attention: This feature is experimental and not enabled by default. To enable sort-merge shuffles, you can configure a reasonable minimum parallelism threshold in the
TaskManager network configuration options .
+
+
+**Improvements to the Flink WebUI ([FLIP-75](https://cwiki.apache.org/confluence/display/FLINK/FLIP-75%3A+Flink+Web+UI+Improvement+Proposal))**
+
+As a continuation of the series of improvements to the Flink WebUI kicked off in the last release, the community worked on exposing JobManager's memory-related metrics and configuration parameters on the WebUI ([FLIP-104](https://cwiki.apache.org/confluence/display/FLINK/FLIP-104%3A+Add+More+Metrics+to+Jobmanager)). The TaskManager's metrics page has also been updated to reflect the [changes to the TaskManager memory model](https://flink.apache.org/news/2020/04/21/memory-management-improvements-flink-1.10.html) introduced in Flink 1.10 ([FLIP-102](https://cwiki.apache.org/confluence/display/FLINK/FLIP-102%3A+Add+More+Metrics+to+TaskManager)), adding new metrics for Managed Memory, Network Memory and Metaspace.
+
+
+
+### Table API/SQL: Metadata Handling in SQL Connectors
+
+Some sources (and formats) expose additional fields as metadata that can be valuable for users to process along with record data. A common example is Kafka, where you might want to _e.g._ access offset, partition or topic information, read/write the record key or use embedded metadata timestamps for time-based operations.
+With the new release, Flink SQL supports **metadata columns** to read and write connector- and format-specific fields for every row of a table ([FLIP-107](https://cwiki.apache.org/confluence/display/FLINK/FLIP-107%3A+Handling+of+metadata+in+SQL+connectors)). These columns are declared in the `CREATE TABLE` statement using the `METADATA` (reserved) keyword.
+
+```sql
+CREATE TABLE kafka_table (
+ id BIGINT,
+ name STRING,
+ event_time TIMESTAMP(3) METADATA FROM 'timestamp', -- access Kafka 'timestamp' metadata
+ headers MAP METADATA -- access Kafka 'headers' metadata
+) WITH (
+ 'connector' = 'kafka',
+ 'topic' = 'test-topic',
+ 'format' = 'avro'
+);
+```
+
+In Flink 1.12, metadata is exposed for the **Kafka** and **Kinesis** connectors, with work on the FileSystem connector already planned ([FLINK-19903](https://issues.apache.org/jira/browse/FLINK-19903)). Due to the more complex structure of Kafka records, [new properties]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/table/connectors/kafka.html#key-format) were also specifically implemented for the Kafka connector to control how to handle the key/value pairs. For a complete overview of metadata support in Flink SQL, check the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/table/connectors/) for each connector, as well as the motivating use cases in the original proposal.
+
+### Table API/SQL: Upsert Kafka Connector
+
+For some use cases, like interpreting compacted topics or writing out (updating) aggregated results, it’s necessary to handle Kafka record keys as _true_ primary keys that can determine what should be inserted, deleted or updated. To enable this, the community created a [dedicated upsert connector]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/table/connectors/upsert-kafka.html) (`upsert-kafka`) that extends the base implementation to work in _upsert_ mode ([FLIP-149](https://issues.apache.org/jira/browse/FLINK-19857)).
+
+The new `upsert-kafka` connector can be used for sources and sinks, and provides the **same base functionality** and **persistence guarantees** as the existing Kafka connector, as it reuses most of its code under the hood. To use the `upsert-kafka connector`, you must define a [primary key constraint]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/table/sql/create.html#primary-key) on table creation, as well as specify the (de)serialization format for the key (`key.format`) and value (`value.format`).
+
+### Table API/SQL: Support for Temporal Table Joins in SQL
+
+Instead of creating a temporal table function to look up against a table at a certain point in time, you can now simply use the standard SQL clause `FOR SYSTEM_TIME AS OF` (SQL:2011) to express a **temporal table join**. In addition, temporal joins are now supported against _any_ kind of table that has a time attribute and a primary key, and not just _append-only_ tables. This unlocks a new set of use cases, like performing temporal joins directly against Kafka compacted topics or database changelogs (e.g. from Debezium).
+
+```sql
+
+-- Table backed by a Kafka topic
+CREATE TABLE orders (
+ order_id STRING,
+ currency STRING,
+ amount INT,
+ order_time TIMESTAMP(3),
+ WATERMARK FOR order_time AS order_time - INTERVAL '30' SECOND
+) WITH (
+ 'connector' = 'kafka',
+ ...
+);
+
+-- Table backed by a Kafka compacted topic
+CREATE TABLE latest_rates (
+ currency STRING,
+ currency_rate DECIMAL(38, 10),
+ currency_time TIMESTAMP(3),
+ WATERMARK FOR currency_time AS currency_time - INTERVAL '5' SECOND,
+ PRIMARY KEY (currency) NOT ENFORCED
+) WITH (
+ 'connector' = 'upsert-kafka',
+ ...
+);
+
+-- Event-time temporal table join
+SELECT
+ o.order_id,
+ o.order_time,
+ o.amount * r.currency_rate AS amount,
+ r.currency
+FROM orders AS o JOIN latest_rates FOR SYSTEM_TIME AS OF o.order_time r
+ON o.currency = r.currency;
+```
+
+The previous example also shows how you can take advantage of the new `upsert-kafka` connector in the context of temporal table joins.
+
+**Hive Tables in Temporal Table Joins**
+
+You can also perform temporal table joins against Hive tables by either automatically reading the latest table partition as a temporal table ([FLINK-19644](https://issues.apache.org/jira/browse/FLINK-19644)) or the whole table as a bounded stream tracking the latest version at execution time. Refer to the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/table/connectors/hive/hive_read_write.html#temporal-table-join) for examples of using Hive tables in temporal table joins.
+
+
+
+### Other Improvements to the Table API/SQL
+
+**Kinesis Flink SQL Connector ([FLINK-18858](https://issues.apache.org/jira/browse/FLINK-18858))**
+
+From Flink 1.12, Amazon Kinesis Data Streams (KDS) is natively supported as a source/sink also in the Table API/SQL. The new Kinesis SQL connector ships with support for Enhanced Fan-Out (EFO) and Sink Partitioning. For a complete overview of supported features, configuration options and exposed metadata, check the [updated documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/table/connectors/kinesis.html).
+
+**Streaming Sink Compaction in the FileSystem/Hive Connector ([FLINK-19345](https://issues.apache.org/jira/browse/FLINK-19345))**
+
+Many bulk formats, such as Parquet, are most efficient when written as large files; this is a challenge when frequent checkpointing is enabled, as too many small files are created (and need to be rolled on checkpoint). In Flink 1.12, the file sink supports **file compaction**, allowing jobs to retain smaller checkpoint intervals without generating a large number of files. To enable file compaction, you can set `auto-compaction=true` in the properties of the FileSystem connector, as described in the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/table/connectors/filesystem.html#file-compaction).
+
+**Watermark Pushdown in the Kafka Connector ([FLINK-20041](https://issues.apache.org/jira/browse/FLINK-20041))**
+
+To ensure correctness when consuming from Kafka, it’s generally preferable to generate watermarks on a per-partition basis, since the out-of-orderness within a partition is usually lower than across all partitions. Flink will now push down watermark strategies to [emit **per-partition watermarks**]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/table/connectors/kafka.html#source-per-partition-watermarks) from within the Kafka consumer. The output watermark of the source will be determined by the minimum watermark across the partitions it reads, leading to better (i.e. closer to real-time) watermarking. Watermark pushdown also lets you configure per-partition **idleness detection** to prevent idle partitions from holding back the event time progress of the entire application.
+
+**Newly Supported Formats**
+
+
+
+
+ Format
+ Description
+ Supported Connectors
+
+
+
+
+ Avro Schema Registry
+ Read and write data serialized with the Confluent Schema Registry KafkaAvroSerializer .
+ Kafka, Upsert Kafka
+
+
+ Debezium Avro
+ Read and write Debezium records serialized with the Confluent Schema Registry KafkaAvroSerializer.
+ Kafka
+
+
+ Maxwell (CDC)
+ Read and write Maxwell JSON records.
+
+ Kafka
+ FileSystem
+
+
+ Raw
+ Read and write raw (byte-based) values as a single column.
+
+ Kafka, Upsert Kafka
+ Kinesis
+ FileSystem
+
+
+
+
+
+**Multi-input Operator for Join Optimization ([FLINK-19621](https://issues.apache.org/jira/browse/FLINK-19621))**
+
+To eliminate unnecessary serialization and data spilling and improve the performance of batch and streaming Table API/SQL jobs, the default planner now leverages the N-ary stream operator introduced in the last release ([FLIP-92](https://cwiki.apache.org/confluence/display/FLINK/FLIP-92%3A+Add+N-Ary+Stream+Operator+in+Flink)) to implement the "chaining" of operators connected by forward edges.
+
+**Type Inference for Table API UDAFs ([FLIP-65](https://cwiki.apache.org/confluence/display/FLINK/FLIP-65%3A+New+type+inference+for+Table+API+UDFs))**
+
+This release concluded the work started in Flink 1.9 on a [new data type system]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/table/types.html#data-types) for the Table API, with the exposure of aggregate functions (UDAFs) to the new type system. From Flink 1.12, UDAFs behave similarly to scalar and table functions, and support all data types.
+
+
+
+### PyFlink: Python DataStream API
+
+To expand the usability of PyFlink, this release introduces a first version of the Python DataStream API ([FLIP-130](https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=158866298)) with support for stateless operations (e.g. Map, FlatMap, Filter, KeyBy).
+
+```python
+from pyflink.common.typeinfo import Types
+from pyflink.datastream import MapFunction, StreamExecutionEnvironment
+
+class MyMapFunction(MapFunction):
+
+ def map(self, value):
+ return value + 1
+
+
+env = StreamExecutionEnvironment.get_execution_environment()
+data_stream = env.from_collection([1, 2, 3, 4, 5], type_info=Types.INT())
+mapped_stream = data_stream.map(MyMapFunction(), output_type=Types.INT())
+mapped_stream.print()
+env.execute("datastream job")
+```
+
+To give the Python DataStream API a try, you can [install PyFlink]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/python/installation.html#installation-of-pyflink) and check out [this tutorial]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/python/datastream_tutorial.html) that guides you through building a simple streaming application.
+
+
+
+### Other Improvements to PyFlink
+
+**PyFlink Jobs on Kubernetes ([FLINK-17480](https://issues.apache.org/jira/browse/FLINK-17480))**
+
+In addition to standalone and YARN deployments, PyFlink jobs can now also be deployed natively on Kubernetes. The [deployment documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.12/deployment/resource-providers/native_kubernetes.html) has detailed instructions on how to start a _session_ or _application_ cluster on Kubernetes.
+
+**User-defined Aggregate Functions (UDAFs)**
+
+From Flink 1.12, you can define and register UDAFs in PyFlink ([FLIP-139](https://cwiki.apache.org/confluence/display/FLINK/FLIP-139%3A+General+Python+User-Defined+Aggregate+Function+Support+on+Table+API)). In contrast to a normal UDF, which doesn’t handle state and operates on a single row at a time, a [UDAF]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/python/table-api-users-guide/udfs/python_udfs.html#aggregate-functions) is stateful and can be used to compute custom aggregations over multiple input rows. To benefit from vectorization, you can also use [Pandas UDAFs]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/python/table-api-users-guide/udfs/vectorized_python_udfs.html#vectorized-aggregate-functions) ([FLIP-137](https://cwiki.apache.org/confluence/display/FLINK/FLIP-137%3A+Support+Pandas+UDAF+in+PyFlink?src=jira)) (up to 10x faster).
+
+
+Note: General UDAFs are only supported for group aggregations and in _streaming_ mode. For _batch_ mode or window aggregations, use Pandas UDAFs.
+
+
+
+
+## Important Changes
+
+ * [[FLINK-19319](https://issues.apache.org/jira/browse/FLINK-19319)] The default stream time characteristic has been changed to `EventTime`, so you no longer need to call `StreamExecutionEnvironment.setStreamTimeCharacteristic()` to enable event time support.
+
+ * [[FLINK-19278](https://issues.apache.org/jira/browse/FLINK-19278)] Flink now relies on Scala Macros 2.1.1, so Scala versions < 2.11.11 are no longer supported.
+
+ * [[FLINK-19152](https://issues.apache.org/jira/browse/FLINK-19152)] The Kafka 0.10.x and 0.11.x connectors have been removed with this release. If you’re still using these versions, please refer to the [documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/connectors/kafka.html) to learn how to upgrade to the universal Kafka connector.
+
+ * [[FLINK-18795](https://issues.apache.org/jira/browse/FLINK-18795)] The HBase connector has been upgraded to the last stable version (2.2.3).
+
+ * [[FLINK-17877](https://issues.apache.org/jira/browse/FLINK-18795)] PyFlink now supports Python 3.8.
+
+ * [[FLINK-18738](https://issues.apache.org/jira/browse/FLINK-18738)] To align with [FLIP-53](https://cwiki.apache.org/confluence/display/FLINK/FLIP-53%3A+Fine+Grained+Operator+Resource+Management), managed memory is now the default also for Python workers. The configurations `python.fn-execution.buffer.memory.size` and `python.fn-execution.framework.memory.size` have been removed and will not take effect anymore.
+
+## Release Notes
+
+Please review the [release notes]({{< param DocsBaseUrl >}}flink-docs-release-1.12/release-notes/flink-1.12.html) carefully for a detailed list of changes and new features if you plan to upgrade your setup to Flink 1.12. This version is API-compatible with previous 1.x releases for APIs annotated with the @Public annotation.
+
+## List of Contributors
+
+The Apache Flink community would like to thank each and every one of the 300 contributors that have made this release possible:
+
+Abhijit Shandilya, Aditya Agarwal, Alan Su, Alexander Alexandrov, Alexander Fedulov, Alexey Trenikhin, Aljoscha Krettek, Allen Madsen, Andrei Bulgakov, Andrey Zagrebin, Arvid Heise, Authuir, Bairos, Bartosz Krasinski, Benchao Li, Brandon, Brian Zhou, C08061, Canbin Zheng, Cedric Chen, Chesnay Schepler, Chris Nix, Congxian Qiu, DG-Wangtao, Da(Dash)Shen, Dan Hill, Daniel Magyar, Danish Amjad, Danny Chan, Danny Cranmer, David Anderson, Dawid Wysakowicz, Devin Thomson, Dian Fu, Dongxu Wang, Dylan Forciea, Echo Lee, Etienne Chauchot, Fabian Paul, Felipe Lolas, Fin-Chan, Fin-chan, Flavio Pompermaier, Flora Tao, Fokko Driesprong, Gao Yun, Gary Yao, Ghildiyal, GitHub, Grebennikov Roman, GuoWei Ma, Gyula Fora, Hequn Cheng, Herman, Hong Teoh, HuangXiao, HuangXingBo, Husky Zeng, Hyeonseop Lee, I. Raleigh, Ivan, Jacky Lau, Jark Wu, Jaskaran Bindra, Jeff Yang, Jeff Zhang, Jiangjie (Becket) Qin, Jiatao Tao, Jiayi Liao, Jiayi-Liao, Jiezhi.G, Jimmy.Zhou, Jindrich Vimr, Jingsong Lee, JingsongLi, Joey Echeverria, Juha Mynttinen, Jun Qin, Jörn Kottmann, Karim Mansour, Kevin Bohinski, Kezhu Wang, Konstantin Knauf, Kostas Kloudas, Kurt Young, Lee Do-Kyeong, Leonard Xu, Lijie Wang, Liu Jiangang, Lorenzo Nicora, LululuAlu, Luxios22, Marta Paes Moreira, Mateusz Sabat, Matthias Pohl, Maximilian Michels, Miklos Gergely, Milan Nikl, Nico Kruber, Niel Hu, Niels Basjes, Oleksandr Nitavskyi, Paul Lam, Peng, PengFei Li, PengchengLiu, Peter Huang, Piotr Nowojski, PoojaChandak, Qingsheng Ren, Qishang Zhong, Richard Deurwaarder, Richard Moorhead, Robert Metzger, Roc Marshal, Roey Shem Tov, Roman, Roman Khachatryan, Rong Rong, Rui Li, Seth Wiesman, Shawn Huang, ShawnHx, Shengkai, Shuiqiang Chen, Shuo Cheng, SteNicholas, Stephan Ewen, Steve Whelan, Steven Wu, Tartarus0zm, Terry Wang, Thesharing, Thomas Weise, Till Rohrmann, Timo Walther, TsReaper, Tzu-Li (Gordon) Tai, Ufuk Celebi, V1ncentzzZ, Vladimirs Kotovs, Wei Zhong, Weike DONG, XBaith, Xiaogang Zhou, Xiaoguang Sun, Xingcan Cui, Xintong Song, Xuannan, Yang Liu, Yangze Guo, Yichao Yang, Yikun Jiang, Yu Li, Yuan Mei, Yubin Li, Yun Gao, Yun Tang, Yun Wang, Zhenhua Yang, Zhijiang, Zhu Zhu, acesine, acqua.csq, austin ce, bigdata-ny, billyrrr, caozhen, caozhen1937, chaojianok, chenkai, chris, cpugputpu, dalong01.liu, darionyaphet, dijie, diohabara, dufeng1010, fangliang, felixzheng, gkrishna, gm7y8, godfrey he, godfreyhe, gsralex, haseeb1431, hequn.chq, hequn8128, houmaozheng, huangxiao, huangxingbo, huzekang, jPrest, jasonlee, jinfeng, jinhai, johnm, jxeditor, kecheng, kevin.cyj, kevinzwx, klion26, leiqiang, libenchao, lijiewang.wlj, liufangliang, liujiangang, liuyongvs, liuyufei9527, lsy, lzy3261944, mans2singh, molsionmo, openopen2, pengweibo, rinkako, sanshi@wwdz.onaliyun.com, secondChoice, seunjjs, shaokan.cao, shizhengchao, shizk233, shouweikun, spurthi chaganti, sujun, sunjincheng121, sxnan, tison, totorooo, venn, vthinkxie, wangsong2, wangtong, wangxiyuan, wangxlong, wangyang0918, wangzzu, weizheng92, whlwanghailong, wineandcheeze, wooplevip, wtog, wudi28, wxp, xcomp, xiaoHoly, xiaolong.wang, yangyichao-mango, yingshin, yushengnan, yushujun, yuzhao.cyz, zhangap, zhangmang, zhangzhanchum, zhangzhanchun, zhangzhanhua, zhangzp, zheyu, zhijiang, zhushang, zhuxiaoshang, zlzhang0122, zodo, zoudan, zouzhiye
diff --git a/docs/content.tr/posts/2020-12-18-release-1.11.3.md b/docs/content.tr/posts/2020-12-18-release-1.11.3.md
new file mode 100644
index 0000000000..dd9c8616bb
--- /dev/null
+++ b/docs/content.tr/posts/2020-12-18-release-1.11.3.md
@@ -0,0 +1,371 @@
+---
+authors:
+- name: Xintong Song
+ xtsong: null
+date: "2020-12-18T00:00:00Z"
+title: Apache Flink 1.11.3 Released
+aliases:
+- /news/2020/12/18/release-1.11.3.html
+---
+
+The Apache Flink community released the third bugfix version of the Apache Flink 1.11 series.
+
+This release includes 151 fixes and minor improvements for Flink 1.11.2. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.11.3.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.11.3
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.11.3
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.11.3
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-17393 ] - Improve the `FutureCompletingBlockingQueue` to wakeup blocking put() more elegantly.
+
+[FLINK-18604 ] - HBase ConnectorDescriptor can not work in Table API
+
+[FLINK-18673 ] - Calling ROW() in a UDF results in UnsupportedOperationException
+
+[FLINK-18680 ] - Improve RecordsWithSplitIds API
+
+[FLINK-18916 ] - Add a "Operations" link(linked to dev/table/tableApi.md) under the "Python API" -> "User Guide" -> "Table API" section
+
+[FLINK-18918 ] - Add a "Connectors" document under the "Python API" -> "User Guide" -> "Table API" section
+
+[FLINK-18922 ] - Add a "Catalogs" link (linked to dev/table/catalogs.md) under the "Python API" -> "User Guide" -> "Table API" section
+
+[FLINK-18926 ] - Add a "Environment Variables" document under the "Python API" -> "User Guide" -> "Table API" section
+
+[FLINK-19162 ] - Allow Split Reader based sources to reuse record batches
+
+[FLINK-19205 ] - SourceReaderContext should give access to Configuration and Hostbame
+
+[FLINK-20397 ] - Pass checkpointId to OperatorCoordinator.resetToCheckpoint().
+
+
+
+ Bug
+
+
+[FLINK-9992 ] - FsStorageLocationReferenceTest#testEncodeAndDecode failed in CI
+
+[FLINK-13733 ] - FlinkKafkaInternalProducerITCase.testHappyPath fails on Travis
+
+[FLINK-15170 ] - WebFrontendITCase.testCancelYarn fails on travis
+
+[FLINK-16246 ] - Exclude "SdkMBeanRegistrySupport" from dynamically loaded AWS connectors
+
+[FLINK-16268 ] - Failed to run rank over window with Hive built-in functions
+
+[FLINK-16768 ] - HadoopS3RecoverableWriterITCase.testRecoverWithStateWithMultiPart hangs
+
+[FLINK-17341 ] - freeSlot in TaskExecutor.closeJobManagerConnection cause ConcurrentModificationException
+
+[FLINK-17458 ] - TaskExecutorSubmissionTest#testFailingScheduleOrUpdateConsumers
+
+[FLINK-17677 ] - FLINK_LOG_PREFIX recommended in docs is not always available
+
+[FLINK-17825 ] - HA end-to-end gets killed due to timeout
+
+[FLINK-18128 ] - CoordinatedSourceITCase.testMultipleSources gets stuck
+
+[FLINK-18196 ] - flink throws `NullPointerException` when executeCheckpointing
+
+[FLINK-18222 ] - "Avro Confluent Schema Registry nightly end-to-end test" unstable with "Kafka cluster did not start after 120 seconds"
+
+[FLINK-18815 ] - AbstractCloseableRegistryTest.testClose unstable
+
+[FLINK-18818 ] - HadoopRenameCommitterHDFSTest.testCommitOneFile[Override: false] failed with "java.io.IOException: The stream is closed"
+
+[FLINK-18836 ] - Python UDTF doesn't work well when the return type isn't generator
+
+[FLINK-18915 ] - FIXED_PATH(dummy Hadoop Path) with WriterImpl may cause ORC writer OOM
+
+[FLINK-19022 ] - AkkaRpcActor failed to start but no exception information
+
+[FLINK-19121 ] - Avoid accessing HDFS frequently in HiveBulkWriterFactory
+
+[FLINK-19135 ] - (Stream)ExecutionEnvironment.execute() should not throw ExecutionException
+
+[FLINK-19138 ] - Python UDF supports directly specifying input_types as DataTypes.ROW
+
+[FLINK-19140 ] - Join with Table Function (UDTF) SQL example is incorrect
+
+[FLINK-19151 ] - Flink does not normalize container resource with correct configurations when Yarn FairScheduler is used
+
+[FLINK-19154 ] - Application mode deletes HA data in case of suspended ZooKeeper connection
+
+[FLINK-19170 ] - Parameter naming error
+
+[FLINK-19201 ] - PyFlink e2e tests is instable and failed with "Connection broken: OSError"
+
+[FLINK-19227 ] - The catalog is still created after opening failed in catalog registering
+
+[FLINK-19237 ] - LeaderChangeClusterComponentsTest.testReelectionOfJobMaster failed with "NoResourceAvailableException: Could not allocate the required slot within slot request timeout"
+
+[FLINK-19244 ] - CSV format can't deserialize null ROW field
+
+[FLINK-19250 ] - SplitFetcherManager does not propagate errors correctly
+
+[FLINK-19253 ] - SourceReaderTestBase.testAddSplitToExistingFetcher hangs
+
+[FLINK-19258 ] - Fix the wrong example of "csv.line-delimiter" in CSV documentation
+
+[FLINK-19280 ] - The option "sink.buffer-flush.max-rows" for JDBC can't be disabled by set to zero
+
+[FLINK-19281 ] - LIKE cannot recognize full table path
+
+[FLINK-19291 ] - Fix exception for AvroSchemaConverter#convertToSchema when RowType contains multiple row fields
+
+[FLINK-19295 ] - YARNSessionFIFOITCase.checkForProhibitedLogContents found a log with prohibited string
+
+[FLINK-19300 ] - Timer loss after restoring from savepoint
+
+[FLINK-19321 ] - CollectSinkFunction does not define serialVersionUID
+
+[FLINK-19338 ] - New source interface cannot unregister unregistered source
+
+[FLINK-19361 ] - Make HiveCatalog thread safe
+
+[FLINK-19398 ] - Hive connector fails with IllegalAccessError if submitted as usercode
+
+[FLINK-19401 ] - Job stuck in restart loop due to excessive checkpoint recoveries which block the JobMaster
+
+[FLINK-19423 ] - Fix ArrayIndexOutOfBoundsException when executing DELETE statement in JDBC upsert sink
+
+[FLINK-19433 ] - An Error example of FROM_UNIXTIME function in document
+
+[FLINK-19448 ] - CoordinatedSourceITCase.testEnumeratorReaderCommunication hangs
+
+[FLINK-19535 ] - SourceCoordinator should avoid fail job multiple times.
+
+[FLINK-19557 ] - Issue retrieving leader after zookeeper session reconnect
+
+[FLINK-19585 ] - UnalignedCheckpointCompatibilityITCase.test:97->runAndTakeSavepoint: "Not all required tasks are currently running."
+
+[FLINK-19587 ] - Error result when casting binary type as varchar
+
+[FLINK-19618 ] - Broken link in docs
+
+[FLINK-19629 ] - Fix NullPointException when deserializing map field with null value for Avro format
+
+[FLINK-19675 ] - The plan of is incorrect when Calc contains WHERE clause, composite fields access and Python UDF at the same time
+
+[FLINK-19695 ] - Writing Table with RowTime Column of type TIMESTAMP(3) to Kafka fails with ClassCastException
+
+[FLINK-19717 ] - SourceReaderBase.pollNext may return END_OF_INPUT if SplitReader.fetch throws
+
+[FLINK-19740 ] - Error in to_pandas for table containing event time: class java.time.LocalDateTime cannot be cast to class java.sql.Timestamp
+
+[FLINK-19741 ] - InternalTimeServiceManager fails to restore due to corrupt reads if there are other users of raw keyed state streams
+
+[FLINK-19748 ] - KeyGroupRangeOffsets#KeyGroupOffsetsIterator should skip key groups that don't have a defined offset
+
+[FLINK-19750 ] - Deserializer is not opened in Kafka consumer when restoring from state
+
+[FLINK-19755 ] - Fix CEP documentation error of the example in 'After Match Strategy' section
+
+[FLINK-19775 ] - SystemProcessingTimeServiceTest.testImmediateShutdown is instable
+
+[FLINK-19777 ] - Fix NullPointException for WindowOperator.close()
+
+[FLINK-19790 ] - Writing MAP<STRING, STRING> to Kafka with JSON format produces incorrect data.
+
+[FLINK-19806 ] - Job may try to leave SUSPENDED state in ExecutionGraph#failJob()
+
+[FLINK-19816 ] - Flink restored from a wrong checkpoint (a very old one and not the last completed one)
+
+[FLINK-19852 ] - Managed memory released check can block IterativeTask
+
+[FLINK-19867 ] - Validation fails for UDF that accepts var-args
+
+[FLINK-19894 ] - Use iloc for positional slicing instead of direct slicing in from_pandas
+
+[FLINK-19901 ] - Unable to exclude metrics variables for the last metrics reporter.
+
+[FLINK-19906 ] - Incorrect result when compare two binary fields
+
+[FLINK-19907 ] - Channel state (upstream) can be restored after emission of new elements (watermarks)
+
+[FLINK-19909 ] - Flink application in attach mode could not terminate when the only job is canceled
+
+[FLINK-19948 ] - Calling NOW() function throws compile exception
+
+[FLINK-20013 ] - BoundedBlockingSubpartition may leak network buffer if task is failed or canceled
+
+[FLINK-20018 ] - pipeline.cached-files option cannot escape ':' in path
+
+[FLINK-20033 ] - Job fails when stopping JobMaster
+
+[FLINK-20050 ] - SourceCoordinatorProviderTest.testCheckpointAndReset failed with NullPointerException
+
+[FLINK-20063 ] - File Source requests an additional split on every restore.
+
+[FLINK-20064 ] - Broken links in the documentation
+
+[FLINK-20065 ] - UnalignedCheckpointCompatibilityITCase.test failed with AskTimeoutException
+
+[FLINK-20068 ] - KafkaSubscriberTest.testTopicPatternSubscriber failed with unexpected results
+
+[FLINK-20069 ] - docs_404_check doesn't work properly
+
+[FLINK-20076 ] - DispatcherTest.testOnRemovedJobGraphDoesNotCleanUpHAFiles does not test the desired functionality
+
+[FLINK-20079 ] - Modified UnalignedCheckpointITCase...MassivelyParallel fails
+
+[FLINK-20081 ] - ExecutorNotifier should run handler in the main thread when receive an exception from the callable.
+
+[FLINK-20143 ] - use `yarn.provided.lib.dirs` config deploy job failed in yarn per job mode
+
+[FLINK-20165 ] - YARNSessionFIFOITCase.checkForProhibitedLogContents: Error occurred during initialization of boot layer java.lang.IllegalStateException: Module system already initialized
+
+[FLINK-20175 ] - Avro Confluent Registry SQL format does not support adding nullable columns
+
+[FLINK-20183 ] - Fix the default PYTHONPATH is overwritten in client side
+
+[FLINK-20193 ] - SourceCoordinator should catch exception thrown from SplitEnumerator.start()
+
+[FLINK-20194 ] - KafkaSourceFetcherManager.commitOffsets() should handle the case when there is no split fetcher.
+
+[FLINK-20200 ] - SQL Hints are not supported in "Create View" syntax
+
+[FLINK-20213 ] - Partition commit is delayed when records keep coming
+
+[FLINK-20221 ] - DelimitedInputFormat does not restore compressed filesplits correctly leading to dataloss
+
+[FLINK-20222 ] - The CheckpointCoordinator should reset the OperatorCoordinators when fail before the first checkpoint.
+
+[FLINK-20223 ] - The RecreateOnResetOperatorCoordinator and SourceCoordinator executor thread should use the user class loader.
+
+[FLINK-20243 ] - Remove useless words in documents
+
+[FLINK-20262 ] - Building flink-dist docker image does not work without python2
+
+[FLINK-20266 ] - New Sources prevent JVM shutdown when running a job
+
+[FLINK-20270 ] - Fix the regression of missing ExternallyInducedSource support in FLIP-27 Source.
+
+[FLINK-20277 ] - flink-1.11.2 ContinuousFileMonitoringFunction cannot restore from failure
+
+[FLINK-20284 ] - Error happens in TaskExecutor when closing JobMaster connection if there was a python UDF
+
+[FLINK-20285 ] - LazyFromSourcesSchedulingStrategy is possible to schedule non-CREATED vertices
+
+[FLINK-20333 ] - Flink standalone cluster throws metaspace OOM after submitting multiple PyFlink UDF jobs.
+
+[FLINK-20351 ] - Execution.transitionState does not properly log slot location
+
+[FLINK-20382 ] - Exception thrown from JobMaster.startScheduling() may be ignored.
+
+[FLINK-20396 ] - Add "OperatorCoordinator.resetSubtask()" to fix order problems of "subtaskFailed()"
+
+[FLINK-20404 ] - ZooKeeper quorum fails to start due to missing log4j library
+
+[FLINK-20413 ] - Sources should add splits back in "resetSubtask()", rather than in "subtaskFailed()".
+
+[FLINK-20418 ] - NPE in IteratorSourceReader
+
+[FLINK-20442 ] - Fix license documentation mistakes in flink-python.jar
+
+[FLINK-20492 ] - The SourceOperatorStreamTask should implement cancelTask() and finishTask()
+
+[FLINK-20554 ] - The Checkpointed Data Size of the Latest Completed Checkpoint is incorrectly displayed on the Overview page of the UI
+
+
+
+ New Feature
+
+
+[FLINK-19934 ] - [FLIP-27 source] add new API: SplitEnumeratorContext.runInCoordinatorThread(Runnable)
+
+
+
+ Improvement
+
+
+[FLINK-16753 ] - Exception from AsyncCheckpointRunnable should be wrapped in CheckpointException
+
+[FLINK-18139 ] - Unaligned checkpoints checks wrong channels for inflight data.
+
+[FLINK-18500 ] - Make the legacy planner exception more clear when resolving computed columns types for schema
+
+[FLINK-18545 ] - Sql api cannot specify flink job name
+
+[FLINK-18715 ] - add cpu usage metric of jobmanager/taskmanager
+
+[FLINK-19193 ] - Recommend stop-with-savepoint in upgrade guidelines
+
+[FLINK-19225 ] - Improve code and logging in SourceReaderBase
+
+[FLINK-19245 ] - Set default queue capacity for FLIP-27 source handover queue to 2
+
+[FLINK-19251 ] - Avoid confusing queue handling in "SplitReader.handleSplitsChanges()"
+
+[FLINK-19252 ] - Jaas file created under io.tmp.dirs - folder not created if not exists
+
+[FLINK-19265 ] - Simplify handling of 'NoMoreSplitsEvent'
+
+[FLINK-19339 ] - Support Avro's unions with logical types
+
+[FLINK-19523 ] - Hide sensitive command-line configurations
+
+[FLINK-19569 ] - Upgrade ICU4J to 67.1+
+
+[FLINK-19677 ] - TaskManager takes abnormally long time to register with JobManager on Kubernetes
+
+[FLINK-19698 ] - Add close() method and onCheckpointComplete() to the Source.
+
+[FLINK-19892 ] - Replace __metaclass__ field with metaclass keyword
+
+[FLINK-20049 ] - Simplify handling of "request split".
+
+[FLINK-20055 ] - Datadog API Key exposed in Flink JobManager logs
+
+[FLINK-20142 ] - Update the document for CREATE TABLE LIKE that source table from different catalog is supported
+
+[FLINK-20152 ] - Document which execution.target values are supported
+
+[FLINK-20156 ] - JavaDocs of WatermarkStrategy.withTimestampAssigner are wrong wrt Java 8
+
+[FLINK-20169 ] - Move emitting MAX_WATERMARK out of SourceOperator processing loop
+
+[FLINK-20207 ] - Improve the error message printed when submitting the pyflink jobs via 'flink run'
+
+[FLINK-20296 ] - Explanation of keyBy was broken by find/replace of deprecated forms of keyBy
+
+
+
+ Test
+
+
+[FLINK-18725 ] - "Run Kubernetes test" failed with "30025: provided port is already allocated"
+
+
+
+ Task
+
+
+[FLINK-20455 ] - Add check to LicenseChecker for top level /LICENSE files in shaded jars
+
+
diff --git a/docs/content.tr/posts/2021-01-02-release-statefun-2.2.2.md b/docs/content.tr/posts/2021-01-02-release-statefun-2.2.2.md
new file mode 100644
index 0000000000..742a40a14e
--- /dev/null
+++ b/docs/content.tr/posts/2021-01-02-release-statefun-2.2.2.md
@@ -0,0 +1,45 @@
+---
+authors:
+- name: Tzu-Li (Gordon) Tai
+ twitter: tzulitai
+ tzulitai: null
+date: "2021-01-02T00:00:00Z"
+title: Stateful Functions 2.2.2 Release Announcement
+aliases:
+- /news/2021/01/02/release-statefun-2.2.2.html
+---
+
+The Apache Flink community released the second bugfix release of the Stateful Functions (StateFun) 2.2 series, version 2.2.2.
+
+The most important change of this bugfix release is upgrading Apache Flink to version 1.11.3. In addition to many stability
+fixes to the Flink runtime itself, this also allows StateFun applications to safely use savepoints to upgrade from
+older versions earlier than StateFun 2.2.1. Previously, restoring from savepoints could have failed under
+[certain conditions](https://issues.apache.org/jira/browse/FLINK-19741).
+
+We strongly recommend all users to upgrade to 2.2.2 .
+
+---
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+This release includes 5 fixes and minor improvements since StateFun 2.2.1. Below is a detailed list of all fixes and improvements:
+
+ Improvement
+
+
+[FLINK-20699 ] - Feedback invocation_id must not be constant.
+
+
+
+ Task
+
+
+[FLINK-20161 ] - Consider switching from Travis CI to Github Actions for flink-statefun's CI workflows
+
+[FLINK-20189 ] - Restored feedback events may be silently dropped if per key-group header bytes were not fully read
+
+[FLINK-20636 ] - Require unaligned checkpoints to be disabled in StateFun applications
+
+[FLINK-20689 ] - Upgrade StateFun to Flink 1.11.3
+
+
diff --git a/docs/content.tr/posts/2021-01-07-pulsar-flink-connector-270.md b/docs/content.tr/posts/2021-01-07-pulsar-flink-connector-270.md
new file mode 100644
index 0000000000..fdb940af51
--- /dev/null
+++ b/docs/content.tr/posts/2021-01-07-pulsar-flink-connector-270.md
@@ -0,0 +1,172 @@
+---
+authors:
+- jianyun: null
+ name: Jianyun Zhao
+ twitter: yihy8023
+- jennifer: null
+ name: Jennifer Huang
+ twitter: Jennife06125739
+date: "2021-01-07T08:00:00Z"
+excerpt: With the unification of batch and streaming regarded as the future in data
+ processing, the Pulsar Flink Connector provides an ideal solution for unified batch
+ and stream processing with Apache Pulsar and Apache Flink. The Pulsar Flink Connector
+ 2.7.0 supports features in Pulsar 2.7 and Flink 1.12 and is fully compatible with
+ Flink's data format. The Pulsar Flink Connector 2.7.0 will be contributed to the
+ Flink repository soon and the contribution process is ongoing.
+title: What's New in the Pulsar Flink Connector 2.7.0
+aliases:
+- /2021/01/07/pulsar-flink-connector-270.html
+---
+
+## About the Pulsar Flink Connector
+In order for companies to access real-time data insights, they need unified batch and streaming capabilities. Apache Flink unifies batch and stream processing into one single computing engine with “streams” as the unified data representation. Although developers have done extensive work at the computing and API layers, very little work has been done at the data messaging and storage layers. In reality, data is segregated into data silos, created by various storage and messaging technologies. As a result, there is still no single source-of-truth and the overall operation for the developer teams poses significant challenges. To address such operational challenges, we need to store data in streams. Apache Pulsar (together with Apache BookKeeper) perfectly meets the criteria: data is stored as one copy (source-of-truth) and can be accessed in streams (via pub-sub interfaces) and segments (for batch processing). When Flink and Pulsar come together, the two open source technologies create a unified data architecture for real-time, data-driven businesses.
+
+The [Pulsar Flink connector](https://github.com/streamnative/pulsar-flink/) provides elastic data processing with [Apache Pulsar](https://pulsar.apache.org/) and [Apache Flink](https://flink.apache.org/), allowing Apache Flink to read/write data from/to Apache Pulsar. The Pulsar Flink Connector enables you to concentrate on your business logic without worrying about the storage details.
+
+## Challenges
+When we first developed the Pulsar Flink Connector, it received wide adoption from both the Flink and Pulsar communities. Leveraging the Pulsar Flink connector, [Hewlett Packard Enterprise (HPE)](https://www.hpe.com/us/en/home.html) built a real-time computing platform, [BIGO](https://www.bigo.sg/) built a [real-time message processing system](https://pulsar-summit.org/en/event/asia-2020/sessions/how-bigo-builds-real-time-message-system-with-apache-pulsar-and-flink), and [Zhihu](https://www.zhihu.com/) is in the process of assessing the Connector’s fit for a real-time computing system.
+
+With more users adopting the Pulsar Flink Connector, it became clear that one of the common issues was evolving around data formats and specifically performing serialization and deserialization. While the Pulsar Flink connector leverages the Pulsar serialization, the previous connector versions did not support the Flink data format. As a result, users had to manually configure their setup in order to use the connector for real-time computing scenarios.
+
+To improve the user experience and make the Pulsar Flink connector easier-to-use, we built the capabilities to fully support the Flink data format, so users of the connector do not spend time on manual tuning and configuration.
+
+## What’s New in the Pulsar Flink Connector 2.7.0?
+The Pulsar Flink Connector 2.7.0 supports features in Apache Pulsar 2.7.0 and Apache Flink 1.12 and is fully compatible with the Flink connector and Flink message format. With the latest version, you can use important features in Flink, such as exactly-once sink, upsert Pulsar mechanism, Data Definition Language (DDL) computed columns, watermarks, and metadata. You can also leverage the Key-Shared subscription in Pulsar, and conduct serialization and deserialization without much configuration. Additionally, you can easily customize the configuration based on your business requirements.
+
+Below, we provide more details about the key features in the Pulsar Flink Connector 2.7.0.
+
+### Ordered message queue with high-performance
+When users needed to strictly guarantee the ordering of messages, only one consumer was allowed to consume them. This had a severe impact on throughput. To address this, we designed a Key_Shared subscription model in Pulsar that guarantees the ordering of messages and improves throughput by adding a Key to each message and routes messages with the same Key Hash to one consumer.
+
+
+
+
+
+
+Pulsar Flink Connector 2.7.0 supports the Key_Shared subscription model. You can enable this feature by setting `enable-key-hash-range` to `true`. The Key Hash range processed by each consumer is decided by the parallelism of tasks.
+
+
+### Introducing exactly-once semantics for Pulsar sink (based on the Pulsar transaction)
+In previous versions, sink operators only supported at-least-once semantics, which could not fully meet requirements for end-to-end consistency. To deduplicate messages, users had to do some dirty work, which was not user-friendly.
+
+Transactions are supported in Pulsar 2.7.0, which greatly improves the fault tolerance capability of the Flink sink. In the Pulsar Flink Connector 2.7.0, we designed exactly-once semantics for sink operators based on Pulsar transactions. Flink uses the two-phase commit protocol to implement TwoPhaseCommitSinkFunction. The main life cycle methods are beginTransaction(), preCommit(), commit(), abort(), recoverAndCommit(), recoverAndAbort().
+
+You can flexibly select semantics when creating a sink operator while the internal logic changes are transparent. Pulsar transactions are similar to the two-phase commit protocol in Flink, which greatly improves the reliability of the Connector Sink.
+
+It’s easy to implement beginTransaction and preCommit. You only need to start a Pulsar transaction and persist the TID of the transaction after the checkpoint. In the preCommit phase, you need to ensure that all messages are flushed to Pulsar, while any pre-committed messages will be committed eventually.
+
+We focus on recoverAndCommit and recoverAndAbort in implementation. Limited by Kafka features, Kafka connector adopts hack styles for recoverAndCommit. Pulsar transactions do not rely on the specific Producer, so it’s easy for you to commit and abort transactions based on TID.
+
+Pulsar transactions are highly efficient and flexible. Taking advantages of Pulsar and Flink, the Pulsar Flink connector is even more powerful. We will continue to improve transactional sink in the Pulsar Flink connector.
+
+### Introducing upsert-pulsar connector
+
+Users in the Flink community expressed their needs for the upsert Pulsar. After looking through mailing lists and issues, we’ve summarized the following three reasons.
+
+- Interpret Pulsar topic as a changelog stream that interprets records with keys as upsert (aka insert/update) events.
+- As a part of the real time pipeline, join multiple streams for enrichment and store results into a Pulsar topic for further calculation later. However, the result may contain update events.
+- As a part of the real time pipeline, aggregate on data streams and store results into a Pulsar topic for further calculation later. However, the result may contain update events.
+
+Based on the requirements, we add support for Upsert Pulsar. The upsert-pulsar connector allows for reading data from and writing data to Pulsar topics in the upsert fashion.
+
+- As a source, the upsert-pulsar connector produces a changelog stream, where each data record represents an update or delete event. More precisely, the value in a data record is interpreted as an UPDATE of the last value for the same key, if any (if a corresponding key does not exist yet, the update will be considered an INSERT). Using the table analogy, a data record in a changelog stream is interpreted as an UPSERT (aka INSERT/UPDATE) because any existing row with the same key is overwritten. Also, null values are interpreted in a special way: a record with a null value represents a “DELETE”.
+
+- As a sink, the upsert-pulsar connector can consume a changelog stream. It will write INSERT/UPDATE_AFTER data as normal Pulsar message values and write DELETE data as Pulsar message with null values (indicate tombstone for the key). Flink will guarantee the message ordering on the primary key by partitioning data on the values of the primary key columns, so the update/deletion messages on the same key will fall into the same partition.
+
+### Support new source interface and Table API introduced in [FLIP-27](https://cwiki.apache.org/confluence/display/FLINK/FLIP-27%3A+Refactor+Source+Interface#FLIP27:RefactorSourceInterface-BatchandStreamingUnification) and [FLIP-95](https://cwiki.apache.org/confluence/display/FLINK/FLIP-95%3A+New+TableSource+and+TableSink+interfaces)
+This feature unifies the source of the batch stream and optimizes the mechanism for task discovery and data reading. It is also the cornerstone of our implementation of Pulsar batch and streaming unification. The new Table API supports DDL computed columns, watermarks and metadata.
+
+### Support SQL read and write metadata as described in [FLIP-107](https://cwiki.apache.org/confluence/display/FLINK/FLIP-107%3A+Handling+of+metadata+in+SQL+connectors)
+FLIP-107 enables users to access connector metadata as a metadata column in table definitions. In real-time computing, users normally need additional information, such as eventTime, or customized fields. The Pulsar Flink connector supports SQL read and write metadata, so it is flexible and easy for users to manage metadata of Pulsar messages in the Pulsar Flink Connector 2.7.0. For details on the configuration, refer to [Pulsar Message metadata manipulation](https://github.com/streamnative/pulsar-flink#pulsar-message-metadata-manipulation).
+
+### Add Flink format type `atomic` to support Pulsar primitive types
+In the Pulsar Flink Connector 2.7.0, we add Flink format type `atomic` to support Pulsar primitive types. When processing with Flink requires a Pulsar primitive type, you can use `atomic` as the connector format. You can find more information on Pulsar primitive types [here](https://pulsar.apache.org/docs/en/schema-understand/).
+
+## Migration
+If you’re using the previous Pulsar Flink Connector version, you need to adjust your SQL and API parameters accordingly. Below we provide details on each.
+
+## SQL
+In SQL, we’ve changed the Pulsar configuration parameters in the DDL declaration. The name of some parameters are changed, but the values are not.
+- Remove the `connector.` prefix from the parameter names.
+- Change the name of the `connector.type` parameter into `connector`.
+- Change the startup mode parameter name from `connector.startup-mode` into `scan.startup.mode`.
+- Adjust Pulsar properties as `properties.pulsar.reader.readername=testReaderName`.
+
+If you use SQL in the Pulsar Flink Connector, you need to adjust your SQL configuration accordingly when migrating to Pulsar Flink Connector 2.7.0. The following sample shows the differences between previous versions and the 2.7.0 version for SQL.
+
+SQL in previous versions:
+
+```
+create table topic1(
+ `rip` VARCHAR,
+ `rtime` VARCHAR,
+ `uid` bigint,
+ `client_ip` VARCHAR,
+ `day` as TO_DATE(rtime),
+ `hour` as date_format(rtime,'HH')
+) with (
+ 'connector.type' ='pulsar',
+ 'connector.version' = '1',
+ 'connector.topic' ='persistent://public/default/test_flink_sql',
+ 'connector.service-url' ='pulsar://xxx',
+ 'connector.admin-url' ='http://xxx',
+ 'connector.startup-mode' ='earliest',
+ 'connector.properties.0.key' ='pulsar.reader.readerName',
+ 'connector.properties.0.value' ='testReaderName',
+ 'format.type' ='json',
+ 'update-mode' ='append'
+);
+```
+
+SQL in Pulsar Flink Connector 2.7.0:
+
+```
+create table topic1(
+ `rip` VARCHAR,
+ `rtime` VARCHAR,
+ `uid` bigint,
+ `client_ip` VARCHAR,
+ `day` as TO_DATE(rtime),
+ `hour` as date_format(rtime,'HH')
+) with (
+ 'connector' ='pulsar',
+ 'topic' ='persistent://public/default/test_flink_sql',
+ 'service-url' ='pulsar://xxx',
+ 'admin-url' ='http://xxx',
+ 'scan.startup.mode' ='earliest',
+ 'properties.pulsar.reader.readername' = 'testReaderName',
+ 'format' ='json'
+);
+```
+
+## API
+From an API perspective, we adjusted some classes and enabled easier customization.
+
+- To solve serialization issues, we changed the signature of the construction method `FlinkPulsarSink`, and added `PulsarSerializationSchema`.
+- We removed inappropriate classes related to row, such as `FlinkPulsarRowSink`, `FlinkPulsarRowSource`. If you need to deal with Row formats, you can use Apache Flink's Row related serialization components.
+
+You can build `PulsarSerializationSchema` by using `PulsarSerializationSchemaWrapper.Builder`. `TopicKeyExtractor` is moved into `PulsarSerializationSchemaWrapper`. When you adjust your API, you can take the following sample as reference.
+
+```
+new PulsarSerializationSchemaWrapper.Builder<>(new SimpleStringSchema())
+ .setTopicExtractor(str -> getTopic(str))
+ .build();
+```
+
+## Future Plan
+Future plans involve the design of a batch and stream solution integrated with Pulsar Source, based on the new Flink Source API (FLIP-27). The new solution will overcome the limitations of the current streaming source interface (SourceFunction) and simultaneously unify the source interfaces between the batch and streaming APIs.
+
+Pulsar offers a hierarchical architecture where data is divided into streaming, batch, and cold data, which enables Pulsar to provide infinite capacity. This makes Pulsar an ideal solution for unified batch and streaming.
+
+The batch and stream solution based on the new Flink Source API is divided into two simple parts: SplitEnumerator and Reader. SplitEnumerator discovers and assigns partitions, and Reader reads data from the partition.
+
+
+
+
+
+
+Apache Pulsar stores messages in the ledger block for users to locate the ledgers through Pulsar admin, and then provide broker partition, BookKeeper partition, Offloader partition, and other information through different partitioning policies. For more details, you can refer [here](https://github.com/streamnative/pulsar-flink/issues/187).
+
+
+## Conclusion
+The latest version of the Pulsar Flink Connector is now available and we encourage everyone to use/upgrade to the Pulsar Flink Connector 2.7.0. The new version provides significant user enhancements, enabled by various features in Pulsar 2.7 and Flink 1.12. We will be contributing the Pulsar Flink Connector 2.7.0 to the [Apache Flink repository](https://github.com/apache/flink/) soon. If you have any questions or concerns about the Pulsar Flink Connector, feel free to open issues in [this repository](https://github.com/streamnative/pulsar-flink/issues).
diff --git a/docs/content.tr/posts/2021-01-11-batch-fine-grained-fault-tolerance.md b/docs/content.tr/posts/2021-01-11-batch-fine-grained-fault-tolerance.md
new file mode 100644
index 0000000000..0bf3a36c39
--- /dev/null
+++ b/docs/content.tr/posts/2021-01-11-batch-fine-grained-fault-tolerance.md
@@ -0,0 +1,119 @@
+---
+authors:
+- name: Robert Metzger
+ rmetzger: null
+ twitter: rmetzger_
+date: "2021-01-11T00:00:00Z"
+excerpt: Apache Flink 1.9 introduced fine-grained recovery through FLIP-1. The Flink
+ APIs that are made for bounded workloads benefit from this change by individually
+ recovering failed operators, re-using results from the previous processing step.
+ This blog post gives an overview over these changes and evaluates their effectiveness.
+title: Exploring fine-grained recovery of bounded data sets on Flink
+aliases:
+- /news/2021/01/11/batch-fine-grained-fault-tolerance.html
+---
+
+Apache Flink is a very versatile tool for all kinds of data processing workloads. It can process incoming data within a few milliseconds or crunch through petabytes of bounded datasets (also known as batch processing).
+
+Processing efficiency is not the only parameter users of data processing systems care about. In the real world, system outages due to hardware or software failure are expected to happen all the time. For unbounded (or streaming) workloads, Flink is using periodic checkpoints to allow for reliable and correct recovery. In case of bounded data sets, having a reliable recovery mechanism is mission critical — as users do not want to potentially lose many hours of intermediate processing results.
+
+Apache Flink 1.9 introduced [fine-grained recovery](https://cwiki.apache.org/confluence/display/FLINK/FLIP-1+%3A+Fine+Grained+Recovery+from+Task+Failures) into its internal workload scheduler. The Flink APIs that are made for bounded workloads benefit from this change by individually recovering failed operators, re-using results from the previous processing step.
+
+In this blog post, we are going to give an overview over these changes, and we will experimentally validate their effectiveness.
+
+
+## **How does fine-grained recovery work?** {#how-does-fine-grained-recovery-work}
+
+For streaming jobs (and in [pipelined mode]({{< param DocsBaseUrl >}}flink-docs-master/api/java/org/apache/flink/api/common/ExecutionMode.html) for batch jobs), Flink is using a coarse-grained restart-strategy: upon failure, the entire job is restarted (but streaming jobs have an entirely different fault-tolerance model, using [checkpointing]({{< param DocsBaseUrl >}}flink-docs-release-1.12/concepts/stateful-stream-processing.html#checkpointing))
+
+For batch jobs, we can use a more sophisticated recovery strategy, by using cached intermediate results, thus only restarting parts of the pipeline.
+
+Let’s look at the topology below: Some connections are pipelined (between A1 and B1, as well as A2 and B2) -- data is immediately streamed from operator A1 to B1.
+
+However the output of B1 and B2 is cached on disk (indicated by the grey box). We call such connections blocking. If there’s a failure in the steps succeeding B1 and B2 and the results of B1 and B2 have already been produced, we don’t need to reprocess this part of the pipeline -- we can reuse the cached result.
+
+
+
+
+
+Looking at the case of a failure (here of D2), we see that we do not need to restart the entire job. Restarting C2 and all dependent tasks is sufficient. This is possible because we can read the cached results of B1 and B2. We call this recovery mechanism “fine-grained”, as we only restart parts of the topology to recover from a failure -- reducing the recovery time, resource consumption and overall job runtime.
+
+
+
+
+
+
+## **Experimenting with fine-grained recovery** {#experimenting-with-fine-grained-recovery}
+
+To validate the implementation, we’ve conducted a small experiment. The following sections will describe the setup, the experiment and the results.
+
+
+### **Setup** {#setup}
+
+**Hardware**: The experiment was performed on an idle MacBook Pro 2016 (16 GB of memory, SSD storage).
+
+**Test Job**: We used a [modified version](https://github.com/rmetzger/flip1-bench/blob/master/flip1-bench-jobs/src/main/java/com/ververica/TPCHQuery3.java) (for instrumentation only) of the [TPC-H Query 3](https://github.com/apache/flink/blob/master/flink-examples/flink-examples-batch/src/main/java/org/apache/flink/examples/java/relational/TPCHQuery3.java) example that is part of the Flink batch (DataSet API) examples, running on Flink 1.12
+
+This is the topology of the query:
+
+
+
+
+
+It has many blocking data exchanges where we cache intermediate results, if executed in batch mode.
+
+**Test Data**: We generated a [TPC-H dataset](http://www.tpc.org/tpch/) of 150 GB as the input.
+
+**Cluster**: We were running 4 TaskManagers with 2 slots each and 1 JobManager in standalone mode.
+
+Running this test job takes roughly 15 minutes with the given hardware and data.
+
+For **inducing failures** into the job, we decided to randomly throw exceptions in the operators. This has a number of benefits compared to randomly killing entire TaskManagers:
+
+* Killing a TaskManager would require starting and registering a new TaskManager — which introduces an uncontrollable factor into our benchmark: We don't want to test how quickly Flink is reconciling a cluster.
+* Killing an entire TaskManager would bring down on average 1/4th of all running operators. In larger production setups, a failure usually affects only a smaller fraction of all running operators. The differences between the execution modes would be less obvious if we killed entire TaskManagers.
+* Keeping TaskManagers across failures helps to better simulate using an external shuffle service, as intermediate results are preserved despite a failure.
+
+The failures are controlled by a central "[failure coordinator](https://github.com/rmetzger/flip1-bench/blob/master/flip1-bench-jobs/src/main/java/com/ververica/utilz/KillerServer.java)" which decides when to kill which operator.
+
+Failures are artificially triggered based on a configured mean failure frequency. The failures follow an [exponential distribution](https://en.wikipedia.org/wiki/Exponential_distribution), which is suitable for simulating continuous and independent failures at a configured average rate.
+
+
+### **The Experiment** {#the-experiment}
+
+We were running the job with two parameters which we varied in the benchmark:
+
+ * [Execution Mode]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/execution_configuration.html): [BATCH or PIPELINED]({{< param DocsBaseUrl >}}flink-docs-release-1.12/api/java/org/apache/flink/api/common/ExecutionMode.html).
+
+ In PIPELINED mode, except for data exchanges susceptible for deadlocks all exchanges are pipelined (e.g. upstream operators are streaming their result downstream). A failure means that we have to restart the entire job, and start the processing from scratch.
+
+ In BATCH mode, all shuffles and broadcasts are persisted before downstream consumption. You can imagine the execution to happen in steps. Since we are persisting intermediate results in BATCH mode, we do not have to reprocess all upstream operators in case of an (induced) failure. We just have to restart the step that was in progress during the failure.
+ * Mean Failure Frequency: This parameter controls the frequency of failures induced into the running job. If the parameter is set to 5 minutes, on average, a failure occurs every 5 minutes. The failures are following an exponential distribution. We’ve chosen values between 15 minutes and 20 seconds.
+
+Each configuration combination was executed at least 3 times. We report the average execution time. This is necessary due to the probabilistic behavior of the induced failures.
+
+
+### **The Results** {#the-results}
+
+The chart below shows the execution time in seconds for each batch and pipelined execution with different failure frequencies.
+
+
+
+
+
+We will now discuss some findings:
+
+1. **Execution time with rare failures**: Looking at the first few results on the left, where we compare the behavior with a mean failure frequency of 15 (=900s), 10 (=600s), 9 (=540s), 8 (=480s), 7 (=420s) minutes. The execution times are mostly the same, around 15 minutes. The batch execution time is usually lower, and more predictable. This behavior is easy to explain. If an error occurred later in the execution, the pipelined mode needs to start from scratch, while the batch mode can re-use previous intermediate results. The variances in runtime can be explained by statistical effects: if an error happens to be induced close to the end of a pipelined mode run, the entire job needs to rerun.
+2. **Execution time with frequent failures**: The results “in the middle”, with failure frequencies of 6, 5, 4, 3 and 2 minutes show that the pipelined mode execution gets unfeasible at some point: If failures happen on average every 3 minutes, the average execution time reaches more than 60 minutes, for failures every 2 minutes the time spikes to more than 120 minutes. The pipelined job is unable to finish the execution, only if we happen to find a window where no failure is induced for 15 minutes, the pipelined job manages to produce the final result. For more frequent failures, the pipelined mode did not manage to finish at all.
+3. **How many failures can the batch mode sustain?** The last numbers, with failure frequencies between 60 and 20 seconds are probably a bit unrealistic for real world scenarios. But we wanted to investigate how frequent failures can become for the batch mode to become unfeasible. With failures induced every 30 seconds, the average execution time is 30 minutes. In other words, even if you have two failures per minute, your execution time only doubles in this case. The batch mode is much more predictable and well behaved when it comes to execution times.
+
+
+## Conclusion {#conclusion}
+
+Based on these results, it makes a lot of sense to use the batch execution mode for batch workloads, as the resource consumption and overall execution times are substantially lower compared to the pipelined execution mode.
+
+In general, we recommend conducting your own performance experiments on your own hardware and with your own workloads, as results might vary from what we’ve presented here. Despite the findings here, the pipelined mode probably has some performance advantages in environments with rare failures and slower I/O (for example when using spinning disks, or network attached disks). On the other hand, CPU intensive workloads might benefit from the batch mode even in slow I/O environments.
+
+We should also note that the caching (and subsequent reprocessing on failure) only works if the cached results are still present -- this is currently only the case, if the TaskManager survives a failure. However, this is an unrealistic assumption as many failures would cause the TaskManager process to die. To mitigate this limitation, data processing frameworks employ external shuffle services that persist the cached results independent of the data processing framework. Since Flink 1.9, there is support for a [pluggable shuffle service](https://cwiki.apache.org/confluence/display/FLINK/FLIP-31%3A+Pluggable+Shuffle+Service), and there are tickets for adding implementations for YARN ([FLINK-13247](https://issues.apache.org/jira/browse/FLINK-13247)) and Kubernetes ([FLINK-13246](https://issues.apache.org/jira/browse/FLINK-13246)). Once these implementations are added, TaskManagers can recover cached results even if the process or machine got killed.
+
+Despite these considerations, we believe that fine-grained recovery is a great improvement for Flink’s batch capabilities, as it makes the framework much more efficient, even in unstable environments.
diff --git a/docs/content.tr/posts/2021-01-18-rocksdb.md b/docs/content.tr/posts/2021-01-18-rocksdb.md
new file mode 100644
index 0000000000..85e9704553
--- /dev/null
+++ b/docs/content.tr/posts/2021-01-18-rocksdb.md
@@ -0,0 +1,124 @@
+---
+authors:
+- Jun Qin: null
+ name: Jun Qin
+date: "2021-01-18T00:00:00Z"
+excerpt: This blog post will guide you through the benefits of using RocksDB to manage
+ your application’s state, explain when and how to use it and also clear up a few
+ common misconceptions.
+title: 'Using RocksDB State Backend in Apache Flink: When and How'
+aliases:
+- /2021/01/18/rocksdb.html
+---
+
+Stream processing applications are often stateful, “remembering” information from processed events and using it to influence further event processing. In Flink, the remembered information, i.e., state, is stored locally in the configured state backend. To prevent data loss in case of failures, the state backend periodically persists a snapshot of its contents to a pre-configured durable storage. The [RocksDB](https://rocksdb.org/) state backend (i.e., RocksDBStateBackend) is one of the three built-in state backends in Flink. This blog post will guide you through the benefits of using RocksDB to manage your application’s state, explain when and how to use it and also clear up a few common misconceptions. Having said that, this is **not** a blog post to explain how RocksDB works in-depth or how to do advanced troubleshooting and performance tuning; if you need help with any of those topics, you can reach out to the [Flink User Mailing List](https://flink.apache.org/community.html#mailing-lists).
+
+# State in Flink
+
+To best understand state and state backends in Flink, it’s important to distinguish between **in-flight state** and **state snapshots**. In-flight state, also known as working state, is the state a Flink job is working on. It is always stored locally in memory (with the possibility to spill to disk) and can be lost when jobs fail without impacting job recoverability. State snapshots, i.e., [checkpoints]({{< param DocsBaseUrl >}}flink-docs-stable/ops/state/checkpoints.html) and [savepoints]({{< param DocsBaseUrl >}}flink-docs-stable/ops/state/savepoints.html#what-is-a-savepoint-how-is-a-savepoint-different-from-a-checkpoint), are stored in a remote durable storage, and are used to restore the local state in the case of job failures. The appropriate state backend for a production deployment depends on scalability, throughput, and latency requirements.
+
+# What is RocksDB?
+
+Thinking of RocksDB as a distributed database that needs to run on a cluster and to be managed by specialized administrators is a common misconception. RocksDB is an embeddable persistent key-value store for fast storage. It interacts with Flink via the Java Native Interface (JNI). The picture below shows where RocksDB fits in a Flink cluster node. Details are explained in the following sections.
+
+
+
+
+
+
+
+# RocksDB in Flink
+
+Everything you need to use RocksDB as a state backend is bundled in the Apache Flink distribution, including the native shared library:
+
+ $ jar -tvf lib/flink-dist_2.12-1.12.0.jar| grep librocksdbjni-linux64
+ 8695334 Wed Nov 27 02:27:06 CET 2019 librocksdbjni-linux64.so
+
+At runtime, RocksDB is embedded in the TaskManager processes. It runs in native threads and works with local files. For example, if you have a job configured with RocksDBStateBackend running in your Flink cluster, you’ll see something similar to the following, where 32513 is the TaskManager process ID.
+
+ $ ps -T -p 32513 | grep -i rocksdb
+ 32513 32633 ? 00:00:00 rocksdb:low0
+ 32513 32634 ? 00:00:00 rocksdb:high0
+
+
+ Note
+The command is for Linux only. For other operating systems, please refer to their documentation.
+
+
+
+# When to use RocksDBStateBackend
+
+In addition to RocksDBStateBackend, Flink has two other built-in state backends: MemoryStateBackend and FsStateBackend. They both are heap-based, as in-flight state is stored in the JVM heap. For the moment being, let’s ignore MemoryStateBackend, as it is intended only for **local developments** and **debugging**, not for production use.
+
+With RocksDBStateBackend, in-flight state is first written into off-heap/native memory, and then flushed to local disks when a configured threshold is reached. This means that RocksDBStateBackend can support state larger than the total configured heap capacity. The amount of state that you can store in RocksDBStateBackend is only limited by the amount of **disk space** available across the entire cluster. In addition, since RocksDBStateBackend doesn’t use the JVM heap to store in-flight state, it’s not affected by JVM Garbage Collection and therefore has predictable latency.
+
+On top of full, self-contained state snapshots, RocksDBStateBackend also supports [incremental checkpointing]({{< param DocsBaseUrl >}}flink-docs-stable/ops/state/large_state_tuning.html#incremental-checkpoints) as a performance tuning option. An incremental checkpoint stores only the changes that occurred since the latest completed checkpoint. This dramatically reduces checkpointing time in comparison to performing a full snapshot. RocksDBStateBackend is currently the only state backend that supports incremental checkpointing.
+
+RocksDB is a good option when:
+
+- The state of your job is larger than can fit in local memory (e.g., long windows, large [keyed state]({{< param DocsBaseUrl >}}flink-docs-stable/dev/stream/state/state.html));
+- You’re looking into incremental checkpointing as a way to reduce checkpointing time;
+- You expect to have more predictable latency without being impacted by JVM Garbage Collection.
+
+Otherwise, if your application has **small state** or requires **very low latency**, you should consider **FsStateBackend**. As a rule of thumb, RocksDBStateBackend is a few times slower than heap-based state backends, because it stores key/value pairs as serialized bytes. This means that any state access (reads/writes) needs to go through a de-/serialization process crossing the JNI boundary, which is more expensive than working directly with the on-heap representation of state. The upside is that, for the same amount of state, it has a **low memory footprint** compared to the corresponding on-heap representation.
+
+# How to use RocksDBStateBackend
+
+RocksDB is fully embedded within and fully managed by the TaskManager process. RocksDBStateBackend can be configured at the cluster level as the default for the entire cluster, or at the job level for individual jobs. The job level configuration takes precedence over the cluster level configuration.
+
+## Cluster Level
+
+Add the following configuration in [`conf/flink-conf.yaml`]({{< param DocsBaseUrl >}}flink-docs-stable/deployment/config.html):
+
+ state.backend: rocksdb
+ state.backend.incremental: true
+ state.checkpoints.dir: hdfs:///flink-checkpoints # location to store checkpoints
+
+# Job Level
+
+Add the following into your job’s code after StreamExecutionEnvironment is created:
+
+ # 'env' is the created StreamExecutionEnvironment
+ # 'true' is to enable incremental checkpointing
+ env.setStateBackend(new RocksDBStateBackend("hdfs:///fink-checkpoints", true));
+
+
+ Note
+In addition to HDFS, you can also use other on-premises or cloud-based object stores if the corresponding dependencies are added under [FLINK_HOME/plugins]({{< param DocsBaseUrl >}}flink-docs-stable/deployment/filesystems/plugins.html).
+
+
+# Best Practices and Advanced Configuration
+
+We hope this overview helped you gain a better understanding of the role of RocksDB in Flink and how to successfully run a job with RocksDBStateBackend. To round it off, we’ll explore some best practices and a few reference points for further troubleshooting and performance tuning.
+
+## State Location in RocksDB
+
+As mentioned earlier, in-flight state in RocksDBStateBackend is spilled to files on disk. These files are located under the directory specified by the Flink configuration [`state.backend.rocksdb.localdir`]({{< param DocsBaseUrl >}}flink-docs-stable/deployment/config.html#state-backend-rocksdb-localdir). Because disk performance has a direct impact on RocksDB’s performance, it’s recommended that this directory is located on a **local** disk. It’s discouraged to configure it to a remote network-based location like NFS or HDFS, as writing to remote disks is usually slower. Also high availability is not a requirement for in-flight state. Local SSD disks are preferred if high disk throughput is required.
+
+State snapshots are persisted to remote durable storage. During state snapshotting, TaskManagers take a snapshot of the in-flight state and store it remotely. Transferring the state snapshot to remote storage is handled purely by the TaskManager itself without the involvement of the state backend. So, [`state.checkpoints.dir`]({{< param DocsBaseUrl >}}flink-docs-stable/deployment/config.html#state-checkpoints-dir) or the parameter you set in the code for a particular job can be different locations like an on-premises [HDFS](https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html) cluster or a cloud-based object store like [Amazon S3](https://aws.amazon.com/s3/), [Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/), [Google Cloud Storage](https://cloud.google.com/storage), [Alibaba OSS](https://www.alibabacloud.com/product/oss), etc.
+
+## Troubleshooting RocksDB
+
+To check how RocksDB is behaving in production, you should look for the RocksDB log file named LOG. By default, this log file is located in the same directory as your data files, i.e., the directory specified by the Flink configuration [`state.backend.rocksdb.localdir`]({{< param DocsBaseUrl >}}flink-docs-stable/deployment/config.html#state-backend-rocksdb-localdir). When enabled, [RocksDB statistics](https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide#rocksdb-statistics) are also logged there to help diagnose potential problems. For further information, check [RocksDB Troubleshooting Guide](https://github.com/facebook/rocksdb/wiki/RocksDB-Troubleshooting-Guide) in [RocksDB Wiki](https://github.com/facebook/rocksdb/wiki). If you are interested in the RocksDB behavior trend over time, you can consider enabling [RocksDB native metrics]({{< param DocsBaseUrl >}}flink-docs-stable/deployment/config.html#rocksdb-native-metrics) for your Flink job.
+
+
+ Note
+From Flink 1.10, RocksDB logging was effectively disabled by [setting the log level to HEADER](https://github.com/apache/flink/blob/master/flink-state-backends/flink-statebackend-rocksdb/src/main/java/org/apache/flink/contrib/streaming/state/PredefinedOptions.java#L64). To enable it, check [How to get RocksDB's LOG file back for advanced troubleshooting](https://ververica.zendesk.com/hc/en-us/articles/360015933320-How-to-get-RocksDB-s-LOG-file-back-for-advanced-troubleshooting).
+
+
+
+ Warning
+Enabling RocksDB's native metrics in Flink may have a negative performance impact on your job.
+
+
+## Tuning RocksDB
+
+Since Flink 1.10, Flink configures RocksDB’s memory allocation to the amount of managed memory of each task slot by default. The primary mechanism for improving memory-related performance issues is to increase Flink’s [managed memory]({{< param DocsBaseUrl >}}flink-docs-stable/deployment/memory/mem_setup_tm.html#managed-memory) via the Flink configuration [`taskmanager.memory.managed.size`]({{< param DocsBaseUrl >}}flink-docs-stable/deployment/config.html#taskmanager-memory-managed-size) or [`taskmanager.memory.managed.fraction`]({{< param DocsBaseUrl >}}flink-docs-stable/deployment/config.html#taskmanager-memory-managed-fraction). For more fine-grained control, you should first disable the automatic memory management by setting [`state.backend.rocksdb.memory.managed`]({{< param DocsBaseUrl >}}flink-docs-stable/deployment/config.html#state-backend-rocksdb-memory-managed) to `false`, then start with the following Flink configuration: [`state.backend.rocksdb.block.cache-size`]({{< param DocsBaseUrl >}}flink-docs-stable/deployment/config.html#state-backend-rocksdb-block-cache-size) (corresponding to block_cache_size in RocksDB), [`state.backend.rocksdb.writebuffer.size`]({{< param DocsBaseUrl >}}flink-docs-stable/deployment/config.html#state-backend-rocksdb-writebuffer-size) (corresponding to write_buffer_size in RocksDB), and [`state.backend.rocksdb.writebuffer.count`]({{< param DocsBaseUrl >}}flink-docs-stable/deployment/config.html#state-backend-rocksdb-writebuffer-count) (corresponding to max_write_buffer_number in RocksDB). For more details, check [this blog post](https://www.ververica.com/blog/manage-rocksdb-memory-size-apache-flink) on how to manage RocksDB memory size in Flink and the [RocksDB Memory Usage](https://github.com/facebook/rocksdb/wiki/Memory-usage-in-RocksDB) Wiki page.
+
+While data is being written or overwritten in RocksDB, flushing from memory to local disks and data compaction are managed in the background by RocksDB threads. On a machine with many CPU cores, you should increase the parallelism of background flushing and compaction by setting the Flink configuration [`state.backend.rocksdb.thread.num`]({{< param DocsBaseUrl >}}flink-docs-stable/deployment/config.html#state-backend-rocksdb-thread-num) (corresponding to max_background_jobs in RocksDB). The default configuration is usually too small for a production setup. If your job reads frequently from RocksDB, you should consider enabling [bloom filters](https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide#bloom-filters).
+
+For other RocksDBStateBackend configurations, check the Flink documentation on [Advanced RocksDB State Backends Options]({{< param DocsBaseUrl >}}flink-docs-stable/deployment/config.html#advanced-rocksdb-state-backends-options). For further tuning, check [RocksDB Tuning Guide](https://github.com/facebook/rocksdb/wiki/RocksDB-Tuning-Guide) in [RocksDB Wiki](https://github.com/facebook/rocksdb/wiki).
+
+# Conclusion
+
+The [RocksDB](https://rocksdb.org/) state backend (i.e., RocksDBStateBackend) is one of the three state backends bundled in Flink, and can be a powerful choice when configuring your streaming applications. It enables scalable applications maintaining up to many terabytes of state with exactly-once processing guarantees. If the state of your Flink job is too large to fit on the JVM heap, you are interested in incremental checkpointing, or you expect to have predictable latency, you should use RocksDBStateBackend. Since RocksDB is embedded in TaskManager processes as native threads and works with files on local disks, RocksDBStateBackend is supported out-of-the-box without the need to further setup and manage any external systems or processes.
diff --git a/docs/content.tr/posts/2021-01-19-release-1.12.1.md b/docs/content.tr/posts/2021-01-19-release-1.12.1.md
new file mode 100644
index 0000000000..fc43633be8
--- /dev/null
+++ b/docs/content.tr/posts/2021-01-19-release-1.12.1.md
@@ -0,0 +1,228 @@
+---
+authors:
+- name: Xintong Song
+ xtsong: null
+date: "2021-01-19T00:00:00Z"
+title: Apache Flink 1.12.1 Released
+aliases:
+- /news/2021/01/19/release-1.12.1.html
+---
+
+The Apache Flink community released the first bugfix version of the Apache Flink 1.12 series.
+
+This release includes 79 fixes and minor improvements for Flink 1.12.0. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.12.1.
+
+
+Attention:
+Using unaligned checkpoints in Flink 1.12.0 combined with two/multiple inputs tasks or with union inputs for single input tasks can result in corrupted state.
+
+This can happen if a new checkpoint is triggered before recovery is fully completed. For state to be corrupted a task with two or more input gates must receive a checkpoint barrier exactly at the same time this tasks finishes recovering spilled in-flight data. In such case this new checkpoint can succeed, with corrupted/missing in-flight data, which will result in various deserialisation/corrupted data stream errors when someone attempts to recover from such corrupted checkpoint.
+
+Using unaligned checkpoints in Flink 1.12.1 , a corruption may occur in the checkpoint following a declined checkpoint.
+
+A late barrier of a canceled checkpoint may lead to buffers being not written into the successive checkpoint, such that recovery is not possible. This happens, when the next checkpoint barrier arrives at a given operator before all previous barriers arrived, which can only happen after cancellation in unaligned checkpoints.
+
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.12.1
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.12.1
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.12.1
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-18897 ] - Add documentation for the maxwell-json format
+
+[FLINK-20352 ] - Rework command line interface documentation page
+
+[FLINK-20353 ] - Rework logging documentation page
+
+[FLINK-20354 ] - Rework standalone deployment documentation page
+
+[FLINK-20355 ] - Rework K8s deployment documentation page
+
+[FLINK-20356 ] - Rework Mesos deployment documentation page
+
+[FLINK-20422 ] - Remove from .html files in flink documentation
+
+[FLINK-20485 ] - Map views are deserialized multiple times
+
+[FLINK-20601 ] - Rework PyFlink CLI documentation
+
+
+
+ Bug
+
+
+[FLINK-19369 ] - BlobClientTest.testGetFailsDuringStreamingForJobPermanentBlob hangs
+
+[FLINK-19435 ] - Deadlock when loading different driver classes concurrently using Class.forName
+
+[FLINK-19725 ] - Logger cannot be initialized due to timeout: LoggerInitializationException is thrown
+
+[FLINK-19880 ] - Fix ignore-parse-errors not work for the legacy JSON format
+
+[FLINK-20213 ] - Partition commit is delayed when records keep coming
+
+[FLINK-20221 ] - DelimitedInputFormat does not restore compressed filesplits correctly leading to dataloss
+
+[FLINK-20273 ] - Fix Table api Kafka connector Sink Partitioner Document Error
+
+[FLINK-20372 ] - Update Kafka SQL connector page to mention properties.* options
+
+[FLINK-20389 ] - UnalignedCheckpointITCase failure caused by NullPointerException
+
+[FLINK-20404 ] - ZooKeeper quorum fails to start due to missing log4j library
+
+[FLINK-20419 ] - Insert fails due to failure to generate execution plan
+
+[FLINK-20428 ] - ZooKeeperLeaderElectionConnectionHandlingTest.testConnectionSuspendedHandlingDuringInitialization failed with "No result is expected since there was no leader elected before stopping the server, yet"
+
+[FLINK-20429 ] - KafkaTableITCase.testKafkaTemporalJoinChangelog failed with unexpected results
+
+[FLINK-20433 ] - UnalignedCheckpointTestBase.execute failed with "TestTimedOutException: test timed out after 300 seconds"
+
+[FLINK-20464 ] - Some Table examples are not built correctly
+
+[FLINK-20467 ] - Fix the Example in Python DataStream Doc
+
+[FLINK-20470 ] - MissingNode can't be casted to ObjectNode when deserializing JSON
+
+[FLINK-20476 ] - New File Sink end-to-end test Failed
+
+[FLINK-20486 ] - Hive temporal join should allow monitor interval smaller than 1 hour
+
+[FLINK-20492 ] - The SourceOperatorStreamTask should implement cancelTask() and finishTask()
+
+[FLINK-20493 ] - SQLClientSchemaRegistryITCase failed with "Could not build the flink-dist image"
+
+[FLINK-20521 ] - Null result values are being swallowed by RPC system
+
+[FLINK-20525 ] - StreamArrowPythonGroupWindowAggregateFunctionOperator doesn't handle rowtime and proctime properly
+
+[FLINK-20543 ] - Fix typo in upsert kafka docs
+
+[FLINK-20554 ] - The Checkpointed Data Size of the Latest Completed Checkpoint is incorrectly displayed on the Overview page of the UI
+
+[FLINK-20582 ] - Fix typos in `CREATE Statements` docs
+
+[FLINK-20607 ] - a wrong example in udfs page.
+
+[FLINK-20615 ] - Local recovery and sticky scheduling end-to-end test timeout with "IOException: Stream Closed"
+
+[FLINK-20626 ] - Canceling a job when it is failing will result in job hanging in CANCELING state
+
+[FLINK-20630 ] - [Kinesis][DynamoDB] DynamoDB Streams Consumer fails to consume from Latest
+
+[FLINK-20646 ] - ReduceTransformation does not work with RocksDBStateBackend
+
+[FLINK-20648 ] - Unable to restore job from savepoint when using Kubernetes based HA services
+
+[FLINK-20664 ] - Support setting service account for TaskManager pod
+
+[FLINK-20665 ] - FileNotFoundException when restore from latest Checkpoint
+
+[FLINK-20666 ] - Fix the deserialized Row losing the field_name information in PyFlink
+
+[FLINK-20669 ] - Add the jzlib LICENSE file in flink-python module
+
+[FLINK-20703 ] - HiveSinkCompactionITCase test timeout
+
+[FLINK-20704 ] - Some rel data type does not implement the digest correctly
+
+[FLINK-20756 ] - PythonCalcSplitConditionRule is not working as expected
+
+[FLINK-20764 ] - BatchGroupedReduceOperator does not emit results for singleton inputs
+
+[FLINK-20781 ] - UnalignedCheckpointITCase failure caused by NullPointerException
+
+[FLINK-20784 ] - .staging_xxx does not exist, when insert into hive
+
+[FLINK-20793 ] - Fix NamesTest due to code style refactor
+
+[FLINK-20803 ] - Version mismatch between spotless-maven-plugin and google-java-format plugin
+
+[FLINK-20841 ] - Fix compile error due to duplicated generated files
+
+
+
+ Improvement
+
+
+[FLINK-19013 ] - Log start/end of state restoration
+
+[FLINK-19259 ] - Use classloader release hooks with Kinesis producer to avoid metaspace leak
+
+[FLINK-19832 ] - Improve handling of immediately failed physical slot in SlotSharingExecutionSlotAllocator
+
+[FLINK-20055 ] - Datadog API Key exposed in Flink JobManager logs
+
+[FLINK-20168 ] - Translate page 'Flink Architecture' into Chinese
+
+[FLINK-20209 ] - Add missing checkpoint configuration to Flink UI
+
+[FLINK-20298 ] - Replace usage of in flink documentation
+
+[FLINK-20468 ] - Enable leadership control in MiniCluster to test JM failover
+
+[FLINK-20510 ] - Enable log4j2 monitor interval by default
+
+[FLINK-20519 ] - Extend HBase notice with transitively bundled dependencies
+
+[FLINK-20570 ] - The `NOTE` tip style is different from the others in process_function page.
+
+[FLINK-20588 ] - Add docker-compose as appendix to Mesos documentation
+
+[FLINK-20629 ] - [Kinesis][EFO] Migrate from DescribeStream to DescribeStreamSummary
+
+[FLINK-20647 ] - Use yield to generate output datas in ProcessFunction for Python DataStream
+
+[FLINK-20650 ] - Mark "native-k8s" as deprecated in docker-entrypoint.sh
+
+[FLINK-20651 ] - Use Spotless/google-java-format for code formatting/enforcement
+
+[FLINK-20682 ] - Add configuration options related to hadoop
+
+[FLINK-20697 ] - Correct the Type of "lookup.cache.ttl" in jdbc.md/jdbc.zh.md
+
+[FLINK-20790 ] - Generated classes should not be put under src/ directory
+
+[FLINK-20792 ] - Allow shorthand invocation of spotless
+
+[FLINK-20805 ] - Blink runtime classes partially ignored by spotless
+
+[FLINK-20822 ] - Don't check whether a function is generic in hive catalog
+
+[FLINK-20866 ] - Add how to list jobs in Yarn deployment documentation when HA enabled
+
+
+
+ Task
+
+
+[FLINK-20300 ] - Create Flink 1.12 release notes
+
+[FLINK-20906 ] - Update copyright year to 2021 for NOTICE files
+
+
diff --git a/docs/content.tr/posts/2021-01-29-release-1.10.3.md b/docs/content.tr/posts/2021-01-29-release-1.10.3.md
new file mode 100644
index 0000000000..b58b829f45
--- /dev/null
+++ b/docs/content.tr/posts/2021-01-29-release-1.10.3.md
@@ -0,0 +1,126 @@
+---
+authors:
+- name: Xintong Song
+ xtsong: null
+date: "2021-01-29T00:00:00Z"
+title: Apache Flink 1.10.3 Released
+aliases:
+- /news/2021/01/29/release-1.10.3.html
+---
+
+The Apache Flink community released the third bugfix version of the Apache Flink 1.10 series.
+
+This release includes 36 fixes and minor improvements for Flink 1.10.2. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.10.3.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.10.3
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.10.3
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.10.3
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+List of resolved issues:
+
+ Bug
+
+
+[FLINK-14087 ] - throws java.lang.ArrayIndexOutOfBoundsException when emiting the data using RebalancePartitioner.
+
+[FLINK-15170 ] - WebFrontendITCase.testCancelYarn fails on travis
+
+[FLINK-15467 ] - Should wait for the end of the source thread during the Task cancellation
+
+[FLINK-16246 ] - Exclude "SdkMBeanRegistrySupport" from dynamically loaded AWS connectors
+
+[FLINK-17341 ] - freeSlot in TaskExecutor.closeJobManagerConnection cause ConcurrentModificationException
+
+[FLINK-17458 ] - TaskExecutorSubmissionTest#testFailingScheduleOrUpdateConsumers
+
+[FLINK-17677 ] - FLINK_LOG_PREFIX recommended in docs is not always available
+
+[FLINK-18081 ] - Fix broken links in "Kerberos Authentication Setup and Configuration" doc
+
+[FLINK-18196 ] - flink throws `NullPointerException` when executeCheckpointing
+
+[FLINK-18212 ] - Init lookup join failed when use udf on lookup table
+
+[FLINK-18832 ] - BoundedBlockingSubpartition does not work with StreamTask
+
+[FLINK-18959 ] - Fail to archiveExecutionGraph because job is not finished when dispatcher close
+
+[FLINK-19022 ] - AkkaRpcActor failed to start but no exception information
+
+[FLINK-19109 ] - Split Reader eats chained periodic watermarks
+
+[FLINK-19135 ] - (Stream)ExecutionEnvironment.execute() should not throw ExecutionException
+
+[FLINK-19237 ] - LeaderChangeClusterComponentsTest.testReelectionOfJobMaster failed with "NoResourceAvailableException: Could not allocate the required slot within slot request timeout"
+
+[FLINK-19401 ] - Job stuck in restart loop due to excessive checkpoint recoveries which block the JobMaster
+
+[FLINK-19557 ] - Issue retrieving leader after zookeeper session reconnect
+
+[FLINK-19675 ] - The plan of is incorrect when Calc contains WHERE clause, composite fields access and Python UDF at the same time
+
+[FLINK-19901 ] - Unable to exclude metrics variables for the last metrics reporter.
+
+[FLINK-20013 ] - BoundedBlockingSubpartition may leak network buffer if task is failed or canceled
+
+[FLINK-20018 ] - pipeline.cached-files option cannot escape ':' in path
+
+[FLINK-20033 ] - Job fails when stopping JobMaster
+
+[FLINK-20065 ] - UnalignedCheckpointCompatibilityITCase.test failed with AskTimeoutException
+
+[FLINK-20076 ] - DispatcherTest.testOnRemovedJobGraphDoesNotCleanUpHAFiles does not test the desired functionality
+
+[FLINK-20183 ] - Fix the default PYTHONPATH is overwritten in client side
+
+[FLINK-20218 ] - AttributeError: module 'urllib' has no attribute 'parse'
+
+[FLINK-20875 ] - [CVE-2020-17518] Directory traversal attack: remote file writing through the REST API
+
+
+
+ Improvement
+
+
+[FLINK-16753 ] - Exception from AsyncCheckpointRunnable should be wrapped in CheckpointException
+
+[FLINK-18287 ] - Correct the documentation of Python Table API in SQL pages
+
+[FLINK-19055 ] - MemoryManagerSharedResourcesTest contains three tests running extraordinary long
+
+[FLINK-19105 ] - Table API Sample Code Error
+
+[FLINK-19252 ] - Jaas file created under io.tmp.dirs - folder not created if not exists
+
+[FLINK-19339 ] - Support Avro's unions with logical types
+
+[FLINK-19523 ] - Hide sensitive command-line configurations
+
+
+
+ Task
+
+
+[FLINK-20906 ] - Update copyright year to 2021 for NOTICE files
+
+
diff --git a/docs/content.tr/posts/2021-02-10-native-k8s-with-ha.md b/docs/content.tr/posts/2021-02-10-native-k8s-with-ha.md
new file mode 100644
index 0000000000..56db15d1a9
--- /dev/null
+++ b/docs/content.tr/posts/2021-02-10-native-k8s-with-ha.md
@@ -0,0 +1,158 @@
+---
+authors:
+- Yang Wang: null
+ name: Yang Wang
+date: "2021-02-10T00:00:00Z"
+excerpt: Kubernetes provides built-in functionalities that Flink can leverage for
+ JobManager failover. In Flink 1.12 (FLIP-144), the community implemented a Kubernetes
+ High Availability (HA) service as an alternative to ZooKeeper for highly available
+ production setups. In this blogpost, we will have a close look at how to deploy
+ Flink applications natively on Kubernetes cluster with HA.
+title: How to natively deploy Flink on Kubernetes with High-Availability (HA)
+aliases:
+- /2021/02/10/native-k8s-with-ha.html
+---
+
+Flink has supported resource management systems like YARN and Mesos since the early days; however, these were not designed for the fast-moving cloud-native architectures that are increasingly gaining popularity these days, or the growing need to support complex, mixed workloads (e.g. batch, streaming, deep learning, web services).
+For these reasons, more and more users are using Kubernetes to automate the deployment, scaling and management of their Flink applications.
+
+From release to release, the Flink community has made significant progress in **integrating natively with Kubernetes**, from active resource management to “Zookeeperless” High Availability (HA).
+In this blogpost, we'll recap the technical details of deploying Flink applications natively on Kubernetes, diving deeper into Flink’s Kubernetes HA architecture. We'll then walk you through a [**hands-on example**](#example-application-cluster-with-ha) of running a Flink [application cluster]({{< param DocsBaseUrl >}}flink-docs-stable/deployment/#application-mode) on Kubernetes with HA enabled.
+We’ll end with a conclusion covering the advantages of running Flink natively on Kubernetes, and an outlook into future work.
+
+# Native Flink on Kubernetes Integration
+
+Before we dive into the technical details of how the Kubernetes-based HA service works, let us briefly explain what _native_ means in the context of Flink deployments on Kubernetes:
+
+1. Flink is **self-contained**. There will be an embedded Kubernetes client in the Flink client, and so you will not need other external tools (_e.g._ kubectl, Kubernetes dashboard) to create a Flink cluster on Kubernetes.
+
+2. The Flink client will contact the Kubernetes API server **directly** to create the JobManager deployment. The configuration located on the client side will be shipped to the JobManager pod, as well as the log4j and Hadoop configurations.
+
+3. Flink’s ResourceManager will talk to the Kubernetes API server to **allocate and release** the TaskManager pods dynamically **on-demand**.
+
+All in all, this is similar to how Flink integrates with other resource management systems (_e.g._ YARN, Mesos), so it should be somewhat straightforward to integrate with Kubernetes if you’ve managed such deployments before — and especially if you already had some internal deployer for the lifecycle management of multiple Flink jobs.
+
+
+
+
+ Fig. 1: Architecture of Flink's native Kubernetes integration.
+
+
+
+
+
+# Kubernetes High Availability Service
+
+High Availability (HA) is a common requirement when bringing Flink to production: it helps prevent a single point of failure for Flink clusters.
+Previous to the [1.12 release](https://flink.apache.org/news/2020/12/10/release-1.12.0.html), Flink has provided a Zookeeper HA service that has been widely used in production setups and that can be integrated in standalone cluster, YARN, or Kubernetes deployments.
+However, managing a Zookeeper cluster on Kubernetes for HA would require an additional operational cost that could be avoided because, in the end, Kubernetes also provides some public APIs for leader election and configuration storage (_i.e._ ConfigMap).
+From Flink 1.12, we leverage these features to make running a HA-configured Flink cluster on Kubernetes more convenient to users.
+
+
+
+
+ Fig. 2: Architecture of Flink's Kubernetes High Availability (HA) service.
+
+
+
+
+The above diagram shows the architecture of Flink’s Kubernetes HA service, which works as follows:
+
+ 1. For the **leader election**, a set of eligible JobManagers is identified. They all race to declare themselves as the leader, with one eventually becoming the active leader. The active JobManager then continually "heartbeats" to renew its position as the leader. In the meantime, all other standby JobManagers periodically make new attempts to become the leader — this ensures that the JobManager could **failover quickly**. Different components (_e.g._ ResourceManager, JobManager, Dispatcher, RestEndpoint) have separate leader election services and ConfigMaps.
+
+ 2. The active leader publishes its address to the ConfigMap. It’s important to note that Flink will use the same ConfigMap for contending lock and storing the leader address. This ensures that there is **no unexpected change** snuck in during a periodic update.
+
+ 3. The leader retrieval service is used to find the active leader’s address and allow the components to then **register** themselves. For example, TaskManagers retrieve the address of ResourceManager and JobManager for registration and to offer slots. Flink uses a **Kubernetes watch** in the leader retrieval service — once the content of ConfigMap changes, it usually means that the leader has changed, and so the listener can **get the latest leader address immediately**.
+
+ 4. All other meta information (_e.g._ running jobs, job graphs, completed checkpoints and checkpointer counter) will be directly stored in the corresponding ConfigMaps. Only the leader can update the ConfigMap. The HA data will only be **cleaned up** once the Flink cluster reaches the global **terminal state**. Please note that only the pointers are stored in the ConfigMap; the concrete data will be stored in the DistributedStorage. This level of indirection is necessary to keep the amount of data in ConfigMap small (ConfigMap is built for data less than 1MB whereas state can grow to multiple GBs).
+
+# Example: Application Cluster with HA
+
+You'll need a running Kubernetes cluster and to get `kubeconfig` properly set to follow along.
+You can use `kubectl get nodes` to verify that you’re all set!
+In this blog post, we’re using [minikube](https://minikube.sigs.k8s.io/docs/start/) for local testing.
+
+**1. Build a Docker image with the Flink job** (`my-flink-job.jar`) **baked in**
+
+```dockerfile
+FROM flink:1.12.1
+RUN mkdir -p $FLINK_HOME/usrlib
+COPY /path/of/my-flink-job.jar $FLINK_HOME/usrlib/my-flink-job.jar
+```
+
+Use the above Dockerfile to build a user image (``) and then push it to your remote image repository:
+
+```bash
+$ docker build -t .
+
+$ docker push
+```
+
+
+**2. Start a Flink Application Cluster**
+
+```bash
+$ ./bin/flink run-application \
+ --detached \
+ --parallelism 4 \
+ --target kubernetes-application \
+ -Dkubernetes.cluster-id=k8s-ha-app-1 \
+ -Dkubernetes.container.image= \
+ -Dkubernetes.jobmanager.cpu=0.5 \
+ -Dkubernetes.taskmanager.cpu=0.5 \
+ -Dtaskmanager.numberOfTaskSlots=4 \
+ -Dkubernetes.rest-service.exposed.type=NodePort \
+ -Dhigh-availability=org.apache.flink.kubernetes.highavailability.KubernetesHaServicesFactory \
+ -Dhigh-availability.storageDir=s3://flink-bucket/flink-ha \
+ -Drestart-strategy=fixed-delay \
+ -Drestart-strategy.fixed-delay.attempts=10 \
+ -Dcontainerized.master.env.ENABLE_BUILT_IN_PLUGINS=flink-s3-fs-hadoop-1.12.1.jar \
+ -Dcontainerized.taskmanager.env.ENABLE_BUILT_IN_PLUGINS=flink-s3-fs-hadoop-1.12.1.jar \
+ local:///opt/flink/usrlib/my-flink-job.jar
+```
+
+
+**3. Access the Flink Web UI** (http://minikube-ip-address:node-port) **and check that the job is running!**
+
+```
+2021-02-05 17:26:13,403 INFO org.apache.flink.kubernetes.KubernetesClusterDescriptor [] - Create flink application cluster k8s-ha-app-1 successfully, JobManager Web Interface: http://192.168.64.21:32388
+```
+
+You should be able to find a similar log in the Flink client and get the JobManager web interface URL.
+
+
+**4. Kill the JobManager to simulate failure**
+
+```bash
+$ kubectl exec {jobmanager_pod_name} -- /bin/sh -c "kill 1"
+```
+
+
+**5. Verify that the job recovers from the latest successful checkpoint**
+
+Refresh the Flink Web UI until the new JobManager is launched, and then search for the following JobManager logs to verify that the job recovers from the latest successful checkpoint:
+
+```
+2021-02-05 09:44:01,636 INFO org.apache.flink.runtime.checkpoint.CheckpointCoordinator [] - Restoring job 00000000000000000000000000000000 from Checkpoint 101 @ 1612518074802 for 00000000000000000000000000000000 located at .
+```
+
+
+**6. Cancel the job**
+
+The job can be cancelled through the Flink the Web UI, or using the following command:
+
+```bash
+$ ./bin/flink cancel --target kubernetes-application -Dkubernetes.cluster-id=
+```
+
+When the job is cancelled, all the Kubernetes resources created by Flink (e.g. JobManager deployment, TaskManager pods, service, Flink configuration ConfigMap, leader-related ConfigMaps) will be deleted automatically.
+
+# Conclusion
+
+The native Kubernetes integration was first introduced in Flink 1.10, abstracting a lot of the complexities of hosting, configuring, managing and operating Flink clusters in cloud-native environments.
+After three major releases, the community has made great progress in supporting multiple deployment modes (i.e. session and application) and an alternative HA setup that doesn’t depend on Zookeeper.
+
+Compared with [standalone]({{< param DocsBaseUrl >}}flink-docs-master/deployment/resource-providers/standalone/kubernetes.html) Kubernetes deployments, the native integration is more **user-friendly** and requires less upfront knowledge about Kubernetes.
+Given that Flink is now aware of the underlying Kubernetes cluster, it also can benefit from dynamic resource allocation and make **more efficient use of Kubernetes cluster resources**.
+The next building block to deepen Flink’s native integration with Kubernetes is the pod template ([FLINK-15656](https://issues.apache.org/jira/browse/FLINK-15656)), which will greatly enhance the flexibility of using advanced Kubernetes features (_e.g._ volumes, init container, sidecar container).
+This work is already in progress and will be added in the upcoming 1.13 release!
diff --git a/docs/content.tr/posts/2021-03-03-release-1.12.2.md b/docs/content.tr/posts/2021-03-03-release-1.12.2.md
new file mode 100644
index 0000000000..e73226e30d
--- /dev/null
+++ b/docs/content.tr/posts/2021-03-03-release-1.12.2.md
@@ -0,0 +1,233 @@
+---
+authors:
+- name: Yuan Mei
+ yuan: null
+- name: Roman Khachatryan
+ roman: null
+date: "2021-03-03T00:00:00Z"
+title: Apache Flink 1.12.2 Released
+aliases:
+- /news/2021/03/03/release-1.12.2.html
+---
+
+The Apache Flink community released the next bugfix version of the Apache Flink 1.12 series.
+
+This release includes 83 fixes and minor improvements for Flink 1.12.1. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.12.2.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.12.2
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.12.2
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.12.2
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+List of resolved issues:
+
+ Sub-task
+
+
+[FLINK-21070 ] - Overloaded aggregate functions cause converter errors
+
+[FLINK-21486 ] - Add sanity check when switching from Rocks to Heap timers
+
+
+
+ Bug
+
+
+[FLINK-12461 ] - Document binary compatibility situation with Scala beyond 2.12.8
+
+[FLINK-16443 ] - Fix wrong fix for user-code CheckpointExceptions
+
+[FLINK-19771 ] - NullPointerException when accessing null array from postgres in JDBC Connector
+
+[FLINK-20309 ] - UnalignedCheckpointTestBase.execute is failed
+
+[FLINK-20462 ] - MailboxOperatorTest.testAvoidTaskStarvation
+
+[FLINK-20500 ] - UpsertKafkaTableITCase.testTemporalJoin test failed
+
+[FLINK-20565 ] - Fix typo in EXPLAIN Statements docs.
+
+[FLINK-20580 ] - Missing null value handling for SerializedValue's getByteArray()
+
+[FLINK-20654 ] - Unaligned checkpoint recovery may lead to corrupted data stream
+
+[FLINK-20663 ] - Managed memory may not be released in time when operators use managed memory frequently
+
+[FLINK-20675 ] - Asynchronous checkpoint failure would not fail the job anymore
+
+[FLINK-20680 ] - Fails to call var-arg function with no parameters
+
+[FLINK-20798 ] - Using PVC as high-availability.storageDir could not work
+
+[FLINK-20832 ] - Deliver bootstrap resouces ourselves for website and documentation
+
+[FLINK-20848 ] - Kafka consumer ID is not specified correctly in new KafkaSource
+
+[FLINK-20913 ] - Improve new HiveConf(jobConf, HiveConf.class)
+
+[FLINK-20921 ] - Fix Date/Time/Timestamp in Python DataStream
+
+[FLINK-20933 ] - Config Python Operator Use Managed Memory In Python DataStream
+
+[FLINK-20942 ] - Digest of FLOAT literals throws UnsupportedOperationException
+
+[FLINK-20944 ] - Launching in application mode requesting a ClusterIP rest service type results in an Exception
+
+[FLINK-20947 ] - Idle source doesn't work when pushing watermark into the source
+
+[FLINK-20961 ] - Flink throws NullPointerException for tables created from DataStream with no assigned timestamps and watermarks
+
+[FLINK-20992 ] - Checkpoint cleanup can kill JobMaster
+
+[FLINK-20998 ] - flink-raw-1.12.jar does not exist
+
+[FLINK-21009 ] - Can not disable certain options in Elasticsearch 7 connector
+
+[FLINK-21013 ] - Blink planner does not ingest timestamp into StreamRecord
+
+[FLINK-21024 ] - Dynamic properties get exposed to job's main method if user parameters are passed
+
+[FLINK-21028 ] - Streaming application didn't stop properly
+
+[FLINK-21030 ] - Broken job restart for job with disjoint graph
+
+[FLINK-21059 ] - KafkaSourceEnumerator does not honor consumer properties
+
+[FLINK-21069 ] - Configuration "parallelism.default" doesn't take effect for TableEnvironment#explainSql
+
+[FLINK-21071 ] - Snapshot branches running against flink-docker dev-master branch
+
+[FLINK-21104 ] - UnalignedCheckpointITCase.execute failed with "IllegalStateException"
+
+[FLINK-21132 ] - BoundedOneInput.endInput is called when taking synchronous savepoint
+
+[FLINK-21138 ] - KvStateServerHandler is not invoked with user code classloader
+
+[FLINK-21140 ] - Extract zip file dependencies before adding to PYTHONPATH
+
+[FLINK-21144 ] - KubernetesResourceManagerDriver#tryResetPodCreationCoolDown causes fatal error
+
+[FLINK-21155 ] - FileSourceTextLinesITCase.testBoundedTextFileSourceWithTaskManagerFailover does not pass
+
+[FLINK-21158 ] - wrong jvm metaspace and overhead size show in taskmanager metric page
+
+[FLINK-21163 ] - Python dependencies specified via CLI should not override the dependencies specified in configuration
+
+[FLINK-21169 ] - Kafka flink-connector-base dependency should be scope compile
+
+[FLINK-21208 ] - pyarrow exception when using window with pandas udaf
+
+[FLINK-21213 ] - e2e test fail with 'As task is already not running, no longer decline checkpoint'
+
+[FLINK-21215 ] - Checkpoint was declined because one input stream is finished
+
+[FLINK-21216 ] - StreamPandasConversionTests Fails
+
+[FLINK-21225 ] - OverConvertRule does not consider distinct
+
+[FLINK-21226 ] - Reintroduce TableColumn.of for backwards compatibility
+
+[FLINK-21274 ] - At per-job mode, during the exit of the JobManager process, if ioExecutor exits at the end, the System.exit() method will not be executed.
+
+[FLINK-21277 ] - SQLClientSchemaRegistryITCase fails to download testcontainers/ryuk:0.3.0
+
+[FLINK-21312 ] - SavepointITCase.testStopSavepointWithBoundedInputConcurrently is unstable
+
+[FLINK-21323 ] - Stop-with-savepoint is not supported by SourceOperatorStreamTask
+
+[FLINK-21351 ] - Incremental checkpoint data would be lost once a non-stop savepoint completed
+
+[FLINK-21361 ] - FlinkRelMdUniqueKeys matches on AbstractCatalogTable instead of CatalogTable
+
+[FLINK-21412 ] - pyflink DataTypes.DECIMAL is not available
+
+[FLINK-21452 ] - FLIP-27 sources cannot reliably downscale
+
+[FLINK-21453 ] - BoundedOneInput.endInput is NOT called when doing stop with savepoint WITH drain
+
+[FLINK-21490 ] - UnalignedCheckpointITCase fails on azure
+
+[FLINK-21492 ] - ActiveResourceManager swallows exception stack trace
+
+
+
+ New Feature
+
+
+[FLINK-20359 ] - Support adding Owner Reference to Job Manager in native kubernetes setup
+
+
+
+ Improvement
+
+
+[FLINK-9844 ] - PackagedProgram does not close URLClassLoader
+
+[FLINK-20417 ] - Handle "Too old resource version" exception in Kubernetes watch more gracefully
+
+[FLINK-20491 ] - Support Broadcast Operation in BATCH execution mode
+
+[FLINK-20517 ] - Support mixed keyed/non-keyed operations in BATCH execution mode
+
+[FLINK-20770 ] - Incorrect description for config option kubernetes.rest-service.exposed.type
+
+[FLINK-20907 ] - Table API documentation promotes deprecated syntax
+
+[FLINK-21020 ] - Bump Jackson to 20.10.5[.1] / 2.12.1
+
+[FLINK-21034 ] - Rework jemalloc switch to use an environment variable
+
+[FLINK-21035 ] - Deduplicate copy_plugins_if_required calls
+
+[FLINK-21036 ] - Consider removing automatic configuration fo number of slots from docker
+
+[FLINK-21037 ] - Deduplicate configuration logic in docker entrypoint
+
+[FLINK-21042 ] - Fix code example in "Aggregate Functions" section in Table UDF page
+
+[FLINK-21048 ] - Refactor documentation related to switch memory allocator
+
+[FLINK-21123 ] - Upgrade Beanutils 1.9.x to 1.9.4
+
+[FLINK-21164 ] - Jar handlers don't cleanup temporarily extracted jars
+
+[FLINK-21210 ] - ApplicationClusterEntryPoints should explicitly close PackagedProgram
+
+[FLINK-21381 ] - Kubernetes HA documentation does not state required service account and role
+
+
+
+ Task
+
+
+[FLINK-20529 ] - Publish Dockerfiles for release 1.12.0
+
+[FLINK-20534 ] - Add Flink 1.12 MigrationVersion
+
+[FLINK-20536 ] - Update migration tests in master to cover migration from release-1.12
+
+[FLINK-20960 ] - Add warning in 1.12 release notes about potential corrupt data stream with unaligned checkpoint
+
+[FLINK-21358 ] - Missing snapshot version compatibility for 1.12
+
+
+
diff --git a/docs/content.tr/posts/2021-03-11-batch-execution-mode.md b/docs/content.tr/posts/2021-03-11-batch-execution-mode.md
new file mode 100644
index 0000000000..60d5671060
--- /dev/null
+++ b/docs/content.tr/posts/2021-03-11-batch-execution-mode.md
@@ -0,0 +1,233 @@
+---
+authors:
+- dwysakowicz: null
+ name: Dawid Wysakowicz
+ twitter: dwysakowicz
+date: "2021-03-11T00:00:00Z"
+excerpt: Apache Flink 1.12 introduced batch execution mode through FLIP-140. This
+ blog post discusses when to use the new mode, discusses its benefits and gives examples
+ of programs that can be run in it.
+title: A Rundown of Batch Execution Mode in the DataStream API
+aliases:
+- /2021/03/11/batch-execution-mode.html
+---
+
+Flink has been following the mantra that [Batch is a Special Case of Streaming](https://flink.apache.org/news/2019/02/13/unified-batch-streaming-blink.html) since the very early days. As the project evolved to address specific uses cases, different core APIs ended up being implemented for _batch_ (DataSet API) and _streaming_ execution (DataStream API), but the higher-level Table API/SQL was subsequently designed following this mantra of _unification_. With Flink 1.12, the community worked on bringing a similarly unified behaviour to the DataStream API, and took the first steps towards enabling efficient [batch execution in the DataStream API](https://cwiki.apache.org/confluence/x/4i94CQ).
+
+The idea behind making the DataStream API a unified abstraction for _batch_ and _streaming_ execution instead of maintaining separate APIs is two-fold:
+
+* Reusability: efficient batch and stream processing under the same API would allow you to easily switch between both execution modes without rewriting any code. So, a job could be easily reused to process real-time and historical data.
+
+* Operational simplicity: providing a unified API would mean using a single set of connectors, maintaining a single codebase and being able to easily implement mixed execution pipelines e.g. for use cases like backfilling.
+
+
+The difference between BATCH and STREAMING vs BOUNDED and UNBOUNDED is subtle, and a common source of confusion — so, let's start by clarifying that. These terms might seem mostly interchangeable, but in reality serve different purposes:
+
+_Bounded_ and _unbounded_ refer to the **characteristics** of the streams you want to process: whether or not they are known to have an end. The terms are also sometimes applied to the applications processing these streams: an application that only processes bounded streams is a _bounded_ stream processing application that eventually finishes; while an _unbounded_ stream processing application processes an unbounded stream and runs forever (or until canceled).
+
+_Batch_ and _streaming_ are **execution modes**. Batch execution is only applicable to bounded streams/applications because it exploits the fact that it can process the whole data (e.g. from a partition) in a batch rather than event-by-event, and possibly execute different batches one after the other. Continuous streaming execution runs everything at the same time, continuously processes (small groups of) events and is applicable to both bounded and unbounded applications.
+
+Based on that differentiation, there are two main scenarios that result of the combination of these properties:
+1. A _bounded_ Stream Processing Application that is executed in a _batch_ mode, which you can call a Batch (Processing) Application.
+2. An _unbounded_ Stream Processing Application that is executed in a _streaming_ mode. This is the combination that has been the primary use case for the DataStream API in Flink.
+
+It's also possible to have a _bounded_ Stream Processing Application that is executed in _streaming_ mode, but this combination is less significant and likely to be used e.g. in a test environment or in other rare corner cases.
+
+## Which API and execution mode should I use?
+
+Before going into the choice of execution mode, try looking at your use case from a different angle: do you need to process structured data? Does your data have a schema of some sort? The Table API/SQL will most likely be the right choice. In fact, the majority of _batch_ use cases should be expressed with the [Table API/SQL]({{< param DocsBaseUrl >}}flink-docs-stable/dev/table/)! Finite, bounded data can most often be organized, described with a schema and put into a catalog. This is where the SQL API shines, giving you a rich set of functions and operators out-of-the box with low-level optimizations and broad connector support, all supported by standard SQL. And it works for _streaming_ use cases, as well!
+
+However, if you need explicit control over the execution graph, you want to manually control the state of your operations, or you need to be able to upgrade Flink (which applies to _unbounded_ applications), the [DataStream API]({{< param DocsBaseUrl >}}flink-docs-stable/dev/datastream_api.html) is the right choice.
+If the DataStream API sounds like the best fit for your use cases, the next decision is what execution mode to run your program in.
+
+**When should you use the _batch_ mode, then?**
+
+The simple answer is if you run your computation on _bounded_, historic data. The _batch_ mode has a few benefits:
+1. In _bounded_ data there is no such thing as late data. You do not need to think how to adjust the watermarking logic that you use in your application. In a streaming case, you need to maintain the order in which the records were written - which is often not possible to recreate when reading from e.g. historic files. In _batch_ mode you don't need to care about that as the data will be sorted according to the timestamp and "perfect" watermarks will be injected automatically.
+2. The way streaming applications are scheduled and react upon failure have significant performance implications that can be optimized when dealing with _bounded_ data. We recommend reading through the blogposts on [pipelined region scheduling](https://flink.apache.org/2020/12/15/pipelined-region-sheduling.html) and [fine-grained fault tolerance](https://flink.apache.org/news/2021/01/11/batch-fine-grained-fault-tolerance.html) to better understand these performance implications.
+3. It can simplify the operational overhead of setting up and maintaining your pipelines. For example, there is no need to configure checkpointing, which otherwise requires things like choosing a state backend or setting up distributed storage for checkpoints.
+
+## How to use the _batch_ execution
+
+Once you have a good understanding of which execution mode is better suited to your use case, you can configure it via the `execution.runtime-mode` setting. There are three possible values:
+
+- `STREAMING`: The classic DataStream execution mode (default)
+- `BATCH`: Batch-style execution on the DataStream API
+- `AUTOMATIC`: Let the system decide based on the boundedness of the sources
+
+This can be configured via command line parameters of `bin/flink run ...` when submitting a job:
+
+```bash
+$ bin/flink run -Dexecution.runtime-mode=BATCH examples/streaming/WordCount.jar
+```
+
+, or programmatically when creating/configuring the `StreamExecutionEnvironment`
+
+ ```java
+StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
+env.setRuntimeMode(RuntimeExecutionMode.BATCH);
+ ```
+
+We recommend passing the execution mode when submitting the job, in order to keep your code configuration-free and potentially be able to execute the same application in different execution modes.
+
+### Hello _batch_ mode
+
+Now that you know how to set the execution mode, let's try to write a simple word count program and see how it behaves depending on the chosen mode. The program is a variation of a standard word count, where we count number of orders placed
+in a given currency. We derive the number in 1-day windows. We read the input data from a new [unified file source]({{< param DocsBaseUrl >}}flink-docs-release-1.12/api/java/org/apache/flink/connector/file/src/FileSource.html) and then apply a [window aggregation]({{< param DocsBaseUrl >}}flink-docs-release-1.12/dev/stream/operators/windows.html#windows). Notice that we will be checking the side output for late arriving data, which can illustrate how watermarks behave differently in the two execution modes.
+
+```java
+public class WindowWordCount {
+ private static final OutputTag LATE_DATA = new OutputTag<>(
+ "late-data",
+ BasicArrayTypeInfo.STRING_ARRAY_TYPE_INFO);
+
+ public static void main(String[] args) throws Exception {
+
+ StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
+ ParameterTool config = ParameterTool.fromArgs(args);
+
+ Path path = new Path(config.get("path"));
+ SingleOutputStreamOperator> dataStream = env
+ .fromSource(
+ FileSource.forRecordStreamFormat(new TsvFormat(), path).build(),
+ WatermarkStrategy.forBoundedOutOfOrderness(Duration.ofDays(1))
+ .withTimestampAssigner(new OrderTimestampAssigner()),
+ "Text file"
+ )
+ .keyBy(value -> value[4]) // group by currency
+ .window(TumblingEventTimeWindows.of(Time.days(1)))
+ .sideOutputLateData(LATE_DATA)
+ .aggregate(
+ new CountFunction(), // count number of orders in a given currency
+ new CombineWindow());
+
+ int i = 0;
+ DataStream lateData = dataStream.getSideOutput(LATE_DATA);
+ try (CloseableIterator results = lateData.executeAndCollect()) {
+ while (results.hasNext()) {
+ String[] late = results.next();
+ if (i < 100) {
+ System.out.println(Arrays.toString(late));
+ }
+ i++;
+ }
+ }
+ System.out.println("Number of late records: " + i);
+
+ try (CloseableIterator> results
+ = dataStream.executeAndCollect()) {
+ while (results.hasNext()) {
+ System.out.println(results.next());
+ }
+ }
+ }
+}
+```
+
+If we simply execute the above program with:
+
+```bash
+$ bin/flink run examples/streaming/WindowWordCount.jar
+```
+
+it will be executed in a _streaming_ mode by default. Because of that, it will use the given watermarking strategy and produce windows based on it. In real-time scenarios, it might happen that records do not adhere to watermarks and
+some records might actually be considered late, so you'll get results like:
+
+```
+...
+[1431681, 130936, F, 135996.21, NOK, 2020-04-11 07:53:02.674, 2-HIGH, Clerk#000000922, 0, quests. slyly regular platelets cajole ironic deposits: blithely even depos]
+[1431744, 143957, F, 36391.24, CHF, 2020-04-11 07:53:27.631, 2-HIGH, Clerk#000000406, 0, eans. blithely special instructions are quickly. q]
+[1431812, 58096, F, 55292.05, CAD, 2020-04-11 07:54:16.956, 2-HIGH, Clerk#000000561, 0, , regular packages use. slyly even instr]
+[1431844, 77335, O, 415443.20, CAD, 2020-04-11 07:54:40.967, 2-HIGH, Clerk#000000446, 0, unts across the courts wake after the accounts! ruthlessly]
+[1431968, 122005, F, 44964.19, JPY, 2020-04-11 07:55:42.661, 1-URGENT, Clerk#000000001, 0, nal theodolites against the slyly special packages poach blithely special req]
+[1432097, 26035, F, 42464.15, CAD, 2020-04-11 07:57:13.423, 5-LOW, Clerk#000000213, 0, l accounts hang blithely. carefully blithe dependencies ]
+[1432193, 97537, F, 87856.63, NOK, 2020-04-11 07:58:06.862, 4-NOT SPECIFIED, Clerk#000000356, 0, furiously furiously brave foxes. bo]
+[1432291, 112045, O, 114327.52, JPY, 2020-04-11 07:59:12.912, 1-URGENT, Clerk#000000732, 0, ding to the fluffily ironic requests haggle carefully alongsid]
+Number of late records: 1514
+(GBP,374,2020-03-31T00:00:00Z,2020-04-01T00:00:00Z)
+(HKD,401,2020-03-31T00:00:00Z,2020-04-01T00:00:00Z)
+(CNY,402,2020-03-31T00:00:00Z,2020-04-01T00:00:00Z)
+(CAD,392,2020-03-31T00:00:00Z,2020-04-01T00:00:00Z)
+(JPY,411,2020-03-31T00:00:00Z,2020-04-01T00:00:00Z)
+(CHF,371,2020-03-31T00:00:00Z,2020-04-01T00:00:00Z)
+(NOK,370,2020-03-31T00:00:00Z,2020-04-01T00:00:00Z)
+(RUB,365,2020-03-31T00:00:00Z,2020-04-01T00:00:00Z)
+...
+```
+
+However, if you execute the exact same code using the _batch_ execution mode:
+
+```bash
+$ bin/flink run -Dexecution.runtime-mode=BATCH examples/streaming/WordCount.jar
+```
+
+you'll see that there won't be any late records.
+
+```
+Number of late records: 0
+(GBP,374,2020-03-31T00:00:00Z,2020-04-01T00:00:00Z)
+(HKD,401,2020-03-31T00:00:00Z,2020-04-01T00:00:00Z)
+(CNY,402,2020-03-31T00:00:00Z,2020-04-01T00:00:00Z)
+(CAD,392,2020-03-31T00:00:00Z,2020-04-01T00:00:00Z)
+(JPY,411,2020-03-31T00:00:00Z,2020-04-01T00:00:00Z)
+(CHF,371,2020-03-31T00:00:00Z,2020-04-01T00:00:00Z)
+(NOK,370,2020-03-31T00:00:00Z,2020-04-01T00:00:00Z)
+(RUB,365,2020-03-31T00:00:00Z,2020-04-01T00:00:00Z)
+```
+
+Also, if you compare the execution timelines of both runs, you'll see that the jobs were scheduled differently. In the case of _batch_ execution, the two stages were executed one after the other:
+
+[](/img/blog/2021-03-11-batch-execution-mode/batch-execution.png)
+
+whereas for _streaming_ both stages started at the same time.
+
+[](/img/blog/2021-03-11-batch-execution-mode/stream-execution.png)
+
+### Example: Two input operators
+
+Operators that process data from multiple inputs can be executed in both execution modes as well. Let's see how we may implement a join of two data sets on a common key. (Disclaimer: Make sure to think first if you [should use the Table API/SQL](#which-api-and-execution-mode-should-i-use) for your join!). We will enrich a stream of orders with information about the customer and we will make it run either of the two modes.
+
+For this particular use case, the DataStream API provides a `DataStream#join` method that requires a window in which the join must happen; since we'll process the data in bulk, we can use a `GlobalWindow` (that would otherwise not be very useful on its own in an _unbounded_ case due to state size concerns):
+
+```java
+DataStreamSource orders = env
+ .fromSource(
+ FileSource.forRecordStreamFormat(new TsvFormat(), ordersPath).build(),
+ WatermarkStrategy.noWatermarks()
+ .withTimestampAssigner((record, previous) -> -1),
+ "Text file"
+ );
+
+Path customersPath = new Path(config.get("customers"));
+DataStreamSource customers = env
+ .fromSource(
+ FileSource.forRecordStreamFormat(new TsvFormat(), customersPath).build(),
+ WatermarkStrategy.noWatermarks()
+ .withTimestampAssigner((record, previous) -> -1),
+ "Text file"
+ );
+
+DataStream> dataStream = orders.join(customers)
+ .where(order -> order[1]).equalTo(customer -> customer[0]) // join on customer id
+ .window(GlobalWindows.create())
+ .trigger(ContinuousProcessingTimeTrigger.of(Time.seconds(5)))
+ .apply(new ProjectFunction());
+```
+
+You might notice the `ContinuousProcessingTimeTrigger`. It is there for the application to produce results in a _streaming_ mode. In a _streaming_ application the `GlobalWindow` never finishes so we need to add a processing time trigger to emit results from time to time. We believe triggers are a way to control when to emit results, but are not part of the logic what to emit. Therefore we think it is safe to ignore those in case of _batch_ mode and that's what we do. In _batch_ mode you will just get one final result for the join.
+
+## Looking into the future
+
+Support for efficient _batch_ execution in the DataStream API was introduced in Flink 1.12 as a first step towards achieving a truly unified runtime for both batch and stream processing. This is not the end of the story yet! The community is still working on some optimizations and exploring more use cases that can be enabled with this new mode.
+
+One of the first efforts we want to finalize is providing world-class support for transactional sinks in both execution modes, for _bounded_ and _unbounded_ streams. An experimental API for [transactional sinks](https://cwiki.apache.org/confluence/x/KEJ4CQ) was already introduced in Flink 1.12, so we're working on stabilizing it and would be happy to hear feedback about its current state!
+
+We are also thinking how the two modes can be brought closer together and benefit from each other. A common pattern that we hear from users is bootstrapping state of a streaming job from a batch one. There are two somewhat different approaches we are considering here:
+
+1. Having a mixed graph, where one of the branches would have only bounded sources and the other would reflect the unbounded part — you can think of such a graph as effectively two separate jobs. The bounded part would be executed first and sink into the state of a common vertex of the two parts. This jobs' purpose would be to populate the state of the common operator. Once that job is done, we could proceed to running the unbounded part.
+
+2. Another approach is to run the exact same program first on the _bounded_ data. However, this time we wouldn't assume completeness of the job; instead, we would produce the state of all operators up to a certain point in time and store it as a savepoint. Later on, we could use the savepoint to start the application on the _unbounded_ data.
+
+Lastly, to achieve feature parity with the DataSet API (Flink's legacy API for batch-style execution), we are looking into the topic of iterations and how to meet the different usage patterns depending on the mode. In STREAMING mode, iterations serve as a loopback edge, but we don't necessarily need to keep track of the iteration step. On the other hand, the iteration generation is vital for Machine Learning (ML) algorithms, which are the primary use case for iterations in BATCH mode.
+
+Have you tried the new BATCH execution mode in the DataStream API? How was your experience? We are happy to hear your feedback and stories!
\ No newline at end of file
diff --git a/docs/content.tr/posts/2021-04-15-release-statefun-3.0.0.md b/docs/content.tr/posts/2021-04-15-release-statefun-3.0.0.md
new file mode 100644
index 0000000000..4265d17abf
--- /dev/null
+++ b/docs/content.tr/posts/2021-04-15-release-statefun-3.0.0.md
@@ -0,0 +1,197 @@
+---
+authors:
+- igalshilman: null
+ name: Igal Shilman
+ twitter: IgalShilman
+- name: Tzu-Li (Gordon) Tai
+ twitter: tzulitai
+ tzulitai: null
+date: "2021-04-15T08:00:00Z"
+subtitle: The Apache Flink community is happy to announce the release of Stateful
+ Functions (StateFun) 3.0.0.
+title: 'Stateful Functions 3.0.0: Remote Functions Front and Center'
+aliases:
+- /news/2021/04/15/release-statefun-3.0.0.html
+---
+
+The Apache Flink community is happy to announce the release of Stateful Functions (StateFun) 3.0.0!
+Stateful Functions is a cross-platform stack for building Stateful Serverless applications, making it radically simpler
+to develop scalable, consistent, and elastic distributed applications.
+
+This new release brings **remote functions to the front and center of StateFun**, making the disaggregated setup that
+separates the application logic from the StateFun cluster the default. It is now easier, more efficient, and more
+ergonomic to write applications that live in their own processes or containers. With the new Java SDK this is now also
+possible for all JVM languages, in addition to Python.
+
+## Background
+
+Starting with the first StateFun release, before the project was donated to the Apache Software Foundation, our focus was: **making scalable stateful applications easy to build and run**.
+
+The first StateFun version introduced an SDK that allowed writing stateful functions that build up a StateFun application packaged and deployed as a particular Flink job submitted to a Flink cluster. Having functions executing within the same JVM as Flink has some advantages, such as the deployment's performance and immutability. However, it had a few limitations:
+
+1. ❌ ⠀Functions can be written only in a JVM based language.
+2. ❌ ⠀A blocking call/CPU heavy task in one function can affect other functions and operations that need to complete in a timely manner, such as checkpointing.
+3. ❌ ⠀Deploying a new version of the function required a stateful upgrade of the backing Flink job.
+
+With StateFun 2.0.0, the debut official release after the project was donated to Apache Flink, the community introduced the concept of *remote functions*, together with an additional SDK for the Python language.
+A remote function is a function that executes in a separate process and is invoked via HTTP by the StateFun cluster processes.
+Remote functions introduce a new and exciting capability: **state and compute disaggregation** - allowing users to scale the functions independently of the StateFun cluster, which essentially plays the role of handling messaging and state in a consistent and fault-tolerant manner.
+
+While remote functions did address the limitations (1) and (2) mentioned above, we still had some room to improve:
+
+1. ❌ ⠀A stateful restart of the StateFun processes is required to register a new function or to change the state definitions of an existing function.
+2. ❌ ⠀The SDK had a few friction points around state and messaging ergonomics - it had a heavy dependency on Google’s Protocol Buffers for it’s multi-language object representation.
+
+As business requirements evolve, the application logic naturally evolves with it. For StateFun applications, this often means
+typical changes such as adding new functions to the application or updating some existing functions to include new state to be persisted.
+This is where the first limitation becomes an issue - such operations require a stateful restart of the StateFun cluster
+in order for the changes to be discovered, meaning that *all* functions of the application would have some downtime for
+this to take effect. With remote functions being standalone instances that are supposedly independent of the StateFun cluster processes,
+this is obviously non-ideal. By making remote functions the default in StateFun, we're aiming at enabling full flexibility
+and ease of operations for application upgrades.
+
+The second limitation around state and messaging ergonomics had came up a few times from our users. Prior to this release,
+all state values and message objects were strictly required to be Protobuf objects. This made it cumbersome to use common
+types such as JSON or simple strings as state and messages.
+
+With the new StateFun 3.0.0 release, the community has enhanced the remote functions protocol (the protocol that describes how StateFun communicates with the remote function processes) to address all the issues mentioned above.
+Building on the new protocol, we rewrote the Python SDK and introduced a brand new remote Java SDK.
+
+## New Features
+
+### Unified Language SDKs
+
+One of the goals that we set up to achieve with the SDKs is a unified set of concepts across all the languages.
+Having standard and unified SDK concepts across the board makes it straightforward for users to switch the languages their
+functions are implemented in.
+
+Here is the same function written with the updated Python SDK and newly added Java SDK in StateFun 3.0.0:
+
+#### Python
+
+```python
+@functions.bind(typename="example/greeter", specs=[ValueSpec(name="visits", type=IntType)])
+async def greeter(context: Context, message: Message):
+ # update the visit count.
+ visits = context.storage.visits or 0
+ visits += 1
+ context.storage.visits = visits
+
+ # compute a greeting
+ name = message.as_string()
+ greeting = f"Hello there {name} at the {visits}th time!"
+
+ caller = context.caller
+
+ context.send(message_builder(target_typename=caller.typename,
+ target_id=caller.id,
+ str_value=greeting))
+```
+
+#### Java
+
+```java
+static final class Greeter implements StatefulFunction {
+ static final ValueSpec VISITS = ValueSpec.named("visits").withIntType();
+
+ @Override
+ public CompletableFuture apply(Context context, Message message){
+ // update the visits count
+ int visits = context.storage().get(VISITS).orElse(0);
+ visits++;
+ context.storage().set(VISITS, visits);
+
+ // compute a greeting
+ var name = message.asUtf8String();
+ var greeting = String.format("Hello there %s at the %d-th time!\n", name, visits);
+
+ // reply to the caller with a greeting
+ var caller = context.caller().get();
+ context.send(
+ MessageBuilder.forAddress(caller)
+ .withValue(greeting)
+ .build()
+ );
+
+ return context.done();
+ }
+}
+```
+
+Although there are some language specific differences, the terms and concepts are the same:
+
+* an address scoped storage acting as a key-value store for a particular address.
+* a unified cross-language way to send, receive, and store values across languages (see also *Cross-Language Type System* below).
+* `ValueSpec` to describe the state name, type and possibly expiration configuration. Please note that it is no longer necessary to declare the state ahead of time in a `module.yaml`.
+
+For a detailed SDK tutorial, we would like to encourage you to visit:
+
+- [Java SDK showcase](https://github.com/apache/flink-statefun-playground/tree/release-3.0/java/showcase)
+- [Python SDK showcase](https://github.com/apache/flink-statefun-playground/tree/release-3.0/python/showcase)
+
+### Cross-Language Type System
+
+StateFun 3.0.0 introduces a new type system with cross-language support for common primitive types, such as boolean,
+integer, long, etc. This is of course all transparent for the user, so you don't need to worry about it. Functions
+implemented in various languages (e.g. Java or Python) can message each other by directly sending supported primitive
+values as message arguments. Moreover, the type system is used for state values as well - so, you can expect that a function
+can safely read previous state after reimplementing it in a different language.
+
+The type system is also very easily extensible to support custom message types, such as JSON or Protobuf messages.
+StateFun makes this super easy by providing builder utilities to help you create custom types.
+
+### Dynamic Registration of State and Functions
+
+Starting with this release it is now possible to dynamically register new functions without going through a stateful upgrade cycle of the StateFun cluster (which entails the standard process of performing a stateful restart of a Flink job).
+This is achieved with a new `endpoint` definition that supports target URL templating.
+
+Consider the following definition:
+
+```yaml
+endpoints:
+ - endpoint:
+ meta:
+ kind: http
+ spec:
+ functions: example/*
+ urlPathTemplate: https://loadbalancer.svc.cluster.local/{function.name}
+```
+
+With this definition, all messages being addressed to functions under the namespace `example` will be forwarded to the specified templated URL.
+For example, a message being addressed to a function of typename `example/greeter` would be forwarded to `https://loadbalancer.svc.cluster.local/greeter`.
+
+This unlocks the possibility to dynamically introduce new functions into the topology without ever restarting the Stateful Functions application.
+
+## Summary
+
+With 3.0.0, we've brought remote functions to the front and center of StateFun. This is done by a new remote function protocol that:
+
+1. ✅ ⠀Allows registering a new function or changing the state definitions of an existing function to happen dynamically without any downtime, and
+2. ✅ ⠀Provides a cross-language type system, which comes along with a few built-in primitive types, that can be used for messaging and state.
+
+A new Java SDK was added for remote functions to extend the array of supported languages to also include all JVM based languages.
+The language SDKs now have unified concepts and constructs in their APIs so that they will all feel familiar to work with
+when switching around languages for your functions. In upcoming releases, the community is also looking forward to
+continuing building on top of the new remote function protocol to provide an even more language SDKs, such as Golang.
+
+## Release Resources
+
+The binary distribution and source artifacts are now available on the updated [Downloads](https://flink.apache.org/downloads.html)
+page of the Flink website, and the most recent Python SDK distribution is available on [PyPI](https://pypi.org/project/apache-flink-statefun/).
+You can also find official StateFun Docker images of the new version on [Dockerhub](https://hub.docker.com/r/apache/flink-statefun).
+
+For more details, check the [updated documentation]({{< param DocsBaseUrl >}}flink-statefun-docs-release-3.0/) and the
+[release notes](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12348822)
+for a detailed list of changes and new features if you plan to upgrade your setup to Stateful Functions 3.0.0.
+We encourage you to download the release and share your feedback with the community through the [Flink mailing lists](https://flink.apache.org/community.html#mailing-lists)
+or [JIRA](https://issues.apache.org/jira/browse/)
+
+## List of Contributors
+
+The Apache Flink community would like to thank all contributors that have made this release possible:
+
+```
+Authuir, Chesnay Schepler, David Anderson, Dian Fu, Frans King, Galen Warren, Guillaume Vauvert, Igal Shilman, Ismaël Mejía, Kartik Khare, Konstantin Knauf, Marta Paes Moreira, Patrick Lucas, Patrick Wiener, Rafi Aroch, Robert Metzger, RocMarshal, Seth Wiesman, Siddique Ahmad, SteNicholas, Stephan Ewen, Timothy Bess, Tymur Yarosh, Tzu-Li (Gordon) Tai, Ufuk Celebi, abc863377, billyrrr, congxianqiu, danp11, hequn8128, kaibo, klion26, morsapaes, slinkydeveloper, wangchao, wangzzu, winder
+```
+
+If you’d like to get involved, we’re always [looking for new contributors](https://github.com/apache/flink-statefun#contributing).
diff --git a/docs/content.tr/posts/2021-04-29-release-1.12.3.md b/docs/content.tr/posts/2021-04-29-release-1.12.3.md
new file mode 100644
index 0000000000..467c8c1eea
--- /dev/null
+++ b/docs/content.tr/posts/2021-04-29-release-1.12.3.md
@@ -0,0 +1,199 @@
+---
+authors:
+- name: Arvid Heise
+ yuan: null
+date: "2021-04-29T00:00:00Z"
+title: Apache Flink 1.12.3 Released
+aliases:
+- /news/2021/04/29/release-1.12.3.html
+---
+
+The Apache Flink community released the next bugfix version of the Apache Flink 1.12 series.
+
+This release includes 73 fixes and minor improvements for Flink 1.12.2. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.12.3.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.12.3
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.12.3
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.12.3
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+
+List of resolved issues:
+
+ Bug
+
+
+[FLINK-18071 ] - CoordinatorEventsExactlyOnceITCase.checkListContainsSequence fails on CI
+
+[FLINK-20547 ] - Batch job fails due to the exception in network stack
+
+[FLINK-20654 ] - Unaligned checkpoint recovery may lead to corrupted data stream
+
+[FLINK-20722 ] - HiveTableSink should copy the record when converting RowData to Row
+
+[FLINK-20752 ] - FailureRateRestartBackoffTimeStrategy allows one less restart than configured
+
+[FLINK-20761 ] - Cannot read hive table/partition whose location path contains comma
+
+[FLINK-20977 ] - USE DATABASE & USE CATALOG fails with quoted identifiers containing characters to be escaped in Flink SQL client
+
+[FLINK-21008 ] - Residual HA related Kubernetes ConfigMaps and ZooKeeper nodes when cluster entrypoint received SIGTERM in shutdown
+
+[FLINK-21012 ] - AvroFileFormatFactory uses non-deserializable lambda function
+
+[FLINK-21133 ] - FLIP-27 Source does not work with synchronous savepoint
+
+[FLINK-21148 ] - YARNSessionFIFOSecuredITCase cannot connect to BlobServer
+
+[FLINK-21159 ] - KafkaSourceEnumerator not sending NoMoreSplitsEvent to unassigned reader
+
+[FLINK-21178 ] - Task failure will not trigger master hook's reset()
+
+[FLINK-21289 ] - Application mode ignores the pipeline.classpaths configuration
+
+[FLINK-21387 ] - DispatcherTest.testInvalidCallDuringInitialization times out on azp
+
+[FLINK-21388 ] - Parquet DECIMAL logical type is not properly supported in ParquetSchemaConverter
+
+[FLINK-21431 ] - UpsertKafkaTableITCase.testTemporalJoin hang
+
+[FLINK-21434 ] - When UDAF return ROW type, and the number of fields is more than 14, the crash happend
+
+[FLINK-21497 ] - JobLeaderIdService completes leader future despite no leader being elected
+
+[FLINK-21515 ] - SourceStreamTaskTest.testStopWithSavepointShouldNotInterruptTheSource is failing
+
+[FLINK-21518 ] - CheckpointCoordinatorTest.testMinCheckpointPause fails fatally on AZP
+
+[FLINK-21523 ] - ArrayIndexOutOfBoundsException occurs while run a hive streaming job with partitioned table source
+
+[FLINK-21535 ] - UnalignedCheckpointITCase.execute failed with "OutOfMemoryError: Java heap space"
+
+[FLINK-21550 ] - ZooKeeperHaServicesTest.testSimpleClose fail
+
+[FLINK-21552 ] - The managed memory was not released if exception was thrown in createPythonExecutionEnvironment
+
+[FLINK-21606 ] - TaskManager connected to invalid JobManager leading to TaskSubmissionException
+
+[FLINK-21609 ] - SimpleRecoveryITCaseBase.testRestartMultipleTimes fails on azure
+
+[FLINK-21654 ] - YARNSessionCapacitySchedulerITCase.testStartYarnSessionClusterInQaTeamQueue fail because of NullPointerException
+
+[FLINK-21661 ] - SHARD_GETRECORDS_INTERVAL_MILLIS wrong use?
+
+[FLINK-21685 ] - Flink JobManager failed to restart from checkpoint in kubernetes HA setup
+
+[FLINK-21691 ] - KafkaSource fails with NPE when setting it up
+
+[FLINK-21707 ] - Job is possible to hang when restarting a FINISHED task with POINTWISE BLOCKING consumers
+
+[FLINK-21710 ] - FlinkRelMdUniqueKeys gets incorrect result on TableScan after project push-down
+
+[FLINK-21725 ] - DataTypeExtractor extracts wrong fields ordering for Tuple12
+
+[FLINK-21733 ] - WatermarkAssigner incorrectly recomputing the rowtime index which may cause ArrayIndexOutOfBoundsException
+
+[FLINK-21746 ] - flink sql fields in row access error about scalarfunction
+
+[FLINK-21753 ] - Cycle references between memory manager and gc cleaner action
+
+[FLINK-21817 ] - New Kafka Source might break subtask and split assignment upon rescale
+
+[FLINK-21833 ] - TemporalRowTimeJoinOperator.java will lead to the state expansion by short-life-cycle & huge RowData, although config idle.state.retention.time
+
+[FLINK-21889 ] - source:canal-cdc , sink:upsert-kafka, print "select * from sinkTable", throw NullException
+
+[FLINK-21922 ] - The method partition_by in Over doesn't work for expression dsl
+
+[FLINK-21933 ] - [kinesis][efo] EFO consumer treats interrupts as retryable exceptions
+
+[FLINK-21941 ] - testSavepointRescalingOutPartitionedOperatorStateList fail
+
+[FLINK-21942 ] - KubernetesLeaderRetrievalDriver not closed after terminated which lead to connection leak
+
+[FLINK-21944 ] - AbstractArrowPythonAggregateFunctionOperator.dispose should consider whether arrowSerializer is null
+
+[FLINK-21969 ] - PythonTimestampsAndWatermarksOperator emitted the Long.MAX_VALUE watermark before emitting all the data
+
+[FLINK-21980 ] - ZooKeeperRunningJobsRegistry creates an empty znode
+
+[FLINK-21986 ] - taskmanager native memory not release timely after restart
+
+[FLINK-21992 ] - Fix availability notification in UnionInputGate
+
+[FLINK-21996 ] - Transient RPC failure without TaskManager failure can lead to split assignment loss
+
+[FLINK-22006 ] - Could not run more than 20 jobs in a native K8s session when K8s HA enabled
+
+[FLINK-22024 ] - Maven: Entry has not been leased from this pool / fix for release 1.12
+
+[FLINK-22053 ] - NumberSequenceSource causes fatal exception when less splits than parallelism.
+
+[FLINK-22055 ] - RPC main thread executor may schedule commands with wrong time unit of delay
+
+[FLINK-22061 ] - The DEFAULT_NON_SPLITTABLE_FILE_ENUMERATOR defined in FileSource should points to NonSplittingRecursiveEnumerator
+
+[FLINK-22081 ] - Entropy key not resolved if flink-s3-fs-hadoop is added as a plugin
+
+[FLINK-22082 ] - Nested projection push down doesn't work for data such as row(array(row))
+
+[FLINK-22124 ] - The job finished without any exception if error was thrown during state access
+
+[FLINK-22172 ] - Fix the bug of shared resource among Python Operators of the same slot is not released
+
+[FLINK-22184 ] - Rest client shutdown on failure runs in netty thread
+
+[FLINK-22191 ] - PyFlinkStreamUserDefinedFunctionTests.test_udf_in_join_condition_2 fail due to NPE
+
+[FLINK-22327 ] - NPE exception happens if it throws exception in finishBundle during job shutdown
+
+[FLINK-22339 ] - Fix some encoding exceptions were not thrown in cython coders
+
+[FLINK-22345 ] - CoordinatorEventsExactlyOnceITCase hangs on azure
+
+[FLINK-22385 ] - Type mismatch in NetworkBufferPool
+
+
+
+ Improvement
+
+
+[FLINK-20533 ] - Add histogram support to Datadog reporter
+
+[FLINK-21382 ] - Standalone K8s documentation does not explain usage of standby JobManagers
+
+[FLINK-21521 ] - Pretty print K8s specifications
+
+[FLINK-21690 ] - remove redundant tolerableCheckpointFailureNumber setting in CheckpointConfig
+
+[FLINK-21735 ] - Harden JobMaster#updateTaskExecutionState()
+
+[FLINK-22051 ] - Better document the distinction between stop-with-savepoint and stop-with-savepoint-with-drain
+
+[FLINK-22142 ] - Remove console logging for Kafka connector for AZP runs
+
+[FLINK-22208 ] - Bump snappy-java to 1.1.5+
+
+[FLINK-22297 ] - Perform early check to ensure that the length of the result is the same as the input for Pandas UDF
+
+
+
\ No newline at end of file
diff --git a/docs/content.tr/posts/2021-05-03-release-1.13.0.md b/docs/content.tr/posts/2021-05-03-release-1.13.0.md
new file mode 100644
index 0000000000..fb491e66cb
--- /dev/null
+++ b/docs/content.tr/posts/2021-05-03-release-1.13.0.md
@@ -0,0 +1,605 @@
+---
+authors:
+- name: Stephan Ewen
+ stephan: null
+ twitter: StephanEwen
+- dwysakowicz: null
+ name: Dawid Wysakowicz
+ twitter: dwysakowicz
+date: "2021-05-03T08:00:00Z"
+excerpt: The Apache Flink community is excited to announce the release of Flink 1.13.0!
+ Around 200 contributors worked on over 1,000 issues to bring significant improvements
+ to usability and observability as well as new features that improve the elasticity
+ of Flink's Application-style deployments.
+title: Apache Flink 1.13.0 Release Announcement
+aliases:
+- /news/2021/05/03/release-1.13.0.html
+---
+
+
+The Apache Flink community is excited to announce the release of Flink 1.13.0! More than 200
+contributors worked on over 1,000 issues for this new version.
+
+The release brings us a big step forward in one of our major efforts: **Making Stream Processing
+Applications as natural and as simple to manage as any other application.** The new *reactive scaling*
+mode means that scaling streaming applications in and out now works like in any other application
+by just changing the number of parallel processes.
+
+The release also prominently features a **series of improvements that help users better understand the performance of
+applications.** When the streams don't flow as fast as you'd hope, these can help you to understand
+why: Load and *backpressure visualization* to identify bottlenecks, *CPU flame graphs* to identify hot
+code paths in your application, and *State Access Latencies* to see how the State Backends are keeping
+up.
+
+Beyond those features, the Flink community has added a ton of improvements all over the system,
+some of which we discuss in this article. We hope you enjoy the new release and features.
+Towards the end of the article, we describe changes to be aware of when upgrading
+from earlier versions of Apache Flink.
+
+We encourage you to [download the release](https://flink.apache.org/downloads.html) and share your
+feedback with the community through
+the [Flink mailing lists](https://flink.apache.org/community.html#mailing-lists)
+or [JIRA](https://issues.apache.org/jira/projects/FLINK/summary).
+
+----
+
+# Notable features
+
+## Reactive scaling
+
+Reactive scaling is the latest piece in Flink's initiative to make Stream Processing
+Applications as natural and as simple to manage as any other application.
+
+Flink has a dual nature when it comes to resource management and deployments: You can deploy
+Flink applications onto resource orchestrators like Kubernetes or Yarn in such a way that Flink actively manages
+the resources and allocates and releases workers as needed. That is especially useful for jobs and
+applications that rapidly change their required resources, like batch applications and ad-hoc SQL
+queries. The application parallelism rules, the number of workers follows. In the context of Flink
+applications, we call this *active scaling*.
+
+For long-running streaming applications, it is often a nicer model to just deploy them like any
+other long-running application: The application doesn't really need to know that it runs on K8s,
+EKS, Yarn, etc. and doesn't try to acquire a specific amount of workers; instead, it just uses the
+number of workers that are given to it. The number of workers rules, the application parallelism
+adjusts to that. In the context of Flink, we call that *reactive scaling*.
+
+The [Application Deployment Mode]({{< param DocsBaseUrl >}}flink-docs-release-1.13/docs/concepts/flink-architecture/#flink-application-execution)
+started this effort, making deployments more application-like (by avoiding two separate deployment
+steps to (1) start a cluster and (2) submit an application). The reactive scaling mode completes this,
+and you now don't have to use extra tools (scripts, or a K8s operator) anymore to keep the number
+of workers, and the application parallelism settings in sync.
+
+You can now put an auto-scaler around Flink applications like around other typical applications — as
+long as you are mindful about the cost of rescaling when configuring the autoscaler: Stateful
+streaming applications must move state around when scaling.
+
+To try the reactive-scaling mode, add the `scheduler-mode: reactive` config entry and deploy
+an application cluster ([standalone]({{< param DocsBaseUrl >}}flink-docs-release-1.13/docs/deployment/resource-providers/standalone/overview/#application-mode) or [Kubernetes]({{< param DocsBaseUrl >}}flink-docs-release-1.13/docs/deployment/resource-providers/standalone/kubernetes/#deploy-application-cluster)). Check out [the reactive scaling docs]({{< param DocsBaseUrl >}}flink-docs-release-1.13/docs/deployment/elastic_scaling/#reactive-mode) for more details.
+
+
+## Analyzing application performance
+
+Like for any application, analyzing and understanding the performance of a Flink application
+is critical. Often even more critical, because Flink applications are typically data-intensive
+(processing high volumes of data) and are at the same time expected to provide results within
+(near-) real-time latencies.
+
+When an application doesn't keep up with the data rate anymore, or an application takes more
+resources than you'd expect it would, these new tools can help you track down the causes:
+
+**Bottleneck detection, Back Pressure monitoring**
+
+The first question during performance analysis is often: Which operation is the bottleneck?
+
+To help answer that, Flink exposes metrics about the degree to which tasks are *busy* (doing work)
+and *back-pressured* (have the capacity to do work but cannot because their successor operators
+cannot accept more results). Candidates for bottlenecks are the busy operators whose predecessors
+are back-pressured.
+
+Flink 1.13 brings an improved back pressure metric system (using task mailbox timings rather than
+thread stack sampling), and a reworked graphical representation of the job's dataflow with color-coding
+and ratios for busyness and backpressure.
+
+
+
+
+
+**CPU flame graphs in Web UI**
+
+The next question during performance analysis is typically: What part of work in the bottlenecked
+operator is expensive?
+
+One visually effective means to investigate that is *Flame Graphs*. They help answer question like:
+
+ - Which methods are currently consuming CPU resources?
+
+ - How does one method's CPU consumption compare to other methods?
+
+ - Which series of calls on the stack led to executing a particular method?
+
+Flame Graphs are constructed by repeatedly sampling the thread stack traces. Every method call is
+represented by a bar, where the length of the bar is proportional to the number of times it is present
+in the samples. When enabled, the graphs are shown in a new UI component for the selected operator.
+
+
+
+
+
+The [Flame Graphs documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.13/docs/ops/debugging/flame_graphs)
+contains more details and instructions for enabling this feature.
+
+**Access Latency Metrics for State**
+
+Another possible performance bottleneck can be the state backend, especially when your state is larger
+than the main memory available to Flink and you are using the [RocksDB state backend](
+{{< param DocsBaseUrl >}}flink-docs-release-1.13/docs/ops/state/state_backends/#the-embeddedrocksdbstatebackend).
+
+That's not saying RocksDB is slow (we love RocksDB!), but it has some requirements to achieve
+good performance. For example, it is easy to accidentally [starve RocksDB's demand for IOPs on cloud setups with
+the wrong type of disk resources](https://www.ververica.com/blog/the-impact-of-disks-on-rocksdb-state-backend-in-flink-a-case-study).
+
+On top of the CPU flame graphs, the new *state backend latency metrics* can help you understand whether
+your state backend is responsive. For example, if you see that RocksDB state accesses start to take
+milliseconds, you probably need to look into your memory and I/O configuration.
+These metrics can be activated by setting the `state.backend.rocksdb.latency-track-enabled` option.
+The metrics are sampled, and their collection should have a marginal impact on the RocksDB state
+backend performance.
+
+## Switching State Backend with savepoints
+
+You can now change the state backend of a Flink application when resuming from a savepoint.
+That means the application's state is no longer locked into the state backend that was used when
+the application was initially started.
+
+This makes it possible, for example, to initially start with the HashMap State Backend (pure
+in-memory in JVM Heap) and later switch to the RocksDB State Backend, once the state grows
+too large.
+
+Under the hood, Flink now has a canonical savepoint format, which all state backends use when
+creating a data snapshot for a savepoint.
+
+## User-specified pod templates for Kubernetes deployments
+
+The [native Kubernetes deployment]({{< param DocsBaseUrl >}}flink-docs-release-1.13/docs/deployment/resource-providers/native_kubernetes/)
+(where Flink actively talks to K8s to start and stop pods) now supports *custom pod templates*.
+
+With those templates, users can set up and configure the JobManagers and TaskManagers pods in a
+Kubernetes-y way, with flexibility beyond the configuration options that are directly built into
+Flink's Kubernetes integration.
+
+## Unaligned Checkpoints - production-ready
+
+Unaligned Checkpoints have matured to the point where we encourage all users to try them out,
+if they see issues with their application under backpressure.
+
+In particular, these changes make Unaligned Checkpoints easier to use:
+
+ - You can now rescale applications from unaligned checkpoints. This comes in handy if your
+ application needs to be scaled from a retained checkpoint because you cannot (afford to) create
+ a savepoint.
+
+ - Enabling unaligned checkpoints is cheaper for applications that are not back-pressured.
+ Unaligned checkpoints can now trigger adaptively with a timeout, meaning a checkpoint starts
+ as an aligned checkpoint (not storing any in-flight events) and falls back to an unaligned
+ checkpoint (storing some in-flight events), if the alignment phase takes longer than a certain
+ time.
+
+Find out more about how to enable unaligned checkpoints in the [Checkpointing Documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.13/docs/ops/state/checkpoints/#unaligned-checkpoints).
+
+## Machine Learning Library moving to a separate repository
+
+To accelerate the development of Flink's Machine Learning efforts (streaming, batch, and
+unified machine learning), the effort has moved to the new repository [flink-ml](https://github.com/apache/flink-ml)
+under the Flink project. We here follow a similar approach like the *Stateful Functions* effort,
+where a separate repository has helped to speed up the development by allowing for more light-weight
+contribution workflows and separate release cycles.
+
+Stay tuned for more updates in the Machine Learning efforts, like the interplay with
+[ALink](https://github.com/alibaba/Alink) (suite of many common Machine Learning Algorithms on Flink)
+or the [Flink & TensorFlow integration](https://github.com/alibaba/flink-ai-extended).
+
+
+# Notable SQL & Table API improvements
+
+Like in previous releases, SQL and the Table API remain an area of big developments.
+
+## Windows via Table-valued functions
+
+Defining time windows is one of the most frequent operations in streaming SQL queries.
+Flink 1.13 introduces a new way to define windows: via *Table-valued Functions*.
+This approach is both more expressive (lets you define new types of windows) and fully
+in line with the SQL standard.
+
+Flink 1.13 supports *TUMBLE* and *HOP* windows in the new syntax, *SESSION* windows will
+follow in a subsequent release. To demonstrate the increased expressiveness, consider the two examples
+below.
+
+A new *CUMULATE* window function that assigns windows with an expanding step size until the maximum
+window size is reached:
+
+```sql
+SELECT window_time, window_start, window_end, SUM(price) AS total_price
+ FROM TABLE(CUMULATE(TABLE Bid, DESCRIPTOR(bidtime), INTERVAL '2' MINUTES, INTERVAL '10' MINUTES))
+GROUP BY window_start, window_end, window_time;
+```
+
+You can reference the window start and window end time of the table-valued window functions,
+making new types of constructs possible. Beyond regular windowed aggregations and windowed joins,
+you can, for example, now express windowed Top-K aggregations:
+
+```sql
+SELECT window_time, ...
+ FROM (
+ SELECT *, ROW_NUMBER() OVER (PARTITION BY window_start, window_end ORDER BY total_price DESC)
+ as rank
+ FROM t
+ ) WHERE rank <= 100;
+```
+
+## Improved interoperability between DataStream API and Table API/SQL
+
+This release radically simplifies mixing DataStream API and Table API programs.
+
+The Table API is a great way to develop applications, with its declarative nature and its
+many built-in functions. But sometimes, you need to *escape* to the DataStream API for its
+expressiveness, flexibility, and explicit control over the state.
+
+The new methods `StreamTableEnvironment.toDataStream()/.fromDataStream()` can model
+a `DataStream` from the DataStream API as a table source or sink.
+Notable improvements include:
+
+- Automatic type conversion between the DataStream and Table API type systems.
+
+- Seamless integration of event time configurations; watermarks flow through boundaries for high
+ consistency.
+
+- Enhancements to the `Row` class (representing row events from the Table API) has received a major
+ overhaul (improving the behavior of `toString()`/`hashCode()`/`equals()` methods) and now supports
+ accessing fields by name, with support for sparse representations.
+
+```java
+Table table = tableEnv.fromDataStream(
+ dataStream,
+ Schema.newBuilder()
+ .columnByMetadata("rowtime", "TIMESTAMP(3)")
+ .watermark("rowtime", "SOURCE_WATERMARK()")
+ .build());
+
+DataStream dataStream = tableEnv.toDataStream(table)
+ .keyBy(r -> r.getField("user"))
+ .window(...);
+```
+
+## SQL Client: Init scripts and Statement Sets
+
+The SQL Client is a convenient way to run and deploy SQL streaming and batch jobs directly,
+without writing any code from the command line, or as part of a CI/CD workflow.
+
+This release vastly improves the functionality of the SQL client. Almost all operations as that
+are available to Java applications (when programmatically launching queries from the
+`TableEnvironment`) are now supported in the SQL Client and as SQL scripts.
+That means SQL users need much less glue code for their SQL deployments.
+
+**Easier Configuration and Code Sharing**
+
+The support of YAML files to configure the SQL Client will be discontinued. Instead, the client
+accepts one or more *initialization scripts* to configure a session before the main SQL script
+gets executed.
+
+These init scripts would typically be shared across teams/deployments and could be used for
+loading common catalogs, applying common configuration settings, or defining standard views.
+
+```
+./sql-client.sh -i init1.sql init2.sql -f sqljob.sql
+```
+
+**More config options**
+
+A greater set of recognized config options and improved `SET`/`RESET` commands make it easier to
+define and control the execution from within the SQL client and SQL scripts.
+
+**Multi-query Support with Statement Sets**
+
+Multi-query execution lets you execute multiple SQL queries (or statements) as a single Flink job.
+This is particularly useful for streaming SQL queries that run indefinitely.
+
+*Statement Sets* are the mechanism to group the queries together that should be executed together.
+
+The following is an example of a SQL script that can be run via the SQL client. It sets up and
+configures the environment and executes multiple queries. The script captures end-to-end the
+queries and all environment setup and configuration work, making it a self-contained deployment
+artifact.
+
+```sql
+-- set up a catalog
+CREATE CATALOG hive_catalog WITH ('type' = 'hive');
+USE CATALOG hive_catalog;
+
+-- or use temporary objects
+CREATE TEMPORARY TABLE clicks (
+ user_id BIGINT,
+ page_id BIGINT,
+ viewtime TIMESTAMP
+) WITH (
+ 'connector' = 'kafka',
+ 'topic' = 'clicks',
+ 'properties.bootstrap.servers' = '...',
+ 'format' = 'avro'
+);
+
+-- set the execution mode for jobs
+SET execution.runtime-mode=streaming;
+
+-- set the sync/async mode for INSERT INTOs
+SET table.dml-sync=false;
+
+-- set the job's parallelism
+SET parallism.default=10;
+
+-- set the job name
+SET pipeline.name = my_flink_job;
+
+-- restore state from the specific savepoint path
+SET execution.savepoint.path=/tmp/flink-savepoints/savepoint-bb0dab;
+
+BEGIN STATEMENT SET;
+
+INSERT INTO pageview_pv_sink
+SELECT page_id, count(1) FROM clicks GROUP BY page_id;
+
+INSERT INTO pageview_uv_sink
+SELECT page_id, count(distinct user_id) FROM clicks GROUP BY page_id;
+
+END;
+```
+
+## Hive query syntax compatibility
+
+You can now write SQL queries against Flink using the Hive SQL syntax.
+In addition to Hive's DDL dialect, Flink now also accepts the commonly-used Hive DML and DQL
+dialects.
+
+To use the Hive SQL dialect, set `table.sql-dialect` to `hive` and load the `HiveModule`.
+The latter is important because Hive's built-in functions are required for proper syntax and
+semantics compatibility. The following example illustrates that:
+
+```sql
+CREATE CATALOG myhive WITH ('type' = 'hive'); -- setup HiveCatalog
+USE CATALOG myhive;
+LOAD MODULE hive; -- setup HiveModule
+USE MODULES hive,core;
+SET table.sql-dialect = hive; -- enable Hive dialect
+SELECT key, value FROM src CLUSTER BY key; -- run some Hive queries
+```
+
+Please note that the Hive dialect no longer supports Flink's SQL syntax for DML and DQL statements.
+Switch back to the `default` dialect for Flink's syntax.
+
+## Improved behavior of SQL time functions
+
+Working with time is a crucial element of any data processing. But simultaneously, handling different
+time zones, dates, and times is an [increadibly delicate task](https://xkcd.com/1883/) when working with data.
+
+In Flink 1.13. we put much effort into simplifying the usage of time-related functions. We adjusted (made
+more specific) the return types of functions such as: `PROCTIME()`, `CURRENT_TIMESTAMP`, `NOW()`.
+
+Moreover, you can now also define an event time attribute on a *TIMESTAMP_LTZ* column to gracefully
+do window processing with the support of Daylight Saving Time.
+
+Please see the release notes for a complete list of changes.
+
+---
+
+# Notable PyFlink improvements
+
+The general theme of this release in PyFlink is to bring the Python DataStream API and Table API
+closer to feature parity with the Java/Scala APIs.
+
+### Stateful operations in the Python DataStream API
+
+With Flink 1.13, Python programmers now also get to enjoy the full potential of Apache Flink's
+stateful stream processing APIs. The rearchitected Python DataStream API, introduced in Flink 1.12,
+now has full stateful capabilities, allowing users to remember information from events in the state
+and act on it later.
+
+That stateful processing capability is the basis of many of the more sophisticated processing
+operations, which need to remember information across individual events (for example, Windowing
+Operations).
+
+This example shows a custom counting window implementation, using state:
+
+```python
+class CountWindowAverage(FlatMapFunction):
+ def __init__(self, window_size):
+ self.window_size = window_size
+
+ def open(self, runtime_context: RuntimeContext):
+ descriptor = ValueStateDescriptor("average", Types.TUPLE([Types.LONG(), Types.LONG()]))
+ self.sum = runtime_context.get_state(descriptor)
+
+ def flat_map(self, value):
+ current_sum = self.sum.value()
+ if current_sum is None:
+ current_sum = (0, 0)
+ # update the count
+ current_sum = (current_sum[0] + 1, current_sum[1] + value[1])
+ # if the count reaches window_size, emit the average and clear the state
+ if current_sum[0] >= self.window_size:
+ self.sum.clear()
+ yield value[0], current_sum[1] // current_sum[0]
+ else:
+ self.sum.update(current_sum)
+
+ds = ... # type: DataStream
+ds.key_by(lambda row: row[0]) \
+ .flat_map(CountWindowAverage(5))
+```
+
+### User-defined Windows in the PyFlink DataStream API
+
+Flink 1.13 adds support for user-defined windows to the PyFlink DataStream API. Programs can now use
+windows beyond the standard window definitions.
+
+Because windows are at the heart of all programs that process unbounded streams (by splitting the
+stream into "buckets" of bounded size), this greatly increases the expressiveness of the API.
+
+### Row-based operation in the PyFlink Table API
+
+The Python Table API now supports row-based operations, i.e., custom transformation functions on rows.
+These functions are an easy way to apply data transformations on tables beyond the built-in functions.
+
+This is an example of using a `map()` operation in Python Table API:
+
+```python
+@udf(result_type=DataTypes.ROW(
+ [DataTypes.FIELD("c1", DataTypes.BIGINT()),
+ DataTypes.FIELD("c2", DataTypes.STRING())]))
+def increment_column(r: Row) -> Row:
+ return Row(r[0] + 1, r[1])
+
+table = ... # type: Table
+mapped_result = table.map(increment_column)
+```
+
+In addition to `map()`, the API also supports `flat_map()`, `aggregate()`, `flat_aggregate()`,
+and other row-based operations. This brings the Python Table API a big step closer to feature
+parity with the Java Table API.
+
+### Batch execution mode for PyFlink DataStream programs
+
+The PyFlink DataStream API now also supports the batch execution mode for bounded streams,
+which was introduced for the Java DataStream API in Flink 1.12.
+
+The batch execution mode simplifies operations and improves the performance of programs on bounded streams,
+by exploiting the bounded stream nature to bypass state backends and checkpoints.
+
+# Other improvements
+
+**Flink Documentation via Hugo**
+
+The Flink Documentation has been migrated from Jekyll to Hugo. If you find something missing, please let us know.
+We are also curious to hear if you like the new look & feel.
+
+**Exception histories in the Web UI**
+
+The Flink Web UI will present up to *n* last exceptions that caused a job to fail.
+That helps to debug scenarios where a root failure caused subsequent failures. The root failure
+cause can be found in the exception history.
+
+**Better exception / failure-cause reporting for unsuccessful checkpoints**
+
+Flink now provides statistics for checkpoints that failed or were aborted to make it easier
+to determine the failure cause without having to analyze the logs.
+
+Prior versions of Flink were reporting metrics (e.g., size of persisted data, trigger time)
+only in case a checkpoint succeeded.
+
+**Exactly-once JDBC sink**
+
+From 1.13, JDBC sink can guarantee exactly-once delivery of results for XA-compliant databases
+by transactionally committing results on checkpoints. The target database must have (or be linked
+to) an XA Transaction Manager.
+
+The connector exists currently only for the *DataStream API*, and can be created through the
+`JdbcSink.exactlyOnceSink(...)` method (or by instantiating the `JdbcXaSinkFunction` directly).
+
+**PyFlink Table API supports User-Defined Aggregate Functions in Group Windows**
+
+Group Windows in PyFlink's Table API now support both general Python User-defined Aggregate
+Functions (UDAFs) and Pandas UDAFs. Such functions are critical to many analysis- and ML training
+programs.
+
+Flink 1.13 improves upon previous releases, where these functions were only supported
+in unbounded Group-by aggregations.
+
+**Improved Sort-Merge Shuffle for Batch Execution**
+
+Flink 1.13 improves the memory stability and performance of the *sort-merge blocking shuffle*
+for batch-executed programs, initially introduced in Flink 1.12 via [FLIP-148](https://cwiki.apache.org/confluence/display/FLINK/FLIP-148%3A+Introduce+Sort-Merge+Based+Blocking+Shuffle+to+Flink).
+
+Programs with higher parallelism (1000s) should no longer frequently trigger *OutOfMemoryError: Direct Memory*.
+The performance (especially on spinning disks) is improved through better I/O scheduling
+and broadcast optimizations.
+
+**HBase connector supports async lookup and lookup cache**
+
+The HBase Lookup Table Source now supports an *async lookup mode* and a lookup cache.
+This greatly benefits the performance of Table/SQL jobs with lookup joins against HBase, while
+reducing the I/O requests to HBase in the typical case.
+
+In prior versions, the HBase Lookup Source only communicated synchronously, resulting in lower
+pipeline utilization and throughput.
+
+# Changes to consider when upgrading to Flink 1.13
+
+* [FLINK-21709](https://issues.apache.org/jira/browse/FLINK-21709) - The old planner of the Table &
+ SQL API has been deprecated in Flink 1.13 and will be dropped in Flink 1.14.
+ The *Blink* engine has been the default planner for some releases now and will be the only one going forward.
+ That means that both the `BatchTableEnvironment` and SQL/DataSet interoperability are reaching
+ the end of life. Please use the unified `TableEnvironment` for batch and stream processing going forward.
+* [FLINK-22352](https://issues.apache.org/jira/browse/FLINK-22352) The community decided to deprecate
+ the Apache Mesos support for Apache Flink. It is subject to removal in the future. Users are
+ encouraged to switch to a different resource manager.
+* [FLINK-21935](https://issues.apache.org/jira/browse/FLINK-21935) - The `state.backend.async`
+ option is deprecated. Snapshots are always asynchronous now (as they were by default before) and
+ there is no option to configure a synchronous snapshot anymore.
+* [FLINK-17012](https://issues.apache.org/jira/browse/FLINK-17012) - The tasks' `RUNNING` state was split
+ into two states: `INITIALIZING` and `RUNNING`. A task is `INITIALIZING` while it loads the checkpointed state,
+ and, in the case of unaligned checkpoints, until the checkpointed in-flight data has been recovered.
+ This lets monitoring systems better determine when the tasks are really back to doing work by making
+ the phase for state restoring explicit.
+* [FLINK-21698](https://issues.apache.org/jira/browse/FLINK-21698) - The *CAST* operation between the
+ NUMERIC type and the TIMESTAMP type is problematic and therefore no longer supported: Statements like
+ `CAST(numeric AS TIMESTAMP(3))` will now fail. Please use `TO_TIMESTAMP(FROM_UNIXTIME(numeric))` instead.
+* [FLINK-22133](https://issues.apache.org/jira/browse/FLINK-22133) The unified source API for connectors
+ has a minor breaking change: The `SplitEnumerator.snapshotState()` method was adjusted to accept the
+ *Checkpoint ID* of the checkpoint for which the snapshot is created.
+* [FLINK-19463](https://issues.apache.org/jira/browse/FLINK-19463) - The old `StateBackend` interfaces were deprecated
+ as they had overloaded semantics which many users found confusing. This is a pure API change and does not affect
+ runtime characteristics of applications.
+ For full details on how to update existing pipelines, please see the [migration guide]({{< param DocsBaseUrl >}}flink-docs-release-1.13/docs/ops/state/state_backends/#migrating-from-legacy-backends).
+
+# Resources
+
+The binary distribution and source artifacts are now available on the updated [Downloads page](/downloads.html)
+of the Flink website, and the most recent distribution of PyFlink is available on [PyPI](https://pypi.org/project/apache-flink/).
+
+Please review the [release notes]({{< param DocsBaseUrl >}}flink-docs-release-1.13/release-notes/flink-1.13)
+carefully if you plan to upgrade your setup to Flink 1.13. This version is API-compatible with
+previous 1.x releases for APIs annotated with the `@Public` annotation.
+
+You can also check the complete [release changelog](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12349287)
+and [updated documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.13/) for a detailed list of changes and new features.
+
+# List of Contributors
+
+The Apache Flink community would like to thank each one of the contributors that have
+made this release possible:
+
+acqua.csq, AkisAya, Alexander Fedulov, Aljoscha Krettek, Ammar Al-Batool, Andrey Zagrebin, anlen321,
+Anton Kalashnikov, appleyuchi, Arvid Heise, Austin Cawley-Edwards, austin ce, azagrebin, blublinsky,
+Brian Zhou, bytesmithing, caozhen1937, chen qin, Chesnay Schepler, Congxian Qiu, Cristian,
+cxiiiiiii, Danny Chan, Danny Cranmer, David Anderson, Dawid Wysakowicz, dbgp2021, Dian Fu,
+DinoZhang, dixingxing, Dong Lin, Dylan Forciea, est08zw, Etienne Chauchot, fanrui03, Flora Tao,
+FLRNKS, fornaix, fuyli, George, Giacomo Gamba, GitHub, godfrey he, GuoWei Ma, Gyula Fora,
+hackergin, hameizi, Haoyuan Ge, Harshvardhan Chauhan, Haseeb Asif, hehuiyuan, huangxiao, HuangXiao,
+huangxingbo, HuangXingBo, humengyu2012, huzekang, Hwanju Kim, Ingo Bürk, I. Raleigh, Ivan, iyupeng,
+Jack, Jane, Jark Wu, Jerry Wang, Jiangjie (Becket) Qin, JiangXin, Jiayi Liao, JieFang.He, Jie Wang,
+jinfeng, Jingsong Lee, JingsongLi, Jing Zhang, Joao Boto, JohnTeslaa, Jun Qin, kanata163, kevin.cyj,
+KevinyhZou, Kezhu Wang, klion26, Kostas Kloudas, kougazhang, Kurt Young, laughing, legendtkl,
+leiqiang, Leonard Xu, liaojiayi, Lijie Wang, liming.1018, lincoln lee, lincoln-lil, liushouwei,
+liuyufei, LM Kang, lometheus, luyb, Lyn Zhang, Maciej Obuchowski, Maciek Próchniak, mans2singh,
+Marek Sabo, Matthias Pohl, meijie, Mika Naylor, Miklos Gergely, Mohit Paliwal, Moritz Manner,
+morsapaes, Mulan, Nico Kruber, openopen2, paul8263, Paul Lam, Peidian li, pengkangjing, Peter Huang,
+Piotr Nowojski, Qinghui Xu, Qingsheng Ren, Raghav Kumar Gautam, Rainie Li, Ricky Burnett, Rion
+Williams, Robert Metzger, Roc Marshal, Roman, Roman Khachatryan, Ruguo,
+Ruguo Yu, Rui Li, Sebastian Liu, Seth Wiesman, sharkdtu, sharkdtu(涂小刚), Shengkai, shizhengchao,
+shouweikun, Shuo Cheng, simenliuxing, SteNicholas, Stephan Ewen, Suo Lu, sv3ndk, Svend Vanderveken,
+taox, Terry Wang, Thelgis Kotsos, Thesharing, Thomas Weise, Till Rohrmann, Timo Walther, Ting Sun,
+totoro, totorooo, TsReaper, Tzu-Li (Gordon) Tai, V1ncentzzZ, vthinkxie, wangfeifan, wangpeibin,
+wangyang0918, wangyemao-github, Wei Zhong, Wenlong Lyu, wineandcheeze, wjc, xiaoHoly, Xintong Song,
+xixingya, xmarker, Xue Wang, Yadong Xie, yangsanity, Yangze Guo, Yao Zhang, Yuan Mei, yulei0824, Yu
+Li, Yun Gao, Yun Tang, yuruguo, yushujun, Yuval Itzchakov, yuzhao.cyz, zck, zhangjunfan,
+zhangzhengqi3, zhao_wei_nan, zhaown, zhaoxing, Zhenghua Gao, Zhenqiu Huang, zhisheng, zhongqishang,
+zhushang, zhuxiaoshang, Zhu Zhu, zjuwangg, zoucao, zoudan, 左元, 星, 肖佳文, 龙三
+
diff --git a/docs/content.tr/posts/2021-05-06-reactive-mode.md b/docs/content.tr/posts/2021-05-06-reactive-mode.md
new file mode 100644
index 0000000000..b484fc5c18
--- /dev/null
+++ b/docs/content.tr/posts/2021-05-06-reactive-mode.md
@@ -0,0 +1,150 @@
+---
+authors:
+- name: Robert Metzger
+ rob: null
+ twitter: rmetzger_
+date: "2021-05-06T00:00:00Z"
+excerpt: Apache Flink 1.13 introduced Reactive Mode, a big step forward in Flink's
+ ability to dynamically adjust to changing workloads, reducing resource utilization
+ and overall costs. This blog post showcases how to use this new feature on Kubernetes,
+ including some lessons learned.
+title: Scaling Flink automatically with Reactive Mode
+aliases:
+- /2021/05/06/reactive-mode.html
+---
+
+## Introduction
+
+Streaming jobs which run for several days or longer usually experience variations in workload during their lifetime. These variations can originate from seasonal spikes, such as day vs. night, weekdays vs. weekend or holidays vs. non-holidays, sudden events or simply the growing popularity of your product. Although some of these variations are more predictable than others, in all cases there is a change in job resource demand that needs to be addressed if you want to ensure the same quality of service for your customers.
+
+A simple way of quantifying the mismatch between the required resources and the available resources is to measure the space between the actual load and the number of available workers. As pictured below, in the case of static resource allocation, you can see that there's a big gap between the actual load and the available workers — hence, we are wasting resources. For elastic resource allocation, the gap between the red and black line is consistently small.
+
+
+
+
+
+**Manually rescaling** a Flink job has been possible since Flink 1.2 introduced [rescalable state](https://flink.apache.org/features/2017/07/04/flink-rescalable-state.html), which allows you to stop-and-restore a job with a different parallelism. For example, if your job is running with a parallelism of p=100 and your load increases, you can restart it with p=200 to cope with the additional data.
+
+The problem with this approach is that you have to orchestrate a rescale operation with custom tools by yourself, including error handling and similar tasks.
+
+[Reactive Mode]({{< param DocsBaseUrl >}}flink-docs-master/docs/deployment/elastic_scaling/) introduces a new option in Flink 1.13: You monitor your Flink cluster and add or remove resources depending on some metrics, Flink will do the rest. Reactive Mode is a mode where JobManager will try to use all TaskManager resources available.
+
+The big benefit of Reactive Mode is that you don't need any specific knowledge to scale Flink anymore. Flink basically behaves like a fleet of servers (e.g. webservers, caches, batch processing) that you can expand or shrink as you wish. Since this is such a common pattern, there is a lot of infrastructure available for handling such cases: all major cloud providers offer utilities to monitor specific metrics and automatically scale a set of machines accordingly. For example, this would be provided through [Auto Scaling groups](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html) in AWS, and [Managed Instance groups](https://cloud.google.com/compute/docs/instance-groups) in Google Cloud.
+Similarly, Kubernetes provides [Horizontal Pod Autoscalers](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/).
+
+What is interesting, as a side note, is that unlike most auto scalable "fleets of servers", Flink is a stateful system, often processing valuable data requiring strong correctness guarantees (comparable to a database). But, unlike many traditional databases, Flink is resilient enough (through checkpointing and state backups) to adjust to changing workloads by just adding or removing resources, with very little requirements (i.e. simple blob store for state backups).
+
+## Getting Started
+
+If you want to try out Reactive Mode yourself locally, follow these steps using a Flink 1.13.0 distribution:
+
+```bash
+# These instructions assume you are in the root directory of a Flink distribution.
+# Put Job into usrlib/ directory
+mkdir usrlib
+cp ./examples/streaming/TopSpeedWindowing.jar usrlib/
+# Submit Job in Reactive Mode
+./bin/standalone-job.sh start -Dscheduler-mode=reactive -Dexecution.checkpointing.interval="10s" -j org.apache.flink.streaming.examples.windowing.TopSpeedWindowing
+# Start first TaskManager
+./bin/taskmanager.sh start
+```
+
+You have now started a Flink job in Reactive Mode. The [web interface](http://localhost:8081) shows that the job is running on one TaskManager. If you want to scale up the job, simply add another TaskManager to the cluster:
+
+```bash
+# Start additional TaskManager
+./bin/taskmanager.sh start
+```
+
+To scale down, remove a TaskManager instance:
+
+```bash
+# Remove a TaskManager
+./bin/taskmanager.sh stop
+```
+
+Reactive Mode also works when deploying [Flink on Docker]({{< param DocsBaseUrl >}}flink-docs-master/docs/deployment/resource-providers/standalone/docker/) or using the [standalone Kubernetes deployment]({{< param DocsBaseUrl >}}flink-docs-master/docs/deployment/resource-providers/standalone/kubernetes/) (both only as application clusters).
+
+## Demo on Kubernetes
+
+In this section, we want to demonstrate the new Reactive Mode in a real-world scenario. You can use this demo as a starting point for your own scalable deployment of Flink on Kubernetes, or as a template for building your own deployment using a different setup.
+
+### The Setup
+
+The central idea of this demo is to use a Kubernetes [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/), which monitors the CPU load of all TaskManager pods and adjusts their replication factor accordingly. On high CPU load, the autoscaler should add more TaskManagers, distributing the load across more machines. On low load, it should stop TaskManagers to save resources.
+
+The whole setup is presented here:
+
+
+
+
+
+Let's discuss the components:
+
+**Flink**
+
+- The **JobManager** is deployed as a [Kubernetes job](https://kubernetes.io/docs/concepts/workloads/controllers/job/). We are submitting a container that is based on the official Flink Docker image, but has the jar file of our job added to it. The Flink job simply reads data from a Kafka topic and does some expensive math operations per event received. We use these math operations to generate high CPU loads, without requiring a large Kafka deployment.
+- The **TaskManager(s)** are deployed as a Kubernetes deployment, which is scaled through a [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). In this experiment, the autoscaler is monitoring the CPU load of the pods in the deployment. The number of pods is adjusted between 1 and 15 pods by the autoscaler.
+
+**Additional Components**:
+
+- We have a **Zookeeper** and **Kafka** deployment (each with one pod) to provide a Kafka topic that serves as the input for the Flink job.
+- The **Data Generator** pod produces simple string messages at a adjustable rate to the Kafka topic. In this experiment, the rate is following a sine wave.
+- For monitoring, we are deploying **Prometheus** and **Grafana**.
+
+The entire setup is [available on GitHub](https://github.com/rmetzger/flink-reactive-mode-k8s-demo) if you want to try this out yourself.
+
+### Results
+
+We've deployed all the above components on a hosted Kubernetes cluster, running it for several days. The results are best examined based on the following Grafana dashboard:
+
+
+
+
Reactive Mode Experiment Results
+
+
+Let's take a closer look at the dashboard:
+
+- On the top left, you can see the **Kafka consumer lag**, reported by Flink's Kafka consumer (source), which reports the queue size of unprocessed messages. A high lag means that Flink is not processing messages as fast as they are produced: we need to scale up.
+
+ The lag is usually following the throughput of data coming from Kafka. When the throughput is the highest, the reported lag is at \~75k messages. In low throughput times, it is basically at zero.
+
+- On the top right, you'll see the **throughput**, measured in records per second, as reported by Flink. The throughput is roughly following a sine wave, peaking at 6k messages per second, and going down to almost zero.
+
+- The bottom left chart shows the **CPU load** per TaskManager. We've added this metric to the dashboard because this is what the pod autoscaler in Kubernetes will use to decide on the replica count of the TaskManager deployment. You can see that, as soon as a certain CPU load is reached, additional TaskManagers are started.
+
+- In the bottom right chart, you can see the **TaskManager count** over time. When the throughput (and CPU load) is peaking, we're running on 5 TaskManagers (with some peaks up to even 8). On low throughput, we're running the minimal number of just one TaskManager. This chart showcases nicely that Reactive Mode is working as expected in this experiment: the number of TaskManagers is adjusting to the load on the system.
+
+
+### Lessons Learned: Configuring a low heartbeat timeout for a smooth scale down
+
+When we initially started with the experiment, we noticed some anomalies in the behavior of Flink, depicted in this chart:
+
+
+
+
Reactive Mode not scaling down properly
+
+
+In all the charts, we see sudden spikes or drops: The consumer lag is going to up to 600k messages (that's 8 times more than the usual 75k lag we observe at peak), the throughput seems to peak (and drop). On the "Number of TaskManagers" chart, we see that we are not following the throughput line very nicely. We are wasting resources by allocating too many TaskManagers for the given at rate.
+
+We see that these issues are only occurring when the load is decreasing, and Reactive Mode is supposed to scale down. So what is happening here?
+
+The Flink JobManager is sending periodic heartbeats to the TaskManagers, to check if they are still alive. These heartbeats have a default timeout of 50 seconds. This value might seem high, but in high load scenarios, there might be network congestions, garbage collection pauses or other disruptions that cause slow heartbeats. We don't want to consider a TaskManager dead just because of a temporary disruption.
+
+However, this default value is causing problems in this experiment: When the Kubernetes autoscaler notices that the CPU load has gone down, it will reduce the replica count of the TaskManager deployment, stopping at least one TaskManager instance. Flink will almost immediately stop processing messages, because of the connection loss in the data transport layer of Flink. However, the JobManager will wait for 50 seconds (the default heartbeat timeout) before the TaskManager is considered dead.
+
+During this waiting period, the throughput is at zero and messages are queuing in Kafka (causing spikes in the consumer lag). Once Flink is running again, Flink will try to catch up on the queued messages, causing a spike in CPU load. The autoscaler notices this load spike and allocates more TaskManagers.
+
+We are only seeing this effect on scale down, because a scale down is much more disruptive than scaling up. Scale up, which means adding TaskManagers, is disrupting the processing only for the duration of a job restart (which is fast since our application state are just a few bytes for the Kafka offsets), while scaling down is disrupting the processing for roughly 50 seconds.
+
+To mitigate this issue, we have reduced the `heartbeat.timeout` in our experiment to 8 seconds. Additionally, we are looking into improving the behavior of the JobManager to detect TaskManager losses better and faster.
+
+
+## Conclusion
+
+In this blog post, we've introduced Reactive Mode, a big step forward in Flink's ability to dynamically adjust to changing workloads, reducing resource utilization and overall costs. The blog post demonstrated Reactive Mode on Kubernetes, including some lessons learned.
+
+Reactive Mode is new feature in Flink 1.13 and is currently in the [MVP (Minimal Viable Product) phase](https://flink.apache.org/roadmap.html#feature-stages) of product development. Before experimenting with it, or using it in production, please check the [documentation]({{< param DocsBaseUrl >}}flink-docs-master/docs/deployment/elastic_scaling), in particular the current [limitations]({{< param DocsBaseUrl >}}flink-docs-master/docs/deployment/elastic_scaling/#limitations) section. In this phase, the biggest limitation is that only standalone application mode deployments are supported (i.e. no active resource managers or session clusters).
+
+The community is actively looking for feedback on this feature, to continue improving Flink's resource elasticity. If you have any feedback, please reach out to the [dev@ mailing list](https://flink.apache.org/community.html#mailing-lists) or to me personally on [Twitter](https://twitter.com/rmetzger_).
+
diff --git a/docs/content.tr/posts/2021-05-21-release-1.12.4.md b/docs/content.tr/posts/2021-05-21-release-1.12.4.md
new file mode 100644
index 0000000000..44edc7528b
--- /dev/null
+++ b/docs/content.tr/posts/2021-05-21-release-1.12.4.md
@@ -0,0 +1,93 @@
+---
+authors:
+- arvid: null
+ name: Arvid Heise
+date: "2021-05-21T00:00:00Z"
+title: Apache Flink 1.12.4 Released
+aliases:
+- /news/2021/05/21/release-1.12.4.html
+---
+
+The Apache Flink community released the next bugfix version of the Apache Flink 1.12 series.
+
+This release includes 21 fixes and minor improvements for Flink 1.12.3. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.12.4.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.12.4
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.12.4
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.12.4
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+
+Release Notes - Flink - Version 1.12.4
+
+ Bug
+
+
+[FLINK-17170 ] - Cannot stop streaming job with savepoint which uses kinesis consumer
+
+[FLINK-20114 ] - Fix a few KafkaSource-related bugs
+
+[FLINK-21181 ] - Buffer pool is destroyed error when outputting data over a timer after cancellation.
+
+[FLINK-22109 ] - Misleading exception message if the number of arguments of a nested function is incorrect
+
+[FLINK-22368 ] - UnalignedCheckpointITCase hangs on azure
+
+[FLINK-22424 ] - Writing to already released buffers potentially causing data corruption during job failover/cancellation
+
+[FLINK-22438 ] - add numRecordsOut metric for Async IO
+
+[FLINK-22442 ] - Using scala api to change the TimeCharacteristic of the PatternStream is invalid
+
+[FLINK-22479 ] - [Kinesis][Consumer] Potential lock-up under error condition
+
+[FLINK-22489 ] - subtask backpressure indicator shows value for entire job
+
+[FLINK-22555 ] - LGPL-2.1 files in flink-python jars
+
+[FLINK-22557 ] - Japicmp fails on 1.12 branch
+
+[FLINK-22573 ] - AsyncIO can timeout elements after completion
+
+[FLINK-22577 ] - KubernetesLeaderElectionAndRetrievalITCase is failing
+
+[FLINK-22597 ] - JobMaster cannot be restarted
+
+
+
+ Improvement
+
+
+[FLINK-18952 ] - Add 10 minutes to DataStream API documentation
+
+[FLINK-20553 ] - Add end-to-end test case for new Kafka source
+
+[FLINK-22470 ] - The root cause of the exception encountered during compiling the job was not exposed to users in certain cases
+
+[FLINK-22539 ] - Restructure the Python dependency management documentation
+
+[FLINK-22544 ] - Add the missing documentation about the command line options for PyFlink
+
+[FLINK-22560 ] - Filter maven metadata from all jars
+
+
+
\ No newline at end of file
diff --git a/docs/content.tr/posts/2021-05-28-release-1.13.1.md b/docs/content.tr/posts/2021-05-28-release-1.13.1.md
new file mode 100644
index 0000000000..c4b10a3d3e
--- /dev/null
+++ b/docs/content.tr/posts/2021-05-28-release-1.13.1.md
@@ -0,0 +1,162 @@
+---
+authors:
+- dwysakowicz: null
+ name: Dawid Wysakowicz
+ twitter: dwysakowicz
+date: "2021-05-28T00:00:00Z"
+title: Apache Flink 1.13.1 Released
+aliases:
+- /news/2021/05/28/release-1.13.1.html
+---
+
+The Apache Flink community released the first bugfix version of the Apache Flink 1.13 series.
+
+This release includes 82 fixes and minor improvements for Flink 1.13.1. The list below includes bugfixes and improvements. For a complete list of all changes see:
+[JIRA](https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315522&version=12350058).
+
+We highly recommend all users to upgrade to Flink 1.13.1.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.13.1
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.13.1
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.13.1
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+
+
+ Release Notes - Flink - Version 1.13.1
+
+ Sub-task
+
+
+[FLINK-22378 ] - Type mismatch when declaring SOURCE_WATERMARK on TIMESTAMP_LTZ column
+
+[FLINK-22666 ] - Make structured type's fields more lenient during casting
+
+
+
+ Bug
+
+
+[FLINK-12351 ] - AsyncWaitOperator should deep copy StreamElement when object reuse is enabled
+
+[FLINK-17170 ] - Cannot stop streaming job with savepoint which uses kinesis consumer
+
+[FLINK-19449 ] - LEAD/LAG cannot work correctly in streaming mode
+
+[FLINK-21181 ] - Buffer pool is destroyed error when outputting data over a timer after cancellation.
+
+[FLINK-21247 ] - flink iceberg table map<string,string> cannot convert to datastream
+
+[FLINK-21469 ] - stop-with-savepoint --drain doesn't advance watermark for sources chained to MultipleInputStreamTask
+
+[FLINK-21923 ] - SplitAggregateRule will be abnormal, when the sum/count and avg in SQL at the same time
+
+[FLINK-22109 ] - Misleading exception message if the number of arguments of a nested function is incorrect
+
+[FLINK-22294 ] - Hive reading fail when getting file numbers on different filesystem nameservices
+
+[FLINK-22355 ] - Simple Task Manager Memory Model image does not show up
+
+[FLINK-22356 ] - Filesystem/Hive partition file is not committed when watermark is applied on rowtime of TIMESTAMP_LTZ type
+
+[FLINK-22408 ] - Flink Table Parsr Hive Drop Partitions Syntax unparse is Error
+
+[FLINK-22424 ] - Writing to already released buffers potentially causing data corruption during job failover/cancellation
+
+[FLINK-22431 ] - AdaptiveScheduler does not log failure cause when recovering
+
+[FLINK-22434 ] - Dispatcher does not store suspended jobs in execution graph store
+
+[FLINK-22438 ] - add numRecordsOut metric for Async IO
+
+[FLINK-22442 ] - Using scala api to change the TimeCharacteristic of the PatternStream is invalid
+
+[FLINK-22463 ] - IllegalArgumentException is thrown in WindowAttachedWindowingStrategy when two phase is enabled for distinct agg
+
+[FLINK-22479 ] - [Kinesis][Consumer] Potential lock-up under error condition
+
+[FLINK-22489 ] - subtask backpressure indicator shows value for entire job
+
+[FLINK-22494 ] - Avoid discarding checkpoints in case of failure
+
+[FLINK-22502 ] - DefaultCompletedCheckpointStore drops unrecoverable checkpoints silently
+
+[FLINK-22511 ] - Fix the bug of non-composite result type in Python TableAggregateFunction
+
+[FLINK-22512 ] - Can't call current_timestamp with hive dialect for hive-3.1
+
+[FLINK-22522 ] - BytesHashMap has many verbose logs
+
+[FLINK-22523 ] - TUMBLE TVF should throw helpful exception when specifying second interval parameter
+
+[FLINK-22525 ] - The zone id in exception message should be GMT+08:00 instead of GMT+8:00
+
+[FLINK-22535 ] - Resource leak would happen if exception thrown during AbstractInvokable#restore of task life
+
+[FLINK-22555 ] - LGPL-2.1 files in flink-python jars
+
+[FLINK-22573 ] - AsyncIO can timeout elements after completion
+
+[FLINK-22574 ] - Adaptive Scheduler: Can not cancel restarting job
+
+[FLINK-22592 ] - numBuffersInLocal is always zero when using unaligned checkpoints
+
+[FLINK-22596 ] - Active timeout is not triggered if there were no barriers
+
+[FLINK-22618 ] - Fix incorrect free resource metrics of task managers
+
+[FLINK-22654 ] - SqlCreateTable toString()/unparse() lose CONSTRAINTS and watermarks
+
+[FLINK-22661 ] - HiveInputFormatPartitionReader can return invalid data
+
+[FLINK-22688 ] - Root Exception can not be shown on Web UI in Flink 1.13.0
+
+[FLINK-22706 ] - Source NOTICE outdated regarding docs/
+
+[FLINK-22721 ] - Breaking HighAvailabilityServices interface by adding new method
+
+[FLINK-22733 ] - Type mismatch thrown in DataStream.union if parameter is KeyedStream for Python DataStream API
+
+
+
+ Improvement
+
+
+[FLINK-18952 ] - Add 10 minutes to DataStream API documentation
+
+[FLINK-20695 ] - Zookeeper node under leader and leaderlatch is not deleted after job finished
+
+[FLINK-22250 ] - flink-sql-parser model Class ParserResource lack ParserResource.properties
+
+[FLINK-22301 ] - Statebackend and CheckpointStorage type is not shown in the Web UI
+
+[FLINK-22304 ] - Refactor some interfaces for TVF based window to improve the extendability
+
+[FLINK-22470 ] - The root cause of the exception encountered during compiling the job was not exposed to users in certain cases
+
+[FLINK-22560 ] - Filter maven metadata from all jars
+
+[FLINK-22699 ] - Make ConstantArgumentCount public API
+
+[FLINK-22708 ] - Propagate savepoint settings from StreamExecutionEnvironment to StreamGraph
+
+[FLINK-22725 ] - SlotManagers should unregister metrics at the start of suspend()
+
+
\ No newline at end of file
diff --git a/docs/content.tr/posts/2021-07-07-backpressure.md b/docs/content.tr/posts/2021-07-07-backpressure.md
new file mode 100644
index 0000000000..813b0c165c
--- /dev/null
+++ b/docs/content.tr/posts/2021-07-07-backpressure.md
@@ -0,0 +1,194 @@
+---
+authors:
+- name: Piotr Nowojski
+ pnowojski: null
+ twitter: PiotrNowojski
+date: "2021-07-07T00:00:00Z"
+excerpt: Apache Flink 1.13 introduced a couple of important changes in the area of
+ backpressure monitoring and performance analysis of Flink Jobs. This blog post aims
+ to introduce those changes and explain how to use them.
+title: How to identify the source of backpressure?
+aliases:
+- /2021/07/07/backpressure.html
+---
+
+
+
+
Backpressure monitoring in the web UI
+
+
+The backpressure topic was tackled from different angles over the last couple of years. However, when it comes
+to identifying and analyzing sources of backpressure, things have changed quite a bit in the recent Flink releases
+(especially with new additions to metrics and the web UI in Flink 1.13). This post will try to clarify some of
+these changes and go into more detail about how to track down the source of backpressure, but first...
+
+## What is backpressure?
+
+This has been explained very well in an old, but still accurate, [post by Ufuk Celebi](https://www.ververica.com/blog/how-flink-handles-backpressure).
+I highly recommend reading it if you are not familiar with this concept. For a much deeper and low-level understanding of
+the topic and how Flink’s network stack works, there is a more [advanced explanation available here](https://alibabacloud.com/blog/analysis-of-network-flow-control-and-back-pressure-flink-advanced-tutorials_596632).
+
+At a high level, backpressure happens if some operator(s) in the Job Graph cannot process records at the
+same rate as they are received. This fills up the input buffers of the subtask that is running this slow operator.
+Once the input buffers are full, backpressure propagates to the output buffers of the upstream subtasks.
+Once those are filled up, the upstream subtasks are also forced to slow down their records’ processing
+rate to match the processing rate of the operator causing this bottleneck down the stream. Backpressure
+further propagates up the stream until it reaches the source operators.
+
+As long as the load and available resources are static and none of the operators produce short bursts of
+data (like windowing operators), those input/output buffers should only be in one of two states: almost empty
+or almost full. If the downstream operator or subtask is able to keep up with the influx of data, the
+buffers will be empty. If not, then the buffers will be full [1 ]. In fact, checking the buffers’ usage metrics
+was the basis of the previously recommended way on how to detect and analyze backpressure described [a couple
+of years back by Nico Kruber](https://flink.apache.org/2019/07/23/flink-network-stack-2.html#backpressure).
+As I mentioned in the beginning, Flink now offers much better tools to do the same job, but before we get to that,
+there are two questions worth asking.
+
+### Why should I care about backpressure?
+
+Backpressure is an indicator that your machines or operators are overloaded. The buildup of backpressure
+directly affects the end-to-end latency of the system, as records are waiting longer in the queues before
+being processed. Secondly, aligned checkpointing takes longer with backpressure, while unaligned checkpoints
+will be larger (you can read more about aligned and unaligned checkpoints [in the documentation]({{< param DocsBaseUrl >}}flink-docs-release-1.13/docs/concepts/stateful-stream-processing/#checkpointing).
+If you are struggling with checkpoint barriers propagation times, taking care of backpressure would most
+likely help to solve the problem. Lastly, you might just want to optimize your job in order to reduce
+the costs of running the job.
+
+In order to address the problem for all cases, one needs to be aware of it, then locate and analyze it.
+
+### Why shouldn’t I care about backpressure?
+
+Frankly, you do not always have to care about the presence of backpressure. Almost by definition, lack
+of backpressure means that your cluster is at least ever so slightly underutilized and over-provisioned.
+If you want to minimize idling resources, you probably can not avoid incurring some backpressure. This
+is especially true for batch processing.
+
+## How to detect and track down the source of backpressure?
+
+One way to detect backpressure is to use [metrics]({{< param DocsBaseUrl >}}flink-docs-release-1.13/docs/ops/metrics/#system-metrics),
+however, in Flink 1.13 it’s no longer necessary to dig so deep. In most cases, it should be enough to just
+look at the job graph in the Web UI.
+
+
+
+
+
+The first thing to note in the example above is that different tasks have different colors. Those colors
+represent a combination of two factors: under how much backpressure this task is and how busy it is. Idling
+tasks will be blue, fully busy tasks will be red hot, and fully backpressured tasks will be black. Anything
+in between will be a combination/shade of those three colors. With this knowledge, one can easily spot the
+backpressured tasks (black). The busiest (red) task downstream of the backpressured tasks will most likely
+be the source of the backpressure (the bottleneck).
+
+If you click on one particular task and go into the “BackPressure” tab you will be able to further dissect
+the problem and check what is the busy/backpressured/idle status of every subtask in that task. For example,
+this is especially handy if there is a data skew and not all subtasks are equally utilized.
+
+
+
+
Backpressure among subtasks
+
+
+In the above example, we can clearly see which subtasks are idling, which are backpressured, and that
+none of them are busy. And frankly, in a nutshell, that should be enough to quickly understand what is
+happening with your Job :) However, there are a couple of more details worth explaining.
+
+### What are those numbers?
+
+If you are curious how it works underneath, we can go a little deeper. At the base of this new mechanism
+we have three [new metrics]({{< param DocsBaseUrl >}}flink-docs-release-1.13/docs/ops/metrics/#io)
+that are exposed and calculated by each subtask:
+
+- `idleTimeMsPerSecond`
+- `busyTimeMsPerSecond`
+- `backPressuredTimeMsPerSecond`
+
+Each of them measures the average time in milliseconds per second that the subtask spent being idle,
+busy, or backpressured respectively. Apart from some rounding errors they should complement each other and
+add up to 1000ms/s. In essence, they are quite similar to, for example, CPU usage metrics.
+
+Another important detail is that they are being averaged over a short period of time (a couple of seconds)
+and they take into account everything that is happening inside the subtask’s thread: operators, functions,
+timers, checkpointing, records serialization/deserialization, network stack, and other Flink internal
+overheads. A `WindowOperator` that is busy firing timers and producing results will be reported as busy or backpressured.
+A function doing some expensive computation in `CheckpointedFunction#snapshotState` call, for instance flushing
+internal buffers, will also be reported as busy.
+
+One limitation, however, is that `busyTimeMsPerSecond` and `idleTimeMsPerSecond` metrics are oblivious
+to anything that is happening in separate threads, outside of the main subtask’s execution loop.
+Fortunately, this is only relevant for two cases:
+
+- Custom threads that you manually spawn in your operators (a discouraged practice).
+- Old-style sources that implement the deprecated `SourceFunction` interface. Such sources will report `NaN`/`N/A`
+as the value for busyTimeMsPerSecond. For more information on the topic of Data Sources please
+[take a look here]({{< param DocsBaseUrl >}}flink-docs-release-1.13/docs/dev/datastream/sources/).
+
+
+
+
Old-style sources do not report busy time
+
+
+In order to present those raw numbers in the web UI, those metrics need to be aggregated from all subtasks
+(on the job graph we are showing only tasks). This is why the web UI presents the maximal value from all
+subtasks of a given task and why the aggregated maximal values of busy and backpressured may not add up to 100%.
+One subtask can be backpressured at 60%, while another can be busy at 60%. This can result in a task that
+is both backpressured and busy at 60%.
+
+### Varying load
+
+There is one more thing. Do you remember that those metrics are measured and averaged over a couple of seconds?
+Keep this in mind when analyzing jobs or tasks with varying load, such as (sub)tasks containing a `WindowOperator`
+that is firing periodically. Both the subtask with a constant load of 50% and the subtask that alternates every
+second between being fully busy and fully idle will be reporting the same value of `busyTimeMsPerSecond`
+of 500ms/s.
+
+Furthermore, varying load and especially firing windows can move the bottleneck to a different place in
+the job graph:
+
+
+
+
Bottleneck alternating between two tasks
+
+
+
+
+
SlidingWindowOperator
+
+
+In this particular example, `SlidingWindowOperator` was the bottleneck as long as it was accumulating records.
+However, as soon as it starts to fire its windows (once every 10 seconds), the downstream task
+`SlidingWindowCheckMapper -> Sink: SlidingWindowCheckPrintSink` becomes the bottleneck and `SlidingWindowOperator`
+gets backpressured. As those busy/backpressured/idle metrics are averaging time over a couple of seconds,
+this subtlety is not immediately visible and has to be read between the lines. On top of that, the web UI
+is updating its state only once every 10 seconds, which makes spotting more frequent changes a bit more difficult.
+
+## What can I do with backpressure?
+
+In general this is a complex topic that is worthy of a dedicated blog post. It was, to a certain extent,
+addressed in [previous blog posts](https://flink.apache.org/2019/07/23/flink-network-stack-2.html#:~:text=this%20is%20unnecessary.-,What%20to%20do%20with%20Backpressure%3F,-Assuming%20that%20you).
+In short, there are two high-level ways of dealing with backpressure. Either add more resources (more machines,
+faster CPU, more RAM, better network, using SSDs…) or optimize usage of the resources you already have
+(optimize the code, tune the configuration, avoid data skew). In either case, you first need to analyze
+what is causing backpressure by:
+
+1. Identifying the presence of backpressure.
+2. Locating which subtask(s) or machines are causing it.
+3. Digging deeper into what part of the code is causing it and which resource is scarce.
+
+Backpressure monitoring improvements and metrics can help you with the first two points. To tackle the
+last one, profiling the code can be the way to go. To help with profiling, also starting from Flink 1.13,
+[Flame Graphs](http://www.brendangregg.com/flamegraphs.html) are [integrated into Flink's web UI]({{< param DocsBaseUrl >}}flink-docs-release-1.13/docs/ops/debugging/flame_graphs/).
+Flame Graphs is a well known profiling tool and visualization technique and I encourage you to give it a try.
+
+But keep in mind that after locating where the bottleneck is, you can analyze it the same way you would
+any other non-distributed application (by checking resource utilization, attaching a profiler, etc).
+Usually there is no silver bullet for problems like this. You can try to scale up but sometimes it might
+not be easy or practical to do.
+
+Anyway... The aforementioned improvements to backpressure monitoring allow us to easily detect the source of backpressure,
+and Flame Graphs can help us to analyze why a particular subtask is causing problems. Together those two
+features should make the previously quite tedious process of debugging and performance analysis of Flink
+jobs that much easier! Please upgrade to Flink 1.13.x and try them out!
+
+[1 ] There is a third possibility. In a rare case when network exchange is actually the bottleneck in your job,
+the downstream task will have empty input buffers, while upstream output buffers will be full.
\ No newline at end of file
diff --git a/docs/content.tr/posts/2021-08-06-release-1.12.5.md b/docs/content.tr/posts/2021-08-06-release-1.12.5.md
new file mode 100644
index 0000000000..2dd5efa5c0
--- /dev/null
+++ b/docs/content.tr/posts/2021-08-06-release-1.12.5.md
@@ -0,0 +1,203 @@
+---
+authors:
+- jingsong: null
+ name: Jingsong Lee
+date: "2021-08-06T00:00:00Z"
+title: Apache Flink 1.12.5 Released
+aliases:
+- /news/2021/08/06/release-1.12.5.html
+---
+
+The Apache Flink community released the next bugfix version of the Apache Flink 1.12 series.
+
+This release includes 76 fixes and minor improvements for Flink 1.12.4. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.12.5.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.12.5
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.12.5
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.12.5
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+
+Release Notes - Flink - Version 1.12.5
+
+ Bug
+
+
+[FLINK-19925 ] - Errors$NativeIoException: readAddress(..) failed: Connection reset by peer
+
+[FLINK-20321 ] - Get NPE when using AvroDeserializationSchema to deserialize null input
+
+[FLINK-20888 ] - ContinuousFileReaderOperator should not close the output on close()
+
+[FLINK-21329 ] - "Local recovery and sticky scheduling end-to-end test" does not finish within 600 seconds
+
+[FLINK-21445 ] - Application mode does not set the configuration when building PackagedProgram
+
+[FLINK-21469 ] - stop-with-savepoint --drain doesn't advance watermark for sources chained to MultipleInputStreamTask
+
+[FLINK-21952 ] - Make all the "Connection reset by peer" exception wrapped as RemoteTransportException
+
+[FLINK-22015 ] - SQL filter containing OR and IS NULL will produce an incorrect result.
+
+[FLINK-22105 ] - SubtaskCheckpointCoordinatorTest.testForceAlignedCheckpointResultingInPriorityEvents unstable
+
+[FLINK-22157 ] - Join & Select a part of composite primary key will cause ArrayIndexOutOfBoundsException
+
+[FLINK-22312 ] - YARNSessionFIFOSecuredITCase>YARNSessionFIFOITCase.checkForProhibitedLogContents due to the heartbeat exception with Yarn RM
+
+[FLINK-22408 ] - Flink Table Parsr Hive Drop Partitions Syntax unparse is Error
+
+[FLINK-22419 ] - testScheduleRunAsync fail
+
+[FLINK-22434 ] - Dispatcher does not store suspended jobs in execution graph store
+
+[FLINK-22443 ] - can not be execute an extreme long sql under batch mode
+
+[FLINK-22494 ] - Avoid discarding checkpoints in case of failure
+
+[FLINK-22496 ] - ClusterEntrypointTest.testCloseAsyncShouldBeExecutedInShutdownHook failed
+
+[FLINK-22502 ] - DefaultCompletedCheckpointStore drops unrecoverable checkpoints silently
+
+[FLINK-22547 ] - OperatorCoordinatorHolderTest. verifyCheckpointEventOrderWhenCheckpointFutureCompletesLate fail
+
+[FLINK-22564 ] - Kubernetes-related ITCases do not fail even in case of failure
+
+[FLINK-22592 ] - numBuffersInLocal is always zero when using unaligned checkpoints
+
+[FLINK-22613 ] - FlinkKinesisITCase.testStopWithSavepoint fails
+
+[FLINK-22683 ] - The total Flink/process memory of memoryConfiguration in /taskmanagers can be null or incorrect value
+
+[FLINK-22698 ] - RabbitMQ source does not stop unless message arrives in queue
+
+[FLINK-22704 ] - ZooKeeperHaServicesTest.testCleanupJobData failed
+
+[FLINK-22721 ] - Breaking HighAvailabilityServices interface by adding new method
+
+[FLINK-22733 ] - Type mismatch thrown in DataStream.union if parameter is KeyedStream for Python DataStream API
+
+[FLINK-22756 ] - DispatcherTest.testJobStatusIsShownDuringTermination fail
+
+[FLINK-22788 ] - Code of equals method grows beyond 64 KB
+
+[FLINK-22814 ] - New sources are not defining/exposing checkpointStartDelayNanos metric
+
+[FLINK-22815 ] - Disable unaligned checkpoints for broadcast partitioning
+
+[FLINK-22819 ] - YARNFileReplicationITCase fails with "The YARN application unexpectedly switched to state FAILED during deployment"
+
+[FLINK-22820 ] - Stopping Yarn session cluster will cause fatal error
+
+[FLINK-22833 ] - Source tasks (both old and new) are not reporting checkpointStartDelay via CheckpointMetrics
+
+[FLINK-22856 ] - Move our Azure pipelines away from Ubuntu 16.04 by September
+
+[FLINK-22886 ] - Thread leak in RocksDBStateUploader
+
+[FLINK-22898 ] - HiveParallelismInference limit return wrong parallelism
+
+[FLINK-22908 ] - FileExecutionGraphInfoStoreTest.testPutSuspendedJobOnClusterShutdown should wait until job is running
+
+[FLINK-22927 ] - Exception on JobClient.get_job_status().result()
+
+[FLINK-22946 ] - Network buffer deadlock introduced by unaligned checkpoint
+
+[FLINK-22952 ] - docs_404_check fail on azure due to ruby version not available
+
+[FLINK-22963 ] - The description of taskmanager.memory.task.heap.size in the official document is incorrect
+
+[FLINK-22964 ] - Connector-base exposes dependency to flink-core.
+
+[FLINK-22987 ] - Scala suffix check isn't working
+
+[FLINK-23010 ] - HivePartitionFetcherContextBase::getComparablePartitionValueList can return partitions that don't exist
+
+[FLINK-23030 ] - PartitionRequestClientFactory#createPartitionRequestClient should throw when network failure
+
+[FLINK-23045 ] - RunnablesTest.testExecutorService_uncaughtExceptionHandler fails on azure
+
+[FLINK-23074 ] - There is a class conflict between flink-connector-hive and flink-parquet
+
+[FLINK-23076 ] - DispatcherTest.testWaitingForJobMasterLeadership fails on azure
+
+[FLINK-23119 ] - Fix the issue that the exception that General Python UDAF is unsupported is not thrown in Compile Stage.
+
+[FLINK-23120 ] - ByteArrayWrapperSerializer.serialize should use writeInt to serialize the length
+
+[FLINK-23133 ] - The dependencies are not handled properly when mixing use of Python Table API and Python DataStream API
+
+[FLINK-23135 ] - Flink SQL Error while applying rule AggregateReduceGroupingRule
+
+[FLINK-23164 ] - JobMasterTest.testMultipleStartsWork unstable on azure
+
+[FLINK-23166 ] - ZipUtils doesn't handle properly for softlinks inside the zip file
+
+[FLINK-23182 ] - Connection leak in RMQSource
+
+[FLINK-23184 ] - CompileException Assignment conversion not possible from type "int" to type "short"
+
+[FLINK-23201 ] - The check on alignmentDurationNanos seems to be too strict
+
+[FLINK-23223 ] - When flushAlways is enabled the subpartition may lose notification of data availability
+
+[FLINK-23233 ] - OperatorEventSendingCheckpointITCase.testOperatorEventLostWithReaderFailure fails on azure
+
+[FLINK-23248 ] - SinkWriter is not closed when failing
+
+[FLINK-23417 ] - MiniClusterITCase.testHandleBatchJobsWhenNotEnoughSlot fails on Azure
+
+[FLINK-23429 ] - State Processor API failed with FileNotFoundException when working with state files on Cloud Storage
+
+
+
+ Improvement
+
+
+[FLINK-17857 ] - Kubernetes and docker e2e tests could not run on Mac OS after migration
+
+[FLINK-18182 ] - Upgrade AWS SDK in flink-connector-kinesis to include new region af-south-1
+
+[FLINK-20695 ] - Zookeeper node under leader and leaderlatch is not deleted after job finished
+
+[FLINK-21229 ] - Support ssl connection with schema registry format
+
+[FLINK-21411 ] - The components on which Flink depends may contain vulnerabilities. If yes, fix them.
+
+[FLINK-22708 ] - Propagate savepoint settings from StreamExecutionEnvironment to StreamGraph
+
+[FLINK-22747 ] - Update commons-io to 2.8
+
+[FLINK-22757 ] - Update GCS documentation
+
+[FLINK-22774 ] - Update Kinesis SQL connector's Guava to 27.0-jre
+
+[FLINK-22939 ] - Generalize JDK switch in azure setup
+
+[FLINK-23009 ] - Bump up Guava in Kinesis Connector
+
+[FLINK-23052 ] - cron_snapshot_deployment_maven unstable on maven
+
+[FLINK-23312 ] - Use -Dfast for building e2e tests on AZP
+
+
+
\ No newline at end of file
diff --git a/docs/content.tr/posts/2021-08-06-release-1.13.2.md b/docs/content.tr/posts/2021-08-06-release-1.13.2.md
new file mode 100644
index 0000000000..cabe7764ce
--- /dev/null
+++ b/docs/content.tr/posts/2021-08-06-release-1.13.2.md
@@ -0,0 +1,317 @@
+---
+authors:
+- name: Yun Tang
+ tangyun: null
+date: "2021-08-06T00:00:00Z"
+title: Apache Flink 1.13.2 Released
+aliases:
+- /news/2021/08/06/release-1.13.2.html
+---
+
+The Apache Flink community released the second bugfix version of the Apache Flink 1.13 series.
+
+This release includes 127 fixes and minor improvements for Flink 1.13.2. The list below includes bugfixes and improvements. For a complete list of all changes see:
+[JIRA](https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12350218&styleName=&projectId=12315522).
+
+We highly recommend all users to upgrade to Flink 1.13.2.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.13.2
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.13.2
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.13.2
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+
+
+ Release Notes - Flink - Version 1.13.2
+
+ Sub-task
+
+
+[FLINK-22726 ] - Hive GROUPING__ID returns different value in older versions
+
+
+
+ Bug
+
+
+[FLINK-20888 ] - ContinuousFileReaderOperator should not close the output on close()
+
+[FLINK-20975 ] - HiveTableSourceITCase.testPartitionFilter fails on AZP
+
+[FLINK-21389 ] - ParquetInputFormat should not need parquet schema as user input
+
+[FLINK-21445 ] - Application mode does not set the configuration when building PackagedProgram
+
+[FLINK-21952 ] - Make all the "Connection reset by peer" exception wrapped as RemoteTransportException
+
+[FLINK-22045 ] - Set log level for shaded zookeeper logger
+
+[FLINK-22195 ] - YARNHighAvailabilityITCase.testClusterClientRetrieval because of TestTimedOutException
+
+[FLINK-22203 ] - KafkaChangelogTableITCase.testKafkaCanalChangelogSource fail due to ConcurrentModificationException
+
+[FLINK-22272 ] - Some scenes can't drop table by hive catalog
+
+[FLINK-22312 ] - YARNSessionFIFOSecuredITCase>YARNSessionFIFOITCase.checkForProhibitedLogContents due to the heartbeat exception with Yarn RM
+
+[FLINK-22376 ] - SequentialChannelStateReaderImpl may recycle buffer twice
+
+[FLINK-22443 ] - can not be execute an extreme long sql under batch mode
+
+[FLINK-22462 ] - JdbcExactlyOnceSinkE2eTest.testInsert failed because of too many clients.
+
+[FLINK-22464 ] - OperatorEventSendingCheckpointITCase.testOperatorEventLostWithReaderFailure hangs with `AdaptiveScheduler`
+
+[FLINK-22492 ] - KinesisTableApiITCase with wrong results
+
+[FLINK-22496 ] - ClusterEntrypointTest.testCloseAsyncShouldBeExecutedInShutdownHook failed
+
+[FLINK-22545 ] - JVM crashes when runing OperatorEventSendingCheckpointITCase.testOperatorEventAckLost
+
+[FLINK-22547 ] - OperatorCoordinatorHolderTest. verifyCheckpointEventOrderWhenCheckpointFutureCompletesLate fail
+
+[FLINK-22613 ] - FlinkKinesisITCase.testStopWithSavepoint fails
+
+[FLINK-22662 ] - YARNHighAvailabilityITCase.testKillYarnSessionClusterEntrypoint fail
+
+[FLINK-22683 ] - The total Flink/process memory of memoryConfiguration in /taskmanagers can be null or incorrect value
+
+[FLINK-22686 ] - Incompatible subtask mappings while resuming from unaligned checkpoints
+
+[FLINK-22689 ] - Table API Documentation Row-Based Operations Example Fails
+
+[FLINK-22698 ] - RabbitMQ source does not stop unless message arrives in queue
+
+[FLINK-22725 ] - SlotManagers should unregister metrics at the start of suspend()
+
+[FLINK-22730 ] - Lookup join condition with CURRENT_DATE fails to filter records
+
+[FLINK-22746 ] - Links to connectors in docs are broken
+
+[FLINK-22759 ] - Correct the applicability of RocksDB related options as per operator
+
+[FLINK-22760 ] - HiveParser::setCurrentTimestamp fails with hive-3.1.2
+
+[FLINK-22777 ] - Restore lost sections in Try Flink DataStream API example
+
+[FLINK-22779 ] - KafkaChangelogTableITCase.testKafkaDebeziumChangelogSource fail due to ConcurrentModificationException
+
+[FLINK-22786 ] - sql-client can not create .flink-sql-history file
+
+[FLINK-22795 ] - Throw better exception when executing remote SQL file in SQL Client
+
+[FLINK-22796 ] - Update mem_setup_tm documentation
+
+[FLINK-22814 ] - New sources are not defining/exposing checkpointStartDelayNanos metric
+
+[FLINK-22815 ] - Disable unaligned checkpoints for broadcast partitioning
+
+[FLINK-22819 ] - YARNFileReplicationITCase fails with "The YARN application unexpectedly switched to state FAILED during deployment"
+
+[FLINK-22820 ] - Stopping Yarn session cluster will cause fatal error
+
+[FLINK-22833 ] - Source tasks (both old and new) are not reporting checkpointStartDelay via CheckpointMetrics
+
+[FLINK-22856 ] - Move our Azure pipelines away from Ubuntu 16.04 by September
+
+[FLINK-22863 ] - ArrayIndexOutOfBoundsException may happen when building rescale edges
+
+[FLINK-22884 ] - Select view columns fail when store metadata with hive
+
+[FLINK-22886 ] - Thread leak in RocksDBStateUploader
+
+[FLINK-22890 ] - Few tests fail in HiveTableSinkITCase
+
+[FLINK-22894 ] - Window Top-N should allow n=1
+
+[FLINK-22898 ] - HiveParallelismInference limit return wrong parallelism
+
+[FLINK-22908 ] - FileExecutionGraphInfoStoreTest.testPutSuspendedJobOnClusterShutdown should wait until job is running
+
+[FLINK-22927 ] - Exception on JobClient.get_job_status().result()
+
+[FLINK-22945 ] - StackOverflowException can happen when a large scale job is CANCELING/FAILING
+
+[FLINK-22946 ] - Network buffer deadlock introduced by unaligned checkpoint
+
+[FLINK-22948 ] - Scala example for toDataStream does not compile
+
+[FLINK-22952 ] - docs_404_check fail on azure due to ruby version not available
+
+[FLINK-22961 ] - Incorrect calculation of alignment timeout for LocalInputChannel
+
+[FLINK-22963 ] - The description of taskmanager.memory.task.heap.size in the official document is incorrect
+
+[FLINK-22964 ] - Connector-base exposes dependency to flink-core.
+
+[FLINK-22966 ] - NPE in StateAssignmentOperation when rescaling
+
+[FLINK-22980 ] - FileExecutionGraphInfoStoreTest hangs on azure
+
+[FLINK-22982 ] - java.lang.ClassCastException when using Python UDF
+
+[FLINK-22987 ] - Scala suffix check isn't working
+
+[FLINK-22993 ] - CompactFileWriter won't emit EndCheckpoint with Long.MAX_VALUE checkpointId
+
+[FLINK-23001 ] - flink-avro-glue-schema-registry lacks scala suffix
+
+[FLINK-23003 ] - Resource leak in RocksIncrementalSnapshotStrategy
+
+[FLINK-23010 ] - HivePartitionFetcherContextBase::getComparablePartitionValueList can return partitions that don't exist
+
+[FLINK-23018 ] - State factories should handle extended state descriptors
+
+[FLINK-23024 ] - RPC result TaskManagerInfoWithSlots not serializable
+
+[FLINK-23025 ] - sink-buffer-max-rows and sink-buffer-flush-interval options produce a lot of duplicates
+
+[FLINK-23030 ] - PartitionRequestClientFactory#createPartitionRequestClient should throw when network failure
+
+[FLINK-23034 ] - NPE in JobDetailsDeserializer during the reading old version of ExecutionState
+
+[FLINK-23045 ] - RunnablesTest.testExecutorService_uncaughtExceptionHandler fails on azure
+
+[FLINK-23073 ] - Fix space handling in Row CSV timestamp parser
+
+[FLINK-23074 ] - There is a class conflict between flink-connector-hive and flink-parquet
+
+[FLINK-23092 ] - Built-in UDAFs could not be mixed use with Python UDAF in group window
+
+[FLINK-23096 ] - HiveParser could not attach the sessionstate of hive
+
+[FLINK-23119 ] - Fix the issue that the exception that General Python UDAF is unsupported is not thrown in Compile Stage.
+
+[FLINK-23120 ] - ByteArrayWrapperSerializer.serialize should use writeInt to serialize the length
+
+[FLINK-23121 ] - Fix the issue that the InternalRow as arguments in Python UDAF
+
+[FLINK-23129 ] - When cancelling any running job of multiple jobs in an application cluster, JobManager shuts down
+
+[FLINK-23133 ] - The dependencies are not handled properly when mixing use of Python Table API and Python DataStream API
+
+[FLINK-23151 ] - KinesisTableApiITCase.testTableApiSourceAndSink fails on azure
+
+[FLINK-23166 ] - ZipUtils doesn't handle properly for softlinks inside the zip file
+
+[FLINK-23182 ] - Connection leak in RMQSource
+
+[FLINK-23184 ] - CompileException Assignment conversion not possible from type "int" to type "short"
+
+[FLINK-23188 ] - Unsupported function definition: IFNULL. Only user defined functions are supported as inline functions
+
+[FLINK-23196 ] - JobMasterITCase fail on azure due to BindException
+
+[FLINK-23201 ] - The check on alignmentDurationNanos seems to be too strict
+
+[FLINK-23223 ] - When flushAlways is enabled the subpartition may lose notification of data availability
+
+[FLINK-23233 ] - OperatorEventSendingCheckpointITCase.testOperatorEventLostWithReaderFailure fails on azure
+
+[FLINK-23235 ] - SinkITCase.writerAndCommitterAndGlobalCommitterExecuteInStreamingMode fails on azure
+
+[FLINK-23248 ] - SinkWriter is not closed when failing
+
+[FLINK-23259 ] - [DOCS]The 'window' link on page docs/dev/datastream/operators/overview is failed and 404 is returned
+
+[FLINK-23260 ] - [DOCS]The link on page docs/libs/gelly/overview is failed and 404 is returned
+
+[FLINK-23270 ] - Impove description of Regular Joins section
+
+[FLINK-23280 ] - Python ExplainDetails does not have JSON_EXECUTION_PLAN option
+
+[FLINK-23306 ] - FlinkRelMdUniqueKeys causes exception when used with new Schema
+
+[FLINK-23359 ] - Fix the number of available slots in testResourceCanBeAllocatedForDifferentJobAfterFree
+
+[FLINK-23368 ] - Fix the wrong mapping of state cache in PyFlink
+
+[FLINK-23429 ] - State Processor API failed with FileNotFoundException when working with state files on Cloud Storage
+
+
+
+ New Feature
+
+
+
+ Improvement
+
+
+[FLINK-18182 ] - Upgrade AWS SDK in flink-connector-kinesis to include new region af-south-1
+
+[FLINK-20140 ] - Add documentation of TableResult.collect for Python Table API
+
+[FLINK-21229 ] - Support ssl connection with schema registry format
+
+[FLINK-21393 ] - Implement ParquetAvroInputFormat
+
+[FLINK-21411 ] - The components on which Flink depends may contain vulnerabilities. If yes, fix them.
+
+[FLINK-22528 ] - Document latency tracking metrics for state accesses
+
+[FLINK-22638 ] - Keep channels blocked on alignment timeout
+
+[FLINK-22655 ] - When using -i <init.sql> option to initialize SQL Client session It should be possible to annotate the script with --
+
+[FLINK-22722 ] - Add Documentation for Kafka New Source
+
+[FLINK-22747 ] - Update commons-io to 2.8
+
+[FLINK-22766 ] - Report metrics of KafkaConsumer in Kafka new source
+
+[FLINK-22774 ] - Update Kinesis SQL connector's Guava to 27.0-jre
+
+[FLINK-22855 ] - Translate the 'Overview of Python API' page into Chinese.
+
+[FLINK-22873 ] - Add ToC to configuration documentation
+
+[FLINK-22905 ] - Fix missing comma in SQL example in "Versioned Table" page
+
+[FLINK-22939 ] - Generalize JDK switch in azure setup
+
+[FLINK-22996 ] - The description about coalesce is wrong
+
+[FLINK-23009 ] - Bump up Guava in Kinesis Connector
+
+[FLINK-23052 ] - cron_snapshot_deployment_maven unstable on maven
+
+[FLINK-23138 ] - Raise an exception if types other than PickledBytesTypeInfo are specified for state descriptor
+
+[FLINK-23156 ] - Change the reference of 'docs/dev/table/sql/queries'
+
+[FLINK-23157 ] - Fix missing comma in SQL example in "Versioned View" page
+
+[FLINK-23162 ] - Create table uses time_ltz in the column name and it's expression which results in exception
+
+[FLINK-23168 ] - Catalog shouldn't merge properties for alter DB operation
+
+[FLINK-23178 ] - Raise an error for writing stream data into partitioned hive tables without a partition committer
+
+[FLINK-23200 ] - Correct grammatical mistakes in 'Table API' page of 'Table API & SQL'
+
+[FLINK-23226 ] - Flink Chinese doc learn-flink/etl transformation.svg display issue
+
+[FLINK-23312 ] - Use -Dfast for building e2e tests on AZP
+
+
+
\ No newline at end of file
diff --git a/docs/content.tr/posts/2021-08-09-release-1.11.4.md b/docs/content.tr/posts/2021-08-09-release-1.11.4.md
new file mode 100644
index 0000000000..8c5439652c
--- /dev/null
+++ b/docs/content.tr/posts/2021-08-09-release-1.11.4.md
@@ -0,0 +1,213 @@
+---
+authors:
+- godfrey: null
+ name: Xiaoling He
+date: "2021-08-09T00:00:00Z"
+title: Apache Flink 1.11.4 Released
+aliases:
+- /news/2021/08/09/release-1.11.4.html
+---
+
+The Apache Flink community released the next bugfix version of the Apache Flink 1.11 series.
+
+This release includes 78 fixes and minor improvements for Flink 1.11.4. The list below includes a detailed list of all fixes and improvements.
+
+We highly recommend all users to upgrade to Flink 1.11.4.
+
+Updated Maven dependencies:
+
+```xml
+
+ org.apache.flink
+ flink-java
+ 1.11.4
+
+
+ org.apache.flink
+ flink-streaming-java_2.11
+ 1.11.4
+
+
+ org.apache.flink
+ flink-clients_2.11
+ 1.11.4
+
+```
+
+You can find the binaries on the updated [Downloads page](/downloads.html).
+
+
+
+ Release Notes - Flink - Version 1.11.4
+
+ Sub-task
+
+
+[FLINK-21070 ] - Overloaded aggregate functions cause converter errors
+
+[FLINK-21486 ] - Add sanity check when switching from Rocks to Heap timers
+
+
+
+ Bug
+
+
+[FLINK-15262 ] - kafka connector doesn't read from beginning immediately when 'connector.startup-mode' = 'earliest-offset'
+
+[FLINK-16443 ] - Fix wrong fix for user-code CheckpointExceptions
+
+[FLINK-18438 ] - TaskManager start failed
+
+[FLINK-19369 ] - BlobClientTest.testGetFailsDuringStreamingForJobPermanentBlob hangs
+
+[FLINK-19436 ] - TPC-DS end-to-end test (Blink planner) failed during shutdown
+
+[FLINK-19771 ] - NullPointerException when accessing null array from postgres in JDBC Connector
+
+[FLINK-20288 ] - Correct documentation about savepoint self-contained
+
+[FLINK-20383 ] - DataSet allround end-to-end test fails with NullPointerException
+
+[FLINK-20626 ] - Canceling a job when it is failing will result in job hanging in CANCELING state
+
+[FLINK-20666 ] - Fix the deserialized Row losing the field_name information in PyFlink
+
+[FLINK-20675 ] - Asynchronous checkpoint failure would not fail the job anymore
+
+[FLINK-20680 ] - Fails to call var-arg function with no parameters
+
+[FLINK-20752 ] - FailureRateRestartBackoffTimeStrategy allows one less restart than configured
+
+[FLINK-20793 ] - Fix NamesTest due to code style refactor
+
+[FLINK-20803 ] - Version mismatch between spotless-maven-plugin and google-java-format plugin
+
+[FLINK-20832 ] - Deliver bootstrap resouces ourselves for website and documentation
+
+[FLINK-20841 ] - Fix compile error due to duplicated generated files
+
+[FLINK-20913 ] - Improve new HiveConf(jobConf, HiveConf.class)
+
+[FLINK-20989 ] - Functions in ExplodeFunctionUtil should handle null data to avoid NPE
+
+[FLINK-21008 ] - Residual HA related Kubernetes ConfigMaps and ZooKeeper nodes when cluster entrypoint received SIGTERM in shutdown
+
+[FLINK-21009 ] - Can not disable certain options in Elasticsearch 7 connector
+
+[FLINK-21013 ] - Blink planner does not ingest timestamp into StreamRecord
+
+[FLINK-21028 ] - Streaming application didn't stop properly
+
+[FLINK-21030 ] - Broken job restart for job with disjoint graph
+
+[FLINK-21071 ] - Snapshot branches running against flink-docker dev-master branch
+
+[FLINK-21132 ] - BoundedOneInput.endInput is called when taking synchronous savepoint
+
+[FLINK-21138 ] - KvStateServerHandler is not invoked with user code classloader
+
+[FLINK-21148 ] - YARNSessionFIFOSecuredITCase cannot connect to BlobServer
+
+[FLINK-21208 ] - pyarrow exception when using window with pandas udaf
+
+[FLINK-21213 ] - e2e test fail with 'As task is already not running, no longer decline checkpoint'
+
+[FLINK-21215 ] - Checkpoint was declined because one input stream is finished
+
+[FLINK-21216 ] - StreamPandasConversionTests Fails
+
+[FLINK-21274 ] - At per-job mode, during the exit of the JobManager process, if ioExecutor exits at the end, the System.exit() method will not be executed.
+
+[FLINK-21289 ] - Application mode ignores the pipeline.classpaths configuration
+
+[FLINK-21312 ] - SavepointITCase.testStopSavepointWithBoundedInputConcurrently is unstable
+
+[FLINK-21323 ] - Stop-with-savepoint is not supported by SourceOperatorStreamTask
+
+[FLINK-21453 ] - BoundedOneInput.endInput is NOT called when doing stop with savepoint WITH drain
+
+[FLINK-21497 ] - JobLeaderIdService completes leader future despite no leader being elected
+
+[FLINK-21550 ] - ZooKeeperHaServicesTest.testSimpleClose fail
+
+[FLINK-21606 ] - TaskManager connected to invalid JobManager leading to TaskSubmissionException
+
+[FLINK-21609 ] - SimpleRecoveryITCaseBase.testRestartMultipleTimes fails on azure
+
+[FLINK-21654 ] - YARNSessionCapacitySchedulerITCase.testStartYarnSessionClusterInQaTeamQueue fail because of NullPointerException
+
+[FLINK-21725 ] - DataTypeExtractor extracts wrong fields ordering for Tuple12
+
+[FLINK-21753 ] - Cycle references between memory manager and gc cleaner action
+
+[FLINK-21980 ] - ZooKeeperRunningJobsRegistry creates an empty znode
+
+[FLINK-21986 ] - taskmanager native memory not release timely after restart
+
+[FLINK-22081 ] - Entropy key not resolved if flink-s3-fs-hadoop is added as a plugin
+
+[FLINK-22109 ] - Misleading exception message if the number of arguments of a nested function is incorrect
+
+[FLINK-22184 ] - Rest client shutdown on failure runs in netty thread
+
+[FLINK-22424 ] - Writing to already released buffers potentially causing data corruption during job failover/cancellation
+
+[FLINK-22489 ] - subtask backpressure indicator shows value for entire job
+
+[FLINK-22597 ] - JobMaster cannot be restarted
+
+[FLINK-22815 ] - Disable unaligned checkpoints for broadcast partitioning
+
+[FLINK-22946 ] - Network buffer deadlock introduced by unaligned checkpoint
+
+[FLINK-23164 ] - JobMasterTest.testMultipleStartsWork unstable on azure
+
+[FLINK-23166 ] - ZipUtils doesn't handle properly for softlinks inside the zip file
+
+
+
+ Improvement
+
+
+[FLINK-9844 ] - PackagedProgram does not close URLClassLoader
+
+[FLINK-18182 ] - Upgrade AWS SDK in flink-connector-kinesis to include new region af-south-1
+
+[FLINK-19415 ] - Move Hive document to "Table & SQL Connectors" from "Table API & SQL"
+
+[FLINK-20651 ] - Use Spotless/google-java-format for code formatting/enforcement
+
+[FLINK-20770 ] - Incorrect description for config option kubernetes.rest-service.exposed.type
+
+[FLINK-20790 ] - Generated classes should not be put under src/ directory
+
+[FLINK-20792 ] - Allow shorthand invocation of spotless
+
+[FLINK-20805 ] - Blink runtime classes partially ignored by spotless
+
+[FLINK-20866 ] - Add how to list jobs in Yarn deployment documentation when HA enabled
+
+[FLINK-20906 ] - Update copyright year to 2021 for NOTICE files
+
+[FLINK-21020 ] - Bump Jackson to 2.10.5[.1] / 2.12.1
+
+[FLINK-21123 ] - Upgrade Beanutils 1.9.x to 1.9.4
+
+[FLINK-21164 ] - Jar handlers don't cleanup temporarily extracted jars
+
+[FLINK-21210 ] - ApplicationClusterEntryPoints should explicitly close PackagedProgram
+
+[FLINK-21411 ] - The components on which Flink depends may contain vulnerabilities. If yes, fix them.
+
+[FLINK-21735 ] - Harden JobMaster#updateTaskExecutionState()
+
+[FLINK-22142 ] - Remove console logging for Kafka connector for AZP runs
+
+[FLINK-22208 ] - Bump snappy-java to 1.1.5+
+
+[FLINK-22470 ] - The root cause of the exception encountered during compiling the job was not exposed to users in certain cases
+
+[FLINK-23312 ] - Use -Dfast for building e2e tests on AZP
+
+
+
\ No newline at end of file
diff --git a/docs/content.tr/posts/2021-08-31-release-1.14.0-rc0.md b/docs/content.tr/posts/2021-08-31-release-1.14.0-rc0.md
new file mode 100644
index 0000000000..3935e7e4d7
--- /dev/null
+++ b/docs/content.tr/posts/2021-08-31-release-1.14.0-rc0.md
@@ -0,0 +1,46 @@
+---
+authors:
+- joemoe: null
+ name: Johannes Moser
+date: "2021-08-31T00:00:00Z"
+title: Help us stabilize Apache Flink 1.14.0 RC0
+aliases:
+- /news/2021/08/31/release-1.14.0-rc0.html
+---
+
+
+
Hint
+
+ Update 29th of September: Today
+ Apache Flink 1.14
+ has been released. For sure we'd still like to hear your feedback.
+
+
+
+Dear Flink Community,
+
+we are excited to announce the first release candidate of Apache Flink 1.14. 🎉
+
+A lot of features and fixes went into this release, including improvements to the
+unified batch and streaming experience, an increase in fault tolerance by reducing
+in-flight data, and more developments on connectors and components.
+It wouldn't have been possible without your help.
+Around 211 people have made contributions!
+
+Two weeks ago (August 16th) we created a feature freeze. This means that only a
+few small, almost-ready features will go into the release from this moment on.
+We are now in the process of stabilizing the release and need your help! As you can
+see on the [1.14 release coordination page](https://cwiki.apache.org/confluence/display/FLINK/1.14+Release),
+a lot of focus is on documentation and testing.
+
+If you would like to contribute to the squirrel community, a great way would be to
+download the [release candidate](https://dist.apache.org/repos/dist/dev/flink/flink-1.14.0-rc0/)
+and test it. You can run some existing Flink jobs or pick one of the
+[test issues](https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=468&quickFilter=2115).
+We would greatly appreciate any feedback you can provide on the
+[JIRA tickets](https://issues.apache.org/jira/projects/FLINK/summary) or on
+the [mailing list](https://flink.apache.org/gettinghelp.html#user-mailing-list).
+
+We continue to be grateful and inspired by the community who believe in the project and want to help create a great user experience and product for all Flink users.
+
+Many thanks!
\ No newline at end of file
diff --git a/docs/content.tr/posts/2021-08-31-release-statefun-3.1.0.md b/docs/content.tr/posts/2021-08-31-release-statefun-3.1.0.md
new file mode 100644
index 0000000000..ddf3c2d71f
--- /dev/null
+++ b/docs/content.tr/posts/2021-08-31-release-statefun-3.1.0.md
@@ -0,0 +1,228 @@
+---
+authors:
+- name: Seth Wiesman
+ sjwiesman: null
+ twitter: sjwiesman
+- igalshilman: null
+ name: Igal Shilman
+ twitter: IgalShilman
+- name: Tzu-Li (Gordon) Tai
+ twitter: tzulitai
+ tzulitai: null
+date: "2021-08-31T08:00:00Z"
+subtitle: The Apache Flink community is happy to announce the release of Stateful
+ Functions (StateFun) 3.1.0.
+title: Stateful Functions 3.1.0 Release Announcement
+aliases:
+- /news/2021/08/31/release-statefun-3.1.0.html
+---
+
+Stateful Functions is a cross-platform stack for building Stateful Serverless applications, making it radically simpler to develop scalable, consistent, and elastic distributed applications.
+This new release brings various improvements to the StateFun runtime, a leaner way to specify StateFun module components, and a brand new GoLang SDK!
+
+The binary distribution and source artifacts are now available on the updated [Downloads](https://flink.apache.org/downloads.html)
+page of the Flink website, and the most recent Java SDK, Python SDK, and GoLang SDK distributions are available on [Maven](https://search.maven.org/artifact/org.apache.flink/statefun-sdk-java/3.1.0/jar), [PyPI](https://pypi.org/project/apache-flink-statefun/), and [Github](https://github.com/apache/flink-statefun/tree/statefun-sdk-go/v3.1.0) repecitvely.
+You can also find official StateFun Docker images of the new version on [Dockerhub](https://hub.docker.com/r/apache/flink-statefun).
+
+For more details, check the complete [release changelog](https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12350038&projectId=12315522)
+and the [updated documentation]({{< param DocsBaseUrl >}}flink-statefun-docs-release-3.0/).
+We encourage you to download the release and share your feedback with the community through the [Flink mailing lists](https://flink.apache.org/community.html#mailing-lists)
+or [JIRA](https://issues.apache.org/jira/browse/)!
+
+## New Features
+
+### Delayed Message Cancellation
+
+Stateful Functions communicate by sending messages, but sometimes it is helpful that a function will send a message for itself.
+For example, you may want to set a time limit on a customer onboarding flow to complete.
+This can easily be implmented by sending a message with a delay.
+But up until now, there was no way to indicate to the StateFun runtime that a particular delayed message is not necessary anymore (a customer had completed their onboarding flow).
+With StateFun 3.1, it is now possible to cancel a delayed message.
+
+```python
+...
+context.send_after(timedelta(days=3),
+ message_builder(target_typename="fns/onboarding",
+ target_id="user-1234",
+ str_value="send a reminder email"),
+ cancellation_token="flow-1234")
+...
+```
+
+To cancel the message at a later time, simply call
+
+```python
+context.cancel_delayed_message("flow-1234")
+```
+
+Please note that a message cancellation occurs on a best-effort basis, as the message might have already been delivered or enqueued for immediate delivery on a remote worker’s mailbox.
+
+### New way to specify components
+
+StateFun applications consist of multiple configuration components, including remote function endpoints, along with ingress and egress definitions, defined in a YAML format.
+We've added a new structure that treats each StateFun component as a standalone YAML document in this release.
+Thus, a `module.yaml` file becomes simply a collection of components.
+
+```yaml
+kind: io.statefun.endpoints.v2/http
+spec:
+ functions: com.example/*
+ urlPathTemplate: https://bar.foo.com/{function.name}
+---
+kind: io.statefun.kafka.v1/ingress
+spec:
+ id: com.example/my-ingress
+ address: kafka-broker:9092
+ consumerGroupId: my-consumer-group
+ topics:
+ - topic: message-topic
+ valueType: io.statefun.types/string
+ targets:
+ - com.example/greeter
+---
+kind: io.statefun.kafka.v1/egress
+spec:
+ id: com.example/my-egress
+ address: kafka-broker:9092
+ deliverySemantic:
+ type: exactly-once
+ transactionTimeout: 15min
+---
+```
+
+While this might seem like a minor cosmetic improvement, this change opens the door to more flexible configuration management options in future releases - such as managing each component as a custom K8s resource definition or even behind a REST API. StateFun still supports the legacy module format in version 3.0 for backward compatibility, but users are encouraged to upgrade.
+The community is providing an [automated migration tool](https://github.com/sjwiesman/statefun-module-upgrade) to ease the transition.
+
+### Pluggable transport for remote function invocations
+It is possible to plugin a custom mechanism that invokes a remote stateful function starting with this release.
+Users who wish to use a customized transport need to register it as an extension and later reference it straight from the endpoint component definition.
+
+For example:
+
+```yaml
+kind: io.statefun.endpoints.v2/http
+spec:
+ functions: com.foo.bar/*
+ urlPathTemplate: https://{function.name}/
+ maxNumBatchRequests: 10000
+ transport:
+ type: com.foo.bar/pubsub
+ some_property1: some_value1
+```
+
+For a complete example of a custom transport you can start exploring [here](https://github.com/apache/flink-statefun/blob/release-3.1.0/statefun-flink/statefun-flink-core/src/main/java/org/apache/flink/statefun/flink/core/nettyclient/NettyTransportModule.java).
+Along with a reference usage over [here](https://github.com/apache/flink-statefun/blob/release-3.1.0/statefun-e2e-tests/statefun-smoke-e2e-java/src/test/resources/remote-module/module.yaml#L21-L22 ).
+
+### Asynchronous, non blocking remote function invocation (beta)
+
+For this release we’ve included a new transport implementation (opt in for this release) that is implemented on top of the asynchronous Netty framework.
+This transport enables much higher resource utilization, higher throughput, and lower remote function invocation latency.
+
+To enable this new transport, set the transport type to be `io.statefun.transports.v1/async`
+Like in the following example:
+
+```yaml
+kind: io.statefun.endpoints.v2/http
+spec:
+ functions: fns/*
+ urlPathTemplate: https://api-gateway.foo.bar/{function.name}
+ maxNumBatchRequests: 10000
+ transport:
+ type: io.statefun.transports.v1/async
+ call: 2m
+ connect: 20s
+```
+
+Take it for a spin!
+
+
+### A brand new GoLang SDK
+
+Stateful Functions provides a unified model for building stateful applications across various programming languages and deployment environments.
+The community is thrilled to release an official GoLang SDK as part of the 3.1.0 release.
+
+```go
+import (
+ "fmt"
+ "github.com/apache/flink-statefun/statefun-sdk-go/v3/pkg/statefun"
+ "net/http"
+)
+
+type Greeter struct {
+ SeenCount statefun.ValueSpec
+}
+
+func (g *Greeter) Invoke(ctx statefun.Context, message statefun.Message) error {
+ storage := ctx.Storage()
+
+ // Read the current value of the state
+ // or zero value if no value is set
+ var count int32
+ storage.Get(g.SeenCount, &count)
+
+ count += 1
+
+ // Update the state which will
+ // be made persistent by the runtime
+ storage.Set(g.SeenCount, count)
+
+ name := message.AsString()
+ greeting := fmt.Sprintf("Hello there %s at the %d-th time!\n", name, count)
+
+ ctx.Send(statefun.MessageBuilder{
+ Target: *ctx.Caller(),
+ Value: greeting,
+ })
+
+ return nil
+}
+
+
+func main() {
+ greeter := &Greeter{
+ SeenCount: statefun.ValueSpec{
+ Name: "seen_count",
+ ValueType: statefun.Int32Type,
+ },
+ }
+
+ builder := statefun.StatefulFunctionsBuilder()
+ _ = builder.WithSpec(statefun.StatefulFunctionSpec{
+ FunctionType: statefun.TypeNameFrom("com.example.fns/greeter"),
+ States: []statefun.ValueSpec{greeter.SeenCount},
+ Function: greeter,
+ })
+
+ http.Handle("/statefun", builder.AsHandler())
+ _ = http.ListenAndServe(":8000", nil)
+}
+```
+
+As with the Python and Java SDKs, the Go SDK includes:
+
+ - An address scoped storage acting as a key-value store for a particular address.
+ - A unified cross-language way to send, receive and store values across languages.
+ - Dynamic `ValueSpec` to describe the state name, type, and possibly expiration configuration at runtime.
+
+You can get started by adding the SDK to your `go.mod` file.
+
+`require github.com/apache/flink-statefun/statefun-sdk-go/v3 v3.1.0`
+
+For a detailed SDK tutorial, we would like to encourage you to visit:
+
+ - [GoLang SDK Showcase](https://github.com/apache/flink-statefun-playground/tree/release-3.1/go/showcase)
+ - [GoLang Greeter](https://github.com/apache/flink-statefun-playground/tree/release-3.1/go/greeter)
+ - [GoLang SDK Documentation]({{< param DocsBaseUrl >}}flink-statefun-docs-release-3.1/docs/sdk/golang/)
+
+## Release Notes
+
+## Release Notes
+
+Please review the [release notes](https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12350038&projectId=12315522)
+for a detailed list of changes and new features if you plan to upgrade your setup to Stateful Functions 3.1.0.
+
+## List of Contributors
+
+Evans Ye, George Birbilis, Igal Shilman, Konstantin Knauf, Seth Wiesman, Siddique Ahmad, Tzu-Li (Gordon) Tai, ariskk, austin ce
+
+If you’d like to get involved, we’re always [looking for new contributors](https://github.com/apache/flink-statefun#contributing).
diff --git a/docs/content.tr/posts/2021-09-07-connector-table-sql-api-part1.md b/docs/content.tr/posts/2021-09-07-connector-table-sql-api-part1.md
new file mode 100644
index 0000000000..2618d0d753
--- /dev/null
+++ b/docs/content.tr/posts/2021-09-07-connector-table-sql-api-part1.md
@@ -0,0 +1,240 @@
+---
+authors:
+- Ingo Buerk: null
+ name: Ingo Buerk
+- Daisy Tsang: null
+ name: Daisy Tsang
+date: "2021-09-07T00:00:00Z"
+title: 'Implementing a Custom Source Connector for Table API and SQL - Part One '
+aliases:
+- /2021/09/07/connector-table-sql-api-part1.html
+---
+
+Part one of this tutorial will teach you how to build and run a custom source connector to be used with Table API and SQL, two high-level abstractions in Flink. The tutorial comes with a bundled [docker-compose](https://docs.docker.com/compose/) setup that lets you easily run the connector. You can then try it out with Flink’s SQL client.
+
+# Introduction
+
+Apache Flink is a data processing engine that aims to keep [state](https://ci.apache.org/projects/flink/flink-docs-release-1.13/docs/ops/state/state_backends/) locally in order to do computations efficiently. However, Flink does not "own" the data but relies on external systems to ingest and persist data. Connecting to external data input (**sources**) and external data storage (**sinks**) is usually summarized under the term **connectors** in Flink.
+
+Since connectors are such important components, Flink ships with [connectors for some popular systems](https://ci.apache.org/projects/flink/flink-docs-release-1.13/docs/connectors/table/overview/). But sometimes you may need to read in an uncommon data format and what Flink provides is not enough. This is why Flink also provides extension points for building custom connectors if you want to connect to a system that is not supported by an existing connector.
+
+Once you have a source and a sink defined for Flink, you can use its declarative APIs (in the form of the [Table API and SQL](https://ci.apache.org/projects/flink/flink-docs-release-1.13/docs/dev/table/overview/)) to execute queries for data analysis.
+
+The **Table API** provides more programmatic access while **SQL** is a more universal query language. It is named Table API because of its relational functions on tables: how to obtain a table, how to output a table, and how to perform query operations on the table.
+
+In this two-part tutorial, you will explore some of these APIs and concepts by implementing your own custom source connector for reading in data from an email inbox. You will then use Flink to process emails through the [IMAP protocol](https://en.wikipedia.org/wiki/Internet_Message_Access_Protocol).
+
+Part one will focus on building a custom source connector and [part two](/2021/09/07/connector-table-sql-api-part2) will focus on integrating it.
+
+
+# Prerequisites
+
+This tutorial assumes that you have some familiarity with Java and objected-oriented programming.
+
+You are encouraged to follow along with the code in this [repository](https://github.com/Airblader/blog-imap).
+
+It would also be useful to have [docker-compose](https://docs.docker.com/compose/install/) installed on your system in order to use the script included in the repository that builds and runs the connector.
+
+
+# Understand the infrastructure required for a connector
+
+In order to create a connector which works with Flink, you need:
+
+1. A _factory class_ (a blueprint for creating other objects from string properties) that tells Flink with which identifier (in this case, “imap”) our connector can be addressed, which configuration options it exposes, and how the connector can be instantiated. Since Flink uses the Java Service Provider Interface (SPI) to discover factories located in different modules, you will also need to add some configuration details.
+
+2. The _table source_ object as a specific instance of the connector during the planning stage. It is responsible for back and forth communication with the optimizer during the planning stage and is like another factory for creating connector runtime implementation. There are also more advanced features, such as [abilities](https://ci.apache.org/projects/flink/flink-docs-release-1.13/api/java/org/apache/flink/table/connector/source/abilities/package-summary.html), that can be implemented to improve connector performance.
+
+3. A _runtime implementation_ from the connector obtained during the planning stage. The runtime logic is implemented in Flink's core connector interfaces and does the actual work of producing rows of dynamic table data. The runtime instances are shipped to the Flink cluster.
+
+Let us look at this sequence (factory class → table source → runtime implementation) in reverse order.
+
+# Establish the runtime implementation of the connector
+
+You first need to have a source connector which can be used in Flink's runtime system, defining how data goes in and how it can be executed in the cluster. There are a few different interfaces available for implementing the actual source of the data and have it be discoverable in Flink.
+
+For complex connectors, you may want to implement the [Source interface](https://ci.apache.org/projects/flink/flink-docs-release-1.13/api/java/org/apache/flink/api/connector/source/Source.html) which gives you a lot of control. For simpler use cases, you can use the [SourceFunction interface](https://ci.apache.org/projects/flink/flink-docs-release-1.13/api/java/org/apache/flink/streaming/api/functions/source/SourceFunction.html). There are already a few different implementations of SourceFunction interfaces for common use cases such as the [FromElementsFunction](https://ci.apache.org/projects/flink/flink-docs-release-1.13/api/java/org/apache/flink/streaming/api/functions/source/FromElementsFunction.html) class and the [RichSourceFunction](https://ci.apache.org/projects/flink/flink-docs-release-1.13/api/java/org/apache/flink/streaming/api/functions/source/RichSourceFunction.html) class. You will use the latter.
+
+
+
Hint
+
The Source interface is the new abstraction whereas the SourceFunction interface is slowly phasing out.
+ All connectors will eventually implement the Source interface.
+
+
+
+`RichSourceFunction` is a base class for implementing a data source that has access to context information and some lifecycle methods. There is a `run()` method inherited from the `SourceFunction` interface that you need to implement. It is invoked once and can be used to produce the data either once for a bounded result or within a loop for an unbounded stream.
+
+For example, to create a bounded data source, you could implement this method so that it reads all existing emails and then closes. To create an unbounded source, you could only look at new emails coming in while the source is active. You can also combine these behaviors and expose them through configuration options.
+
+When you first create the class and implement the interface, it should look something like this:
+
+```java
+import org.apache.flink.streaming.api.functions.source.RichSourceFunction;
+import org.apache.flink.table.data.RowData;
+
+public class ImapSource extends RichSourceFunction {
+ @Override
+ public void run(SourceContext ctx) throws Exception {}
+
+ @Override
+ public void cancel() {}
+}
+```
+
+Note that internal data structures (`RowData`) are used because that is required by the table runtime.
+
+In the `run()` method, you get access to a [context](https://ci.apache.org/projects/flink/flink-docs-release-1.13/api/java/org/apache/flink/streaming/api/functions/source/SourceFunction.SourceContext.html) object inherited from the SourceFunction interface, which is a bridge to Flink and allows you to output data. Since the source does not produce any data yet, the next step is to make it produce some static data in order to test that the data flows correctly:
+
+```java
+import org.apache.flink.streaming.api.functions.source.RichSourceFunction;
+import org.apache.flink.table.data.GenericRowData;
+import org.apache.flink.table.data.RowData;
+import org.apache.flink.table.data.StringData;
+
+public class ImapSource extends RichSourceFunction {
+ @Override
+ public void run(SourceContext ctx) throws Exception {
+ ctx.collect(GenericRowData.of(
+ StringData.fromString("Subject 1"),
+ StringData.fromString("Hello, World!")
+ ));
+ }
+
+ @Override
+ public void cancel(){}
+}
+```
+
+You do not need to implement the `cancel()` method yet because the source finishes instantly.
+
+# Create and configure a dynamic table source for the data stream
+
+[Dynamic tables](https://ci.apache.org/projects/flink/flink-docs-release-1.13/docs/dev/table/concepts/dynamic_tables/) are the core concept of Flink’s Table API and SQL support for streaming data and, like its name suggests, change over time. You can imagine a data stream being logically converted into a table that is constantly changing. For this tutorial, the emails that will be read in will be interpreted as a (source) table that is queryable. It can be viewed as a specific instance of a connector class.
+
+You will now implement a [DynamicTableSource](https://ci.apache.org/projects/flink/flink-docs-release-1.13/api/java/org/apache/flink/table/connector/source/DynamicTableSource.html) interface. There are two types of dynamic table sources: [ScanTableSource](https://ci.apache.org/projects/flink/flink-docs-release-1.13/api/java/org/apache/flink/table/connector/source/ScanTableSource.html) and [LookupTableSource](https://ci.apache.org/projects/flink/flink-docs-release-1.13/api/java/org/apache/flink/table/connector/source/LookupTableSource.html). Scan sources read the entire table on the external system while lookup sources look for specific rows based on keys. The former will fit the use case of this tutorial.
+
+This is what a scan table source implementation would look like:
+
+```java
+import org.apache.flink.table.connector.ChangelogMode;
+import org.apache.flink.table.connector.source.DynamicTableSource;
+import org.apache.flink.table.connector.source.ScanTableSource;
+import org.apache.flink.table.connector.source.SourceFunctionProvider;
+
+public class ImapTableSource implements ScanTableSource {
+ @Override
+ public ChangelogMode getChangelogMode() {
+ return ChangelogMode.insertOnly();
+ }
+
+ @Override
+ public ScanRuntimeProvider getScanRuntimeProvider(ScanContext ctx) {
+ boolean bounded = true;
+ final ImapSource source = new ImapSource();
+ return SourceFunctionProvider.of(source, bounded);
+ }
+
+ @Override
+ public DynamicTableSource copy() {
+ return new ImapTableSource();
+ }
+
+ @Override
+ public String asSummaryString() {
+ return "IMAP Table Source";
+ }
+}
+```
+
+[ChangelogMode](https://ci.apache.org/projects/flink/flink-docs-release-1.13/api/java/org/apache/flink/table/connector/ChangelogMode.html) informs Flink of expected changes that the planner can expect during runtime. For example, whether the source produces only new rows, also updates to existing ones, or whether it can remove previously produced rows. Our source will only produce (`insertOnly()`) new rows.
+
+[ScanRuntimeProvider](https://ci.apache.org/projects/flink/flink-docs-release-1.13/api/java/org/apache/flink/table/connector/source/ScanTableSource.ScanRuntimeProvider.html) allows Flink to create the actual runtime implementation you established previously (for reading the data). Flink even provides utilities like [SourceFunctionProvider](https://ci.apache.org/projects/flink/flink-docs-release-1.13/api/java/org/apache/flink/table/connector/source/SourceFunctionProvider.html) to wrap it into an instance of [SourceFunction](https://ci.apache.org/projects/flink/flink-docs-release-1.13/api/java/org/apache/flink/streaming/api/functions/source/SourceFunction.html), which is one of the base runtime interfaces.
+
+You will also need to indicate whether the source is bounded or not. Currently, this is the case but you will have to change this later.
+
+# Create a factory class for the connector so it can be discovered by Flink
+
+You now have a working source connector, but in order to use it in Table API or SQL, it needs to be discoverable by Flink. You also need to define how the connector is addressable from a SQL statement when creating a source table.
+
+You need to implement a [Factory](https://ci.apache.org/projects/flink/flink-docs-release-1.13/api/java/org/apache/flink/table/factories/Factory.html), which is a base interface that creates object instances from a list of key-value pairs in Flink's Table API and SQL. A factory is uniquely identified by its class name and `factoryIdentifier()`. For this tutorial, you will implement the more specific [DynamicTableSourceFactory](https://ci.apache.org/projects/flink/flink-docs-release-1.13/api/java/org/apache/flink/table/factories/DynamicTableSourceFactory.html), which allows you to configure a dynamic table connector as well as create `DynamicTableSource` instances.
+
+```java
+import java.util.HashSet;
+import java.util.Set;
+import org.apache.flink.configuration.ConfigOption;
+import org.apache.flink.table.connector.source.DynamicTableSource;
+import org.apache.flink.table.factories.DynamicTableSourceFactory;
+import org.apache.flink.table.factories.FactoryUtil;
+
+public class ImapTableSourceFactory implements DynamicTableSourceFactory {
+ @Override
+ public String factoryIdentifier() {
+ return "imap";
+ }
+
+ @Override
+ public Set