<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>question Re: hadoop where to provide connection encoding in Support Questions</title>
    <link>https://community.cloudera.com/t5/Support-Questions/hadoop-where-to-provide-connection-encoding/m-p/215002#M176914</link>
    <description>&lt;P&gt;Hi &lt;A rel="user" href="https://community.cloudera.com/users/62318/gaurangnshah.html" nodeid="62318"&gt;@Gaurang Shah&lt;/A&gt;,&lt;/P&gt;&lt;P&gt;we need to note three main things on this character-encoding issue, that&lt;/P&gt;&lt;P&gt;1. What type of data we have in HDFS/Hive &lt;/P&gt;&lt;P style="margin-left: 40px;"&gt;On this context if the data is originally UTF8 encoded and stored as UTF8 coded data, there should not be an issue, however in some cases we load the linguistic encoding into Hive (it supports) and try to read the data in different encoding technique, such cases you will visualize the data with some weird characters, such cases we must ensure that we have provided the proper configuration to the de-serialize so that it can extract the accurate data(with out making any traslations)&lt;/P&gt;&lt;P style="margin-left: 40px;"&gt;for that you must specify at hive table level with serde properties &lt;/P&gt;&lt;PRE&gt;ROW FORMAT SERDE "org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe" WITH SERDEPROPERTIES("serialization.encoding"='UTF-8');&lt;/PRE&gt;&lt;P&gt;UTF-8 can be any other char-set which is supported by serde library. &lt;/P&gt;&lt;P&gt;2. Letting the Sqoop know your character set&lt;/P&gt;&lt;P style="margin-left: 20px;"&gt;This will ensure that the character set is encoded and decoded with same encoding module.&lt;/P&gt;&lt;P style="margin-left: 20px;"&gt;on the sqoop import/export following property will ensure that you are not translating from one charector set to other and causing the untranslatable / any other junk mocked-up characters(described &lt;A href="https://sqoop.apache.org/docs/1.4.3/SqoopUserGuide.html#_controlling_the_import_process" target="_blank"&gt;here&lt;/A&gt;).&lt;/P&gt;&lt;PRE&gt;--default-character-set=utf8&lt;/PRE&gt;&lt;P&gt;3. Target Character Set&lt;/P&gt;&lt;P style="margin-left: 20px;"&gt;Ensure that your, target table (in netezza/Teradata/Oracle) has the same character set defined for the column properties, so that it wont reject while loading the data, in most of the casess this is the root-cause for the failures,&lt;/P&gt;&lt;P style="margin-left: 20px;"&gt;on the other note - though you did not check first and second points which mentioned above you still will be able to load the data into target by making sure that target (Netezza )support rich-character set, but that doesnt mean that we have loaded the data as is ( instead we truncated and load)&lt;/P&gt;&lt;P style="margin-left: 20px;"&gt;&lt;/P&gt;&lt;P style="margin-left: 20px;"&gt;while exporting the data you may use the hcat/query so that it can enforce the serde properties while extracting the data.&lt;/P&gt;&lt;P style="margin-left: 20px;"&gt;Hope this helps !!&lt;/P&gt;</description>
    <pubDate>Wed, 11 Apr 2018 07:17:43 GMT</pubDate>
    <dc:creator>bkosaraju</dc:creator>
    <dc:date>2018-04-11T07:17:43Z</dc:date>
  </channel>
</rss>

