使用Internal Impala table相较External Impala table有何缺陷？

你提到的内表支持Merge单列更新、内置查询优化与查询缓存的优势确实成立，但在实际生产场景中，内表对比外表存在几个无法忽略的缺陷：

• 数据删除风险极高，生命周期强绑定
  内表属于Impala全权托管的表，执行DROP TABLE、TRUNCATE TABLE操作时，会同步删除HDFS、对象存储等底层介质上的所有实际数据文件，没有兜底恢复机制。如果是多引擎（Hive、Spark、Flink等）共享数据的数仓环境，误删内表会直接导致所有关联任务全部失败，故障影响面极大。而外表执行删除操作时，只会清除Impala侧存储的元数据信息，底层数据文件完全不受影响，容错性高很多。
• 存储路径灵活性差，数据接入成本高
  内表默认只能存储在Impala配置的warehouse托管目录下，若不额外指定LOCATION参数，无法直接映射已经存在的业务数据——比如业务侧实时推送到固定HDFS路径的日志、其他计算任务产出的固定路径结果集，要接入内表必须先把文件移动到托管目录，或者执行LOAD DATA操作做数据导入，流程冗余。外表建表时可以直接指定任意合规存储路径，无需移动原有文件即可完成数据映射，接入存量数据的成本极低。
• 跨引擎共享适配性差，运维成本高
  内表的元数据、数据所有权完全归属Impala，其他计算引擎访问内表时必须严格同步Impala侧的元数据，一旦其他引擎直接修改了内表路径下的数据文件（比如Spark直接写入批处理结果），Impala侧会出现元数据与实际文件不一致的问题，必须手动执行INVALIDATE METADATA或REFRESH命令才能重新识别数据，运维复杂度高。外表本身就是对外部路径数据的映射，其他引擎只要有路径读写权限就可以正常操作数据，元数据冲突概率低，适配多引擎协同的场景更顺畅。
• 底层数据运维灵活度不足
  针对底层数据的批量操作，比如冷数据归档、历史批次数据替换、坏数据清理等场景，直接操作内表托管路径下的文件很容易破坏Impala的元数据映射逻辑，触发查询报错。而外表路径下的文件可以直接做增删、移动、归档操作，操作完成后只要刷新一次元数据即可正常查询，做数据运维的灵活度远高于内表。

注：如果你的场景是Impala专属的、不需要和其他引擎共享数据、对更新性能和查询速度要求极高的AD-Hoc查询类业务，内表的优势可以完全覆盖以上缺陷；如果是多引擎协同的数仓生产链路，更推荐使用外表规避上述风险。

内容的提问来源于stack exchange，提问作者Anuj Mehra