For all Hive users using stat1002/1004, you might have seen a deprecation
warning when you launch the hive client - that claims it's being replaced
with Beeline. The Beeline shell has always been available to use, but it
required supplying a database connection string every time, which was
pretty annoying. We now have a wrapper
setup to make this easier. The old Hive CLI will continue to exist, but we
encourage moving over to Beeline. You can use it by logging into the
stat1002/1004 boxes as usual, and launching `beeline`.
There is some documentation on this here:
If you run into any issues using this interface, please ping us on the
Analytics list or #wikimedia-analytics or file a bug on Phabricator
(If you are wondering stat1004 whaaat - there should be an announcement
coming up about it soon!)
Wikimedia is releasing a new service today: EventStreams
<https://wikitech.wikimedia.org/wiki/EventStreams>. This service allows us
to publish arbitrary streams of JSON event data to the public. Initially,
the only stream available will be good ol’ RecentChanges
<https://www.mediawiki.org/wiki/Manual:RCFeed>. This event stream overlaps
functionality already provided by irc.wikimedia.org and RCStream
<https://wikitech.wikimedia.org/wiki/RCStream>. However, this new service
has advantages over these (now deprecated) services.
We can expose more than just RecentChanges.
Events are delivered over streaming HTTP (chunked transfer) instead of
IRC or socket.io. This requires less client side code and fewer special
routing cases on the server side.
Streams can be resumed from the past. By using EventSource, a
disconnected client will automatically resume the stream from where it left
off, as long as it resumes within one week. In the future, we would like
to allow users to specify historical timestamps from which they would like
to begin consuming, if this proves safe and tractable.
I did say deprecated! Okay okay, we may never be able to fully deprecate
irc.wikimedia.org. It’s used by too many (probably sentient by now) bots
out there. We do plan to obsolete RCStream, and to turn it off in a
reasonable amount of time. The deadline iiiiiis July 7th, 2017. All
services that rely on RCStream should migrate to the HTTP based
EventStreams service by this date. We are committed to assisting you in
this transition, so let us know how we can help.
Unfortunately, unlike RCStream, EventStreams does not have server side
event filtering (e.g. by wiki) quite yet. How and if this should be done
is still under discussion <https://phabricator.wikimedia.org/T152731>.
The RecentChanges data you are used to remains the same, and is available
at https://stream.wikimedia.org/v2/stream/recentchange. However, we may
have something different for you, if you find it useful. We have been
internally producing new Mediawiki specific events
for a while now, and could expose these via EventStreams as well.
Take a look at these events, and tell us what you think. Would you find
them useful? How would you like to subscribe to them? Individually as
separate streams, or would you like to be able to compose multiple event
types into a single stream via an API? These things are all possible.
I asked for a lot of feedback in the above paragraphs. Let’s try and
centralize this discussion over on the mediawiki.org EventStreams talk page
<https://www.mediawiki.org/wiki/Talk:EventStreams>. In summary, the
What RCStream clients do you maintain, and how can we help you migrate
to EventStreams? <https://www.mediawiki.org/wiki/Topic:Tkjkee2j684hkwc9>
Is server side filtering, by wiki or arbitrary event field, useful to
Would you like to consume streams other than RecentChanges?
available events are described here
- Andrew Otto
Does anyone know of a way to look up the top editors for a certain
namespace (like "Module") across all Wikimedia sites?
I'm asking as I'm wondering how to get more aware of developer activity
outside of Wikimedia Git/Gerrit.
Thanks for any ideas (or pointing out a better place to ask)!
Andre Klapper | Wikimedia Bugwrangler
Hello! Has anyone experienced issues `mvn package`-ing
analytics/refinery/source on a local machine?
Wikimedia Analytics Refinery Jobs fails for me as of "Add mediawiki history
spark jobs to refinery-job" (https://gerrit.wikimedia.org/r/#/c/325312/)
Here's my `mvn --version`:
Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
Maven home: /usr/local/Cellar/maven/3.3.9/libexec
Java version: 1.8.0_121, vendor: Oracle Corporation
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.12.4", arch: "x86_64", family: "mac"
When I set HEAD to the commit prior to that everything succeeds. Any commit
after that one makes Jobs tests fail with warnings and errors like:
[INFO] Checking for multiple versions of scala
[WARNING] Expected all dependencies to require Scala version: 2.10.4
[WARNING] com.twitter:chill_2.10:0.5.0 requires scala version: 2.10.4
requires scala version: 2.10.4
requires scala version: 2.10.4
requires scala version: 2.10.4
[WARNING] org.apache.spark:spark-core_2.10:1.6.0-cdh5.10.0 requires scala
[WARNING] org.json4s:json4s-jackson_2.10:3.2.10 requires scala version:
[WARNING] org.json4s:json4s-core_2.10:3.2.10 requires scala version: 2.10.4
[WARNING] org.json4s:json4s-ast_2.10:3.2.10 requires scala version: 2.10.4
[WARNING] org.json4s:json4s-core_2.10:3.2.10 requires scala version: 2.10.0
[WARNING] Multiple versions of scala libraries detected!
17/03/31 13:38:41 WARN NativeCodeLoader: Unable to load native-hadoop
library for your platform... using builtin-java classes where applicable
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
Caused by: java.lang.UnsatisfiedLinkError: no snappyjava in
... 33 more
- should put max rev ts when no page state match *** FAILED ***
org.apache.spark.SparkException: Job aborted due to stage failure: Task
serialization failed: java.lang.reflect.InvocationTargetException
We need to do some maintenance work to the evenlogging database that
requires renaming and archiving of all tables that are currently receiving
Tables will be renamed from, for example: WikipediaZeroUsage_14574251 to
15423246 is the capsule schema version.
As new events are come for 'WikipediaZeroUsage' schema with schema version
14574251 the table WikipediaZeroUsage_14574251 will get recreated again,
the only difference is that this new table will have different column
length for varchar fields.
Details of this change are here: https://phabricator.wikimedia.org/T160454
We will start our maintenance event on Thursday morning around 11 am PST
time and it would last couple hours, no data loss on eventlogging will
happen as part of this event.
Reportupdater queries that use eventlogging would need to be updated to
select from the newly renamed tables (and we will take care of doing that)
but other than those we do not think there are any other automated scripts
that would need updating. Please let us know otherwise.
Also, please be so kind to let us know if this renaming is disruptive in
any way. We can also do this changes at a later time next week.
I'm not sure about the Geographical Distribution, but I agree that the
information at the top of the page seems to imply that the data is from
Regretfully, my retention query was killed because it was running too long.
https://quarry.wmflabs.org/query/17500 I'll start a new one on our
analytics servers. I'm flying to the same conference you are so are today
so hopefully, I'll be able to give you some good news when I land (tomorrow
On Tue, Mar 28, 2017 at 6:25 PM, Shannon Keith <shannon(a)williamsworks.com>
> Thank you all, this has been very helpful.
> A couple follow-up questions:
> · The geographical distribution
> is from 2013 correct?
> · Would someone be able to create an updated graph of editor
> retention on English Wikipedia up to 2016? It doesn’t have to be just
> ‘good-faith’ editors, I know that would be much more work. This is the one
> we currently have, but it would be great to have it show recent years:
> This will be part of a presentation from the strategy team, so if it’s
> possible to do by this Thursday, I would be so grateful.
> *From:* Aaron Halfaker [mailto:email@example.com]
> *Sent:* Thursday, March 23, 2017 7:59 AM
> *To:* A mailing list for the Analytics Team at WMF and everybody who has
> an interest in Wikipedia and analytics. <analytics(a)lists.wikimedia.org>
> *Cc:* Shannon Keith <shannon(a)williamsworks.com>
> *Subject:* Re: [Analytics] Fwd: follow-up on editors
> Note that "editing session" is not at all similar to an "edit session"
> from this:
> Geiger, R. S., & Halfaker, A. (2013, February). Using edit sessions to
> measure participation in Wikipedia. In *Proceedings of the 2013
> conference on Computer supported cooperative work* (pp. 861-870). ACM.
> On Thu, Mar 23, 2017 at 9:55 AM, Nuria Ruiz <nuria(a)wikimedia.org> wrote:
> >· Average hours of spent by editors by segment (5+ edits and
> 100+ edits)?
> We do not keep track of session length per editor thus this data is not
> The most similar thing I can think of is session length of editing session
> which is quite different. That is a heavily sampled metric that is reported
> via eventlogging, some related data is reported here:
> On Wed, Mar 22, 2017 at 5:03 PM, Federico Leva (Nemo) <nemowiki(a)gmail.com>
> Aaron Halfaker, 22/03/2017 22:43:
> __· __Number of editors who contribute 1 edit per month? __
> First column of https://stats.wikimedia.org/EN/TablesWikimediaAllProjects.
> htm .
> __· Is it possible/feasible to run editor retention metrics
> globally (versus just based on a single project?
> This depends if one just wants to (deduplicate and) sum different
> projects, or also consider interwiki events (such as a person stopping
> activity on a wiki but resuming activity on another wiki). I remember
> something was done a few years ago to see if Wikidata removed active
> editors from other projects and a few "migration" paths were identified in
> all directions. I can't find the chart/table now though.
> __· __Total number of editors on all projects over the past 16
> years (not just ENWP)?____
> For a quick estimate I usually make a proportion
> editor_activity_levels : https://stats.wikimedia.org/
> EN/TablesWikimediaAllProjects.htm ~ https://stats.wikimedia.org/
> EN/TablesWikipediaEN.htm#editdistribution : x . If the active editors in
> most classes are about 1 : 2, then probably the total number of editors in
> all Wikipedias + all other project is more than twice the English
> Wikipedia's total e.g. over 10 millions (or over 2 millions if you consider
> the usual 10 edits threshold).
> __· __Global distribution of editors by region (or country),
> + https://web.archive.org/web/20161002042707/https://stats.
> Analytics mailing list
> Analytics mailing list