Migrating a Sentry-Secured CDH Cluster to CDP Private Cloud Base
A 48-node CDH 5.16 cluster stores 900 TB in HDFS and serves 350 analysts through Hive and Impala. The metastore contains 12,000 tables: 60% external tables pointing at HDFS paths, 25% managed tables, and 15% views. Authorization is entirely Sentry-based. The organization must move to CDP Private Cloud Base 7.1.9 while keeping the old cluster readable for an eight-week parallel run, and it cannot recopy the external table data. In a pilot, the team copied 50 managed tables and upgraded the metastore; afterward, 1,800 managed tables appeared as external, ACID inserts failed on several tables, and Sentry roles did not map to Ranger. The security team will not approve a migration that loses table-level audit or lets analysts see HR schemas. The business also wants Impala queries to remain available during cutover. What should the migration lead do?
1. Assess whether the pilot result is a blocker and how to sequence the migration of managed tables, external tables, and authorization.
Read the worked answer
Treat the pilot as a signal to fix migration mechanics, not as a reason to abandon CDP. Hive 3 changes table semantics: managed tables are transactional/ACID by default and external tables are not. Seeing managed tables appear as external usually means the migration tooling or metastore upgrade path converted them, or the tables were created with an explicit LOCATION; confirm with DESCRIBE FORMATTED and the Hive schema tool output before changing anything. Sequence: (1) inventory every table by type, owner, location, ACID usage, and Sentry privilege; (2) back up the metastore and freeze DDL; (3) migrate the metastore with the supported CDP upgrade path; (4) convert or recreate managed tables deliberately, validating ACID inserts on a sample; (5) for external tables, do not copy data-create them in the new metastore pointing at the same HDFS paths, then validate row counts and partitions; (6) recreate views after base tables; (7) migrate Sentry roles to Ranger with the supported tooling, then test least privilege. Keep the old cluster read-only for BI and run Impala on the new cluster only after validation. Do not dual-write managed tables during parallel run; that creates irreconcilable ACID state.
2. The security team asks how to prove table-level auditing and prevent HR schema exposure after cutover. What concrete controls and validation would you put in place?
Read the worked answer
Use a persona-based test matrix, not a policy screenshot. In Ranger, create Hive and Impala policies for each Sentry role, plus HDFS policies for the underlying paths, because Hive/Impala authorization does not replace file-system checks. Add column masking and row filters for HR and PII columns, and tag-based policies via Atlas where tags are reliable. Set the default to deny, and remove broad public grants. Enable Ranger audits to Solr or HDFS and verify each test records user, operation, database/table, column, and allow/deny. Validate with at least four personas: HR analyst (should see masked data), finance analyst (no HR access), ETL service account (write only to staging), and auditor (read audit, no data). Compare the Sentry role export to Ranger policies line by line, and run negative tests-queries that must fail. Keep an export of Ranger policies in version control so cutover and rollback are reproducible.
3. What cutover and rollback criteria would you define for the eight-week parallel run?
Read the worked answer
Define exit criteria before the parallel run: 100% of tier-1 queries return identical row counts and schemas; ACID insert/update/delete tests pass; Ranger negative and positive tests pass; Impala p95 latency is within 10% of baseline at 40 concurrent users; no audit gaps for 72 hours; and metastore backups restore in a drill. Rollback triggers: any security regression, more than 5% tier-1 query failure, or ACID corruption. Rollback plan: keep old cluster and metastore intact and read-only; preserve JDBC/DNS cutover scripts; export Ranger policies and new metastore before cutover; define how any new writes on the new cluster are reversed or replayed. Run cutover in a maintenance window with a named decision owner, and do not decommission the old cluster until the eight-week parallel run and a post-cutover audit are complete.