Having previously worked with ARIMA and other AR-related models, this is a very comprehensive introduction of ARIMA which anyone interested in learning more about time-series forecasting can benefit from.
One point of critique though which is not immediately mentioned in the article: Depending on your data, and especially if your granularity is measured in anything under minutes, you might find the need to continuously calibrate your parameters as to ensure performance over time. I found myself running optimisations in parallel when deploying an ARIMA-inspired model for my use case, for instance. If continuously computing optimisations is not an option, it might be worthwhile implementing outlier detection or simple thresholds to prompt optimisation calls when needed. In either case, ARIMA is definitely a fun rabbit hole to explore if you have not previously worked with time-series forecasting!
Anyone here have a take on when to use Arima vs Holt Winters vs something like R's GLM for forecasting time series data which may have seasonal or day-of-week patterns? I've been on projects using all of them and I'm still not clear on the tradeoffs.
Holt Winters is just a fancy way of saying triple exponential forecasting. Exponential forecasting is supposedly easier to handle trends and seasonality. Holt Winters assume there is seasonality.
ARIMA can do seasonality too if you differentiate for it. I believe both require you to either decompose your time series and figure out if there is any seasonality in it. ARIMA requires that the time series be stationary so if it is not you need to transform it. Exponential smoothing including Holt Winters don't care and iirc you use exponential smoothing technique most of the time for nonstationary data.
GLM have rigorous assumptions for data that makes it usually harder for time series. Both ARIMA and Holt Winter are for forecasting where was GLM is for inferences. ARIMA is auto regressive where it regress on it's pass self. So if you look at the equation it's only Y's unless you use ARIMAX. GLM is a general framework for regression and it regress on other predictors (independent variables). It's tricky to do GLM on time series data because when you want to predict a value in the future say 2021 then often time you need to know your predictor values in the future to predict your response.
I know ARIMA inference is base on time lag. Hence regressing it past self. The relationship that your inferencing on is what response you care about and it's past self. So you can detect patterns in time lag. As for GLM you inference between the linear association between the independent predictors and the response.
One problem I have with statsmodels is that I cannot apply trained models to new data rather than to the train data. In other words I do not want to forecast the train data - I want to forecast completely new time series.
For example, here I create and train a model:
model = ARIMA(df.value, order=(1,1,1))
fitted = model.fit(disp=0)
And then I immediately do forecast:
fc, se, conf = fitted.forecast(...)
Yet, it is not what I need. Typically, I store the model and then apply it to many new datasets which are received later.
sklearn explicitly supports this pattern (train data set for training and then another data set for prediction).
Is it possible in ARIMA and other forecasting algorithms in statsmodels?
In ARIMA the only thing that changes is time so you don't need to wait for future data. It sounds like you may be trying to use covariates, which is not a problem with statsmodels but model choice -- you'd need to use ARIMAX not ARIMA.
Assume we have a series of N value 4, 7, 3, ..., 9, 2, 5. We use them for training a model. Now we forget about this data (for whatever reason). We receive a completely new series like 2, 3, 7, 5, 4, 5. Our goal is to forecast the next value of this new series. How can we find it using statsmodels?
It'll depend on your usecase. Prophet is easier to use because FB wrapped everything in a really simple API.
ARIMA is still really good if you have someone who is an expert in it. It has been producing useful results for the past like...30 years? If you have someone who understand the concept and can tune it, I'd say go for it.
On the other hand, I find that it is extremely hard to explain ARIMA model to business folks. Since ARIMA is basically AR terms and MA terms, which translates into using historical value, and historical error, to predict future values, it makes it really hard to say 'when did something changed?' or 'what is our seasonality?' or 'what is the month to month seasonality for this particular product?'
Prophet, on the other hand, gives you really nice components, such as seasonality, trend, holidays, and can be made to easily incorporate other factors, something ARIMA type models can as well...but it is really advance stuff.
Overall...If you're just learning time-series analysis, ARIMA is an important lesson to learn, but for actually doing the analysis/forecast, I'd say use Prophet. Just don't fall into the trap of using a package someone else created without understanding what's going on underneath
In practice I find prophet far superior. Prophet can deal deftly with the kind of problems that show up in real-world data like missing values and radical changes in trend from shocks to the system you're modeling.
For textbook problems like forecasting electricity demand, sARIMA works just fine, but you'll struggle forecasting anything more complex. This is not to say that it's impossible, but it will require far more expertise.
It's kinda amazing that only now have I discovered how useful time series forecasting is for sysadmin/devops/SRE/whatever we call it now.
In effect, Icinga (Nagios) represents a local maxima. It's very easy to write checks without mathematical or statistical sophistication -- write a check in the language of your choice and return a status enum containing one of three values: OK, WARN, CRIT. A result there's a massive collection of checks written by others. Sure the language to configure it sucks, but mostly because it models so many things -- systems to be monitored, how to group systems, the checks to monitor systems with, who to alert, and on what schedule.
Instead of doing one thing well, Nagios does everything, kinda poorly. You can't easily schedule overrides for an on-call rotation. Event correlation is entirely manual. You have to restart the service to add or remove monitoring -- it's not prepared for autoscaling or clustering. It can't even scale itself!
There is a better way, using a layered approach. Break the task up into multiple steps: Sense, Store, Analzye, Alert, Route. Nagios effectively discards the Store step, and divy up the remaining work between checks and nagios master. Sense+Analyze+Alert are done by the client, and the Nagios master handles alert Routing.
(taking it home to the topic) Because Nagios has no Store step, analyze is limited in power. You cannot calculate standard deviations, or even rates of change. ARIMA is impossible, as is ETS. You typically define static thresholds. If there's any seasonality, you have to find a static threshold that catches real problems while minimizing false alarms.
The downside to the layered model is that there are many different solutions, and every decision point leads to a more fragmented community. How many people out there run statsite+graphite+grafana+opsgenie? A good layered approach needs to fully isolate layers, so that any integration feature or problem is limited to pairings. Usually easy for features, but for bugs, it's almost definitionally impossible to prevent a problem in an earlier layer from causing symptoms or or two layers later.
tl;dr: I've been mostly learning about ETS (holtwinters) on the job, but would love to learn more about predicting customer traffic.
