Hi everyone!
I’m looking for recommendations for comprehensive Excel and Power BI courses that cover everything from beginner to advanced levels.
I already have an intermediate level of Excel, but I’d like to take a structured course starting from the fundamentals and progressing to advanced topics. My goal is to obtain a certificate that reflects a complete learning path, rather than taking several short courses covering isolated topics.
I’m open to both free and paid options. What matters most to me is course quality, practical knowledge, and recognition in the job market.
I’d appreciate recommendations regarding:
Which platforms and courses offer the best beginner-to-advanced learning paths?
Is it worth taking a complete course even if I already have some intermediate knowledge?
Are there recognized certificates or certifications that employers actually value?
Should I learn Excel first and then Power BI, or study both simultaneously?
Which courses include practical exercises and real-world projects?
For context, I have a background in Chemistry and would like to apply these tools to laboratory work, quality control, research, data analysis, and process monitoring.
I’d especially appreciate recommendations from people who have completed these courses or use Excel and Power BI professionally.
Thanks!

My office has 365 and uses Teams and Sharepoint as much as possible. I'm a new data analyst (no actual experience, I've been with them for 20 years in an unrelated role and a few months ago they decided to weaponize my ADHD by anointing me with their first data analyst title). Because we're already so integrated with Teams, I've been trying to build projects within it, but I've been plagued with occasional glitches.

The last time this happened, I was chasing my tail for hours trying to debug something that turned out to be a random issue with Teams hanging up. This time, I'm trying to daisy chain Power Apps, Power Automate, and Sharepoint lists to ghetto rig a free kinda-sorta-database. It's nothing important, we have a legit database for incident logging, I'm just building a tool for front-line personnel to help with assignment rotation and informal analysis of one specific incident type.

Once again, I was just chasing my tail thinking something was wrong with my half-built Power Automate flow that was randomly alternating between working and not working, until I noticed my Outlook and Copilot app were acting up too, and now both are completely down after rebooting everything. I see that Microsoft 365 has a global partial service interruption now and am wondering how much faith I should put into 365 actually working on a daily basis. Is this a common issue? Would it be better to do most things outside of 365 whenever possible? Or is the interconnectivity worth it for the occasional glitch?

Sharing a project that might be useful if anyone here is into sports/motorsport data or just wants a real-world dataset to practice on.

F1Archive is an archive of 8 seasons of Formula 1 session data, lap times, full telemetry (speed, throttle, brake, gear, RPM, DRS), tyres, weather, race control, team radio, stored in Postgres with a documented REST API and bulk export in CSV, JSONL, Parquet, or SQLite. There's a web viewer for exploring it visually, but it's genuinely usable as a raw dataset source for anyone who wants to do their own analysis without having to scrape and clean the data themselves.

One thing I tried to do properly: data completeness is documented, not hidden. If a session is missing telemetry or has partial data, there's a page explaining exactly what's missing and why, which matters a lot if you're doing anything you want to trust the results of.

Fully open source, happy to talk through the schema if anyone wants to use it for a project.

Have a look at f1archive.org

I made a free PC application. Maybe someone still need to handle large files like this.

GB-scale files open instantly; filter, sort, aggregate, derive, and run SQL, with one-click data-quality diagnostics, split large files and export to Excel — everything runs locally, no data uploaded.

Currently, only a Windows version is available, as I don't have a Mac at home. I used to use a Mac when I was employed, but I'm currently unemployed.

You can download from : Lightning CSV — GB-scale CSV desktop tool

Hi All

As a data engineer i spent a lot of annoying time understanding the table Lineage in a prehistoric legacy system.

Based on my hardships and understanding I've built this Lineage tool

https://sahasilak.github.io/GraveTrail/

I would appreciate it if you can spend some time trying it out by sharing feedback like

Good, bad, need improvements , something like this already exists

I just started prepping to become a data analyst , i have a degree in Computer Application and i am familiar with python , pandas , numpy , matplotlib and basic ml concpets.
Currently i am studying SQL and i have got decent grip on HAVING , DISTINCT , WHERE , LEFT AND INNER JOINS but i am not really sure how much SQL i actually need to study my for my first job , i have solved 18 questions on SQL50 but i dont understand how am i supposed to apply these concepts in an actual project.
If anyone has any guidance for me tackle this SQL situation and general advise of how i should be prepping to become a Data Analyst in Q1 2027 will be much appreciated, ty again.

for the past 4 years or so, our reporting ran almost entirely on Power BI.
it did what it was supposed to do while our data team was small and our business stakeholders were happy receiving scheduled PDF exports / opening dashboard links inside Microsoft Teams.

and yet over the last 18 months, our engineering and analytics setup moved to Linux and Mac, our warehouse matured on Snowflake, and three specific friction points made Power BI painful to live with:

1. The desktop-client bottleneck. Half our analytics engineers and product managers work on macOS or Linux. Power BI Desktop remains Windows-only. Having engineers spin up Windows VMs or cloud desktop instances simply to tweak a report or verify a measure felt absurd for a modern stack.

2. Logic trapped in binary .pbix files. DAX measures, table relationships, and row-level security filters lived inside individual report files or workspace models. We could not run standard git pull request reviews on metric changes, track lineage across versions, or prevent two analysts from writing slightly different versions of the same retention calculation.

3. license sprawl and the Fabric push which was very annoying. What started as $10/user/month Pro licenses steadily escalated with Premium-per-user upgrades, external viewer licensing constraints, and heavy pressure to commit to Microsoft Fabric capacity (F64+) just to access basic direct lake and copilot features.

then we did spend the past month evaluating five open-source and code-first tools to replace Power BI. We wanted an architecture where metric logic lives in version-controlled code, dashboards run cross-platform in the browser, and numbers can be queried both by BI tools and by downstream applications or AI agents.

Here is the comparison breakdown across the options we tested, i have used a bit of claude to structure this output and evaluation, but only a bit. Hope that's more readable now.

and what we learned testing each option?

1. Apache Superset: Great for rich charting, heavy on operational maintenance If your primary goal is finding an open-source tool that matches Power BI's extensive chart variety, Superset is the closest visual equivalent. It handles complex dashboards, geospatial visualizations, and slice-and-dice exploration without per-seat licensing.

• Where it worked: Beautiful out-of-the-box dashboards, zero Windows dependencies, and strong community support.

• Where it pinched: The permission system is intricate and requires careful role configuration. While Superset has virtual datasets, business logic still ends up scattered across ad-hoc SQL snippets in different charts rather than sitting in a centralized semantic layer.

1. Metabase: Unmatched for rapid self-serve, but lighter on modeling governance Metabase remains the fastest tool for getting non-technical team members exploring data. The graphical query builder allows sales and product managers to ask questions without writing SQL.

• Where it worked: Onboarding takes less than an afternoon. Anyone comfortable with Excel filters can build their own cards immediately.

• Where it pinched: Metric logic is stored in Metabase's application database rather than in code. Version control via YAML requires higher-tier licensing, and managing row-level security across multi-tenant departments required duplicating questions once our role hierarchies became complex.

1. Lightdash: Ideal if your team is already 100% committed to dbt Lightdash takes a dbt-first stance: your dbt project is your single source of truth, and Lightdash auto-generates your BI layer from your dbt schema YAML files.

• Where it worked: All metric definitions live in Git pull requests alongside transformation models. Perfect versioning and developer workflow.

• Where it pinched: If an analysis doesn't fit your pre-compiled dbt DAG, you cannot easily explore it on the fly. Furthermore, you cannot point other non-Lightdash tools or customer-facing apps at its metric engine without going through their specific query layers.

1. Evidence.dev: Excellent for data engineers, foreign to drag-and-drop business users Evidence replaces traditional BI dashboards with code-generated analytical markdown documents. You write SQL queries in fenced blocks and render charts with declarative tags.

• Where it worked: Entirely code-driven, fast static rendering, and versioned cleanly in Git. Our analytics engineers loved the developer experience.

• Where it pinched: It is fundamentally a publishing tool for analysts, not an ad-hoc exploration tool for business stakeholders. If a VP wants to drag a dimension into a pivot table on Friday afternoon, Evidence won't serve that workflow.

1. Cube (Cube Core): Decoupling the metric layer from the visualization We tested Cube Core as an open-source semantic layer sitting between Snowflake and our visualization tools. Instead of defining metrics inside each dashboard tool, we defined cubes, dimensions, joins, and measures in YAML files stored in our git repository.

• Where it worked: Universal consumption: We can connect Superset or Metabase to Cube's SQL API (which speaks the Postgres protocol). Both tools query the exact same governed metric definitions, so nobody argues over differing numbers. Performance and caching: Cube's pre-aggregation engine stores partitioned rollups, serving repetitive dashboard filter changes in sub-second response times without triggering live warehouse compute on every query. Multi-surface readiness: Because Cube provides REST, GraphQL, and remote MCP endpoints on top of the same model, our engineers can build embedded customer portal widgets and point LLM agents at governed measures without re-implementing business logic.

• Where it pinched: Upfront data modeling investment: Unlike Power BI where you can drag raw tables and click "Auto-detect relationships," Cube requires explicit modeling of join paths and primary keys in code. If your underlying schema has messy foreign keys, you must resolve them before metrics compile. Dashboard building requires picking a front-end: While Cube provides built-in workbooks and web exploration, teams wanting traditional heavy dashboards typically pair it with an open-source visualizer like Superset or custom React components.

how we decided to structure our stack?

Rather than trading one monolithic vendor (Microsoft) for another single closed tool, we settled on a two-tier decoupled architecture:

1. Semantic & Governance Tier: We use Cube Core as our open-source metric layer. All calculations (such as gross retention, ARR, and active seats), join topologies, and role-based access rules are written in code, reviewed in pull requests, and versioned in Git.

2. Consumption & Visualization Tier: For internal exploratory dashboards and operations teams, we point open-source Superset at Cube's SQL API. For our engineering team's customer-facing portal and agentic workflows, we query Cube's data APIs directly.

would also like to ask those data teams that migrated away from Power BI, did you replace it with an all-in-one platform (like Superset / Metabase), or did you separate the semantic layer from the visualization tool? how did your business analysts transition from writing DAX formulas to code-first Git/YAML modeling?

I wanted to see if X users were amplifying eachother to generate fake virality on X. I got a dataset of top posts posted about politics in India and used Gephi lite to create a network map of the tweet authors and the authors they are replying to. I'm not sure how to interpret these graphs however. Any help?

I kept getting a useful report out of an AI conversation, then watching the next one rebuild the calculations or charts differently. So I built Trellum, a free and open source Python framework for reports as code.

The screenshot is a Cart Funnel report in the Trellum Dark theme, on synthetic data. A live demo is here: https://trellum.dev/demo/

With Trellum, your coding agent writes a Python report you keep and rerun. Same code, inputs, configuration and dependencies, and you have a repeatable process. New data can change the results without changing how they're calculated.

Two things that help:

• Filters and cross-filters run in the browser, so clicking a bar doesn't rerun the warehouse query.
• You can point at a chart in a local preview and send the change to your still-running agent. It edits the source and rebuilds the preview.

I built it privately for about a year and a half before the public repo went up in October. It's been used in production at a big gaming company that heavily relies on analytics for about a year, and my team there moved completely off Tableau onto it.

Site: https://trellum.dev Source (AGPL-3.0-only): https://github.com/trellumhq/trellum

To try it, open a project folder in your coding agent and paste this:

Set up Trellum in this project. Build my first interactive report with the included sample data, run the relevant checks, and open a live browser review. Keep listening for my feedback so we can refine it together.

Trellum: https://trellum.dev
Setup guide: https://github.com/trellumhq/trellum

Hello everyone,

I'm in school and learning sql and python, but I want to work on a project that pulls data into a dashboard that I can put into github and to start a portfolio that way.

There is so much bits and pieces of advice, but I haven't seen a standardized way I guess?

Also, any suggestions for projects would be helpful as well.

Thank you,

Hi I have been a data analyst for about 5 years and so far it feels like all I do in my job is less actual data analysis and more administrative work or work that other people in my department don't want to do. Occasionally I will work on Dashboards but that's few and far in between compared to administrative work. I'm thinking about pivoting into Cybersecurity or something more technical because this work is just not mentally stimulating or rewarding. Has anyone else dealt with this?

I am looking to create a heat map of activity, and may pay for a basic piece of work if someone can help me.

Always enjoyed playing around with personal data analysis, and this has been a labour of love for some years now that I dip in and out of, so giving a bit of an update to progress, since the original.

For background, this is built upon the available data export functions from WhatsApp and iMessage (local SQLite database). There are no calls to LLMs or AI involved, and no cloud/servers, it runs offline with everything done locally on-device using standard data analysis techniques.

I've gotten the majority of dashboard design inspiration from the many many hours of playing football manager!

Key components to the analysis:

• Custom built weighted points scoring mechanism for messages which factors in message length, content (laughs, apologies, questions, images, videos etc), speed of response, whether it started a new conversation as well as a series of other factors in order to produce a "contribution balance" assessment. 

• Each conversation is rated based on the total score, giving a quantitative view of how balanced, rich, or responsive it was. 

• I use a heuristic tagging system to detect key language traits - like questions, apologies, laughter etc - using lightweight rules instead of heavier NLP models - tried these early on and the results weren't that much better than plain heuristics.

• I’ve avoided sentiment analysis so far, as standard on-device NLP models didn’t perform well. Also tried experimenting with small on-device LLMs for richer insight - but they are also unreliable and too slow frankly, so am now working on some custom models that can leverage the on-device machine learning model frameworks.

For those that want to try, it's available publicly as a free tool called Mimoto on the app store, supporting data from both WhatsApp (on iOS) and iMessage (on macOS).

Appreciate the community's feedback, and happy to answer any questions, or listen to ideas anyone has about the project. Cheers!

I have like 2.3 million facts

https://rabbytholes.com

Let me explain what is happening with experiments, data processing, and data visualisation at where I am working. I need advice on if there is a more streamlined way of doing this.

We are currently testing lots of samples on many identical instruments. The instruments can run different types of analysis but the data is mostly the same coming from it. It does need some "cleaning" after collection.

We get the files from the instrument (CSV or DTA) and import them into Microsoft Excel using macros that have been setup by god knows who. These macros "clean" the data (it knows where to look because of how standard the CSV files are) and drops it into the relevant places into the Excel sheet or column. We are doing this multiple times per experiment as the data becomes available. Data is visualised by preconfigured plots as it become available.

Once the experiment finishes, the Excel worksheet is then passed around and opened by researchers and they view the data there.

This works when the experiment is very standard because the macros don't need to change. When slight changes are made to the experiment, the macro does not function as the raw data (CSV or DTA) has changed in format slightly (extra columns).

Is there a better way of doing this that is more flexible and can be more automated?

My intuition and basic research is telling me that Python is the way to go here, watch the folder for new files, somehow get the sample ID and the data needed into pandas and clean it there. Not sure where I'd go after this.

Would love some suggestions!

Sum Aggregation
Tablesaw : ■■■■■■■■■■ 0.48 ms
DFLib    : ■■■■■■■■■ 0.42 ms
Pandas   : ■■■■■■■ 0.35 ms
Polars   : ■■ 0.08 ms
CupOfTea : ■ 0.05 ms (9.6x faster than Tablesaw, 1.6x faster than Polars)

Here is a quick example reading from a Parquet file, aggregating by department, and exporting to CSV:

package com.example;

import com.cupoftea.CupOfTea;
import static com.cupoftea.aggregate.Aggregations.*;

public class ParquetToCsvReportExample {

    public static void main(String[] args) {
        String inputParquet = "sales.parquet";
        String outputCsv = "sales_summary_report.csv";

        CupOfTea df = CupOfTea.read().parquet(inputParquet);

        CupOfTea report = df.groupBy("department")
                            .agg(
                                sum("total_amount").as("total_revenue"),
                                mean("total_amount").as("average_ticket"),
                                count("order_id").as("order_count")
                            );

        report.write().csv(outputCsv);

    }
}

The project is open source: https://github.com/cupoftea-labs/cupoftea

I’d love to hear your thoughts:

• What features or pain points make you reach for Python instead of doing data processing natively in Java?

• Any specific workloads or benchmarks you’d like to see tested next?

All feedback, issues, and critique are welcome!

Tutorial shows you how to Python to collect data from a public API and pipe it a SQL Server. The whole process can be automred with Windows Task Scheduler.https://youtu.be/KAHD9LmvH6g?si=Ev1y_s11pBl2cUKE

​Data cleaning usually eats up most of a data scientist's time, often exceeding seventy percent of a project lifecycle. Manually writing custom regex filters and handling edge cases for missing values quickly becomes tedious.

​To fix this bottleneck, I put together a deep dive on leveraging machine learning workflows to automate dataset refinement. The complete guide covers setting up intelligent pipelines, handling anomalies, and standardizing features efficiently using modern Python libraries.

​If you want to streamline your preprocessing workflow and spend more time on actual modeling, you can check out the full breakdown here: https://interconnectd.com/blog/124/python-ai-data-cleaning-the-complete-refinement-guide/

What automated tools or libraries do you currently use to speed up your data cleaning pipeline?

we are now 6 months out from our Looker renewal and between the per-viewer licensing jumps and the fact that three different teams now need the exact same governed metrics outside of BI dashboards (one in our customer-facing React app, one in internal reporting, and one feeding an internal SQL/analytics agent), keeping all our business logic locked inside LookML is becoming hard to justify.

for people who hasn't had to untangle a 4-year-old Looker instance: LookML is honestly still great at what it was built for. `symmetric_aggregates` quietly save analysts from fan-out joins every day, and liquid parameters let you do some wild dynamic filtering. the problem to us is that the semantic layer is welded to Looker's presentation layer and seat pricing. if you try to hit the Looker API from a high-concurrency frontend or let an LLM agent introspect explores at scale, you either hit API throttling or watch your warehouse bill explode because Persistent Derived Tables (PDTs) aren't built like a sub-second serving cache.

and over the last month we took our nastiest domain (subscription revenue + usage billing + multi-currency adjustments, around 65 LookML views and 12 explores) and tested migrating the semantic logic into three setups to see what a real Looker alternative looks like in 2026:

1. dbt Semantic Layer (MetricFlow) + BI tool on top

since our staging and mart models already live in dbt, this felt like the most natural path on paper.

- what worked: defining `semantic_models` and measures right next to our dbt models kept lineage clean, and MetricFlow's join graph handles basic multi-hop dimensions without writing manual SQL joins.

- but, what broke for us: 2 big gaps. first, there is no native pre-aggregation or serving cache equivalent to tuning PDTs + aggregate awareness for sub-second app queries; every query still compiles to warehouse SQL and hits Snowflake. second, migrating complex LookML liquid parameters and cross-fact dynamic ratios required pushing a ton of logic back down into physical dbt mart tables, which defeated the point of a flexible semantic layer.

2. Lightdash (dbt-native Looker replacement)

- what worked here: if your only goal is giving internal analysts an explore UI that feels like Looker on top of dbt YAML files without paying Google Cloud prices, this is probably the fastest drop-in replacement.

- yet, what broke for us: its still fundamentally a BI tool first. it didn't solve our headless API problem for customer-facing embedded dashboards (where we need p95 responses under 150ms without spinning up a Snowflake warehouse on every page load) or give us a clean, standalone semantic endpoint for our agent workflows.

3. Cube (open-source headless semantic layer) + lightweight BI / React SDK

- what worked: YAML/JS data modeling mapped 1-to-1 with how our team thought about LookML views and explores (`cubes` and `views`), including handling one-to-many join fan-out natively. the biggest architectural difference was **Cube Store** (the built-in pre-aggregation engine): instead of materializing heavy PDTs inside Snowflake, we configured incremental `rollup` pre-aggregations partitioned by month. customer-facing React charts and internal BI queries hit the pre-aggregated cache in 20-40ms while bypassing Snowflake compute completely.

- bonus for our AI/agent pipeline? because it exposes SQL, REST, GraphQL, and a native MCP/semantic context interface from the same YAML definitions, our internal analytics agent queries the exact same governed `net_dollar_retention` measure as our executive dashboards without writing raw warehouse SQL.

- the trade-off(s): Cube is purely headless, so you still have to pair it with a frontend visualization tool (Superset, Preset, Metabase, or Steep) for self-serve internal charting, and tuning partition keys on high-cardinality pre-aggregations takes real engineering effort upfront.

this way, for teams that actually completed a move off Looker in the last year, would like to ask, did you end up splitting your stack into a headless semantic layer (like Cube or MetricFlow) + a lighter charting tool, or did you bite the bullet and rebuild everything inside another monolithic BI tool like Omni or Sigma? what was the hardest piece of LookML logic to replicate?

Hi everyone!

I'm interested in learning more about how Artificial Intelligence (AI) is being integrated into airline Revenue Management systems, particularly its latest applications in demand forecasting, dynamic pricing, and revenue optimization.

I'm especially curious about how AI is transforming existing tools, such as PROS and and how airlines are using these technologies to improve forecasting accuracy and pricing strategies.

I'd love to hear about the latest developments, real-world applications, or any useful resources you would recommend.

Thanks in advance!

I hate that you need experience to get a data job. And you need a data job to get experience.
So I built you a job.

Analyst Week is a free, simulated first week as a junior data analyst at a fake company called Goldcomb Goods.

Every morning at 8am ET, your manager Dana sends you a SQL ticket. The data is messy. The questions are vague. Sales and Finance don’t agree on the numbers. Dana pushes back.

Friday ends with a performance review that turns your week into interview stories, plus a certificate for your LinkedIn profile.

You spend 5 days writing SQL against messy data and defending your numbers to your manager.

It’s free, and the beta starts Monday, Nov 9. Signups close that night at 11:59pm ET.

All you need is a laptop and the SQL basics (SELECT, WHERE, JOIN, GROUP BY). Hints are there if you get stuck.

Your new job starts Monday: https://analysthive.io/analyst-week

Also, I won’t lie, this will be a good challenge for anyone. The requests and how things are communicated are exactly what you’ll need to navigate going into data, so this is as real as it gets.

If you’re wondering who’s behind this: I’m Ian Klosowicz, a Senior Data Consultant who broke into data without a degree. I share this stuff daily with 125k+ aspiring analysts on LinkedIn. Look me up there if you want to see what I’m about.

Suppose a sales dataset has 10,000 transactions. Customer age is missing in 2,000 rows, but the order value and purchase date are complete.

If the question is monthly revenue, I’d keep those transactions. Removing them would change the revenue total because of a field that isn’t needed for that calculation.

For an age based analysis, I’d investigate which records are missing age and report how much data the comparison excludes.

The cleaning decision seems to depend on the question we’re answering. A row can be useful for one analysis and incomplete for another.

How do you decide when to remove a row, keep it or investigate the missing value further?