Hadoop

ZooKeeper 사용 시 “jute.maxbuffer"라는 설정이 있다. ZooKeeper 클라이언트 또는 서버 측에서 설정 가능하며, 클라이언트 측 설정값은 서버 측보다 낮아야 한다. 클라이언트가 이 설정값보다 큰 데이터를 받으면 오류가 발생한다. 관련 이슈: https://issues.apache.org/jira/browse/HIVE-21993 https://issues.apache.org/jira/browse/YARN-2962 이러한 오류를 방지하기 위해 ZooKeeper에서 다음 지표를 모니터링해야 한다. last_client_response_size 또는 max_client_response_size client_response_size는 ZooKeeper 서버에서 클라이언트로의 응답 크기(바이트)다. last_proposal_size 또는 max_proposal_size proposal_size는 ZooKeeper 서버 리더가 팔로워로 보내는 proposal 크기(바이트)다. proposal에 대한 자세한 내용은 https://zookeeper.apache.org/doc/r3.7.1/zookeeperInternals.html 참고. 이 값들은 jute.maxbuffer보다 낮아야 한다. 이 설정은 -Djute.maxbuffer=10485760 (10MB)와 같은 JVM 인자로 설정할 수 있다.

MySQL Index Hive Metastore가 RDBMS에 메타데이터를 저장/조회할 때 비용이 큰 작업이 있다. 다음은 관련 공식 Hive 패치의 인덱스 생성 SQL이다. -- HIVE-21063 CREATE UNIQUE INDEX `NOTIFICATION_LOG_EVENT_ID` ON NOTIFICATION_LOG (`EVENT_ID`) USING BTREE; -- HIVE-21487 CREATE INDEX COMPLETED_COMPACTIONS_RES ON COMPLETED_COMPACTIONS (CC_DATABASE,CC_TABLE,CC_PARTITION); -- HIVE-27165 DROP INDEX TAB_COL_STATS_IDX ON TAB_COL_STATS; CREATE INDEX TAB_COL_STATS_IDX ON TAB_COL_STATS (DB_NAME, TABLE_NAME, COLUMN_NAME, CAT_NAME) USING BTREE; DROP INDEX PCS_STATS_IDX ON PART_COL_STATS; CREATE INDEX PCS_STATS_IDX ON PART_COL_STATS (DB_NAME,TABLE_NAME,COLUMN_NAME,PARTITION_NAME,CAT_NAME) USING BTREE; Hive 업그레이드 시 RDBMS 테이블에 변경사항이 있을 수 있다. 버전별 필요한 SQL은 https://github.com/apache/hive/tree/master/standalone-metastore/metastore-server/src/main/sql/mysql 에서 확인 가능하다. ...

https://web.mit.edu/kerberos/krb5-1.13/doc/admin/princ_dns.html 운영 체제 버그로 인해 rdns = false 설정이 reverse DNS lookup을 비활성화하지 못할 수 있다. 일부 GNU libc 버전의 getaddrinfo()는 필요하지 않은 경우에도 PTR 레코드를 조회하는 버그가 있다. MIT Kerberos 릴리스 krb5-1.10.2 이상 및 krb5-1.9.x 시리즈(krb5-1.9.4 이상)에는 이 문제에 대한 해결 방법이 포함되어 있다. Hadoop 생태계에서 krb5.conf의 “rdns = false"가 적용되지 않는 경우가 있다. /etc/hosts를 수정하거나 PTR 레코드를 등록하여 해결할 수 있다. 1. HiveMetaStoreClient https://github.com/apache/hive/blob/rel/release-3.1.3/standalone-metastore/src/main/java/org/apache/hadoop/hive/metastore/HiveMetaStoreClient.java#L246 if (uriResolverHook != null) { metastoreURIArray.addAll(uriResolverHook.resolveURI(tmpUri)); } else { metastoreURIArray.add(new URI( tmpUri.getScheme(), tmpUri.getUserInfo(), HadoopThriftAuthBridge.getBridge().getCanonicalHostName(tmpUri.getHost()), tmpUri.getPort(), tmpUri.getPath(), tmpUri.getQuery(), tmpUri.getFragment() )); } metastore.thrift.uris 또는 hive.metastore.uris에서 canonical hostname을 확인하는 로직이 있다. 해결된 hostname이 원하는 대로 나오지 않는다면 다음 가지 해결 방법이 있다. ...

HDFS 재시작 없이 설정 변경 (reconfigure) https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSCommands.html 재시작 없이 변경 가능한 key는 제한적임 $ hdfs dfsadmin -reconfig namenode nn1.example.com:8020 properties Node [nn1.example.com:8020] Reconfigurable properties: dfs.block.placement.ec.classname dfs.block.replicator.classname dfs.heartbeat.interval dfs.image.parallel.load dfs.namenode.avoid.read.slow.datanode dfs.namenode.block-placement-policy.exclude-slow-nodes.enabled dfs.namenode.heartbeat.recheck-interval dfs.namenode.max.slowpeer.collect.nodes dfs.namenode.replication.max-streams dfs.namenode.replication.max-streams-hard-limit dfs.namenode.replication.work.multiplier.per.iteration dfs.storage.policy.satisfier.mode fs.protected.directories hadoop.caller.context.enabled ipc.8020.backoff.enable

https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/UnixShellGuide.html#HADOOP_CLASSPATH Hadoop 생태계에서 HADOOP_CLASSPATH 환경 변수는 다양한 곳에서 사용된다. Hive도 이 변수를 사용한다. beeline 같은 스크립트에서 HADOOP_CLASSPATH 변수가 어떻게 사용되는지 궁금했다. Hive 소스 코드에서는 HADOOP_CLASSPATH 변수를 찾을 수 없었다. 알고 보니 beeline 실행 시 hadoop jar 명령을 사용한다. (https://github.com/apache/hive/blob/rel/release-3.1.3/bin/ext/beeline.sh#L35) 이때 RunJar.java가 사용되며, 여기서 HADOOP_CLASSPATH가 CLASSPATH 설정에 사용된다. (https://github.com/apache/hadoop/blob/rel/release-3.3.4/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/util/RunJar.java#L347-L351) Hadoop 생태계에서 RunJar#main을 사용하는 경우, 대부분 HADOOP_CLASSPATH 환경 변수를 따르게 된다.

참고 https://docs.cloudera.com/cloudera-manager/7.5.5/security-troubleshooting/cm-security-troubleshooting.pdf https://search-guard.com/elasticsearch-kibana-kerberos/ Hadoop 데몬(NameNode, DataNode, JournalNode, ResourceManager, NodeManager 등)이 동일한 kerberos keytab(/etc/security/keytabs/spnego.service.keytab)과 principal(HTTP/_HOST@{REALM})을 공유하기 때문에 발생하는 문제로 추정된다. 특정 상황에서 DataNode가 이를 replay attack으로 오판한다. 다음 JVM 시스템 속성을 Hadoop 데몬에 추가하면 해결된다. Java 프로세스가 replay cache를 사용하지 않게 된다. -Dsun.security.krb5.rcache=none