Comments (7)
we can't really use toBytesWithoutClass
unless we know for sure the class
. Note, that is different from knowing the type.
In Hadoop, it can give you the class in some cases (and cascading also has a mechanism for this, which is why it was there).
Note: kryo will write a registration number instead of a classname when you do toBytesWithClass
if the class type is registered, which is why we allow setting up the kyroinstantitator in the config. We try to register most common scala standard library classes, but also you can (should) set up a twitter kryoinstantiator that knows about thrift types in play.
We had some idea in the past of using scala reflection to try to enumerate the possible classes in play in a job and register those, but I don't know what the state of that was. I don't recall where that code lived.
cc @ianoc who may have some recollections.
from scalding.
Thats the PR that added it , I'm not sure how well it would work with the execution API though. the test is only aimed at Job rather than execution.
The optimizer/planner could probably add a phase to try use this reflection and traverse an execution to build it up. (There would be gremlins to be careful around only doing it in a means that can't result in cached data between jobs/flatmaped executions getting invalid).
from scalding.
yeah, maybe here:
(and in the other two: toIterable and force) we could traverse the typedpipes you have that you are about to run, update the config with new classnames, and it might "just work"?
from scalding.
Yep - ensuring zipped executions share a synchronized registry can probably be setup on a per-execution run basis here: ?
for registering should be good i think?from scalding.
Okay, you make a good point: you can't change the registration between stages because you need to be able to deserialize data from earlier stages in later stages. This basically means that you can't see inside flatmaps, which I think is what you are implying.
I think the only safe place to put the token updating is where you linked: just before you run. You should walk the static value you have inside def run
and that's that. That may mean in practice a lot gets hidden since flatMap
is used internally.
That said... I have always been a bit skeptical this will be a giant win since I think we almost always compress output and the classnames will be basically the first things to be compressed, but I could be wrong (it may be that allocating all those strings is a waste of memory if Class
does not cache the name allocation.
from scalding.
I think the requirement I was thinking of is a bit looser, with the logic:
- If a type is registered now but wasn't earlier, then the classname is inline, so it should work
- Thus we can add types in later
- However, we must always have a agreed upon adding order
Which i think a global lock for an execution would work? or mutex guarded state around the class registration?
(1) should hold right?
Its been many many years since i've ever benchmarked/profiled this, but i could believe at least that the internode speeds aren't often the determining factor now. The serializing of the string many many times could be a big factor, along with flushing buffers to disk super often. If you take skewed data or reduction to a single reducer/hot join key -- in these cases the serialization/deserialization of the classname, compression of data cpu time and disk I/O i believe would be pretty meaningful?
from scalding.
yeah, I think you are right Ian: you could before you run any stage potentially update a dynamic map as long as it has a mutex. So you only add to the map of class to numbers. That should work.
from scalding.
Related Issues (20)
- Use cats PairingHeap for PriorityQueueMonoid
- changes to continuous integration HOT 2
- Scalding on Beam discussion about Joins HOT 1
- migrate to github CI HOT 10
- scalding-jbdc current use / discussion on support/deprecation HOT 4
- flake on optimization test HOT 1
- Set up automatic publishing HOT 16
- scalding-hadoop3 backend OR spark backend upgrade to 3.X HOT 12
- Re-enable code coverage HOT 3
- copy dagon into this tree HOT 1
- Beam backend is missing some pipes
- [Proposal] Support more sinks/sources in scalding-spark HOT 1
- Support CounterPipe in spark-backend HOT 8
- [bug/nit] code format enforcement lost
- make codecov not suck
- push new tags HOT 4
- incompatibility with recent java8 runtime environments due to hadoop
- duplicate tags in pom files HOT 1
- my account is closed HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from scalding.