一、mysql中怎么直接查看一个表的字符集
基本上现在的字符集MySQL都支持，查看MySQL支持的字符集列表，有两种方法：
1.SQL语句
2.查看元数据字典表
查询结果：
1）第一列代表字符集名字；
2）第二列表示字符集排序规则；
3）第三列表示字符集描述；
二、详细介绍oracle数据库字符集
一什么是oracle字符集
Oracle字符集是一个字节数据的解释的符号集合有大小之分有相互的包容关系ORACLE支持国家语言的体系结构允许你使用本地化语言来存储处理检索数据它使数据库工具错误消息排序次序日期时间货币数字和日历自动适应本地化语言和平台
影响oracle数据库字符集最重要的参数是NLS_LANG参数它的格式如下:
NLS_LANG=language_territorycharset
它有三个组成部分(语言地域和字符集)每个成分控制了NLS子集的特性其中:
Language指定服务器消息的语言territory指定服务器的日期和数字格式charset指定字符集如:AMERICAN_AMERICAZHSGBK
从NLS_LANG的组成我们可以看出真正影响数据库字符集的其实是第三部分所以两个数据库之间的字符集只要第三部分一样就可以相互导入导出数据前面影响的只是提示信息是中文还是英文
二如何查询Oracle的字符集
很多人都碰到过因为字符集不同而使数据导入失败的情况这涉及三方面的字符集一是oracelserver端的字符集二是oracleclient端的字符集;三是dmp文件的字符集在做数据导入的时候需要这三个字符集都一致才能正确导入
查询oracleserver端的字符集
有很多种方法可以查出oracleserver端的字符集比较直观的查询方法是以下这种:SQL>selectuserenv(language)fromdual;
结果类似如下:AMERICAN_AMERICAZHSGBK
如何查询dmp文件的字符集
用oracle的exp工具导出的dmp文件也包含了字符集信息dmp文件的第和第个字节记录了dmp文件的字符集如果dmp文件不大比如只有几M或几十M可以用UltraEdit打开(进制方式)看第第个字节的内容如然后用以下SQL查出它对应的字符集:
SQL>selectnls_charset_name(to_number(xxxx))fromdual;
ZHSGBK
如果dmp文件很大比如有G以上(这也是最常见的情况)用文本编辑器打开很慢或者完全打不开可以用以下命令(在unix主机上):
catexpdmp|odx|head|awk{print$$}|cutc
然后用上述SQL也可以得到它对应的字符集
查询oracleclient端的字符集
这个比较简单在windows平台下就是注册表里面相应OracleHome的NLS_LANG还可以在dos窗口里面自己设置比如:
setnls_lang=AMERICAN_AMERICAZHSGBK
这样就只影响这个窗口里面的环境变量
在unix平台下就是环境变量NLS_LANG
$echo$NLS_LANG
AMERICAN_AMERICAZHSGBK
如果检查的结果发现server端与client端字符集不一致请统一修改为同server端相同的字符集
三修改oracle的字符集
上文说过oracle的字符集有互相的包容关系如usascii就是zhsgbk的子集从usascii到zhsgbk不会有数据解释上的问题不会有数据丢失在所有的字符集中utf应该是最大因为它基于unicode双字节保存字符(也因此在存储空间上占用更多)
一旦数据库创建后数据库的字符集理论上讲是不能改变的因此在设计和安装之初考虑使用哪一种字符集十分重要根据Oracle的官方说明字符集的转换是从子集到超集受支持反之不行如果两种字符集之间根本没有子集和超集的关系那么字符集的转换是不受oracle支持的对数据库server而言错误的修改字符集将会导致很多不可测的后果可能会严重影响数据库的正常运行所以在修改之前一定要确认两种字符集是否存在子集和超集的关系一般来说除非万不得已我们不建议修改oracle数据库server端的字符集特别说明我们最常用的两种字符集ZHSGBK和ZHSCGB之间不存在子集和超集关系因此理论上讲这两种字符集之间的相互转换不受支持
修改server端字符集(不建议使用)
在oracle之前可以用直接修改数据字典表props$来改变数据库的字符集但oracle之后至少有三张系统表记录了数据库字符集的信息只改props$表并不完全可能引起严重的后果正确的修改方法如下:
$sqlplus/nolog
SQL>conn/assysdba;
若此时数据库服务器已启动则先执行SHUTDOWNIMMEDIATE命令关闭数据库服务器然后执行以下命令:
SQL>STARTUPMOUNT;
SQL>ALTERSYSTEMENABLERESTRICTEDSESSION;
SQL>ALTERSYSTEMSETJOB_QUEUE_PROCESSES=;
SQL>ALTERSYSTEMSETAQ_TM_PROCESSES=;
SQL>ALTERDATABASEOPEN;
SQL>ALTERDATABASECHARACTERSETZHSGBK;
SQL>ALTERDATABASEnationalCHARACTERSETZHSGBK;
SQL>SHUTDOWNIMMEDIATE;
SQL>STARTUP
修改dmp文件字符集
上文说过dmp文件的第第字节记录了字符集信息因此直接修改dmp文件的第第字节的内容就可以骗过oracle的检查这样做理论上也仅是从子集到超集可以修改但很多情况下在没有子集和超集关系的情况下也可以修改我们常用的一些字符集如USASCIIWEISOPZHSCGBZHSGBK基本都可以改因为改的只是dmp文件所以影响不大
具体的修改方法比较多最简单的就是直接用UltraEdit修改dmp文件的第和第个字节比如想将dmp文件的字符集改为ZHSGBK可以用以下SQL查出该种字符集对应的进制代码:
SQL>selectto_char(nls_charset_id(ZHSGBK)xxxx)fromdual;
然后将dmp文件的字节修改为即可
lishixinzhi/Article/program/Oracle/201311/17875
字节跳动数据中台的DataCatalog系统搜索实践
2022-11-2115:24·字节跳动技术团队1.背景
DataCatalog能够帮助大公司更好地梳理和管理自己的资产，是Data-drvien公司的重要平台。一个通用的DataCatalog平台通常包含元数据管理，搜索，血缘，标签，术语等功能。其中，搜索是DataCatalog的入口功能，承担着让用户“找到数”的主要能力。在字节跳动数据中台的DataCatalog系统中，每天有70%以上的用户会使用搜索功能。2.功能要求业界主要的AugmentedDataCatalog需要支持Google一样的搜索体验来搜索数据资产，以满足不同角色的用户的找数需求。我们的系统也一样，搜索需要支持的主要功能包括：支持多种不同类型资产的搜索。目前系统中已经包含15+种数据源，可以分为几大类：数仓表比如Hive、看板、数据集、实时表、Topic、对象存储、分布式文件系统如LasFS等。带来的主要挑战是不同类型的资产，搜索的字段和权重有明显差异。支持个性化。目前系统的用户遍布整个公司，角色涵盖数据工程师、数据分析师、产品经理、项目经理、销售和数据科学家等等，需要完成的数据工作任务差异也比较大，比如数据开发、数据治理、BI、数据分析和机器学习等等，因此个性化对DataCatalog的搜索尤为重要。支持各种业务元数据的高级筛选。数据资产除了名称/别名/描述等字段，通常还会有一些业务元数据，如项目/业务域/负责人/负责人部门/标签/业务术语/生命周期状态等。通过支持指定业务元数据进行筛选，帮助用户减小搜索范围，更快搜到对应资产。支持秒级的实时性。这里的实时性是指元数据的变更需要在秒级别反映到DataCatalog的搜索里，例如新建表需要在操作完成后1～2秒内即能搜到相应的表，删除表需要不再显示在搜索结果中。原因是用户新建或更新资产后通常会到我们的系统上查看相应的变更是否生效。用户手动在浏览器操作搜索的时间通常是秒级，超过这个时间会给用户带来困惑，降低整个DataCatalog的使用体验。支持Google类似的搜索推荐(Typeasyousearch)功能。搜索补全功能是搜索的一个导航功能，可以在用户键入内容时提示他们可以输入的相关内容，从而提高搜索精度。这个功能对响应速度有一定的要求，同时由于数据资产的特殊性，前缀相同的资产数量较多，因此也需要根据资产的热度进行一定的排序。支持多租户。我们的系统不仅供公司内部使用，也提供公有云服务，因此支持多租户也是搜索的一个P0需求。支持多语言。数据资产的名称/描述/标签/术语等需要支持多种语言，搜索的输入也可能是不同的语言，最常用的比如英文和中文。不同语言的分词，专有名词字典，文本特征等都会带来一些挑战。3.个性化的综合搜索为了满足上述需求，我们的系统采用了个性化综合搜索的方案。区别于联合搜索（federatedsearch），用户需要指定搜索的具体资产类型或在搜索结果页对不同的资产分栏显示，综合搜索（unifiedsearch）允许用户在一个搜索框中进行搜索输入而无需指定搜索的资产类型，同时，搜索服务会在同一个搜索结果页返回不同类型的相关资产，并根据匹配程度和用户的个性化数据进行混合排序。优势是能给不同的用户针对不同资产的搜索需求提供统一的搜索体验，同时提供了用户跨类型圈定资产的能力。另外，综合搜索使得我们可以在页面上进行标准化透出，从而我们可以从技术上进行搜索标准化，达到新数据源接入即可搜索。3.1架构3.1.1整体架构我们的搜索系统使用了开源的搜索引擎Elasticsearch进行基础的文档检索（Recall阶段），因此各种资产元数据会被存放到Elasticsearch中。整个系统包括4个主要的数据流程：实时导入。资产元数据变更时相应的平台发出实时变更消息，DataCatalog系统会消费变更消息，通过ingestion服务更新Elasticsearch中的文档，以此来达到搜索实时性秒级的需求。离线导入。实时导入的过程中可能会遇到网络波动等不可控因素导致更新失败，因此需要定时的任务来检查和增量更新缺失的元数据。用户行为记录。记录用户搜索点击日志，用来后续进行搜索的Badcasereview和模型训练。这部分采用了前端埋点和服务端埋点结合的方式。前端埋点有成熟的内部框架，埋点数据流入离线数仓表，缺点是这部分数据要经过离线任务T+1才能使用。服务端埋点数据直接进入Elasticsearch，即时可用，同时在不支持前端埋点的场景（如ToB场景），可以成为主要的埋点数据收集方式。线上搜索服务。提供搜索相关的线上服务，在后文详细解释这部分。3.1.2服务架构上图是线上搜索服务的主要组件图。整个搜索服务分为三个大的服务：搜索推荐服务、聚合服务和搜索服务。
1.搜索推荐服务（Typeasyousearch）。搜索推荐服务对性能有一定的要求，通常来说补全的请求完成时间不能超过200ms，超过了用户就会有比较明显的延迟感。因此不能直接使用搜索接口实现，我们的系统里是基于Elasticsearch的Contextsuggester实现的。除此之外，还有两个问题需要重点考虑：
（1）基于浏览的热度排序。页面上能够推荐的词数是有限的，通常是10个，在输入较短时，候选的推荐词通常会超过这个限制，因此通过资产的浏览热度来排序可以提高搜索推荐的准确率，改善用户的搜索体验。（2）时序问题。一次搜索过程中会有一连串的搜索推荐请求，服务端会并行的处理这些请求，通常更长的输入由于候选推荐词更少服务端响应反而更快，在用户输入较快的时候（比如连续的删除字符），前端先发出的请求可能会后返回，因此可能造成输入停止后推荐的词与输入不匹配。我们的方案是前端在根据服务端响应刷新数据时需要检查返回的输入与当前输入框内容是否一致，从而保持最终一致性。2.聚合服务。聚合服务根据输入和筛选项提供搜索过程中需要用到的统计数字。例如用户希望知道搜索结果总共有多少条，每个筛选项下有多少个候选结果等统计信息，从而指导用户对搜索结果进行筛选，缩小搜索范围。同时，每个筛选项下的可选项需要根据输入和其它关联的筛选值动态生成，这部分也需要聚合服务提供。
3.搜索服务。支持核心的搜索过程，通过输入，返回对应的资产作为搜索结果。分为4个主要的部分。
（1）预处理过程（Preprocess），主要包含对输入的预处理和用户信息的预处理。对输入的预处理主要包括分词，停用，词性还原等基本的文本处理。分词主要包含英文分词和中文分词。英文分词需要处理-_等链接符分词，中文分词主要是用IK分词器。停用主要包含各种词如“的”，“了”，“我”和各种特殊符号“》〉？”等无意义的词语。词性还原是一把双刃剑，因为DataCatalog中的词语不同于一般的自然语言，有比较多的专有名词，比如livelisting不应当被还原为livelist，避免文本匹配的分数不准。同时这部分也包含对输入中的强pattern进行识别，如"数据库名.表名”等。对用户信息的预处理。用户是否为超级用户，是否为API用户等，可以借此判断用户常搜索的资产类型或从未搜索的资产类型。（2）召回过程（Recall），负责通过输入和筛选项根据文本相关度从Elasticsearch查询一定数量的搜索候选结果，供下一步精排使用。召回过程需要保证用户期望的结果包含在召回结果中，否则后续排序优化都是徒劳。同时，召回的数量需要限制在合理的数值。主要原因有两点：一是排序靠后的搜索结果几乎没有用户会查看。二是召回过多的候选结果会影响性能，尤其是排序性能消耗比较大时。我们的召回主要分为两种方式：自然召回和强规则召回。自然召回。对经过预处理的输入进行不同资产类型的召回，使用bestfield的策略，对资产的不同字段设置不同的权重，例如命中名称的资产应当比命中描述的资产优先级高。这里的权重通常根据经验设置，可以根据搜索结果的Badcasereview得到，这个权重数值的精度要求不高，确保期望的结果能召回回来即可。强规则召回。可以定制一些规则，作为自然召回的补充，涵盖精确表名的召回，或者从用户的常用资产列表进行召回。除此之外，还需要做好多租户的隔离，避免当前租户的用户召回其它租户的资产。（3）精排过程（Rank），负责对召回的结果进行最终的排序。精排过程依次包含机器学习模型预测（Learningtorank）和基于规则调整两部分。Learningtorank部分详细介绍见后文。机器学习模型在线预测，负责主要的排序工作。加载离线训练得到的PMML模型文件，提供预测功能。基于强规则的调整，包含排序的各种兜底策略，比较常用的有：1.精确匹配的结果排在第一位。2.添加Tie-breaker，保证分数相同的结果多次搜索的排序一致。（4）后处理过程（Postprocess），对排好序的结果添加各种不影响顺序的后处理。例如：权限检查，隐藏表设置。一些资产不希望被没有相关权限的用户查看详情，需要在搜索结果中设置相应字段并返回给前端。高亮，对命中字段进行高亮标注，返回给前端。3.2LearningtorankLearningtorank主要分为数据收集，离线训练和在线预测三个部分。搜索系统是一个Data-drivensystem，因此系统设计之初就需要考虑数据收集。收集的数据可以用来评估和提升搜索的效果。数据收集和在线预测前面已有介绍，不再赘述，下面主要介绍离线训练部分。离线训练的过程主要包括数据标注，特征工程，模型训练和评估。这四个步骤并非从前往后一气呵成，而是有可能进行评估，发现不足，然后增加标注数据，增加特征，重新训练，再次评估。评估效果有比较明显的收益时，才会上线测试。3.2.1数据标注作为DataCatalog的搜索系统，不太容易获取大规模的人工标注数据，主要有两个原因：一是标注的成本较高，二是领域知识的专业性导致不容易找到合适的标注人员。因此，我们的标注数据来源主要有两个：一是来自搜索日志中有点击的部分，我们将这部分数据划分为三档，曝光有点击，曝光排名前五且未点击和曝光未点击，赋予不同的分数；二是我们根据资产名称结合日志中未点击的输入，基于规则生成一定的训练数据。训练数据集需要持续更新，在reviewbadcase时，可以针对需要改进的场景添加相应的训练数据。3.2.2特征特征工程是一个持续的过程。经过一系列的选取，我们系统的主要特征分为4大类型，涵盖了搜索的文本特征，数据的权威性，用户的个性化数据和数据的时效性。下面列举了一些我们用到的主要特征和分类：1.文本特征（1）入相关的文本特征1.输入长度，比如有多少个词，总长度等等2.输入语言类型，中文或英文（2）文本匹配度相关的特征1.基于词袋的CQR2.Elasticsearch查询返回分数，基于BM252.数据权威性热度：AssetRank，基于资产的使用量和血缘关系，通过WeightedPageRank算法计算得到的资产热度元数据完整度，包含资产的业务元数据，如项目，主题，产品线等资产的最近1天/7天/30天的全平台使用总次数资产所处的生命周期：如上线，待下线，废弃等资产的总点赞数3.用户个性化数据，分为三大类：（1）静态个性化数据1.负责人：当前用户是否是该资产的负责人2.收藏：当前用户是否收藏了该资产3.点赞：当前用户是否点赞了该资产（2）历史搜索查询行为数据1.当前用户历史上最近1天/7天/30天全平台使用该资产的次数2.当前用户历史上最近1天/7天/30天在DataCatalog平台查询点击该资产的次数（3）协同数据1.同部门人员历史上最近1天/7天/30天在DataCatalog平台查询点击该资产的次数2.当前用户历史上最近1天/7天/30天在DataCatalog平台查询点击该资产所属部门所有资产的次数3.当前用户历史上最近1天/7天/30天在DataCatalog平台查询点击该资产所属负责人所有资产的次数4.数据实效性，用户会更倾向于使用最近创建或者有数据更新到资产资产创建时间资产数据等最近更新时间等3.2.3模型Learningtorank通常有三类方法：Pointwise，Pairwise和Listwise。这三类方法各有优缺点，细节介绍如下：1.Pointwise，对每个输入，对每个召回的资产单独打分（通常是Regression），然后按照分数进行排序。优点：简单直观。缺点：排序实际上不需要对资产进行精确打分，这类方法没有考虑召回资产之间的互相关系，考虑到用户在一组资产中只会点击其中一个，排名靠后的和排名靠前的资产在损失函数上的贡献没有体现。2.Pairwise，对每个输入，考虑召回结果中所有资产的二元组合<资产1，资产2>，采取分类模型，预测两个资产的相对排序关系。优点：基于点击与原有相关性分数排序标注简单，相比pointwise考虑到选项之间关系。缺点：同样没有考虑排序前后顺序的重要性不同，样本生成复杂，开销大。对异常标注敏感，错误点影响范围大。3.Listwise，考虑给定输入下的召回资产集合的整体序列，优化整个序列，通常使用NDCG作为优化目标。优点：优化整个序列，考虑序列内资产之间的关系。缺点：单条样本训练量大。样本过少，则无法对所有样本预测得到好的效果。我们对Pointwise和Listwise都做了实验，最终我们的系统采用了Listwise的方案。主要原因是在我们的标注方式下，Listwise的方案更容易标注。具体实现上我们采用了LightGBM的框架。3.2.4评估我们使用了NDCG，AUC和验证点击率的方式对模型进行评估。NDCG，归一化折损累计增益。NDCG是推荐和搜索中比较常用的评估方法，用来整体评估排序结果的准确性。AUC，AUC主要反映排序能力的相对性，用于在正负样本不均衡的情况衡量离线模型拟合情况。重放有点击历史数据的点击率，使用待评估的模型预测有点击的历史输入，排序后得到Top3，Top5，Top10点击率作为参考。这种方式比较直观，缺点是不能反映出在无点击历史数据上的效果。3.3衡量指标搜索服务变更或新模型上线后，我们需要对线上搜索的真实效果进行衡量。目前我们主要通过搜索的点击率和Top3点击率来衡量。由于DataCatalog搜索的特殊性，我们更看重模糊搜索的总体点击率和Top3点击率（输入和资产名称完全一致的为精确搜索，其它为模糊搜索）。实际上，点击率并非越高越好，过高的点击率可能意味着:搜索结果页透出的信息过少，用户不得不点击结果进入资产详情，即使只想查看一些简单的信息。用户在系统上探索的兴趣较小，只搜熟悉的资产或者确定能搜到的输入。当然过低的点击率意味着较差的搜索体验。因此，点击率保持在一定健康的区间后，我们也需要关注模糊搜索和精确搜索的占比等指标。4.其它模式除了个性化的搜索需求，也会有一些场景，用户不需要精细化的排序，只需要把包含相关文本的资产都列举出来，因此我们也支持单纯的列表模式，用户可以在列表模式通过指定字段来对搜索结果进行排序。我们也在规划实现一些querysyntax的功能，以此来支持用户在列表模式下更灵活地约束输入。5.后续工作DataCatalog系统的搜索功能还有很多有意义的工作值得我们继续探索，例如：血缘中的搜索。当一个资产的一级下游就超过上千个时，想从当前资产的众多下游中查找到相关的资产并不容易，因此提供基于血缘的筛选和搜索是一个不错的选择。多租户之间模型的迁移。作为支持多租户的公有云服务，由于租户之间数据的差异，新租户的冷启动问题，以较小的数据量和成本来支持不同租户都有好的搜索体验，也是一个值得挑战的方向。6.关于我们火山引擎大数据研发治理套件DataLeap一站式数据中台套件，帮助用户快速完成数据集成、开发、运维、治理、资产、安全等全套数据中台建设，帮助数据团队有效的降低工作成本和数据维护成本、挖掘数据价值、为企业决策提供数据支撑。
