How to optimize mysql table of 2 billions rows?
Use InnoDB.
Normalize entityType or turn it into an ENUM.
Change INT UNSIGNED (always 4 bytes) into a suitable sized int)
If the 3-column key is unique, then make it the PRIMARY KEY and toss id
id, if kept, will need to be BIGINT UNSIGNED -- you are getting too close to the 4 billion limit of INT UNSIGNED.
The optimal order for the index:  (entityId, entityType, timeStamp), or possibly (entityId, timeStamp)
Minimize the number of indexes on a DataWarehouse table.
For purging data after a year, DELETE will be painful.  Instead PARTITION BY RANGE and use months:  http://mysql.rjweb.org/doc.php/partitionmaint
If you get in trouble with the ingestion rate: http://mysql.rjweb.org/doc.php/staging_table
If you keep id, then do


this trick:

PRIMARY KEY (entityId, timeStamp, id)
INDEX(id)


This, together with InnoDB, makes the data for that SELECT mostly 'clustered', hence faster to fetch.

But the big fix to that query, and similar "report" queries in a Data Warehouse (which what you have), comes from building and maintaining Summary table(s):  http://mysql.rjweb.org/doc.php/summarytables

The summary table to support that would look something like:

CREATE TABLE summary (
    entityType VARCHAR... -- denormalized
    dy  -- timestamp truncated to the day
    entityId
    sumCount  -- SUM(entityCount); use SUM(sumCount) to get weekly total (etc)
    PRIMARY KEY(entityid, entityType, dy)


See the link for various ways to keep the summary table updated.

addenda

Munch on what I said.  Then think about how it splitting into multiple similar tables based on entityType.

One simplicity -- count is always "1" for some Types, so you don't need a count column (except in the Summary table for that Type).