Flink sql for state checkpoint - apache-flink

When I use flink sql api process data.
Restart app, sum result not save in checkpoint.It's still start with 1.
final StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
StateBackend stateBackend = new FsStateBackend("file:///D:/d_backup/github/flink-best-practice/checkpoint");
env.enableCheckpointing(1000 * 60);
env.setStateBackend(stateBackend);
Table table = tableEnv.sqlQuery(
"select sum(area_id) " +
"from rtc_warning_gmys " +
"where area_id = 1 " +
"group by character_id,area_id,group_id,platform");
// convert the Table into a retract DataStream of Row.
// A retract stream of type X is a DataStream<Tuple2<Boolean, X>>.
// The boolean field indicates the type of the change.
// True is INSERT, false is DELETE.
DataStream<Tuple2<Boolean, Row>> dsRow = tableEnv.toRetractStream(table, Row.class);
dsRow.map(new MapFunction<Tuple2<Boolean,Row>, Object>() {
#Override
public Object map(Tuple2<Boolean, Row> booleanRowTuple2) throws Exception {
if(booleanRowTuple2.f0) {
System.out.println(booleanRowTuple2.f1.toString());
return booleanRowTuple2.f1;
}
return null;
}
});
env.execute("Kafka table select");
Log as:
1
2
3
...
...
100
Restart app it still start:
1
2
3
...
I think sum value will be stored in checkpint file and restart app can read last result from checkpint like:
101
102
103
...
120

Some possibilities:
Did the job run long enough to complete a checkpoint? Just because the job produced output doesn't mean that a checkpoint was completed. I see you have checkpointing configured to occur once a minute, and the checkpoints could take some time to complete.
How was the job stopped? Unless they have been externalized, checkpoints are deleted when a job is cancelled.
How was the job restarted? Did it recover (automatically) from a checkpoint, or was it resumed from an externalized checkpoint or savepoint, or was it restarted from scratch?
This sort of experiment is easiest to do via the command line. You might, for example,
write an app that uses checkpoints, and has a restart strategy (e.g., env.setRestartStrategy(RestartStrategies.fixedDelayRestart(1000, 1000)))
start a local cluster
"flink run -d app.jar" to start the job
wait until at least one checkpoint has completed
"kill -9 task-manager-PID" to cause a failure
"taskmanager.sh start" to allow the job to resume from the checkpoint

Related

Why sys.sp_describe_first_result_set return 1 on very first time- not always?

SSIS package for import csv file has been configured with SQL server agent which run every 2 min.
Experiencing, SQL process suspended with result sys.sp_describe_first_result_set;1
When : ONLY at VERY first time (when Azure VM created) with more than one csv file import.
When not :
If any single CSV file import has happen before.
If point 1 has been followed , we can rapid import any number of csv file.(no sql suspend)
SQL Process suspended with sys.sp_describe_first_result_set return 1
Details of suspended :
Blkby = -2 = orphaned distributed transaction
Suspended : session is waiting for an event to complete
Command : Execute
Issue has been resolved by removing <DTS:TransactionOption = "2" from SSIS package
It was not properly implemented in my case ,follow for more details
https://learn.microsoft.com/en-us/sql/integration-services/integration-services-transactions?view=sql-server-ver16
Below are TransactionOption values
NotSupported : 0 Supported : 1 Required : 2

Snowflake Warehouse Cannot Be Suspended?

I have a Snowflake Warehouse using 10 credits so far this month I no longer believe to be in use. To safely verify it's no longer in use I tried to:
ALTER WAREHOUSE MY_WAREHOUSE SUSPEND
But I received the message:
Invalid state. Warehouse 'MY_WAREHOUSE' cannot be suspended.
Why might the warehouse not be able to be suspended? What else do I need to check and run?
Additionally, is there a way to check if any queries/loaders have utilized this warehouse in the past X days?
While issuing the ALTER WAREHOUSE ... SUSPEND command, you will receive the error "Invalid state. Warehouse 'MY_WAREHOUSE' cannot be suspended" when the warehouse has already been suspended.
Before issuing the SUSPEND command, check the status of the warehouse using the below command
show warehouses like '%TEST%' in account;
The STATE column of the resultset will give the status of the warehouse.
To check if there were any queries that were using this warehouse, you can use the below query
select * from snowflake.account_usage.query_history where warehouse_name='Warehouse name' and START_TIME > 'Timestamp';
https://docs.snowflake.com/en/sql-reference/account-usage/query_history.html#query-history-view
https://docs.snowflake.com/en/sql-reference/functions/query_history.html#query-history-query-history-by
Or you could also choose to check the warehouse credits from the Account -> Usage tab in the Snowflake Web UI.
try dropping the auto suspend e.g. running something like this :
CREATE OR REPLACE WAREHOUSE SOME_FANCY_WAREHOUSE_NAME
WITH WAREHOUSE_SIZE = 'MEDIUM'
MAX_CLUSTER_COUNT = 1
MIN_CLUSTER_COUNT = 1
AUTO_SUSPEND = 60
AUTO_RESUME = TRUE
INITIALLY_SUSPENDED = TRUE
;

Snowflake task with CRON not scheduled

I have created a Snowflake task like the one below,
CREATE or replace TASK staging.task_name
WAREHOUSE = 'staging_warehouse'
SCHEDULE = 'USING CRON 0 1 * * * UTC'
AS
delete from staging....
but I dont the see task scheduled or executed looking at the task history
select *
from table(information_schema.task_history(
scheduled_time_range_start=>dateadd('hour',-10,current_timestamp()),
result_limit => 10,
task_name=>'task_name'));
I usually run task with minute based schedule and this is the first time using a cron schedule, what might I be missing here?
Can you enable the task and then run the query again?
alter task staging.task_name resume;

Is there a way to force run a Snowflake's TASK now (before the next scheduled slot)?

I have a task scheduled to run every 15 minutes:
CREATE OR REPLACE TASK mytask
WAREHOUSE = 'SHARED_WH_MEDIUM'
SCHEDULE = '15 MINUTE'
STATEMENT_TIMEOUT_IN_SECONDS = 3600,
QUERY_TAG = 'KLIPFOLIO'
AS
CREATE OR REPLACE TABLE mytable AS
SELECT * from xxx;
;
alter task mytask resume;
I see from the output of task_history() that the task is SCHEDULED:
select * from table(aftonbladet.information_schema.task_history(task_name => 'MYTASK')) order by scheduled_time;
QUERY_ID NAME DATABASE_NAME SCHEMA_NAME QUERY_TEXT CONDITION_TEXT STATE ERROR_CODE ERROR_MESSAGE SCHEDULED_TIME COMPLETED_TIME RETURN_VALUE
*** MYTASK *** *** *** SCHEDULED 2020-01-21 09:58:12.434 +0100
but I want it to run right now without waiting for the SCHEDULED_TIME , is there any way to accomplish that?
Snowflake now supports running tasks manually. Just use the EXECUTE TASK command:
EXECUTE TASK manually triggers an asynchronous single run of a scheduled task (either a standalone task or the root task in a task tree) independent of the schedule defined for the task. A successful run of a root task triggers a cascading run of child tasks in the tree as their precedent task completes, as though the root task had run on its defined schedule.
Also, there is no need for the task in started mode. Even tasks in suspended mode can be executed manually.
There is no way currently to execute a task manually. You could, however, alter the task schedule to 1 minute, let it run, and then alter it back to 15 minutes, so that you're not waiting the full 15 minutes. I have seen this request multiple times, and there is an Idea on Lodge (https://community.snowflake.com/s/ideas) that you should upvote (search for 'Tasks' and I think it'll be one of the top ideas). Since Tasks are still in Public Preview, it's likely that these types of ideas will be reviewed and prioritized if they have a lot of votes.
To build on Mike's answer:
You could have a task that executes every minute, but only if there's data on the stream!
For this you can create a table and stream just to decide if the task will be triggered every minute or not.
This root task should delete the data inserted in the stream to prevent the task running again.
So then you can have dependent tasks that execute every time you bring data into the stream, but only when the stream has new data.
This relies on the ability to run a task only when SYSTEM$STREAM_HAS_DATA()
-- stream so this task executes every minute, but only if there's new data
create table just_timestamps_stream_table(value varchar);
create stream just_timestamps_stream on table just_timestamps_stream_table;
-- https://docs.snowflake.com/en/user-guide/tasks-intro.html
create or replace task mytask_minute
warehouse = test_small
schedule = '1 MINUTE'
when SYSTEM$STREAM_HAS_DATA('just_timestamps_stream')
as
-- consume stream so tasks doesn't execute again
delete from just_timestamps_stream_table;
-- the real task to be executed
create or replace task mytask_minute_child1
warehouse = test_small
after mytask_minute
as
insert into just_timestamps values(current_timestamp, 'child1');
Full example:
https://github.com/fhoffa/snowflake_snippets/blob/main/stream_and_tasks/minimal.sql

xml Column update and Locking in Sql Server

I have a few windwos services. They get xml column from Sql server manipulate and update it.
Service A- Gets XML
Service B- Gets XML
Service A- Updates XML (it will be lost)
Service B- Updates XML
I must lock row and I use next Code:
SqlCommand cmdUpdate = new SqlCommand();
cmdUpdate.CommandText = "select MyXML from MyTable with(holdlock,rowlock) where id=#id";
cmdUpdate.Parameters.AddWithValue("#id", id);
using (SqlConnection conn = Helper.GetConnection())
{
cmdUpdate.Connection = conn;
SqlTransaction ts = conn.BeginTransaction();
cmdUpdate.Transaction = ts;
XElement elem = XElement.Parse(cmdUpdate.ExecuteScalar().ToString());
UpdateXElement(elem);
cmdUpdate.Parameters.Clear();
cmdUpdate.CommandText = "update MyTable set MyXML=#xml where id=#id";
cmdUpdate.Parameters.AddWithValue("#id", id);
cmdUpdate.Parameters.AddWithValue("#xml", elem.ToString());
cmdUpdate.ExecuteNonQuery();
ts.Commit();
}
}`
then occurs Deadlocks.
Have you got a better idea, to solve this problem ?
Thanks
The scenario you are describing is not a deadlock. It's a lock contention, in other words, exactly what the locks are for:
Service A- Gets XML - Service A locks XML
Service B- Gets XML - Services B places lock request which waits for service A to release the lock
Service A- Updates XML (it will be lost) - Service A should commit or rollback the transaction to release the lock.
Service B- Updates XML - Service B acquires the lock on the XML and updates it
Service B will be frozen between steps 2 and 3.
This means you should perform these steps as fast as possible.
Update:
You use a HOLDLOCK to lock the row in a transaction.
HOLDLOCK places a shared lock which is compatible with another shared lock but not with update lock placed by UPDATE.
Here's what happens:
Service A places a shared lock on row 1
Service B places a shared lock on row 1
Service A tries to place an update lock on row 1 which is not compatible with the shared lock placed by Service B on step 2. Service A enters wait state (while still holding a shared lock placed on step 1).
Service B tries to place an update lock on row 1 which is not compatible with the shared lock placed by Service A on step 1. Service B enters wait state. DEADLOCK.
There is no point in placing a shared lock in a SELECT clause here. You should place an UPDLOCK in a SELECT clause instead. This will make the transaction locks completely incompatible and either transaction will have to wait for completion of other transactions before acquiring any locks.
In this scenario, deadlocks are impossible.

Resources