แชร์ผ่าน


ข้อควรพิจารณาของเกตเวย์ข้อมูลภายในองค์กรสําหรับปลายทางข้อมูลใน Dataflow Gen2

บทความนี้พยายามระบุข้อจํากัดและข้อควรพิจารณาเมื่อใช้เกตเวย์ข้อมูลที่มีสถานการณ์ปลายทางข้อมูลใน Dataflow Gen2

การประเมินหมดเวลา

กระแสข้อมูลที่ใช้เกตเวย์และคุณลักษณะปลายทางข้อมูลจะถูกจํากัดไว้ที่เวลาการประเมินหรือรีเฟรชของหนึ่งชั่วโมง

เรียนรู้เพิ่มเติมเกี่ยวกับข้อจํากัดนี้จากบทความที่ บทความแก้ไขปัญหาเกตเวย์ข้อมูลภายในองค์กร

ปัญหาเครือข่ายกับพอร์ต 1433

เมื่อใช้ Microsoft Fabric Dataflow Gen2 กับเกตเวย์ข้อมูลภายในองค์กร คุณอาจพบปัญหาเกี่ยวกับกระบวนการรีเฟรชกระแสข้อมูล ปัญหาพื้นฐานเกิดขึ้นเมื่อเกตเวย์ไม่สามารถเชื่อมต่อกับกระแสข้อมูลโดยจัดเตรียม Lakehouse เพื่ออ่านข้อมูลก่อนที่จะคัดลอกไปยังปลายทางข้อมูลที่ต้องการ ปัญหานี้สามารถเกิดขึ้นได้โดยไม่คํานึงถึงชนิดของข้อมูลปลายทางที่ใช้อยู่

ในระหว่างการรีเฟรชกระแสข้อมูลโดยรวม การรีเฟรชตารางสามารถแสดงเป็น "สําเร็จแล้ว" แต่ส่วนกิจกรรมจะแสดงเป็น "ล้มเหลว" รายละเอียดข้อผิดพลาดสําหรับกิจกรรม WriteToDatabaseTableFrom_... บ่งชี้ข้อผิดพลาดต่อไปนี้:

Mashup Exception Error: Couldn't refresh the entity because of an issue with the mashup document MashupException.Error: Microsoft SQL: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - An attempt was made to access a socket in a way forbidden by its access permissions.) Details: DataSourceKind = Lakehouse;DataSourcePath = Lakehouse;Message = A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - An attempt was made to access a socket in a way forbidden by its access permissions.);ErrorCode = -2146232060;Number = 10013

หมายเหตุ

จากมุมมองทางสถาปัตยกรรม กลไกกระแสข้อมูลใช้จุดสิ้นสุด HTTPS (พอร์ต 443) ขาออกเพื่อเขียนข้อมูลลงใน Lakehouse อย่างไรก็ตาม การอ่านข้อมูลจากเลคเฮ้าส์จําเป็นต้องใช้โพรโทคอล TDS (TCP ผ่านพอร์ต 1433) โพรโทคอลนี้ถูกใช้เพื่อคัดลอกข้อมูลจากเลคเฮ้าส์จัดเตรียมไปยังปลายทางข้อมูล สิ่งนี้อธิบายว่าทําไมขั้นตอนการโหลดตารางจึงประสบความสําเร็จในขณะที่กิจกรรมปลายทางข้อมูลล้มเหลวแม้ว่าทั้งสองเลคเฮ้าส์จะอยู่ในอินสแตนซ์ OneLake เดียวกัน

การแก้ไขปัญหา

เมื่อต้องการแก้ปัญหานี้ ให้ทําตามขั้นตอนต่างๆ ต่อไปนี้:

  1. ยืนยันว่ากระแสข้อมูลได้รับการกําหนดค่าด้วยปลายทางข้อมูลแล้ว

    ภาพหน้าจอของตัวแก้ไข Power Query ที่เน้นปลายทางของข้อมูล Lakehouse

  2. ตรวจสอบว่าการรีเฟรชกระแสข้อมูลล้มเหลว มีการรีเฟรชตารางที่แสดงเป็น "สําเร็จแล้ว" และกิจกรรมที่แสดงเป็น "ล้มเหลว"

    ภาพหน้าจอของรายละเอียดกระแสข้อมูลพร้อมตารางที่แสดงความสําเร็จและกิจกรรมที่ล้มเหลว

  3. ตรวจทานรายละเอียดข้อผิดพลาดสําหรับ กิจกรรม WriteToDatabaseTableFrom_...ซึ่งให้ข้อมูลเกี่ยวกับข้อผิดพลาดที่พบ

    ภาพหน้าจอของกิจกรรม WriteToDatabaseTablefrom ที่แสดงข้อความแสดงข้อผิดพลาด

วิธีแก้ไข: ตั้งค่ากฎไฟร์วอลล์ใหม่บนเซิร์ฟเวอร์ที่เรียกใช้เกตเวย์

กฎไฟร์วอลล์บนเซิร์ฟเวอร์เกตเวย์ และ/หรือพร็อกซีเซิร์ฟเวอร์ของลูกค้าจําเป็นต้องได้รับการอัปเดตเพื่ออนุญาตให้มีการรับส่งข้อมูลขาออกจากเซิร์ฟเวอร์เกตเวย์ดังต่อไปนี้:

  • โพรโทคอล: TCP
  • จุดสิ้นสุด: *.datawarehouse.pbidedicated.windows.net, *.datawarehouse.fabric.microsoft.com, *.dfs.fabric.microsoft.com
  • พอร์ต: 1433

หมายเหตุ

ในบางสถานการณ์ โดยเฉพาะอย่างยิ่งเมื่อความจุอยู่ในภูมิภาคที่ไม่ใกล้เคียงเกตเวย์ อาจจําเป็นต้องกําหนดค่าไฟร์วอลล์เพื่ออนุญาตให้เข้าถึงจุดสิ้นสุดหลายจุดได้ (*cloudapp.azure.com) การปรับปรุงนี้จําเป็นต้องมีเพื่อให้เหมาะสมกับการเปลี่ยนเส้นทางที่อาจเกิดขึ้นภายใต้เงื่อนไขเหล่านี้ หากปริมาณการใช้งานที่กําหนดไว้สําหรับ *.cloudapp.azure.com ไม่ถูกสกัดกั้นโดยกฎ คุณสามารถอนุญาต ที่อยู่ IP สําหรับขอบเขตข้อมูลของคุณในไฟร์วอลล์ของคุณได้

ถ้าคุณต้องการจํากัดขอบเขตของจุดสิ้นสุดให้แคบลงไปยังอินสแตนซ์ OneLake จริงในพื้นที่ทํางาน (แทนอักขระตัวแทน *.datawarehouse.pbidedicated.windows.net) คุณสามารถค้นหา URL นั้นได้โดยการนําทางไปยังพื้นที่ทํางาน Fabric ค้นหา DataflowsStagingLakehouseและเลือกดูรายละเอียด จากนั้น คัดลอกและวางสายอักขระการเชื่อมต่อ SQL

สกรีนช็อตของพื้นที่ทํางาน Fabric ที่มี DataflowsStagingLakehouse พร้อมจุดไข่ปลาที่เลือก และเน้นตัวเลือก ดูรายละเอียด

สกรีนช็อตของข้อมูลรายละเอียด DataflowsStagingLakehouse ที่เน้นสายอักขระการเชื่อมต่อ SQL

ชื่อปลายทางทั้งหมดมีลักษณะคล้ายกับตัวอย่างต่อไปนี้:

x6eps4xrq2xudenlfv6naeo3i4-l27nd6wdk4oephe4gz4j7mdzka.datawarehouse.pbidedicated.windows.net

วิธีแก้ปัญหา: แยกกระแสข้อมูลในการนําเข้าที่แยกต่างหากและโหลดกระแสข้อมูล

หากคุณไม่สามารถอัปเดตกฎไฟร์วอลล์ได้ คุณสามารถแยกกระแสข้อมูลออกเป็นกระแสข้อมูลที่แยกจากกันสองรายการได้ กระแสข้อมูลแรกมีหน้าที่รับผิดชอบในการนําเข้าข้อมูลลงในเลคเฮ้าส์ที่จัดเตรียมไว้ กระแสข้อมูลที่สองมีหน้าที่รับผิดชอบในการโหลดข้อมูลจากเลคเฮ้าส์ที่กําหนดขั้นไปยังปลายทางของข้อมูล การแก้ไขปัญหาชั่วคราวนี้ไม่เหมาะสมเนื่องจากต้องใช้กระแสข้อมูลที่แยกต่างหากสองตัว แต่สามารถใช้เป็นโซลูชันชั่วคราวได้จนกว่าจะสามารถอัปเดตกฎไฟร์วอลล์ได้

เมื่อต้องการแก้ปัญหานี้ ให้ทําตามขั้นตอนเหล่านี้:

  1. ลบปลายทางของข้อมูลออกจากกระแสข้อมูลปัจจุบันของคุณที่นําเข้าข้อมูลผ่านเกตเวย์ของคุณ

    สกรีนช็อตของตัวแก้ไข Power Query ที่มีปลายทางของข้อมูล Lakehouse ถูกลบออก

  2. สร้างกระแสข้อมูลใหม่ที่ใช้ตัวเชื่อมต่อกระแสข้อมูลเพื่อเชื่อมต่อกับกระแสข้อมูลการนําเข้า กระแสข้อมูลนี้รับผิดชอบในการนําเข้าข้อมูลจากการจัดเตรียมลงในปลายทางข้อมูล

    สกรีนช็อตของตัวแก้ไข Power Query พร้อมตัวเลือกรับข้อมูลที่เลือกไว้และตัวเลือกตัวเชื่อมต่อกระแสข้อมูลจะถูกเน้น

    สกรีนช็อตของกล่องโต้ตอบรับข้อมูลที่มีตัวเลือกตัวเชื่อมต่อกระแสข้อมูลที่เลือกไว้

  3. ตั้งค่าปลายทางของข้อมูลเป็นปลายทางข้อมูลที่คุณเลือกสําหรับกระแสข้อมูลใหม่นี้

    สกรีนช็อตของตัวแก้ไข Power Query ที่มีการตั้งค่าปลายทางของข้อมูล Lakehouse

  4. อีกวิธีหนึ่งคือ คุณสามารถปิดใช้งานการจัดเตรียมสําหรับกระแสข้อมูลใหม่นี้ การเปลี่ยนแปลงนี้จะป้องกันไม่ให้คัดลอกข้อมูลไปยังเลคเฮ้าส์แสดงข้อมูลอีกครั้ง และคัดลอกข้อมูลโดยตรงจากกระแสข้อมูลการนําเข้าไปยังปลายทางของข้อมูล

    ภาพหน้าจอของตัวแก้ไข Power Query พร้อมตัวเลือกการจัดเตรียมที่ถูกปิดใช้งาน