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 3E507200CCA for ; Wed, 5 Jul 2017 04:28:05 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 3D6921622F8; Wed, 5 Jul 2017 02:28:05 +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 8376F1622F3 for ; Wed, 5 Jul 2017 04:28:04 +0200 (CEST) Received: (qmail 15367 invoked by uid 500); 5 Jul 2017 02:28:03 -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 15355 invoked by uid 99); 5 Jul 2017 02:28:03 -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:28:03 +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 B24F0191715 for ; Wed, 5 Jul 2017 02:28:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id wlm2Sz2FQi4R for ; Wed, 5 Jul 2017 02:27:59 +0000 (UTC) Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id A05DC5FC43 for ; Wed, 5 Jul 2017 02:27:58 +0000 (UTC) Received: by mail-wm0-f48.google.com with SMTP id w126so208838467wme.0 for ; Tue, 04 Jul 2017 19:27:58 -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=JYSKTSoRZvTTyofBsI8rQ51sqXrTXVJSCS6CFxUsNn0=; b=H4D6N4Ysw+SrqGByZgU/GUboLFYgOE2zB/ailYUD3otUaCWly3eGNSwKUEJ5gQlngV 746L/793ON/tmM+Heh8TkwSF+60D7g6onvLNTfwRVUqvnuLllekQSQz/qQUrRZ8TZG0Z SZ/SrSkL00kr9GOvTG04l6hSSbrE3vfRT/DGBXqUi9/rAxiKCf564wcSWC0o2DVtI1x/ ILPdRB7gyMkQE8/5oHsvpsvc+28hQh/UnAx3ORevJ0EDVrSQcbDHmiEj1ji66GGPrMrj WB+T8CyrCyV45sL6sgOD1+JgBSNxeoQWRqhI8XdKpT+2WqT1zcu0mym5yXGPZeLDxXix ZvjQ== 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=JYSKTSoRZvTTyofBsI8rQ51sqXrTXVJSCS6CFxUsNn0=; b=dMQdoYERRLoTu7z56RjRet9CujHMTI6BAnJ2/JKmsFMTKL+HSX3HYbspa8z19TYmvc CNzZZuWlyzJ35B4KQWyYHtbXJ3Rf5VCbii/ktXCUao8VJoWeqe9IeU+WWK1iZtJ/d8yG NuUFMDR+1/nz9mEPb7uMT4ogShHEauKiCttlEY9JPKproleQgIMgOT8ms0OS5xYYlCsR ClNkwpp8daJyXNeI3L14AAY/rIX5TVkxgnMz1tk2D96NIxUAYFlPzTeEK00iEjvijuqd MJ9mEhINajKT3EdyAYcEGPgb0aMHzHt1wJBzKWBo5Pp9/hvHqKSvpOaaqVxnMY8ZvNaM GUzw== X-Gm-Message-State: AIVw111iU+eRwF8SiJx6vv7oJTw8hCLpXUqzL31pEeEBTa7TuMHIQsJC UNr4lqyHJDkHhMXt4gqyJhvbWPkutw== X-Received: by 10.28.21.80 with SMTP id 77mr9499314wmv.79.1499221678221; Tue, 04 Jul 2017 19:27:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.138.189 with HTTP; Tue, 4 Jul 2017 19:27:57 -0700 (PDT) In-Reply-To: <3dd83d0b-3d2d-e4f8-2f82-bc4a766442f2@apache.org> References: <3dd83d0b-3d2d-e4f8-2f82-bc4a766442f2@apache.org> From: "wenlong.lwl" Date: Wed, 5 Jul 2017 10:27:57 +0800 Message-ID: Subject: Re: [DISCUSS] FLIP-22: Eager State Declaration To: dev@flink.apache.org Content-Type: multipart/alternative; boundary="001a1145b3d091ed01055388bf44" archived-at: Wed, 05 Jul 2017 02:28:05 -0000 --001a1145b3d091ed01055388bf44 Content-Type: text/plain; charset="UTF-8" Hi, all, we have jobs which create state according to type of the key and a dynamic configuration: eg: key_type_1's aggregation function is average, while key_type_2's is sum we need to create state dynamically because the aggregation function may change in runtime and different aggregation function may need different state to persistent state. It is really hard to declare state eagerly. In the flip, I think the main concern to propose the eager declaration of state is to make sure when restoring we can have all states registered. how about just persisting state descriptor in state handle and automatically register states in restoring? On 5 July 2017 at 03:53, Chesnay Schepler wrote: > 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 >> > > > --001a1145b3d091ed01055388bf44--