Alternatives to Alation logo

Alternatives to Alation

Google Tag Manager, Segment, Apache Spark, Splunk, and Apache Flink are the most popular alternatives and competitors to Alation.
5
15
+ 1
0

What is Alation and what are its top alternatives?

The leader in collaborative data cataloging, it empowers analysts & information stewards to search, query & collaborate for fast and accurate insights.
Alation is a tool in the Analytics Integrator category of a tech stack.

Top Alternatives to Alation

  • Google Tag Manager

    Google Tag Manager

    Tag Manager gives you the ability to add and update your own tags for conversion tracking, site analytics, remarketing, and more. There are nearly endless ways to track user behavior across your sites and apps, and the intuitive design lets you change tags whenever you want. ...

  • Segment

    Segment

    Segment is a single hub for customer data. Collect your data in one place, then send it to more than 100 third-party tools, internal systems, or Amazon Redshift with the flip of a switch. ...

  • 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. ...

  • Apache Flink

    Apache Flink

    Apache Flink is an open source system for fast and versatile data analytics in clusters. Flink supports batch and streaming analytics, in one system. Analytical programs can be written in concise and elegant APIs in Java and Scala. ...

  • Amazon Athena

    Amazon Athena

    Amazon Athena is an interactive query service that makes it easy to analyze data in Amazon S3 using standard SQL. Athena is serverless, so there is no infrastructure to manage, and you pay only for the queries that you run. ...

  • Apache Hive

    Apache Hive

    Hive facilitates reading, writing, and managing large datasets residing in distributed storage using SQL. Structure can be projected onto data already in storage. ...

  • Presto

    Presto

    Distributed SQL Query Engine for Big Data

Alation alternatives & related posts

Google Tag Manager logo

Google Tag Manager

59.6K
4.5K
0
Quickly and easily update tags and code snippets on your website or mobile app
59.6K
4.5K
+ 1
0
PROS OF GOOGLE TAG MANAGER
    Be the first to leave a pro
    CONS OF GOOGLE TAG MANAGER
      Be the first to leave a con

      related Google Tag Manager posts

      Iva Obrovac
      Product Marketing Manager at Martian & Machine · | 6 upvotes · 23.7K views

      Hi,

      This is a question for best practice regarding Segment and Google Tag Manager. I would love to use Segment and GTM together when we need to implement a lot of additional tools, such as Amplitude, Appsfyler, or any other engagement tool since we can send event data without additional SDK implementation, etc.

      So, my question is, if you use Segment and Google Tag Manager, how did you define what you will push through Segment and what will you push through Google Tag Manager? For example, when implementing a Facebook Pixel or any other 3rd party marketing tag?

      From my point of view, implementing marketing pixels should stay in GTM because of the tag/trigger control.

      If you are using Segment and GTM together, I would love to learn more about your best practice.

      Thanks!

      See more
      Segment logo

      Segment

      2.8K
      723
      275
      A single hub to collect, translate and send your data with the flip of a switch.
      2.8K
      723
      + 1
      275
      PROS OF SEGMENT
      • 86
        Easy to scale and maintain 3rd party services
      • 49
        One API
      • 39
        Simple
      • 25
        Multiple integrations
      • 19
        Cleanest API
      • 10
        Easy
      • 9
        Free
      • 8
        Mixpanel Integration
      • 7
        Segment SQL
      • 6
        Flexible
      • 4
        Google Analytics Integration
      • 2
        Salesforce Integration
      • 2
        SQL Access
      • 2
        Clean Integration with Application
      • 1
        Own all your tracking data
      • 1
        Quick setup
      • 1
        Clearbit integration
      • 1
        Beautiful UI
      • 1
        Integrates with Apptimize
      • 1
        Escort
      • 1
        Woopra Integration
      CONS OF SEGMENT
      • 2
        Not clear which events/options are integration-specific
      • 1
        Limitations with integration-specific configurations
      • 1
        Client-side events are separated from server-side

      related Segment posts

      Robert Zuber

      Our primary source of monitoring and alerting is Datadog. We’ve got prebuilt dashboards for every scenario and integration with PagerDuty to manage routing any alerts. We’ve definitely scaled past the point where managing dashboards is easy, but we haven’t had time to invest in using features like Anomaly Detection. We’ve started using Honeycomb for some targeted debugging of complex production issues and we are liking what we’ve seen. We capture any unhandled exceptions with Rollbar and, if we realize one will keep happening, we quickly convert the metrics to point back to Datadog, to keep Rollbar as clean as possible.

      We use Segment to consolidate all of our trackers, the most important of which goes to Amplitude to analyze user patterns. However, if we need a more consolidated view, we push all of our data to our own data warehouse running PostgreSQL; this is available for analytics and dashboard creation through Looker.

      See more
      Max Musing
      Founder & CEO at BaseDash · | 8 upvotes · 124.5K views

      Functionally, Amplitude and Mixpanel are incredibly similar. They both offer almost all the same functionality around tracking and visualizing user actions for analytics. You can track A/B test results in both. We ended up going with Amplitude at BaseDash because it has a more generous free tier for our uses (10 million actions per month, versus Mixpanel's 1000 monthly tracked users).

      Segment isn't meant to compete with these tools, but instead acts as an API to send actions to them, and other analytics tools. If you're just sending event data to one of these tools, you probably don't need Segment. If you're using other analytics tools like Google Analytics and FullStory, Segment makes it easy to send events to all your tools at once.

      See more
      Apache Spark logo

      Apache Spark

      2.4K
      2.8K
      132
      Fast and general engine for large-scale data processing
      2.4K
      2.8K
      + 1
      132
      PROS OF APACHE SPARK
      • 58
        Open-source
      • 48
        Fast and Flexible
      • 7
        One platform for every big data problem
      • 6
        Easy to install and to use
      • 6
        Great for distributed SQL like applications
      • 3
        Works well for most Datascience usecases
      • 2
        Machine learning libratimery, Streaming in real
      • 2
        In memory Computation
      • 0
        Interactive Query
      CONS OF APACHE SPARK
      • 3
        Speed

      related Apache Spark posts

      Eric Colson
      Chief Algorithms Officer at Stitch Fix · | 21 upvotes · 2M 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 · 1M 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

      459
      726
      11
      Search, monitor, analyze and visualize machine data
      459
      726
      + 1
      11
      PROS OF SPLUNK
      • 2
        API for searching logs, running reports
      • 1
        Query engine supports joining, aggregation, stats, etc
      • 1
        Query any log as key-value pairs
      • 1
        Splunk language supports string, date manip, math, etc
      • 1
        Granular scheduling and time window support
      • 1
        Alert system based on custom query results
      • 1
        Custom log parsing as well as automatic parsing
      • 1
        Dashboarding on any log contents
      • 1
        Ability to style search results into reports
      • 1
        Rich GUI for searching live logs
      CONS OF SPLUNK
      • 1
        Splunk query language rich so lots to learn

      related Splunk posts

      Shared insights
      on
      KibanaKibanaSplunkSplunkGrafanaGrafana

      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
      Apache Flink logo

      Apache Flink

      406
      638
      35
      Fast and reliable large-scale data processing engine
      406
      638
      + 1
      35
      PROS OF APACHE FLINK
      • 15
        Unified batch and stream processing
      • 8
        Easy to use streaming apis
      • 8
        Out-of-the box connector to kinesis,s3,hdfs
      • 3
        Open Source
      • 1
        Low latency
      CONS OF APACHE FLINK
        Be the first to leave a con

        related Apache Flink posts

        Surabhi Bhawsar
        Technical Architect at Pepcus · | 7 upvotes · 545.3K views
        Shared insights
        on
        KafkaKafkaApache FlinkApache Flink

        I need to build the Alert & Notification framework with the use of a scheduled program. We will analyze the events from the database table and filter events that are falling under a day timespan and send these event messages over email. Currently, we are using Kafka Pub/Sub for messaging. The customer wants us to move on Apache Flink, I am trying to understand how Apache Flink could be fit better for us.

        See more

        I have to build a data processing application with an Apache Beam stack and Apache Flink runner on an Amazon EMR cluster. I saw some instability with the process and EMR clusters that keep going down. Here, the Apache Beam application gets inputs from Kafka and sends the accumulative data streams to another Kafka topic. Any advice on how to make the process more stable?

        See more
        Amazon Athena logo

        Amazon Athena

        384
        608
        46
        Query S3 Using SQL
        384
        608
        + 1
        46
        PROS OF AMAZON ATHENA
        • 15
          Use SQL to analyze CSV files
        • 8
          Glue crawlers gives easy Data catalogue
        • 6
          Cheap
        • 5
          Query all my data without running servers 24x7
        • 4
          No data base servers yay
        • 3
          Easy integration with QuickSight
        • 2
          Query and analyse CSV,parquet,json files in sql
        • 2
          Also glue and athena use same data catalog
        • 1
          No configuration required
        • 0
          Ad hoc checks on data made easy
        CONS OF AMAZON ATHENA
          Be the first to leave a con

          related Amazon Athena posts

          I use Amazon Athena because similar to Google BigQuery , you can store and query data easily. Especially since you can define data schema in the Glue data catalog, there's a central way to define data models.

          However, I would not recommend for batch jobs. I typically use this to check intermediary datasets in data engineering workloads. It's good for getting a look and feel of the data along its ETL journey.

          See more

          Hi all,

          Currently, we need to ingest the data from Amazon S3 to DB either Amazon Athena or Amazon Redshift. But the problem with the data is, it is in .PSV (pipe separated values) format and the size is also above 200 GB. The query performance of the timeout in Athena/Redshift is not up to the mark, too slow while compared to Google BigQuery. How would I optimize the performance and query result time? Can anyone please help me out?

          See more
          Apache Hive logo

          Apache Hive

          362
          362
          0
          Data Warehouse Software for Reading, Writing, and Managing Large Datasets
          362
          362
          + 1
          0
          PROS OF APACHE HIVE
            Be the first to leave a pro
            CONS OF APACHE HIVE
              Be the first to leave a con

              related Apache Hive posts

              Ashish Singh
              Tech Lead, Big Data Platform at Pinterest · | 36 upvotes · 878.8K views

              To provide employees with the critical need of interactive querying, we’ve worked with Presto, an open-source distributed SQL query engine, over the years. Operating Presto at Pinterest’s scale has involved resolving quite a few challenges like, supporting deeply nested and huge thrift schemas, slow/ bad worker detection and remediation, auto-scaling cluster, graceful cluster shutdown and impersonation support for ldap authenticator.

              Our infrastructure is built on top of Amazon EC2 and we leverage Amazon S3 for storing our data. This separates compute and storage layers, and allows multiple compute clusters to share the S3 data.

              We have hundreds of petabytes of data and tens of thousands of Apache Hive tables. Our Presto clusters are comprised of a fleet of 450 r4.8xl EC2 instances. Presto clusters together have over 100 TBs of memory and 14K vcpu cores. Within Pinterest, we have close to more than 1,000 monthly active users (out of total 1,600+ Pinterest employees) using Presto, who run about 400K queries on these clusters per month.

              Each query submitted to Presto cluster is logged to a Kafka topic via Singer. Singer is a logging agent built at Pinterest and we talked about it in a previous post. Each query is logged when it is submitted and when it finishes. When a Presto cluster crashes, we will have query submitted events without corresponding query finished events. These events enable us to capture the effect of cluster crashes over time.

              Each Presto cluster at Pinterest has workers on a mix of dedicated AWS EC2 instances and Kubernetes pods. Kubernetes platform provides us with the capability to add and remove workers from a Presto cluster very quickly. The best-case latency on bringing up a new worker on Kubernetes is less than a minute. However, when the Kubernetes cluster itself is out of resources and needs to scale up, it can take up to ten minutes. Some other advantages of deploying on Kubernetes platform is that our Presto deployment becomes agnostic of cloud vendor, instance types, OS, etc.

              #BigData #AWS #DataScience #DataEngineering

              See more
              Presto logo

              Presto

              331
              842
              62
              Distributed SQL Query Engine for Big Data
              331
              842
              + 1
              62
              PROS OF PRESTO
              • 17
                Works directly on files in s3 (no ETL)
              • 12
                Open-source
              • 11
                Join multiple databases
              • 10
                Scalable
              • 7
                Gets ready in minutes
              • 5
                MPP
              CONS OF PRESTO
                Be the first to leave a con

                related Presto posts

                Ashish Singh
                Tech Lead, Big Data Platform at Pinterest · | 36 upvotes · 878.8K views

                To provide employees with the critical need of interactive querying, we’ve worked with Presto, an open-source distributed SQL query engine, over the years. Operating Presto at Pinterest’s scale has involved resolving quite a few challenges like, supporting deeply nested and huge thrift schemas, slow/ bad worker detection and remediation, auto-scaling cluster, graceful cluster shutdown and impersonation support for ldap authenticator.

                Our infrastructure is built on top of Amazon EC2 and we leverage Amazon S3 for storing our data. This separates compute and storage layers, and allows multiple compute clusters to share the S3 data.

                We have hundreds of petabytes of data and tens of thousands of Apache Hive tables. Our Presto clusters are comprised of a fleet of 450 r4.8xl EC2 instances. Presto clusters together have over 100 TBs of memory and 14K vcpu cores. Within Pinterest, we have close to more than 1,000 monthly active users (out of total 1,600+ Pinterest employees) using Presto, who run about 400K queries on these clusters per month.

                Each query submitted to Presto cluster is logged to a Kafka topic via Singer. Singer is a logging agent built at Pinterest and we talked about it in a previous post. Each query is logged when it is submitted and when it finishes. When a Presto cluster crashes, we will have query submitted events without corresponding query finished events. These events enable us to capture the effect of cluster crashes over time.

                Each Presto cluster at Pinterest has workers on a mix of dedicated AWS EC2 instances and Kubernetes pods. Kubernetes platform provides us with the capability to add and remove workers from a Presto cluster very quickly. The best-case latency on bringing up a new worker on Kubernetes is less than a minute. However, when the Kubernetes cluster itself is out of resources and needs to scale up, it can take up to ten minutes. Some other advantages of deploying on Kubernetes platform is that our Presto deployment becomes agnostic of cloud vendor, instance types, OS, etc.

                #BigData #AWS #DataScience #DataEngineering

                See more
                Eric Colson
                Chief Algorithms Officer at Stitch Fix · | 21 upvotes · 2M 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