Thanks for the details of the issue. It will also help if you can share the
number of incoming messages and the number of messages processed by Atlas (like
in a day?). Your observations of longer processing times for tables having
large number of columns and column-linage are correct. We are looking at few
improvements for a better processing throughput, including use of multiple
threads. This is an involved work and might take couple of weeks before we can
share the details.
From: Österlund Berry <berry.osterl...@scania.com>
Reply-To: "firstname.lastname@example.org" <email@example.com>
Date: Thursday, February 22, 2018 at 12:56 AM
To: "firstname.lastname@example.org" <email@example.com>
Subject: Too much load for Atlas from ATLAS_HOOK
So’ I’m facing a problem that I don’t really know how to solve. The core
problem is that Atlas don’t process the information in the ATLAS_HOOK topic
fast enough. So we have a backlog that is growing every day.
As we want to use tag-based security in combination with Ranger, we moved away
from dropping and recreating the tables in Hive every night when we do our
sqoop imports to instead do the sqoop import into a temporary table, and then
truncate and “insert into” the target table. We are doing this for many 1000’s
of tables every night, and many of them have over 1000 columns. This in
combination with the Column level lineage in Atlas creates a huge workload that
Atlas needs to process, and it just doesn’t handle it.
What I’ve been trying to do is increase the HBase and Kafka performance to make
sure that there is no bottlenecks there. Like HBase atlas_titan table is right
now running evenly distributed over 287 partitions, and I can read all messages
in the topic in roughly 10-15 minutes. So I don’t think that the problem is
within those two systems.
I like to get some pointer on what to do to increase the performance on how
fast Atlas is processing the data in the ATLAS_HOOK topic. For example, it
looks like the NotificationHookConsumer is only running with one thread. Is it
possible to run this in a multi-threaded setup to be able to process the data
in parallel? Anything else you can think of that can help me here?