There are several ways to load data into Bigtable, and which one fits depends on your source and the format the data is already in. A small set of CSV files in Cloud Shell calls for a different tool than a live stream of events or a full migration off another database. The Professional Cloud Database Engineer exam tends to give you a source and a requirement, then ask which method matches, so the useful thing to know is what each path is built for rather than the exact syntax of any one command.
The Cloud Bigtable Tool, usually called the cbt tool, is the most direct option. You would reach for it when you are working with CSV files stored locally or in your Cloud Shell environment. To move the data, you run the cbt import command from the terminal. This is the straightforward, command line path, and it suits situations where the data is already sitting as files near you rather than living in another Google Cloud service.
When the data you need is already in BigQuery, you can run a BigQuery EXPORT DATA statement to send it into Bigtable. The statement is designed to handle that transfer directly, with minimal configuration. This is the path to recognize whenever a scenario describes data that has been sitting in BigQuery and now needs to land in Bigtable, since it avoids stepping the data through an intermediate export to files first.
For real time ingestion, Pub/Sub is the option built for data that needs to be written as it arrives. By setting up Pub/Sub Bigtable subscriptions, the system writes incoming messages directly to your table without needing intermediate processing. That direct write is the point to hold onto. When the requirement is streaming data and the question is how to get each message into Bigtable as it comes in, a Bigtable subscription handles the write without a separate pipeline in the middle.
Dataflow is the standard choice for more complex requirements, and in particular for large scale migrations from other databases. You can use pre-built Dataflow Templates or custom Dataflow Connectors, which remove the need to write and maintain integration code yourself. Where cbt fits files and a Pub/Sub subscription fits a stream, Dataflow fits the heavier work of moving a large body of data from one system into Bigtable in a managed way.
One Dataflow pattern worth understanding for the Professional Cloud Database Engineer exam is moving data from an external cloud provider into a Bigtable instance. The example starts with a source database such as DynamoDB on AWS. Dataflow sits in the middle as the processing engine. A DynamoDBIO connector reads from the source, and a BigtableIO connector writes into Bigtable. Together these specialized connectors handle the data movement so you do not have to write custom integration code for the source.
This setup works as a serverless ETL process between Google Cloud and external sources, and it brings a few benefits that tend to matter during a migration. It can enable near real time replication, which helps maintain data consistency while the transition is still in progress. Because the pipeline stays active, it can reduce downtime through continuous synchronization between the source and the target, so you can cut over to the new database once the data is consistent across both environments. It also minimizes operational overhead by relying on automated scaling, since Dataflow adjusts its worker count based on the volume of data being moved.
Pulling these together, the way to keep them straight is by source and shape of the data. Use cbt and the cbt import command for CSV files in Cloud Shell, a BigQuery EXPORT DATA statement for data already in BigQuery, Pub/Sub Bigtable subscriptions for streaming data, and Dataflow with its templates and connectors for large migrations, including cross-cloud moves through connectors like DynamoDBIO and BigtableIO.
Our Professional Cloud Database Engineer course covers importing data into Bigtable alongside provisioning and scaling Bigtable resources, with practice questions that drill these distinctions.
