Introduction

Welcome to a journey into the world of containers, where we will talk about Docker, virtual machines (VMs), Kubernetes and orchestration. If you have taken your seats, let’s get started.

At the center of everything are physical machines, i.e. tangible entities, that provide the computing resources to manifest our digital desires. Think of these as the solid ground on which our virtual efforts stand. What about virtual machines (VMs)? They are like digital twins of physical machines running on the hypervisor layer. Each VM creates its own share of CPU, memory and storage, replicating the functionality of an advanced machine.

I hope this article will be a guide to understanding its complexities and the mechanism behind it as we delve deeper into this journey.

Containers: The Game Changer

But here’s where things get interesting: containers. Think of them as these lightweight, portable packages that contain everything your application needs to run smoothly. Unlike VMs, which carry their own mini-operating systems, containers share the host operating system’s core, making them super-efficient.

Containers encapsulate not just your app, but also its dependencies, libraries, and settings. This means you can run your application anywhere without worrying about compatibility issues. It’s like having your lunch packed in a neat, spill-proof box that you can take with you wherever you go.

Containerization existed long before docker was invented. What Docker basically does is present this in a user-friendly API. Docker make it easy to use.

It is important to remember that containers are not physical entities, but rather virtualized environments that contain and run applications seamlessly. This virtualization offers unparalleled flexibility and efficiency, revolutionizing the software development, deployment and management landscape.

Docker is emerging as a major player taking containerization to new heights with its robust toolset. Docker streamlines the development workflow by empowering developers to effortlessly build, deploy, and manage containerized applications.

So let’s delve deeper into the world of Docker.

Docker and its Components

You may have heard of the classic “it works on my machine” scenario, where deployment issues arise due to inconsistent environments.

This is where Docker comes in, providing a solution by providing consistent and portable containers that facilitate deployment processes.

Picture this: Encapsulating your applications and dependencies into portable, self-contained units that can run seamlessly in any environment. This is Docker’s trick. It allows you to run your applications consistently without compatibility issue.

At its core, Docker consists of Dockerfiles, Docker Containers, and Docker Images. These components allow developers to effortlessly build, run, and manage containerized applications.

Docker’s platform isolates applications from the underlying system, allowing multiple applications to run on the same machine without conflict. It eliminates manual dependency installations and simplifies deployment processes, making it ideal for web development.

Virtual Machines vs. Containers

Now, let’s take a step back and compare virtual machines (VMs) with containers. It also helps you understand the concept and logic better.

A comparison between virtual machines (VMs) and containers reveals fundamental differences in architecture and functionality. While VMs emulate entire operating systems on a hypervisor layer, containers leverage the host operating system’s resources, resulting in lighter, more efficient deployments. Containers, with their faster startup times and lower resource consumption, offer a compelling alternative to the resource-intensive nature of VM.

This fundamental difference in architecture makes containers more lightweight and efficient compared to VMs. While VMs require significant overhead due to emulation of entire hardware environments, containers run more directly on the host system, resulting in faster startup times and lower resource consumption.

And containers are very fast, their creation are cheaper than VMs.

So, VMs and containers represent two different paradigms for deploying applications. VMs offer full isolation and compatibility but come with higher resource load. Containers, on the other hand, provide lightweight, portable environments that share resources with the host operating system, making them ideal for modern application deployment. Understanding these differences is crucial to navigating the modern software development environment.

Docker revolutionizes application deployment by providing self-sufficient containers that streamline the development, testing, and production processes. These containers, defined by configuration files, eliminate the “it works on my machine” dilemma, ensuring consistent performance from development to production.

Kubernetes: The Captain of Container Orchestration

Now, where does Kubernetes come into play? Think of Kubernetes as an orchestra conductor that aligns the various elements of your cloud infrastructure to work in sync. Just as an orchestra conductor directs musicians to produce a beautiful piece of music, Kubernetes coordinates containers, storage, scaling mechanisms, and network services to bring your application to life.

Kubernetes is just an orchestrator.

From a technical perspective, Kubernetes acts as a centralized management system, enabling seamless deployment, scaling and management of containerized applications.

Kubernetes consists of several components that work together to facilitate container orchestration. For example, the kubelet agent runs on each node in the Kubernetes cluster, ensuring that pods are created, scheduled, and maintained according to the desired state. The kube-proxy component enables network communication between pods and external services, while the kube-scheduler optimally distributes workloads among available nodes.

Without going too deep, let’s examine the two important components of Kubernetes and their functions.

Pods: Your Basic Building Blocks

Let’s talk about pods. Think of pods as your basic building blocks in the Kubernetes world. They’re like little bundles of joy that house one or more containers, kind of like roommates sharing an apartment.

Interestingly, the term “pod” is derived from the sci-fi concept of a space capsule, signifying its role in encapsulating containers.

So why are pods necessary? Well, imagine that you manage a video streaming service that requires both a media server and a caching system. Instead of running these elements separately in their own containers, Kubernetes says, “Let’s put them in the same pod!” This arrangement facilitates seamless communication between them, allowing seamless sharing of resources such as storage space.

So pods are not just random groupings; They are strategic clusters of containers that cooperate harmoniously. When you ask Kubernetes to deploy something, it’s usually about deploying pods, not individual containers. This is like saying to your friend, “Hey, let’s host a meeting at my house” instead of sending individual invitations to each guest.

Each pod in Kubernetes has a unique IP address; this allows direct communication between pods without the need to make each container available separately. This increases efficiency and security within the cluster.

The Kubelet — Agent of Kubernetes

You can think of Kubelet as an agent of Kubernetes. It acts as a tireless intermediary across all servers and all workers. It’s like having a multitasking assistant on each server that has the ability to adapt to different environments.

So what does the kubelet actually do? It’s like a nosy messenger constantly checking the Kubernetes API server. It’s always asking the question: “Hey, do I have a pod assigned to me? Is there something I need to take care of?”

This is where it gets interesting: Imagine the scheduler makes a decision and assigns a specific worker, let’s call it worker 1. Worker 1’s kubelet immediately jumps into action and checks the API server to see if there is a pod waiting for it. If there is, it’s like saying, “Okay, I’ll handle it. Let’s make it work here.”

So how does kubelet manage to run these containers? kubelet doesn’t actually know how to run containers. Docker, like Containerd and even Podman, is based on what we call Container Runtime. So, when it comes time to run a container, the kubelet instructs the runtime to do the job.

Kubelet is essentially the unsung hero of Kubernetes; It manages containers seamlessly and keeps your cluster running smoothly.

When we talk about Kubernetes components, there is actually a lot to tell such as Controller Manager, Schedular, etcd etc.. We can talk about the details of these in another article. For now, let’s continue our article.

Kubernetes simplifies container management by controlling the container lifecycle, scaling, and networking tasks. It automatically replaces faulty containers to maintain uninterrupted operation and allows external communication when necessary. In software deployment, Kubernetes ensures consistency and reliability across diverse environments, freeing developers from the complexity of infrastructure management so they can focus on defining the desired state of their applications.

Alternative tools for orchestration include Docker Swarm, Docker Compose, Mesos, Nomad, and OpenShift. Each has its own strengths and weaknesses that suit different use cases and needs.

Conclusion

In this dive into the world of containers, we took a bird’s eye journey through the fundamentals of modern software development. From the beginnings of containers as lightweight, portable packages that revolutionized application delivery, to the orchestration prowess of Kubernetes that seamlessly aligns cloud infrastructure components.

At the heart of modern computing infrastructure are physical hosts, which are tangible machines that provide computing resources. Virtual machines (VMs) abstract these physical resources, allowing multiple virtual instances to be run on a single physical host. Containers, on the other hand, encapsulate applications and their dependencies, allowing consistent deployment in different environments.

I hope your containers run smoothly, your pods thrive, and your orchestration is always solid. Until we meet again, happy containerization!🚀🐳

Exploring the World of Containers: Docker, Kubernetes and Beyond was originally published in DataPebbles on Medium, where people are continuing the conversation by highlighting and responding to this story.

Project Overview

I believe in learning by doing and prefer to dive into practical projects as soon as I grasp the basics. In this blog post, we’ll work on a simple project together to improve our AWS skills. Whether you’re new to AWS or aiming to enhance your data engineering expertise, this project is for you.

In a previous blog post, I shared an ETL script that extracted Spotify playlist data and stored it in SQLite. Now, we’ll modify this script to send data to an Amazon S3 bucket.

We can expand this project by using services such as AWS Lambda and RedShift later or in future sections. Let’s keep it simple for now. No need to jump into the hardest, most unresolved thing — at least not yet.

Feel free to check GitHub repository and blog post.

The key point here is when opening your AWS account and setting it up, go step by step, paying close attention to specific details like security and billing, which I’ll explain later.

Step-by-Step Guide: Uploading Data to AWS S3 Bucket with Boto 3

What is our Goal?

Our goal is to upload data extracted from the Spotify API into an Amazon S3 Bucket using Python and Boto3. We’ll start by setting up the AWS side and we’ll be integrating S3 functionality into our Spotify ETL Pipeline script.

Prerequisites:

Before diving into the project, ensure you have the following prerequisites:

• AWS Account
• Spotify API Credentials
• AWS Credentials

Our path will be as follows, this is the scenario I designed for this project. When designing your project, you should make a plan based on the most appropriate options for the problem and data at hand. Don’t forget to design it on paper first.

And, the rest is up to your imagination…

At the end of the day, if you complete everything correctly, when you execute the script, your data will be in S3 Bucket in the folder you specified.

So, Let’s Start…

To upload data to an Amazon S3 bucket, we’ll follow these steps:

1) Setting Up Your AWS Account

If you haven’t already, create an AWS account, making use of the free tier and credits. Enable billing alerts in AWS Billing and Cost Management to avoid unexpected charges.

Enable Multi-Factor Authentication (MFA) for your root account with a strong password.

For further guidance, refer to AWS Security Best Practices documentation. You can also explore articles and tutorials on topics like creating billing alerts and enhancing account security. Also check out : “Getting started: Are you a first-time AWS user?” guide from AWS documentation.

Once you’ve created a strong AWS account by following best practices, you’re free to play.

2) Create an IAM User for Admin Privileges

It’s time to create an IAM User with administrative features.

To begin, log in to your AWS root account and navigate to the IAM service. From the Users page in the left control panel, create a new user. You can name this user anything you prefer, such as “admin-user.” In this example, let’s call it “Merve.” Assign the “AdministratorAccess” policy to grant comprehensive administrative permissions.

In the image below, you’ll see the IAM User named “Merve” with admin privileges:

3) Creating an S3 Bucket

Before creating the bucket, we will create an IAM user with a policy only on a specific S3 bucket and specific actions that we specify.

I will follow these steps before creating an S3 Bucket:

1. Creating Customer Managed User Policy
2. Creating an IAM User and attach IAM User Policy

After, we will move on to the step of creating the S3 bucket from the S3 service.

# Creating Customer Managed User Policy

Before we start creating the S3 bucket, we will create an IAM User Policy that defines the exact access privileges for the specified bucket. This policy ensures that the IAM user to which it is attached has permissions only for specific actions related to the S3 bucket.

Later, you will generate Access Keys for this IAM user to send data to S3 from your code.

“ Customer managed policies — Managed policies that you create and manage in your AWS account. Customer managed policies provide more precise control over your policies than AWS managed policies.” — Policies and permissions in IAM

To create the User Policy:

From the AWS console, go to the IAM service. In the control panel on the left, click “Policies” and create a new policy. Although various services are accessible via search, I prefer the JSON file option to generate the policy.

Here is the custom user policy JSON file in specific bucket privileges:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [  
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListAllMyBuckets",
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "arn:aws:s3::: spotifydatabucket1",
                "arn:aws:s3::: spotifydatabucket1/*"
            ]
        }
    ]
}

Simply put, this policy restricts access to only the specified Bucket and defines the allowed actions. It can list other buckets, but there is no access to see object inside them. It also does not have permissions for other services such as IAM.

We called that policy “ single-bucket-access-spotify”

# Create an IAM User and attach IAM User Policy

By default IAM users have no permissions to do anything.

“ Use customer managed policies instead of inline policies. It’s also best to use customer managed policies instead of AWS managed policies. AWS managed policies usually provide broad administrative or read-only permissions. For greatest security, grant least privilege, which is granting only the permissions required to perform specific job tasks.” — link

To create an IAM User:

In the IAM service, navigate to the users page and click on the “create user” button. Choose a name for the IAM User, such as “test-user1” or whatever you want to call it, and configure additional settings as needed.

Next, select the “Add Policies Directly” option on the page that appears, then locate and select the “single-bucket-access-spotify” policy we previously created from the policy search section. Proceed by clicking the NEXT button.

As you continue, you will reach the final step where you can view your user information and password. This is your last chance to review and download this information.

When completed, the IAM user will be created with the privileges specified in the actions in the policy attached to it.

Finally, Creating an S3 Bucket

If you have followed the steps so far and successfully created your “test-user1” IAM user, congratulations! You can now proceed to create your S3 Bucket and populate it with the objects you want.

Begin by logging in with the IAM user “test-user1.” Navigate to the AWS console page and search for the S3 service. Click on the “create bucket” button. On the next page, provide a name for your bucket and specify your preferred region:

Once you’ve filled in the necessary information, proceed by confirming your settings. That’s it! Your S3 Bucket has been successfully created:

4) Creating Access Key for IAM User

Once you’ve successfully created your bucket “spotifydatabucket1”, it is time to create AWS credentials to upload data to our S3 Bucket from our Python script. Create an Access Key for the authorized IAM user for our S3 Bucket. Be sure to store this information securely for future use.

5) Coding Part with Python Boto3

I will talk about the function we added to the Spotify ETL Pipeline script to load data to S3. We interact with our S3 Bucket using the Boto3 library and I integrate the necessary operations into the code.

Boto3 acts as a powerful Python SDK for AWS, enabling seamless integration and automation of tasks such as managing resources and storing data in S3 buckets.

Function that uploads data to S3:

def upload_to_s3(df, key, folder_name='', aws_access_key=None, aws_secret_key=None, aws_region=None, aws_s3_bucket_name=None):
    try:
        csv_buffer = StringIO()
        df.to_csv(csv_buffer, index=False)

        if aws_access_key and aws_secret_key and aws_region and aws_s3_bucket_name:
            s3_client = boto3.client(
                service_name='s3',
                region_name=aws_region,
                aws_access_key_id=aws_access_key,
                aws_secret_access_key=aws_secret_key
            )


            full_key = f"{folder_name}/{key}" if folder_name else key
            s3_client.put_object(Body=csv_buffer.getvalue(), Bucket=aws_s3_bucket_name, Key=full_key)

            logging.info(f"Data successfully uploaded to AWS S3 with key: {full_key}")
        else:
            raise ValueError("AWS credentials are missing. Data not uploaded to AWS S3.")
    except botocore.exceptions.NoCredentialsError:
        logging.error("AWS credentials are incorrect or missing. Please check your AWS access key and secret key.",
                      exc_info=True)
    except botocore.exceptions.ParamValidationError:
        logging.error("Invalid parameter value. Please check your AWS region or S3 bucket name.", exc_info=True)
    except Exception as e:
        logging.error(f"An error occurred during data upload to AWS S3: {e}", exc_info=True)
    finally:
        csv_buffer.close()

def etl_pipeline():

  # ...
    aws_access_key = os.getenv('AWS_ACCESS_KEY')
    aws_secret_key = os.getenv('AWS_SECRET_KEY')
    aws_s3_bucket_name = os.getenv('AWS_S3_BUCKET_NAME')
    aws_region = os.getenv('AWS_REGION')

    if aws_access_key and aws_secret_key and aws_s3_bucket_name:
        # ETL Load to AWS S3
        upload_to_s3(user_df, 'user.csv', 'csv-files', aws_access_key, aws_secret_key, aws_region, aws_s3_bucket_name)
        upload_to_s3(playlist_df, 'playlist.csv', 'csv-files', aws_access_key, aws_secret_key, aws_region, aws_s3_bucket_name)
        upload_to_s3(track_df, 'track.csv', 'csv-files', aws_access_key, aws_secret_key, aws_region, aws_s3_bucket_name)
        upload_to_s3(album_df, 'album.csv', 'csv-files', aws_access_key, aws_secret_key, aws_region, aws_s3_bucket_name)
        upload_to_s3(artist_df, 'artist.csv', 'csv-files', aws_access_key, aws_secret_key, aws_region, aws_s3_bucket_name)

        logging.info("Data uploaded to AWS S3 successfully.")
  # ...      

This code snippet shows the “upload_to_s3” function where we convert the received data into a DataFrame and upload it as a .csv file to the S3 bucket in the folder we specify.

I’ve made the loading section of my ETL Pipeline optional. Now, by providing AWS parameters, you can choose to load your data directly into your S3 Bucket rather than using SQLite.

Let’s RUN the world !

If you have followed each step carefully and provided your parameters and credentials correctly, running the script will ensure that your data is uploaded to the specified Bucket without any problems.

Once you have all the necessary scripts, all you have to do is run “main.py” to load your data into the designated folder:

Now let’s check our AWS S3 Bucket:

As you can see, the files were successfully uploaded to our S3 bucket in .csv format in the exact folder that we wanted in our S3 Bucket.

It’s important to understand that the user we’ve granted privileges within the relevant S3 Bucket can only list other buckets and cannot view their contents. You have the flexibility to customize these settings to your specific needs using the JSON format policy when creating a Customer Managed Policy. Just do not forget grant least privilege.

In this scenario, I prefered for User Policies for S3 authorization, although Bucket Policy or IAM Role are alternative methods. If you’re interested in exploring these alternatives further, we can discuss them in a separate, more detailed article.

Summary

What did we do?

AWS part:

• Created a strong AWS account with a strong password and Multi-Factor Authentication (MFA).
• IAM user with admin privileges has been created and MFA enabled.
• Another IAM user is created that has restricted access only to the specified S3 Bucket.
• S3 bucket was created and attached with a user policy, allowing only the specified user to access the bucket.
• Access Key is created for the IAM user to upload data to the S3 bucket.

Coding part:

• Integrated a function into the Spotify ETL Pipeline Python script to upload data to the S3 bucket.
• The data was uploaded to the S3 Bucket after running the code with the S3 IAM user’s access key.

Final Thoughts

We covered basic topics such as AWS IAM users, policies, access key and S3 Bucket through a practice. By running a Python script, we successfully loaded the playlist data extracted from the Spotify API into AWS S3 Bucket in .csv format.

Through this practical project, I aimed to provide a basic understanding of AWS while offering a hands-on learning opportunity. I believe you gained basic experience with AWS services and perspective to improve your ETL skills.

Stay with science and art!

“Music is a moral law. It gives soul to the universe, wings to the mind, flight to the imagination, and charm and gaiety to life and to everything.” — Plato

Have you ever been curious about Spotify data? In this practice, we start on creating a simple yet powerful ETL (Extract, Transform, Load) pipeline using Python and SQLite3. Our primary goal is to raise our data engineering skills and build an simple ETL pipeline that opens the door of data-driven insights.

What does ETL mean?

Before diving deep into our project, let’s start a clear understanding of ETL. You may have encountered the term ETL before in the realms of data engineering, data science, and business intelligence. ETL stands for Extract, Transform, Load. It’s the process of taking data from one source, transforming it, and loading it into another source.

In a way, turning chaos into clarity, making data more structured and ready for analysis.

Okay, what is ETL process?

ETL Process

We’ll follow these stages:

1. Connect with the Spotify API: Connecting with Spotify API by fetching predefined data.
2. Creating a SQLite Database: Creating a SQLite database with a structured data schema compatible with the data we will extract.
3. Data Extract Transform and Load: Extracting, transforming and inserting the specified data from the relevant API endpoints into the created SQLite database.
4. Automation with Cron: Automate the entire ETL process using Cron on Linux, ensuring the pipeline runs at scheduled intervals for more efficient data processing.

The Process Behind the Project

In the coding part, first we create the SQLite database, connect to the Spotify API, and manage the ETL process. Our Python scripts cover the required functionality, from fetching user playlists and songs to transforming and loading data.

Before diving into the project, you need to have a spotify account and you should create your Spotify App.

Create a Spotify Developer Account

Begin your practice by visiting the Developer Dashboard and create a web app to obtain the client id and client secret. For more details, refer to the documentation.

API Interaction

To retrieve user, playlist and track data from Spotify, I use the SpotifyAPI class I defined in spotify_api.py. This class handles communication with the Spotify API, managing authentication and making GET requests.

The get_user_data and get_playlists methods are examples of how I retrieve user information and playlists respectively :

class SpotifyAPI:
    """A class for interacting with the Spotify API."""

    # ...

    def get_user_data(self):
        """Get user data for the specified user ID."""
        return self._authenticated_request(f"{self.USER_ENDPOINT}/{self.user_id}")

    def get_playlists(self):
        """Get playlists for the specified user ID."""
        return self._authenticated_request(f"{self.USER_ENDPOINT}/{self.user_id}/{self.PLAYLISTS_ENDPOINT}")["items"]

Creating SQLite Database

Database creation is orchestrated through the create_database function, ensuring a structured form for Spotify data.

Here, sample of create_db.py file:

def create_database(db_path='spotify_data.db'):
    try:
        with sqlite3.connect(db_path) as conn:
            cursor = conn.cursor()

            # Table Definitions (aligned for consistency)
            cursor.execute('''
                CREATE TABLE IF NOT EXISTS user (
                    id TEXT PRIMARY KEY,
                    name TEXT
                )
            ''')

            # ... 

            conn.commit()
            cursor.close()

    except sqlite3.Error as e:
        logging.error(f"Error creating database: {e}", exc_info=True)

Data Extraction

The extract_spotify_data function instantiates the Spotify API class, retrieves user, playlist and track data and processes the data.

def extract_spotify_data(client_id, client_secret, user_id):
    spotify_api = SpotifyAPI(client_id, client_secret, user_id)

    # Tables list:
    track_data = []
    artist_data = []
    album_data = []
    playlist_data = []

    # Get user data
    user_item = spotify_api.get_user_data()

    # Extract user_name from user_item
    user_name = user_item.get("display_name", "")  # Assuming display_name is available in user_data

    user_dict = {
        "user_name": user_name,
        "user_id": user_id
    }

    user_data = [user_dict]

    # Get playlists 
    playlist_item = spotify_api.get_playlists()

    if playlist_item:
        for item in playlist_item:
            # Playlist information
            playlist_id = item['id']
            playlist_name = item['name']

            playlist_dict = {
                "playlist_id": playlist_id,
                "user_id": user_id,
                "playlist_name": playlist_name
            }
            playlist_data.append(playlist_dict)

            # Get tracks for each playlist
            tracks_item = spotify_api.get_playlist_tracks(playlist_id)

            for i in tracks_item:
                track_id = i['track']['id']
                track_name = i['track']['name']
                artist_id = i["track"]["artists"][0].get("id")
                artist_name = i["track"]["artists"][0].get("name")
                album_id = i["track"]["album"].get("id")
                album_name = i["track"]["album"].get("name")

                track_dict = {
                    "track_id": track_id,
                    "playlist_id": playlist_id,
                    "artist_id": artist_id,
                    "album_id": album_id,
                    "track_name": track_name
                }

                artist_dict = {
                    "artist_id": artist_id,
                    "artist_name": artist_name
                }

                album_dict = {
                    "album_id": album_id,
                    "album_name": album_name
                }

                track_data.append(track_dict)
                artist_data.append(artist_dict)
                album_data.append(album_dict)

            # Log the number of tracks found for each playlist
            logging.info(f"Playlist {playlist_id} has {len(tracks_item)} tracks.")
    else:
        logging.info("No playlists found.")

    return user_data, playlist_data, track_data, album_data, artist_data

Transformation

After data extraction, I transformed data into Pandas DataFrames and rename the column names to match structure in the database by the transform_data function for better manipulation.

def transform_data(track_data, artist_data, album_data, playlist_data, user_data):
    track_df = pd.DataFrame(track_data).rename(
        columns={"track_id": "id", "playlist_id": "playlist_id", "artist_id": "artist_id", "album_id": "album_id",
                 "track_name": "name"})
    artist_df = pd.DataFrame(artist_data).rename(columns={"artist_id": "id", "artist_name": "name"})
    album_df = pd.DataFrame(album_data).rename(columns={"album_id": "id", "album_name": "name"})
    playlist_df = pd.DataFrame(playlist_data).rename(
        columns={"playlist_id": "id", "user_id": "user_id", "playlist_name": "name"})
    user_df = pd.DataFrame(user_data).rename(columns={"user_id": "id", "user_name": "name"})
    return user_df, playlist_df, track_df, album_df, artist_df

Validation

I’ve implemented a function to validate incoming data before it gets sent to the database. This function checks for duplicate entries in the DataFrames and removes them. Additionally, it issues a warning message if there are any missing data values.

You can improve this part according to the needs of your project.

def check_duplicates_and_missing_values(track_df, artist_df, album_df, playlist_df, user_df):
    for df, name in [(track_df, "track"), (artist_df, "artist"), (album_df, "album"), (playlist_df, "playlist"),
                     (user_df, "user")]:
        duplicate_entries = df[df.duplicated()]
        if not duplicate_entries.empty:
            logging.warning(f"Duplicate {name} found. Duplicates will be removed.")
            df.drop_duplicates(inplace=True)

        if df.isnull().values.any():
            logging.warning(f"Missing values found in {name} data. Please handle missing values appropriately.")

Loading

After successfully validating and transforming the data, the final step is loading it into SQLite database. I am setting up a connection to the database using the sqlite3 module and efficiently loading Pandas DataFrames into their corresponding tables.

def load_data_to_database(user_df, playlist_df, track_df, album_df, artist_df, db_path):
    try:
        conn = sqlite3.connect(db_path)
        user_df.to_sql('user', conn, if_exists='replace', index=False)
        playlist_df.to_sql('playlist', conn, if_exists='replace', index=False)
        track_df.to_sql('track', conn, if_exists='replace', index=False)
        album_df.to_sql('album', conn, if_exists='replace', index=False)
        artist_df.to_sql('artist', conn, if_exists='replace', index=False)
    except sqlite3.Error as e:
        logging.error(f"An error occurred during data insertion: {e}", exc_info=True)def load_data_to_database(user_df, playlist_df, track_df, album_df, artist_df, db_path):

    try:
        conn = sqlite3.connect(db_path)
        user_df.to_sql('user', conn, if_exists='replace', index=False)
        playlist_df.to_sql('playlist', conn, if_exists='replace', index=False)
        track_df.to_sql('track', conn, if_exists='replace', index=False)
        album_df.to_sql('album', conn, if_exists='replace', index=False)
        artist_df.to_sql('artist', conn, if_exists='replace', index=False)
    except sqlite3.Error as e:
        logging.error(f"An error occurred during data insertion: {e}", exc_info=True)

Putting It All Together: The ETL Pipeline

Now it’s time to connect the dots and make sense of it all. Consider the etl_pipeline function as our guide on this data process. That’s what ties everything together for data process.

This function below encapsulates the entire data process — from extracting raw Spotify data, transforming it into structured DataFrames, simple data validation, and loading of data into SQLite database.

def etl_pipeline():
    try:
        # ETL Extract
        client_id = os.getenv('SPOTIFY_CLIENT_ID')
        client_secret = os.getenv('SPOTIFY_CLIENT_SECRET')
        user_id = os.getenv('SPOTIFY_USER_ID')
        db_path = os.getenv('DB_PATH')

        user_data, playlist_data, track_data, album_data, artist_data = extract_spotify_data(client_id, client_secret,
                                                                                             user_id)

        # ETL Transform
        user_df, playlist_df, track_df, album_df, artist_df = transform_data(track_data, artist_data, album_data,
                                                                             playlist_data, user_data)

        # Perform data validation checks
        check_duplicates_and_missing_values(track_df, artist_df, album_df, playlist_df, user_df)

        # ETL Load
        load_data_to_database(user_df, playlist_df, track_df, album_df, artist_df, db_path)
        logging.info("ETL Pipeline completed successfully.")
    except Exception as e:
        logging.error(f"An error occurred during ETL Pipeline: {e}", exc_info=True)

Automation with Cron

Now, after making sure that ETL pipeline is running smoothly and ready, I automate it by scheduling the script at the interval I specify using Cron. I chose Cron because it is fast, reliable and easy to use.

Let’s say we want it to run every Friday at midnight, just add this line to your crontab:

0 23 * * 5  /usr/bin/python your_data_path/main.py >/dev/null 2>&1

This line in your crontab ensures that your script run every Friday at midnight.

There are many great and open-source tools you can use during the automation phase. You can look at these and choose the best tool for you according to your project and needs. For example, Airflow might be a good alternative for workflow scheduling in our case.

Conclusion:

The primary goal of this project is to provide a hands-on, practical guide on creating and automating a simple ETL pipeline, using Spotify data as an example. Thus, this project hopes to offer a practical way to improve your data engineering skills.

But the adventure doesn’t end there. Spotify data can be used for a variety of analytical purposes and provides valuable insight into user behavior, popular playlists and music tastes.

For enthusiasts looking to perform deeper analysis and develop ETL pipelines, Spotify’s Developer Web API opens the door to a variety of data. You can look here to discover more about the spotify data and feel free to access all the code on my GitHub repository.

Who knows, maybe the next project will be an exciting one that goes into data analysis and graphics?

While we almost all love creating playlists and discovering new tracks, the real magic happens when we can transform raw data into meaningful insights.

Stay with art and science! 🎵🚀

1. Introduction

Containerization has transformed application development, deployment, and management, and Red Hat OpenShift Container Platform (OCP) stands as a reliable and flexible solution for these tasks. Whether you’re new to containers or looking to level up your skills, this blog post will be your beginner’s guide to OCP.

What is Red Hat OpenShift Container Platform?
Red Hat OpenShift Container Platform simplifies the building, deploying, and managing of containerized applications. It is a Kubernetes-based platform that provides a scalable and secure environment for effective collaboration between developers and operations teams.

So, What is the difference between OCP and Kubernetes or even Docker Swarm?

OpenShift Container Platform (OCP) distinguishes itself from Kubernetes and Docker Swarm with its comprehensive feature set and enterprise-grade support. While Kubernetes is an open-source platform focused on managing containerized applications, OCP builds upon Kubernetes, offering additional tools, enhanced management capabilities, and a user-friendly web console. Docker Swarm, on the other hand, is a lightweight orchestration solution provided by Docker.

2. Getting Started with Red Hat OpenShift Container Platform

To begin your OCP journey, it’s important to set up your development environment and grasp the core concepts. Follow this step-by-step guide:

Install OpenShift Tools: Download and install the OpenShift command-line tools (oc) specific to your operating system. Follow the installation instructions provided by Red Hat to ensure a successful setup.

You can check → Getting started with the OpenShift CLI

Access a Cluster: Determine whether you will be working with a local or remote OpenShift cluster. If setting up a local development environment, consider using tools like Minishift or CodeReady Containers. Alternatively, obtain access to a remote cluster provided by your organization or a cloud provider.

Create a Project: Use the oc command-line tool to create a project that will serve as a logical container for your applications. This allows for better organization and management of your workloads within the OpenShift environment. You can also create a project directly through the web console provided by OpenShift. You can choose the method that suits your preference and workflow — whether it’s using the oc command-line tool or the web console.

While the web interface for OpenShift is user-friendly and convenient, I believe it is valuable to invest time in mastering the CLI commands.

Although the interface provides ease of use, in my opinion, learning the CLI commands enables automation, scripting, and integration with other tools, granting greater control and efficiency in managing your OpenShift environment. =)

Deploy Your Application: Prepare your application artifacts, such as Docker images or source code, and use the oc command-line tool to deploy them to the project you created. Follow the appropriate deployment approach based on your application’s requirements, whether it involves source-to-image (S2I) or using pre-built container images.

• S2I Approach: You provide your application’s source code along with a builder image that contains the necessary build dependencies and instructions. OpenShift will then automatically build a container image from your source code and the builder image. This process streamlines the build and deployment workflow, simplifying the application lifecycle management.
• Pre-Built Container Images: You can deploy your application using pre-built container images. These images are ready-to-use and typically obtained from container registries such as Red Hat Quay, Docker Hub, or private repositories. You can select the appropriate pre-built image that matches your application’s requirements, pulling it into your project and deploying it directly.

Check documentation: Understanding containers, images, and image streams

Key Concepts: Familiarize yourself with essential concepts in OpenShift Container Platform. Understand pods, learn about services, explore routes and finally, understand deployments. These resources are the Core Concepts of OCP.

— Pods: Pods are the smallest units of deployment in OpenShift, representing running containers.
 — Services: Services enable communication between pods and provide a stable network endpoint.
 — Routes: Routes expose your application to external traffic and enable access from outside the cluster.
 — Deployments: Deployments provide control over scaling and updating your application as needed, allowing for seamless updates without downtime.

For more on Core Concepts just click.

Explore Web Console: Access the web console, a graphical user interface provided by OpenShift, through your preferred web browser.

The OpenShift web console is a user-friendly graphical interface that allows you to visually manage and monitor applications. With features such as health monitoring, resource management, scaling options, and log access, the web console streamlines application management tasks and enhances control within the OpenShift environment.

For more detailed information on documentation OpenShift Container Platform 4.13, I highly recommend visiting the official documentation here.

— I will plan to share a detailed and hands-on blog post for this section in the future.

3. Building and Deploying Applications in OpenShift Container Platform

Once you have established a foundation, it’s time to dive deeper into application development and deployment in OCP.

Building and deploying applications in Red Hat OpenShift Container Platform involves several key steps that enable efficient development and seamless deployment.

One crucial aspect is creating container images for your applications. This can be achieved by utilizing existing images from container registries or building custom images using Dockerfiles. For instance, suppose you have a web application written in Node.js. In that case, you can create a container image that incorporates the necessary dependencies, configurations, and your application code.

Once you have your container image, you can leverage OpenShift’s build configurations to automate the build process. This includes defining triggers, specifying build strategies, and connecting to source code repositories. For instance, you can set up a build configuration that triggers a new build whenever changes are pushed to your Git repository.

Deployment configurations in OpenShift allow you to define the desired state of your application. You can specify the number of replicas and configure deployment strategies like rolling updates, ensuring smooth application updates without downtime. In our example, you can define a deployment configuration that ensures three replicas of your Node.js web application are always running.

To handle varying traffic and demand, OpenShift provides scaling and resource management capabilities. You can configure auto-scaling based on metrics like CPU or memory usage. As your web application gains popularity and draws in more visitors, OpenShift springs into action with seamless efficiency, effortlessly spawning additional replicas to gracefully handle the increased load. So, whether it’s a sudden surge or a gradual climb, OpenShift ensures your application stays responsive and performs at its best, without breaking a sweat.

OpenShift’s monitoring and logging features are vital for effective application management. By tracking resource utilization, performance metrics, and log data, you can swiftly identify and resolve any issues. For instance, if your application experiences increased resource consumption, OpenShift’s monitoring and logging capabilities help you pinpoint the root cause and take necessary measures to ensure smooth operation.

Lastly, integrating OpenShift with CI/CD tools like Jenkins or GitLab enables continuous integration and delivery. You can automate the entire software delivery pipeline, including building, testing, and deploying applications. For example, you can configure OpenShift to automatically trigger a build and deployment whenever changes are pushed to your Git repository.

By following these steps, you can efficiently build and deploy applications in Red Hat OpenShift, enabling seamless development and ensuring scalability and reliability for your applications.

Useful Article: How to deploy a web service on OpenShift

4. Key Features of OpenShift Container Platform

Kubernetes Superpowers: OCP harnesses the immense power of Kubernetes, relieving you of scaling and load balancing headaches. You can trust OCP to handle it all with ease.

Developer Delight: OCP understands developers’ needs and speaks their language. Its user-friendly interface and command-line tools make you feel like a coding wizard. Plus, it’s got tricks like source-to-image (S2I) up its sleeve, turning your source code into container magic.

CI/CD Integration: OpenShift’s CI/CD integration streamlines the software delivery process by seamlessly integrating with popular CI/CD tools. With automated workflows and optimized pipelines, you can accelerate your software releases and achieve greater efficiency in your development lifecycle. Say goodbye to manual tasks and hello to automated superhero speed.

Scalability: When your application experiences a sudden surge in traffic, OCP steps up its game. Through automatic scaling and load balancing, OCP ensures that your apps can handle the increased load without breaking a sweat. Your users will be delighted as your applications continue to perform flawlessly, effortlessly adapting to the growing demand.

Security Shield: Protecting your applications is OCP’s top priority. With built-in security features like role-based access control (RBAC) and secure container registries, it’s like having a bulletproof shield for your code.

Insights in a Flash: OCP grants you superhero vision into your app’s performance. Monitor and analyze metrics like a pro, effortlessly troubleshoot issues, and save the day when things go awry. It’s like having a built-in crystal ball!

So far, I’ve discussed the positive aspects of Red Hat OpenShift Container Platform. Now, let’s consider some of the potential drawbacks or considerations to provide a more balanced perspective. Here are a few points to keep in mind:

5. Considerations and Potential Drawbacks of OCP

Learning Curve: OpenShift can be complex, especially for beginners, requiring time and effort to understand its advanced features.

Resource Requirements: Running OpenShift requires substantial hardware and operational resources, adding complexity and costs.

License Costs: OCP is not free and requires a subscription, which may be a consideration for organizations on a tight budget.

Upgrades and Compatibility: Upgrading to newer versions can be challenging and may have compatibility issues with existing applications.

Vendor Lock-In: Choosing OCP ties you to the Red Hat ecosystem, limiting long-term flexibility.

Customization and Flexibility: OpenShift may have limitations when it comes to specific customizations or unique requirements.

Community and Third-Party Ecosystem: The third-party ecosystem for OpenShift may be less extensive compared to other platforms, affecting the availability of specific integrations or tools.

6. Conclusion

Red Hat OpenShift Container Platform offers a comprehensive solution for containerized application development and management. It provides a user-friendly interface, robust features, and a supportive community. However, it’s important to carefully consider the potential challenges discussed earlier before making a decision. By evaluating the pros and cons, individuals and organizations can determine if OpenShift is the right fit for their needs.

Whether you’re a beginner or an experienced professional, exploring OpenShift can open up exciting possibilities in the world of containerization. Feel free to visit the Red Hat Developer website to learn more and dive deeper into the possibilities of OpenShift.

Thank you for taking the time to read this article! I hope you found it helpful and gained valuable insights from it.

You can always reach me on linkedln and twitter.

Stay with science and art!

Merhabalar,

Daha önce konuyu teorik olarak ele almıştık. Bu bölümde Zaman Serileri Tahmin Yöntemlerini Python üzerinden uygulamalı olarak aktarmaya çalışacağım.

Serinin birinci ve ikinci bölümlerini okumak isterseniz;

Zaman Serileri Analizi — 1 ve Zaman Serileri Analizi — 2

Çalışma için kullanacağımız veriler Türkiye’nin 2017–2022 yılları arasındaki elektrik tüketim verileridir ve EPİAŞ ŞEFFAFLIK PLATFORMU sitesinden çekilmiştir.

Öncelikle, gerekli kütüphanelerin ve veri setinin içeri aktarılması ile başlıyoruz. Veri setine genel bir bakış, kolon isimlerinin düzenlenmesi ve tip dönüşümlerini yapıyoruz. Bu düzenlemeleri yaptıktan sonra saatlik frekanstaki veriyi günlük frekansa çektim.

Bu aşamaları bu yazıya dahil etmiyorum, eğer detayları görmek isterseniz kodun tamamına buradan erişebilirsiniz.

Veri setimizi düzenledik ve saatlik verileri günlük frekansa getirdik. Şimdi veri setimizin ilk beş elemanına bir göz atalım:

data_daily = df.set_index("Tarih").asfreq('D')
data_daily.head()

Zaman Serisi verileriyle çalışacağımız için “Tarih” kolonunu da indeks olarak veriyoruz.

Daha sonra veri setinde eksik ve yinelenen (duplike) değer var mı diye kontrol edeceğiz. Bu aşamada veri setinde eksik değer bulunmamıştır fakat 3 adet duplike kayıt tespit edilmiş ve veri setinden çıkarılmıştır.

Verileri Çizgi Grafiği Üzerinde Görelim:

plt.figure(figsize=(22,4))
sns.lineplot(data = data_daily.reset_index(), x="Tarih", y="Tuketim")

Zaman Serisi Bileşenleri :

data_monthly = df.set_index("Tarih").asfreq('M')

plt.rcParams['figure.figsize'] = [20,7]
decomposition = sm.tsa.seasonal_decompose(data_monthly)
fig = decomposition.plot()
plt.show()

Görsellerden anlayabileceğimiz üzere, elektrik tüketim verilerinin özellikle 2020 yılından sonra genel bir pozitif eğilime ve mevsimselliğe sahip olduğunu söyleyebiliriz.

Elektrik tüketim değerleri yaz aylarında zirve ve sonbaharda keskin bir düşüş yapar, ardından kış mevsimine kadar hafif bir artış olur ve bahar mevsimi boyunca yavaş yavaş azalır.

Verilerin hem trend hem de mevsimselliğe sahip olması verilerin durağan olmadığı anlamına gelir.

ACF ve PACF Grafikleri:

Zaman serileri analizinde verilerin otokorelasyon ve kısmı otokorelasyon grafiğinin incelenmesi önemli bir adımdır. Model terimlerinin sayısını belirlemek için Otokorelasyon fonksiyonu (ACF) ve kısmi otokorelasyon fonksiyonu (PACF) grafiklerinden yararlanacağız. Aynı zamanda bu grafiklere bakarak serinin durağanlığı hakkında çıkarımlar yapabildiğimizi öğrenmiştik. Serinin diğer yazılarında bu konulardan detaylıca bahsediyorum.

fig, (ax1, ax2) = plt.subplots(1, 2,figsize=(20,5), dpi= 70)

plot_acf(data_daily.Tuketim.tolist(), ax=ax1, lags=48)
plot_pacf(data_daily.Tuketim.tolist(), ax=ax2, lags=48, method="ywm")

plt.show()

Verilerin çizgi grafiği, zaman serileri bileşenleri ve ACF-PACF grafiğinden yola çıkarak serinin durağan olmadığını söyleyebiliriz.

Yaptığımız gözlemleri doğrulamak için Dickey-Fuller ve KPSS hipotez testlerini kullanacağız:

Durağanlık Analizi

1- Augmented Dickey-Fuller Testi

• Sıfır Hipotez H0 : Seri Durağan Değildir
• Alternati Hipotez H1 : Seri Durağandır (Birim Kök Yoktur)

2- Kwiatkowski-Phillips-Schmidt-Shin Testi

• Sıfır Hipotez H0 : Seri Durağandır (Birim Kök Yoktur)
• Alternati Hipotez H1: Seri durağan değildir

# ADF Testi:

def adf(data):
    adf_test = sm.tsa.adfuller(data, autolag='AIC')
    print(f'ADF Statistic: {adf_test[0]}')
    print(f'p-value: {adf_test[1]}')
    print("Seri Durağan Değildir") if adf_test[1] > 0.05 else print("Seri Durağandır(Birim Kök Yoktur)")

# KPSS Testi:

def kpss(data):
    kpss_test = sm.tsa.kpss(data)
    print('KPSS Statistic: %f' % kpss_test[0])
    print('p-value: %f' % kpss_test[1])
    print("Seri Durağandır") if kpss_test[1] > 0.05 else print("Seri durağan değildir(Seri Birim Kök İçerir)")

adf(data_daily)
kpss(data_daily)

ADF Statistic: -3.721
p-value: 0.003
Seri Durağandır(Birim Kök Yoktur)

KPSS Statistic: 2.007
p-value: 0.010
Seri durağan değildir(Seri Birim Kök İçerir)

Sonuçların farklı gelmesi güzel oldu çünkü önemli bir noktaya değineceğiz. Eğer ADF testi bir birim kök bulamazsa, ancak KPSS testi bulursa, seri fark-durağandır. Yine de fark almanız gerekir. Testlerden biri bile birim kökün varlığına işaret ediyorsa, seri durağandır diyemeyiz.

Serinin durağan olmadığına emin olduktan sonra fark yöntemi ile serinin birinci dereceden farkını alarak serinin durağan hale gelip gelmediğini test edelim:

data_daily_diff = data_daily.copy()
data_daily_diff['Tuketim'] = data_daily['Tuketim'] - data_daily['Tuketim'].shift(1)
data_daily_diff = data_daily_diff.dropna()

fig, (ax1, ax2) = plt.subplots(1, 2,figsize=(20,5), dpi= 70)

plot_acf(data_daily_diff.Tuketim.tolist(), ax=ax1, lags=48)
plot_pacf(data_daily_diff.Tuketim.tolist(), ax=ax2, lags=48, method="ywm")
plt.show()

adf(data_daily_diff)
kpss(data_daily_diff)

ADF Statistic: -11.067
p-value: 4.649e-20
Seri Durağandır(Birim Kök Yoktur)

KPSS Statistic: 0.049
p-value: 0.100
Seri Durağandır

Serimiz artık durağan hale gelmiş olsa bile hala ACF grafiğinde dalgalanmalar yani mevsimselliğin olduğunu ve gecikme sayılarının tekrarlarını incelediğimiz zaman periyodun 7 olduğunu tespit edebiliyoruz. Ayrıca PACF’deki 7. gecikmenin de sınırlar dışında kaldığını görüyoruz.

Periyot 7 olarak belirledikten sonra birinci dereceden mevsimsel fark alıyoruz:

data_daily_diff2 = data_daily_diff.diff(7).dropna()

fig, (ax1, ax2) = plt.subplots(1, 2,figsize=(20,5), dpi= 70)

plot_acf(data_daily_diff2.Tuketim.tolist(), ax=ax1, lags=48)
plot_pacf(data_daily_diff2.Tuketim.tolist(), ax=ax2, lags=48)
plt.show()

Böylece serimizi trend ve mevsimsel etkiden arındırmayı başardık.

Modelleme aşamasına geçmeden önce, yaptığımız analizler doğrultusunda model parametrelerini manuel olarak belirleyemeye çalışalım.

Hem trend hem mevsimsel fark alınarak durağan hale geldiği için d = 1 ve D = 1 şeklinde tanımlayacağız.

ACF grafiğinde 1,2 ve 7'de önemli bir gecikme vardır. Bu nedenle MA(q) parametresi 2 ve mevsimsel MA(Q) parametresi 1 olabilir.

PACF grafiğinde ise 1,2 ve 7,14,21’de önemli bir gecikme vardır. AR(p) parametresi 2 olabilir. Mevsimsel AR(P) parametresinin ise aslında bu durumda 0 alınması tavsiye ediliyor.

Bazı kaynaklarda, mevsimsel gecikmedeki otokorelasyon negatifse, modele mevsimsel MA(Q) terimi eklenip mevsimsel AR(P) teriminin atlanması yani 0 alınması öneriliyor. Fakat yapmış olduğum denemelerde AR(P)=1 almak daha düşük hata oranı ve yüksek R Kare değeri verdiği için biz burada AR(P) terimini 1 olarak alacağız.

Buradan yola çıkarak;

ARIMA(2,1,2) ve SARIMA(2,1,2)x(1,1,1,7) olacak şekilde notasyonumuzu oluşturuyoruz.

Model parametrelerini belirlemenin (autoarima, gridsearch gibi) ve test etmenin başka yolları vardır. Biz bu çalışmada manuel olarak belirlediğimiz parametreleri kullanacağız ve herhangi bir model iyileştirmesi yapmayacağız.

Şimdilik amacım, ileri düzey bir elektrik tüketim tahmini yapmaktan ziyade zaman serileri tahmin yöntemlerini basit şekilde Python ile nasıl uygulamaya dökeriz göstermeye çalışmak.

Modelleme ve Tahmin

1 Ocak 2017 - 31 Temmuz 2022 eğitim seti, 1 Ağustos 2022 - 31 Ağustos 2022 ise test seti olacak şekilde ayırıyoruz. Her model için aynı aralıkta bir tahminleme işlemi yapacağız sonrasında sonuçları test setindeki gerçek değerler ile karşılaştıracağız.

ARIMA

ARIMA(2,1,2) modelini statsmodels paketini kullanarak oluşturalım ve belirlediğimiz aralık için bir tahminleme gerçekleştirelim. Ardından gerçek değerler ile tahmin edilen değerleri bir görsel üzerinde gösterelim.

Verileri eğitim ve test seti olarak ikiye ayırıyoruz:

train_data = data_daily[:'2022-07-31']
test_data = data_daily['2022-08-01':'2022-08-31']
pred_df = test_data.copy()

# ARIMA (2,1,2)

arima_model = sm.tsa.arima.ARIMA(np.asarray(train_data),order=(2,1,2))
arima_model_fit = arima_model.fit()
arima_pred = arima_model_fit.forecast(len(test_data),disp=False)

pred_df["arima_pred"] = arima_pred.round(2)
plt.figure(figsize=(22,4))
sns.lineplot(data = pred_df[['Tuketim', 'arima_pred']])

ARIMA modeli grafikten anlayacağımız üzere pek iyi çalışmadı çünkü verilerimiz mevsimsellik içeriyor ve ARIMA tarafından iyi tahmin edilemiyor. Bu tür durumlarda daha önceki yazımda bahsettiğim gibi SARIMA modeli daha iyi çalışacaktır.

Şimdi aynı tahmin işlemini SARIMA üzerinde gerçekleştirelim.

SARIMA

SARIMA (2,1,2) (1,1,1,7)

# SARIMA (2,1,2) (1,1,1,7)

sarima_model = SARIMAX(np.asarray(train_data), order=(2, 1, 2), seasonal_order=(1,1,1,7))
sarima_model_fit = sarima_model.fit()
sarima_pred = sarima_model_fit.forecast(len(test_data))

pred_df["sarima_pred"] = sarima_pred.round(2)
plt.figure(figsize=(22,4))
sns.lineplot(data = pred_df[['Tuketim', 'sarima_pred']])

SARIMA modelinin ARIMA modelinden daha iyi sonuç verdiğini grafikten gözlemleyebiliyoruz.

Son olarak Prophet ile bir tahminleme yapalım ve sonuçları değerlendirelim:

PROPHET

Burada Prophet algoritması girdi olarak “ds” ve “y” değişkenleriyle çalıştığı için eğitim ve test setimizi buna göre ayarlıyoruz:

# PROPHET

prophet_df = data_daily.reset_index()
prophet_df.columns = ["ds","y"]

train_data_prophet = prophet_df[prophet_df['ds'] < '2022-08-01']
test_data_prophet = prophet_df[(prophet_df['ds'] >= '2022-08-01') & (prophet_df['ds'] <= '2022-08-31')]

prophet_model = Prophet()
prophet_model.fit(train_data_prophet)
model_predict = prophet_model.predict(test_data_prophet)

pred_df["prophet_yhat"] = model_predict["yhat"].values.round(2)
pred_df["prophet_yhat_lower"] = model_predict["yhat_lower"].values.round(2)
pred_df["prophet_yhat_upper"] = model_predict["yhat_upper"].values.round(2)

plt.figure(figsize=(22,4))
sns.lineplot(data = pred_df[['Tuketim', 'prophet_yhat']])

yhat, yhat_lower ve yhat_upper değerlerini içeren grafik :

Modeli değerlendirmek için MAPE, RMSE ve R2 metriklerini kullanacağız:

R2 (Coefficient of Determination) : R Kare, belirleme katsayısıdır. Verilerin fit edilen model tarafından ne kadar iyi açıklandığının bir ölçüsüdür yani bağımlı değişkendeki değişkenliğin ne kadarının model tarafından açıklanabileceğini ölçer ve 0 ile 1 arasında bir değer aldığı varsayılır fakat R Kare negatif değerler de alabilir. R Kare değeri 1'e yaklaştıkça güçlü bir korelasyon var ve algoritmamız iyi, 0'a yaklaştıkça modelimiz ortalamaya yaklaşır ve ilişki azalır.

RMSE (Root Mean Squared Error): Kök Ortalama Kare Hata, MSE yani Hata Kareler Ortalamasının kareköküdür. Hata Kareler Ortalaması, tahmin edilen değer ile gerçek değer arasındaki farkların karelerinin ortalamasını temsil eder.

MAPE (Mean Absolute Percentage Error) : Ortalama Mutlak Yüzde Hata, tahminlerin mutlak yüzde hatalarının ortalamasıdır.

Bizim örneğimizde ARIMA modelinin R Kare değeri -0.042 gibi negatif bir değer çıkmıştır. Bu da demek oluyor ki model gerçekten de verilerimiz için uygun değil.

İlgili dönem aralığındaki model performans sonuçlarında SARIMA modeli en düşük RMSE ve MAPE değerine sahip olmakla birlikte R Kare skoru 0,66'dır ve bu, modellerimiz arasında en yüksek puandır.

Sonuçlar aslında şaşırılacak şekilde iyi görünüyor? Rastgele bir doğrulama dönemi seçerek bir dizi tek adımlı tahmin yaptık. Bu oluşturulan modellerin, geleceğe yönelik birçok dönemi doğru bir şekilde tahminleyeceği anlamına gelmez. Yani etkili bir zaman serisi modelini bulmak ve doğrulamak aslında bu kadar basit değil.

Burada çok temel şekilde modellerimizi oluşturduk ve hiperparametre ayarlamalarını yapmadık. Ayrıca daha gerçekçi bir senaryoda aslında verilerinizi üç farklı veri kümesi şeklinde ayırmanız iyi bir pratiktir. Güvenilir bir model oluşturmak istiyorsanız veri kümenizi eğitim, validasyon ve test şeklinde ayırmanız gerekir.

SARIMA ve Prophet modellerinin geliştirilmesi ve hata oranlarının düşürülmesi için doğru şekilde veri setinin ayrıştırılması, parametre optimizasyonu, anlamlı bağımsız değişkenlerin modele eklenmesi, tatil günlerinin ayrıştırılması gibi yapabileceğiniz birçok şey vardır.

Çalışma üzerinde kendiniz birtakım denemeler yaparsanız, mesela eğitim ve test seti dönemlerini değiştirmek gibi, o zaman sonuçların aslında ne kadar yanıltıcı olabileceğini görebilirsiniz. Bu çalışmanın, kendinizin bazı içgörüleri oluşturabilmesi adına size bir başlangıç noktası verebileceğini düşünüyorum.

Gelecek zamanlarda bu temel modellerin ötesine giderek elektrik tüketim tahminlemesi çalışmamızı derinleştireceğiz.

Bana her zaman linkedln ve twitter üzerinden ulaşabilirsiniz.

Bilim ve Sanatla Kalın !

Zaman Serileri Tahmin Yöntemleri— ARIMA, SARIMA & Facebook Prophet

Bir önceki bölümde zaman serilerine genel bir giriş yaparak önemli temel kavramlardan bahsettim. Bu bölümde ARIMA ve SARIMA modellerini anlatmaya çalışacağım. Daha sonra Facebook Prophet’e kısa bir giriş yaparak yazıyı sonlandıracağım.

Serinin ilk bölümünü merak edenler için : Zaman Serileri Analizi — 1

Box-Jenkins yöntemine geçmeden önce AR, MA ve ARMA modelleriyle alakalı kısa bir bilgi vermek gerekirse, temelde AR ve MA, doğrusal durağan stokastik ARMA modelinin özel bir halidir ve bu modeller durağan olan zaman serilerinin analizinde kullanılır. Gerçek dünya verileri çoğunlukla durağan değildir. Bu durumda eğer seri (mesela farkı alınarak) durağan hale getirilebiliyorsa, ARIMA gibi yöntemler uygulanabilir.

NOT: Eğer ACF ve PACF’deki anlamlı korelasyonlar birden fazla ise duruma göre ARMA ya da ARIMA modelinin kullanılması daha doğru olacaktır.

ARIMA (AutoRegressive Integrated Moving Average)

Box-Jenkins yöntemlerinden biri olan ARIMA(Otoregresif Entegre Hareketli Ortalama) modeli, zaman serileri analizinde kullanılan istatistiksel analiz yöntemlerinden biridir. Yeteri kadar örneklem varsa kısa dönem tahminlerde başarılı olabilir.

ARIMA terimini üçe ayırabiliriz:

AR(p) : Autoregression/Otoregresif — tahmin denklemindeki değişkenlerin gecikmeleri göstermektedir

I(d): Integrated/Entegre — durağanlığa ulaşmak için fark alma işlemini gerçekleştirdiğimiz sırayı veren fark derecesini göstermektedir

MA(q) : Moving Average/Hareketli Ortalama — tahmin hatalarının gecikmeleri göstermektedir

p : modele dahil edilen gecikmelerin sayısı

d : farklılaşma derecesi

q : hareketli ortalama penceresinin sayısı

Notasyonu şu şekildedir : ARIMA (p,d,q)

Bir ARIMA modeli oluştururken p,q ve d parametrelerini belirlememiz gerekiyor. Peki bu parametreleri neye göre seçeceğiz?

Zaman serisini, farkını alarak durağan hale getirdikten sonra (d=1), p ve q parametrelerini belirlemek için genel kabul görmüş tek bir yöntem olmamakla birlikte otokorelasyon fonksiyonu (ACF) ve kısmi otokorelasyon fonksiyonu (PACF) grafiklerine bakarak, AR ve MA terimlerinin sayısını belirleyebiliriz. Aynı zamanda bu grafiklere bakarak serinin trend ve mevsimsellik içerip içermediği hakkında da yorumlar yapabiliriz.

ACF grafiği, serinin kendisi ile gecikmeleri arasındaki korelasyon katsayılarının bir çubuk grafiğidir. PACF grafiği ise, 2 gecikmeli değer arasındaki gecikmeleri veren ve diğer gecikmelerin önemli olmadığı bir çubuk grafiktir. Genellikle AR terimi için PACF, MA terimi için ACF grafiğine bakılmaktadır. AR ve MA düzeyini belirlerken, güven sınırının dışında kalan otokorelasyon sayısına bakılmaktadır.

Ne demek istediğimi bir örnek üzerinden giderek anlamaya çalışalım:

Yukarıdaki grafikler, günlük frekansta oluşturulan bir zaman serisi verilerinin ACF ve PACF grafiklerini göstermektedir. Serinin durağan olmadığı ilk bakışta gözümüze çarpıyor. İlk dört gecikme güven sınırları dışında olduğu için trend içerdiğini söyleyebiliriz. Ayrıca 7 günde bir gecikmeler zirve yapmış görünüyor.

Bu bilgiler ışığında veri setinin hem trend hem mevsimsellik etkisinde olduğunu söyleyebiliriz.

Serinin durağan olmadığına emin olmak için bir de ADF ve KPSS testleri yapıldığında gelen sonuçlar şu şekildedir :

ADF Statistic: -2.8507122243484138
p-value: 0.051387040622567326
Seri Durağan değil

KPSS Test Statistics: 0.22902758041889848
p-value: 0.01
Seri Durağan değil

Serinin durağan olmadığına ikna olduğumuza göre yolumuza seriyi durağan hale getirerek devam ediyoruz.

Logaritmik dönüşüm, trend ekleme, box-cox dönüşümü gibi farklı durağanlaştırma teknikleri olmakla birlikte biz burada fark alarak durağanlaştırma yöntemini kullanacağız.

Yukarıdaki grafikler, serinin farkı alındıktan sonra oluşturulan ACF ve PACF grafiklerini göstermektedir. Seri durağan hale gelmiş gibi görünüyor fakat sizin de bir şey dikkatinizi çekmiyor mu?

Dikkat etmemiz noktaya değinmeden önce gelin bir de ADF ve KPSS testi yaparak serinin durağan hale gelip gelmediğinden emin olalım :

ADF Statistic: -11.517895214887874
p-value: 4.1073890331024725e-21
Seri Durağan

KPSS Test Statistics: 0.018849922085689242
p-value: 0.1
Seri Durağan

Tamam seriyi durağan hale getirmeyi başardık. Peki, yukarıdaki grafiklerde hala bazı gecikmelerde bir ilişki olduğu görülmektedir. Bunun sebebi serinin mevsimsellik barındırmasıdır. İlk başta tespit ettiğimiz şekilde, zirveler her 7 günde bir olmaktadır. Yani periyodumuzun 7 olduğunu söyleyebiliriz. Bu bilgi de bizi mevsimsel ARIMA yani SARIMA modelinin serimiz için daha uygun olabileceği bilgisine götürüyor.

DİKKAT! DİKKAT! :)

Serinin birinci farkını alarak yaptığımız durağanlaştırma işlemi seriyi trend etkisinden arındırarak durağan hale gelmesini sağladı. Burda yaptığımız işlem mevsimsel olmayan fark alma işlemidir. Yalnız seri hala mevsimselliğin etkisindedir. Bu durumda kuracağınız ARIMA modeli muhtemelen iyi performans göstermeyecektir.

Peki ne yapabiliriz?

Serinin bir de mevsimsel farkını almamız gerekmektedir. Az önce de bahsettiğim gibi mevsimsellik içeren serilere uygun bir model olan SARIMA modelini kullanabiliriz.

SARIMA (Seasonal AutoRegressive Integrated Moving Average)

Bir diğer Box-Jenkins yöntemi, Mevsimsel eğilimleri modelleyebilmemizi sağlayan SARIMA(Mevsimsel Otoregresif Entegre Hareketli Ortalama) modeli, ARIMA modelinin uyarlanmış bir versiyonudur diyebiliriz.

SARIMA modeli, ARIMA modelindeki mevsimsel olmayan bileşenlere (p,d,q) ek olarak, mevsimsel bileşenlere (P,D,Q,s) sahiptir. Mevsimsel bileşenler sırasıyla; otoregresif sırasını, fark sırasını ve hareketli ortalama sırasını ve periyot sayısını temsil eder.

Notasyonu şu şekildedir : SARIMA (p,d,q) (P,D,Q)s

Bu da temelde modelin mevsimsel hareketleri algılayarak daha iyi öngörü yapmasını sağlıyor.

Mevsimsellikten kurtulmak için ACF grafiğinden daha önce belirlediğimiz periyot sayısını baz alarak serinin mevsimsel farkını alıyoruz:

ACF grafiğinden anlaşılacağı üzere mevsimsellik etkisini ortadan kaldırmayı başardık.

ADF Statistic: -18.372774147759294
p-value: 2.2166111743407356e-30
Seri Durağan

KPSS Test Statistics: 0.010250802628270732
p-value: 0.1
Seri Durağan

Serimizdeki trend ve mevsimsellik etkisini ortadan kaldırarak serinin durağan hale geldiğini tespit ettik. Bu analizler sonucunda bir model yapısı kurmaya çalışalım:

ARIMA ve SARIMA sürecindeki analizlerden yola çıkarak modelimizi oluşturuyoruz: SARIMA (2,1,1) (0,1,1)7

Hem trend hem mevsimsel fark alınarak durağan hale gelen bir seri olduğunu tespit etmiştik( d = 1 ve D = 1). PACF grafiğinde ilk iki gecikmenin önemli olması AR(2) süreci olabileceğini düşündürmektedir. MA terimi için birden fazla gecikme önemli gibi durmaktadır. Burada yaklaşık bir çıkarım yapmak zor olduğu için şimdilik ilk modelimizdeki MA sürecini MA(1) olarak tanımladım. Mevsimsel AR(P) için PACF grafiğine baktığımız zaman ilgili gecikmelerde tekrar eden bir durum söz konusu olduğu için P = 0, Mevsimsel MA(Q) için tek bir gecikme olması Q=1 sürecine karar vermeme neden oldu.

Seçilen parametreleri model sonuçlarındaki anlamlılık düzeylerine göre değiştirebilir veya çıkartabilirsiniz.

Model parametrelerini belirlemenin başka yolları da vardır. Bunlardan biri “grid search” yapmaktır. Kabaca sistemin çalışma mantığı, birtakım istatistiksel testler yaparak modelinize en uyumlu parametreleri döndürmesidir. Bu pratik bir yöntemdir fakat öncesinde gerekli analizlerin yapılarak zaman serisinin çözümlenmesi oldukça faydalı olabilir.

Burada temel mantığı aktarmak adına, ACF-PACF grafiklerini inceleyerek manuel olarak bir parametre seçimi yapmayı göstermek istedim.

Facebook Prophet

Geleneksel zaman serileri analiz yöntemlerini kullanarak başarılı sonuçlar elde etmek uzmanlık gerektirir ve zaman alıcıdır. Özellikle model oluşturma aşamasında parametrelerin seçilmesi ve ayarlanması oldukça zordur. Ve bazen tüm denemelere rağmen tatmin edici sonuçlar elde edilemeyebilir.

Ayrıca “Ben bu alanda bilgi sahibi değilim ya da benim zamanım kısıtlı tüm bu analiz ve çözümlerle vakit kaybetmek istemiyorum ama zaman serileriyle de çalışmak istiyorum” diyebilirsiniz.

Facebook bu noktada, 2017'de, zaman serileri analizi hakkında herkesin rahatlıkla kullanabileceği hızlı, güçlü ve kolay bir şekilde tek değişkenli zaman serisi modellemesi sağlayan, Python ve R’da uygulanabilir, açık kaynak kodlu bir kütüphane olan Prophet’i geliştirdi.

Prophet, trend, mevsimsellik ve tatiller olmak üzere üç ana model bileşene sahiptir:

g(t): parçalı doğrusal veya lojistik büyüme eğrisi

s(t): mevsimsellik

h(t): tatiller

εt: hata terimi

Prophet kabaca, zamanın doğrusal ve doğrusal olmayan fonksiyonlarını otomatik bir şekilde bileşen olarak modele fit etmeye yani uydurmaya çalışır. Prophet, serinin içerisinde bulunan trendleri otomatik olarak bizim için tespit eder. Daha sonra fit edilen modeli kullanarak geleceğe yönelik tahmin işlemleri gerçekleştiririz.

FB Prophet’e özet bir giriş yapmış olduk. Daha sonra uygulamalı olarak anlatmaya devam edeceğim FB Prophet konusunu şimdilik burada bitiriyorum.

Bir sonraki yazımda, Zaman Serileri Analizi — 1 ve bu bölümde anlattıklarımı Python ile pratiğe dökeceğiz. Aynı zamanda FB Prophet konusuna uygulamalı olarak kaldığımız yerden devam etmiş olacağız.

Vakit ayırdığınız için teşekkürler…

Bana her zaman linkedin ve twitter üzerinden ulaşabilirsiniz.

Bilim ve Sanatla Kalın !

Zaman Serileri Analizi — 2 was originally published in Machine Learning Turkiye on Medium, where people are continuing the conversation by highlighting and responding to this story.

Zaman Serisi Nedir?

Zaman Serisi verileri kısaca eşit zaman aralıklarında elde edilen ve kronolojik bir zaman sırasında tutulan verilerdir. Zaman serisi verileri hemen hemen her yerdedir, çünkü zaman gözlenebilen her şeyin bir parçasıdır. Ekonomik göstergeler, hava durumu, sensör verileri ve tıklamalar zaman serisi verilerine örnektir.

Yüzyıllar boyunca insanlık geleceği bilmek istedi ve bir zaman sonra bu istek aynı zamanda zorunlu bir hale geldi. Bir gözlemin bugünkü ve geçmiş değerlerine bakarak, gelecekte alacağı değerlerin tespit edilmeye çalışılması geleceği tahminleme işidir. Bunu yapabilmenin en iyi yollarından birisi zaman serisi analizleridir.

Zaman serisi analizinin birden fazla alanda farklı kullanım durumları vardır. Elektrik tüketim tahmini, örüntü tanıma, sinyal işleme, deprem tahmini, aykırı değerlerin yakalandığı anomali tespiti gibi birçok yerde kullanılır.

Aşağıdaki grafik bir zaman serisinin grafiksel gösterimine örnek olması açısından EPİAŞ üzerinden çektiğim ve günlük frekansta oluşturduğum 2017–2021 Türkiye’nin Elektrik Tüketim verilerini temsil etmektedir:

Zaman Serisi Bileşenleri

Zaman serileri dört bileşene ayrılabilir:

Trend — Verilerin yukarı ya da aşağı yönlü olarak uzun vadede sergiledikleri harekete trend denir.

Mevsimsellik — Bir dönem boyunca tekrar eden belirli bir kalıbı tanımlar. Periyodik olarak tekrar eden bir örüntü sergiler.

Gürültü — Kalıntılar veya düzensizlikler olarak da bilinir. Trend ve mevsimsellik etkisi ortadan kaldırıldıktan sonra geriye kalan şey kalıntılardır. Öngörülemeyen kısa vadeli dalgalanma şeklinde de özetlenebilir.

Konjonktürel Dalgalanmalar — Bir yıldan fazla süren, uzunluğu sabit kalmayan ve genellikle ekonomik koşulların etkisinden dolayı birçok değişkende görülen dalgalanmalardır.

Bu incelemelerin yapılmasındaki esas amaç zaman serisi verilerindeki desenleri ortaya çıkarıp, bir sonraki bölümde göreceğimiz model seçimi aşamasında bu örüntüleri doğru şekilde kavrayabilecek bir model seçimi yaparken bize yol gösterecek olmalarıdır.

Zaman serisi analizi temelde belirli bir değişkenin zamanla nasıl değiştiğini görmek istediğimiz zaman bize ışık tutacak bir yöntemdir.

İki tür zaman serisi modeli vardır:

• Tek değişkenli zaman serisi: Bir zamana bağlı değişkeni ve tek bir bağımsız değişkeni olan zaman serisi.
• Çok Değişkenli Zaman Serileri: Bir zamana bağlı değişken ve birden fazla bağımsız değişken içeren zaman serileri.

Dikkat edilmesi gereken noktalardan bir diğeri ise serinin deterministik veya stokastik özelliklerinin incelenmesidir.

Sabit bir kat sayı, mevsimsellik ve trend deterministik özelliklerken, stokastik özellik değişkenin durağanlığı ile ilgilidir.

Hmm… Durağanlık mı…

Durağanlık ve Durağan-Dışılık Nedir?

Bir serinin geçmiş değerlerine bakarak geleceğe yönelik tahminler yapmaktan söz ediyorduk. Bunu doğru bir şekilde yapabilmemiz için elimizdeki serinin “durağan” olmasını bekliyoruz.

Peki tam olarak bir seriye durağan diyebilmemiz için ne olması gerekiyor?

Zaman içinde belirli bir değere doğru yaklaşan yani sabit ortalama, sabit varyans ve sabit otokorelasyon yapısına sahip olan seriler durağan serilerdir. Bu tanımlamalardan herhangi birini sağlamayan bir zaman serisi durağan-dışı olarak tanımlanır.

Zaman serileri genellikle durağan değildir. Bu seriler birinci veya ikinci farkları ya da logaritmaları alınarak durağan hale getirilmektedir.

Zaman serileri çözümlemesinde serilerin durağan olması neden önemlidir?

Çünkü bir seri eğer durağan değilse farklı örüntüler sergiler. Bu durumda serinin davranışı diğer dönemlere genellenemez ve geleceği tahmin etmek için faydalı olmaz. İşte bu yüzden elimizdeki bir zaman serisinin durağan olup olmadığını bilmek isteriz.

Gelin hep beraber bir serinin durağan olup olmadığını nasıl tespit edebileceğimizi görelim.

Durağanlık Sınamaları Nasıl Yapılır ?

Durağanlık sınaması için çeşitli yöntemler vardır. Bunlar arasından en yaygın kullanılan ADF, Phillipps-Perron, KPSS birim kök testlerinden ve Korelogram grafiğinden bahsedeceğim:

1-Birim Kök Testleri

• Genişletilmiş Dickey-Fuller Testi (ADF) :

Sıfır hipotezi : Zaman serisinin durağan-dışı (birim kök içerir)

Alternatif Hipotez: Zaman serisinin durağan (birim kök içermez)

T-test üzerinden hesaplanan değer ADF Testi için hesaplanmış olan kritik değerlerden küçükse sıfır hipotezi reddedilir ve bu serinin durağan olduğu anlamına gelir. Eğer sıfır hipotezini reddetmekte başarısız olunursa seri birim kök içerir yani durağan-dışı deriz.

• Phillipps-Perron Testi

Zaman serilerinde bir diğer birim kök sınaması için kullanılan test Phillipps-Perron testidir. ADF’den farklı olarak t-test istatistiğine parametrik olmayan bir düzeltme yapar. Böylelikle otokorelasyonlar ve değişen varyans durumlarında daha düzgün sonuçlar üretir.

• KPSS

ADF testi gibi, KPSS testi de bir serinin durağanlığını analiz etmek için yaygın olarak kullanılmaktadır. KPSS testi için sıfır ve alternatif hipotez, ADF testinin tersidir.

2- Otokorelasyon (ACF)

ACF grafiği, verilerin zaman grafiğine bakmanın yanı sıra, durağan olmayan zaman serilerini belirlemek için de kullanışlıdır.

ACF durağan olmayan bir zaman serisi için yavaşça düşer. Mesela çok yüksek bir değerden başlayıp sıfıra doğru çok yavaş düşmesi. Durağan bir zaman serisi içinse otokorelasyon fonksiyonu hızla sıfıra yaklaşır.

Aşağıdaki ilk grafik durağan olmayan bir serinin ACF grafiğini göstermekte olup, ikinci grafik aynı serinin birinci farkı alınıp durağan hale getirildikten sonra çizilen ACF grafiğini temsil etmektedir :

Özetle,

Yukarıdaki durağanlık sınama yöntemlerinden sadece bir tanesinin kullanılmasından ziyade hem grafiksel hem de parametrik yöntemlerin birlikte kullanılması seri hakkında daha doğru çıkarımlar yapılmasını sağlayacaktır.

Özellikle istatistiksel bir alanda çalışma yapıyorsanız, tek bir teste bağlı kalmak bazen sizi büyük bir yanılgıya doğru sürükleyebilir.

Buraya kadar zaman serisi hakkında fazla detaya ve istatistiksel ispatlara girmeden önemli temel kavramlardan bahsettim. Gelecek bölümde Box-Jenkis Modelleri ve Facebook Prophet üzerinde duracağız…

Vakit ayırdığınız için teşekkürler…

Bana her zaman linkedin ve twitter üzerinden ulaşabilirsiniz.

Bilim ve Sanatla Kalın !

Zaman Serileri Analizi — 1 was originally published in Machine Learning Turkiye on Medium, where people are continuing the conversation by highlighting and responding to this story.