Skip to main content
Loading Explore guides…
SAS Cloud Time Series Processing · Acedra
Home
Explore
Computer Science
SAS Cloud Time Series Processing
Sign in to save
Chat
If YouTube asks you to sign in, open the video on YouTube.
Watch on YouTube
Reload player
Transcript
58 segments
Copy
Hide video
0:00
JAVIER DELGADO: Hello, everyone, and thank you for taking the time to attend this presentation. And so what I'll be discussing today is the cloud-based time series processing system that's behind SAS Visual Forecasting. And this is a system that's designed to scale to millions of time series if your infrastructure allows it. And this has been a very well-received system. Now, one thing that we've constantly been asked over the past couple of years when we presented it
0:36
is whether users can use languages besides the SAS language itself to interact with the system. And in particular, people are interested in the time series community to use Python and R. And so I'm happy to report that as of the end of 2019, the answer to that is yes. You can now use Python and R code using our new External Languages Package. So that's what I'll be discussing today is how to use this package. But before that, let me quickly give a primer
1:08
on the back-end system behind all of this. So what we refer to as TSMODEL is this cloud-based time series processing infrastructure. And what it is an infrastructure that works with facets of Cloud Analytic Services to allow users to run your time series on the cloud. And it scales very well. It handles data movement for you, as well as data processing.
1:40
I'm not going to show any empirical results here, in the interest of time. But we've done tests with millions of times series and it scales very well.
1:50
And there's multiple ways you can interact with this system. So you can use the SAS Visual Forecasting Graphical User Interface. Or you can use SAS code if you're a coder. You can use, for example, the TSMODEL Procedure to interact with the system. Or if you prefer using one of the other clients that CAS supports, you can use those as well.
2:12
So let's set the scene for a scenario in which you could use this system. So if you're a big corporation or some other entity that has millions of time series and you have a huge cluster, you can use this system. For the sake of just describing the system, let's go with a more modest cluster of four worker nodes connected to a distributed file system. And so the distributed file system is essentially a set of hardware for storage and software to manage that storage in an optimal fashion.
2:47
As a user, all you're concerned with is that you have data tables, in our case, time series data tables, and you want to submit those to the worker nodes to work with them. So we're going to ignore the distributor file system details in the interest of time. Now, we'll get back to that later. So as a user, what you're concerned with is that you will have some processing you want to do on these worker nodes. So what you're going to do is you're going to write a script.
3:21
Either manually write the script yourself, or if you're using the Visual Forecasting Interface, then your interactions with the interface will create that script for you. And the system will replicate the script on each of the worker nodes.
3:38
You don't have to worry about any of that yourself.
3:44
And the big news here is that you're not limited to just SAS anymore with your users script. You can use any combination of SAS, Python, and R code in there.
3:59
So let's go a little bit into the details of the script. So the first thing that's going to happen when the worker nodes receive this, they're going to compile the script into the machine code, so that it's as quick as possible.
4:14
And so that should the SAS code itself. But as I mentioned, you can now have Python and R code. So how does that work with this system? So in order to discuss that, let's make the script a little bit less abstract. Let's show this hypothetical, very simple SAS script I call an external language code, in this case, Python code. All you need to know here is that anything within these submit blocks, that's what's going to run on the worker nodes.
4:42
And you can see here that we've pushed some Python code. So you can think of this code as being written into its own little code.py file. And it's the same concept for R. But for this example, I'll just use Python.
5:01
All right. So we're back to our cluster here. We have our compiled script on each of these nodes. So now, we want to run some Python code, in addition to the compiled SAS code. So by using Python objects in here with the system nodes that it has to run to Python interpreter, which on Windows, python.exe. If this was UNIX, user then Python, et cetera. And remember that code.py file where we extracted the Python code, so that's going to be fed to the Python process.
5:39
So what's missing now is the data. So back here, we go back to the distributed file system, which is going to take the data and send it to the worker nodes. I won't go into the details of how the load balancing and all that work. In this case, it's pretty simple. We have seven time series on each of the two data tables, and we have four worker nodes. And so that results in three of the worker nodes having two times series from each table, and then the last, the third node
6:12
having just one time series from each of the two tables. Presumably, these are modern nodes where that leads four CPU cores each. So we can actually process all of these time series in parallel at the same time.
6:34
Now, once that's done processing, what's left is to send the data back to the distributed file system. And that's all automatically handled for you as well. You just specify what your output data sets are. One thing I didn't show here is how that data is shared between the SAS process and the Python process. So you don't need to worry about that either. We're going to do that for you. All you need to do a specify which are the variables that you want to share between the environments.
7:07
But we're not going to unnecessarily share all the variables for you.
7:13
And I'll show how that works in a bit when we go into the actual objects that you use for interacting with the external languages.
7:24
This is just a quick slide that shows how the system scales. So here, we ran up to 400 threads with a data set size of 87 gigabytes. And you can see that it scales very well, culminating at about five minutes for using 400 processing cores to run this really large data set.
7:52
Comparatively, if we did the same thing using our serial processing framework, it's 130 hours.
8:03
All right, so now, let's get into the details of the External Languages Package.
8:11
And here, I list all of the packages that come with Visual Forecasting. But I don't really have time to go into each one. But I list them here just to emphasize the fact that in addition to the fact that you can parallelize your Python and R code now, you can also integrate that code with all of these features that come with Visual Forecasting. So that really augments the power of what you can do.
8:38
As far as some highlights of this External Languages Package, so first of all, you can run any code you want with this system. Obviously, it's designed to optimize time series processing. But we don't limit what you can do. If you want to run some hello world with it, that's fine. Go ahead. We also don't limit what version of Python and R you use. Obviously, there's some practical limits here. If you want to use a version of Python that was released 10 years ago, that might be a problem.
9:12
But any relatively recent version, like 2.6 for Python, 2.5 for R, that will work. We also don't require you to install any third-party packages for either Python or R. We only installed the libraries that you need for your own processing.
9:32
As I mentioned, we automatically transfer data to and from SAS.
9:38
So basically, we share the variables. Whatever variables you specify your want to share, we're going to do that data transfer for you. And I'll give an example how you specify those variables in a bit.
9:51
For those of you who are concerned now because you have support for these general purpose languages, like Python and R, that allow you to access file system, the key processes and all that, we do have a flexible access control methodology in place to restrict what users can do. As far as launching the External Language Process that's supplying which Python or R interpreter they want to use, things like that, you can control them.
10:23
All right, so now, let's go into a little bit more of the specifics of the package itself. As with our other Visual Forecasting packages, we take an object-oriented approach. And we can break down the objects into three main kinds. The first are the interpreter objects. So these are the objects we use to actually interact directly with the external language. So the first thing you can do with these objects is insert code. And we provide three ways of inserting code.
10:55
One is directly into the SAS script. So basically, you just create a string there with the Python or R code you want to run. If you have a very long piece of code, that's obviously not going to be as convenient. So you can also load the code from a file, provided it's a file that's accessible to all of the worker nodes. And you can also load code from a CAS table.
11:24
With the interpreter objects, you can also specify shared variables. So these are the variables that will be made available in the Python or R process.
11:36
And you can specify environment variables. If your external language code relies on environment variables, you can specify those within the SAS program. They'll be made available for you. Obviously, you can run the code. And then there's several other miscellaneous functions for things like getting exit codes, run times, things like that. So I won't go into those specific little details now. The next set of objects are the collector objects.
12:05
So these are the ones you use to store other kinds of data into CAS tables. So, for example, if you're running on millions of time series, you're going to have millions of logs. By logs, I mean anything that's read into standard output or standard error in your Python or Oracle code using print statements or whatever.
12:27
So you can store these into CAS tables so that you can look at them later. So, for example, if something didn't go right with just a subset of the time series or if you just want to take a look at a few random ones just to eyeball what went on, you can do that by storing it in the table using this collector object and then looking at it later using whatever modality you use for looking tables. You can also store shared variable status. So occasionally, shared variables
12:58
that are supposed to be written back to the SAS process are not, for one reason or another. But you can use this status table to get a better idea of what went wrong. And you can store source code, which you can then load back using these repeater objects. Well, in this case, we just have one repeater object to load. That stores the source code.
13:26
All right, so with that, we can go into the example.
13:32
And we'll describe a very simple example, which calculates the moving average of a time series using Python. And in this case, we have a data set consisting of many times series, so this can all be done in parallel.
13:47
For those of you viewing this, I'm not close to a monitor, like in a classroom setting or something. Don't worry. I'm going to go into the details of each of these sections of code. But I wanted to show like a big picture view of the code itself first. And this is an actual working code. So this kind of demonstrates that you don't need to have a lot of setup code to run your Python program. So the first thing to emphasize here is that the code between the submit and then submit logs.
14:23
Keep in mind, that's what's going to actually run in the cluster on the worker nodes, in other words. The rest is basically setup code where you're going to specify the tables you use for input and output and whatnot. And then this section of code here in the purple, that is just extend the language specific code. As you can see, this program is mostly just using external language codes. The rest is boilerplate stuff.
14:55
All right, so let's get to the first part here. So the first thing is we're going to specify the parameters of our PROC TSMODEL call. The first thing is the input data that we're going to use. And here, we're using the skinproduct data set in the mycas CAS library. So the skinproduct data set is a synthetic data set. It has several times series, consisting of a fictional skincare products sales with a weekly time interval.
15:30
Next, we're going to specify where we're going to put our output data. So we're specifying here that output array data. That's going to go in a table called outarray in the same mycas CAS library.
15:45
Similarly, scalar output data is going to go into this OUTSCALAR table. And then objects that are part of the Visual Forecasting infrastructure that we use, they'll go on their own tables. So in this case, we just have one such object, which is a log object. And that's going to store all of our Python logs. And that's going to go in this pylog table.
16:12
Here, we specify the name of the variable in the data set that contains the temporal data. So in this case, it's a variable called date. And the interval is weekly. BY, so that's where we delineate how we want these time series to be parallelized. So in this case, each distribution center is going to be its own time series. So depending on the number of distribution centers we have in this skinproduct data set, we'll have a separate process for each of those.
16:45
And we'll automatically send that sub-series of the time series to the appropriate worker node.
16:58
And then VAR revenue, so this is a variable within this skinproduct data set that we want to use. And when we accumulate the data set into equal sized buckets of time, we're going to sum those data.
17:15
And then runtime, that's going to be our only OUTSCALAR. And that's going to store the runtime of the pipeline process, just so you know how long it took to run that pipeline code.
17:28
And then our only output array is M average, which is a moving average.
17:36
All right, so now, we can get to the next section. So the first thing we do is we specify that we want to use objects for the External Languages Package. And we do that with this REQUIRE statement. If you're a Python programmer, that's like an import statement. If you're R programmer, you've got the library statement Next, we start our SUBMIT block, which recall this where we start the code that's going to be executed on the cluster. So we're going to create our pipeline object.
18:07
In this case, we want to use the Python 2 interpreter. So we're going to create a Python 2 object, and then initialize that object.
18:17
Next, we're going to specify our shared variables. In this case, we have two shared variables. And to do that, we use this AddVariable method. And the AddVariable method takes various parameters. I'm just going to go over the two main ones here. So the first required parameter is the variable name itself, in this case, revenue. And so the first common optional parameter for AddVariable is the alias. So this is used because you might have existing Python
18:55
code that doesn't necessarily take a variable called revenue, but a more generic name, like y for an independent variable. So by specifying this alias, instead of making the variable known as revenue in the Python program, it'll be known as y. So you can just refer to it as Y. So you don't need to change your Python programming, in other words, just to accommodate this. So the other shared variable is M average for the moving average.
19:26
And the parameter we're passing here is read only. So by default, we're only going to send data to the Python process. And, again, this is just to limit the amount of unnecessary data movement.
19:43
So in the case of revenue, we're only using it as an input variable. So we then have to bring it back. So we keep the default read only attribute there. In the case of M average, that's what we actually want to calculate and bring back to SAS. So we're going to have data that's not read only. We want that back to the SAS process.
20:04
And then finally, we can add our Python code. I'm not going to go into the details of this code itself. Basically, it calculates the moving average, using convolution. And then you specify that you want to run the code using the run method call. You can get the runtime. And then we're going to write the code to collect the log from each of these Python runs. And for that, we use this OUTEXTLOG object. And we call the collect method using the Python object as an argument.
20:42
And then we specify that we want all the logs.
20:49
And that's it for the parallel code. And we can close TSMODEL statement. Once you run that, you can retrieve the data any way you want. You can use SGPLOT to plot it. You can use PROC print to print table, et cetera.
21:06
So that was an example of how to use the SAS programmatically or how to use the External Language programmatically. You can also use it through the GUI, although that's kind of limited since this is a new package. But here, I'll just show some screenshots of how you would integrate external language code into Model Studio. So you can use the Exchange to add a, for example, an open source node to use as part of your automatic model selection process. And once you do that, you can see
21:45
when you create a pipeline that it will be part of your pipeline. In this case, for these screens, what I'm showing screenshots of here, we used an R model, an R ARIMA model, as part of the automatic model selection. And you can see that it was actually used in some cases. And so that's all I have for now. Thanks for your attention.
Here to help you learn
Sign in to keep a private conversation with your course tutor.
Ask me anything about the material…
Sign in to chat