Take a random sample of rows
A number of rows or a percentage, drawn at random and reproducibly: the same seed over the same file always gives the same sample, so you and a colleague can look at identical rows. Stratify by a column and each of its values keeps its share of the file, so a sample of a skewed dataset still looks like the dataset.
Why a seed, and why it is not optional here
An unseeded random sample is a one-time event. You draw it, you find something interesting in row 40, you send the file to a colleague, and when they draw their own sample row 40 is a different record. Neither of you can reproduce the other's work, and neither of you can reproduce your own from last week.
So the seed is a first-class control here rather than an advanced option, and it defaults to 1 rather than to the clock. The same file and the same seed always produce the same rows, in every browser, on every machine, today and next year. Change the seed and you get a different sample, which is exactly what you want when the first one looked unrepresentative and you need a second opinion.
It takes a word as readily as a number, so march-audit is a valid seed. That is worth doing: a seed you can say out loud is a seed that ends up in the ticket, and a sample described as "the first hundred rows, seed march-audit" is one anybody can regenerate.
The generator is mulberry32, a small well-tested PRNG. It is not cryptographically secure and does not need to be: the requirement here is a reproducible, evenly distributed shuffle, not an unpredictable one.
Stratifying, and what it fixes
Plain random sampling has a failure mode that shows up exactly when it matters most. Take a hundred rows at random from a file where one region accounts for 2% of the rows, and there is a real chance you get one row from that region, or none. Your sample is now missing a category the dataset contains, and every conclusion you draw from it inherits that gap.
Stratifying fixes it by allocating the sample proportionally. Pick a column under Keep the mix of and each of its values gets its share:
100 rows: 80 marked big, 20 marked small
Plain sample of 20 → anywhere from 12 to 20 big, by luck
Stratified sample of 20 → exactly 16 big and 4 small, every timeThe allocation uses largest-remainder rounding, so the leftovers from rounding go to the groups that lost the most to it rather than always to whichever group happens to be first. Within each group the draw is still random and still seeded.
If the column has more distinct values than the sample has rows, some values cannot be represented at all, and the tool says so with the number you would need to cover every group. That is a more useful answer than silently giving you a sample that is missing a third of the categories.
Worked example
A hundred rows, eighty in group big and twenty in group small. Ask for twenty rows, stratified by group, seed 1:
20 of 100 rows · 20.0% of the file · seed 1 · stratified across 2 values of groupSixteen big and four small, every time, in the file's original row order. Run it again with the same seed and you get the same twenty rows. Change the seed to march-audit and you get a different twenty, still split sixteen and four.
Drop the stratification and ask again with seed 1 and you get twenty rows whose split will be somewhere near sixteen and four but is not guaranteed to be. That is the whole difference, and on a file where the small group is 2% rather than 20% it is the difference between a usable sample and one that is missing a category.
Count or percentage, and row order
- A fixed count is right when something downstream has a limit: a tool that accepts a thousand rows, a fixture you want to keep small, a manual review somebody has to actually do. Ask for more rows than the file has and you get the whole file, with a note.
- A percentage is right when the sample should scale with the input: a 10% sample of this month's export and next month's are comparable in a way that two 1,000-row samples of differently-sized files are not.
- Row order is preserved by default. The sampled rows come out in the order they appeared in the file, so a chronological file stays chronological and the sample still reads as data rather than as a shuffled pile. This does not bias anything: which rows were chosen was already decided at random.
- Shuffling is the other option. Turn row order to Shuffled when you want the output order itself to be random, which matters for assigning a review queue or splitting into arms of a test.
What people use this for
- Test fixtures from real data. A hundred real rows exercise more edge cases than a hundred invented ones, because real data contains the encoding oddity and the empty field and the value nobody thought of. A seed makes the fixture stable, so a test that passes today passes tomorrow.
- Manual quality review. Nobody is checking four hundred thousand rows. Two hundred stratified across the categories that matter is a review somebody will finish, and the seed means a second reviewer can check the same rows.
- Sharing a shape without sharing the data. A small sample conveys the structure of a file to a colleague or a vendor. Combine it with dropping the sensitive columns first.
- Making a big file workable. Building a pipeline against ten thousand rows and then running it on four million is much faster than iterating on the whole thing, and a sample small enough to open in a spreadsheet is a sample you can eyeball.
- Splitting a dataset. Two runs at the same seed with different sizes give you nested samples. For genuinely disjoint splits, sample once and then use the splitter on the shuffled result.
Frequently Asked Questions
Will I get the same rows if I run it again?
Yes, as long as the seed and the file are the same. That is the point of the seed. The generator is deterministic and runs identically in every browser, so you and a colleague on different machines drawing seed 7 from the same file see the same rows. Change the seed for a different draw.
What does stratified mean?
Each value of the column you choose keeps its share of the file in the sample. If 20% of your rows are from the West, then 20% of the sample is too, rather than however many happened to be drawn. It matters most for small categories, which plain random sampling can miss entirely, and that is exactly when missing them does the most damage.
Is the sample actually random?
It is a deterministic pseudo-random draw using mulberry32, with a partial Fisher-Yates shuffle so every row has an equal chance of selection. It is not cryptographically secure and is not meant to be. For choosing rows to inspect, building fixtures or estimating a distribution, this is the right kind of random; for anything where somebody has an incentive to predict the draw, it is not.
Why are my sampled rows still in the original order?
Because that is the default, and it keeps a chronological file chronological. Which rows were selected was already random, so the output order carries no extra information and reading the sample is easier when it matches the source. Switch row order to Shuffled if you want the order randomized too.
What if I ask for more rows than the file has?
You get the whole file and a note saying so. Nothing is duplicated to pad the count out, because a sample with repeated rows is not a sample of anything. In percentage mode the maximum is 100, which is likewise just the file.
Can I stratify by a column with lots of values?
You can, but if it has more distinct values than your sample has rows, some of them cannot appear at all. The tool warns you and names the minimum sample size that would cover every group. For a high-cardinality column, consider bucketing it first, or stratifying on a coarser column instead.
Related
Draw a sample you can draw again
Seeded, optionally stratified, and reproducible on any machine by anyone holding the same file.
Back to the sampler