Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 261D9200CCA for ; Wed, 5 Jul 2017 04:36:09 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 2539E16231F; Wed, 5 Jul 2017 02:36:09 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 6ABA4162319 for ; Wed, 5 Jul 2017 04:36:08 +0200 (CEST) Received: (qmail 22721 invoked by uid 500); 5 Jul 2017 02:36:07 -0000 Mailing-List: contact dev-help@flink.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@flink.apache.org Delivered-To: mailing list dev@flink.apache.org Received: (qmail 22708 invoked by uid 99); 5 Jul 2017 02:36:07 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Jul 2017 02:36:07 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id B3C461812FA for ; Wed, 5 Jul 2017 02:36:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id 7RSeXyK-BfAy for ; Wed, 5 Jul 2017 02:36:05 +0000 (UTC) Received: from mail-wr0-f172.google.com (mail-wr0-f172.google.com [209.85.128.172]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id B4BED5F6C4 for ; Wed, 5 Jul 2017 02:36:04 +0000 (UTC) Received: by mail-wr0-f172.google.com with SMTP id c11so256056596wrc.3 for ; Tue, 04 Jul 2017 19:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zeh1wNGjh69e5huiXCLEEhUw5FSO4/iHtbh1O6OQhQw=; b=hbYiz9dqfoAwWZ+jDI3waKI2QeSsPfQ8FM6jAKcl13P5qnnNlpEkzxyK75lJRo8yGR 2kjS2QmmFczD7i3wUG6m2qVd3pIGWfm+qFQyhZgLQNJvGtHFnt6aHHBXzG6dXK5a8wCc yTmW6ct4HaTuQuQ/pUls+Kd2DDJ1saO1dbo3vFgq+W+KE1VDLi6GeBWVpZiXdjcM3XAy eSP6L/1DPRmWlKUDNAcR/nWFO9id+BgPyHvfmt+2ep4ozQbscJtzUFkxIqu8i53bVRMR JkMFDxqljAtH7nLgJawkLHf+Z9FkjBkm+uvJfbRvGRoAeD5o1NnCc4b4ipax5iM/xgkc ovCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=zeh1wNGjh69e5huiXCLEEhUw5FSO4/iHtbh1O6OQhQw=; b=mIgWKUruwcBE5IIIFAssgv18P2rUa/upe6QrQGWgESe9ePc4GTW2RFjcSPp1U8ywYv giie6EcrGj+Wz44LDPGZBymJwXyEAjvX2v9QavbnrGG+kspCkr1YhEWzilFd1QmCw1Ws 8/d0EALD9ocRqxp45nH/tQ57lKyobWiC/xCJma2pmt6AZ6LAlwc6big9W4WWLf/LEX/l exmSkKgc3wJMCSWSSQ93AH9D9Mekj2YXNzl+LJC+smDdOlnJtuTf7Ni0gRaFmS2wpnUp EBsBLYIocWV/ZxotbMHd9U+C8zxrZ8/u4kuZnP2e9+8g4G+wT0X08OJRAL852uEP/C1W e6+w== X-Gm-Message-State: AKS2vOwENO3USo7AgJe29hHxmD76MD4N1Bt2fsgq2VislFm0m47KG04H KMbHXdnBph6ckGRAlT5qaFDVD3NiGeIm X-Received: by 10.223.133.211 with SMTP id 19mr42881675wru.27.1499222163504; Tue, 04 Jul 2017 19:36:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.168.118 with HTTP; Tue, 4 Jul 2017 19:36:02 -0700 (PDT) In-Reply-To: <3dd83d0b-3d2d-e4f8-2f82-bc4a766442f2@apache.org> References: <3dd83d0b-3d2d-e4f8-2f82-bc4a766442f2@apache.org> From: SHI Xiaogang Date: Wed, 5 Jul 2017 10:36:02 +0800 Message-ID: Subject: Re: [DISCUSS] FLIP-22: Eager State Declaration To: dev@flink.apache.org Content-Type: multipart/alternative; boundary="001a114984147ec5ee055388dcf7" archived-at: Wed, 05 Jul 2017 02:36:09 -0000 --001a114984147ec5ee055388dcf7 Content-Type: text/plain; charset="UTF-8" Hi Tzu-Li, Thanks for the proposal. The changes are great. I have several questions about some details. First, do you have any plan to provide a method to remove states? Now states can only be created (either lazily or eagerly), but cannot be removed. We cannot remove those states not registered because they may be accessed later (with those deprecated methods). Second, what about exposing namespaces to users? Now namespaces are only used in window streams and all user states are in the void namespace. But some users may come across similar scenarios to window streams where states are closely related to arrived records and cannot be known beforehand. Since namespaces are not exposed, they have to create new states when new records arrive. MapState is another choice, but will be less efficient in some cases. If we can expose namespaces to users, these users may benefit from eagerly declared states. I think the change will not break existing interfaces. Looking forwards to your comments. Regards, Xiaogang 2017-07-05 3:53 GMT+08:00 Chesnay Schepler : > Could you add an example to the FLIP for how a user can register a state > with the methods in the RichFunction interface? > Currently it only contains an example for the annotation option. > > These methods look like they are called by the user, but that doesn't > really make sense to me as after all the user has to > implement them. > > To me a more intuitive signature would be > > |void registerKeyedState(StateDescriptorRegistry registry);| > > that is called by the system when a UDF is provided by a user who then > registers all the state descriptors he has. > > > On 04.07.2017 20:00, Tzu-Li (Gordon) Tai wrote: > >> Hi Flink devs! >> >> I would like to propose the following FLIP - Eager State Declaration for >> Flink managed state: https://cwiki.apache.org/confl >> uence/display/FLINK/FLIP-22%3A+Eager+State+Declaration. >> The proposal is a result of some offline discussions with Aljoscha >> Krettek, Stephan Ewen, and Stefan Richter. >> >> With how the current managed state declaration interfaces work, users may >> declare state lazily while jobs are running. >> This behavior is a direct blocker for several state management features >> we wish to make a reality in the future. >> I also see it as an opportunity to make the interfaces for keyed / >> operator managed state declarations more unified at the API level, as well >> as improved user experience for general use cases. >> >> The most important part of the required changes is the deprecation of >> existing APIs and introducing new state declaration interfaces. >> Since this would be a rework of the state interfaces, it would be great >> to hear thoughts on this and make sure that the proposal is what we want in >> the long run! >> >> Happy to hear feedback on this :) >> >> Cheers, >> Gordon >> > > > --001a114984147ec5ee055388dcf7--