Alternatives to OpenRefine logo

Alternatives to OpenRefine

Trifacta, R Language, Python, Pandas, and Talend are the most popular alternatives and competitors to OpenRefine.
20
23
+ 1
0

What is OpenRefine and what are its top alternatives?

It is a powerful tool for working with messy data: cleaning it; transforming it from one format into another; and extending it with web services and external data.
OpenRefine is a tool in the Big Data Tools category of a tech stack.
OpenRefine is an open source tool with 7.7K GitHub stars and 1.4K GitHub forks. Here’s a link to OpenRefine's open source repository on GitHub

Top Alternatives to OpenRefine

  • Trifacta

    Trifacta

    It is an Intelligent Platform that Interoperates with Your Data Investments. It sits between the data storage and processing environments and the visualization, statistical or machine learning tools used downstream ...

  • R Language

    R Language

    R provides a wide variety of statistical (linear and nonlinear modelling, classical statistical tests, time-series analysis, classification, clustering, ...) and graphical techniques, and is highly extensible. ...

  • Python

    Python

    Python is a general purpose programming language created by Guido Van Rossum. Python is most praised for its elegant syntax and readable code, if you are just beginning your programming career python suits you best. ...

  • Pandas

    Pandas

    Flexible and powerful data analysis / manipulation library for Python, providing labeled data structures similar to R data.frame objects, statistical functions, and much more. ...

  • Talend

    Talend

    It is an open source software integration platform helps you in effortlessly turning data into business insights. It uses native code generation that lets you run your data pipelines seamlessly across all cloud providers and get optimized performance on all platforms. ...

  • RapidMiner

    RapidMiner

    It is a software platform for data science teams that unites data prep, machine learning, and predictive model deployment. ...

  • Apache Spark

    Apache Spark

    Spark is a fast and general processing engine compatible with Hadoop data. It can run in Hadoop clusters through YARN or Spark's standalone mode, and it can process data in HDFS, HBase, Cassandra, Hive, and any Hadoop InputFormat. It is designed to perform both batch processing (similar to MapReduce) and new workloads like streaming, interactive queries, and machine learning. ...

  • Splunk

    Splunk

    It provides the leading platform for Operational Intelligence. Customers use it to search, monitor, analyze and visualize machine data. ...

OpenRefine alternatives & related posts

Trifacta logo

Trifacta

12
20
0
Develops data wrangling software for data exploration and self-service data preparation for analysis
12
20
+ 1
0
PROS OF TRIFACTA
    No pros available
    CONS OF TRIFACTA
      No cons available

      related Trifacta posts

      related R Language posts

      Eric Colson
      Chief Algorithms Officer at Stitch Fix · | 20 upvotes · 1.6M views

      The algorithms and data infrastructure at Stitch Fix is housed in #AWS. Data acquisition is split between events flowing through Kafka, and periodic snapshots of PostgreSQL DBs. We store data in an Amazon S3 based data warehouse. Apache Spark on Yarn is our tool of choice for data movement and #ETL. Because our storage layer (s3) is decoupled from our processing layer, we are able to scale our compute environment very elastically. We have several semi-permanent, autoscaling Yarn clusters running to serve our data processing needs. While the bulk of our compute infrastructure is dedicated to algorithmic processing, we also implemented Presto for adhoc queries and dashboards.

      Beyond data movement and ETL, most #ML centric jobs (e.g. model training and execution) run in a similarly elastic environment as containers running Python and R code on Amazon EC2 Container Service clusters. The execution of batch jobs on top of ECS is managed by Flotilla, a service we built in house and open sourced (see https://github.com/stitchfix/flotilla-os).

      At Stitch Fix, algorithmic integrations are pervasive across the business. We have dozens of data products actively integrated systems. That requires serving layer that is robust, agile, flexible, and allows for self-service. Models produced on Flotilla are packaged for deployment in production using Khan, another framework we've developed internally. Khan provides our data scientists the ability to quickly productionize those models they've developed with open source frameworks in Python 3 (e.g. PyTorch, sklearn), by automatically packaging them as Docker containers and deploying to Amazon ECS. This provides our data scientist a one-click method of getting from their algorithms to production. We then integrate those deployments into a service mesh, which allows us to A/B test various implementations in our product.

      For more info:

      #DataScience #DataStack #Data

      See more
      Python logo

      Python

      102K
      76.5K
      6.3K
      A clear and powerful object-oriented programming language, comparable to Perl, Ruby, Scheme, or Java.
      102K
      76.5K
      + 1
      6.3K
      PROS OF PYTHON

      related Python posts

      Conor Myhrvold
      Tech Brand Mgr, Office of CTO at Uber · | 35 upvotes · 3.2M views

      How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:

      Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.

      Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:

      https://eng.uber.com/distributed-tracing/

      (GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)

      Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark

      See more
      Nick Parsons
      Director of Developer Marketing at Stream · | 35 upvotes · 1.2M views

      Winds 2.0 is an open source Podcast/RSS reader developed by Stream with a core goal to enable a wide range of developers to contribute.

      We chose JavaScript because nearly every developer knows or can, at the very least, read JavaScript. With ES6 and Node.js v10.x.x, it’s become a very capable language. Async/Await is powerful and easy to use (Async/Await vs Promises). Babel allows us to experiment with next-generation JavaScript (features that are not in the official JavaScript spec yet). Yarn allows us to consistently install packages quickly (and is filled with tons of new tricks)

      We’re using JavaScript for everything – both front and backend. Most of our team is experienced with Go and Python, so Node was not an obvious choice for this app.

      Sure... there will be haters who refuse to acknowledge that there is anything remotely positive about JavaScript (there are even rants on Hacker News about Node.js); however, without writing completely in JavaScript, we would not have seen the results we did.

      #FrameworksFullStack #Languages

      See more
      Pandas logo

      Pandas

      988
      793
      19
      High-performance, easy-to-use data structures and data analysis tools for the Python programming language
      988
      793
      + 1
      19

      related Pandas posts

      Server side

      We decided to use Python for our backend because it is one of the industry standard languages for data analysis and machine learning. It also has a lot of support due to its large user base.

      • Web Server: We chose Flask because we want to keep our machine learning / data analysis and the web server in the same language. Flask is easy to use and we all have experience with it. Postman will be used for creating and testing APIs due to its convenience.

      • Machine Learning: We decided to go with PyTorch for machine learning since it is one of the most popular libraries. It is also known to have an easier learning curve than other popular libraries such as Tensorflow. This is important because our team lacks ML experience and learning the tool as fast as possible would increase productivity.

      • Data Analysis: Some common Python libraries will be used to analyze our data. These include NumPy, Pandas , and matplotlib. These tools combined will help us learn the properties and characteristics of our data. Jupyter notebook will be used to help organize the data analysis process, and improve the code readability.

      Client side

      • UI: We decided to use React for the UI because it helps organize the data and variables of the application into components, making it very convenient to maintain our dashboard. Since React is one of the most popular front end frameworks right now, there will be a lot of support for it as well as a lot of potential new hires that are familiar with the framework. CSS 3 and HTML5 will be used for the basic styling and structure of the web app, as they are the most widely used front end languages.

      • State Management: We decided to use Redux to manage the state of the application since it works naturally to React. Our team also already has experience working with Redux which gave it a slight edge over the other state management libraries.

      • Data Visualization: We decided to use the React-based library Victory to visualize the data. They have very user friendly documentation on their official website which we find easy to learn from.

      Cache

      • Caching: We decided between Redis and memcached because they are two of the most popular open-source cache engines. We ultimately decided to use Redis to improve our web app performance mainly due to the extra functionalities it provides such as fine-tuning cache contents and durability.

      Database

      • Database: We decided to use a NoSQL database over a relational database because of its flexibility from not having a predefined schema. The user behavior analytics has to be flexible since the data we plan to store may change frequently. We decided on MongoDB because it is lightweight and we can easily host the database with MongoDB Atlas . Everyone on our team also has experience working with MongoDB.

      Infrastructure

      • Deployment: We decided to use Heroku over AWS, Azure, Google Cloud because it is free. Although there are advantages to the other cloud services, Heroku makes the most sense to our team because our primary goal is to build an MVP.

      Other Tools

      • Communication Slack will be used as the primary source of communication. It provides all the features needed for basic discussions. In terms of more interactive meetings, Zoom will be used for its video calls and screen sharing capabilities.

      • Source Control The project will be stored on GitHub and all code changes will be done though pull requests. This will help us keep the codebase clean and make it easy to revert changes when we need to.

      See more
      Guillaume Simler

      Jupyter Anaconda Pandas IPython

      A great way to prototype your data analytic modules. The use of the package is simple and user-friendly and the migration from ipython to python is fairly simple: a lot of cleaning, but no more.

      The negative aspect comes when you want to streamline your productive system or does CI with your anaconda environment: - most tools don't accept conda environments (as smoothly as pip requirements) - the conda environments (even with miniconda) have quite an overhead

      See more
      Talend logo

      Talend

      80
      114
      0
      A single, unified suite for all integration needs
      80
      114
      + 1
      0
      PROS OF TALEND
        No pros available
        CONS OF TALEND
          No cons available

          related Talend posts

          RapidMiner logo

          RapidMiner

          21
          25
          0
          Prep data, create predictive models & operationalize analytics within any business process
          21
          25
          + 1
          0
          PROS OF RAPIDMINER
            No pros available
            CONS OF RAPIDMINER
              No cons available

              related RapidMiner posts

              related Apache Spark posts

              Eric Colson
              Chief Algorithms Officer at Stitch Fix · | 20 upvotes · 1.6M views

              The algorithms and data infrastructure at Stitch Fix is housed in #AWS. Data acquisition is split between events flowing through Kafka, and periodic snapshots of PostgreSQL DBs. We store data in an Amazon S3 based data warehouse. Apache Spark on Yarn is our tool of choice for data movement and #ETL. Because our storage layer (s3) is decoupled from our processing layer, we are able to scale our compute environment very elastically. We have several semi-permanent, autoscaling Yarn clusters running to serve our data processing needs. While the bulk of our compute infrastructure is dedicated to algorithmic processing, we also implemented Presto for adhoc queries and dashboards.

              Beyond data movement and ETL, most #ML centric jobs (e.g. model training and execution) run in a similarly elastic environment as containers running Python and R code on Amazon EC2 Container Service clusters. The execution of batch jobs on top of ECS is managed by Flotilla, a service we built in house and open sourced (see https://github.com/stitchfix/flotilla-os).

              At Stitch Fix, algorithmic integrations are pervasive across the business. We have dozens of data products actively integrated systems. That requires serving layer that is robust, agile, flexible, and allows for self-service. Models produced on Flotilla are packaged for deployment in production using Khan, another framework we've developed internally. Khan provides our data scientists the ability to quickly productionize those models they've developed with open source frameworks in Python 3 (e.g. PyTorch, sklearn), by automatically packaging them as Docker containers and deploying to Amazon ECS. This provides our data scientist a one-click method of getting from their algorithms to production. We then integrate those deployments into a service mesh, which allows us to A/B test various implementations in our product.

              For more info:

              #DataScience #DataStack #Data

              See more
              Conor Myhrvold
              Tech Brand Mgr, Office of CTO at Uber · | 7 upvotes · 818.1K views

              Why we built Marmaray, an open source generic data ingestion and dispersal framework and library for Apache Hadoop :

              Built and designed by our Hadoop Platform team, Marmaray is a plug-in-based framework built on top of the Hadoop ecosystem. Users can add support to ingest data from any source and disperse to any sink leveraging the use of Apache Spark . The name, Marmaray, comes from a tunnel in Turkey connecting Europe and Asia. Similarly, we envisioned Marmaray within Uber as a pipeline connecting data from any source to any sink depending on customer preference:

              https://eng.uber.com/marmaray-hadoop-ingestion-open-source/

              (Direct GitHub repo: https://github.com/uber/marmaray Kafka Kafka Manager )

              See more
              Splunk logo

              Splunk

              348
              509
              0
              Search, monitor, analyze and visualize machine data
              348
              509
              + 1
              0
              PROS OF SPLUNK
                No pros available
                CONS OF SPLUNK
                  No cons available

                  related Splunk posts

                  Shared insights
                  on
                  Kibana
                  Splunk
                  Grafana

                  I use Kibana because it ships with the ELK stack. I don't find it as powerful as Splunk however it is light years above grepping through log files. We previously used Grafana but found it to be annoying to maintain a separate tool outside of the ELK stack. We were able to get everything we needed from Kibana.

                  See more