Spark schema ការវិវត្តន៍ក្នុងការអនុវត្ត

អ្នកអានជាទីគោរព ថ្ងៃល្អ!

នៅក្នុងអត្ថបទនេះ ទីប្រឹក្សាឈានមុខគេនៃតំបន់អាជីវកម្ម Big Data Solutions របស់ Neoflex ពិពណ៌នាលម្អិតអំពីជម្រើសសម្រាប់ការកសាងរចនាសម្ព័ន្ធអថេរដោយប្រើប្រាស់ Apache Spark ។

ជាផ្នែកនៃគម្រោងវិភាគទិន្នន័យ ភារកិច្ចនៃការកសាងមុខហាងដោយផ្អែកលើទិន្នន័យដែលមានរចនាសម្ព័ន្ធរលុងជាញឹកញាប់កើតឡើង។

ជាធម្មតាទាំងនេះគឺជាកំណត់ហេតុ ឬការឆ្លើយតបពីប្រព័ន្ធផ្សេងៗ ដែលត្រូវបានរក្សាទុកជា JSON ឬ XML។ ទិន្នន័យ​ត្រូវ​បាន​ផ្ទុក​ឡើង​ទៅ Hadoop បន្ទាប់​មក​អ្នក​ត្រូវ​ការ​បង្កើត​មុខ​ហាង​ពី​ពួក​គេ​។ យើងអាចរៀបចំការចូលទៅកាន់កន្លែងតាំងបង្ហាញដែលបានបង្កើតឧទាហរណ៍តាមរយៈ Impala ។

ក្នុងករណីនេះ គ្រោងការណ៍នៃមុខហាងគោលដៅមិនត្រូវបានគេដឹងជាមុនទេ។ ជាងនេះទៅទៀត គ្រោងការណ៍នេះក៏មិនអាចគូរទុកជាមុនបានដែរ ព្រោះវាអាស្រ័យលើទិន្នន័យ ហើយយើងកំពុងដោះស្រាយជាមួយទិន្នន័យដែលមានរចនាសម្ព័ន្ធរលុងខ្លាំងទាំងនេះ។

ឧទាហរណ៍ ថ្ងៃនេះ ការឆ្លើយតបខាងក្រោមត្រូវបានកត់ត្រា៖

{source: "app1", error_code: ""}

ហើយថ្ងៃស្អែក ពីប្រព័ន្ធតែមួយមក ចម្លើយខាងក្រោម៖

{source: "app1", error_code: "error", description: "Network error"}

ជាលទ្ធផល វាលមួយបន្ថែមទៀតគួរតែត្រូវបានបន្ថែមទៅកន្លែងបង្ហាញ - ការពិពណ៌នា ហើយគ្មាននរណាម្នាក់ដឹងថាវានឹងមកឬអត់នោះទេ។

ភារកិច្ចនៃការបង្កើត storefront លើទិន្នន័យបែបនេះគឺពិតជាស្តង់ដារហើយ Spark មានឧបករណ៍មួយចំនួនសម្រាប់រឿងនេះ។ សម្រាប់ការវិភាគប្រភពទិន្នន័យ មានការគាំទ្រសម្រាប់ទាំង JSON និង XML ហើយសម្រាប់គ្រោងការណ៍ដែលមិនស្គាល់ពីមុន ការគាំទ្រសម្រាប់ schemaEvolution ត្រូវបានផ្តល់ជូន។

នៅ glance ដំបូង, ដំណោះស្រាយមើលទៅសាមញ្ញ។ អ្នកត្រូវយក Folder ជាមួយ JSON ហើយអានវាទៅក្នុង dataframe។ Spark នឹងបង្កើតគ្រោងការណ៍ បង្វែរទិន្នន័យដែលបានដាក់ចូលទៅក្នុងរចនាសម្ព័ន្ធ។ លើសពីនេះទៀត អ្វីគ្រប់យ៉ាងត្រូវរក្សាទុកនៅក្នុង parquet ដែលត្រូវបានគាំទ្រផងដែរនៅក្នុង Impala ដោយការចុះឈ្មោះមុខហាងនៅក្នុង Hive metastore ។

អ្វីគ្រប់យ៉ាងហាក់ដូចជាសាមញ្ញ។

ទោះជាយ៉ាងណាក៏ដោយ វាមិនច្បាស់ទេពីឧទាហរណ៍ខ្លីៗនៅក្នុងឯកសារ អ្វីដែលត្រូវធ្វើជាមួយបញ្ហាមួយចំនួនក្នុងការអនុវត្ត។

ឯកសារពិពណ៌នាអំពីវិធីសាស្រ្តមិនបង្កើត storefront ប៉ុន្តែដើម្បីអាន JSON ឬ XML ទៅក្នុង dataframe ។

ពោលគឺវាគ្រាន់តែបង្ហាញពីរបៀបអាន និងញែក JSON៖

df = spark.read.json(path...)

នេះគឺគ្រប់គ្រាន់ដើម្បីធ្វើឱ្យទិន្នន័យមានសម្រាប់ Spark ។

នៅក្នុងការអនុវត្ត ស្គ្រីបមានភាពស្មុគស្មាញជាងការអានឯកសារ JSON ពីថតឯកសារ និងបង្កើតស៊ុមទិន្នន័យ។ ស្ថានភាពមើលទៅដូចនេះ៖ មានមុខហាងជាក់លាក់រួចហើយ ទិន្នន័យថ្មីចូលមកជារៀងរាល់ថ្ងៃ ពួកគេត្រូវបន្ថែមទៅមុខហាងដោយមិនភ្លេចថាគ្រោងការណ៍អាចខុសគ្នា។

គ្រោងការណ៍ធម្មតាសម្រាប់ការសាងសង់កន្លែងតាំងបង្ហាញមានដូចខាងក្រោម:

ជំហាន 1 ។ ទិន្នន័យ​ត្រូវ​បាន​ផ្ទុក​ទៅ​ក្នុង Hadoop ជាមួយ​នឹង​ការ​ផ្ទុក​ឡើង​វិញ​ប្រចាំ​ថ្ងៃ​ជា​បន្ត​បន្ទាប់​និង​បាន​បន្ថែម​ទៅ​ភាគ​ថា​ស​ថ្មី​មួយ​។ វាប្រែចេញថតដែលមានទិន្នន័យដំបូងបែងចែកតាមថ្ងៃ។

ជំហាន 2 ។ កំឡុងពេលផ្ទុកដំបូង ថតនេះត្រូវបានអាន និងញែកដោយ Spark ។ ស៊ុមទិន្នន័យលទ្ធផលត្រូវបានរក្សាទុកជាទម្រង់ដែលអាចញែកបាន ឧទាហរណ៍នៅក្នុង parquet ដែលបន្ទាប់មកអាចត្រូវបាននាំចូលទៅក្នុង Impala ។ វាបង្កើតការបង្ហាញគោលដៅជាមួយនឹងទិន្នន័យទាំងអស់ដែលបានប្រមូលផ្តុំរហូតដល់ចំណុចនេះ។

ជំហាន 3 ។ ការទាញយកត្រូវបានបង្កើតឡើងដែលនឹងធ្វើបច្ចុប្បន្នភាពមុខហាងជារៀងរាល់ថ្ងៃ។
មានសំណួរនៃការបង្កើនការផ្ទុក តម្រូវការក្នុងការបែងចែកកន្លែងតាំងបង្ហាញ និងសំណួរនៃការថែរក្សាគ្រោងការណ៍ទូទៅនៃកន្លែងតាំងបង្ហាញ។

សូមលើកឧទាហរណ៍មួយ។ ចូរនិយាយថាជំហានដំបូងនៃការបង្កើតឃ្លាំងត្រូវបានអនុវត្តហើយឯកសារ JSON ត្រូវបានផ្ទុកឡើងទៅកាន់ថតឯកសារ។

ការបង្កើត dataframe ពីពួកវា បន្ទាប់មករក្សាទុកវាជាការបង្ហាញ មិនមែនជាបញ្ហាទេ។ នេះគឺជាជំហានដំបូងបំផុតដែលអាចត្រូវបានរកឃើញយ៉ាងងាយស្រួលនៅក្នុងឯកសារ Spark៖

df = spark.read.option("mergeSchema", True).json(".../*") 
df.printSchema()

root 
|-- a: long (nullable = true) 
|-- b: string (nullable = true) 
|-- c: struct (nullable = true) |    
|-- d: long (nullable = true)

អ្វីគ្រប់យ៉ាងហាក់ដូចជាល្អ។

យើងអាន និងញែក JSON បន្ទាប់មកយើងរក្សាទុក dataframe ជា parquet ដោយចុះឈ្មោះវានៅក្នុង Hive តាមមធ្យោបាយងាយស្រួលណាមួយ៖

df.write.format(“parquet”).option('path','<External Table Path>').saveAsTable('<Table Name>')

យើងទទួលបានបង្អួច។

ប៉ុន្តែនៅថ្ងៃបន្ទាប់ ទិន្នន័យថ្មីពីប្រភពត្រូវបានបន្ថែម។ យើង​មាន​ថត​ឯកសារ​ដែល​មាន JSON និង​ផ្ទាំង​បង្ហាញ​ដែល​បាន​បង្កើត​ពី​ថត​នេះ។ បន្ទាប់ពីផ្ទុកទិន្នន័យបណ្តុំបន្ទាប់ពីប្រភព Data mart បាត់ទិន្នន័យតម្លៃមួយថ្ងៃ។

ដំណោះស្រាយឡូជីខលគឺត្រូវបែងចែកមុខហាងតាមមួយថ្ងៃ ដែលនឹងអនុញ្ញាតឱ្យបន្ថែមភាគថាសថ្មីរៀងរាល់ថ្ងៃបន្ទាប់។ យន្តការសម្រាប់ការនេះត្រូវបានគេស្គាល់ផងដែរ Spark អនុញ្ញាតឱ្យអ្នកសរសេរភាគថាសដាច់ដោយឡែក។

ដំបូងយើងធ្វើការផ្ទុកដំបូងដោយរក្សាទុកទិន្នន័យដូចដែលបានពិពណ៌នាខាងលើដោយបន្ថែមតែការបែងចែកប៉ុណ្ណោះ។ សកម្មភាពនេះត្រូវបានគេហៅថាការចាប់ផ្តើម storefront ហើយត្រូវបានធ្វើតែម្តងគត់៖

df.write.partitionBy("date_load").mode("overwrite").parquet(dbpath + "/" + db + "/" + destTable)

នៅថ្ងៃបន្ទាប់ យើងផ្ទុកតែភាគថាសថ្មីប៉ុណ្ណោះ៖

df.coalesce(1).write.mode("overwrite").parquet(dbpath + "/" + db + "/" + destTable +"/date_load=" + date_load + "/")

អ្វីដែលនៅសេសសល់គឺត្រូវចុះឈ្មោះឡើងវិញនៅក្នុង Hive ដើម្បីធ្វើបច្ចុប្បន្នភាពគ្រោងការណ៍។
ទោះយ៉ាងណាក៏ដោយនេះគឺជាកន្លែងដែលបញ្ហាកើតឡើង។

បញ្ហាដំបូង។ មិនយូរមិនឆាប់ parquet លទ្ធផលនឹងមិនអាចអានបានទេ។ នេះគឺដោយសារតែរបៀបដែល parquet និង JSON ព្យាបាលវាលទទេខុសគ្នា។

ចូរយើងពិចារណាអំពីស្ថានភាពធម្មតា។ ឧទាហរណ៍ ម្សិលមិញ JSON មកដល់៖

День 1: {"a": {"b": 1}},

ហើយថ្ងៃនេះ JSON ដូចគ្នាមើលទៅដូចនេះ៖

День 2: {"a": null}

ឧបមាថាយើងមានភាគថាសពីរផ្សេងគ្នា ដែលនីមួយៗមានបន្ទាត់មួយ។
នៅពេលដែលយើងអានទិន្នន័យប្រភពទាំងមូល Spark នឹងអាចកំណត់ប្រភេទ ហើយនឹងយល់ថា "a" គឺជាវាលនៃប្រភេទ "structure" ជាមួយនឹងវាលដែលដាក់ "b" នៃប្រភេទ INT ។ ប៉ុន្តែប្រសិនបើភាគថាសនីមួយៗត្រូវបានរក្សាទុកដោយឡែកពីគ្នានោះយើងទទួលបាន parquet ជាមួយនឹងគ្រោងការណ៍ភាគមិនឆបគ្នា:

df1 (a: <struct<"b": INT>>)
df2 (a: STRING NULLABLE)

ស្ថានភាពនេះត្រូវបានគេស្គាល់យ៉ាងច្បាស់ ដូច្នេះជម្រើសមួយត្រូវបានបន្ថែមជាពិសេស - នៅពេលញែកទិន្នន័យប្រភព យកវាលទទេចេញ៖

df = spark.read.json("...", dropFieldIfAllNull=True)

ក្នុងករណីនេះ parquet នឹងមានភាគថាសដែលអាចអានជាមួយគ្នាបាន។
ថ្វីត្បិតតែអ្នកដែលបានធ្វើវានៅក្នុងការអនុវត្តនឹងញញឹមយ៉ាងជូរចត់នៅទីនេះក៏ដោយ។ ហេតុអ្វី? បាទ / ចាសព្រោះទំនងជាមានស្ថានភាពពីរទៀត។ ឬបី។ ឬបួន។ ទីមួយ ដែលស្ទើរតែនឹងកើតឡើង គឺថាប្រភេទលេខនឹងមើលទៅខុសគ្នានៅក្នុងឯកសារ JSON ផ្សេងៗគ្នា។ ឧទាហរណ៍ {intField: 1} និង {intField: 1.1} ។ ប្រសិនបើវាលបែបនេះត្រូវបានរកឃើញនៅក្នុងភាគថាសមួយ នោះការបញ្ចូលគ្នានៃគ្រោងការណ៍នឹងអានអ្វីគ្រប់យ៉ាងត្រឹមត្រូវដែលនាំទៅដល់ប្រភេទត្រឹមត្រូវបំផុត។ ប៉ុន្តែប្រសិនបើនៅក្នុងមួយផ្សេងគ្នា នោះមួយនឹងមាន intField: int ហើយមួយទៀតនឹងមាន intField: ទ្វេ។

មានទង់ខាងក្រោមដើម្បីដោះស្រាយស្ថានភាពនេះ៖

df = spark.read.json("...", dropFieldIfAllNull=True, primitivesAsString=True)

ឥឡូវនេះយើងមានថតដែលមានភាគថាសដែលអាចត្រូវបានអានចូលទៅក្នុង dataframe តែមួយនិង parquet ត្រឹមត្រូវនៃ showcase ទាំងមូល។ បាទ? ទេ

យើងត្រូវតែចងចាំថាយើងបានចុះឈ្មោះតារាងនៅក្នុង Hive ។ Hive មិនប្រកាន់អក្សរតូចធំនៅក្នុងឈ្មោះវាលទេ ខណៈពេលដែល parquet គឺប្រកាន់អក្សរតូចធំ។ ដូច្នេះ ភាគថាសដែលមានគ្រោងការណ៍៖ field1: int និង Field1: int គឺដូចគ្នាសម្រាប់ Hive ប៉ុន្តែមិនមែនសម្រាប់ Spark ទេ។ កុំភ្លេចបំប្លែងឈ្មោះវាលទៅជាអក្សរតូច។

បន្ទាប់ពីនោះអ្វីៗហាក់ដូចជាល្អ។

ទោះយ៉ាងណាក៏ដោយមិនមែនទាំងអស់សាមញ្ញទេ។ មានបញ្ហាទីពីរ ដែលគេស្គាល់ផងដែរ។ ដោយសារភាគថាសថ្មីនីមួយៗត្រូវបានរក្សាទុកដោយឡែកពីគ្នា ថតភាគថាសនឹងមានឯកសារសេវាកម្ម Spark ឧទាហរណ៍ ទង់ជោគជ័យប្រតិបត្តិការ _SUCCESS ។ នេះនឹងបណ្តាលឱ្យមានកំហុសនៅពេលព្យាយាម parquet ។ ដើម្បីជៀសវាងបញ្ហានេះ អ្នកត្រូវកំណត់រចនាសម្ព័ន្ធ ដើម្បីការពារ Spark ពីការបន្ថែមឯកសារសេវាកម្មទៅថត៖

hadoopConf = sc._jsc.hadoopConfiguration()
hadoopConf.set("parquet.enable.summary-metadata", "false")
hadoopConf.set("mapreduce.fileoutputcommitter.marksuccessfuljobs", "false")

វាហាក់ដូចជាថាឥឡូវនេះជារៀងរាល់ថ្ងៃ ភាគថាស parquet ថ្មីត្រូវបានបន្ថែមទៅថតឯកសារបង្ហាញគោលដៅ ដែលទិន្នន័យដែលបានញែកសម្រាប់ថ្ងៃនោះស្ថិតនៅ។ យើងបានយកចិត្តទុកដាក់ជាមុនថាមិនមានភាគថាសដែលមានជម្លោះប្រភេទទិន្នន័យទេ។

ប៉ុន្តែយើងមានបញ្ហាទីបី។ ឥឡូវនេះ គ្រោងការណ៍ទូទៅមិនត្រូវបានគេដឹងនោះទេ លើសពីនេះ តារាងនៅក្នុង Hive មានគ្រោងការណ៍មិនត្រឹមត្រូវ ដោយសារភាគថាសថ្មីនីមួយៗទំនងជាណែនាំការបង្ខូចទ្រង់ទ្រាយទៅក្នុងគ្រោងការណ៍។

អ្នកត្រូវចុះឈ្មោះតារាងឡើងវិញ។ នេះអាចត្រូវបានធ្វើដោយសាមញ្ញ: អាន parquet នៃ storefront ម្តងទៀត, យកគ្រោងការណ៍និងបង្កើត DDL ដោយផ្អែកលើវា, ជាមួយនឹងការដែលចុះឈ្មោះថតម្តងទៀតនៅក្នុង Hive ជាតារាងខាងក្រៅ, ធ្វើបច្ចុប្បន្នភាពគ្រោងការណ៍នៃ storefront គោលដៅ។

យើងមានបញ្ហាទីបួន។ នៅពេលដែលយើងបានចុះឈ្មោះតារាងជាលើកដំបូង យើងពឹងផ្អែកលើ Spark ។ ឥឡូវនេះយើងធ្វើវាដោយខ្លួនឯងហើយយើងត្រូវចាំថាវាល parquet អាចចាប់ផ្តើមជាមួយនឹងតួអក្សរដែលមិនត្រូវបានអនុញ្ញាតសម្រាប់ Hive ។ ឧទាហរណ៍ Spark បោះចោលបន្ទាត់ដែលវាមិនអាចញែកនៅក្នុងវាល "corrupt_record" ។ វាលបែបនេះមិនអាចត្រូវបានចុះឈ្មោះនៅក្នុង Hive ដោយមិនត្រូវបានរត់គេចខ្លួន។

ដោយដឹងរឿងនេះយើងទទួលបានគ្រោងការណ៍៖

f_def = ""
for f in pf.dtypes:
  if f[0] != "date_load":
    f_def = f_def + "," + f[0].replace("_corrupt_record", "`_corrupt_record`") + " " + f[1].replace(":", "`:").replace("<", "<`").replace(",", ",`").replace("array<`", "array<") 
table_define = "CREATE EXTERNAL TABLE jsonevolvtable (" + f_def[1:] + " ) "
table_define = table_define + "PARTITIONED BY (date_load string) STORED AS PARQUET LOCATION '/user/admin/testJson/testSchemaEvolution/pq/'"
hc.sql("drop table if exists jsonevolvtable")
hc.sql(table_define)

លេខកូដ ("_corrupt_record", "`_corrupt_record`") + " " + f[1].replace(":", "`:").replace("<", "<`").replace(",", ",`").ជំនួស("អារេ<`", "អារេ<") ធ្វើឱ្យ DDL មានសុវត្ថិភាព ពោលគឺជំនួសឱ្យ៖

create table tname (_field1 string, 1field string)

ជាមួយនឹងឈ្មោះវាលដូចជា "_field1, 1field" សុវត្ថិភាព DDL ត្រូវបានបង្កើតឡើងនៅកន្លែងដែលឈ្មោះវាលត្រូវបានគេចចេញ៖ បង្កើតតារាង `tname` (`_field1` string, `1field` string)។

សំណួរកើតឡើង: របៀបដើម្បីទទួលបានស៊ុមទិន្នន័យឱ្យបានត្រឹមត្រូវជាមួយនឹងគ្រោងការណ៍ពេញលេញ (នៅក្នុងកូដ pf)? តើធ្វើដូចម្តេចដើម្បីទទួលបាន pf នេះ? នេះគឺជាបញ្ហាទីប្រាំ។ អានឡើងវិញនូវគ្រោងការណ៍នៃភាគថាសទាំងអស់ពីថតឯកសារជាមួយនឹងឯកសារ parquet នៃកន្លែងតាំងបង្ហាញគោលដៅ? វិធីសាស្រ្តនេះគឺមានសុវត្ថិភាពបំផុត ប៉ុន្តែពិបាក។

គ្រោងការណ៍មានរួចហើយនៅក្នុង Hive ។ អ្នកអាចទទួលបានគ្រោងការណ៍ថ្មីដោយរួមបញ្ចូលគ្នានូវគ្រោងការណ៍នៃតារាងទាំងមូលនិងភាគថាសថ្មី។ ដូច្នេះ អ្នកត្រូវយកតារាង schema ពី Hive ហើយផ្សំវាជាមួយ schema នៃ partition ថ្មី។ នេះអាចត្រូវបានធ្វើដោយការអានទិន្នន័យមេតាសាកល្បងពី Hive រក្សាទុកវាទៅក្នុងថតបណ្តោះអាសន្ន ហើយប្រើ Spark ដើម្បីអានភាគថាសទាំងពីរក្នុងពេលតែមួយ។

តាមការពិតមានអ្វីគ្រប់យ៉ាងដែលអ្នកត្រូវការ: គ្រោងការណ៍តារាងដើមនៅក្នុង Hive និងភាគថាសថ្មី។ យើងក៏មានទិន្នន័យផងដែរ។ វានៅសល់តែដើម្បីទទួលបានគ្រោងការណ៍ថ្មីដែលរួមបញ្ចូលគ្នានូវគ្រោងការណ៍មុខហាង និងវាលថ្មីពីភាគថាសដែលបានបង្កើត៖

from pyspark.sql import HiveContext
from pyspark.sql.functions import lit
hc = HiveContext(spark)
df = spark.read.json("...", dropFieldIfAllNull=True)
df.write.mode("overwrite").parquet(".../date_load=12-12-2019")
pe = hc.sql("select * from jsonevolvtable limit 1")
pe.write.mode("overwrite").parquet(".../fakePartiton/")
pf = spark.read.option("mergeSchema", True).parquet(".../date_load=12-12-2019/*", ".../fakePartiton/*")

បន្ទាប់មក យើងបង្កើតតារាងចុះឈ្មោះ DDL ដូចនៅក្នុងអត្ថបទមុនដែរ។
ប្រសិនបើខ្សែសង្វាក់ទាំងមូលដំណើរការបានត្រឹមត្រូវ ពោលគឺមានការចាប់ផ្ដើមផ្ទុក ហើយតារាងត្រូវបានបង្កើតយ៉ាងត្រឹមត្រូវនៅក្នុង Hive នោះយើងទទួលបានតារាងតារាងដែលបានធ្វើបច្ចុប្បន្នភាព។

ហើយបញ្ហាចុងក្រោយគឺថាអ្នកមិនអាចគ្រាន់តែបន្ថែមភាគថាសទៅតារាង Hive ទេព្រោះវានឹងខូច។ អ្នកត្រូវបង្ខំ Hive ដើម្បីជួសជុលរចនាសម្ព័ន្ធភាគរបស់វា៖

from pyspark.sql import HiveContext
hc = HiveContext(spark) 
hc.sql("MSCK REPAIR TABLE " + db + "." + destTable)

ភារកិច្ចសាមញ្ញនៃការអាន JSON និងបង្កើតមុខហាងដោយផ្អែកលើវានាំឱ្យយកឈ្នះលើការលំបាកមួយចំនួនដែលជាដំណោះស្រាយដែលអ្នកត្រូវរកមើលដោយឡែកពីគ្នា។ ហើយទោះបីជាដំណោះស្រាយទាំងនេះមានលក្ខណៈសាមញ្ញក៏ដោយ ក៏វាត្រូវការពេលច្រើនដើម្បីស្វែងរកពួកគេ។

ដើម្បី​អនុវត្ត​ការ​សាងសង់​បន្ទប់​តាំង​បង្ហាញ ខ្ញុំ​ត្រូវ​៖

• បន្ថែមភាគថាសទៅកន្លែងតាំងបង្ហាញ កម្ចាត់ឯកសារសេវាកម្ម
• ដោះស្រាយជាមួយវាលទទេនៅក្នុងទិន្នន័យប្រភពដែល Spark បានវាយបញ្ចូល
• បោះប្រភេទសាមញ្ញទៅខ្សែអក្សរ
• បំប្លែងឈ្មោះវាលទៅជាអក្សរតូច
• ការបញ្ចូលទិន្នន័យដាច់ដោយឡែក និងការចុះឈ្មោះតារាងក្នុង Hive (ជំនាន់ DDL)
• កុំភ្លេចគេចពីឈ្មោះវាលដែលអាចមិនត្រូវគ្នាជាមួយ Hive
• ស្វែងយល់ពីរបៀបធ្វើបច្ចុប្បន្នភាពការចុះឈ្មោះតារាងនៅក្នុង Hive

សរុបមក យើងកត់សម្គាល់ថាការសម្រេចចិត្តសាងសង់បង្អួចហាងគឺពោរពេញដោយភាពលំបាកជាច្រើន។ ដូច្នេះក្នុងករណីមានការលំបាកក្នុងការអនុវត្ត វាជាការប្រសើរក្នុងការទាក់ទងដៃគូដែលមានបទពិសោធន៍ជាមួយអ្នកជំនាញជោគជ័យ។

សូមអរគុណសម្រាប់ការអានអត្ថបទនេះ យើងសង្ឃឹមថាអ្នករកឃើញព័ត៌មានមានប្រយោជន៍។

ប្រភព: www.habr.com