This is a parent task for the work to be done for the FY2018-2019 [[ https://www.mediawiki.org/wiki/Wikimedia_Technology/Annual_Plans/FY2019/TEC2:_Modern_Event_Platform | Modern Event Platform Program ]] ([[https://www.mediawiki.org/wiki/Wikimedia_Technology/Goals/2018-19_Q1#TEC2:_Modern_Event_Platform | Q1 goals]]).
EventLogging is home grown, and was not designed for purposes other than low volume analytics in MySQL databases. However, the ideas it was based on are solid and convergently have become an industry standard, often called a Stream Data Platform. In the last two years, we have been developing the EventBus sub-system with the aim of standardizing events to be used both internally for propagating changes to update the dependent artifacts as well as exposing them to clients. While this has been a success, integrating these events with different systems requires much custom and cumbersome glue code. There exist open source technologies for integrating and processing streams of events.
Engineering teams should be able to quickly develop features that are easy to instrument and measure, as well as for those features to react to events from other systems.
As a way to begin the process of understanding existing challenges with EventLogging, we have created the following document: https://docs.google.com/spreadsheets/d/1M1A4YEdlF0T79KgQO7g4_jpzNSe-XCn3lO0_TzhO6yQ/edit?ts=5ae7bc8a#gid=0. This document is meant to list out all the steps to instrumenting and analyzing with EventLogging, indicate which ones are the most time-consuming and error-prone, identify which teams participate, and be specific about the challenges in each step.
This program also overlaps with the [[ https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2018-2019/Audiences#Better_Use_of_Data | Better Use of Data ]] program. See also https://docs.google.com/spreadsheets/d/16cALJVeql2euSad3GgXJjDCOVYsBRC64ietw8oRzsbI/edit#gid=0
# Background Reading
- https://www.confluent.io/blog/data-dichotomy-rethinking-the-way-we-treat-data-and-services/
- https://www.confluent.io/blog/stream-data-platform-1/
- https://www.confluent.io/blog/messaging-single-source-truth/
- https://www.confluent.io/blog/build-services-backbone-events/
# Components
Each of the components described below are units of technical output of this program. They are either deployed services/tools, or documentation and policy guidelines.
Let's first define a couple of terms before the individual technical components are detailed below.
- **Event** - A strongly typed and schemaed piece of data, usually representing something happening at a definite time. E.g. revision-create, user-button-click, page-load, etc.
- **Stream** - A contiguous (often unending) collection of events (loosely) ordered by time.
##### [[ https://phabricator.wikimedia.org/T201068 | Stream Intake Service ]]
from internal and external clients (browsers & apps). EventLogging + EventBus do some of this already, but are limited in scope and scale. We will either refactor EventLogging, or use something new.
##### [[ https://phabricator.wikimedia.org/T201063 | Event Schema Registry ]]
This should combine the existing EventLogging schemas with the mediawiki/event-schemas. This might be something new, or it might be improvements to the existant Mediawiki based schema repository.
##### [[ https://phabricator.wikimedia.org/T214093 | Event Schema Guidelines ]]
Some exist already for analytics purposes, some exist for mediawiki/event-schemas. We should unify these.
##### [[ https://phabricator.wikimedia.org/T214430 | Stream Connectors ]] for ingestion to and from various state stores
(MySQL, Redis, Druid, Cassandra, HDFS, etc.) This will likely be Kafka Connect. We will need to [[ https://github.com/ottomata/kafka-connect-jsonschema | adapt Kafka Connect ]] to work with JSONSchemas and our Event Schema Repository.
##### [[ https://phabricator.wikimedia.org/T205319 | Stream Configuration Service ]]
Product needs the ability to have more dynamic control over how client side producers of events are configured. This includes things like sampling rate, time based event producing windows etc. (This component was originally conceived of as part of the Event Schema Repository component. It is complex and architecturally different enough to warrant its own component here.)
##### Stream Processing system with dependency tracking system conceptual design
Engineers should have a standardized way to build and deploy and maintain stream processing type jobs, for both analytics an production purposes. A very common use of stream processing at WMF is change-propogation, which to do well requires a dependency tracking mechanism, a very long term goal. We want to choose stream processing technologies that work toward this goal.
This component is the lowest priority of the Modern Event Platform, and as such will have more thought and planning towards the end of the program.
See also:
- https://www.mediawiki.org/wiki/User:Daniel_Kinzler_(WMDE)/DependencyEngine
- {T105766}
# Timeline
##### FY2017-2018
- [x] Q4: Interview product and technology stakeholders to collect desires, use cases, and requirements.
---
##### FY2018-2019
- [x] Q1: Survey and choose technologies and solutions with input from #services and #operations.
- [x] Q2: Begin implementation and deployment of some chosen techs.
- [x] Q3: Deployment of eventgate-analytics stream intake service - T206785,
- [x] Q4: Deployment of eventgate-main stream intake service - T218346
- [] Q4: Decommission Avro streams in favor of eventgate-analytics JSON based ones, T188136
- [] Q4: (new) CI support for event schemas repo - T206814
---
##### FY2019-2020
###### Stream Connectors
[] Q1: Kafka Connect development work (Kubernetes? YARN? Standalone?)
[] Q2: Kafka Connect deployment; replace some usages of Camus HDFS with Kafka Connect HDFS
[] Q3-Q4: Replace usages of Camus HDFS for eventgate events with Kafka Connect HDFS
###### Stream Intake Service - T201068
Migrate Mediawiki EventBus events to eventgate-main & deprecate eventlogging-service-eventbus
[] Q1: Continue migrating events to eventgate-main - T211248
[] Q2: Decomission eventlogging-service-eventbus
###### Event Schema Registry - T201063
[] Q1: Schema repository hooks to generate dereferenced canonical version - T206812
[] Q2: Support $ref in JSONSchemas - T206824
[] Q2/Q3: Set up public HTTP endpoint for schemas
[] Q2/Q3: Create a new 'analytics' schema repository
###### Stream Configuration Service - T205319
- Q2: start planning with Audiences
- Q3: implementation
###### Replace EventLogging Analytics
This is a long term project to be worked on in collaboration with Audiences engineers which includes work on the Event Schema Registry and Stream Configuration Service components.
- Q2: Begin planning this work with Audiences.
- Q3: Coding work on all of these pieces (e.g. client side library to use Stream Config and POST to eventgate)
- Q3-Q4: deployment of Stream Config Service and some usages of external eventgate
#### Stream Processing System & Dependency Tracking
Work for next year:
- collect basic requirments
- Figure out if a streaming platform + graph db support basic requirements at scale
## Use case collection
- JADE for ORES
- Fundraising banner impressions pipeline
- WDQS state updates
- Job Queue (implementation ongoing)
- Frontend Cache (varnish) invalidation
- Scalable EventLogging (with automatic visualization in tools (Pivot, etc.))
- Realtime SQL queries and state store updates. Can be used to verify real time that events have what they should/are valid
- Trending pageviews & edits
- Mobile App Events
- ElasticSearch index updates incorporating new revisions & ORES scores
- Automatic Prometheus metric transformation and collection
- Dependency tracking transport and stream processing
- Stream of reference/citation events: https://etherpad.wikimedia.org/p/RefEvents
- Javascript errors
(...add more as collected!)
WIP Diagram Here: https://www.lucidchart.com/documents/view/2f3d5337-d393-4229-8e26-2f49283fc63a/0
{F26295297, width=800}