Member since
10-11-2022
137
Posts
22
Kudos Received
14
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 261 | 06-05-2026 04:08 AM | |
| 453 | 05-05-2026 03:16 AM | |
| 459 | 05-05-2026 02:33 AM | |
| 581 | 08-19-2025 01:50 AM | |
| 2096 | 11-07-2024 10:00 PM |
07-01-2026
09:17 PM
@solardelune This is a great question. The behavior you are observing is actually working exactly as designed by Impala's Admission Controller. It comes down to how the admission controller "clamps" user limits and how the query planner interacts with the MEM_LIMIT parameter. Here is exactly why your query is clamping to 2GiB, why the estimates change, and how to fix it 1. Why your limit was set to 2GiB (The Clamping Behavior) When you configure min-query-mem-limit (2GiB) and max-query-mem-limit (57GiB), you establish a strict memory floor and ceiling for queries running in that specific resource pool You mentioned that you tried setting the limit to 10000000. Because MEM_LIMIT takes values in bytes if no suffix is provided, 10000000 evaluates to just 10 MB By default, Impala has a setting called Clamp MEM_LIMIT Query Option enabled . If a user sets a MEM_LIMIT that falls outside of your configured min/max range, the Admission Controller forcefully "clamps" the limit back into the allowed boundaries . Because your requested 10 MB fell far below the 2GiB minimum, the admission controller clamped it up to your 2GiB floor . Since this was a heavy query, 2GiB was not enough memory to complete the operation, resulting in an Out-Of-Memory (OOM) error. 2. Why the memory estimate changes when you SET MEM_LIMIT It is completely normal that your estimated memory changes when you manually execute SET MEM_LIMIT=4G or 8G When you set an explicit MEM_LIMIT, Impala's query planner takes this hard boundary into account when constructing the execution strategy. Knowing the memory ceiling changes how the planner assigns internal resources—such as when to activate the "spill-to-disk" mechanism or how to size internal memory buffers . Because the underlying query plan adapts to accommodate your new limit, the resulting memory estimate changes as well. In fact, the Impala error logs explicitly warn that "changing the mem_limit may also change the plan" 3. How to make the daemon use the higher memory limits To stop your queries from OOMing and allow them to utilize up to your 57GiB maximum, you have two options: Option A (Manual Override): Explicitly set the MEM_LIMIT for your heavy query to a value between 2GiB and 57GiB using the correct size suffixes (e.g., SET MEM_LIMIT=30G;) . Because 30 GB is comfortably within your boundaries, the Admission Controller will not clamp it, and your query will be granted the 30 GB needed to execute safely Option B (Automatic Estimation via Statistics): If you do not set a MEM_LIMIT, the Admission Controller relies entirely on the planner's memory estimate to decide how much memory to set aside . If your heavy query is only being assigned a 4GB estimate automatically but requires much more, it means your table statistics are missing, stale, or corrupt. You must run the COMPUTE STATS statement on the tables involved in the query . Accurate statistics allow the planner to correctly calculate a much higher memory estimate, which the Admission Controller will then automatically grant within your 2GiB to 57GiB window
... View more
06-05-2026
06:54 AM
Glad that you implemented. The reference in nifi.properties is something like nifi-kv/default/nifi.security.keystorePasswd. Inside Vault, the secret must have the password under the correct key name (usually value by default for KV v1 in NiFi's client). If you stored it under a different key (e.g., password, secret, or custom), it won't pull the right value. Extra spaces, newlines, or character encoding differences when the value was stored in Vault vs. the original plaintext password For many PKCS12 keystores, nifi.security.keyPasswd must match nifi.security.keystorePasswd. If only one is protected and they differ slightly, or if one resolves and the other doesn't, this error appears. Need to check the above. @TechStream
... View more
06-05-2026
04:08 AM
2 Kudos
@AlokKumar Templates (XML) have been completely removed in Apache NiFi 2.x (including 2.8.0). They are replaced by JSON Flow Definitions. Quick Export/Import (closest to the old template workflow) Export Right-click the Process Group → Download Flow Definition. Choose Without external services (recommended) or With external services. Import Drag a new Process Group from the top toolbar onto the canvas. In the Create Process Group dialog, click the Browse/Upload icon (two boxes with upward arrow) next to the Name field. Select your .json file → Add. Double-click the new Process Group to enter it. Note: Controller Services are not auto-enabled after import — enable them manually. Sensitive properties may need re-entering. Recommended for Production: Use NiFi Registry for versioning and promoting flows across environments. References: https://nifi.apache.org/docs/nifi-docs/html/user-guide.html https://docs.cloudera.com/dataflow/cloud/develop-flow-definitions/topics/cdf-download-flow-definition.html
... View more
06-05-2026
03:59 AM
Apache NiFi 2.8.0 fully supports retrieving sensitive startup properties such as: nifi.security.keystorePasswd nifi.security.keyPasswd nifi.security.truststorePasswd directly from HashiCorp Vault KV during bootstrap/startup, so these values do not need to be stored in plain text in nifi.properties. HASHICORP_VAULT_KV Sensitive Property Provider This uses the bootstrap-level Vault integration, which resolves secrets very early in the startup process Configure conf/bootstrap-hashicorp-vault.conf (Vault URI, KV path, authentication method — e.g., Token, AppRole, or Certificate). Link it in bootstrap.conf nifi.bootstrap.protection.hashicorp.vault.conf=./conf/bootstrap-hashicorp-vault.conf Store the passwords in Vault KV (v1) using paths like nifi-kv/default/nifi.security.keystorePasswd Use the NiFi Toolkit encrypt-config tool with the HASHICORP_VAULT_KV protection scheme to replace plaintext values in nifi.properties with Vault references Start NiFi — the bootstrap process will fetch the secrets from Vault https://docs.cloudera.com/cfm/4.11.0/nifi-components-cfm/nifi-docs/toolkit-guide.html Search for HASHICORP_VAULT_KV — explicitly lists it as a supported scheme with bootstrap config details. @TechStream
... View more
05-05-2026
03:48 AM
1. Cloudera Operational Database backup guide: https://docs.cloudera.com/operational-database/cloud/managing-database/topics/cod-backing-up-table.html https://docs.cloudera.com/cdp-public-cloud/cloud/requirements-azure/topics/mc-az-minimal-setup-for-cloud-storage.html HBase snapshot export also covered in Runtime HBase backup docs. 2. Default backup location: Mainly stores cluster-level backups (Data Lake, FreeIPA, logs/telemetry). Not HBase table data. 3. Different container for manual backups: Use --snapshot-location abfss://[email protected]/path in snapshot/export command. No direct Hadoop config edit needed in CDP Public Cloud. 4. Give HBase rights Assign Storage Blob Delegator role to HBase Managed Identity (at Storage Account level). Grant Storage Blob Data Owner/Contributor on target container. Set POSIX ACLs (Execute + Read/Write) on root and target path via Storage Explorer. Verify IDBroker mapping for HBase user. Test access with hdfs dfs -ls on target path. Enable "Allow trusted Microsoft services" if option available. @MintberryCrunch
... View more
05-05-2026
03:16 AM
Enabling a CMK at the environment level is meant for new encryption use in that environment, not for changing how already running services are encrypted. It should not disrupt existing CDE, CDF, or CML services that are already deployed and running. Existing services generally continue using the encryption setup they already have. The CMK choice is typically applied to new resources or new clusters created after the CMK is configured. In practice, the main impact is on future deployments, not on the current installed services. The CMK setting is usually a one-time environment configuration for that environment. @Lorenzo_F
... View more
05-05-2026
02:33 AM
Use a pre‑created Customer Managed KMS Key (CMK) for secret encryption; with restricted IAM, Liftie cannot create the key automatically. In AWS KMS, create or select a symmetric CMK in the same region as the CDP environment. Edit the Compute Restricted IAM policy and in the statement RestrictedKMSPermissionsUsingCustomerProvidedKey, replace the placeholder with the exact CMK ARN. Make sure that statement includes KMS actions such as kms:CreateGrant, kms:DescribeKey, kms:Encrypt, kms:Decrypt, kms:ReEncrypt*, kms:GenerateDataKey*. On the CMK itself, edit the KMS key policy to allow the required service roles (for example AWSServiceRoleForAutoScaling and the EKS/EC2 roles used by CDP) to use the key with the same KMS actions. Re‑run the compute cluster activation; since skip‑validation is not supported here, it will only succeed once the CMK and all related permissions are correctly configured. If, after these changes, the error persists, the next step is to capture the environment name, CMK ARN, and the full key policy, and open a case with Cloudera Support @Lorenzo_F
... View more
02-24-2026
01:48 AM
@APentyala This error is not caused by the SCD Type-2 logic or the MERGE syntax itself. The message “Ambiguous column reference deal_yearnumber in tgt” usually indicates that the column exists more than once in the target table metadata. Please check whether deal_yearnumber (or the partition column) is defined both as a regular column and in the PARTITIONED BY section. Run DESCRIBE FORMATTED and SHOW CREATE TABLE to verify the schema. If the column appears twice or was altered previously, Hive may treat it as ambiguous during MERGE compilation. Recreating the table with a clean schema (ensuring the partition column is defined only once) typically resolves the issue.
... View more
02-08-2026
12:10 AM
@MarlinGomez For that CCA175 streaming scenario with inconsistent formats, cleansing/transforming to HDFS, better to go with Spark Structured Streaming + schema evolution as the most exam-realistic pick. It handles real-time ingestion efficiently via micro-batches, infers/evolves schemas on the fly (especially with JSON/Avro), and lets you apply transformations like filter/map before writing Parquet to HDFS. Separate ETL pipelines per format add too much complexity/overhead for exam constraints, and pure schema-on-read skips proactive cleansing. QuickStart with Kafka source, schema merging enabled: .option("mergeSchema", "true").writeStream... to HDFS.This nails the "perform ETL on data using Spark API" objective perfectly. Good luck on your prep.
... View more
09-05-2025
04:17 AM
In NiFi 2.4 and above, the built-in Jython (Python 2 interpreter) for ExecuteScript has been removed, so the traditional approach using inline Python is no longer supported. There is, however, a modern and robust alternative using NiFi's first-class Python processor support for attribute manipulation, or using Groovy/Clojure in ExecuteScript, or simply leveraging UpdateAttribute for simple logic. https://nifi.apache.org/nifi-docs/python-developer-guide.html https://nifi.apache.org/components/org.apache.nifi.processors.script.ExecuteScript/
... View more